Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Что проверять на проекте: качество координат
Чек-лист аудитора. Тема узкая: не «есть ли SBOM вообще», а можно ли по нему вообще что-то найти — то есть достаточно ли точны и полны идентификаторы компонентов и уязвимостей.
- [ ] Покрытие PURL. Какая доля компонентов в SBOM имеет непустой
purl? Пустойpurl= компонент невидим для экосистемных сканеров. Особое внимание — C/C++ части. - [ ] Покрытие CPE. Какая доля компонентов имеет
cpe? Для C/C++ и системных библиотек CPE критичен, потому что PURL у них часто синтетический (pkg:generic/...). - [ ] Нормализация PURL. Нет ли в
purlприватных qualifiers (?repository_url=...,?user=..., внутренние registry)? Они уводят матчинг мимо публичных баз — проверяется через П24. PURL нормализация и private qualifiers. - [ ] Корректность версий. Версии нормализованы (нет лишнего
v, учтены эпохи deb, нет «latest»/диапазонов в поле точной версии)? Иначе ломается попадание в диапазон затронутых версий. - [ ] CPE-alias проверен. Для ключевых продуктов сверены vendor по словарю NVD (классический пример — curl:
haxx:curlvscurl:curl). Есть ли worklist расхождений — П25. CPE alias worklist? - [ ] Имя продукта в CPE ≠ имя пакета. Не подставлен ли в CPE
productпакетный artifactId вместо словарного имени NVD (например,log4j-coreвместоlog4j)? - [ ] Подключён БДУ ФСТЭК. Поиск ведётся не только по NVD/OSV, но и по БДУ ФСТЭК; учтено, что часть
BDU:YYYY-NNNNNне имеет CVE и сроки публикации расходятся. - [ ] «0 уязвимостей» проверено на ложный ноль. Есть ли процедура, подтверждающая, что нулевой результат означает «уязвимостей нет», а не «компоненты не попали в матчинг»? Хотя бы выборочная проверка координат.
- [ ] Список unresolved/unknown. Ведётся ли реестр компонентов без надёжной координаты (внутренние форки, статически слинкованные, vendored-исходники) с назначенным ответственным за доразметку?
- [ ] Связь уязвимость↔версия. Каждая находка привязана к конкретной версии компонента (а не к продукту в целом) и имеет идентификатор (CVE/GHSA/OSV/BDU)?
- [ ] Воспроизводимость координат. Зафиксированы инструмент, его версия, дата анализа и источник, по которому проставлена координата (чтобы расхождение можно было перепроверить)?
- [ ] Внутренние форки не приравнены к upstream. Форк с собственными патчами учтён как отдельная сущность, а не матчится автоматически по координате upstream.
Красный флаг аудита Отчёт «уязвимостей не найдено» при заметной доле компонентов с пустым
purl/cpe. Это почти всегда не безопасность, а пробел в координатах — false negative по построению. Требуйте измерить покрытие PURL/CPE прежде, чем доверять нулю.