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

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

OWASP Dependency-Check

Для чего

Dependency-Check — ветеран SCA, который работает не по lockfile, а через эвристику: анализаторы извлекают «улики» (Evidence) из артефактов — имена пакетов, версии, теги манифестов, метаданные JAR/DLL — и строят из них CPE, после чего матчат собранную локально копию NVD. Поэтому он умеет находить уязвимости даже там, где явного манифеста зависимостей нет, ценой более шумного результата.

Как применяют

Запускается как CLI, плагин Maven/Gradle или образ. Ключевой нюанс — первичная загрузка NVD требует API-ключа NVD (иначе крайне медленно):

Команда

dependency-check.sh \
  --project "my-service" \
  --scan ./ \
  --nvdApiKey "$NVD_API_KEY" \
  --format SARIF --format JSON \
  --failOnCVSS 7

Подавление FP — отдельный XML-файл, который подключают флагом --suppression suppress.xml:

Фрагмент suppression.xml

<suppress>
  <notes>FP: vendored copy, not exploitable</notes>
  <packageUrl regex="true">^pkg:maven/com\.example/.*$</packageUrl>
  <cve>CVE-2021-12345</cve>
</suppress>

Матчит компонент через CPE вида cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*; на входе — Java, .NET, JS/npm, Python, Ruby и ряд других через соответствующие анализаторы.

Сильные стороны

Evidence-based подход находит зависимости без манифеста (вложенные JAR, упакованные DLL) — там, где lockfile-сканеры слепы.
Глубокая интеграция в Java-экосистему: зрелые плагины Maven/Gradle/Ant, привычный отчёт в CI.
Локальная копия NVD: после первичной синхронизации матчинг идёт офлайн и воспроизводимо.
Гибкое подавление через suppression-XML с regex по PURL/CPE/CVE и пороговый гейт --failOnCVSS.

Ограничения

Высокий уровень FP/FN из-за эвристического построения CPE: «угаданный» вендор/продукт может дать как ложное срабатывание, так и пропуск.
Привязан к NVD как почти единственному источнику; с ростом задержек и реформой NVD актуальность данных страдает, БДУ ФСТЭК и EPSS не учитываются.
Первичная синхронизация NVD тяжёлая и без API-ключа практически непригодна для CI.
Для нативного C/C++ покрытие ограничено: без распознаваемых метаданных артефакта улик для CPE недостаточно.

Offline / on-premise

Частично. Данные NVD кэшируются локально (каталог data/), и его можно наполнять из внутреннего зеркала через --nvdDatafeed (офлайн-фиды) или общий каталог БД, после чего сканирование идёт без интернета. Полностью автономен только после первичного наполнения кэша; в закрытом контуре нужен регламент обновления фидов и host-/CPE-словарей.

Связанные темы

М06 Поиск уязвимостей и VDR/VEX · М04 Идентификаторы компонентов и уязвимостей Практика: П25. CPE alias worklist · П34. SBOM quality gate Смежные карточки: CPE · NVD · OWASP Dependency-Track · Grype · OSV-Scanner