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

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

SBOM evidence occurrences

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

В экосистемных языках источник компонента очевиден — строка в lock-файле. В C/C++ компонент часто появляется в SBOM по косвенным признакам: символ в бинаре, путь к .so, строка версии в секции .comment, совпадение хеша. Без записанного доказательства такая запись неотличима от догадки генератора. CycloneDX закрывает это полем evidence с подполями occurrences (где физически найден компонент) и identity (на каком основании присвоены имя и версия, с confidence). Это превращает SBOM из списка имён в доказательную базу: для каждой записи видно, откуда она и насколько ей можно верить.

Для аудита это ключевое отличие «честного» SBOM от декоративного. Запись OpenSSL 3.0.11 без evidence — утверждение; та же запись с occurrence-путём к libssl.so.3 и identity-методом binary-symbol — проверяемый факт. Именно по наличию evidence сервис аудита/вердиктов отделяет findings, которые можно эскалировать, от тех, что требуют доразметки.

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

Компонент с доказательствами происхождения и оценкой достоверности:

{
  "type": "library", "name": "openssl", "version": "3.0.11",
  "purl": "pkg:deb/debian/libssl3@3.0.11-1~deb12u2?arch=amd64",
  "evidence": {
    "identity": [{
      "field": "version", "confidence": 0.8, "methods": [
        { "technique": "binary-analysis", "confidence": 0.8,
          "value": "OpenSSL 3.0.11 19 Sep 2023" }]
    }],
    "occurrences": [
      { "location": "usr/lib/x86_64-linux-gnu/libssl.so.3" },
      { "location": "opt/app/bin/service" }
    ]
  }
}

Из этой записи аудитор читает: компонент найден в двух местах (системная .so и сам бинарь, который её тянет), версия восстановлена из строки в бинаре с confidence 0.8 — не из манифеста, значит подтверждать дополнительно. Запись без блока evidence такой трассировки не даёт: непонятно, реально ли это OpenSSL или совпадение имени.

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

Слепая зона — равнять записи с доказательством и без. Генератор может выдать confidence: 1.0 там, где компонент извлечён из манифеста, и низкий — там, где из бинаря; если отчёт игнорирует confidence, обе строки выглядят одинаково надёжными. Приём: использовать occurrences и identity.confidence как фильтр и как worklist. Низкий confidence или отсутствие occurrence — повод для ручной доразметки, а не для тихого включения в итоговый список.

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

  1. Включить сбор evidence в генераторе (для cdxgen — режим с --evidence/глубоким анализом), не ограничиваться плоским списком имён.
  2. Проверить, что у системных и статически вшитых компонентов заполнены occurrences (путь к .so/архиву/бинарю) и identity.methods.
  3. Отсортировать компоненты по identity.confidence: низкий — в worklist доразметки.
  4. Сверять occurrences с реальностью: путь должен указывать на существующий артефакт в поставке, а не на промежуточный build-каталог.
  5. Записи без evidence трактовать как неподтверждённые: либо доказать происхождение, либо понизить их статус в отчёте.
  6. Хранить evidence как аудиторский след: он отвечает на вопрос «откуда вы знаете, что здесь OpenSSL 3.0.11».

Связь