Как мы работаем: этапы и процессы ГОСТ Р 56939-2024
Раздел 5 стандарта описывает 25 процессов безопасной разработки. У каждого есть цели, требования и артефакты — документы и записи, по которым проверяют, что процесс работает. Мы разобрали, какие процессы закрывает конвейер, какие ведёте вы по нашим шаблонам и что после нас остаётся у вас.
Показать заказчику или проверяющему, что процессы безопасной разработки работают, а не только описаны.
Проходим шесть этапов: от замеров до передачи. Для каждого процесса ГОСТ решаем, что делает конвейер, а что — ваша команда.
Конвейер, регламенты и артефакты по пунктам стандарта, которые накапливаются в каждой сборке.
Этапы
Один порядок для всех проектов. Цену и срок фиксируем после замеров.
- Шаг 1 · 1–3 дня
Обследование
Смотрим репозитории, сборку и инфраструктуру, проходим по 25 процессам и для каждого ставим статус: есть, частично, нет, не применимо. «Есть» — только когда видели артефакт. Результат — отчёт с фиксированной ценой и сроком.
- Шаг 2
Проектирование
Проектное решение: состав конвейера, схема установки, какие процессы он закрывает. План работ с планом отката и программа испытаний.
- Шаг 3
Подготовка инфраструктуры
Стенд и рабочие окружения, доступы — по списку и минимальные.
- Шаг 4
Внедрение
Автоматизированная установка, подключение проектов, настройка проверок и сбора артефактов, шаблоны регламентов под вашу компанию.
- Шаг 5
Испытания и приёмка
Проверяем по согласованной программе, оформляем протокол.
- Шаг 6
Передача
Документация, обучение команды, отзыв наших доступов. Дальше — поддержка по подписке, если она нужна.
Для пакета «Старт» (до 20 разработчиков) весь путь от обследования до передачи занимает 4 недели; обследование и там проводим — чтобы убедиться, что вы в рамки пакета попадаете.
25 процессов: кто что делает
Для каждого процесса стандарт требует регламент — его пишем по нашему шаблону, утверждаете вы. В таблице — остальное: что даёт конвейер и какие артефакты из пунктов 5.x.3 остаются у вас.
| Процесс | Кто | Что делаем | Что остаётся у вас |
|---|---|---|---|
| Организация процессов | |||
| п. 5.1Планирование | Вы + наш шаблон | Обследование даёт анализ текущего статуса процессов, на этапе проектирования готовим проект плана реализации. | Анализ текущего статуса (5.1.3.1), план реализации (5.1.3.4). План развития и область применения с обоснованием (5.1.3.3, 5.1.3.5) утверждаете вы. |
| п. 5.2Обучение сотрудников | Вы + наш шаблон | Обучаем команду работе с конвейером и разбору срабатываний. | Сведения о проведённом обучении. План и учёт обучения (5.2.3.2–5.2.3.4) — ваши. |
| п. 5.3Требования безопасности к ПО | Конвейер + вы | Шаблон регламента и тип задач в трекере с полями из п. 5.3.3.2: идентификатор, формулировка, дата, приоритет, сроки, кто предъявил и кто принял. | Набор требований и история их статусов (5.3.3.2, 5.3.3.3). Сами требования формулируете вы. |
| Проектирование | |||
| п. 5.6Архитектура ПО | Вы + наш шаблон | Шаблон описания архитектуры с составом из п. 5.6.3.2: назначение, среда, подсистемы, интерфейсы, порты, протоколы. | Описание архитектуры и его уточнения ведёте вы. |
| п. 5.7Моделирование угроз и поверхность атаки | Вы + наш шаблон | Шаблон модели угроз ПО. Перечень целей из п. 5.7.3.4 берём для настройки фаззинга и экспертизы кода. | Модель угроз, описание поверхности атаки, перечень целей (5.7.3.1–5.7.3.4). |
| Код | |||
| п. 5.4Управление конфигурацией | Конвейер | Репозитории, версии, защищённые ветки, документация в системе контроля версий. | Факты изменений ПО и документации — история коммитов и merge request (5.4.3.3). |
| п. 5.5Недостатки и запросы на изменение | Конвейер | Трекер с полями «версия», «приоритет», «статус» и связью задач с коммитами. Средства автоматизации здесь обязательны (п. 5.5.2.5). | Записи по недостаткам и запросам (5.5.3.3, 5.5.3.4). |
| п. 5.8Правила кодирования | Конвейер | Проверка правил в каждом merge request линтерами и статическим анализатором — п. 5.8.2.4 это допускает. | Результаты проверки по каждому изменению. Регламент по языкам — по нашему шаблону. |
| п. 5.9Экспертиза исходного кода | Конвейер | Обязательное одобрение merge request, владельцы кода для модулей поверхности атаки, чек-лист экспертизы. | История обсуждений и одобрений (5.9.3.2). Экспертизу проводит разработчик, который не писал этот код (примечание к 5.9.2). |
| п. 5.10Статический анализ | Конвейер | AppSec.Wave в каждом merge request и сборке, все срабатывания и разметка сохраняются. | Перечень инструментов с версиями, конфигурации, отчёты с разметкой (5.10.3.2–5.10.3.4). |
| п. 5.11Динамический анализ и фаззинг | Конвейер | ZAP, AFL++, libFuzzer в конвейере; коллекции входных данных и отчёты хранятся. | Перечни инструментов и модулей, сценарии, отчёты динамического анализа и фаззинга (5.11.3.2–5.11.3.6). |
| Сборка и сторонние компоненты | |||
| п. 5.12Безопасная система сборки | Конвейер | Сборка в контейнерах с закреплёнными версиями образов и инструментов. | Сведения о сборочной среде и перечень выполненных рекомендаций производителя (5.12.3.2, 5.12.3.3). |
| п. 5.13Безопасность сборочной среды | Конвейер | Изолированные агенты сборки, хранилище результатов AppSec.Registry, контрольные суммы, доступ по ролям. | Схема среды, журналы аудита каждой сборки, хранилище с контрольными суммами (5.13.3.3–5.13.3.5). |
| п. 5.14Доступ и целостность кода | Конвейер | Ролевая модель, защищённые ветки, подпись коммитов, резервные копии репозиториев. | Модель доступа и результаты контроля целостности (5.14.3.2, 5.14.3.3). |
| п. 5.15Секреты | Конвейер | OpenBao, проверка изменений на секреты, подпись артефактов. Процесс применяется по усмотрению разработчика (примечание к 5.15.2). | Отчёты проверок и политики хранилища секретов. |
| п. 5.16Композиционный анализ | Конвейер | AppSec.Track и SBOM каждой сборки; зависимости — только через внутренние репозитории. Допуск новых компонентов → | Перечень зависимостей с версиями и источником, журналы, результаты анализа (5.16.3.2–5.16.3.4). |
| п. 5.17Вредоносное ПО через цепочки поставок | Конвейер + вы | Антивирусная проверка зависимостей и образов в конвейере, контрольные суммы предсобранных компонентов. | Отчёты антивирусного сканирования и идентификация предсобранного ПО (5.17.3.4, 5.17.3.5). Перечни поставщиков и критичной инфраструктуры — ваши. |
| Тестирование | |||
| п. 5.18Функциональное тестирование | Конвейер + вы | Запуск ваших тестов в конвейере, отчёты привязаны к номеру сборки. | Журналы тестирования (5.18.3.3). План и сценарии (5.18.3.1) — ваши. |
| п. 5.19Нефункциональное тестирование | Конвейер + вы | Динамическое сканирование, проверка образов и конфигураций в конвейере. | Результаты автоматических проверок. Тестирование с имитацией нарушителя и выводы — вы или сторонняя организация. |
| Выпуск и эксплуатация | |||
| п. 5.20Выпуск версии | Конвейер | Выпуск только после прохождения проверок; подпись и контрольные суммы релизов. | Результаты проверки мер целостности (5.20.3.4). Решения о выпуске с неустранёнными ошибками (5.20.3.2) — ваши. |
| п. 5.21Поставка пользователям | Конвейер + вы | Хранилище всех выпущенных версий только на чтение. | Место хранения копий версий (5.21.3.3). Эксплуатационная документация — ваша. |
| п. 5.22Поддержка при эксплуатации | Вы + наш шаблон | Шаблон регламента технической поддержки. | Служба поддержки и оповещение пользователей — ваши. |
| п. 5.23Реагирование на уязвимости | Конвейер | Трекер для сообщений об уязвимостях, оповещения AppSec.Track о новых уязвимостях в выпущенных версиях, шаблон ответа пользователю. | Записи по обращениям, анализу и оценке критичности (5.23.3.2–5.23.3.4). |
| п. 5.24Поиск уязвимостей при эксплуатации | Конвейер | Регулярная повторная проверка выпущенных версий по SBOM — в подписке на поддержку. | Регулярные отчёты (5.24.3.2) в части проверок; исправления и выпуск обновлений — ваши. |
| п. 5.25Вывод из эксплуатации | Вы + наш шаблон | Шаблон регламента вывода ПО из эксплуатации. | Оповещение пользователей о прекращении поддержки — ваше. |
Это раскладка для объёма работ, а не оценка соответствия: методика оценки — предмет отдельного национального стандарта (п. 4.4). Если документ требует соответствия ГОСТ, обязательны все требования, кроме сформулированных через «рекомендуется» и «может» (п. 4.14). Распределение для вашего проекта фиксируем в проектном решении.
Общие требования раздела 4
Среда разработки
Контроль версий, непрерывная интеграция и управление задачами, а проверки встроены в эти системы (п. 4.13). Это основа конвейера: AppSec.Code или ваш GitLab.
Регламенты
Обязанности, роли и порядок по каждому процессу; можно одним руководством по безопасной разработке (п. 4.12). Его же прикладывают к заявке на сертификацию по приказу ФСТЭК России № 240 (п. 5.1).
Защита самих результатов
Доступ к отчётам анализаторов и тестов — по ролям, защищённое хранение, антивирусная защита (п. 4.17).
Правила, по которым работаем
- Код и данные остаются в вашей инфраструктуре. На обследовании — доступ только на чтение.
- Каждый доступ записан и отзывается при передаче.
- Ничего не меняем в рабочих окружениях без согласованного плана и плана отката; сначала — стенд.
- Если в системах есть персональные данные, до доступа оформляем поручение на их обработку.
- Не обещаем соответствие и сертификацию: внедряем меры и собираем доказательную базу, оценку проводите вы или орган по сертификации.
Вопросы и ответы
Почему таблица по ГОСТ, а не по зарубежным практикам?
Приказы ФСТЭК России № 240 и № 117 и указания Банка России о сертификации процессов разработки ссылаются на ГОСТ Р 56939-2024. Если ваш процесс уже построен по NIST SSDF (SP 800-218) или другой модели, на обследовании сопоставим его с процессами ГОСТ и покажем, чего не хватает. Кому и что нужно →
Нужно ли внедрять все 25 процессов?
Зависит от того, откуда требование. Если документ требует соответствия стандарту — все требования, кроме рекомендуемых (п. 4.14). Для НИОКР в техническом задании можно перечислить только нужные процессы (п. 4.15). Объём определяем на обследовании.
Вы напишете модель угроз и описание архитектуры?
Даём шаблоны и помогаем заполнить. Сами документы зависят от вашего продукта — если нужно, разработку берём отдельной строкой в цене.
Что такое «артефакт» в этой таблице?
Любая сохранённая информация, по которой можно подтвердить выполнение требования: документ, отчёт, журнал, результат работы инструмента (п. 4.11). Конвейер сохраняет такие записи в каждой сборке.
Источники
- ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования», утверждён приказом Росстандарта от 24 октября 2024 г. № 1504-ст, разделы 4 и 5.
- Порядок сертификации процессов безопасной разработки, утверждённый приказом ФСТЭК России № 240, в редакции приказа № 230 — пп. 5.1, 19. Кратко →
С чего начать
Напишите, сколько у вас разработчиков, какой стек и откуда требование (приказ, заказчик, Банк России). Предложим обследование и пришлём пример отчёта.