Кому нужна безопасная разработка и что именно проверяют

ГОСТ Р 56939-2024

Национальный стандарт «Защита информации. Разработка безопасного программного обеспечения. Общие требования» утверждён приказом Росстандарта от 24 октября 2024 г. № 1504-ст. Раздел 5 описывает 25 процессов безопасной разработки (пункты 5.1–5.25). Что из них закрывает конвейер →

Для конкретной организации стандарт становится обязательным через нормативные акты, которые на него ссылаются. Ниже — три таких случая.

Приказ ФСТЭК России № 117

Госсистемы и иные информационные системы госорганов, ГУП и госучреждений

Требования о защите информации. Действуют с 1 марта 2026 г. вместо приказа № 17; с 1 сентября 2026 г. — с изменениями приказа № 137, которые пункты ниже не затрагивают.

• Если оператор сам разрабатывает ПО для своих систем, он должен реализовать меры разделов 4 и 5 ГОСТ Р 56939-2024 (п. 50).
• Если ПО разрабатывает подрядчик, требования ГОСТ Р 56939-2024 могут быть включены в техническое задание — по решению руководителя оператора (п. 50).
• Подрядчики разрабатывают и тестируют ПО только на изолированных стендах, не в рабочих системах (п. 58).
• При использовании ИИ нельзя передавать разработчику модели информацию ограниченного доступа (п. 60); запросы и ответы ИИ-сервисов должны контролироваться по шаблонам или допустимым тематикам (п. 61).

Что даёт конвейер: меры ГОСТ для собственной разработки оператора и изолированные стенды для подрядчиков. Для ИИ — контроль запросов и ответов.

Положение Банка России № 851-П

Прикладное ПО банков и финансовых организаций

Обязательные требования к защите информации при переводах денежных средств для кредитных организаций и филиалов иностранных банков. Действует с 29 марта 2025 г. На ГОСТ Р 56939-2024 положение не ссылается: требования к ПО сформулированы через сертификацию или оценку по уровню доверия.

• Приложения, которые банк распространяет клиентам для банковских операций, и ПО на участках приёма распоряжений через интернет должны быть сертифицированы в системе сертификации ФСТЭК России или пройти оценку соответствия не ниже ОУД4 по ГОСТ Р ИСО/МЭК 15408-3-2013 (п. 4.1).
• Для остального прикладного ПО банк сам решает, нужна ли сертификация или оценка (п. 4.1).
• Оценку проводит сам банк или организация с лицензией ФСТЭК России на техническую защиту конфиденциальной информации (п. 4.2).
• Если банк выбрал сертификацию: системно значимые банки и значимые на рынке платёжных услуг — не ниже 4 уровня доверия, остальные — не ниже 5 (п. 4.3).
• После изменения исходного кода, который реализует технологию обработки защищаемой информации, оценку соответствия проводят заново (п. 4.4).
• Выполнение требований к прикладному ПО оценивают не реже одного раза в два года (п. 13.4).

Что даёт конвейер: каждое изменение кода проходит одни и те же проверки, отчёты и разметка срабатываний сохраняются. Это материал для повторной оценки после изменений. Саму оценку проводят банк или проверяющая организация.

Сертификация процессов вместо оценки каждой версии

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

• С 1 октября 2026 г. операторы по переводу денежных средств, банковские платёжные агенты, операторы услуг информационного обмена, операторы услуг платёжной инфраструктуры и операторы электронных платформ вправе не проводить сертификацию или оценку соответствия разрабатываемого ими прикладного ПО (кроме ПО, взаимодействующего с СКЗИ), если ФСТЭК России сертифицировала их процессы безопасной разработки на соответствие разделам 4 и 5 ГОСТ Р 56939-2024 (Положение № 821-П, п. 1.2 в ред. Указания № 7220-У).
• С 1 января 2027 г. такое же право получают некредитные финансовые организации усиленного и стандартного уровней защиты (Положение № 757-П, п. 1.8 в ред. Указания № 7219-У).
• Без сертифицированного процесса сертификацию или оценку проводят при каждом изменении исходного кода, который реализует технологию обработки защищаемой информации (те же пункты; для банков — п. 4.4 № 851-П).
• В Положении № 851-П, обязательном для кредитных организаций, такой оговорки нет.

Что даёт конвейер: процессы разделов 4 и 5 ГОСТ Р 56939-2024 в работающем виде — инструменты, регламенты и артефакты, которые проверяют при сертификации процессов. Сертификацию проводит ФСТЭК России; мы готовим к ней.

Некредитные финансовые организации

Положение Банка России № 757-П. Действует с 2021 г.; изменения Указания № 7219-У вступают в силу с 1 января 2027 г.

• Уровень защиты по ГОСТ Р 57580.1-2017 зависит от вида деятельности: усиленный — центральные контрагенты, центральный депозитарий, регистраторы финансовых транзакций; стандартный — в том числе клиринговые организации, организаторы торговли, НПФ по обязательному пенсионному страхованию, страховщики с активами более 20 млрд руб., часть брокеров, дилеров и управляющих; остальные — минимальный (п. 1.4).
• Организации усиленного и стандартного уровней используют для приложений клиентов и ПО приёма распоряжений через интернет только ПО, сертифицированное ФСТЭК России или прошедшее оценку соответствия не ниже ОУД4. Остальные решают сами (п. 1.8).
• Оценку ПО организация проводит сама или с проверяющей организацией; при выборе сертификации — не ниже 4 уровня доверия для усиленного уровня защиты и не ниже 5 для стандартного (п. 1.8).
• Для усиленного и стандартного уровней: ежегодное тестирование на проникновение и анализ уязвимостей; оценка соответствия уровня защиты — с лицензиатом ФСТЭК России, раз в год для усиленного уровня и раз в три года для стандартного (пп. 1.4.5, 1.5).

Профиль защиты Банка России

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

• Уровень доверия — ОУД4, усиленный и расширенный компонентами, в том числе: проверка кода на вредоносное ПО из цепочек поставок, безопасность сборочной среды, контроль целостности кода, статический и динамический анализ, реагирование на уязвимости (п. 2.1).
• Разрешены только сторонние библиотеки и компоненты, которые разработчик проверил, — с композиционным анализом и проверкой на вредоносное ПО (политика безопасности 6, п. 4.2).
• Сборочная среда: регламент и схема, журналы аудита каждой сборки с защитой целостности, отдельное хранилище результатов, доступ по ролям, повторяемость сборки (ALC_DVS_EXT.2).
• Статический анализ — инструменты для каждого языка, все предупреждения регистрируются и размечаются, повторный анализ после изменений (ALC_TAT_EXT.1). Динамический анализ и мутационный фаззинг с обратной связью (ALC_TAT_EXT.2).
• Вместо оценки по требованиям доверия можно оценивать сам процесс безопасной разработки. Условия: ПО не используется на значимых объектах КИИ; процессы задокументированы; инфраструктура соответствует ГОСТ Р 57580.1-2017; в команде есть специалист по безопасности приложений и Security Champion; применяются инструменты статического, динамического и композиционного анализа (пп. 7.4.1, 7.4.2).
• Такую оценку проводит сам разработчик или организация, независимая от тех, кто оказывает ему услуги по внедрению и сопровождению средств и процессов защиты информации (п. 7.4.1).
• Исходный код проверяет не его автор, а другой разработчик или специалист — вручную и (или) средствами статического анализа; результаты оформляются протоколом (ADV_IMP.2.3D).
• Код и конфигурации проверяются на наличие секретов, для секретов используется система управления секретами (п. 7.4.3.2.1).
• Сторонние компоненты проверяются до размещения в репозитории, в том числе антивирусом (табл. 7.4.3.7). Перед переносом в промышленную среду образы контейнеров и виртуальных машин, сценарии развёртывания и управления конфигурацией проверяются на целостность и происхождение (п. 7.4.3.9).
• В тестировании запрещено использовать данные, которые по закону и договорам требуют защиты (замечания к ATE_FUN.1.2C).
• Роли: аналитик ИБ (AppSec) и Security Champion в команде; исполнять и контролировать одно контрольное мероприятие в рамках одной роли нельзя (п. 7.4.3.2.3). Ориентировочный процесс спринта приведён в справочном приложении В.
• Отдельные контрольные мероприятия — экспертиза кода, в первую очередь модулей на поверхности атаки, и тестирование на проникновение развёрнутого ПО перед промышленной эксплуатацией (табл. 7.4.3.7, 7.4.3.9).

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