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

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

CPE alias для libssl3

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

Матчинг на NVD идёт по строке CPE вида cpe:2.3:a:<vendor>:<product>:<version>:.... Проблема в том, что у одного и того же продукта в NVD CPE Dictionary исторически живёт несколько разных написаний vendor:product, а имя бинарного артефакта (libssl3, libssl.so.3) вообще не совпадает ни с одним из них. OpenSSL встречается и как openssl:openssl, и как openssl_project:openssl; уязвимости при этом могут быть привязаны к одному alias, а ваш SBOM нести другой. Тогда матчинг не находит CVE — и это не ошибка инструмента, а штатная тишина: findings приходит подозрительно мало.

Для C/C++ это бьёт сильнее, чем для экосистемных языков: системный пакет называется libssl3 (Debian/Ubuntu) или openssl-libs (RPM), upstream-проект — openssl, а в NVD продукт — openssl под двумя vendor. Между «именем .so», «именем пакета» и «CPE-продуктом» нет автоматического моста, его строят руками.

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

Пакет в системе и его upstream-имя расходятся, а NVD знает только третье написание:

$ dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.3
libssl3:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.3
$ apt-cache show libssl3 | grep -E '^(Package|Version|Source)'
Package: libssl3
Version: 3.0.11-1~deb12u2
Source: openssl            # ← upstream-имя, а не libssl3

В NVD CPE Dictionary тот же продукт имеет минимум два vendor:

cpe:2.3:a:openssl:openssl:3.0.11:*:*:*:*:*:*:*
cpe:2.3:a:openssl_project:openssl:3.0.11:*:*:*:*:*:*:*

Если генератор SBOM подставил CPE по имени пакета (libssl3) или взял только один alias, часть CVE OpenSSL к компоненту не привяжется. При этом доля версий в CVE задаётся диапазонами (versionStartIncluding/versionEndExcluding), поэтому даже верный alias с неточной версией даст пропуск.

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

Слепая зона — «один компонент, один CPE». Реальная идентичность libssl3 — это связка имя .so → имя deb-пакета → Source-пакет → upstream-проект → набор CPE alias в NVD. Приём: для критичных сетевых библиотек (openssl, libcurl, libxml2) вести не единственный CPE, а список всех известных alias и проверять, к какому из них привязаны нужные CVE. Один зафиксированный alias = потенциальный false negative.

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

  1. Выгрузить из SBOM C/C++ компоненты с пустым cpe, но известным именем/PURL — это вход в alias-worklist.
  2. Для каждого восстановить цепочку: dpkg -S / rpm -qf → apt-cache show ... | grep Source (или rpm -qi) → upstream-имя.
  3. По upstream-имени найти в NVD CPE Dictionary все записи vendor:product, а не первую; зафиксировать alias списком.
  4. Сверять не точную строку версии, а попадание версии в уязвимый диапазон CVE.
  5. Приоритизировать: сетевые/криптобиблиотеки размечать первыми, внутренние помечать CPE отсутствует (internal).
  6. Хранить worklist как передаваемый артефакт со статусом и приоритетом — NVD добавляет и депрекейтит записи, разовая правка устаревает.

Связь