Конспект: нормативная трассировка и доказательная база

Зачем модуль

Организация уже умеет генерировать SBOM, сканировать уязвимости и считать лицензии. Но когда приходит аудитор (внутренний, заказчик или регуляторный), он задаёт не вопрос «есть ли у вас инструмент SCA», а вопрос «покажите, что требование номер такой-то выполняется, и докажите это документом». Между требованием стандарта и папкой с отчётами лежит разрыв: формулировка ГОСТа абстрактна, а артефакт инструмента — это JSON, не привязанный к пункту нормы. Этот модуль закрывает разрыв: учит строить трассировку — однозначную цепочку требование → практика → артефакт, где каждое звено воспроизводимо и датировано.

Без такой трассировки происходит типичная авария аудита: процесс реально работает, но защититься нечем — никто не может за пять минут сопоставить пункт «контроль и актуализация ППК» с конкретным файлом VDR за конкретный релиз.

Ключевые идеи

1. Evidence ≠ артефакт «вообще». Evidence — это артефакт с фиксированными атрибутами трассировки. Один и тот же CycloneDX-файл становится доказательством только когда у него есть: дата генерации (timestamp), идентичность создателя (creator), версия продукта, версия инструмента и место хранения. BSI TR-03183-2 прямо требует для самого SBOM минимум двух полей — Creator of the SBOM и Timestamp (§5.2.1), а для каждого компонента — creator, name, version, dependencies, distribution licences и набор свойств (§5.2.2). Файл без этих полей формально не является конформным SBOM, а значит и не работает как evidence.

2. Разделение статики и динамики — стержень доказательной базы. BSI TR-03183-2 формулирует это как норму: SBOM статичен относительно неизменного ПО и MUST NOT содержать сведений об уязвимостях (§3, §8.1.14), потому что уязвимости динамичны и при включении в SBOM бессмысленно тиражировались бы по цепочке поставки. Следствие для трассировки: «выполнили КАПО» нельзя доказать одним SBOM. Нужны два класса artefacts — статический инвентарь (SBOM) и динамическая оценка применимости (VEX/CSAF/VDR). Рекомендованный BSI формат раздачи сведений об уязвимостях — CSAF, профилем которого является VEX.

3. Класс SBOM — это тип evidence. BSI §8.4 различает Design / Source / Build / Analysed / Deployed / Runtime SBOM. Для аудита важно, что Build SBOM строится по прогону линковщика, а не компилятора (§8.4.3) — это ровно то доказательство, которого требует C/C++ legacy, где #include ничего не говорит о фактически слинкованной версии.

4. Язык требований различает уровни доказанности. BSI опирается на RFC 2119, причём ключевые слова считаются нормативными, только когда написаны заглавными (§2). Это позволяет отделить обязательный evidence от рекомендованного. Поля §5.2 — это MUST: без creator, timestamp и координат компонента SBOM неконформен и доказательством не является. А цифровая подпись SBOM описана в пояснительном приложении (§8.1.15) фразой «ideally … should be digitally signed» — это не нормативный SHOULD, а рекомендация: её отсутствие не делает SBOM неконформным, но снижает доказательную силу артефакта при аудите.

Как выглядит на практике: матрица маппинга

Спина трассировки — требования КАПО из ГОСТ Р 56939-2024, разложенные на практики SSDF и нормы BSI.

Слепые зоны именно этой темы - Маппинг 1:1 не существует. ГОСТ Р 56939-2024 описывает процесс, SSDF — практики, BSI — формат документа. Они пересекаются, но не накрывают друг друга: у BSI нет аналога «регламента», у ГОСТа нет требований к полям JSON. Натягивать строгое соответствие — ошибка; маппинг показывает где искать evidence, а не доказывает эквивалентность норм. - Точные ID практик SSDF меняются между ревизиями. В матрице — ориентиры; для аудита ID сверяют с официальной таблицей NIST. - «Есть артефакт» ≠ «есть трассировка». Папка с 200 SBOM без привязки к версии продукта и пункту требования не проходит аудит: невозможно ответить, какой файл доказывает какой контроль за какой релиз. - VEX без SBOM и issuer не самодостаточен. Вердикт «не применимо» бессмыслен без статического инвентаря, к версии компонента в котором он привязан, и без автора решения для продукта. См. VEX в процессе РБПО.

Связь с нормативкой

ГОСТ Р 56939-2024 и Проект ГОСТ Р КАПО задают пять требований КАПО (регламент, формирование ППК, контроль/актуализация, анализ на поверхности атаки, корректирующие воздействия). NIST SP 800-218 SSDF даёт практики PS.3.2/PW.4/RV.1/RV.2. BSI TR-03183-2 v2.1.0 задаёт, что именно делает документ конформным evidence (поля §5.2, форматы CycloneDX ≥1.6 / SPDX ≥3.0.1, запрет vuln-данных в SBOM). CISA Minimum Elements for SBOM — внешний минимум полей. Шаблоны: Матрица evidence для аудита, Журналирование и audit trail.

Что уносим в работу

1. Завести единую матрицу требование → практика → артефакт → владелец → где хранится как живой документ, а не разовый отчёт (шаблон).
2. Для каждого контроля назвать тип evidence по классификации BSI §8.4 (Build SBOM для C/C++, не Source).
3. Никогда не смешивать SBOM и vuln-данные как один слой ответственности: даже если CycloneDX технически хранит vulnerabilities[].analysis, VEX должен иметь issuer, evidence и срок пересмотра (справка, П09, П35).
4. Проверять каждый артефакт на минимальные поля трассировки до того, как назвать его доказательством (П34).
5. Закрепить хранение и датирование артефактов так, чтобы строку матрицы можно было воспроизвести на следующем релизе (П29).