Журнал "Information Security/ Информационная безопасность" #2, 2026

– Как вы подходите к выбору инструментов для РБПО? – Универсальной методики выбора нет – слишком разные классы инстру- ментов и задачи. Но есть базовые прин- ципы, от которых отталкивается команда безопасной разработки УЦСБ. Интегра- ция в существующий ландшафт – инстру- менты должны вписываться в инфра- структуру заказчика: работать с систе- мами управления задачами, CI/CD, аутентификацией, а также уметь пере- давать результаты в агрегаторы вроде ASOC, где происходит централизованная обработка уязвимостей. Дальше начинаются специфические требования по классам решений. Для SAST ключевое требование – качество поддержки языков. Даже если два инструмента заявляют поддержку одного языка, на практике качество ана- лиза может сильно отличаться, поэтому мы всегда рекомендуем проводить пило- ты. Для компилируемых языков важно, чтобы анализатор корректно встраивал- ся в процесс сборки – это напрямую влияет на точность результатов и сни- жает количество ложных срабатываний обоих типов. Для SCA критичны несколько факто- ров. Во-первых, качество и полнота Vul- nerability Feeds – открытых баз часто недостаточно. Во-вторых, способность проверять наличие уязвимости в биб- лиотеке, и ее достижимость в конкрет- ном приложении. Без этого заказчик получает тысячи срабатываний, из кото- рых реально значимыми оказываются единицы. Отдельно стоит требование к проверке лицензионной чистоты – этот аспект становится все более важным. А еще для ряда отраслей критична возмож- ность работы в изолированной среде, без доступа в интернет. Дополнительный важный критерий – производительность. Инструменты долж- ны уметь работать не только с полным кодом, но и с изменениями. Если анализ каждого коммита занимает часы, то это ломает весь пайплайн и вызывает сопро- тивление со стороны разработчиков. В итоге выбор всегда балансирует между качеством анализа, скоростью, интеграцией и применимостью в кон- кретном технологическом и организа- ционном контексте. – Как безопасная разработка помогает выполнять требования регуляторов? И могут ли центра- лизованные модули безопасности стать отраслевым стандартом? – Регуляторные требования в этой области постоянно развиваются. Появляются новые ГОСТы, актуализи- руются отраслевые документы, уточ- няются требования к уровням доверия и к процессам разработки. Если ком- пания подходит к этому фрагментарно, то каждое новое требование превра- щается в отдельный проект: нужно срочно писать регламенты, собирать документы, восстанавливать логику процессов и заново доказывать соот- ветствие. Это затратно и по времени, и по усилиям. Если же практики безопасной разра- ботки внедрены системно и по ним дей- ствительно ведется работа, подтвер- ждать соответствие становится заметно проще. Ценность безопасной разработки не сводится только к выполнению требова- ний. Многие практики, например доку- ментирование архитектуры, учет компо- нентов, описание зависимостей и про- цессов, полезны и для регулятора, и для эксплуатации. Они помогают при рас- следовании инцидентов, внедрении защитных мер и в целом повышают управляемость разработки. Что касается централизованных моду- лей безопасности, шлюзов и подобных решений, то это важный и перспективный подход, но не универсальная замена под- ходу Secure-by-Design. Такие механизмы действительно дают плюсы: централизо- ванное управление, единые политики, удобство масштабирования, особенно в больших и распределенных инфраструк- турах. Поэтому как отраслевой паттерн они вполне могут развиваться и стано- виться все более распространенными. Но есть и обратная сторона. Любой такой шлюз становится критически важной точ- кой: это и дополнительная поверхность атаки, и потенциальная точка отказа. Если он скомпрометирован, то риски возникают уже для всего сегмента, кото- рый он защищает. Поэтому сам такой модуль должен разрабатываться по мак- симально жестким требованиям безопас- ности, проходить проверки, а если это стороннее решение, то иметь подтвер- жденную зрелость процессов разработки и независимую оценку. Есть и еще один риск – культурный. Появление централизованного защит- ного слоя может создать у разработчи- ков ложное ощущение, что безопасность теперь вынесена наружу и самим про- дуктом можно заниматься менее внима- тельно. Это опасная иллюзия. Даже при наличии шлюзов базовые практики без- опасной разработки внутри самого ПО все равно необходимы. Наиболее реалистичный сценарий будущего – не замена одной модели на другую, а их сочетание: централизован- ные модули безопасности могут стать важной частью отраслевого стандарта, но только как дополнительный защитный слой, а не как оправдание отказа от безопасной разработки самого промыш- ленного ПО. – Недавно прошел ваш квар- тирник по безопасной разработ- ке. Как вы оцениваете результа- ты и планируете ли развивать формат? – Для нас это уже не первое мероприя- тие, мы проводим его третий год подряд. Начинали с небольших встреч в Екате- ринбурге, там же прошел первый квар- тирник, а в этом году мы вышли на более высокий уровень – провели меро- приятие в Москве. По масштабу это был заметный шаг вперед: более двухсот участников – заказчики, партнеры, кол- леги по рынку. Особенно ценно, что мы получили в основном положительную обратную связь – и по содержанию, и по атмосфере. Мы точно планируем про- должать. Основная цель таких мероприятий – популяризация практик безопасной раз- работки и создание площадки для обме- на опытом. В следующем году, скорее всего, будем думать о расширении мас- штаба. При этом хотим сохранить фор- мат. Квартирник ценен своей камер- ностью, неформальной атмосферой, воз- можностью спокойно пообщаться со спи- керами, задать вопросы, обсудить прак- тические кейсы. Это не классическая конференция в пиджаках и галстуках, и нам важно не потерять эту особенность. Такие мероприятия как квартирник играют важную роль – они формируют ощущение сообщества, дают площадку для обмена опытом и живого диалога. Особенно востребован формат дискус- сий: он позволяет услышать разные точки зрения, выйти за рамки классиче- ских докладов. – Растет ли сообщество РБПО? – Да, сообщество заметно расширяет- ся. Во-первых, растет число компаний, вовлеченных в профильные инициативы, например в работу комитетов при ФСТЭК России по безопасной разра- ботке. Во-вторых, все больше заказчиков приходят в УЦСБ с задачами внедрения РБПО, в том числе те, у кого раньше таких процессов не было вообще. Растет и интерес со стороны регуля- торов: Центрального банка России, про- фильных ведомств, которые развивают требования и стимулируют компании двигаться в этом направлении. При этом важно, что развитие идет не сверху – из-за требований, а снизу: компании сами начинают понимать ценность без- опасной разработки. l Критически важно выстраивать единое понимание на уровне бизне- са: зачем внедряется безопасная разработка, какие компромиссы неизбежны. Безопасность – это управляемый риск. В конечном счете безопасность должна рабо- тать на бизнес, а не превращаться в формальность ради галочек. • 13 ПЕРСОНЫ www.itsec.ru На правах рекламы Ваше мнение и вопросы присылайте по адресу is@groteck.ru