Введение в действие национального стандарта ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» (взамен ГОСТ Р 56939-2016) знаменует новый этап в регулировании процессов создания программного обеспечения (ПО) в Российской Федерации. Для организаций, работающих с государственными информационными системами (ГИС), персональными данными (ПДн) и объектами критической информационной инфраструктуры (КИИ), внедрение требований этого стандарта становится не просто рекомендацией, а необходимым условием для выполнения регуляторных предписаний ФСТЭК России.
Данная статья призвана помочь специалистам по информационной безопасности и руководителям разработчиков разобраться в пересечении регуляторных требований и стандарта, а также предложить пошаговый план действий по подготовке процессов разработки к оценке соответствия.
1. Регуляторный контекст: Зачем это нужно?
Сам по себе ГОСТ Р 56939-2024 является документом добровольного применения. Однако его требования становятся обязательными де-факто, когда они referenced (ссылаются) в нормативных правовых актах или технических заданиях. Ключевыми документами, формирующими спрос на безопасную разработку, являются:
Федеральное законодательство
- Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» [консультант.ру] — базовый закон, устанавливающий правовые основы защиты информации.
- Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» [консультант.ру] — определяет требования к безопасности значимых объектов КИИ.
- Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» [консультант.ру] — регулирует обработку и защиту персональных данных.
Приказы ФСТЭК России
- Приказ ФСТЭК России № 239 от 25.12.2017 «Требования по обеспечению безопасности значимых объектов КИИ» [fstec.ru].
- В разделе 29.3 прямо указаны требования к безопасной разработке ПО для значимых объектов 1 категории (и частично 2 и 3). Требуется наличие руководства по безопасной разработке, анализ угроз безопасности ПО, описание структуры ПО, тестирование на уязвимости (статический и динамический анализ).
- Пункт 29.4 требует оценки выполнения этих требований разработчиком на этапе проектирования.
- Приказ ФСТЭК России № 17 от 11.02.2013 «Требования о защите информации… в государственных информационных системах» [fstec.ru].
- Требует проведения анализа угроз (п. 14.3), анализа уязвимостей (п. 16.6) и использования сертифицированных средств защиты информации (СЗИ) в зависимости от класса защищенности ГИС.
- Приказ ФСТЭК России № 21 от 18.02.2013 «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных» [fstec.ru].
- Для уровней защищенности 1 и 2 предусматривает меры по анализу кода, тестированию на проникновение и использованию методов защищенного программирования (п. 11).
Постановления Правительства
- Постановление Правительства РФ от 01.11.2012 № 1119 «Требования к защите персональных данных при их обработке в информационных системах персональных данных» [консультант.ру] — устанавливает уровни защищенности ПДн, от которых зависит состав мер защиты.
Методические документы ФСТЭК России
- «Методика оценки угроз безопасности информации», утв. ФСТЭК России 05.02.2021 [контур.норматив] — методология проведения анализа угроз.
- «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных», утв. ФСТЭК России 15.02.2008 [fstec.ru].
- «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных», утв. ФСТЭК России 14.02.2008 [fstec.ru].
- Банк данных угроз безопасности информации ФСТЭК России (БДУ) [bdu.fstec.ru] — обязательный источник при моделировании угроз согласно требованиям приказов № 17, 21, 239.
- «Порядок проведения сертификации», утв. приказом ФСТЭК России от 01.12.2023 № 240 [fstec.ru] — регламентирует процедуры оценки соответствия.
Национальные стандарты
- ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» [контур.документ] — основной стандарт, рассматриваемый в статье.
- ГОСТ Р 56939-2016 (предыдущая версия) [wikisec.ru] — для понимания эволюции требований.
- ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения» [контур.документ] — применяется при проектировании защищённых систем.
- ГОСТ Р 59547-2021 «Защита информации. Требования к разработке безопасного программного обеспечения для информационных систем персональных данных» [контур.документ] — специализированный стандарт для ПДн.
ГОСТ Р 56939-2024 предоставляет методологическую базу для выполнения этих требований. Он описывает как именно организовать процессы, чтобы нейтрализовать уязвимости на этапах создания ПО, а не только во время эксплуатации.
2. Ключевые процессы безопасной разработки по ГОСТ Р 56939-2024
Стандарт описывает жизненный цикл безопасной разработки через совокупность процессов (Раздел 5). Для подготовки к соответствию организации необходимо внедрить и документально зафиксировать следующие ключевые активности:
2.1. Управление и планирование
- Планирование процессов (5.1): Организация должна иметь план развития и внедрения процессов безопасной разработки, анализировать потребности в ресурсах.
- Обучение сотрудников (5.2): Обязательное повышение осведомленности разработчиков об угрозах, уязвимостях и безопасном кодировании. Требуется учет обучения и критерии пересмотра программ.
- Управление требованиями безопасности (5.3): Требования к безопасности должны быть выделены в отдельный набор, tracked (отслеживаться) и пересматриваться.
2.2. Инженерные практики
- Архитектура и моделирование угроз (5.6, 5.7): Критически важный пункт для выполнения требований Приказа № 239. Необходимо создавать и актуализировать модель угроз ПО и описание поверхности атаки с использованием Банка данных угроз ФСТЭК России [bdu.fstec.ru] и методик оценки угроз [контур.норматив].
- Безопасное кодирование (5.8): Наличие регламента оформления кода, запрет на опасные конструкции (например, хардкод паролей).
- Анализ кода (5.9, 5.10, 5.11):
- Экспертиза кода: Ручной или автоматизированный анализ.
- Статический анализ (SAST): Обязателен регламент, выбор инструментов, обработка предупреждений.
- Динамический анализ (DAST) и фаззинг-тестирование: Поиск уязвимостей в работающем коде.
- Безопасная сборка (5.12, 5.13): Контроль целостности среды сборки, управление доступом, логирование действий.
- Управление зависимостями (5.16): Композиционный анализ (SCA) для выявления уязвимостей в сторонних компонентах (Supply Chain Security).
2.3. Тестирование и выпуск
- Функциональное и нефункциональное тестирование (5.18, 5.19): Включая тесты на безопасность, имитирующие действия нарушителя.
- Приемка и выпуск (5.20, 5.21): Анализ влияния неустраненных ошибок на безопасность, обеспечение целостности поставляемого ПО.
- Поддержка и реагирование (5.22, 5.23, 5.24): Процессы обработки сообщений об уязвимостях от пользователей, поиск уязвимостей в эксплуатируемом ПО.
3. Артефакты: Доказательство соответствия
Согласно разделу 4.11 ГОСТ Р 56939-2024, подтверждением реализации требований являются артефакты. При проверке (аудите или аттестации) регулятор или оценщик будет запрашивать именно их.
Основные группы документов, которые должны быть готовы в организации:
- Регламенты и политики:
- Регламент управления требованиями безопасности.
- Регламент управления конфигурацией ПО.
- Регламент проведения статического и динамического анализа.
- Регламент безопасной сборки и поставки.
- Регламент реагирования на уязвимости.
- Отчетные документы:
- Модель угроз безопасности ПО и описание поверхности атаки (с использованием БДУ ФСТЭК [bdu.fstec.ru]).
- Отчеты статического и динамического анализа (с разметкой ошибок).
- Отчеты функционального и нефункционального тестирования.
- Журналы аудита сборки ПО.
- Перечень зависимостей ПО (SBOM) и результаты анализа их уязвимости.
- Записи об обучении:
- Планы обучения, списки сотрудников, сертификаты/отчеты о прохождении курсов.
4. Пошаговое руководство к действиям
Подготовка организации к соответствию требованиям ГОСТ Р 56939-2024 и смежным приказам ФСТЭК требует системного подхода. Ниже приведен план действий.
Шаг 1. Анализ текущего состояния (Gap Analysis)
- Действие: Проведите аудит существующих процессов разработки (SDLC).
- Цель: Выявить разрывы между текущими практиками и требованиями ГОСТ Р 56939-2024 и Приказа № 239 (если вы субъект КИИ).
- Результат: Отчет о несоответствиях. Например, «Отсутствует регламент статического анализа» или «Не ведется модель угроз для новых модулей».
Шаг 2. Разработка нормативной базы
- Действие: Разработайте или актуализируйте пакет организационно-распорядительных документов (ОРД).
- Важно: Документы не должны быть формальными. Они должны описывать реальные процессы. Используйте требования разделов 5.1–5.25 ГОСТа как чек-лист для содержания регламентов.
- Нюанс: Согласно ГОСТ (п. 4.12), регламенты могут быть объединены в одно руководство по безопасной разработке.
Шаг 3. Выбор и настройка инструментария
- Действие: Подберите инструменты для автоматизации требований.
- Необходимый минимум:
- Система управления задачами (для трекинга уязвимостей и требований).
- Средства статического анализа кода (SAST).
- Средства динамического анализа/фаззинга (DAST).
- Средства анализа зависимостей (SCA).
- Система контроля версий и безопасной сборки (CI/CD).
- Требование ФСТЭК: Для ГИС и КИИ может потребоваться использование сертифицированных средств защиты информации (Приказы № 17, 239). Проверьте реестры ФСТЭК и порядок сертификации [fstec.ru].
Шаг 4. Обучение и культура безопасности
- Действие: Организуйте обучение разработчиков, тестировщиков и архитекторов.
- Содержание: Безопасное кодирование, работа с инструментами анализа, основы моделирования угроз с использованием актуальных методик ФСТЭК.
- Фиксация: Сохраните все материалы обучения и списки участников (требование п. 5.2 ГОСТа).
Шаг 5. Пилотное внедрение
- Действие: Примените новые процессы на одном из проектов (желательно не самом критичном, но репрезентативном).
- Цель: Отработать взаимодействие между разработчиками и безопасниками, настроить пороги срабатывания анализаторов, чтобы не блокировать разработку ложными срабатываниями.
- Результат: Скорректированные регламенты и набор реальных артефактов (отчетов).
Шаг 6. Оценка соответствия и аттестация
- Действие: Проведите внутренний аудит процессов.
- Для КИИ/ГИС: Подготовьте документацию для аттестации информационной системы или оценки уровня защищенности.
- Важно: Помните, что методика оценки соответствия процессов разработки положениям ГОСТ Р 56939-2024 является предметом отдельного национального стандарта (п. 4.4 ГОСТа). Однако наличие внедренных процессов является обязательным требованием Приказа № 239 для значимых объектов.
5. Типичные ошибки при внедрении
- Формальный подход: Создание регламентов, которые никто не читает. Аудиторы проверяют не наличие бумаги, а наличие записей в журналах, отчетов анализаторов и фактов устранения уязвимостей.
- Игнорирование Supply Chain: В ГОСТ Р 56939-2024 (раздел 5.16, 5.17) и Приказе № 239 большое внимание уделено безопасности цепочки поставок. Отсутствие анализа сторонних библиотек — критическое несоответствие.
- Отсутствие интеграции в CI/CD: Безопасность не должна быть «воротами» в конце разработки. Инструменты анализа должны быть встроены в конвейер сборки (п. 4.13 ГОСТа).
- Неактуальная модель угроз: Модель угроз должна пересматриваться при изменениях в архитектуре (п. 5.7.2.4). Статичный документ, созданный один раз, не соответствует требованиям. Используйте БДУ ФСТЭК [bdu.fstec.ru] для актуализации.
- Некорректный выбор мер защиты: При адаптации базовых наборов мер из Приложений к Приказам № 17, 21, 239 необходимо учитывать специфику ПО и актуальные угрозы, а не применять меры механически.
Заключение
ГОСТ Р 56939-2024 задает высокую планку зрелости процессов разработки. Для организаций, подпадающих под регулирование ФСТЭК России (КИИ, ГИС, операторы ПДн), внедрение этого стандарта — это путь не только к соблюдению закона, но и к снижению рисков безопасности и затрат на устранение уязвимостей на поздних этапах.
Подготовка к соответствию требует времени и ресурсов, но наличие прозрачных, задокументированных и автоматизированных процессов безопасной разработки становится ключевым конкурентным преимуществом и обязательным условием допуска на рынок защищенного программного обеспечения в Российской Федерации.
Примечание: Данная статья носит информационный характер. При реализации мер защиты необходимо руководствоваться актуальными текстами нормативных правовых актов и стандартов, размещёнными на официальных сайтах ФСТЭК России (https://fstec.ru), Роскомнадзора (https://rkn.gov.ru/) и в правовых системах.
Справочный раздел: Полезные ресурсы
| Документ | Ссылка |
|---|---|
| ГОСТ Р 56939-2024 | контур.документ |
| Приказ ФСТЭК № 239 (КИИ) | fstec.ru |
| Приказ ФСТЭК № 17 (ГИС) | fstec.ru |
| Приказ ФСТЭК № 21 (ПДн) | fstec.ru |
| Банк данных угроз ФСТЭК | bdu.fstec.ru |
| Методика оценки угроз (2021) | контур.норматив |
| Порядок сертификации ФСТЭК | fstec.ru |
| Постановление № 1119 (ПДн) | консультант.ру |
| 149-ФЗ «Об информации» | консультант.ру |
| 187-ФЗ «О безопасности КИИ» | консультант.ру |
| 152-ФЗ «О персональных данных» | консультант.ру |