DevSecOps Q4 2025: ФСТЭК №177 и карта инструментов AppSec

Введение

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

При этом реальный уровень зрелости DevSecOps в стране остаётся низким: лишь около 10%компаний имеют интегрированные практики безопасности в CI/CD. Разрыв между регуляторными требованиями и фактическими возможностями — главная проблема отрасли.

Приказ ФСТЭК №177: что изменилось

ГОСТ Р 56939 «Защита информации. Разработка безопасного программного обеспечения» существовал и раньше, но его применение было ограниченным. Приказ ФСТЭК №177, вступивший в силу в октябре 2025 года, радикально расширил область обязательного применения.

Теперь требования распространяются на всех разработчиков ПО, поставляемого для объектов КИИ — критической информационной инфраструктуры. Это банки, телеком, энергетика, транспорт, здравоохранение и их подрядчики. Если раньше ГОСТ 56939 был обязателен для десятков компаний, то теперь — для сотен.

Что требует ГОСТ на практике: моделирование угроз на этапе проектирования, статический анализ кода (SAST), проверка зависимостей (SCA), фаззинг-тестирование и документирование процессов безопасной разработки. Для компаний, привыкших к «безопасность — проблема ИБ-отдела», это культурный шок.

Карта инструментов AppSec: российский ландшафт

Санкции вытеснили с российского рынка ряд западных инструментов — Checkmarx, Snyk, Veracode стали недоступны или работают с ограничениями. На их место пришли отечественные продукты, и к Q4 2025 карта инструментов выглядит так:

SAST — статический анализ кода

PT Application Inspector от Positive Technologies — лидер российского рынка SAST. Поддерживает анализ исходного кода на основных языках (Java, C#, Python, Go, JavaScript), интегрируется с CI/CD-пайплайнами и предоставляет рекомендации по исправлению. Для компаний, подпадающих под требования ФСТЭК, PT AI — наиболее очевидный выбор.

Solar appScreener поддерживает 36языков программирования — рекордный показатель среди российских SAST-инструментов. Особенность — возможность анализа бинарного кода (без исходников), что полезно при аудите стороннего ПО.

SCA — анализ состава ПО

CodeScoring — российский инструмент Software Composition Analysis. Проверяет open-source зависимости на уязвимости и лицензионные конфликты. В контексте ГОСТ 56939 — обязательный элемент: стандарт требует контроля сторонних компонентов.

Рынок SCA в России менее зрелый, чем SAST. Многие компании до сих пор используют бесплатные инструменты (OWASP Dependency-Check) или проверяют зависимости вручную. CodeScoring — единственный российский enterprise-продукт в этом сегменте.

DAST и фаззинг

Динамический анализ (DAST) и фаззинг-тестирование — самые слабые звенья российского AppSec-стека. Отечественных продуктов enterprise-уровня практически нет. Компании используют open-source инструменты (OWASP ZAP, AFL) или разрабатывают собственные решения.

10% зрелости: почему так мало

Лишь около 10% российских компаний имеют зрелые практики DevSecOps. Что значит «зрелые»? Это интеграция SAST и SCA в CI/CD, автоматическое блокирование сборки при критических уязвимостях, security gate перед деплоем в продакшен и регулярное обучение разработчиков основам безопасного кода.

Остальные 90% распределяются по спектру от «проводим ручной пентест раз в год» до «у нас нет никакой проверки кода на безопасность». Причины:

• Кадровый дефицит — специалистов, одновременно разбирающихся в разработке и безопасности, критически мало. Вакансии DevSecOps выросли на 45% за год, но заполняются медленно
• Стоимость инструментов — enterprise-лицензии PT Application Inspector или Solar appScreener недоступны для малого и среднего бизнеса
• Культурный разрыв — в большинстве компаний безопасность и разработка существуют как отдельные силосы. DevSecOps требует организационных изменений, а не только покупки инструментов
• Отсутствие стимулов — до приказа №177 у многих компаний не было формальных причин внедрять DevSecOps. Регуляторное давление — главный катализатор изменений

Рынок труда: DevSecOps +45%

Рост вакансий DevSecOps на 45%за год — один из самых высоких показателей среди инженерных специализаций. Компании ищут специалистов, способных встроить безопасность в CI/CD, настроить SAST/SCA/DAST-инструменты и обучить разработчиков основам безопасного кода.

Проблема: рынок кандидатов не успевает за спросом. Типичный DevSecOps-инженер — это бывший DevOps, прошедший дополнительное обучение по безопасности, или ИБ-специалист, освоивший инфраструктурные инструменты. Путь подготовки — долгий, 2–3 года минимум.

Зарплатные ожидания растут: senior DevSecOps в Москве к концу 2025 года — 350–500 тыс. ₽. Конкуренция за этих специалистов ведётся между банками, телекомом и IT-интеграторами.

КИИ и цепочка поставок: новый периметр

Приказ №177 сместил фокус регулирования с самих объектов КИИ на их цепочку поставок. Если раньше банк отвечал за безопасность своей инфраструктуры, то теперь он обязан требовать соблюдения ГОСТ 56939 от своих подрядчиков — разработчиков и интеграторов.

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

Интерпретация: безопасность как инженерная дисциплина

DevSecOps в России к концу 2025 года — это парадоксальная ситуация. С одной стороны — жёсткие регуляторные требования, растущий ландшафт инструментов и взрывной рост вакансий. С другой — 90% компаний без зрелых практик, дефицит кадров и культурный разрыв между разработкой и безопасностью.

Приказ ФСТЭК №177 — переломный момент. Он превращает безопасную разработку из «хорошей практики» в обязательное условие работы на крупнейших рынках. Компании, начавшие внедрение DevSecOps в 2025 году, будут готовы к 2026. Компании, откладывающие внедрение, рискуют потерять доступ к заказчикам из сегмента КИИ — а это самый платёжеспособный сегмент российского IT-рынка.

Источники

Исследование подготовлено редакцией it-institute.ru на основе анализа открытых источников с использованием собственной аналитической методологии. Все числовые утверждения сопровождаются ссылками на первоисточники.

FAQ о DevSecOps Q4 2025 и оркестрации AppSec