Как читать авторский курс и нормативные материалы

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

П24. PURL нормализация и private qualifiers

Цель

Привести «грязные» PURL C/C++ компонентов (с приватными Conan-полями user/channel и нестандартным регистром) к каноничной форме, пригодной для публичного матчинга на OSV/NVD. Проверяемый результат: таблица «исходный PURL → нормализованный PURL → что отброшено» минимум на 5 компонентов и явная пометка тех PURL, которые после чистки совпали с публичной координатой.

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

Это ручная нормализация по спецификации PURL — без отдельного инструмента. Правила для типа conan и приватных qualifiers:

1. Отбросить приватные qualifiers, которых нет в публичном индексе:
   ?user=mycorp  ?channel=stable  ?rrev=...  ?prev=...  (Conan recipe/package revision)
2. Сохранить только различающие qualifiers (например ?arch=amd64 для deb).
3. type и namespace — в нижний регистр; имя пакета привести к канону экосистемы.
4. Версию оставить как есть (она различающая), но отделить от revision-метаданных.

pkg:conan/OpenSSL@3.2.1?user=mycorp&channel=stable   ->  pkg:conan/openssl@3.2.1
pkg:conan/zlib@1.3.1#rrev=abcdef                       ->  pkg:conan/zlib@1.3.1
pkg:deb/debian/libssl3@3.0.11-1~deb12u2?arch=amd64     ->  без изменений (arch различающий)

Почему приватные qualifiers ломают матчинг OSV и публичные сканеры ищут точное совпадение строки PURL. pkg:conan/openssl@3.2.1?user=mycorp для них — другой компонент, чем pkg:conan/openssl@3.2.1, поэтому уязвимости OpenSSL к нему не привяжутся. Приватные поля сужают идентичность до вашего реестра и невидимо отключают публичный матчинг — классический false negative модуля М04.

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

Заполненную таблицу нормализации:

Исходный PURL	Нормализованный PURL	Отброшено	Совпал с публичным?
`pkg:conan/OpenSSL@3.2.1?user=mycorp&channel=stable`	`pkg:conan/openssl@3.2.1`	`user`, `channel`, регистр имени	да
`pkg:conan/zlib@1.3.1#rrev=ab12cd`	`pkg:conan/zlib@1.3.1`	recipe revision	да
`pkg:generic/customnet@1.0`	`pkg:generic/customnet@1.0`	—	нет (внутренний компонент)
`pkg:deb/debian/libcurl4@7.88.1-10?arch=amd64`	`pkg:deb/debian/libcurl4@7.88.1-10?arch=amd64`	—	да

Ориентир: после чистки доля PURL, совпавших с публичной координатой, должна заметно вырасти. Компоненты pkg:generic/... без апстрима так и останутся внутренними — это нормально, их версионируете и отслеживаете сами.

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

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

После чистки PURL всё равно не находит уязвимостей. Проверьте не qualifiers, а само имя: канон может отличаться (openssl против OpenSSL против pkg:conan/openssl против pkg:cargo/...). Сверьте имя по публичному индексу экосистемы.
Удалили arch у deb и сломали совпадение. arch — различающий qualifier, его отбрасывать нельзя. Приватные (user, channel, rrev, prev) — да; различающие (arch, distro) — оставлять.
Не понятно, какие qualifiers приватные. Приватные — те, которых нет в публичном индексе и которые указывают на ваш реестр/ревизию. Если qualifier влияет на то, какой именно артефакт скачается из публичного источника, он различающий; если только на ваш внутренний путь — приватный.
Компонент вообще без апстрима (pkg:generic). Нормализовать не к чему — это внутренняя библиотека. Не выдумывайте публичный PURL; ведите её как внутренний компонент с собственной версией.

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

Показать преподавателю: таблицу нормализации минимум на 5 C/C++ компонентов с колонками «исходный → нормализованный → отброшено → совпал ли публично», и устно объяснить на одном примере, какой именно приватный qualifier отключал матчинг и почему его безопасно отбросить (а какой — нельзя).

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

Канонический PURL — это полнота и точность идентификаторов SBOM по BSI TR-03183-2 v2.1.0 и базовый элемент по CISA Minimum Elements for SBOM. Без него RV.1 NIST SP 800-218 SSDF (поиск уязвимостей в компонентах) даёт ложную тишину. Это ядро модуля М04. Смежные практики: П21. Conan graph и package identity (откуда берётся грязный PURL), П25. CPE alias worklist (вторая координата — CPE). Шаблон: Соглашение о качестве данных SBOM.