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

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

honest SBOM

Почему это важно для SCA/OSA

«Честный SBOM» — это про разрыв между тем, что декларируется в поставляемом bom.json, и тем, что реально лежит в артефакте. Поставщик может приложить аккуратный CycloneDX, сгенерированный на чистой dev-машине, тогда как образ, который реально едет заказчику, собран иначе: с другими версиями .so, с забытым vendored-кодом, с лишними слоями. SBOM в этом случае формально валиден, но не соответствует поставке. Задача composition analysis — не доверять декларации, а проверять её сходимость с независимо извлечёнными фактами.

Как это проявляется

Честность проверяется дифом: сгенерировать SBOM независимо из самого артефакта (с полным охватом слоёв) и сравнить множества компонентов с тем, что прислал поставщик.

# что прислал поставщик
jq -r '.components[] | "\(.name)@\(.version)"' supplier-bom.json | sort > declared.txt

# что реально в образе (все слои, не верхняя проекция)
syft myapp:1.4 --scope all-layers -o cyclonedx-json > actual-bom.json
jq -r '.components[] | "\(.name)@\(.version)"' actual-bom.json | sort > actual.txt

diff declared.txt actual.txt
# < openssl@3.0.2        <-- объявлено, но в образе 3.0.13 (расхождение версии)
# > zlib@1.2.11          <-- реально присутствует, но в декларации нет
# > libcurl@7.68.0       <-- vendored, не попал в декларацию

Любая строка > (есть в образе, нет в декларации) — недекларированный компонент; любая < — призрак, заявленный, но отсутствующий. Расхождение версий по одному имени — отдельный класс дефектов.

Слепая зона или приём

Честность = сходимость двух независимых источников SBOM считается честным, когда декларация воспроизводится из артефакта при независимой генерации. Один источник (только поставщикский файл или только верхняя ФС) доказательством не является — нужны оба и их совпадение в пределах объявленного допуска.

Слепая зона: генерация SBOM по dev-окружению вместо релизного артефакта. Тогда декларация описывает «как собирали у себя», а не «что отгрузили».

Что делать на проекте

  1. Принимать SBOM только вместе с артефактом, к которому он относится, и сверять хеш артефакта.
  2. Независимо генерировать SBOM из самого артефакта с --scope all-layers и делать diff множеств компонентов.
  3. Расхождения раскладывать на классы: недекларированный компонент, призрак, расхождение версии — и для каждого требовать объяснение.
  4. Проверять покрытие минимальных элементов (имя, версия, поставщик, идентификатор, отношения, автор SBOM, timestamp) по CISA/BSI.
  5. Недоказанные записи помечать пониженным confidence и отправлять в worklist доразметки, а не молча принимать.
  6. Закрепить «критерий честности» в quality gate: поставка проходит, только если diff в пределах объявленных исключений.

Связь