DevSecOps Q1 2025: ГОСТ Р 56939 и первые шаги AppSec

ГОСТ Р 56939: безопасная разработка становится обязательной

ГОСТ Р 56939 «Защита информации. Разработка безопасного программного обеспечения» — ключевой российский стандарт в области безопасной разработки. В 2024 году вышла обновлённая версия стандарта, расширяющая требования к жизненному циклу безопасной разработки (SSDLC).

Для субъектов критической информационной инфраструктуры (КИИ) соответствие ГОСТ Р 56939 становится де-факто обязательным — через привязку к Приказу ФСТЭК №239, который требует обеспечения безопасности ПО, используемого на объектах КИИ.

Основные требования стандарта:

• Моделирование угроз — на этапе проектирования, до написания кода
• Статический анализ кода (SAST) — автоматическая проверка исходного кода на уязвимости
• Динамический анализ (DAST) — тестирование работающего приложения
• Анализ состава ПО (SCA) — проверка используемых библиотек на известные уязвимости
• Управление уязвимостями — процесс выявления, оценки и устранения уязвимостей
• Документирование — фиксация всех этапов безопасной разработки

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

Рынок AppSec в России: ранняя стадия

Рынок инструментов безопасности приложений (Application Security) в России находится на ранней стадии формирования. По оценкам, его объём не превышает 10–15 млрд ₽ — малая доля от общего рынка ИБ (~270 млрд ₽).

Основные игроки:

• Positive Technologies Application Inspector (PT AI) — лидер российского рынка SAST. Поддерживает анализ исходного кода на основных языках (Java, C#, Python, Go, JavaScript). Интеграция с CI/CD, отчёты для ФСТЭК
• Solar appScreener — SAST-решение от «Солар» (дочка «Ростелекома»). Анализ исходного кода и бинарного кода, поддержка 36+ языков
• InfoWatch Attack Killer — WAF (Web Application Firewall) с элементами DAST
• Стингрей (Stingray) — российское решение для тестирования мобильных приложений на безопасность

Критически не хватает российских решений для SCA (Software Composition Analysis) — анализа зависимостей и open-source библиотек. После инцидентов типа Log4Shell (декабрь 2021) важность SCA стала очевидной, но полноценных отечественных инструментов в этом сегменте практически нет. Компании используют open-source решения (OWASP Dependency-Check, Trivy) или западные инструменты (Snyk, Black Duck) там, где это ещё возможно.

Приказ ФСТЭК №239 и требования к КИИ

Приказ ФСТЭК России №239 устанавливает требования к обеспечению безопасности значимых объектов критической информационной инфраструктуры. Для разработчиков ПО, создающих или модифицирующих системы для КИИ, это означает обязательное выполнение ряда требований:

• Безопасная среда разработки — контроль доступа к репозиториям, защита CI/CD-конвейера
• Анализ уязвимостей — регулярное сканирование кода и зависимостей
• Тестирование на проникновение — пентесты перед вводом в эксплуатацию
• Управление конфигурациями — контроль изменений и версионирование
• Реагирование на инциденты — процесс обработки выявленных уязвимостей

К субъектам КИИ относятся организации из 13 отраслей: энергетика, транспорт, связь, здравоохранение, наука, финансы, оборонная промышленность и другие. По оценкам, число субъектов КИИ в России превышает 50 тыс. организаций — и для всех них требования безопасной разработки становятся обязательными.

Атаки на цепочки поставок: растущая угроза

Атаки на цепочки поставок ПО (supply chain attacks) — один из наиболее опасных трендов в кибербезопасности. Инцидент с Log4Shell (декабрь 2021) продемонстрировал масштаб проблемы: одна уязвимость в широко используемой библиотеке затронула миллионы приложений по всему миру.

После Log4Shell осведомлённость о рисках цепочек поставок выросла, но практические меры внедряются медленно:

• SBOM (Software Bill of Materials) — перечень всех компонентов ПО, включая open-source библиотеки. В мире становится стандартом (требование US Executive Order 14028), в России — пока экзотика
• Подпись артефактов — криптографическая верификация пакетов и контейнерных образов (Sigstore, Cosign). Практически не используется в российских компаниях
• Сканирование зависимостей — автоматическая проверка npm, PyPI, Maven-пакетов на уязвимости. Внедрено в 20–30% продуктовых команд

Проблема усугубляется тем, что российские разработчики активно используют open-source библиотеки из международных репозиториев (npm, PyPI, Maven Central). После инцидента с node-ipc (март 2022), когда разработчик библиотеки добавил деструктивный код для пользователей из России, вопрос доверия к цепочкам поставок стал ещё острее.

DevSecOps на практике: первые шаги

Для большинства российских компаний DevSecOps — это скорее цель, чем реальность. Типичная картина:

• Продвинутые компании (5–10%) — полноценный SSDLC, SAST/DAST/SCA интегрированы в CI/CD, security champions в командах, регулярные пентесты
• Средний уровень (20–30%) — SAST запускается, но результаты не всегда обрабатываются. Security review перед релизами, но не на каждый коммит
• Начальный уровень (60–70%) — безопасность «по требованию», пентесты раз в год перед аудитом, отсутствие автоматизации проверок

Главный барьер — не инструменты (PT AI и Solar appScreener доступны), а культура и процессы. Разработчики воспринимают security-проверки как тормоз, руководство — как дополнительные расходы. Изменение этого восприятия — задача CISO и engineering-лидеров, которая требует не столько бюджета, сколько последовательности.

Рекомендация для команд, начинающих путь к DevSecOps: начните с одного инструмента (SAST), интегрированного в CI/CD pipeline. Настройте его так, чтобы он не блокировал сборку, а только информировал. Через 2–3 месяца, когда команда привыкнет к результатам, переходите к обязательным проверкам критических уязвимостей. Постепенность — ключ к устойчивому внедрению.