В поисках баланса: итоги Квартирника по безопасной разработке от УЦСБ

На прошлой неделе в Москве состоялся Квартирник по безопасной разработке — неформальное отраслевое событие, собравшее порядка 200 ИТ-специалистов. Мероприятие объединило представителей регуляторов, разработчиков ПО, интеграторов и крупных заказчиков ИТ-решений для обсуждения самых острых тем безопасной разработки. Организатором выступил российский системный интегратор УЦСБ, стратегическим партнером — ГК «Солар».

Диванная дискуссия: DevSecOps без прикрас

Главным событием вечера стала диванная дискуссия «Как жить с DevSecOps в 2026 году: честный разговор о зрелости, рисках и реальных изменениях». Модератором выступил директор по кибербезопасности компании «СберТех» Всеслав Соленик. В диалоге приняли участие: руководитель направления безопасной разработки УЦСБ Евгений Тодышев, заместитель генерального директора испытательной лаборатории НТЦ «Фобос-НТ», сотрудник ИСП РАН и преподаватель МГТУ им. Н. Э. Баумана ИУ10 Дмитрий Пономарев, директор по кибербезопасности «Домклик» Андрей Лагоденко, директор по информационной безопасности «Точка Банк» Вячеслав Касимов и руководитель направления ИСП РАН Сергей Деев.

Эксперты обсудили, какие подходы к безопасной разработке действительно работают в текущих реалиях, как изменились угрозы за последний год и к чему готовиться дальше.

Острым стал вопрос баланса между скоростью выпуска продукта и его безопасностью. Спикеры признали, что в реальности компромиссы неизбежны. Участники поделились опытом, когда команда разработки может официально принять риск на себя, если потребность в функционале перевешивает потенциальную уязвимость продукта, но с обязательством устранить этот технический долг в оговоренные сроки.

Однако Вячеслав Касимов занял более принципиальную позицию, предложив делать ставку на повышение ИБ-культуры: «Показывать, объяснять, доносить аргументы внутреннему заказчику». Спикер рассказал, как введенная в банке роль product security помогает перевести технические риски на бизнес-язык еще до выпуска релиза, тем самым не доводя ситуацию до потенциально опасных компромиссов. 

Андрей Лагоденко добавил, что конфликты между ИБ и бизнесом — это норма, ведь бизнес оперирует сроками вывода продукта (TTM), а ИБ управляет рисками. Однако если копнуть глубже, обе стороны заинтересованы в стабильности продукта, безопасности данных и прибыли. Конфликт сходит на нет, когда язык абстрактных рисков переводится в бизнес-плоскость: оценка потерь, вероятность реализации, осознанное принятие риска или отказ от него. Участники дискуссии сошлись во мнении, что необходимость вложений в безопасность помогают обосновать демонстрация цифровых угроз, а также вовлечение владельцев продуктов в управление рисками.

Оживленную реакцию зала вызвала тема сертификации процессов разработки на соответствие требованиям приказа 240 ФСТЭК России. Дмитрий Пономарев отметил, что в настоящий момент данная процедура носит рекомендательный характер, прямой бизнес-необходимости стремиться к получению данного сертификата сейчас нет. При этом в первую и основную очередь необходимо думать о реальном развитии качественной и безопасной разработки, выстраивании зрелых практик. И, как следствие, рассматривать возможность прохождения сертификации процессов РБПО до 2028 года. Эксперты уточнили, что на текущий момент в России сертификацию по актуальным требованиям прошли всего несколько компаний, а подготовка к ней занимает от года и требует значительных ресурсов. При этом Дмитрий подчеркнул, что требования к защищенности растут пропорционально усложнению продуктов и цифровым угрозам, в том числе активно прорабатывается нормативно-правовая база в области исследований безопасности ПО, включающего ИИ-модели. По прогнозам спикера, к 2027 году вероятность ввода действия регуляторики, определяющей порядок безопасной разработки и последующей сертификации ПО с ИИ, является высокой.

Дополнил коллегу Сергей Деев, также представляющий ИСП РАН. Он акцентировал внимание на том, что практики безопасной разработки становятся обязательными для все большего количества отраслей, и отметил необходимость их внедрения: «Ими точно нужно заниматься, вы от них никуда не денетесь, они с нами надолго». При этом спикеры сошлись во мнении, что на текущем этапе развития регуляторики подтверждением успешности внедрения практик РБПО не обязательно должен являться сертификат ФСТЭК России, и достаточным будет подготовленный набор артефактов, по возможности, сопровожденный экспертным заключением одной из профильных организаций отрасли, имеющих лицензию ФСТЭК на ТЗКИ. К получению же сертификата на РБПО нужно идти осознанно, без спешки. 

Подтверждением того, что требования к РБПО затрагивают все большее количество организаций, стало упоминание актуальных версий приказов ФСТЭК России 117 и 239, регламентирующих требования к защите информации, включая и безопасную разработку в государственных организациях и критических информационных инфраструктурах. Также важным маркером новых изменений в финансовом секторе является недавно утвержденный Профиль защиты информации для ПО для кредитных и некредитных организаций финансового сектора. Что можно считать примером успешного согласования требований Банка России с разработанным ФСТЭК России отраслевыми стандартами.

Отдельное внимание участники дискуссии уделили взаимодействию с подрядчиками. Практика показывает, что многие внешние разработчики не имеют зрелых процессов безопасности, поэтому заказчикам необходим активный мониторинг, аудит исходного кода и внедрение требований безопасности в договорные отношения.

Важным итогом диалога стало обсуждение проекта «Унифицированная среда» разработки безопасного ПО. В нем реализованы подходы по применению ключевых практик разработки безопасного программного обеспечения, использованию инструментов исследования безопасности ПО. Проект продолжает свое развитие — проводится апробация методологической базы. Инициатива направлена на поддержку повсеместного внедрения практик безопасной разработки. Участники поддержали развитие этого ресурса, а также создание сообщества практиков для обмена опытом и типовыми регламентами. Среди других предложений, прозвучавших в ходе дискуссии: разработка инструментария для валидации контролей различных типов моделей искусственного интеллекта (включая LLM) с учетом проблемы «галлюцинаций», а также подготовка публичного проекта стандарта по защите искусственного интеллекта в рамках ГРПО.

Аудит цепочек поставок: методика от УЦСБ

В рамках серии экспертных докладов руководитель направления безопасной разработки УЦСБ Евгений Тодышев представил авторскую методику оценки рисков. Он начал с диагностики проблемы: большинство аудитов безопасности разработки сегодня страдают от субъективизма, когда итоговые рекомендации часто зависят от личного опыта проверяющего, а не от реальных рисков бизнеса.

В противовес этому УЦСБ предлагает методику, основанную на объективной оценке активов, угроз и уже внедренных средств защиты. Первый шаг — определение уровня критичности актива не абстрактно, а через диалог с бизнесом: что произойдет, если сервис не будет работать час, сутки или двое? Далее — учет компенсирующих мер: наличие WAF, NGFW, MFA или правильно настроенной сетевой сегментации может существенно снизить требуемый уровень контроля на этапе разработки. «Приложение может быть настолько изолированно, что внедрять для него статический анализ необязательно. Мы это тоже учитываем», — пояснил спикер. В результате формируется численная метрика, которая позволяет обоснованно приоритизировать мероприятия.

Особый акцент в докладе был сделан на цепочках поставок и управлении зависимостями. Евгений привел пример внутреннего сервиса с обработкой персональных данных: высокая критичность актива была снижена до средней благодаря тому, что заказчик уже использовал ряд дополнительных средств защиты. При этом эксперт предостерег от погони за «модными» инструментами безопасности на неподготовленной почве. 

Технологические вызовы: ИИ, Open Source и экономика безопасности

Программа Квартирника была насыщена технологическими кейсами. Антон Прокофьев (Solar appScreener) в докладе «Люди и ИИ в безопасной разработке: где кончается эффективность и начинается опасность?» разобрал баланс между автоматизацией и контролем, а также критерии оценки надежности языковых моделей. Антон отметил, что публичные LLM на этапе верификации и исправления уязвимостей кода в разы оптимизируют время, которое команды разработки используют для циклов проверки софта. Но иллюзия скорости на масштабных проектах создает риски пропуска критичных уязвимостей в конечном софте, поэтому точность работы и процент ошибок, используемой LLM, − важнейшие показатели. Кроме того, облачные LLM становятся каналом утечки исходного кода, что создает дополнительные риски для информационной безопасности продукта. Эксперт порекомендовал обратить внимание на локальные (on-premise) специализированные LLM для задач AppSec, которые используются в закрытом контуре компании.

Алексей Смирнов (CodeScoring) представил комплексный подход к контролю безопасности Open Source, предложив методику снижения нагрузки на разработчиков на всех этапах: от IDE до продуктивной среды.

Денис Макрушин (Яндекс) выступил с темой «ИИ в безопасной разработке, и как он меняет поверхность атаки». Спикер предостерег: «К привычным инструментам разработчика сейчас прикрутили руль для управления LLM, и это лишь расширило поверхность атак. Теперь при должной сноровке этим рулем могут управлять хакеры». Он подробно остановился на новых векторах проникновения, которые открывают ML-модели и агенты, манипулировании зависимостями в SDLC.

Леонид Плетнев (1С-Битрикс) в докладе «Зачем бизнесу инвестировать в безопасную разработку ПО» перевел технические метрики в экономическую плоскость, объяснив, как культура РБПО помогает не только снижать риски, но и экономить ресурсы компании.

Завершилась официальная часть серией кратких вендорских докладов и кейсов, плавно перешедших в вечернюю программу.

Выставочная зона: экосистема решений для DevSecOps

На протяжении всего мероприятия работала выставочная зона, где свои решения для безопасной разработки представили лидеры рынка.

Среди партнеров: ГК «Солар» (Солар, Luntry, Hexway), УЦСБ, Security Vision, AppSec Solutions, CodeScoring, СберТех, Deckhouse и SASTAV, «Лаборатория Касперского», Positive Technologies, Axel Pro, Axiom JDK, Axoft, Fortis. В уютных демонстрационных зонах гости смогли познакомиться с инструментами, повышающими качество и безопасность ПО, а также задать вопросы техническим экспертам в неформальной обстановке.

Квартирник по безопасной разработке подтвердил: сообщество DevSecOps в России продолжает активно искать баланс между жесткими требованиями регуляторов, скоростью разработки и внедрением новых технологий, включая ИИ.

Первый Квартирник состоялся в 2025 году в Екатеринбурге и показал, насколько востребована атмосфера открытого диалога о безопасной разработке. В этом году организаторы перенесли площадку в Москву — и расчет оправдался: гости с интересом откликнулись, активно вовлекаясь в дискуссии и задавая вопросы разработчикам DevSecOps-решений.