ГОСТ Р 56939-2024: 25 процессов безопасной разработки и потоки данных между ними

Интерактивная карта раздела 5 стандарта: какой процесс какие артефакты берёт у других. Выберите процесс на карте — входящие потоки подсветятся оранжевым, исходящие — зелёным, под картой появятся пункты стандарта и дословные цитаты. Кнопка «Проиграть потоки» проводит по всем связям от организации к эксплуатации, «Проиграть обратный контур» — по пути уязвимости из эксплуатации обратно в разработку.

25процессов (5.1–5.25)
121требований к реализации
98видов артефактов
34связей: 28 с номером пункта, 6 без номера
5.6 → 10архитектура — самый частый источник
5.7 → 9модель угроз и поверхность атаки
⟲ 14связей обратного контура: 5 прямо в тексте, 6 по событиям, 3 по номеру нет

Карта потоков

Обратный контур:прямо в текстепо событиям разработчикапо номеру нет

Обратный контур показан цветными линиями; нажмите «⟲ Проиграть обратный контур», чтобы пройти его по шагам.

Обратный контур: уязвимость из эксплуатации возвращается в разработку

Уязвимость, найденная при эксплуатации (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«Контролировать реализацию запросов на изменение в рамках жизненного цикла ПО.»
Передача подтверждённой уязвимости из 5.23 в реестр 5.5 по номеру не прописана.

4. Возврат в требования, архитектуру, модель угроз

  • по событиям 5.3.2.4«Осуществлять пересмотр набора требований безопасности на основе выполнения критериев пересмотра - с установленной периодичностью или при наступлении определенных событий.»
  • по событиям 5.6.2.4«Выполнять уточнение архитектуры ПО в процессе разработки кода и его изменений с установленной периодичностью или при наступлении определенных событий.»
  • по событиям 5.7.2.4«Выполнять уточнение модели угроз ПО для изменяемого в ходе разработки ПО кода с установленной периодичностью или при наступлении определенных событий.»
  • по событиям 5.7.2.5«Выполнять уточнение описания поверхности атаки для изменяемого в ходе разработки ПО кода с установленной периодичностью или при наступлении определенных событий.»
  • прямо 5.19.2.5«Осуществлять корректировку описания поверхности атаки, модели угроз и архитектуры ПО по результатам выполнения нефункционального тестирования.»
Эксплуатация как повод пересмотра не названа: события задаёт разработчик (5.3.3.1, 5.6.3.3). Перечень мер нейтрализации (5.7.3.2) в уточнение не входит.

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«… критерии выбора версий ПО (модулей ПО, компонентов ПО), подлежащих нефункциональному тестированию, и определения периодичности тестирования …»
Экспертизу кода (5.9) и проверку на ВПО (5.17) повторять не требуется; проверки не ссылаются на уточнённые 5.6.3.4 и 5.7.3.5–5.7.3.7.

6. Приёмка исправления

  • прямо 5.20.2.2«Осуществлять анализ степени влияния на безопасность ПО неустраненных ошибок. Информация о неустраненных ошибках выпускаемого ПО должна быть зафиксирована (например, в системе управления изменениями, системе отслеживания ошибок и т.п.).»
Требования пропускать обновление через приёмку 5.20 по номеру нет.

7. Поставка и оповещение

  • прямо 5.21.3.1«… процедуры поставки ПО (обновлений ПО, включая обновления безопасности, предназначенных для устранения недостатков, в том числе уязвимостей) …»
  • прямо 5.22.2.3«Разработать процедуру оповещения пользователей о выпуске обновлений (включая обновления безопасности) и необходимости их установки.»
  • прямо 5.22.2.5«Разработать процедуру информирования пользователей ПО о выявленных уязвимостях и способах реализации мер по их нейтрализации до разработки обновлений безопасности, устраняющих уязвимость, по установленным каналам взаимодействия.»
Связка 5.20 → 5.21 по номеру не названа.
прописать

Что прописать в регламентах, чтобы контур замкнулся

  1. Включить «подтверждённую уязвимость из эксплуатации (5.23)» в события пересмотра требований (критерии 5.3.3.1), уточнения архитектуры (5.6.3.3), модели угроз и поверхности атаки (5.7.2.4, 5.7.2.5).
  2. Прописать передачу подтверждённой уязвимости в реестр недостатков и запросов на изменение (5.5.3.1, 5.5.3.3): идентификатор, версия, приоритет, статус.
  3. Обновлять вместе с моделью угроз и перечень мер нейтрализации (5.7.3.2) — в 5.7.2.4 и 5.7.2.5 он не входит.
  4. Добавить исправления уязвимостей в критерии повторного тестирования (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. Пропускать исправление через приёмку 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

Пять схем с трассировкой потоков, поиском, фокусом и экспортом (интерфейс просмотрщика — на английском).

Уязвимость из эксплуатации → 5.5 → 5.3·5.6·5.7 и повторный анализ → 5.20 → 5.21 → 5.22Открыть отдельно ↗

Матрица связей

Строка — процесс-источник, столбец — потребитель. Зелёная клетка — связь с номером пункта, сиреневая — без номера. Щелчок открывает потребителя на карте.

источник ↓ / потребитель →12345678910111213141516171819202122232425
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Инструменты композиционного анализа (проверка кода на секреты)