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

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

OpenVEX

Для чего

OpenVEX — минималистичный формат VEX-утверждений (Vulnerability Exploitability eXchange): он отвечает не на вопрос «есть ли в составе уязвимый компонент», а на вопрос «эксплуатируема ли эта уязвимость в нашем продукте». Это инструмент гашения шума: сканер нашёл CVE в зависимости, OpenVEX-документ заявляет not_affected с обоснованием — и находка обоснованно снимается. В отличие от тяжёлого CSAF, это отдельный компактный JSON-LD. Смысл issuer и evidence разобран в VEX в процессе РБПО.

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

Документ — JSON-LD с массивом statements, каждое связывает уязвимость, продукт и статус:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "author": "Организация",
  "statements": [{
    "vulnerability": { "name": "CVE-2024-0001" },
    "products": [{ "@id": "pkg:conan/openssl@3.0.13" }],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

Статус — ровно одно из четырёх значений: not_affected, affected, fixed, under_investigation. Ключевое правило: статус not_affected обязан нести обоснование — либо justification из фиксированного перечня (component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist), либо текстовый impact_statement. Продукт адресуется через Package URL. Сканеры (Grype, OSV-Scanner) принимают такой документ на вход и фильтруют находки. Поле author должно указывать сторону, ответственную за продукт, а не базу уязвимостей.

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

Предельно компактен: одно утверждение «не затронуто» — несколько строк, без product_tree как в CSAF.
Жёсткий enum обоснований заставляет аргументировать not_affected, а не просто глушить находку.
Адресация продукта по purl ложится прямо на SBOM и вывод сканера; конвейер триажа — П35. VEX triage.

Ограничения

Это только VEX: метаданных бюллетеня, серьёзности и ремедиаций, как в CSAF, у него нет.
Дисциплина обоснований переносит ответственность на человека — неверный justification маскирует реальную уязвимость (П09. VDR и VEX различие факта и решения).
Upstream VEX/advisory можно использовать как evidence, но финальное утверждение для собственного продукта выпускает производитель/владелец продукта.
Утверждения нужно поддерживать в актуальности: смена версии компонента может сделать прежний not_affected недействительным.

Offline / on-premise

Полностью офлайновый: документ генерируется и потребляется как локальный JSON, привязка к находкам сканера идёт без сети. В закрытом контуре VEX-утверждения хранятся рядом с SBOM и применяются на этапе триажа без внешних обращений.

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

М06 Поиск уязвимостей · М08 Защита цепочки поставки и OSA Справка: VEX в процессе РБПО Практики: П09. VDR и VEX различие факта и решения · П35. VEX triage Смежные карточки: CSAF · CycloneDX · Package URL · Grype · OSV-Scanner