Практическая работа: координаты компонентов и эффект битого PURL

Цель

Собрать корректные координаты (PURL, CPE, идентификаторы уязвимостей) для четырёх компонентов и на собственном опыте увидеть, как порча координаты превращает уязвимый компонент в «чистый» в отчёте сканера.

Что понадобится

• стенд из П01 (Docker, доступ в сеть к публичным базам);
• osv-scanner (см. П07);
• доступ к NVD CPE Search (nvd.nist.gov/products/cpe/search), osv.dev, БДУ ФСТЭК (bdu.fstec.ru).

Часть 1. Таблица координат (4 компонента)

Заполните таблицу для OpenSSL, zlib, libcurl и одной внутренней библиотеки Организации. Версии берите фиксированные (как в реальном релизе).

Где брать значения PURL экосистемного пакета часто берётся из самого SBOM. Для C/C++ компонента CPE приходится искать вручную: вбейте product в NVD CPE Search и посмотрите, под какими vendor он зарегистрирован. Для libcurl специально проверьте обе формы — haxx:curl и curl:curl.

Шаги

1. Зафиксируйте вход: компонент, версию, дату анализа, версии инструментов.
2. Для каждого компонента найдите PURL и проверьте его в osv.dev → выпишите CVE/GHSA.
3. Найдите CPE в NVD CPE Search; для libcurl зафиксируйте обе vendor-формы (alias).
4. Проверьте каждый CVE по БДУ ФСТЭК — выпишите BDU:YYYY-NNNNN, где есть; отметьте записи без CVE.
5. Для внутренней библиотеки решите: есть ли публичная координата вообще; если нет — пометьте как «unresolved, требует ручной разметки».

Часть 2. Эксперимент «битый PURL → тихий ноль»

1. Возьмите lockfile или manifest с заведомо уязвимым пакетом (например, устаревший npm/PyPI). Запустите базовый скан:

osv-scanner scan source --lockfile=package-lock.json

Зафиксируйте число находок (например, N уязвимостей).

2. Смоделируйте порчу координаты. В SBOM (CycloneDX JSON) у этого компонента добавьте приватный qualifier и/или измените type, затем прогоните скан по SBOM:

# было:  pkg:npm/lodash@4.17.20
# стало: pkg:npm/lodash@4.17.20?repository_url=https://nexus.internal/repo
osv-scanner scan --sbom=bom.cdx.json

3. Сравните: число находок упало (часто до нуля по этому компоненту), при этом скан завершился без ошибок. Запишите результат.

4. Снимите приватный qualifier (нормализуйте PURL по правилам П24. PURL нормализация и private qualifiers) и повторите — находки должны вернуться.

Главный вывод части 2 Снижение числа находок не сопровождается ошибкой. Это и есть механизм false negative: компонент «выпал» из матчинга, а отчёт выглядит благополучно.

Ожидаемый результат

• Заполненная таблица из 4 строк с PURL, CPE (для libcurl — две vendor-формы), CVE/GHSA и BDU.
• Зафиксированная пара чисел находок: до порчи PURL и после, плюс восстановление после нормализации.
• Короткий вывод (3–5 строк): какие компоненты остались без надёжной координаты и что отправить в worklist.

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

• osv-scanner находит ноль на чистом проекте — проверьте, что lockfile реальный и пакет действительно уязвимой версии; возможно, версия уже пропатчена.
• CPE не находится в NVD — продукт может быть под другим vendor (alias) или вообще без записи в словаре; это нормальный результат для C/C++ — фиксируйте в П25. CPE alias worklist.
• После порчи PURL находок столько же — вероятно, сканер взял координату не из изменённого поля; убедитесь, что меняете именно тот purl, по которому идёт матчинг.
• БДУ пусто, а CVE есть — нормально: часть CVE не имеет записи в БДУ и наоборот; так и фиксируйте.

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

Показать преподавателю: (1) таблицу координат с alias для libcurl; (2) воспроизведённый эффект «битый PURL → падение находок → восстановление после нормализации» с конкретными числами; (3) список unresolved-координат.

Практики

• П24. PURL нормализация и private qualifiers
• П25. CPE alias worklist
• П07. OSV-Scanner и lockfiles
• П10. БДУ ФСТЭК как национальный источник

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

NIST SP 800-218 SSDF RV.1 (поиск уязвимостей опирается на корректную идентификацию), CISA Minimum Elements for SBOM (уникальные идентификаторы), BSI TR-03183-2 v2.1.0 (качество SBOM), БДУ ФСТЭК.