Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

Конспект: SBOM и ППК как машинный источник фактов

Зачем модуль

Споры про безопасность ПО часто застревают на уровне «кажется, у нас где-то есть log4j, но какой версии — никто точно не знает». SBOM закрывает именно эту проблему: переводит вопрос «что у нас внутри» из устной легенды в машиночитаемый факт, который можно прочитать командой, а не созвоном. Но сам по себе факт ничего не решает — его легко перепутать с интерпретацией и с управленческим решением, и тогда SBOM либо игнорируют, либо превращают в свалку «красных» строк, которые невозможно закрыть. Модуль ставит навык: читать SBOM как доказательство, отделять его от выводов и понимать, зачем рядом с SBOM Организации нужен ППК.

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

Минимальные элементы — это контракт на полноту. NTIA в 2021 году зафиксировала семь базовых элементов, CISA их развивает: автор данных SBOM, имя поставщика компонента (supplier), имя компонента, версия, прочие уникальные идентификаторы (purl, CPE), отношения зависимости (dependency relationship) и временная метка. Если в файле нет версии или нет purl — это не «мелкая недоработка», а пробитый контракт: такой компонент нельзя сопоставить с уязвимостью автоматически. Свежий пример развития того же принципа — G7-руководство 2026 года по SBOM для ИИ-систем: оно отдельно выделяет кластер метаданных (автор SBOM, версия, формат и его версия, цифровая подпись автора, имя и версия инструмента, контекст генерации «before build / build / after build», timestamp) — то есть данные о самом артефакте, отдельно от данных о компонентах.

Факт → интерпретация → решение. Это разделение — главный мыслительный инструмент модуля. - Факт: pkg:npm/lodash@4.17.19 присутствует в сборке, хэш такой-то, источник — реестр такой-то. Это в SBOM. - Интерпретация: на эту версию есть CVE-2021-23337 (prototype pollution), severity high. Это получается сопоставлением SBOM с базой (OSV, NVD, БДУ ФСТЭК), и в SBOM это не записывают. - Решение: «обновляем до 4.17.21 до релиза» или «принимаем риск, путь не достижим» — с автором, датой и сроком пересмотра. Это вердикт человека или политики, и его место — в ППК и в реестре исключений, не в bom.json.

Почему ППК и SBOM дополняют друг друга. SBOM — одноразовый снимок одного коммита одним инструментом: он недолговечен, переснимается на каждой сборке и описывает только то, что увидел сканер. ППК (перечень программных компонентов в контролируемом репозитории Организации) — это долговечный учётный слой: дедуплицированный по purl, обогащённый владельцами компонентов, юридическими вердиктами по лицензиям, статусами уязвимостей и историей решений. SBOM отвечает на вопрос «что внутри этой сборки», ППК — «что мы вообще используем, кто за это отвечает и что мы про это решили». Поэтому в G7-документе прямо подчёркнуто: SBOM сам по себе безопасности не добавляет — он должен быть подключён к инструментам анализа уязвимостей. ППК и есть точка такого подключения на стороне Организации.

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

Минимальная проверка полноты прямо из CycloneDX JSON:

# сколько компонентов без purl — это «слепые» для сопоставления с CVE
jq '[.components[] | select(.purl == null)] | length' bom.json

# кто и чем сгенерировал SBOM (метаданные артефакта)
jq '.metadata | {timestamp, tools: .tools, authors: .authors}' bom.json
Минимальный элемент Где в CycloneDX Признак дефекта
Имя + версия components[].name, .version пустая или unknown версия
Идентификатор components[].purl / .cpe purl == null
Поставщик components[].supplier отсутствует у внешних пакетов
Зависимости dependencies[] граф пустой при множестве компонентов
Автор и timestamp metadata.authors, .timestamp нет — нельзя доказать происхождение

Слепые зоны именно этой темы - «SBOM есть» ≠ «SBOM полный». Файл присутствует, но половина компонентов без purl — анализатор находит подозрительно мало CVE, и это читают как хорошую новость. - Метаданные пустые. Нет автора, инструмента и timestamp — артефакт невозможно привязать к коммиту и сборке, на аудите он бесполезен. - Интерпретация просочилась в факт. В SBOM руками дописали severity или «принято» — теперь снимок состава нельзя пересоздать воспроизводимо. - SBOM перепутали с ППК. Каждую сборку складывают как новый файл, но никто не дедуплицирует и не ведёт владельцев — реестра Организации так и нет.

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

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

  1. Полнота SBOM измеряется не «есть файл / нет файла», а долей компонентов с purl, версией и поставщиком — это считается одной командой jq.
  2. В SBOM хранится только факт; severity, вердикты и принятие риска — в ППК и реестрах, не в bom.json.
  3. Метаданные (автор, инструмент, timestamp, контекст генерации) обязательны — без них артефакт недоказуем на аудите.
  4. ППК нужен отдельно от SBOM как долговечный обогащённый реестр; SBOM в него загружают и дедуплицируют.
  5. Закрепить минимум полей и порог качества в договорённостях: Минимальный набор полей ППК, Соглашение о качестве данных SBOM.

Практика: П02. Чтение CycloneDX JSON руками.