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

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

detection accuracy

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

В C/C++ точность обнаружения — это не «сколько уязвимостей нашли», а «какую долю реально присутствующих компонентов мы вообще увидели и верно скоординировали». Здесь два разных провала. Первый — компонент не попал в SBOM (статическая линковка, vendored-код, stripped-бинарь) — провал полноты (recall). Второй — компонент в SBOM есть, но координата битая (generic-PURL, не тот CPE-alias, ненормализованная версия) — провал точности координаты. Оба дают один и тот же видимый симптом: подозрительно мало findings. И оба опасны именно тем, что выглядят как «всё чисто».

Самый дорогой исход в SCA — не false positive (его видно и можно отклонить), а false negative из-за невидимого компонента или битой координаты: уязвимость есть, а инструмент молчит. Поэтому «accuracy» здесь измеряют не точностью срабатываний, а способностью доказать, что нулю findings можно верить.

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

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

метод обнаружения          OpenSSL  zlib(static)  внутр. форк  итог покрытия
скан готового бинаря        cpe?       —             —          частично
ldd / readelf -d (.so)      да         —             —          только динамика
build-scan (перехват CC)    да         да            да         полно

Статически слинкованная zlib не видна ни в ldd, ни в готовом SBOM от позднего скана — её ловит только перехват вызовов компилятора на этапе сборки. То есть точность напрямую зависит от метода: поздний скан бинаря систематически недосчитывает статику и vendored-код.

# симптом провала полноты: cdxgen нашёл мало C/C++ компонентов
$ jq '[.components[] | select(.purl|startswith("pkg:generic"))] | length' bom.json
7     # семь generic — кандидаты на потерю матчинга
$ jq '[.components[] | select(.purl==null)] | length' bom.json
3     # три компонента вообще без координаты

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

Слепая зона — измерять точность по числу findings. Малое число находок одинаково означает и «чисто», и «мы не туда смотрели». Приём: оценивать accuracy через прокси-метрики качества данных — доля компонентов с валидным PURL, доля с CPE, доля с evidence/высоким confidence, число pkg:generic и записей без координаты. Контрольный приём — намеренно сломать координату известного компонента и убедиться, что findings для него пропадает: это показывает, что матчинг вообще работает и насколько он хрупок.

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

  1. Различать два провала: полнота (компонент не в SBOM) и точность координаты (компонент есть, координата битая) — лечатся они по-разному.
  2. Для полноты — переносить обнаружение на этап сборки (build-scan), а не на поздний скан бинаря; статику/vendored иначе не увидеть.
  3. Считать прокси-метрики: доля валидных PURL/CPE, число generic и записей без координаты, доля записей с evidence.
  4. Прогонять контрольный эксперимент «битая координата → пропавшие находки», чтобы доказать, что матчинг живой.
  5. Записи с низким confidence/без evidence держать в worklist доразметки, а не в итоговом «чистом» списке.
  6. Трактовать «ноль уязвимостей» как гипотезу, требующую доказательства полноты, а не как результат.

Связь