Содержание
Безопасная разработка программного обеспечения — это процессы, которые не дают уязвимостям попасть в код и помогают быстро закрыть те, что всё же прошли. Её содержание в России задаёт ГОСТ Р 56939-2024, а обязательной её делают документы ФСТЭК России — для операторов государственных информационных систем, разработчиков ПО для значимых объектов КИИ и изготовителей сертифицированных средств защиты. Разберём требования и инструменты для статического, динамического и композиционного анализа: PT Application Inspector, АК-ВС 3, Burp Suite Professional и другие. Факты — из текста стандарта, документов ФСТЭК и госреестра на 1 октября 2026 года.
Что такое безопасная разработка и ГОСТ Р 56939-2024
Стандарт называет безопасным ПО, созданное в ходе процессов, которые предотвращают появление недостатков программы и устраняют их. В отраслевой речи это РБПО — разработка безопасного программного обеспечения.
ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» утверждён приказом Росстандарта от 24 октября 2024 г. № 1504-ст и действует с 20 декабря 2024 года вместо редакции 2016 года. Его готовили ФСТЭК России и разработчики средств защиты, среди них Positive Technologies и НПО «Эшелон».
Главное отличие от старой редакции: вместо мер по этапам жизненного цикла — 25 процессов с целями, требованиями и артефактами (документами, журналами, отчётами инструментов), по которым соответствие проверяет аудитор. Процессы не привязаны к модели жизненного цикла и встраиваются и в классическую разработку, и в конвейер DevSecOps.
25 процессов: что требует стандарт
Процессы (подразделы 5.1–5.25) удобно разделить на пять групп:
| Группа | Процессы стандарта |
|---|---|
| Организация | планирование (5.1), обучение сотрудников (5.2), требования безопасности к ПО (5.3), управление конфигурацией (5.4), управление недостатками (5.5) |
| Проектирование | архитектура (5.6), моделирование угроз и поверхность атаки (5.7), правила безопасного кодирования (5.8) |
| Проверка кода | экспертиза кода (5.9), статический анализ (5.10), динамический анализ и фаззинг (5.11), композиционный анализ (5.16), функциональное и нефункциональное тестирование (5.18, 5.19) |
| Сборка и цепочка поставок | система сборки (5.12), сборочная среда (5.13), доступ и целостность кода (5.14), секреты (5.15), проверка кода из цепочек поставок (5.17) |
| Выпуск и эксплуатация | выпуск версии (5.20), поставка (5.21), поддержка (5.22), реагирование на уязвимости (5.23), поиск уязвимостей (5.24), вывод из эксплуатации (5.25) |
Главный артефакт почти каждого процесса — регламент с ролями и порядком работы; регламенты можно свести в одно руководство по разработке безопасного ПО (п. 4.12). Проверки кода подключают к контролю версий, непрерывной интеграции и системе задач (п. 4.13).
Моделирование угроз в стандарте — это угрозы самому разрабатываемому ПО. Модель угроз информационной системы по методике ФСТЭК — другой документ.
Не всё в стандарте обязательно. Требования со словами «рекомендуется» и «может» — рекомендации, требования к секретам (5.15) и часть требований к поиску уязвимостей при эксплуатации (5.24.2.3–5.24.2.4) применяются по усмотрению разработчика, а оценивать при аудите процессы из справочного приложения А не обязательно.
Кому безопасная разработка обязательна
Сам стандарт обязанностей не создаёт: процессы к реализации определяют нормативные акты, другие стандарты и техническое задание. Если документ требует соответствия ГОСТ Р 56939-2024, выполнять нужно все требования, кроме рекомендаций (п. 4.14). Такие документы есть у ФСТЭК России:
| Кто | Документ | Что требуется |
|---|---|---|
| Оператор ГИС, иной ИС госоргана, ГУП или госучреждения, который пишет ПО сам | приказ ФСТЭК № 117, п. 50 | меры разделов 4 и 5 ГОСТ Р 56939-2024, внутренний регламент |
| Тот же оператор, если ПО пишет подрядчик | приказ № 117, п. 50 | требования стандарта можно включить в техническое задание по решению руководителя |
| Субъект КИИ и разработчик прикладного ПО для значимого объекта | приказ ФСТЭК № 239, п. 29.3 | руководство по безопасной разработке, анализ угроз, статический анализ, фаззинг; для 1-й категории — ещё описание структуры ПО и динамический анализ |
| Изготовитель сертифицированного средства защиты | требования по уровням доверия (приказ ФСТЭК № 76) | документация по безопасной разработке, испытания на уязвимости и недекларированные возможности, поддержка безопасности |
| Изготовитель СЗИ, который сертифицирует процессы | порядок сертификации (приказ ФСТЭК № 240) | соответствие процессов ГОСТ Р 56939-2024 |
Для госсектора содержание регламента раскрывает методический документ ФСТЭК от 12 апреля 2026 года (п. 3.12): состав ПО, ответственные, процессы и перечень инструментальных средств. В КИИ выполнение п. 29.3 оценивает исполнитель работ по созданию значимого объекта на этапе проектирования — по документам разработчика (п. 29.4); о прочих мерах — в статье о средствах защиты КИИ.
Остальным разработчикам стандарт становится обязательным, когда на него сошлётся договор или техническое задание заказчика; для НИОКР процессы нужно перечислить в ТЗ явно, можно не в полном объёме (п. 4.15).
Сертификация процессов безопасной разработки во ФСТЭК
С 1 июня 2024 года изготовитель средств защиты может сертифицировать и процессы разработки — по порядку из приказа ФСТЭК России от 1 декабря 2023 г. № 240, а после изменений приказом от 30 июня 2025 г. № 230 — на соответствие ГОСТ Р 56939-2024.
Проверку по заявке изготовителя проводит аккредитованный орган по сертификации. Эксперты работают на площадке изготовителя в России, включая среду сборки: смотрят артефакты всех 25 процессов, наличие средств статического, динамического и композиционного анализа, квалификацию сотрудников и проводят инструментальный контроль. Сертификат выдаётся не более чем на пять лет.
Выгода — с действующим сертификатом процессов изготовитель сам проводит испытания при изменениях сертифицированного средства, включая новые функции безопасности и обновления версий (информационное сообщение ФСТЭК от 26 апреля 2024 г.). О сертификатах на сами средства и уровнях доверия — в статье о сертификатах ФСТЭК и ФСБ.
Средства безопасной разработки: какие инструменты нужны
Продуктов стандарт не называет, но требует инструментов статического, динамического (с фаззингом) и композиционного анализа — их наличие проверяют и при сертификации процессов.
| Процесс ГОСТ Р 56939-2024 | Класс инструмента | Продукты в каталоге |
|---|---|---|
| 5.10 Статический анализ исходного кода | SAST | PT Application Inspector, АК-ВС 3 |
| 5.16 Композиционный анализ | SCA — анализ сторонних компонентов | PT Application Inspector |
| 5.15 Секреты | поиск паролей и ключей в коде | PT Application Inspector |
| 5.11 Динамический анализ | DAST для веб-приложений, динамический анализ ПО | PT BlackBox, Burp Suite DAST, PT Application Inspector, АК-ВС 3 |
| 5.11 Фаззинг-тестирование | фаззер | АК-ВС 3 |
| 5.19 Нефункциональное тестирование, имитация действий нарушителя | ручное тестирование на проникновение | Burp Suite Professional |
| 5.13 и 5.16 для контейнерных образов | безопасность контейнеров | PT Container Security |
DAST-сканер — лишь один из методов динамического анализа: он подаёт работающему веб-приложению некорректные данные. Фаззинг-тестирование стандарт требует отдельно (5.11.2.7), в том числе для веб-приложений. Код из цепочек поставок проверяют как минимум антивирусом — отчёты сканирования прямо названы в п. 5.17.3.5.
Инструменты Positive Technologies
Товар PT Application Inspector по запросу Смотреть →PT Application Inspector сочетает статический анализ, анализ сторонних компонентов и динамический анализ. Он ищет уязвимости, недекларированные возможности вроде закладок, пароли и ключи в коде, а для заимствованных библиотек проверяет, вызывается ли уязвимая функция на самом деле, — меньше времени уходит на ложные срабатывания. Базовых языков четырнадцать — среди них Java, C#, Go, Python и Swift, в версии 6.0 добавлен 1С; есть бесплатные плагины для JetBrains и Visual Studio Code. Сертификат ФСТЭК № 4000 по 4-му уровню доверия действует до 3 сентября 2028 года.
Товар PT BlackBox по запросу Смотреть →PT BlackBox проверяет веб-приложение методом чёрного ящика — как злоумышленник, который не знает устройства приложения. Ставится на инфраструктуре заказчика, запускается из сценариев CI/CD, проверяет API по описанию OpenAPI.
Товар PT Container Security по запросу Смотреть →PT Container Security сканирует образы и конфигурации (Dockerfile, манифесты Kubernetes), не пускает в кластер небезопасные ресурсы и следит за работающими контейнерами; в базе уязвимостей — российские Linux и БДУ ФСТЭК. В госсекторе он помогает с мерой группы ЗКО из методического документа ФСТЭК — выявлением известных уязвимостей в образах контейнеров.
PT Maze решает задачу за рамками стандарта: защищает мобильные приложения для iOS и Android от реверс-инжиниринга, клонов и взлома.
Burp Suite и АК-ВС 3: инструменты других производителей
Burp Suite Professional (PortSwigger) — инструмент специалиста по тестированию на проникновение: перехват трафика, ручная правка запросов и автоматическое сканирование. Лицензия — на конкретного специалиста. Подходит для нефункционального тестирования глазами нарушителя (п. 5.19) и ручной проверки находок сканеров.
Товар Burp Suite DAST по запросу Смотреть →Burp Suite DAST — тот же движок для всего портфеля веб-приложений: проверки по расписанию и в CI/CD, пользователей без ограничения, установка на своих серверах, в Kubernetes или в облаке PortSwigger.
АК-ВС 3 (НПО «Эшелон») — анализатор исходных текстов со статическим и полносистемным динамическим анализом и фаззинг-тестированием. Статический анализ — для C/C++, Java, C#, PHP, Python, JavaScript, Go и Perl; работает на Astra Linux SE 1.7 и 1.8 и Ubuntu, в том числе без сети. Отчёты строятся по методике ФСТЭК 2020 года по выявлению уязвимостей и недекларированных возможностей; есть версия с сертификатом Минобороны России.
Из перечисленных инструментов в государственном реестре сертифицированных средств защиты ФСТЭК на 1 октября 2026 года есть только PT Application Inspector. Если заказчик требует сертифицированный анализатор, учтите это при выборе.
Как организовать безопасную разработку: с чего начать
- Определите область. Какие продукты, версии и модули попадут под процессы и какие процессы уже работают.
- Опишите процессы. Руководство по разработке безопасного ПО с регламентами; для госсектора — регламент по п. 3.12 методического документа ФСТЭК.
- Подключите проверки к конвейеру. Статический и композиционный анализ — на каждое изменение кода, динамический — на тестовом стенде, находки — в систему задач.
- Проверьте инструмент на своём коде. У PT Application Inspector есть тест-драйв: показ на платформе PT Matrix (около часа), демонстрация по программе испытаний (3–12 часов) и работа на стенде (3–10 дней). У Burp Suite Professional — пробная версия, у PT BlackBox — бесплатный онлайн-сканер.
- Обучите команду (5.2) и примите правила безопасного кодирования для каждого языка (5.8).
- Настройте работу с уязвимостями после выпуска (5.23, 5.24) — того же требует п. 29.3.3 приказа № 239. У оператора, который эксплуатирует ПО, своя обязанность — управление уязвимостями по методикам ФСТЭК.
Сколько стоят инструменты и как купить
Продукты Positive Technologies лицензируются под проект, цена — по запросу. У АК-ВС 3 и Burp Suite Professional цены открыты. Стартовая лицензия АК-ВС 3 — один проект на год:
Годовая подписка Burp Suite Professional на одного специалиста:
Подберём инструменты, выставим счёт и подготовим договор для юрлица.
Частые вопросы
Что такое безопасная разработка программного обеспечения? +
По ГОСТ Р 56939-2024 безопасное ПО — это ПО, разработанное в ходе процессов, направленных на предотвращение появления и устранение недостатков программы, в том числе уязвимостей. Стандарт описывает 25 таких процессов: от обучения разработчиков и моделирования угроз до статического, динамического и композиционного анализа и поиска уязвимостей в выпущенных версиях. Сокращённо безопасную разработку называют РБПО.
Чем ГОСТ Р 56939-2024 отличается от ГОСТ Р 56939-2016? +
Редакция 2016 года группировала меры по процессам жизненного цикла — от анализа требований до решения проблем при эксплуатации, плюс управление конфигурацией, инфраструктурой среды разработки и персоналом. Редакция 2024 года действует с 20 декабря 2024 года и описывает 25 процессов, не привязанных к модели жизненного цикла; для каждого заданы цели, требования и артефакты. Отдельными процессами стали композиционный анализ, защита секретов, безопасность сборочной среды и проверка кода из цепочек поставок на вредоносное ПО.
Обязателен ли ГОСТ Р 56939-2024? +
Сам стандарт обязанностей не создаёт: какие процессы реализовать, определяют нормативные акты, другие стандарты и техническое задание (п. 4.14). Оператор ГИС или иной ИС госоргана, ГУП, госучреждения, который сам разрабатывает ПО для своих систем, обязан реализовать меры разделов 4 и 5 стандарта (п. 50 требований, утверждённых приказом ФСТЭК № 117). Для прикладного ПО значимых объектов КИИ требования задаёт п. 29.3 приказа № 239, а сертификация процессов разработки средств защиты во ФСТЭК идёт на соответствие этому стандарту. В остальных случаях стандарт обязателен, если на него ссылается договор или ТЗ; для НИОКР процессы нужно явно перечислить в ТЗ, допускается неполный объём (п. 4.15).
Какие требования к безопасной разработке предъявляет ФСТЭК для КИИ? +
Пункт 29.3 приказа № 239 требует от прикладного ПО значимого объекта: руководство по безопасной разработке, анализ угроз безопасности ПО, статический анализ исходного кода, фаззинг-тестирование, процедуры отслеживания и исправления ошибок и уязвимостей, способы и сроки доведения до пользователей информации об уязвимостях и обновлений. Для 1-й категории значимости добавляются описание структуры ПО, динамический анализ кода и информирование об окончании производства или поддержки. Выполнение оценивают на этапе проектирования значимого объекта по документам разработчика (п. 29.4).
Какие средства безопасной разработки нужны? +
Минимум — инструменты, которых прямо требует стандарт: статический анализатор для каждого используемого языка (5.10), средства динамического анализа и фаззинг-тестирования (5.11) и средства композиционного анализа заимствованных компонентов (5.16). Их наличие проверяют и при сертификации процессов во ФСТЭК. Статический и композиционный анализ закрывает PT Application Inspector, статический и динамический анализ с фаззингом — АК-ВС 3, динамический анализ веб-приложений — PT BlackBox и Burp Suite DAST.
Как связаны DevSecOps и ГОСТ Р 56939-2024? +
Слова DevSecOps в стандарте нет, но его процессы намеренно не привязаны к модели жизненного цикла (п. 4.3), а среда разработки должна обеспечивать контроль версий, непрерывную интеграцию и управление задачами, с которыми интегрируются проверки кода (п. 4.13). Поэтому конвейер DevSecOps со статическим, композиционным и динамическим анализом при каждом изменении — удобный способ выполнить требования, если к нему добавить регламенты и артефакты, которые требует стандарт.
На какой срок выдают сертификат на процессы безопасной разработки? +
На срок, указанный изготовителем в заявке, но не более чем на пять лет (порядок, утверждённый приказом ФСТЭК России от 1 декабря 2023 г. № 240). Сертифицируют процессы разработки ПО средств защиты информации на соответствие ГОСТ Р 56939-2024; проверка идёт на площадке изготовителя в России.
