ГОСТ Р 56939-2024: 25 процессов безопасной разработки и потоки данных между ними
Интерактивная карта раздела 5 стандарта: какой процесс какие артефакты берёт у других. Выберите процесс на карте — входящие потоки подсветятся оранжевым, исходящие — зелёным, под картой появятся пункты стандарта и дословные цитаты. Кнопка «Проиграть потоки» проводит по всем связям от организации к эксплуатации, «Проиграть обратный контур» — по пути уязвимости из эксплуатации обратно в разработку.
Карта потоков
Обратный контур показан цветными линиями; нажмите «⟲ Проиграть обратный контур», чтобы пройти его по шагам.
Выберите процесс
Щелчок или Enter на узле карты покажет, что процесс получает и кому отдаёт, с пунктами стандарта и цитатами.
Обратный контур: уязвимость из эксплуатации возвращается в разработку
Уязвимость, найденная при эксплуатации (5.22–5.24), должна вернуться назад: в реестр недостатков (5.5), в требования (5.3), архитектуру (5.6), модель угроз и поверхность атаки (5.7) — и затем пройти повторные проверки, приёмку (5.20) и поставку (5.21). Стандарт этот путь задумывает, но замыкает его не ссылками между пунктами, а событиями, которые разработчик сам прописывает в своих регламентах. Прямо по тексту: входная половина (5.22, 5.23, 5.24), повторный статический и динамический анализ после устранения (5.10.2.6, 5.11.2.6) и корректировка модели угроз, поверхности атаки и архитектуры по итогам нефункционального тестирования (5.19.2.5).
1. Выявление
- прямо
5.23.2.2«Осуществлять обработку поступающих запросов от пользователей (через службу технической поддержки, по иным каналам взаимодействия) с последующим анализом ошибок функционирования на предмет наличия уязвимостей (в случае получения таких запросов).» - прямо
5.24.2.2«Актуализировать информацию об уязвимостях ПО из открытых источников на регулярной основе на всем протяжении срока действия его технической поддержки: выполнять поиск в открытых источниках информации об уязвимостях самого ПО и его сторонних компонентов.»
2. Подтверждение и решение
- прямо
5.23.2.4«Осуществлять анализ информации о найденных уязвимостях в ПО на предмет подтверждения наличия/отсутствия уязвимостей и принимать решение о необходимости их устранения по результатам оценки.» - прямо
5.23.2.5«Осуществлять оценку актуальности и критичности уязвимости с точки зрения безопасности ПО (в случае получения информации об уязвимости ПО из внешнего источника) и принимать решение о необходимости ее устранения по результатам оценки.»
3. Регистрация и контроль изменения
- прямо
5.5.2.3«Контролировать реализацию изменений, связанных с недостатками ПО.» - прямо
5.5.2.4«Контролировать реализацию запросов на изменение в рамках жизненного цикла ПО.»
4. Возврат в требования, архитектуру, модель угроз
- по событиям
5.3.2.4«Осуществлять пересмотр набора требований безопасности на основе выполнения критериев пересмотра - с установленной периодичностью или при наступлении определенных событий.» - по событиям
5.6.2.4«Выполнять уточнение архитектуры ПО в процессе разработки кода и его изменений с установленной периодичностью или при наступлении определенных событий.» - по событиям
5.7.2.4«Выполнять уточнение модели угроз ПО для изменяемого в ходе разработки ПО кода с установленной периодичностью или при наступлении определенных событий.» - по событиям
5.7.2.5«Выполнять уточнение описания поверхности атаки для изменяемого в ходе разработки ПО кода с установленной периодичностью или при наступлении определенных событий.» - прямо
5.19.2.5«Осуществлять корректировку описания поверхности атаки, модели угроз и архитектуры ПО по результатам выполнения нефункционального тестирования.»
5. Повторные проверки
- прямо
5.10.2.5«Осуществлять пересмотр конфигурации и параметров настройки инструментов статического анализа при выполнении установленных событий (изменениях в правилах сборки, применяемых статических анализаторах, получении информации об уязвимостях и т.п.).» - прямо
5.10.2.6«Осуществлять повторный статический анализ ПО после устранения ранее выявленных ошибок и уязвимостей; внесения изменений в ходе разработки в исходные тексты ПО; изменения (для компилируемого в промежуточное используемых версий компиляторов, сред выполнения представление или интерпретируемого кода), обновлений используемых инструментов статического анализа.» - прямо
5.11.2.6«Проводить повторный динамический анализ модулей (компонентов) ПО с целью контроля устранения ошибок.» - прямо
5.16.2.3«Контролировать и актуализировать перечень зависимостей ПО в соответствии с регламентом композиционного анализа на предмет наличия известных уязвимостей.» - по событиям
5.18.3.1«… критерии выполнения повторного тестирования …» - по событиям
5.19.3.1«… критерии выбора версий ПО (модулей ПО, компонентов ПО), подлежащих нефункциональному тестированию, и определения периодичности тестирования …»
6. Приёмка исправления
- прямо
5.20.2.2«Осуществлять анализ степени влияния на безопасность ПО неустраненных ошибок. Информация о неустраненных ошибках выпускаемого ПО должна быть зафиксирована (например, в системе управления изменениями, системе отслеживания ошибок и т.п.).»
7. Поставка и оповещение
- прямо
5.21.3.1«… процедуры поставки ПО (обновлений ПО, включая обновления безопасности, предназначенных для устранения недостатков, в том числе уязвимостей) …» - прямо
5.22.2.3«Разработать процедуру оповещения пользователей о выпуске обновлений (включая обновления безопасности) и необходимости их установки.» - прямо
5.22.2.5«Разработать процедуру информирования пользователей ПО о выявленных уязвимостях и способах реализации мер по их нейтрализации до разработки обновлений безопасности, устраняющих уязвимость, по установленным каналам взаимодействия.»
Что прописать в регламентах, чтобы контур замкнулся
- Включить «подтверждённую уязвимость из эксплуатации (5.23)» в события пересмотра требований (критерии 5.3.3.1), уточнения архитектуры (5.6.3.3), модели угроз и поверхности атаки (5.7.2.4, 5.7.2.5).
- Прописать передачу подтверждённой уязвимости в реестр недостатков и запросов на изменение (5.5.3.1, 5.5.3.3): идентификатор, версия, приоритет, статус.
- Обновлять вместе с моделью угроз и перечень мер нейтрализации (5.7.3.2) — в 5.7.2.4 и 5.7.2.5 он не входит.
- Добавить исправления уязвимостей в критерии повторного тестирования (5.18.3.1, 5.19.3.1); решить, нужны ли повторная экспертиза (5.9) и проверка на ВПО (5.17); проверки вести по уточнённым артефактам 5.6.3.4 и 5.7.3.5–5.7.3.7.
- Пропускать исправление через приёмку 5.20 (5.20.2.2) и поставку 5.21 (5.21.3.1); до выхода обновления — информировать пользователей о мерах нейтрализации (5.22.2.5).
Это выводы из текста стандарта: чего в нём нет по номерам пунктов. Для сертификации процессов безопасной разработки эти связки разработчик задаёт сам.
Главное о потоках
Модель угроз и поверхность атаки (5.7)
Модель угроз (5.7.3.1) и описание поверхности атаки (5.7.3.3) явно используются в динамическом анализе (5.11), безопасности секретов (5.15), композиционном анализе (5.16), проверке на ВПО (5.17), функциональном и нефункциональном тестировании (5.18, 5.19), реагировании на уязвимости (5.23) и их поиске при эксплуатации (5.24). Динамический анализ получает ещё и перечень целей (5.7.3.4). Экспертиза кода (5.9) начинает с модулей поверхности атаки — связь без номера пункта.
Архитектура (5.6) — самый частый источник
Описание архитектуры (5.6.3.2) нужно моделированию угроз, статическому и динамическому анализу; требования к принципам проектирования (5.6.3.1) — ещё семи процессам. Сама 5.6 строится на требованиях безопасности (5.3).
Выпуск версии (5.20) собирает результаты проверок
Результаты экспертизы (5.9.3.2), отчёты SAST (5.10.3.4) и DAST (5.11.3.5), итоги устранения уязвимостей компонентов (5.16.3.5), отчёт функционального тестирования (5.18.3.2) и сведения о неустранённых недостатках из реестра 5.5.
Главные источники и потребители
Отдают больше всех: 5.6 (10), 5.7 (9), 5.16 (3), 5.3 (2). Получают больше всех: 5.20 (6), 5.24 (5), 5.17 (4), 5.18 (3).
Не связаны ни в одну сторону: 5.1 Планирование РБПО, 5.2 Обучение, 5.8 Правила кодирования, 5.13 Сборочная среда, 5.14 Доступ и целостность, 5.25 Вывод из эксплуатации — в разделе 5 другие процессы на их артефакты не ссылаются, и сами они на артефакты других процессов не ссылаются.
Схемы Archify
Пять схем с трассировкой потоков, поиском, фокусом и экспортом (интерфейс просмотрщика — на английском).
Матрица связей
Строка — процесс-источник, столбец — потребитель. Зелёная клетка — связь с номером пункта, сиреневая — без номера. Щелчок открывает потребителя на карте.
| источник ↓ / потребитель → | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 5.1 Планирование РБПО | |||||||||||||||||||||||||
| 5.2 Обучение | |||||||||||||||||||||||||
| 5.3 Требования безопасности | |||||||||||||||||||||||||
| 5.4 Конфигурация ПО | |||||||||||||||||||||||||
| 5.5 Недостатки и запросы | |||||||||||||||||||||||||
| 5.6 Архитектура | |||||||||||||||||||||||||
| 5.7 Модель угроз и ПА | |||||||||||||||||||||||||
| 5.8 Правила кодирования | |||||||||||||||||||||||||
| 5.9 Экспертиза кода | |||||||||||||||||||||||||
| 5.10 Статический анализ | |||||||||||||||||||||||||
| 5.11 Динамический анализ | |||||||||||||||||||||||||
| 5.12 Система сборки | |||||||||||||||||||||||||
| 5.13 Сборочная среда | |||||||||||||||||||||||||
| 5.14 Доступ и целостность | |||||||||||||||||||||||||
| 5.15 Секреты | |||||||||||||||||||||||||
| 5.16 Композиционный анализ | |||||||||||||||||||||||||
| 5.17 Проверка на ВПО | |||||||||||||||||||||||||
| 5.18 Функц. тестирование | |||||||||||||||||||||||||
| 5.19 Нефункц. тестирование | |||||||||||||||||||||||||
| 5.20 Выпуск версии | |||||||||||||||||||||||||
| 5.21 Поставка | |||||||||||||||||||||||||
| 5.22 Поддержка | |||||||||||||||||||||||||
| 5.23 Реагирование | |||||||||||||||||||||||||
| 5.24 Поиск уязвимостей | |||||||||||||||||||||||||
| 5.25 Вывод из эксплуатации |
Все 34 связей
| Источник | Потребитель | Что передаётся — где требуется | Связь |
|---|---|---|---|
| 5.3 Требования безопасности | 5.6 Архитектура | Набор требований безопасности ПО — 5.6.2.1Регламент управления требованиями безопасности ПО — 5.6.2.2 | явная |
| 5.3 Требования безопасности | 5.18 Функц. тестирование | Набор требований безопасности ПО: основа сценариев плана тестирования, 5.3.3.2 — 5.18.2.1 | явная |
| 5.4 Конфигурация ПО | 5.5 Недостатки и запросы | Идентификаторы версий ПО (модулей, компонентов) по порядку идентификации из регламента управления конфигурацией (5.4.3.1) — 5.5.3.3 | без номера |
| 5.5 Недостатки и запросы | 5.20 Выпуск версии | Зафиксированные сведения о недостатках ПО с текущим статусом обработки (5.5.3.3), где неустранённые — незакрытые недостатки — 5.20.2.2 | без номера |
| 5.5 Недостатки и запросы | 5.24 Поиск уязвимостей | Зафиксированные факты изменений по недостаткам ПО со статусом исправления (5.5.3.3) — 5.24.3.2 | без номера |
| 5.6 Архитектура | 5.7 Модель угроз и ПА | Описание архитектуры ПО — 5.7.2.1Описание архитектуры ПО — 5.7.2.2Описание архитектуры ПО — 5.7.2.3Уточненная архитектура ПО (5.6.3.4) — 5.7.2.7 | явная |
| 5.6 Архитектура | 5.10 Статический анализ | Описание архитектуры ПО — 5.10.2.1Описание архитектуры ПО — 5.10.2.2 | явная |
| 5.6 Архитектура | 5.11 Динамический анализ | Описание архитектуры ПО — 5.11.2.1 | явная |
| 5.6 Архитектура | 5.15 Секреты | Требования к принципам проектирования архитектуры ПО — 5.15.2.1 | явная |
| 5.6 Архитектура | 5.16 Композиционный анализ | Требования к принципам проектирования архитектуры ПО (в т.ч. применение заимствованных компонентов), 5.6.3.1 — 5.16.2.2 | явная |
| 5.6 Архитектура | 5.17 Проверка на ВПО | Требования к принципам проектирования архитектуры ПО, 5.6.3.1 — 5.17.2.4 | явная |
| 5.6 Архитектура | 5.18 Функц. тестирование | Требования к принципам проектирования архитектуры ПО, 5.6.3.1 — 5.18.2.1 | явная |
| 5.6 Архитектура | 5.19 Нефункц. тестирование | Требования к принципам проектирования архитектуры ПО, 5.6.3.1 — 5.19.2.3Описание архитектуры ПО (5.6.3.2), в том числе уточнённая архитектура (5.6.3.4) — 5.19.3.3 | явная |
| 5.6 Архитектура | 5.23 Реагирование | Требования к принципам проектирования архитектуры ПО — 5.23.2.1 | явная |
| 5.6 Архитектура | 5.24 Поиск уязвимостей | Требования к принципам проектирования архитектуры ПО — 5.24.2.1 | явная |
| 5.7 Модель угроз и ПА | 5.9 Экспертиза кода | Описание поверхности атаки (5.7.3.3, уточненное — 5.7.3.6) — 5.9.2.2 | без номера |
| 5.7 Модель угроз и ПА | 5.11 Динамический анализ | Модель угроз — 5.11.2.1Описание поверхности атаки — 5.11.2.1Перечень целей для исследований — 5.11.2.3 | явная |
| 5.7 Модель угроз и ПА | 5.15 Секреты | Модель угроз — 5.15.2.1Описание поверхности атаки — 5.15.2.1 | явная |
| 5.7 Модель угроз и ПА | 5.16 Композиционный анализ | Модель угроз, 5.7.3.1 — 5.16.2.1Описание поверхности атаки: какие заимствованные компоненты её составляют, 5.7.3.3 — 5.16.2.4 | явная |
| 5.7 Модель угроз и ПА | 5.17 Проверка на ВПО | Модель угроз: для выявления элементов инфраструктуры, влияющих на появление НДВ, 5.7.3.1 — 5.17.2.3Описание поверхности атаки, 5.7.3.3 — 5.17.2.3 | явная |
| 5.7 Модель угроз и ПА | 5.18 Функц. тестирование | Модель угроз, 5.7.3.1 — 5.18.2.1Описание поверхности атаки, 5.7.3.3 — 5.18.2.1 | явная |
| 5.7 Модель угроз и ПА | 5.19 Нефункц. тестирование | Модель угроз: возможности и мотивация нарушителя в регламенте тестирования, 5.7.3.1 — 5.19.2.2Описание поверхности атаки: интерфейсы и цели тестов с имитацией нарушителя, 5.7.3.3 — 5.19.2.4Перечень мер по нейтрализации (снижению вероятности возникновения) угроз безопасности информации (5.7.3.2) — 5.19.2.1 | явная |
| 5.7 Модель угроз и ПА | 5.23 Реагирование | Модель угроз — 5.23.2.1Описание поверхности атаки — 5.23.2.1 | явная |
| 5.7 Модель угроз и ПА | 5.24 Поиск уязвимостей | Модель угроз — 5.24.2.1Описание поверхности атаки — 5.24.2.1 | явная |
| 5.9 Экспертиза кода | 5.20 Выпуск версии | Результаты экспертизы исходного кода, 5.9.3.2 — 5.20.2.2 | явная |
| 5.10 Статический анализ | 5.20 Выпуск версии | Отчёты по результатам статического анализа, 5.10.3.4 — 5.20.2.2 | явная |
| 5.11 Динамический анализ | 5.20 Выпуск версии | Отчёты по результатам динамического анализа, 5.11.3.5 — 5.20.2.2 | явная |
| 5.12 Система сборки | 5.17 Проверка на ВПО | Информация о сборочной среде: инструменты системы сборки, их версии и конфигурации, 5.12.3.2 — 5.17.2.1 | явная |
| 5.16 Композиционный анализ | 5.17 Проверка на ВПО | Перечень зависимостей ПО (заимствованные компоненты, версии, поставщики), 5.16.3.2 — 5.17.2.1 | явная |
| 5.16 Композиционный анализ | 5.20 Выпуск версии | Результаты корректирующих воздействий по уязвимостям в зависимостях, 5.16.3.5 — 5.20.2.2 | явная |
| 5.16 Композиционный анализ | 5.24 Поиск уязвимостей | Перечень зависимостей ПО — 5.24.2.2 | явная |
| 5.18 Функц. тестирование | 5.20 Выпуск версии | Отчёт по результатам функционального тестирования (в т.ч. перечень ошибок), 5.18.3.2 — 5.20.2.2 | явная |
| 5.21 Поставка | 5.24 Поиск уязвимостей | Зафиксированные сведения о версиях ПО и обновлениях, поставленных пользователям (5.21.2.2, 5.21.3.2) — 5.24.3.2 | без номера |
| 5.22 Поддержка | 5.23 Реагирование | Обращения пользователей, принятые службой технической поддержки (5.22.2.2, 5.22.3.1) — 5.23.2.2 | без номера |
Кандидаты, которые не вошли — 9
Найдены при разборе, но в карту не вошли.
Проверка по тексту не подтвердила — 5
| Кандидат | Что предполагалось | Почему не вошёл |
|---|---|---|
| 5.10 → 5.9 | Отчеты по результатам статического анализа | Цитата есть в примечании к 5.9.2, многоточие допустимо. Но это справочное примечание об охвате подраздела, а не требование, которое использует артефакт. Оно лишь говорит, что экспертиза охватывает и код, где результаты статического анализа «нуждаются в подтверждении». В нем нет указания брать отчеты |
| 5.5 → 5.18 | Система управления недостатками ПО (средства автоматизации 5.5.2.5, учёт недостатков 5.5.3.3) | Цитата есть в 5.18.2.5 дословно. Но данные из 5.5 здесь не используются: пункт требует вести исправление ошибок через систему управления ошибками, то есть 5.18 пользуется общим инструментом и сам пишет в него записи. Реестр ошибок тестирования — собственный артефакт 5.18 (5.18.3.4 «Сведения системы |
| 5.20 → 5.22 | Факт выпуска обновления ПO (версии, готовой к эксплуатации) | Цитата есть в 5.22.2.3 дословно. Но пункт требует РАЗРАБОТАТЬ процедуру оповещения, то есть говорит о теме, а не берёт готовые данные. Источник тоже не подтверждается: в 5.20.3 перечислены регламент приёмки, результаты анализа неустранённых ошибок, регламент целостности и результаты проверки мер цел |
| 5.5 → 5.23 | Средства автоматизации управления недостатками и изменениями (система управления изменениями, отслеживания ошибок, управления задачами) | Цитата есть в 5.23.2.3 дословно. Но это общий инструмент, а не данные: 5.23 требует пользоваться средствами автоматизации, причём системы названы как примеры («например»), без отсылки к системам из 5.5. Источник не подтверждается: в 5.5.3 есть только регламенты (5.5.3.1, 5.5.3.2) и зафиксированные ф |
| 5.20 → 5.24 | Сведения о выпуске обновлений ПО | Цитата есть в 5.24.3.2, и отчёт действительно включает сведения о выпуске обновлений. Но источник указан неверно. В 5.20.3 есть регламент приёмки (5.20.3.1), результаты анализа неустранённых ошибок (5.20.3.2), регламент целостности (5.20.3.3) и результаты проверки мер целостности (5.20.3.4); сведени |
Не проверялись — исключены по умолчанию — 4
Проверяющий их не рассмотрел; по правилу «при сомнении не включать» в карту они не вошли. Все четыре касаются инструментов анализа, а не передачи данных.
| Кандидат | Что предполагалось |
|---|---|
| 5.16 → 5.12 | Инструменты композиционного анализа (для перечня инструментов сборки) |
| 5.10 → 5.13 | Инструменты статического анализа в составе сборочной среды |
| 5.10 → 5.15 | Инструменты статического анализа (проверка кода на секреты) |
| 5.16 → 5.15 | Инструменты композиционного анализа (проверка кода на секреты) |