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

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

private Conan qualifiers

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

Когда компонент пришёл из Conan, его PURL несёт не только имя и версию, но и приватные qualifiers: user, channel, recipe revision (rrev), package revision (prev). Пример: pkg:conan/zlib@1.3.1?user=org&channel=stable&rrev=ab12.... Эти поля точно описывают, откуда именно собрался пакет в приватном репозитории, и это ценно для provenance. Но ровно эти же поля ломают матчинг на публичные источники уязвимостей: ни NVD, ни БДУ ФСТЭК не знают про ваш user=org&channel=stable, и попытка найти CVE по PURL целиком даёт ноль совпадений там, где уязвимость на самом деле есть.

То есть приватные qualifiers создают вилку: для трассируемости их нужно сохранять, а для сопоставления с уязвимостями — отбрасывать. SCA-конвейер обязан уметь и то, и другое одновременно.

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

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

PURL Назначение Матчинг на NVD/БДУ
pkg:conan/openssl@3.2.1?user=org&channel=stable&rrev=ab12cd provenance: точный пакет из приватного репо не находит (qualifiers не знакомы)
pkg:conan/openssl@3.2.1 (нормализованный) сопоставление с публичными источниками находит CVE/CPE по openssl 3.2.1

Где живут qualifiers

conan graph info . --format=json | jq '.graph.nodes[].ref'
# zlib/1.3.1@org/stable#ab12cd...

Запись name/version@user/channel#rrev — это и есть источник приватных полей PURL. @org/stable → ?user=org&channel=stable, #ab12cd → ?rrev=ab12cd.

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

Слепая зона — «тихий ноль»: сканер прогоняет PURL с приватными qualifiers, не находит уязвимостей и помечает компонент чистым, хотя на деле просто не было совпадения по ключу. Это ложноотрицательный результат, который выглядит как успешная проверка.

Нормализация для матчинга, оригинал для provenance Храните две формы PURL. Полную (с user/channel/rrev/prev) — в evidence и в поле bom-ref для трассируемости. Нормализованную (только pkg:conan/<name>@<version>) — для запроса к NVD/БДУ. Никогда не подменяйте одну другой молча: иначе теряется либо provenance, либо findings.

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

  1. Для каждого Conan-компонента сохраните полный PURL c приватными qualifiers как evidence/identity.
  2. Перед матчингом на уязвимости стройте нормализованный PURL: отбросьте user, channel, rrev, prev, оставьте тип/имя/версию.
  3. Дополнительно сформируйте CPE-кандидат по name+version — многие источники матчатся по CPE, а не по PURL.
  4. Проверьте, что «ноль findings» по приватному PURL не маскирует реальную уязвимость: перепроверьте по нормализованной форме.
  5. Зафиксируйте правило нормализации в политике конвейера, чтобы оно применялось ко всем приватным экосистемам единообразно.
  6. Если по нормализованному PURL всё равно нет совпадений (форк, патч), переводите компонент в worklist ручной доразметки.

Связь