Аббревиатура РБПО за последние два года переехала из документов вендоров средств защиты в требования, которые предъявляют обычным операторам информационных систем. Разработка безопасного программного обеспечения перестала быть темой тех, кто продаёт средства защиты. Теперь её спрашивают у всех, кто пишет код внутри организации.
20 декабря 2024 года вступил в силу ГОСТ Р 56939-2024. Он заменил редакцию 2016 года и сместил акцент: теперь стандарт требует не просто реагировать на найденные пользователями ошибки, а выстроить процесс устранения недостатков целиком.
Разберём по первоисточникам: что стандарт требует, что изменилось в новой редакции, кому РБПО обязательно и как процесс доказывают при сертификации.
Что такое РБПО простыми словами
РБПО расшифровывается как разработка безопасного программного обеспечения. За аббревиатурой стоит простая мысль: безопасность продукта определяется тем, как его делали. Находки в готовом бинарнике показывают лишь часть картины.
Классическая проверка выглядела так: готовый продукт отдают на испытания, где ищут уязвимости и недекларированные возможности. При обнаружении дефекты исправляют, при отсутствии находок выдают сертификат.
Такой подход проверяет один снимок во времени, и о том, что будет с продуктом после следующего релиза, он не говорит ничего. Через месяц выйдет обновление. О его безопасности проведённые испытания не говорят ровным счётом ничего, потому что проверяли они совсем другую версию продукта. РБПО меняет предмет проверки. Смотрят на процесс. Как принимаются решения по уязвимостям, кто отвечает за состав используемых компонентов, чем именно проверяется код перед тем, как попасть в сборку релиза.
Для организации это означает переход от разовых мероприятий, которые проводятся под конкретную проверку и забываются сразу после неё, к постоянной деятельности с закреплёнными ролями, письменными регламентами и следами, накапливающимися месяцами. Следы важны отдельно. Процесс, который не оставил документов, при проверке неотличим от отсутствующего, даже если фактически работал годами.
ГОСТ Р 56939: что требует стандарт
Действующая редакция называется ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Внесён техническим комитетом по стандартизации ТК 362 «Защита информации». Утверждён и введён в действие приказом Росстандарта от 24 октября 2024 года № 1504-ст. Дата введения: 20 декабря 2024 года.
Область применения в редакции 2024 года сформулирована так:
Настоящий стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного программного обеспечения (ПО) и устранением выявленных недостатков, в том числе уязвимостей, ПО.
Адресат назван прямо: разработчики и производители ПО, а также организации, выполняющие оценку соответствия процессов разработки положениям стандарта.
Что изменилось по сравнению с редакцией 2016 года
Предыдущая редакция, ГОСТ Р 56939-2016, действовала с 1 июня 2017 года по 20 декабря 2024 года. Сравнение областей применения показывает три содержательных сдвига.
Первый: устранение недостатков отвязали от пользователя. Редакция 2016 года говорила о «формировании (поддержании) среды обеспечения оперативного устранения выявленных пользователями ошибок программного обеспечения и уязвимостей программы». В 2024 году эта привязка убрана. Устранять нужно выявленные недостатки, независимо от того, кто их нашёл: внутренний анализ, исследователь или пользователь.
Второй: предмет расширен с уязвимостей до недостатков. Новая формулировка говорит о «недостатках, в том числе уязвимостях». Уязвимость стала частным случаем. Под требование попадают дефекты, которые сегодня не эксплуатируются, но создают условия для будущих проблем.
Третий: стандарт стал головным в семействе. Редакция 2024 года прямо предусматривает применение «в комплексе с другими национальными стандартами по разработке безопасного ПО, в которых раскрываются вопросы внедрения и оценки соответствия положениям настоящего стандарта, задаются требования к отдельным технологиям, применяемым в процессах разработки».
Практический смысл третьего пункта недооценивают чаще остальных. Он означает, что одним ГОСТ Р 56939 внедрение не закрывается: организации, рассчитывающей закрыть тему единственным документом, придётся расширять список стандартов уже на этапе подготовки к оценке соответствия. Стандарт задаёт рамку, детали живут в сопутствующих документах по конкретным технологиям и по порядку оценки соответствия.
Как читать требования стандарта
У организаций, впервые открывших ГОСТ Р 56939, обычно возникает одинаковый вопрос: требования сформулированы на уровне «должны выполняться работы», без указания конкретных инструментов и метрик. Это сделано намеренно.
Стандарт задаёт, что должно происходить в процессе разработки, и оставляет организации выбор, чем это делать. Один и тот же анализ кода закрывается коммерческим анализатором, свободным инструментом или сочетанием нескольких. Проверяющего интересует наличие самой деятельности и её результативность, а название конкретного продукта роли не играет.
Отсюда следствие для внедрения. Начинать с покупки инструмента неправильно по порядку. Сначала описывается процесс и точки контроля, потом под них подбирается инструментарий. Обратный порядок даёт дорогой анализатор, чьи отчёты никто не разбирает.
Кому РБПО обязательно
Прямая обязанность возникает у трёх групп организаций, и границы между этими группами за последние два года заметно размылись.
Разработчики средств защиты информации. Для них РБПО стало условием сертификации во ФСТЭК России. Требование к процессу разработки стало частью системы сертификации, и подтверждать его нужно не результатом испытаний, а свидетельствами процесса.
Производители ПО, претендующие на реестр отечественного программного обеспечения. Здесь требование к безопасной разработке появляется как одно из условий включения в реестр и последующего подтверждения статуса продукта.
Организации с собственной разработкой, проходящие оценку зрелости. Эта группа оказалась самой многочисленной, и именно о ней чаще всего забывают при планировании работ по защите информации.
Связь с методикой оценки зрелости ФСТЭК
Методический документ ФСТЭК от 7 августа 2026 года ввёл оценку уровня зрелости деятельности по защите информации. Оценка идёт по 21 направлению, и направление 13 называется «Разработка безопасного программного обеспечения».
Из этого следует вещь, которую стоит проговорить отдельно. Организация может не продавать ПО, не претендовать на реестр и не сертифицировать средства защиты. Но если она разрабатывает что-то для себя, при оценке зрелости направление 13 придётся закрывать наравне с остальными двадцатью. Нулевая оценка по одному направлению тянет вниз общий показатель зрелости, рассчитываемый как среднее по всем двадцати одному.
Проверить, как направление выглядит на вашей организации, можно в самооценке зрелости ИБ по методике ФСТЭК: расчёт идёт по всем 21 направлению, включая разработку.
Что означает «разработка» для оценки зрелости
Организации часто отвечают, что разработки у них нет, а потом выясняется обратное. Под направление 13 попадает больше случаев, чем кажется:
- собственные веб-сервисы и личные кабинеты, написанные внутри или подрядчиком;
- доработки типовых систем — конфигурации 1С, модули CMS, интеграционные обработчики;
- скрипты автоматизации, которые обрабатывают чувствительные данные;
- мобильные приложения под собственным брендом.
Признак принадлежности к этой группе довольно простой. Код пишется под вашу задачу, вы отвечаете за его работу, значит направление 13 применимо. Покупка коробочного продукта сюда не относится: там за безопасную разработку отвечает производитель, а ваша зона начинается с эксплуатации и обновлений.
Отдельный случай представляет разработка на аутсорсе. Код пишет подрядчик, но продукт ваш. Требования к безопасной разработке при этом закрепляются в договоре, а зрелость самого подрядчика с 1 марта 2027 года становится предметом отдельной оценки: по пункту 32 приказа ФСТЭК № 117 в редакции приказа № 137 от 8 мая 2026 года расчёт показателя уровня зрелости проводится подрядной организацией до получения доступа к информационным системам заказчика.
Процессы РБПО: что внедрять на практике
Стандарт описывает требования к содержанию и порядку работ. На уровне практики это разворачивается в несколько групп деятельности. Точный перечень и формулировки требований смотрите в тексте стандарта. Ниже практическая карта того, что придётся построить.
Моделирование угроз для продукта. Не то же самое, что модель угроз информационной системы. Предмет здесь сам разрабатываемый продукт. Разбирают доверенные границы, состав обрабатываемых данных и последствия компрометации каждого компонента в отдельности.
Анализ кода. Статический анализ ищет дефекты в исходниках до сборки. Динамический проверяет работающее приложение. Ни один не заменяет другой. Статический видит то, что не выполняется в тестах. Динамический ловит проявляющееся только в рантайме.
Управление сторонними компонентами. Современный продукт на 80–90 процентов состоит из чужого кода. Нужен перечень компонентов, отслеживание их уязвимостей и правило, по которому принимается решение об обновлении. Здесь РБПО смыкается с управлением уязвимостями. Компонент с известной уязвимостью внутри вашего продукта становится вашей уязвимостью.
Контроль сборки и поставки. Кто может собрать релиз, откуда берутся зависимости, чем подписывается артефакт. Атаки на цепочку поставки бьют именно сюда.
Реагирование на сообщения об уязвимостях. Канал приёма, сроки разбора, порядок выпуска исправлений. Редакция 2024 года требует устранения выявленных недостатков без оговорки о том, кто их выявил. Значит канал нужен и для внешних сообщений.
Обучение разработчиков. Процесс держится на людях, которые пишут код. Без понимания, зачем нужны проверки, они превращаются в формальность.
Методика выявления уязвимостей и НДВ
Отдельный документ, который путают с приказами ФСТЭК: информационное сообщение ФСТЭК России от 10 февраля 2021 года № 240/24/647 об утверждении Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении.
Методика описывает порядок поиска уязвимостей и НДВ при испытаниях. Для разработчика она полезна как карта того, что будут искать: зная методику проверяющего, проще выстроить внутренний контроль так, чтобы находки случались до подачи документов.
⚠️ Распространённая ошибка: эту методику приписывают приказу ФСТЭК № 9 от 20 января 2026 года. Приказ № 9 называется «О внесении изменений в Положение о системе сертификации средств защиты информации, утверждённое приказом Федеральной службы по техническому и экспортному контролю от 3 апреля 2018 г.» и относится к устройству системы сертификации. Это разные документы с разным предметом.
Сертификация: как доказать процесс
Проверка процесса устроена принципиально иначе, чем привычные испытания готового продукта. Продукт можно подготовить к испытаниям за месяц. Процесс за месяц не готовится.
Проверяющий смотрит свидетельства. Отчёты анализа кода за прошлые релизы, история решений по найденным уязвимостям, записи об обучении, журналы сборок за период, который его интересует. Все эти артефакты имеют дату. Процесс, запущенный за две недели до подачи документов, виден по датам сразу.
Отсюда следует практический вывод для планирования сроков. Внедрять РБПО нужно за год до того, как понадобится сертификат. Не потому что внедрение долгое, а потому что доказательства копятся временем.
Второе соображение касается непрерывности процесса во времени. Сертификат выдаётся на срок. Процесс проверяется повторно. Есть организации, у которых РБПО оживает к каждой проверке и засыпает после неё. Разрыв в свидетельствах виден проверяющему так же хорошо, как полное их отсутствие, и объяснять его придётся отдельно.
С чего начинается внедрение
Порядок действий, который работает у организаций с небольшой командой разработки.
Шаг 1. Инвентаризация того, что пишется. Список продуктов, сервисов и доработок с указанием, кто их делает и какие данные они обрабатывают. Без этого списка невозможно оценить объём работ, а он обычно оказывается больше ожидаемого.
Шаг 2. Перечень сторонних компонентов. Для каждого продукта выписываются используемые библиотеки и их версии. Задача решается специальными инструментами анализа состава программного обеспечения, но на первом этапе достаточно ручной выгрузки из менеджера зависимостей и сверки полученного списка с базами известных уязвимостей. Дальше этот перечень сверяется с БДУ ФСТЭК и другими базами уязвимостей.
Шаг 3. Точки контроля в существующем процессе. Где сейчас код проходит проверку: ревью, тесты, ручное тестирование перед релизом. Такие точки есть почти всегда, и задача сводится к тому, чтобы описать их и дополнить недостающими проверками. Строить контроль с нуля обычно не требуется.
Шаг 4. Регламент. Документ, который связывает предыдущие три шага: кто отвечает, что проверяется, в какие сроки, как принимается решение по найденному. Регламент пишется под сложившуюся практику команды, иначе он останется документом, который никто не исполняет после утверждения.
Шаг 5. Свидетельства. Определить, что и где сохраняется. Отчёты анализаторов, записи ревью, решения по уязвимостям. Артефакты складываются в одно место с сохранением дат, и именно они станут доказательной базой при любой из проверок.
Первые три шага занимают несколько недель и не требуют бюджета вообще. Именно они дают понимание масштаба, после которого разговор об инструментах становится предметным.
РБПО и управление уязвимостями: где стык
Две темы пересекаются в точке, которую легко упустить. Управление уязвимостями в организации обычно строится вокруг эксплуатируемой инфраструктуры: сканирование хостов, приоритизация находок, устранение в срок. Разрабатываемый продукт в этот контур часто не попадает.
Между тем уязвимость в подключённой библиотеке живёт одновременно в двух мирах, и упустить один из них означает закрыть проблему наполовину. Как компонент инфраструктуры она видна сканеру. Как элемент вашего продукта она уезжает заказчику вместе с релизом.
Практический вывод: перечень компонентов разрабатываемого ПО стоит вести в том же реестре, что и остальные активы, а решения по уязвимостям компонентов принимать по тем же правилам приоритизации. Иначе возникает разрыв. Служба ИБ закрывает уязвимость на своём сервере и не знает, что тот же компонент неделю назад уехал заказчикам в составе релиза.
Типичные ошибки
Процесс живёт только в момент подачи документов. Самая частая. Инструменты закуплены, регламенты написаны, отчёты сформированы за неделю до срока. Через месяц после получения сертификата статический анализатор никто не запускает.
Нет истории решений по уязвимостям. Уязвимость нашли, исправили, забыли. При проверке невозможно показать, как принималось решение: почему эту закрыли за день, а ту отложили на квартал. Обоснование приоритета входит в процесс. Это не бюрократия.
Сторонние компоненты вне периметра. Свой код проверяют, библиотеки берут как есть. При этом основной объём уязвимостей приходит именно из зависимостей.
Моделирование угроз подменяется моделью угроз системы. Документ по методике ФСТЭК для информационной системы написан, а угрозы самого разрабатываемого продукта никто не разбирал. Это разные задачи.
РБПО считают задачей отдела ИБ. Процесс исполняют разработчики. Служба ИБ задаёт требования и проверяет, но код пишет не она. Попытка внедрить РБПО без вовлечения команды разработки заканчивается формальными отчётами.
Стандарты рядом с ГОСТ Р 56939
Редакция 2024 года прямо предусматривает применение в комплексе с другими национальными стандартами. Разобраться, что во что входит, полезно до начала внедрения.
ГОСТ Р 56939 работает как головной документ. Задаёт общие требования к содержанию и порядку работ.
Стандарты по отдельным технологиям раскрывают требования к конкретным практикам: статическому анализу, фаззингу, работе с зависимостями. Их состав меняется, актуальный перечень стоит смотреть в каталоге национальных стандартов.
Документы по оценке соответствия описывают, как проверяется внедрение. Именно на них опирается испытательная лаборатория.
Отдельно стоит развести РБПО и требования к самому продукту. Уровни доверия ФСТЭК характеризуют глубину проверки конкретного средства защиты при сертификации, а РБПО описывает процесс, в котором это средство создавалось. Организация может иметь выстроенный процесс и не иметь при этом ни одного сертифицированного продукта. Обратная ситуация опаснее: сертификат, полученный без работающего процесса, создаст проблемы уже при первой повторной проверке.
Путают и другую пару: РБПО и управление уязвимостями по методике ФСТЭК. Первое отвечает за то, чтобы уязвимостей в продукте становилось меньше на этапе создания. Второе занимается теми, что уже есть в эксплуатируемой инфраструктуре. Пересекаются они в компонентах. Сторонняя библиотека попадает в оба контура.
Оценка соответствия: как подтверждают внедрение
Стандарт называет отдельным адресатом «организации, выполняющие оценку соответствия процессов разработки ПО положениям настоящего стандарта». То есть проверка внедрения ведётся как самостоятельная деятельность со своими правилами.
На практике организация сталкивается с оценкой в трёх сценариях.
Испытательная лаборатория при сертификации СЗИ. Самый строгий вариант. Проверяются свидетельства процесса за период. Декларации о наличии недостаточно. Готовиться нужно заранее, потому что доказательства имеют даты.
Аудит по требованию заказчика. Крупные заказчики всё чаще включают требования к безопасной разработке в договор и просят подтверждение. Формат проверки здесь свободный, но вопросы задают те же самые: какие проверки выполняются, кто за них отвечает и где хранятся результаты.
Самооценка в рамках оценки зрелости. Организация оценивает направление 13 своими силами по методике ФСТЭК. Здесь нет внешнего проверяющего, но есть требование обоснованности: уровень выставляется не по ощущению, а по наличию документов и записей.
Общее у трёх сценариев одно. Оценивают то, что организация может показать документально. Разрыв между реальной практикой и её документированием чаще всего и роняет оценку у команд, которые технически делают всё правильно.
Что собрать заранее
Минимальный комплект свидетельств, который спрашивают в любом из трёх сценариев:
- регламент или политика безопасной разработки с датой утверждения;
- приказ или иной документ о распределении ролей;
- отчёты средств анализа кода за несколько последних релизов;
- перечень используемых сторонних компонентов с версиями;
- журнал решений по выявленным уязвимостям с обоснованием сроков;
- записи об обучении разработчиков.
Комплект собирается за час, если процесс действительно работал все эти месяцы. Если не работал, за час он не собирается никак. Это ровно то, что проверка должна выявлять.
Кто отвечает за РБПО внутри организации
Процесс исполняют разработчики, но владельца у него часто нет. Отсюда типичная картина: инструменты закуплены службой ИБ, отчёты приходят в никуда, разработка о требованиях узнаёт из письма перед проверкой.
Работающее распределение выглядит так.
Служба ИБ задаёт требования, проверяет их выполнение и отвечает за связь с регулятором. Она определяет, какие проверки обязательны и какие находки блокируют релиз, но не заменяет собой разработку.
Технический лидер разработки отвечает за встраивание проверок в конвейер и за то, чтобы они не превращались в препятствие. Если статический анализ выдаёт сотни ложных срабатываний и его отключают, причина в настройке инструмента.
Владелец продукта принимает решения о приоритете исправлений там, где безопасность конфликтует со сроками. Такие решения фиксируются письменно. Отложенная уязвимость с обоснованием считается нормальной практикой. Отложенная молча образует разрыв в процессе.
Руководство утверждает регламент и выделяет ресурс. Без поддержки на этом уровне процесс держится на энтузиазме отдельных людей и разваливается вместе с их уходом из компании.
Разделение ролей стоит закрепить документально. При оценке зрелости по направлению 13 вопрос «кто отвечает» задаётся одним из первых, и ответ «все понемногу» засчитывается как отсутствие процесса.
Частые заблуждения
«РБПО нужен только вендорам СЗИ». Было верно до появления методики оценки зрелости. Сейчас направление 13 применяется к любой организации с собственной разработкой независимо от того, продаёт она ПО или нет.
«Достаточно купить анализатор кода». Инструмент закрывает одну из групп требований. Моделирование угроз, управление компонентами, контроль сборки и реагирование на сообщения об уязвимостях он не заменяет.
«ГОСТ Р 56939 регулирует безопасность кода». Стандарт про процесс разработки целиком, включая то, что происходит после релиза: устранение выявленных недостатков входит в область применения прямым текстом.
«У нас Agile, регламенты не применимы». Регламент описывает точки контроля. Методологию разработки он не задаёт. Проверка перед мержем одинаково встраивается и в спринт, и в водопад. Методология тут ни при чём.
«Сертификат получен, процесс можно свернуть». Повторная проверка увидит разрыв в свидетельствах. Непрерывность процесса и есть предмет проверки.
Что дальше
Три шага для организации, которая начинает с нуля.
Первый шаг: понять, какая из трёх описанных выше групп обязанности касается именно вашей организации, потому что требования у них разной жёсткости. Сертификация СЗИ, реестр отечественного ПО и оценка зрелости по направлению 13 предъявляют требования разной жёсткости.
Второй: собрать перечень того, что уже делается. Статический анализ, ревью кода, учёт зависимостей. Часть практик обычно уже есть, но не описана как процесс и не оставляет свидетельств.
Третий: закрыть разрыв между тем, что команда фактически делает, и тем, что об этом написано. Регламент без выполнения бесполезен. Выполнение без следов недоказуемо.
Если разработка ведётся внутри организации и предстоит оценка зрелости, начать стоит с самооценки по методике ФСТЭК. Она покажет, как направление 13 выглядит на фоне остальных двадцати и что закрывать первым.
