П25. CPE alias worklist

Цель

Составить рабочий список C/C++ зависимостей, у которых нет CPE (а значит, нет матчинга на NVD), и для каждой подобрать корректный CPE с учётом alias-проблемы (один продукт — несколько разных vendor:product). Проверяемый результат: таблица-worklist «компонент → найденный CPE → альтернативные написания vendor/product → статус», отсортированная по приоритету.

Команда или действие

Это аналитическая практика без инструмента: вы вручную сверяете компоненты с форматом CPE 2.3 и ищете совпадения в NVD CPE Dictionary. Алгоритм worklist:

1. Выгрузить из SBOM C/C++ компоненты, у которых cpe == пусто (но есть purl/имя).
2. Для каждого — найти в NVD CPE Dictionary кандидатов по имени продукта.
3. Зафиксировать ВСЕ варианты vendor:product (alias!), а не первый попавшийся.
4. Проставить приоритет: критичные/сетевые библиотеки (openssl, libcurl) — выше.
5. Собрать рабочий CPE-шаблон cpe:2.3:a:<vendor>:<product>:<version>:*:*:*:*:*:*:*

Alias-проблема CPE У одного продукта в NVD исторически бывает несколько vendor:product. OpenSSL встречается и как openssl:openssl, и как openssl_project:openssl; для других библиотек vendor мог меняться при смене мейнтейнера. Если в SBOM записан один alias, а CVE привязан к другому — находка теряется. Поэтому в worklist фиксируют не один CPE, а все известные написания.

Что вы должны увидеть

Worklist в виде таблицы:

Ориентир: worklist охватывает все C/C++ компоненты без CPE из вашего SBOM; для публичных OSS у каждого должен появиться хотя бы один CPE-кандидат, для внутренних — пометка «CPE отсутствует, internal». Строки с несколькими alias — самые ценные: именно они закрывают потенциальные false negative.

Зачем worklist, а не разовая правка CPE проставляется руками и устаревает: NVD добавляет/депрекейтит записи. Worklist с приоритетом и статусом — это передаваемый артефакт для сервиса аудита/вердиктов, а не разовое действие. Критичные сетевые библиотеки размечаются первыми.

Если не получилось

• В NVD нашлось несколько vendor:product для одного продукта — не знаю, какой брать. Это и есть alias-проблема: берите все и проверяйте, к какому из них привязаны нужные CVE. В worklist оставляйте основной + альтернативные, а не выбирайте один наугад.
• Для библиотеки вообще нет CPE в NVD. Бывает для нишевых OSS и почти всегда для внутренних форков. Помечайте CPE отсутствует; для матчинга на уязвимости остаётся PURL→OSV (П24. PURL нормализация и private qualifiers) и ручное наблюдение.
• Версия в CPE не матчится, хотя vendor/product верные. CPE-матчинг чувствителен к формату версии и к диапазонам в CVE (versionStartIncluding/versionEndExcluding). Сверяйте не точную строку, а попадание версии в уязвимый диапазон.
• CPE взят для другого продукта с похожим именем. Частая ошибка: zlib против постороннего *zlib*-пакета. Проверяйте по описанию записи в CPE Dictionary, а не только по имени.

Критерий зачёта

Показать преподавателю: worklist по всем C/C++ компонентам без CPE из учебного SBOM, где для публичных библиотек заполнены CPE и альтернативные alias, проставлен приоритет и статус, а внутренние помечены CPE отсутствует. Отдельно объяснить на примере OpenSSL, как два разных alias могли бы привести к пропуску CVE.

Нормативная связка

Полнота и корректность CPE — условие матчинга на NVD и БДУ ФСТЭК; без них RV.1 NIST SP 800-218 SSDF (поиск уязвимостей в компонентах) даёт false negative. Качество идентификаторов SBOM — критерий BSI TR-03183-2 v2.1.0; alias-проблема CPE — ядро модуля М04. Смежные практики: П24. PURL нормализация и private qualifiers (вторая координата — PURL), П23. Статическая линковка как слепая зона и П22. ELF dynamic dependencies (откуда берутся безымянные C/C++ компоненты). Шаблон: Реестр unresolved libraries.