SecRadar / Комплаенс / РБПО и ГОСТ Р 56939

ГОСТ Р 56939-2024 · Комплаенс РБПО

РБПО и ГОСТ Р 56939-2024: что это, что требует и когда обязательно

Q: Что такое РБПО?

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

Q: Что требует ГОСТ Р 56939?

Действующая редакция ГОСТ Р 56939-2024 описывает 25 процессов безопасной разработки в разделе 5 (пункты 5.1–5.25) — от планирования и обучения сотрудников до моделирования угроз, экспертизы исходного кода, статического анализа (SAST), динамического анализа и фаззинга (DAST), композиционного анализа компонентов (SCA), безопасной сборки, реагирования на уязвимости после выпуска ПО и вывода ПО из эксплуатации. В отличие от отменённой редакции 2016 года, которая описывала набор организационно-технических мер, версия 2024 года требует выстроить и поддерживать сквозные процессы на протяжении всего жизненного цикла продукта.

Q: Обязателен ли ГОСТ Р 56939?

Формально национальный стандарт добровольный — таково общее правило для ГОСТ Р по закону «О стандартизации в РФ». Но фактически он обязателен по ссылке из двух схем ФСТЭК: при сертификации процессов безопасной разработки СЗИ по приказу №240 от 01.12.2023 (порядок сертификации прямо ссылается на ГОСТ Р 56939, с 30.06.2025 — уже на редакцию 2024 года) и содержательно — при сертификации СЗИ по уровням доверия (приказ №76 от 02.06.2020), где на всех открытых уровнях требуется документация по безопасной разработке средства. Для разработчиков, не претендующих на сертификат ФСТЭК, стандарт остаётся добровольным ориентиром.

Q: Чем РБПО связан с сертификацией ФСТЭК?

Связь идёт по двум независимым линиям. Первая — сертификация самих процессов разработки СЗИ по приказу ФСТЭК №240: вендор подтверждает, что его процессы соответствуют ГОСТ Р 56939, а не проверяет каждую версию продукта отдельно. Вторая — сертификация СЗИ по уровням доверия (приказ №76): на всех открытых уровнях 4–6 требуется документация по безопасной разработке средства, и чем выше уровень доверия (ближе к 1-му), тем строже требования к процессам, включая исследования на предмет уязвимостей и недекларированных возможностей.

Q: Какие российские инструменты для безопасной разработки есть?

Для процессов РБПО на рынке РФ есть подтверждённые в реестре российского ПО инструменты по основным классам: Solar appScreener (SAST+DAST+SCA в одном решении, ГК «Солар»), PT Application Inspector (SAST+DAST+IAST+SCA, Positive Technologies), Svace (SAST, ИСП РАН, используется Kaspersky и Postgres Professional), CodeScoring (SCA и построение SBOM, Profiscope) и AppSec.Hub (класс ASPM — управление практиками DevSecOps, AppSec Solutions/Swordfish Security). Выбор инструмента зависит от того, какие процессы раздела 5 ГОСТ нужно закрыть в первую очередь.

Проверено экспертной редакцией SecRadar · по первоисточникам ФСТЭК / ФСБ / Банка России

РБПО — это разработка безопасного программного обеспечения: набор процессов, встроенных в саму разработку, чтобы уязвимости не появлялись, а не искались потом. РБПО (разработка безопасного программного обеспечения) — комплекс процессов, которые снижают число уязвимостей и недекларированных возможностей в ПО на всех этапах его жизненного цикла, от формирования требований до поддержки уже выпущенного продукта.

В России эти процессы описывает ГОСТ Р 56939 — с 20 декабря 2024 года действует новая редакция стандарта, а прежняя, 2016 года, отменена. Разбираем, что именно требует актуальная версия ГОСТа, когда соответствие ему обязательно, а не просто желательно, и какими российскими инструментами эти требования закрывают на практике.

Экспертная редакция SecRadar · как мы проверяем факты → Обновлено 9 июля 2026 · ~14 мин чтения ✓ сверено с ГОСТ Р 56939-2024 и приказами ФСТЭК №76, №240 (по независимым зеркалам официальных текстов)

Кратко

Что действует: ГОСТ Р 56939-2024 — с 20.12.2024, приказ Росстандарта № 1504-ст от 24.10.2024. Редакция 2016 года отменена, в базе ГАРАНТ прямо помечена «документ не действует».
Что такое РБПО: 25 процессов безопасной разработки (раздел 5 ГОСТа, п. 5.1–5.25) — от моделирования угроз и SAST/DAST до вывода ПО из эксплуатации.
Обязательность: Сам стандарт добровольный, но обязателен «по ссылке» — при сертификации процессов РБПО (приказ ФСТЭК №240) и при сертификации СЗИ по уровням доверия (приказ №76).
Для кого критично: Разработчики СЗИ, претендующие на сертификат ФСТЭК; разработчики ПО для значимых объектов КИИ и ГИС.
Что нового в 2026: Методика ФСТЭК от 12.05.2026 синхронизирована с ГОСТ-2024 и требует SBOM в формате CycloneDX.
Наши цифры: 778 действующих сертификатов СЗИ в реестре ФСТЭК и 1 431 записи класса «СЗИ» в реестре российского ПО — потенциальный круг, для которого сертификация процессов РБПО актуальна.

Что такое РБПО

РБПО — встроенная в цикл разработки дисциплина, а не разовая проверка перед релизом. Требования безопасности формируются ещё до того, как написана первая строка кода, а завершается работа только реагированием на уязвимости, найденные уже в промышленной эксплуатации. Цель не в том, чтобы поймать баг перед сдачей продукта, а в том, чтобы системно снижать вероятность появления уязвимости или недекларированной возможности, которую потом придётся закрывать патчем.

На практике РБПО пригождается разработчику в трёх разных ситуациях:

Сертификация СЗИ

Для сертификата ФСТЭК по уровням доверия и для отдельной сертификации процессов безопасной разработки нужно подтверждённое соответствие ГОСТ Р 56939.

Реестр российского ПО

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

Доверие заказчика

Для КИИ, ГИС и других регулируемых заказчиков задокументированный процесс РБПО — практический аргумент в пользу продукта наравне с сертификатом.

ГОСТ Р 56939: редакция 2024 года вместо 2016

Полное название стандарта дословно одинаково в обеих редакциях — «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Но с 20 декабря 2024 года действует новая редакция — ГОСТ Р 56939-2024, утверждённая приказом Росстандарта от 24.10.2024 № 1504-ст. Прежняя редакция, ГОСТ Р 56939-2016 (приказ от 01.06.2016 № 458-ст), отменена и в базе ГАРАНТ помечена «документ не действует» факт.

Большинство статей в рунете о ГОСТ Р 56939 написаны до конца 2024 года и описывают отменённую редакцию 2016 года как действующую. Если материал не упоминает редакцию 2024 года и приказ Росстандарта № 1504-ст — он устарел. Ключевая смена парадигмы: версия 2016 года описывала набор организационно-технических мер, версия 2024 года описывает сквозные процессы — это позволяет сертифицировать процесс разработки целиком, а не каждую версию продукта отдельно.

ГОСТ Р 56939-2016 отменён

Набор организационно-технических мер безопасной разработки, применяемых к конкретной версии продукта. Утв. приказом от 01.06.2016 № 458-ст. С 20.12.2024 не действует.

ГОСТ Р 56939-2024 действует

25 сквозных процессов (раздел 5, п. 5.1–5.25), охватывающих весь жизненный цикл — включая поддержку, реагирование на уязвимости после релиза и вывод ПО из эксплуатации. Утв. приказом Росстандарта от 24.10.2024 № 1504-ст, введён с 20.12.2024. Разработан техническим комитетом ТК 362 с участием ФСТЭК, «Лаборатории Касперского», «Астра», «Базальт СПО» и других — с декабря 2022 г. внесено 558 замечаний, 310 из них приняты полностью или частично.

Обязателен ли ГОСТ Р 56939 сам по себе? Формально нет — как и любой национальный стандарт, он добровольный по общей логике ФЗ «О стандартизации в РФ». Но на практике действует двухслойная логика: соответствие ГОСТ Р 56939-2024 становится обязательным там, где на него ссылается конкретная схема сертификации.

При сертификации процессов безопасной разработки СЗИ по приказу ФСТЭК России от 01.12.2023 № 240 — порядок сертификации прямо ссылается на действующую редакцию ГОСТ Р 56939; приказом ФСТЭК от 30.06.2025 № 230 ссылка обновлена с редакции 2016 года на редакцию 2024 года факт.
Содержательно — при сертификации СЗИ по уровням доверия (приказ ФСТЭК № 76 от 02.06.2020): на всех открытых уровнях доверия требуется документация по безопасной разработке средства, логически соответствующая ГОСТ Р 56939, хотя прямая ссылка на номер стандарта в доступной публичной выписке приказа №76 не встречается оценка.
Для остальных разработчиков — тех, кто не претендует на сертификацию ФСТЭК и не пишет ПО для ГИС/КИИ — стандарт остаётся добровольным методическим ориентиром.

Не путать с приказом ФСТЭК № 21. Приказ №21 регулирует меры защиты персональных данных при эксплуатации информационных систем (152-ФЗ) — это другая область регулирования, к разработке ПО он отношения не имеет.

Что требует ГОСТ: 25 процессов РБПО

Раздел 5 ГОСТ Р 56939-2024 описывает 25 процессов (п. 5.1–5.25) — от планирования до вывода продукта из эксплуатации. Ниже — их распределение по укрупнённым этапам жизненного цикла разработки; в скобках указан номер пункта раздела 5. Процессы, для которых на рынке есть отдельный класс инструментов (моделирование угроз, SAST, DAST/фаззинг, экспертиза кода, SCA, реагирование на уязвимости), выделены жирным.

↔ таблицу можно прокрутить вбок

Этап ЖЦ	Процессы РБПО (раздел 5 ГОСТ Р 56939-2024)
Планирование и требования	5.1 Планирование процессов разработки безопасного ПО · 5.2 Обучение сотрудников · 5.3 Формирование требований безопасности
Архитектура и проектирование	5.6 Разработка архитектуры ПО · 5.7 Моделирование угроз и анализ поверхности атаки · 5.8 Формирование правил кодирования
Кодирование	5.4 Управление конфигурацией ПО · 5.9 Экспертиза исходного кода · 5.14 Управление доступом и контроль целостности кода · 5.15 Безопасность секретов (ключи, пароли)
Сборка и тестирование	5.10 Статический анализ (SAST) · 5.11 Динамический анализ и фаззинг-тестирование (DAST) · 5.12 Безопасная система сборки · 5.13 Безопасность сборочной среды · 5.16 Композиционный анализ компонентов (SCA) · 5.17 Проверка на вредоносный код в цепочках поставок · 5.18 Функциональное тестирование · 5.19 Нефункциональное тестирование
Выпуск и поставка	5.20 Безопасность при выпуске версии · 5.21 Безопасная поставка пользователям
Эксплуатация и поддержка	5.5 Управление недостатками и запросами на изменение · 5.22 Техническая поддержка при эксплуатации · 5.23 Реагирование на информацию об уязвимостях · 5.24 Поиск уязвимостей при эксплуатации · 5.25 Обеспечение безопасности при выводе ПО из эксплуатации

факт смена парадигмы «меры → процессы» и число 25 позиций в разделе 5 (п. 5.1–5.25) — сверено по официальному тексту ГОСТ Р 56939-2024 оценка формулировки пунктов сведены по независимым зеркалам текста, для дословных цитат сверяйте с protect.gost.ru

Проверьте перед использованием. Прямой доступ к protect.gost.ru на момент подготовки материала был технически недоступен — таблица выше собрана по независимым зеркалам официального текста стандарта (реквизиты и оглавление раздела 5 сверены и совпадают: 25 пунктов, 5.1–5.25), но для дословных формулировок конкретного пункта перед использованием в проекте сверяйте с оригиналом на protect.gost.ru.

Процессы 5.23–5.25 (реагирование на уязвимости, их поиск при эксплуатации и вывод ПО из эксплуатации) на практике продолжаются уже после релиза — этим занимается класс VM (управление уязвимостями). А если продукт предоставляет доступ через API, то отдельный контур защиты самих API-интерфейсов в проде закрывает класс API Security — оба класса дополняют SAST/DAST/SCA из таблицы выше, но работают уже на эксплуатируемой системе, а не на этапе сборки.

Для кого обязательно и важно

Прямой обязанности «выполнять ГОСТ Р 56939» нет ни у одной категории разработчиков — обязательность возникает только через конкретную схему сертификации или конкретного заказчика. Ниже — кому эта связка касается на практике.

Критично

Разработчики СЗИ, претендующие на сертификат ФСТЭК с уровнем доверия и/или на отдельную сертификацию процессов РБПО по приказу №240 — без соответствия ГОСТ Р 56939-2024 сертификат не получить.

Важно

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

Методически полезно

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

По данным SecRadar (Госреестр сертифицированных СЗИ ФСТЭК, срез на 25.08.2026) в реестре — 755 действующих сертификатов СЗИ из 1 648 за всю историю реестра факт. Это ориентировочный верхний предел числа продуктов, для которых сертификация процессов РБПО по приказу №240 актуальна уже сейчас или станет актуальной при продлении сертификата.

В Реестре российского ПО класс «СЗИ» на 25.08.2026 — 1 431 записи факт: более широкий круг разработчиков средств защиты, для которых РБПО релевантно как минимум методически, даже без пройденной сертификации ФСТЭК. Источники: reestr.fstec.ru/reg3, reestr.digital.gov.ru/reestr.

Отдельная и пока не подтверждённая напрямую связь — реформа реестра доверенного ПО. Постановление Правительства РФ от 28.11.2025 № 1937 вводит в правила реестра российского ПО новую категорию «доверенное ПО» с поэтапными требованиями к информационной безопасности разных категорий продуктов: с 01.09.2026 — офисное ПО, с 01.01.2027 — средства виртуализации, СУБД и разработки, с 01.06.2027 — прикладное ПО и средства защиты информации.

Прямая ссылка на ГОСТ Р 56939 в тексте постановления в открытых пересказах не встретилась — вероятная, но не подтверждённая связь оценка. Разработчикам, которые уже планируют включение продукта в реестр российского ПО, стоит заранее проверить, какие требования к ПО для включения в реестр актуальны для их категории.

Связь с уровнями доверия ФСТЭК

Приказ ФСТЭК России от 02.06.2020 № 76 устанавливает 6 уровней доверия к средствам технической защиты информации — от 6-го (низший) до 1-го (высший, для систем с гостайной). Выполнение этих требований обязательно при любой сертификации СЗИ, которую организует ФСТЭК России факт. Информация об уровнях 1–3 закрыта, открыты уровни 4–6.

↔ таблицу можно прокрутить вбок

Уровень	Типовой объект защиты	Требование к документации по безопасной разработке
6 (базовый)	значимые объекты КИИ 3-й категории, ИСПДн 3–4 уровней защищённости	документация по безопасной разработке средства: физические, процедурные, организационные и иные меры
5	значимые объекты КИИ 2-й категории, ГИС 2 класса, ИСПДн 2 уровня	требования совпадают с уровнем 6
4	значимые объекты КИИ 1-й категории, ГИС 1 класса, ИСПДн 1 уровня	дополнительно — документация по безопасной разработке аппаратной платформы средства
1–3	системы с гостайной, наивысшие требования	детали закрыты, не публикуются

факт 6 уровней доверия, обязательность требований для сертификации ФСТЭК оценка соответствие уровней объектам защиты — по открытому пересказу приказа №76, для дословных формулировок сверить с оригиналом

Прямая ссылка на номер ГОСТ Р 56939 в доступной публичной выписке приказа №76 не встречается — связь реализована не текстом самого приказа, а через отдельный порядок сертификации процессов РБПО (приказ №240): чтобы подтвердить документацию по безопасной разработке на любом из открытых уровней доверия, разработчику практически необходимо выстроить процессы, соответствующие ГОСТ Р 56939-2024.

Что нового в 2026 году: SBOM и методика ФСТЭК

12 мая 2026 года ФСТЭК России утвердила методический документ «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении» — впервые в открытом доступе, тогда как предыдущая методика от 25.12.2020 имела гриф «для служебного пользования» факт. Документ прямо синхронизирован с ГОСТ Р 56939-2024 и приказом ФСТЭК №76: все виды исследований привязаны к 6 уровням доверия.

Практически значимое требование методики — предоставлять перечни компонентов ПО (SBOM) в машиночитаемом формате CycloneDX, с указанием хеш-сумм, репозиториев и специальных атрибутов (в том числе кастомных полей GOST:attack_surface, GOST:security_function, GOST:provided_by). Это самое свежее подтверждение того, что регулятор реально требует SBOM-артефакты именно в увязке с ГОСТ Р 56939-2024, а не только в виде общей рекомендации — и прямо поднимает ценность инструментов класса SCA (композиционный анализ), которые такие перечни строят автоматически.

Российские инструменты РБПО

Для закрытия конкретных процессов раздела 5 — прежде всего SAST, DAST, SCA и ASPM — на рынке РФ есть решения, подтверждённые в реестре российского ПО. Единого каталога классов SAST/DAST на SecRadar пока нет — раздел готовится, а до его запуска ориентир — таблица ниже и общий каталог классов СЗИ.

↔ таблицу можно прокрутить вбок

Инструмент	Класс	Вендор	Соответствие ГОСТ Р 56939
Solar appScreener	SAST + DAST + SCA (OSA) в одном решении	ГК «Солар»	сертификат ФСТЭК России №4825 (УД4), вендор заявляет поддержку редакций ГОСТ 2016 и 2024
PT Application Inspector	SAST + DAST + IAST + SCA	Positive Technologies	сертификат ФСТЭК, комбинированный анализ
Svace	SAST — статический анализ, более 70 классов дефектов	ИСП РАН	базовый инструмент для безопасного ЖЦ разработки; используется Kaspersky, Postgres Professional и другими (более 200 организаций)
CodeScoring	SCA — композиционный анализ open source-компонентов, построение SBOM	Profiscope	первое российское решение класса SCA в реестре
AppSec.Hub	ASPM — управление практиками AppSec/DevSecOps	AppSec Solutions / Swordfish Security	заявлена интеграция с большинством рыночных средств анализа безопасности

факт все пять инструментов — в реестре российского ПО, подтверждены вендорскими и отраслевыми источниками оценка точные номера реестровых записей — проверять на дату использования, реестр обновляется

Помимо перечисленных, отдельные отраслевые обзоры называют российскими DAST-решениями PT BlackBox, SolidPoint DAST и AppSec.Sting — эта оценка приведена по одному обзору Anti-Malware и не перепроверена по второму источнику оценка. Практический выбор инструмента зависит от того, какие именно процессы раздела 5 нужно закрыть первыми: для старта обычно достаточно SAST и SCA (покрывают экспертизу кода и анализ компонентов), DAST и ASPM подключают по мере роста зрелости процессов.

Частые вопросы

Что такое РБПО?

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

Что требует ГОСТ Р 56939?

Действующая редакция 2024 года описывает 25 процессов в разделе 5 (п. 5.1–5.25) — от планирования и обучения сотрудников до моделирования угроз, экспертизы кода, статического анализа (SAST), динамического анализа и фаззинга (DAST), композиционного анализа компонентов (SCA), безопасной сборки, реагирования на уязвимости после выпуска и вывода ПО из эксплуатации. В отличие от отменённой редакции 2016 года, которая описывала набор мер, версия 2024 года требует выстроить сквозные процессы на весь жизненный цикл продукта. Метка: факт — число и оглавление раздела 5 сверены по официальному тексту ГОСТ Р 56939-2024; формулировки отдельных пунктов сведены по независимым зеркалам, для дословных цитат сверяйте с protect.gost.ru.

Обязателен ли ГОСТ Р 56939?

Сам по себе — нет, национальный стандарт добровольный. Но он становится обязательным «по ссылке» из двух схем ФСТЭК: при сертификации процессов безопасной разработки СЗИ (приказ №240 от 01.12.2023, с 30.06.2025 ссылается уже на редакцию 2024 года) и содержательно — при сертификации СЗИ по уровням доверия (приказ №76 от 02.06.2020), где на всех открытых уровнях нужна документация по безопасной разработке. Для разработчиков вне этих схем сертификации ГОСТ остаётся добровольным ориентиром. Метка: факт по цепочке норм — приказ №240 и приказ №230; логика «доброволен сам по себе, обязателен по ссылке» — оценка на основе общей нормы ФЗ «О стандартизации».

Чем РБПО связан с сертификацией ФСТЭК?

Двумя независимыми линиями. Первая — сертификация самих процессов разработки СЗИ по приказу №240: подтверждается процесс в целом, а не отдельная версия продукта. Вторая — сертификация СЗИ по уровням доверия (приказ №76): на уровнях 4–6 требуется документация по безопасной разработке средства, а на уровне 4 — дополнительно по аппаратной платформе. Прямой текстовой ссылки на номер ГОСТ Р 56939 внутри приказа №76 в открытой выписке нет — связь идёт содержательно, через приказ №240. Метка: факт по приказу №240; связь с приказом №76 — оценка по открытой выписке документа.

Какие российские инструменты для безопасной разработки есть?

Подтверждённые в реестре российского ПО: Solar appScreener (SAST+DAST+SCA, ГК «Солар»), PT Application Inspector (SAST+DAST+IAST+SCA, Positive Technologies), Svace (SAST, ИСП РАН), CodeScoring (SCA и построение SBOM, Profiscope), AppSec.Hub (ASPM, AppSec Solutions/Swordfish Security). Отдельные обзоры также называют DAST-решениями PT BlackBox, SolidPoint DAST и AppSec.Sting — это оценка по одному источнику. Метка: факт — пять основных инструментов подтверждены записью в реестре; DAST-тройка — оценка по одному отраслевому обзору.

Хаб «Комплаенс» на SecRadar

Реестр российского ПО, требования к включению, категорирование КИИ и другая регуляторика ИБ — независимый разбор без привязки к вендору.

Открыть хаб «Комплаенс» →