Безопасная разработка (DevSecOps) программного обеспечения для систем КИИ

03.03.2026

Разбираем нормативную базу безопасной разработки ПО для КИИ, архитектуру конвейера DevSecOps, выбор инструментов SAST и DAST, аудит исходного кода и практику сертификации процессов РБПО по ГОСТ Р 56939-2024.

Программное обеспечение, функционирующее в составе значимых объектов критической информационной инфраструктуры, подвергается целенаправленным атакам: от эксплуатации уязвимостей нулевого дня до внедрения закладок через цепочки поставок. Классическая модель «сначала разработка — потом безопасность» не работает: обнаружение дефекта на этапе промышленной эксплуатации обходится в десятки раз дороже, чем его устранение на стадии проектирования. Безопасная разработка КИИ по методологии DevSecOps переносит контроль защищённости на каждый этап жизненного цикла ПО — от формирования требований до вывода из эксплуатации.

Статья адресована CIO и руководителям разработки, которым необходимо привести процессы создания прикладного ПО в соответствие с приказом ФСТЭК № 239, новым ГОСТ Р 56939-2024 и обеспечить готовность к проверкам регулятора. Рассмотрим нормативную базу, архитектуру конвейера DevSecOps, инструменты SAST/DAST, аудит исходного кода и практику сертификации.

Нормативная база: что обязывает применять безопасную разработку

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

реализацию требований по безопасной разработке прикладного ПО;
проведение испытаний по выявлению уязвимостей (статический и динамический анализ, фаззинг);
поддержку безопасности на протяжении всего жизненного цикла.

С 20 декабря 2024 года вступил в силу ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования», заменивший редакцию 2016 года. Если прежний стандарт описывал набор организационных и технических мер, то новый акцентирует внимание на построении и непрерывном совершенствовании процессов безопасной разработки (РБПО). Отдельные разделы посвящены правилам кодирования, контролю целостности кода, проверкам на внедрение вредоносного ПО через цепочки поставок и нефункциональному тестированию.

Дополнительно действуют требования 187-ФЗ о безопасности КИИ, обязывающие субъектов обеспечивать защиту значимых объектов, а также нормы подключения к ГосСОПКА, предполагающие оперативное информирование об инцидентах, в том числе связанных с уязвимостями ПО.

С 1 января 2026 года для средств защиты информации, претендующих на внесение в реестр, обязательным становится подтверждение наличия процедуры устранения ошибок и уязвимостей. Это означает, что DevSecOps ГОСТ — уже не рекомендация, а обязательное условие работы на рынке ИБ.

Принципы DevSecOps в контексте КИИ

DevSecOps — методология, интегрирующая практики информационной безопасности во все этапы разработки и эксплуатации программного обеспечения. Для объектов КИИ она приобретает особое значение: последствия эксплуатации уязвимости в АСУ ТП энергосистемы или медицинской информационной системе несопоставимы с рисками для обычного веб-приложения.

Ключевые принципы

Shift Left — смещение проверок безопасности на самые ранние стадии: формирование требований, проектирование архитектуры, написание кода.
Автоматизация — встраивание инструментов SAST, DAST, SCA, фаззинга в конвейер CI/CD для непрерывного контроля без замедления релизного цикла.
Security as Code — описание политик безопасности, конфигураций и проверок в виде кода, хранимого в репозитории наравне с исходным кодом продукта.
Непрерывный мониторинг — передача данных об уязвимостях и инцидентах в SOC и ГосСОПКА в режиме реального времени.
Общая ответственность — безопасность перестаёт быть задачей выделенного подразделения ИБ; разработчики, тестировщики и операторы несут совместную ответственность.

Внедрение DevSecOps позволяет сократить стоимость устранения уязвимостей в 6–10 раз (за счёт обнаружения на этапе разработки, а не эксплуатации) и сокращает time-to-market при одновременном повышении уровня защищённости. Для субъекта КИИ это также означает готовность к аудитам и проверкам ФСТЭК.

Жизненный цикл безопасной разработки ПО для КИИ

ГОСТ Р 56939-2024 определяет следующую структуру процессов РБПО, которую необходимо реализовать в организации:

Этап	Процессы РБПО	Инструменты / артефакты
Формирование требований	Анализ требований безопасности, моделирование угроз	Модель угроз, Security Requirements Specification
Проектирование	Формирование архитектурных ограничений, определение правил кодирования	Design Review Checklist, Coding Standards
Реализация (кодирование)	Контроль целостности кода, статический анализ, рецензирование	SAST, SCA, Code Review, SBOM
Тестирование	Динамический анализ, фаззинг, нефункциональное тестирование	DAST, IAST, фаззеры, пентест
Выпуск и развёртывание	Проверка конфигураций, контроль IaC-сканирование	IaC-S, Container Security, подпись артефактов
Эксплуатация и сопровождение	Мониторинг уязвимостей, управление патчами, реагирование на инциденты	SOC, ГосСОПКА, Bug Bounty
Вывод из эксплуатации	Безопасное удаление данных, архивирование артефактов	Data Wiping, документирование

Каждый этап порождает артефакты, которые впоследствии предъявляются при сертификации СЗИ и проверках регулятора. Отсутствие документированного процесса — основная причина замечаний при аудитах.

Инструменты SAST и DAST: что выбрать для КИИ

Статический (SAST) и динамический (DAST) анализ — две основные категории автоматизированных проверок, которые должны быть встроены в конвейер CI/CD для ПО значимых объектов КИИ.

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

SAST-инструменты анализируют исходный код (или байткод) без запуска приложения. Они выявляют уязвимости типа SQL-инъекций, XSS, переполнений буфера, небезопасных криптографических реализаций, жёстко закодированных секретов. Для объектов КИИ важно, чтобы инструмент соответствовал требованиям импортозамещения и имел сертификат ФСТЭК.

DAST — динамический анализ

DAST проверяет работающее приложение путём отправки запросов и анализа ответов. Это позволяет обнаружить уязвимости, проявляющиеся только в рантайме: ошибки аутентификации, SSRF, неправильную обработку сессий. DAST дополняет SAST и не может его заменить — используются совместно.

Дополнительные классы инструментов

SCA (Software Composition Analysis) — анализ open-source-компонентов и зависимостей, формирование SBOM (Software Bill of Materials).
IAST (Interactive AST) — гибрид SAST и DAST, работающий в агентном режиме внутри приложения.
Фаззинг — подача случайных и мутированных данных на входы приложения для обнаружения необработанных исключений и аварийных завершений.
IaC-S (Infrastructure as Code Security) — проверка конфигураций Terraform, Ansible, Docker на соответствие политикам безопасности.

Решение	Класс	Сертификат ФСТЭК	Реестр отечественного ПО
Solar appScreener	SAST / DAST / SCA	Есть	№ 7763
PT Application Inspector	SAST / DAST / SCA / IAST	Есть	Есть
Apsafe (УЦСБ)	SAST / SCA / DAST / IaC-S / ASOC	Облачная платформа	Есть
SafeERP Code Security	SAST (SAP ABAP)	Есть	Есть

При выборе инструмента для объектов КИИ приоритетными критериями являются: наличие сертификата ФСТЭК, включение в реестр отечественного ПО, поддержка языков программирования вашего стека и возможность интеграции с существующим CI/CD-конвейером.

Для кого эта услуга

Связь

Топливно-энергетический комплекс

Химическая промышленность

Оборонная промышленность

Энергетика

Атомная энергия

Здравоохранение

Горнодобывающая промышленность

Транспорт

О нашей компании

Постоянно сотрудничаем с крупными государственными и международными корпорациями

Четко выполняем требования контролирующих организаций

Непрерывно работаем над улучшением нашего профессионализма

Послепродажная поддержка в правовых аспектах

Беспроцентная рассрочка (до 4 месяцев)

Бесплатная доставка документации по регионам России лично к заказчику

Клиенты

Присоединиться

Благодарственные письма

Благодарственное письмо от Казино Оракул

Благодарственное письмо от ГАПОУ Уральский политехнический колледж

Благодарственное письмо от СоюзПромЭкспо

Аудит исходного кода: методика и практические рекомендации

Аудит исходного кода — это экспертная проверка программного кода на наличие уязвимостей, архитектурных дефектов, несоответствий стандартам кодирования и потенциальных закладок. В отличие от автоматизированного SAST-сканирования, ручной аудит выполняется квалифицированными специалистами и позволяет обнаружить логические уязвимости, которые инструменты пропускают.

Когда необходим аудит исходного кода

Перед вводом прикладного ПО значимого объекта КИИ в промышленную эксплуатацию (требование п. 29.3 приказа № 239).
При использовании open-source-компонентов — для выявления известных уязвимостей и нежелательных зависимостей.
После существенной модернизации кодовой базы или смены команды разработки.
В рамках подготовки к сертификации СЗИ во ФСТЭК или ФСБ.
При проведении комплексного аудита ИБ перед плановой проверкой.

Структура аудита

Типичный аудит исходного кода для ПО объектов КИИ включает:

Инвентаризацию компонентов — формирование SBOM, определение open-source-зависимостей, проверка лицензионной чистоты.
Автоматизированное сканирование — SAST/SCA для выявления типовых уязвимостей.
Ручной анализ — проверка бизнес-логики, аутентификации, авторизации, криптографических реализаций.
Верификацию результатов — подтверждение обнаруженных уязвимостей, исключение ложных срабатываний.
Формирование отчёта — описание уязвимостей с классификацией по CVSS, рекомендации по устранению, приоритизация.

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

Платформы класса ASOC: Apsafe и оркестрация DevSecOps

Отдельного внимания заслуживают платформы класса ASOC (Application Security Orchestration and Correlation), которые объединяют результаты различных инструментов анализа в единую картину и автоматизируют управление уязвимостями.

Apsafe — облачная платформа от Центра кибербезопасности УЦСБ, предоставляющая экосистему инструментов для безопасной разработки:

SAST, SCA, DAST, IaC-S в едином интерфейсе.
Ручная верификация результатов специалистом по безопасности приложений.
Интеграция с трекерами задач (Jira, YouTrack, Redmine), WAF и SOC.
Уведомления разработчиков через мессенджеры об обнаруженных проблемах.
Подключение за ~10 дней без изменений инфраструктуры разработки (in-house внедрение аналогичного набора инструментов занимает до года).

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

При выборе между on-premise и облачной моделью необходимо учитывать требования к защите ЗОКИИ: для объектов 1-й категории значимости передача исходного кода в облако может потребовать дополнительного обоснования в модели угроз.

Архитектура конвейера: встраивание безопасности в CI/CD

Практическое внедрение DevSecOps для ПО объектов КИИ предполагает модификацию существующего CI/CD-конвейера. Ниже приведена референсная архитектура, которую можно адаптировать под конкретный стек.

Референсный конвейер DevSecOps для ПО объектов КИИ
1. Commit	2. Build	3. Test	4. Release	5. Deploy	6. Operate
Pre-commit hooks Secrets scanning Linting	SAST SCA / SBOM License check	DAST / IAST Фаззинг Пентест (manual)	IaC-S Container scan Подпись артефактов	Runtime protection WAF RASP	SOC / SIEM ГосСОПКА Patch management
Quality Gate 1 — блокировка при критических уязвимостях		Quality Gate 2 — блокировка при непройденных тестах		Quality Gate 3 — подтверждение ИБ-специалистом

Quality Gates (контрольные точки) — критически важный элемент конвейера. Для ПО значимых объектов КИИ рекомендуется три уровня:

QG1 (после сборки) — автоматическая блокировка релиза при обнаружении уязвимостей с CVSS ≥ 7.0 или известных CVE в зависимостях без патча.
QG2 (после тестирования) — блокировка при непройденных функциональных и нефункциональных тестах безопасности.
QG3 (перед развёртыванием) — ручное подтверждение специалистом ИБ для объектов 1-й и 2-й категории значимости.

Такой подход обеспечивает выполнение требований ГОСТ Р 56939-2024 в части нефункционального тестирования и контроля целостности кода, а также готовность к проверкам по КИИ.

Сопровождение сертификации ПО и процессов РБПО

ФСТЭК России проводит сертификацию по двум направлениям, имеющим прямое отношение к DevSecOps:

1. Сертификация средств защиты информации

Если разрабатываемое ПО является средством защиты (антивирус, межсетевой экран, средство обнаружения вторжений), оно подлежит сертификации во ФСТЭК. С 2026 года для включения в реестр необходимо подтвердить наличие процедуры устранения уязвимостей, что фактически требует выстроенного процесса DevSecOps.

2. Сертификация процессов разработки безопасного ПО (РБПО)

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

Чек-лист готовности к сертификации РБПО по ГОСТ Р 56939-2024

Утверждена политика безопасной разработки, назначены ответственные.
Разработаны и актуализированы правила кодирования для каждого используемого языка.
Внедрены инструменты SAST и SCA, интегрированные в CI/CD; результаты архивируются.
Проводится динамический анализ (DAST) и фаззинг перед каждым мажорным релизом.
Сформирован и поддерживается актуальный SBOM для каждого продукта.
Реализован процесс управления уязвимостями: регистрация, приоритизация, устранение, верификация.
Обеспечена целостность кода: подписание коммитов, контроль доступа к репозиторию.
Выполняются проверки на внедрение вредоносного ПО через цепочки поставок (проверка зависимостей).
Документированы процедуры реагирования на инциденты безопасности ПО.
Проведён внутренний аудит процессов РБПО; замечания устранены.

Сертификация РБПО повышает доверие заказчиков и регулятора, упрощает процедуру включения продукта в реестр сертифицированных СЗИ и является конкурентным преимуществом при участии в государственных закупках.

Типичные ошибки при внедрении DevSecOps для КИИ

Опыт проектов по внедрению безопасной разработки позволяет выделить наиболее распространённые ошибки:

№	Ошибка	Последствие	Решение
1	Внедрение SAST без настройки правил	Тысячи ложных срабатываний, разработчики игнорируют результаты	Настроить профиль под стек, подавить неприменимые правила, ввести ручную верификацию
2	Отсутствие Quality Gates	Уязвимый код попадает в продакшен	Определить пороги блокировки для каждого этапа конвейера
3	Игнорирование SCA и цепочек поставок	Уязвимые open-source-библиотеки в составе ПО КИИ	Внедрить SCA, формировать SBOM, мониторить CVE в зависимостях
4	DevSecOps «на бумаге»	Замечания при проверке ФСТЭК, штрафы	Обеспечить реальное функционирование процессов и хранение артефактов
5	Отсутствие обучения разработчиков	Сопротивление внедрению, обход проверок	Проводить Security Champions Program, регулярные тренинги

Предотвращение этих ошибок требует системного подхода. Начните с инвентаризации ИТ-активов и определения периметра ПО, подлежащего требованиям безопасной разработки, а затем поэтапно внедряйте инструменты, начиная с SAST и SCA.

Дорожная карта внедрения DevSecOps для субъекта КИИ

Ниже приведён практический план, рассчитанный на 6–12 месяцев:

Фаза	Срок	Мероприятия	Результат
Фаза 1	Месяцы 1–2	GAP-анализ текущих процессов, инвентаризация ИТ-активов, определение scope, разработка политики РБПО	Отчёт о текущем состоянии, утверждённая политика
Фаза 2	Месяцы 2–4	Выбор и пилотное внедрение SAST/SCA, настройка правил, интеграция в CI/CD, обучение разработчиков	Работающий SAST в конвейере, первые результаты сканирования
Фаза 3	Месяцы 4–6	Внедрение DAST/фаззинга, настройка Quality Gates, запуск процесса управления уязвимостями	Полный цикл автоматизированных проверок, метрики устранения
Фаза 4	Месяцы 6–9	Проведение аудита исходного кода, пентест, подготовка документации для сертификации	Отчёт аудита, план устранения, пакет документов
Фаза 5	Месяцы 9–12	Сертификация РБПО, интеграция с SOC и ГосСОПКА, выход на режим непрерывного совершенствования	Сертификат РБПО, настроенный мониторинг, зрелый процесс

Для организаций, которым необходимо ускорить процесс, доступны облачные платформы (Apsafe) и услуги комплексной кибербезопасности КИИ под ключ, позволяющие сократить сроки до 3–6 месяцев.

Итоги: безопасная разработка как обязательный компонент защиты КИИ

Безопасная разработка КИИ по методологии DevSecOps — это не модный тренд, а нормативное требование, закреплённое в приказе ФСТЭК № 239 и ГОСТ Р 56939-2024. Для CIO и руководителей разработки это означает необходимость:

Интегрировать инструменты SAST, DAST, SCA в конвейер CI/CD с обязательными Quality Gates.
Проводить регулярный аудит исходного кода — как автоматизированный, так и экспертный.
Выстроить процесс управления уязвимостями с фиксацией артефактов для проверок.
Обеспечить соответствие DevSecOps ГОСТ: документировать процессы РБПО, правила кодирования, SBOM.
Рассмотреть сертификацию процессов РБПО как способ подтверждения зрелости и конкурентное преимущество.

Компания «Астелс» сопровождает субъектов КИИ на всех этапах: от категорирования объектов и разработки ОРД до внедрения DevSecOps и подготовки к сертификации. Мы поможем выбрать оптимальный набор инструментов, выстроить конвейер и обеспечить готовность к проверкам регулятора.

Медиа

Была ли полезна вам данная статья?

Да Нет

Отправить запрос

Ваш менеджер

Кирилл Соколов

8(800) 70-70-144

info@sertifikat.bz

Услуги

г. Екатеринбург	г. Москва	г. Челябинск	г. Казань	г. Пермь
г. Волгоград	г. Нижний Новгород	г. Омск	г. Новосибирск	г. Воронеж
г. Санкт-Петербург	г. Ростов-на-Дону	г. Самара	г. Красноярск	г. Уфа