Ключевые выводы
- Приказ ФСТЭК 117 действует с 1 марта 2026 года. Документ утверждён 11 апреля 2025 года, зарегистрирован Минюстом 16 июня 2025 года под № 82619 и заменяет прежнюю регуляторную рамку для защиты информации в государственных информационных системах.
- Главное изменение — переход от разовой аттестации к управляемому процессу. В приказе закреплены требования к внутренним стандартам, управлению конфигурациями, событиям безопасности, обновлениям, резервному копированию, безопасной разработке и контролю применяемого программного обеспечения.
- Разработка попадает в зону контроля через пункт 50. Если оператор или обладатель информации самостоятельно разрабатывает программное обеспечение для информационных систем, мероприятия должны предотвращать, выявлять и устранять уязвимости, а также учитывать разделы 4 и 5 ГОСТ Р 56939-2024.
- 0% из 669 команд в нашей выборке соответствовали полной модели с первого прохода. Чаще всего отсутствовали формализованные security gates, обязательный SBOM на каждый билд, единый реестр уязвимостей и доказательная база по исправлению дефектов.
- Реалистичный срок перехода — 6-12 месяцев. Команды с готовым CI/CD и базовыми SAST/SCA-инструментами обычно укладываются в 6-8 месяцев; организации с ручными релизами, разрозненными репозиториями и слабым управлением зависимостями выходят на 9-12 месяцев.
- Штрафной риск измеряется не только суммой санкции. По КоАП для нарушений требований защиты информации и КИИ применяются диапазоны до 100 000 ₽ и до 500 000 ₽ для юридических лиц по отдельным составам, но главный ущерб возникает из-за предписаний, остановки ввода системы и повторной аттестации.
Контекст исследования
Приказ ФСТЭК 117 стал одним из самых заметных регуляторных изменений 2026 года для организаций, которые эксплуатируют государственные информационные системы, иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Его практическое значение выходит за рамки классической защиты периметра: документ требует описанного, измеримого и постоянно поддерживаемого процесса защиты информации.
Для команд разработки важен не только сам текст приказа, но и связка с безопасной разработкой программного обеспечения. В пункте 50 требований указано, что при самостоятельной разработке программного обеспечения должны проводиться мероприятия, направленные на предотвращение появления, выявление и устранение уязвимостей. На практике это переводит DevSecOps из рекомендованной инженерной практики в часть доказательной базы соответствия.
Особое внимание требуется организациям, у которых государственные информационные системы, персональные данные, подрядная разработка и элементы критической информационной инфраструктуры пересекаются в одном технологическом контуре. Формально приказ № 117 адресован ГИС и иным информационным системам государственных организаций, но его требования могут влиять на подрядчиков, интеграторов и команды, которые поставляют программное обеспечение для таких систем.
В этой статье приказ ФСТЭК 117 рассматривается через призму безопасной разработки и DevSecOps. Это не юридическое заключение, а исследовательский черновик для CTO, CISO, руководителей разработки, владельцев ГИС и подрядчиков, которым нужно понять практический объём работ.
Методология и источники
Исследование построено на сопоставлении официального текста приказа № 117, открытых разъяснений и практического аудита команд разработки. Мы выделяли не только юридические требования, но и инженерные действия, которые позволяют подтвердить соответствие: наличие внутренних стандартов, журналов, реестров, отчётов сканирования, SBOM, правил приёмки и процедур устранения уязвимостей.
Внутренняя выборка IT Institute включала 669 команд и контуров разработки, связанных с государственным сектором, финансовыми сервисами, подрядной разработкой, промышленными системами и инфраструктурными ИТ-поставщиками. Оценивались процессы, а не названия инструментов: команда могла использовать GitHub, GitLab, Jenkins, TeamCity, отечественные платформы или собственный контур, если могла доказать контроль требований.
Охват исследования
- География: Российская Федерация, с фокусом на организации, работающие с государственными информационными системами, подрядной разработкой для госсектора и регулируемыми ИТ-контурами.
- Сегмент: государственные организации, банки, финтех-команды, поставщики ПО, интеграторы, субъекты КИИ, подрядчики, обслуживающие системы с персональными данными и защищаемой информацией.
- Период: нормативные документы 2017-2026 годов, практические аудиты 2025-2026 годов.
- Исключения: криптографическая защита, гостайна, сертификация конкретных средств защиты информации и полный юридический анализ договорных обязательств подрядчиков.
Основные результаты
Что такое приказ ФСТЭК № 117
Приказ ФСТЭК России от 11.04.2025 № 117 утверждает требования о защите информации, содержащейся в государственных информационных системах и иных информационных системах государственных органов, государственных унитарных предприятий и государственных учреждений. Документ официально опубликован 17.06.2025 и вступил в силу 01.03.2026.
Практически приказ заменяет привычную логику приказа ФСТЭК № 17 от 2013 года. Вместо разового набора мер и последующей аттестации организация должна поддерживать систему защиты как непрерывный управляемый процесс. Это видно по требованиям к внутренним стандартам, учёту конфигураций, событиям безопасности, управлению обновлениями, резервному копированию, контролю доступа и безопасной разработке.
Для разработки критически важен пункт 50: если оператор самостоятельно создаёт программное обеспечение для информационных систем, он должен предотвращать появление уязвимостей, выявлять их и устранять. В инженерной плоскости это означает SAST, DAST, SCA, контроль секретов, анализ контейнеров, управление зависимостями, регистрацию дефектов, правила релиза и подтверждение исправлений.
Кому касается приказ ФСТЭК 117
Прямой адресат приказа — операторы и обладатели информации в государственных информационных системах и иных информационных системах государственных органов, государственных унитарных предприятий и государственных учреждений. Однако фактический круг участников шире, потому что разработка, сопровождение, тестирование и эксплуатация часто передаются подрядчикам.
Если подрядчик разрабатывает модуль, интеграцию, портал, API, мобильное приложение или сервис обработки данных для регулируемого контура, требования безопасной разработки могут быть включены в техническое задание. В этом случае команда разработки должна предоставить не презентацию об инструментах, а проверяемые артефакты: отчёты сканирования, реестр уязвимостей, SBOM, протоколы устранения, историю согласований и правила выпуска.
Для субъектов КИИ приказ № 117 не заменяет 187-ФЗ и профильные требования ФСТЭК по значимым объектам КИИ. Но если объект КИИ связан с ГИС, государственным заказчиком или обработкой защищаемой информации, требования пересекаются. В таких проектах безопасная разработка становится общей зоной ответственности CISO, CTO, владельца продукта, службы эксплуатации и подрядчика.
Чек-лист соответствия: 25 пунктов
Ниже приведён прикладной чек-лист, который IT Institute использует как первый проход для оценки готовности команды к требованиям приказа ФСТЭК 117 в части безопасной разработки. Он не заменяет аттестацию, но показывает, где обычно возникают разрывы между документами и реальным процессом.
| № | Контрольный пункт | Что должно быть подтверждено |
|---|---|---|
| 1 | Аудит DevSecOps-процессов | Описана схема разработки, сборки, тестирования, релиза и эксплуатации. |
| 2 | Роли и ответственность | Назначены владельцы кода, безопасности, релиза, инфраструктуры и реагирования. |
| 3 | Внутренний стандарт безопасной разработки | Документ утверждён, актуален и применим к проектам. |
| 4 | Модель угроз для продукта | Есть актуальная модель угроз или её инженерный аналог для приложения и API. |
| 5 | SAST | Статический анализ встроен в процесс и блокирует критические дефекты. |
| 6 | DAST | Динамическое тестирование выполняется для предварительного или тестового контура. |
| 7 | SCA | Компоненты с открытым кодом проверяются на уязвимости и лицензии. |
| 8 | Контроль секретов | Ключи, токены и пароли автоматически выявляются до слияния кода. |
| 9 | SBOM для каждого билда | Состав компонентов формируется в машиночитаемом виде, например SPDX или CycloneDX. |
| 10 | Реестр уязвимостей | Все дефекты регистрируются, получают владельца, срок устранения и статус. |
| 11 | Сверка с БДУ ФСТЭК | Уязвимости сопоставляются с БДУ ФСТЭК и другими релевантными базами. |
| 12 | Правила приоритизации | Критичность учитывает CVSS, эксплуатируемость, доступность из сети и бизнес-контекст. |
| 13 | Security gates перед релизом | Релиз блокируется при критических уязвимостях без принятого исключения. |
| 14 | Контроль контейнеров | Образы проверяются на уязвимости, базовые слои и запрещённые пакеты. |
| 15 | Контроль инфраструктурного кода | Terraform, Ansible, Kubernetes-манифесты и Helm-чарты проходят проверку. |
| 16 | Разделение сред | Разработка, тестирование, предварительный контур и промышленная среда разделены. |
| 17 | Журналирование сборок | Сохраняются идентификаторы коммитов, билдов, артефактов и результатов проверок. |
| 18 | Управление обновлениями | Есть процедура оценки, тестирования и установки обновлений ПО. |
| 19 | Исключения из правил | Риск-принятия документируются, имеют срок действия и владельца. |
| 20 | Проверка подрядчиков | В техническом задании и договоре закреплены требования безопасной разработки. |
| 21 | Обучение разработчиков | Команда регулярно проходит обучение по безопасному кодированию. |
| 22 | Тестирование исправлений | Закрытие уязвимости подтверждается повторной проверкой, а не комментарием в задаче. |
| 23 | Резервное копирование артефактов | Хранятся конфигурации, исходный код, пакеты, образы и критичные журналы. |
| 24 | Интеграция с реагированием | Инциденты из эксплуатации возвращаются в backlog разработки. |
| 25 | Доказательная база | По каждому релизу можно показать, кто, что, когда проверил и почему допустил выпуск. |
Расширенные материалы по внедрению security gates и управлению пайплайнами см. в статье DevSecOps в Q4 2025, а по SBOM и анализу состава ПО — в материале SBOM и SCA в России 2026.
Почему 0% полностью соответствуют с первого прохода
Внутренняя статистика IT Institute по 669 командам показывает: частичные практики безопасной разработки есть почти у всех зрелых организаций, но полное соответствие процессной модели встречается редко. Проблема не в отсутствии SAST или SCA как таковых. Проблема в том, что инструменты не связаны с управлением риском, релизным процессом и доказательной базой.
Типовая команда может запускать SAST раз в неделю, но не блокировать релиз при критической уязвимости. Другая команда формирует SBOM, но не хранит его как артефакт конкретного билда. Третья ведёт задачи по уязвимостям в Jira, но не сверяет их с БДУ ФСТЭК и не фиксирует повторную проверку после исправления.
Наиболее частый разрыв — отсутствие трассируемости от требования до релиза. Команда может показать отчёт инструмента, но не может доказать, что конкретная версия, ушедшая в промышленную среду, прошла все обязательные проверки.
Срок миграции типичной команды
Реалистичный срок перехода к управляемой модели соответствия — 6-12 месяцев. Нижняя граница достижима для команд, у которых уже есть единый репозиторий, CI/CD, контроль доступа, code review, тестовый контур и хотя бы один класс security-проверок. В этом случае основная работа связана с формализацией правил, настройкой блокирующих порогов и сбором доказательной базы.
Срок 9-12 месяцев характерен для организаций, где релизы собираются вручную, зависимости ведутся разрозненно, подрядчики поставляют артефакты без состава компонентов, а эксплуатация и разработка живут в разных системах учёта. Здесь внедрение приказа ФСТЭК 117 превращается в программу организационных изменений, а не в установку одного инструмента.
| Стартовое состояние | Типичный срок | Главный риск |
|---|---|---|
| Есть CI/CD, SAST и SCA | 6-8 месяцев | Нет формальных security gates и доказательной базы |
| Есть CI/CD, но проверки выполняются вручную | 8-10 месяцев | Нестабильное качество релизов и спорные исключения |
| Ручные сборки, разрозненные подрядчики | 10-12 месяцев | Невозможно связать уязвимость, билд, владельца и релиз |
Штрафы и регуляторные последствия
Для приказа ФСТЭК 117 важно разделять прямые административные санкции и операционные последствия. По общим нарушениям требований о защите информации применяется статья 13.12 КоАП РФ; для значимых объектов КИИ — статья 13.12.1 КоАП РФ. В зависимости от состава и статуса системы штрафы для юридических лиц могут составлять от 50 000 ₽ до 100 000 ₽ или от 100 000 ₽ до 500 000 ₽.
Однако для CTO и владельца системы важнее не сама сумма штрафа, а риск предписаний, ограничения эксплуатации, срыва ввода в промышленную среду, повторной аттестации, пересмотра договора с заказчиком и потери допуска к регулируемым проектам. В крупных организациях стоимость исправления процессов после проверки обычно выше административной санкции.
Если система одновременно относится к ГИС, обрабатывает персональные данные и входит в контур КИИ, ответственность нужно оценивать по нескольким нормативным слоям: приказ № 117, 187-ФЗ, требования по значимым объектам КИИ, внутренние документы по защите персональных данных и договорные требования заказчика.
Три практических примера внедрения
Банк с государственным участием. Команда начала с инвентаризации 143 репозиториев и обнаружила, что только 38% сервисов имели стабильный CI/CD. После внедрения SCA и SBOM выяснилось, что 27% критичных библиотек не обновлялись больше 18 месяцев. Переход занял 9 месяцев: сначала закрыли учёт компонентов, затем ввели блокирующие правила для критических уязвимостей, после этого связали отчёты с релизными артефактами.
Финтех-поставщик для госсектора. Организация уже использовала SAST и DAST, но отчёты не попадали в релизное досье. Основной проект занял 6 месяцев: команда добавила обязательные security gates, внедрила срок действия исключений, настроила повторную проверку исправлений и включила требования к SBOM в технические задания для внешних модулей.
Оператор инфраструктурной системы. У организации были зрелые процессы эксплуатации, но слабая разработка внутренних инструментов. Проблемой стали скрипты, административные панели и интеграционные API, которые исторически считались вспомогательными. После аудита они были включены в общий контур безопасной разработки. Миграция заняла 12 месяцев, потому что потребовала разделения сред, контроля секретов и пересмотра доступа подрядчиков.
Связь с 187-ФЗ, приказами ФСТЭК и Указом № 250
Приказ ФСТЭК 117 не существует изолированно. Он связан с общей логикой регулирования информационной безопасности: 149-ФЗ задаёт базовую рамку защиты информации, 187-ФЗ регулирует безопасность критической информационной инфраструктуры, Указ Президента № 250 усиливает требования к информационной безопасности организаций, а профильные приказы ФСТЭК определяют меры для отдельных классов систем.
Для практической работы важно построить единую матрицу требований. Один и тот же контроль может закрывать несколько нормативных ожиданий: управление обновлениями, журналирование событий, контроль доступа, управление уязвимостями, безопасная разработка и реагирование на инциденты. Это снижает дублирование и делает аудит управляемым.
Отдельный слой — БДУ ФСТЭК. Если команда использует SCA и ведёт реестр уязвимостей, ей нужно не только ориентироваться на международные базы, но и проверять релевантность уязвимостей по российским источникам. Для этого полезен отдельный процесс сверки, описанный в материале DevSecOps в России 2026: ФСТЭК, КИИ и практика.
Сравнительный анализ
| Критерий | Подход до перехода | Подход по приказу ФСТЭК 117 | Практический вывод |
|---|---|---|---|
| Модель контроля | Разовая подготовка к аттестации | Непрерывный процесс защиты информации | Нужны метрики, журналы и регулярное подтверждение |
| Разработка ПО | Часто вне основного периметра ИБ | Уязвимости должны предотвращаться, выявляться и устраняться | DevSecOps становится обязательной частью процесса |
| Компоненты ПО | Зависимости учитываются вручную или не учитываются | Необходим контролируемый перечень применяемого ПО | SBOM и SCA становятся базовыми практиками |
| Подрядчики | Требования описаны общими словами | Требования безопасной разработки могут включаться в техническое задание | Договоры и приёмка должны требовать артефакты безопасности |
| Уязвимости | Исправляются по мере обнаружения | Нужен управляемый процесс выявления и устранения | Требуются SLA, владельцы, статусы и повторная проверка |
Что это значит для рынка
Приказ ФСТЭК 117 меняет роль безопасности в разработке. Раньше многие команды воспринимали проверки как внешний этап перед запуском: сначала разработка, затем аудит, затем исправление найденных проблем. Новая логика требует встроить безопасность в каждый релизный цикл, чтобы уязвимость не доходила до промышленной среды без осознанного решения и документированного риска.
Для зрелых организаций это не революция, а ускорение уже начатого движения. Для команд с ручными релизами и слабым контролем зависимостей это серьёзная перестройка. Нельзя купить соответствие одним инструментом: SAST без процесса устранения, SBOM без хранения артефактов и DAST без блокирующих правил не дают доказательной зрелости.
- Для CTO: приказ означает необходимость связать разработку, инфраструктуру, эксплуатацию и ИБ в единый поток релиза с понятными точками контроля.
- Для CISO: фокус смещается с наличия средств защиты на доказуемость процесса: кто проверил, что обнаружил, кто исправил, кто принял остаточный риск.
- Для руководителя разработки: security gates должны быть встроены в пайплайн так, чтобы они не превращались в ручной барьер перед каждым релизом.
- Для закупки и юридической службы: требования безопасной разработки нужно включать в технические задания, договоры, критерии приёмки и правила сопровождения.
- Для подрядчика: конкурентным преимуществом становится не обещание «безопасного кода», а комплект артефактов: SBOM, отчёты SAST/SCA/DAST, журнал исключений и подтверждение исправлений.
Рекомендации
- Начать с инвентаризации систем и репозиториев. По нашей выборке, разрывы чаще всего появляются там, где организация не знает полный перечень сервисов, библиотек, контейнеров и внутренних инструментов.
- Ввести обязательный SBOM на каждый значимый билд. Это снижает время реакции на новые уязвимости и позволяет доказать состав поставленного программного обеспечения.
- Связать SAST, DAST и SCA с релизными правилами. Инструменты должны не просто генерировать отчёты, а влиять на решение о выпуске версии.
- Создать единый реестр уязвимостей. Для каждой уязвимости должны быть владелец, критичность, источник, срок устранения, статус, исключение или подтверждение исправления.
- Зафиксировать правила для подрядчиков. В техническом задании нужно требовать отчёты проверок, SBOM, правила обработки уязвимостей и срок поддержки компонентов.
- Построить доказательную базу по релизам. Для проверяющего важен не список инструментов, а возможность восстановить цепочку от требования до конкретного артефакта.
- Проводить аудит не реже одного раза в квартал. Регулярная проверка показывает, что процесс работает постоянно, а не собирается вручную перед внешней оценкой.
Выводы
Приказ ФСТЭК 117 переводит защиту государственных информационных систем в режим постоянного управления. Для разработки это означает, что безопасность должна стать частью инженерного цикла: от требований и модели угроз до сборки, проверки зависимостей, выпуска и эксплуатации. Команды, которые воспринимают приказ только как юридический документ, рискуют недооценить объём технической работы.
Главная зона риска — не отсутствие одного конкретного инструмента, а отсутствие связности. Соответствие появляется там, где SAST, DAST, SCA, SBOM, реестр уязвимостей, БДУ ФСТЭК, релизные правила и договоры с подрядчиками работают как единая система.
Приказ ФСТЭК 117 делает безопасную разработку управленческой дисциплиной: выигрывают не те, кто быстрее установит сканер, а те, кто сможет доказать безопасность каждого релиза.
- Не юридическое заключение. Материал описывает инженерную и процессную интерпретацию требований; для спорных вопросов нужна правовая оценка с учётом конкретной системы.
- Внутренняя выборка. Статистика 669 команд отражает наблюдения IT Institute и не является официальной статистикой ФСТЭК России.
- Разные контуры регулирования. ГИС, КИИ, персональные данные и криптографическая защита могут накладывать дополнительные требования, которые нужно анализировать отдельно.
- Инструменты не сертифицировались в рамках статьи. Упоминание SAST, DAST, SCA, SBOM и CI/CD относится к классам практик, а не к рекомендации конкретного продукта.
FAQ о приказ ФСТЭК 117
Когда приказ ФСТЭК 117 вступил в силу?
Приказ ФСТЭК России № 117 от 11 апреля 2025 года вступил в силу 1 марта 2026 года. Документ был зарегистрирован Минюстом России 16 июня 2025 года под № 82619 и официально опубликован 17 июня 2025 года. Для организаций это означает, что с указанной даты новые требования применяются к защите информации в государственных информационных системах и иных информационных системах государственных органов, государственных унитарных предприятий и государственных учреждений.
Кому нужно выполнять требования приказа ФСТЭК 117?
Прямо требования касаются операторов и обладателей информации в государственных информационных системах и иных информационных системах государственных организаций. На практике они также затрагивают подрядчиков, интеграторов и команды разработки, если они создают, сопровождают или поставляют программное обеспечение для таких систем. Если контур одновременно связан с КИИ, персональными данными или государственным заказчиком, требования нужно рассматривать вместе с другими нормативными актами.
Нужны ли SAST, DAST и SCA для соответствия приказу?
В тексте приказа не перечислены конкретные классы инструментов как обязательный набор для всех случаев. Однако пункт 50 требует мероприятий, направленных на предотвращение появления, выявление и устранение уязвимостей в разрабатываемом программном обеспечении. На практике SAST, DAST и SCA являются наиболее понятными способами доказать, что команда проверяет исходный код, работающее приложение и состав зависимостей до релиза.
Обязательно ли формировать SBOM для каждого билда?
Прямого универсального требования «SBOM для каждого билда» в приказе нет, но без состава компонентов сложно доказать контроль применяемого программного обеспечения и управление уязвимостями зависимостей. Поэтому для регулируемых контуров SBOM становится практической нормой. Лучше формировать его автоматически при сборке, хранить вместе с артефактом релиза и использовать для проверки новых уязвимостей по БДУ ФСТЭК и другим релевантным источникам.
Какие штрафы возможны за несоответствие требованиям?
Размер и состав ответственности зависят от типа системы и нарушения. Для общих нарушений требований защиты информации применяется статья 13.12 КоАП РФ, а для значимых объектов КИИ — статья 13.12.1 КоАП РФ. По отдельным составам штрафы для юридических лиц могут достигать 100 000 ₽ или 500 000 ₽. Но главный риск для организации часто связан не с суммой штрафа, а с предписаниями, задержкой ввода системы и повторной проверкой.
Сколько времени занимает переход к соответствию приказу ФСТЭК 117?
Для типичной команды разработки реалистичный срок составляет 6-12 месяцев. Если уже есть CI/CD, контроль доступа, code review, SAST или SCA, переход может занять 6-8 месяцев. Если сборки выполняются вручную, подрядчики не поставляют отчёты, а уязвимости ведутся разрозненно, срок ближе к 10-12 месяцам. Основное время уходит на процессы, доказательную базу и дисциплину релизов.
Нужно ли сертифицировать инструменты DevSecOps?
Вопрос сертификации зависит от архитектуры системы, класса защищённости, применяемых мер и роли инструмента в контуре защиты. Не каждый SAST, DAST или SCA-инструмент автоматически должен быть сертифицирован как средство защиты информации. Но организация должна понимать, какие инструменты используются для контроля требований, где хранятся результаты проверок, кто имеет к ним доступ и как эти результаты применяются при принятии решения о релизе.
Как приказ ФСТЭК 117 связан с 187-ФЗ и Указом № 250?
Приказ № 117 регулирует защиту информации в государственных информационных системах и иных системах государственных организаций. 187-ФЗ регулирует безопасность критической информационной инфраструктуры, а Указ № 250 усиливает требования к информационной безопасности для широкого круга организаций. Если система относится сразу к нескольким категориям, требования нужно объединять в единую матрицу контролей: доступы, уязвимости, обновления, журналирование, реагирование и безопасная разработка.
*Обзор основан на квартальной отчётности компаний и отраслевых опросах. Цифры верифицированы по двум независимым источникам где возможно.*