Многие госорганы и учреждения сами дорабатывают свои информационные системы: пишут модули, интеграции со СМЭВ, отчёты, личные кабинеты. С 1 марта 2026 года у такой работы появились обязательные правила. Приказ ФСТЭК России от 11.04.2025 № 117 требует от оператора, который сам разрабатывает программы для своих систем, вести разработку безопасно — по ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» — и иметь внутренний регламент об этом.
Ниже — кого это касается, что требуют приказ и методический документ ФСТЭКФедеральная служба по техническому и экспортному контролю — Регулятор технической защиты информации (ИСПДн, ГИС, КИИ); ведёт реестр сертифицированных СЗИ., как устроен стандарт, что писать в регламенте и что делать, если программу пишет подрядчик.
Кого это касается
Требования приказа № 117 распространяются на государственные информационные системы, а также на иные информационные системы госорганов, государственных унитарных предприятий и государственных учреждений. Требования к разработке адресованы оператору системы (обладателю информации). Безопасная разработка нужна не всем, а только тем, кто пишет программы сам.
| Ситуация | Что требуется |
|---|---|
| Свои программисты пишут или дорабатывают программы для системы | Меры разделов 4 и 5 ГОСТ Р 56939-2024 и внутренний регламент разработки безопасного ПО (пункт 50 и подпункт «д» пункта 14 Требований) |
| Программу пишет подрядчик по договору | Требования ГОСТ Р 56939-2024 можно включить в техническое задание. Решает руководитель или ответственное лицо (пункт 50 Требований) |
| Покупаете готовую программу или облачный сервис и только меняете параметры | Обычно это не собственная разработка. Работают другие мероприятия: управление уязвимостями, обновлениями и конфигурацией |
Граница проходит по содержанию работ, а не по их названию. Изменение параметров готовой программы и заполнение справочников обычно не разработка. Свой модуль, скрипт выгрузки, интеграция или программная логика, написанная встроенным языком платформы, — разработка, даже если её называют «настройкой».
Что требует приказ № 117
В приказе две нормы о разработке.
- Подпункт «д» пункта 14. Оператор утверждает внутренние регламенты по защите информации. Один из них — порядок разработки безопасного ПО, если оператор разрабатывает его сам.
- Пункт 50. Мероприятия по безопасной разработке должны предотвращать появление уязвимостей, выявлять и устранять их. При собственной разработке реализуются меры разделов 4 и 5 ГОСТ Р 56939-2024. При разработке подрядчиком требования стандарта по решению руководителя можно включить в техническое задание.
Подробности раскрывает методический документ ФСТЭК России «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», утверждённый 12.04.2026. Безопасной разработке в нём посвящён пункт 3.12, мероприятие «БР». Оно перечисляет работы — от планирования и обучения до поиска уязвимостей при эксплуатации — и требования к самому регламенту. Внутренний регламент должен содержать шесть сведений:
- состав ПО, на разработку и эксплуатацию которого распространяются процессы безопасной разработки;
- подразделения или работников, которые организуют и внедряют эти процессы, их функции и полномочия;
- состав и содержание процессов;
- инструменты, которыми процессы выполняются;
- подразделения или работников, которые контролируют процессы, их функции и полномочия;
- порядок взаимодействия работников при разработке.
Это обязательное содержание регламента. Разделы можно построить как удобно, но все шесть сведений должны в нём быть, а описание процессов — соответствовать требованиям ГОСТ.
Там же есть требование к усилению: искать уязвимости в своём ПО через открытые программы с привлечением внешних экспертов и разрабатывать меры по их устранению. Такие программы часто называют bug bounty. Это усиление, а не базовый состав мероприятия.
Если вы субъект КИИ
У значимых объектов критической информационной инфраструктуры своя норма. Пункт 29.3 Требований, утверждённых приказом ФСТЭК России от 25.12.2017 № 239, касается прикладного ПО, которое обеспечивает работу значимого объекта по назначению и внедряется при его создании, модернизации, реконструкции или ремонте. К такому ПО предъявляются три группы требований:
- безопасная разработка — руководство по безопасной разработке и анализ угроз безопасности ПО;
- испытания — статический анализ исходного кода и фаззинг-тестирование;
- поддержка — процедуры исправления ошибок и уязвимостей; способы и сроки, в которые разработчик сообщает пользователям об уязвимостях, компенсирующих мерах и ограничениях; способы получения обновлений и проверки их целостности и подлинности.
Для объектов 1 категории добавляются динамический анализ, описание структуры ПО на уровне подсистем с сопоставлением функций и интерфейсов из функциональной спецификации, а также процедуры уведомления субъекта об окончании производства или поддержки ПО. Выполнение требований оценивает на этапе проектирования тот, кто создаёт объект или обеспечивает его безопасность. Оценка идёт по материалам разработчика, которые он представляет по техническому заданию. Результаты включают в проектную документацию и передают субъекту КИИКритическая информационная инфраструктура — Информационные системы и сети госорганов и организаций ключевых отраслей; режим защиты установлен 187-ФЗ. (пункт 29.4).
Приказ № 239 на ГОСТ Р 56939-2024 прямо не ссылается. Руководство, написанное по стандарту, подходит для требования о наличии руководства. Остальные требования пункта 29.3 выполняют и подтверждают отдельно: отчётами анализа, испытаний и документами о поддержке.
Как устроен ГОСТ Р 56939-2024
Стандарт утверждён приказом Росстандарта от 24.10.2024 № 1504-ст, действует с 20.12.2024 и заменил ГОСТ Р 56939-2016. Его разработали ФСТЭК России, ИСП РАН и крупные разработчики средств защиты. Стандарт адресован разработчикам ПО и организациям, которые оценивают процессы разработки на соответствие (пункт 1).
Национальные стандарты применяются добровольно. Обязательным ГОСТ делает ссылка на него в акте или договоре. Приказ № 117 такую ссылку содержит. А когда документ требует соответствия стандарту, выполняются все его требования со словами «должен» и «следует». Требования со словами «рекомендуется» и «может» остаются на выбор (пункт 4.14).
Ещё три положения раздела 4 важны на практике.
- Регламенты — главный артефакт. Требований к оформлению нет. Регламенты разных процессов можно издать отдельными документами или свести в одно руководство по разработке безопасного ПО (пункт 4.12).
- Нужна среда разработки. Должны быть контроль версий, непрерывная интеграция и система управления задачами с учётом ошибок. Проверки кода встраиваются в эти системы, чтобы шли регулярно и было видно, как устранена каждая ошибка (пункт 4.13).
- Защищаются сами процессы. Сведения о безопасной разработке тоже защищают: разграничивают доступ к результатам исследований и тестирования, хранят их защищённо, применяют антивирусную защиту (пункт 4.17).
Раздел 5 описывает 25 процессов. У каждого три части: цели, требования к реализации и артефакты — то, чем выполнение можно подтвердить. Артефакт не обязательно документ: подходят отчёт инструмента, журнал сборки, запись в трекере.
25 процессов и что показать проверяющему
Удобно разложить процессы на пять участков. В правом столбце — что обычно служит подтверждением.
| Участок | Процессы (пункты ГОСТ) | Чем подтверждается |
|---|---|---|
| Управление | 5.1 планирование процессов; 5.2 обучение сотрудников | Описание области применения, анализ текущего состояния, план внедрения, план обучения и учёт пройденного обучения |
| Требования и проектирование | 5.3 требования безопасности; 5.4 управление конфигурацией; 5.5 управление недостатками и запросами на изменение; 5.6 архитектура; 5.7 моделирование угроз и поверхность атаки | Набор требований безопасности, перечень элементов конфигурации, записи в трекере, описание архитектуры, модель угроз ПО и описание поверхности атаки |
| Код и его проверка | 5.8 правила кодирования; 5.9 экспертиза кода; 5.10 статический анализ; 5.11 динамический анализ кода, включая фаззинг; 5.14 доступ к коду и его целостность; 5.15 секреты; 5.16 композиционный анализ; 5.17 проверка кода на внедрение вредоносного ПО через цепочки поставок | Регламенты процессов, отчёты анализаторов с разметкой срабатываний, перечень зависимостей, модель доступа к репозиториям, результаты антивирусной проверки заимствованного кода |
| Сборка, тестирование, выпуск | 5.12 система сборки; 5.13 сборочная среда; 5.18 функциональное тестирование; 5.19 нефункциональное тестирование; 5.20 выпуск версии; 5.21 поставка пользователям | Описание и схема сборочной среды, журналы сборки, планы и отчёты тестирования, решения о неустранённых ошибках, сведения о версии и месте хранения дистрибутива |
| Эксплуатация | 5.22 поддержка; 5.23 реагирование на сведения об уязвимостях; 5.24 поиск уязвимостей; 5.25 вывод из эксплуатации | Регламенты поддержки и реагирования, журнал сообщений об уязвимостях с оценкой критичности, регулярные отчёты проверок |
Для оператора часть процессов выглядит проще, чем у производителя коробочного ПО. Пользователи — свои работники. Поставка — выкладка на свой сервер. Поддержка — своя служба. Но процессы от этого не исчезают. Их описывают применительно к вашему ПО, а неприменимость отдельного требования обосновывают особенностями программы, а не тем, что так сейчас не делают.
Как написать регламент
Практичный путь — одно руководство по разработке безопасного ПО. Его разделы повторяют шесть сведений из методического документа, а описание процессов идёт по стандарту.
- Определите область. Перечислите программы собственной разработки: название, версии, модули, в какой системе работают. Объясните, почему выбран именно этот состав. Готовые программы сюда не входят.
- Оцените, что уже есть. Пройдите 25 процессов и отметьте по каждому, что выполняется и где пробелы. Если требование неприменимо, обоснуйте это особенностями ПО. Это и есть анализ текущего состояния, которого требует пункт 5.1 стандарта.
- Назначьте роли. Кто внедряет процессы, кто пишет код, кто проводит экспертизу и анализ, кто контролирует. По возможности поручайте контроль не тому, кто пишет код: так проверка будет независимой.
- Назовите инструменты. Система контроля версий, сервер сборки, трекер, анализаторы. Для каждого — версия и для чего применяется.
- Опишите процессы. По каждому процессу — кто делает, когда, каким инструментом, где лежит результат. Пишите то, что делаете, а не то, что хотелось бы.
- Составьте план. Пробелы — в план устранения со сроками и ответственными. Стандарт прямо предусматривает план развития и план реализации процессов. Но план не заменяет обязательные меры: он показывает, как и когда пробел будет закрыт.
- Утвердите и ознакомьте. Руководство утверждает руководитель или ответственное лицо. С ним знакомят разработчиков и тех, кто контролирует.
Проверяющий сверяет документ с практикой. Регламент должен описывать то, что действительно делается, а подтверждают его отчёты, журналы и записи в трекере. Регламент, который требует статический анализ каждого изменения, без отчётов анализатора сам указывает на нарушение.
Если программу пишет подрядчик
Приказ № 117 разрешает включить требования ГОСТ Р 56939-2024 в техническое задание. Это не обязанность, а решение руководителя. Но без таких требований заказчик получает код, о безопасности которого ничего не знает.
Для научно-исследовательских и опытно-конструкторских работ стандарт разрешает предъявлять требования только явным перечнем процессов в техническом задании, в том числе не в полном объёме (пункт 4.15). В обычном договоре разработки тоже можно согласовать конкретные процессы и артефакты, которые подрядчик сдаёт вместе с программой. Только такой перечень — это не то же самое, что требование полного соответствия ГОСТ: если в договоре написано «по ГОСТ Р 56939-2024», выполняются все его обязательные требования (пункт 4.14). Обычно в перечень входят:
- отчёт статического анализа с разметкой срабатываний;
- перечень заимствованных компонентов с версиями и результаты их проверки на известные уязвимости;
- модель угроз ПО и описание поверхности атаки;
- отчёты функционального тестирования и проверки исправлений;
- порядок сообщения об уязвимостях и сроки выпуска исправлений на время гарантии.
Ещё одно правило стоит записать в договор. Методический документ ФСТЭК запрещает подрядчику разрабатывать и тестировать ПО прямо в рабочей системе оператора. Подрядчику дают доступ к отдельным стендам разработки и тестирования и контролируют этот доступ по внутренним регламентам. Порядок переноса готового ПО в рабочую систему тоже закрепляют в регламентах и доводят до работников подрядчика (пункт 3.16).
Инструменты без затрат на лицензии
Требования стандарта не привязаны к конкретным продуктам. Начать можно со свободных инструментов. Достаточность покрытия определяет не список программ, а то, как они встроены в процессы и разбираются ли их результаты.
| Процесс | Свободные инструменты |
|---|---|
| Контроль версий, сборка, трекер | Git, GitLab Community Edition, Gitea, Jenkins |
| Статический анализ (5.10) | Semgrep, SonarQube Community Build, анализаторы конкретного языка: gosec, Bandit, SpotBugs |
| Композиционный анализ (5.16) | Trivy, OWASP Dependency-Check, Syft для перечня компонентов |
| Динамический анализ и фаззинг (5.11) | OWASP ZAP, AFL++, libFuzzer |
| Секреты в коде (5.15) | Gitleaks |
Сам ГОСТ Р 56939-2024 не устанавливает требования о сертификации инструментов анализа. Важно другое: инструмент подходит к языку, описан в регламенте, а его отчёты сохраняются и разбираются.
Найденные уязвимости удобно сверять с банками уязвимостей БДУ ФСТЭК и CVE, а критичность оценивать по методике ФСТЭК России.
Частые ошибки
- Регламент переписан из стандарта. Проверяющему нужно не изложение ГОСТ, а ответ, как это сделано у вас: кто, чем, когда и где результат.
- Не указан состав ПО. Без области применения непонятно, на что распространяется регламент.
- Нет следов работы. Регламент есть, а отчётов анализаторов, журналов сборки и записей в трекере нет.
- Анализаторы запущены, но срабатывания не разобраны. Стандарт требует не только отчёт, но и разметку: какое срабатывание — ошибка, а какое — ложное.
- Готовая программа принята за разработку. Если вы только меняете параметры купленного ПО, нужен порядок управления обновлениями и уязвимостями. Но если встроенным языком платформы пишется программная логика, это уже разработка.
Как ГрамотаИБ помогает с безопасной разработкой
В ГрамотаИБ есть режим «Разработка безопасного ПО». Его включают в профиле организации отметкой «Сами разрабатываем программное обеспечение», и в «Режимах защиты» появляется отдельный раздел. Ниже — что в нём происходит на примере учреждения, которое дорабатывает свой портал записи на услуги.
Мастер ведёт по шагам
Раздел открывается мастером из шести шагов: область применения, самооценка процессов, ответственный, инструменты, приказ о внедрении и приказ о регламентах. Готовность считается по фактам: состав ПО указан, процессы оценены, ответственный назначен, приказ внесён в реестр утверждённых.
Самооценка 25 процессов
По каждому процессу стандарта нужно выбрать состояние: реализован, реализован частично, внедряется или не применяется. Рядом — обоснование и срок внедрения. У каждого процесса видны его цель своими словами, число артефактов и документы, которые их закрывают. Неприменимость требуется обосновать особенностями программы, а не тем, что так пока не делают.
Инструменты попадают в регламенты
Систему контроля версий, конвейер сборки, анализаторы и хранилища называют один раз. Регламенты печатают эти названия в своих положениях. Под каждым полем — свободные инструменты этого вида: стандарт не требует сертифицированных анализаторов. Если инструмент не назван, регламент пишет общее наименование вида, а не оставляет прочерк посреди положения.
Пять папок на все 98 артефактов
Документы разложены по пяти папкам — по участкам жизненного цикла: управление и обучение, требования и проектирование, код и его проверка, сборка и выпуск, эксплуатация и уязвимости. Всего 42 документа: два приказа, руководство, план, программа обучения, пятнадцать регламентов, описания, отчёты и формы учёта. Каждый из 98 артефактов стандарта закрыт одним из них.
Регламенты с пунктом ГОСТ у каждого раздела
Регламент открывается общими положениями и терминами, затем идут разделы по артефактам стандарта. В каждом разделе — номер пункта ГОСТ Р 56939-2024 и положение по каждому обязательному сведению: кто что делает, каким инструментом и что считается результатом. Заканчивается регламент разделами о контроле, ответственности и пересмотре. Регламенты вводятся в действие приказом и печатаются с отметкой о приложении к нему.
План внедрения из самооценки
Процессы, отмеченные как частично реализованные или внедряемые, попадают в план развития и реализации. Очерёдность, срок из самооценки и ответственный подставляются сами. Графы плана — сведения пунктов 5.1.3.3 и 5.1.3.4 стандарта: изменения штатной структуры, закупки инструментов, затраты на обучение, необходимые ресурсы.
Что берёт на себя сервис, а что остаётся организации
- Сервис держит перечень процессов и артефактов стандарта, собирает руководство с шестью сведениями пункта 3.12 методического документа ФСТЭК, подставляет в документы состав ПО, инструменты, ответственного и сроки, ставит задачи в «Что сделать» и напоминает о незакрытых шагах.
- Организация решает, как устроены её процессы, запускает анализаторы, размечает срабатывания, проводит тестирование и хранит машинные отчёты. Формы отчётов и журналов показывают, какие сведения в них должны быть, но анализ кода сервис не выполняет.
Режим входит в тариф «Полный» — вместе с режимами государственных систем и КИИ, для которых он нужен чаще всего.
Частые вопросы
Обязателен ли ГОСТ Р 56939-2024? Сам по себе стандарт добровольный. Но приказ № 117 требует от оператора, который сам разрабатывает ПО для своих систем, реализовать меры разделов 4 и 5 стандарта. Для такого оператора требования стандарта становятся обязательными.
Можно ли сделать один документ вместо 25 регламентов? Да. Пункт 4.12 стандарта разрешает объединить регламенты в одно руководство по разработке безопасного ПО. Требований к оформлению регламентов стандарт не предъявляет.
Нужна ли сертификация процессов разработки? Для выполнения пункта 50 приказа № 117 — нет, сертификат процессов там не предусмотрен. Отдельный порядок сертификации процессов безопасной разработки ПО средств защиты информации установлен приказом ФСТЭК России от 01.12.2023 № 240. Он касается разработчиков средств защиты, а не операторов систем.
У нас один программист. Что делать? Стандарт не требует отдельного подразделения. Опишите, как процессы выполняются при вашем составе, а пробелы внесите в план. Экспертизу кода и контроль по возможности поручите другому работнику или внешнему специалисту: так проверка будет независимой.
Подрядчик отказывается выполнять ГОСТ. Это нарушение? Пункт 50 приказа № 117 сам по себе подрядчика не обязывает: включать ли ГОСТ в техническое задание, решает руководитель оператора. Поэтому требования закладывают при заключении договора. Но проверьте другие нормы: например, для ПО значимого объекта КИИ требования пункта 29.3 приказа № 239 действуют независимо от договора.
Главное
Если ваша организация подпадает под приказ № 117 и сама пишет программы для своих систем, нужен регламент безопасной разработки и меры по ГОСТ Р 56939-2024. Регламент строится по шести сведениям из пункта 3.12 методического документа ФСТЭК: состав ПО, кто внедряет, какие процессы, какие инструменты, кто контролирует, как взаимодействуют. Стандарт задаёт 25 процессов, и их регламенты можно свести в одно руководство. Начните с честной оценки: что делается уже и где пробелы, а пробелы закрывайте по плану. Если программу пишет подрядчик, заложите требования стандарта и перечень сдаваемых артефактов в техническое задание.