Как работает KEV?

KEV указывает на уязвимости, которые активно эксплуатируются в атаках.

Почему CVSS не всегда подходит?

CVSS измеряет потенциальный вред, а не вероятность атаки.

Что такое VEX?

VEX — это стандарт, который указывает, эксплуатируется ли уязвимость в конкретном контексте.

Как SBOM помогает в release gate?

SBOM позволяет точно знать, какие компоненты входят в сборку и их уязвимости.

Материал

Release gate на основе SBOM и KEV: как за 30 секунд получить ответ «можно ли выпускать»

Q: Что такое SBOM?

SBOM — это машиночитаемый список всех компонентов программного продукта.

Опубликовано: 04 мая 2026 Время чтения: 17 мин

Один релиз — один сигнал. Не отчёт на 400 строк, а одно решение: зелёный или красный.

Почему CVSS больше не работает как release gate

Каждый год CVE-база растёт. В 2024 году в неё добавили свыше 40 000 записей [1]. Если использовать CVSS ≥ 7.0 как единственный порог для остановки релиза, каждый второй PR будет заблокирован — включая компоненты, которые никогда не атакуют в реальности.

Это не теория: исследование FIRST показывает, что при стратегии «патчим всё с CVSS ≥ 7» команда обрабатывает примерно вдвое больше уязвимостей, чем при аналогичном EPSS-пороге [2]. При этом эффективность — то есть доля реально заэксплуатированных — значительно выше у EPSS-выборки. CVSS измеряет потенциальный вред в худшем сценарии, а не вероятность того, что атака состоится.

В 2025 году появился CVSS 4.0 с метрикой «Exploit Maturity», но он остаётся показателем тяжести, а не риска [3]. Ключевой вопрос перед релизом звучит иначе: «эту уязвимость эксплуатируют прямо сейчас?» — и ответ на него даёт не CVSS, а KEV.

Что такое KEV и почему это сигнал другого класса

CISA (Cybersecurity and Infrastructure Security Agency, США) ведёт каталог Known Exploited Vulnerabilities — Known Exploited Vulnerabilities Catalog [4]. Запись попадает в него только при одновременном выполнении трёх условий:

CVE-идентификатор присвоен.
Подтверждено активное использование в реальных атаках.
Существует рекомендованное действие по устранению.

В 2025 году в каталог добавили 245 новых уязвимостей — рост более 30% по сравнению с 2023–2024 годами. На конец 2025-го каталог содержал 1484 записи [5]. Обновляется он несколько раз в неделю и доступен в machine-readable JSON-формате.

KEV — это бинарный сигнал: уязвимость либо есть в каталоге, либо нет. Никаких весовых коэффициентов, никакой интерпретации. Именно поэтому он идеально подходит как основа для автоматического gate-решения: если компонент из вашего SBOM пересекается с записью KEV — это блокирующий факт, а не предупреждение.

С октября 2023 года CISA дополнительно помечает KEV-записи флагом «Known Ransomware Campaign Use» — признаком использования в кампаниях с шифровальщиками [6]. Это ещё один уровень сигнала для тех, кто строит дифференцированные политики.

SBOM: инвентарь, без которого gate бессмысленен

Release gate на основе KEV требует, чтобы вы точно знали, какие компоненты входят в сборку. Именно здесь нужен SBOM — Software Bill of Materials.

SBOM — машиночитаемый список всех компонентов программного продукта: библиотеки, зависимости (прямые и транзитивные), версии, лицензии, источники. Два основных стандарта:

CycloneDX — разработан OWASP, ориентирован на безопасность и supply chain risk; поддерживает VEX-аннотации прямо внутри документа [7].
SPDX — стандарт Linux Foundation, изначально акцентирован на лицензионном комплаенсе [8].

На практике обе системы поддерживаются всеми современными сканерами. Для release gate рекомендован CycloneDX: он лучше приспособлен к интеграции VEX и последующей автоматизированной обработке.

Регуляторный контекст нарастает. US Executive Order 14028 (2021) закрепил SBOM как основу secure software supply chain для поставщиков федерального правительства. EU Cyber Resilience Act распространяет требование на продукты с digital elements, реализуемые на рынке ЕС [9]. PCI DSS 4.0 с марта 2025 года требует поддерживать живой инвентарь всех сторонних компонентов в кастомном ПО [10]. CISA в 2025 году опубликовала обновлённые Minimum Elements для SBOM, унифицировав обязательные поля [11].

Ключевой вывод: SBOM сам по себе не обеспечивает безопасность — это список. Безопасность начинается тогда, когда список сопоставляется с актуальными данными об уязвимостях [12].

Архитектура release gate: три уровня решений

Хорошая архитектура gate не останавливает всё на каждом чихе. Она разделяет сигналы по приоритету и даёт команде понятный следующий шаг.

Уровень 1 — блокирующий (STOP)

Условие: компонент из SBOM присутствует в KEV-каталоге.

Действие: pipeline завершается с ненулевым кодом, релиз заблокирован. Это не рекомендация — это автоматическая остановка. Отложить можно только при наличии утверждённого VEX-исключения с обоснованием (например, уязвимый code path недостижим в данном деплойменте).

Почему именно KEV, а не CVSS ≥ 9? Потому что KEV означает «атака происходит прямо сейчас», а CVSS 9.0 означает лишь «в теории очень плохо». Разница принципиальная для операционного решения.

Уровень 2 — предупреждающий (WARN)

Условия (применяются при отсутствии KEV-попадания):

CVSS ≥ 9.0 без KEV, или
EPSS ≥ 0.5 (высокая вероятность эксплуатации в ближайшие 30 дней).

Действие: pipeline проходит, но создаётся тикет с SLA. Команда получает конкретный список компонентов и окно для реакции. Типичные SLA: CVSS Critical без KEV — 14 дней; EPSS-high — 7 дней.

Уровень 3 — информационный (LOG)

Всё остальное: CVSS < 9, EPSS < 0.5, нет KEV. Фиксируется в артефакте сборки, доступно для аудита, не влияет на pipeline.

Такая трёхуровневая модель воспроизводит подход, описанный в академическом исследовании «Vulnerability Management Chaining» (arXiv, 2025): сначала фильтр по threat-likelihood (KEV + EPSS), затем оценка severity (CVSS) [13]. Эксперименты на 28 000+ реальных уязвимостей показали 18-кратное повышение эффективности при сохранении покрытия.

VEX: как снизить шум без потери безопасности

Уязвимость из KEV присутствует в зависимости, но уязвимый code path в вашем приложении никогда не вызывается. Блокировать релиз в этом случае — операционный шум без снижения реального риска.

Именно это решает VEX (Vulnerability Exploitability eXchange) — стандарт, разработанный при участии CISA и NTIA [14]. VEX-документ сопровождает SBOM и для каждой уязвимости указывает один из статусов:

not_affected — уязвимость присутствует в компоненте, но не эксплуатируема в данном контексте (с обязательным обоснованием).
affected — уязвимость реальна, требует действия.
fixed — уже исправлено в используемой версии.
under_investigation — анализ продолжается.

На практике это значит: gate не просто сравнивает CVE-идентификаторы, а учитывает контекст. Если VEX-статус для KEV-попадания — not_affected с задокументированным обоснованием (например, code_not_reachable), pipeline может продолжаться, а факт остаётся в аудит-логе.

Отраслевые данные показывают, что инструменты анализа достижимости кода снижают количество ложноположительных алертов примерно на 85% [15]. Это критично для команд, которые устали патчить то, что не угрожает их конкретному продукту.

CycloneDX поддерживает встроенные VEX-аннотации непосредственно внутри SBOM-документа. Альтернативно — OpenVEX (проект OpenSSF) и CSAF VEX от OASIS Open [16].

Практический pipeline: от коммита до решения за одну job

Ниже — минимальная рабочая схема. Все инструменты open source, интегрируются в GitHub Actions, GitLab CI, Jenkins за одну job.

Шаг 1. Генерация SBOM

Syft от Anchore — один из наиболее зрелых SBOM-генераторов [17]. Поддерживает контейнеры, файловые системы, широкий спектр экосистем (Go, Python, Java, Node.js, Rust и другие).

syft . -o cyclonedx-json > sbom.json

Для container image:

syft myapp:${GIT_SHA} -o cyclonedx-json > sbom.json

SBOM генерируется как иммутабельный артефакт сборки — он фиксирует именно то, что ушло в прод.

Шаг 2. Сканирование уязвимостей

Grype (тот же Anchore) принимает SBOM на вход и сопоставляет компоненты с NVD, GitHub Advisory Database и другими фидами.

grype sbom:sbom.json -o json > vuln-report.json

Шаг 3. KEV-пересечение

KEV-каталог доступен как JSON-фид по адресу https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. Пересечение с результатами Grype — задача для ≈ 20 строк Python или bash с jq.

# Получить KEV-идентификаторы
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' > kev_ids.txt

# Сопоставить с результатами сканирования
KEV_HITS=$(jq -r '.matches[].vulnerability.id' vuln-report.json \
  | grep -Fxf kev_ids.txt | wc -l)

if [ "$KEV_HITS" -gt 0 ]; then
  echo "BLOCKED: $KEV_HITS KEV-listed vulnerabilities found"
  exit 1
fi
echo "PASSED: No KEV hits"

Шаг 4. Применение VEX-исключений (опционально)

Если у команды есть VEX-документ с not_affected-статусами, скрипт gate должен отфильтровать соответствующие CVE перед финальным решением. OWASP Dependency-Track поддерживает VEX-импорт и автоматическую фильтрацию [18].

Результат pipeline

Вместо 400-строчного отчёта команда получает одно из трёх:

BLOCKED — список KEV-компонентов, ссылка на KEV-запись, рекомендуемое действие.
WARN — список высокорисковых уязвимостей без KEV, SLA для реакции.
PASSED — SBOM сохранён как артефакт, можно деплоить.

Что проверять на каждом этапе: чек-лист

До merge (PR-уровень)

Появился ли в diff новый или обновлённый пакет?
Если да — сгенерирован ли SBOM-diff (список изменённых зависимостей)?
Есть ли KEV-попадания по новым компонентам?
Есть ли транзитивные зависимости с KEV-статусом?

В CI (перед сборкой в прод)

SBOM сгенерирован для финального артефакта (не для source, а для build/container)?
KEV-фид актуален (обновляется несколько раз в неделю)?
VEX-исключения задокументированы с обоснованием и датой ревью?
SBOM подписан и привязан к конкретному build-артефакту?

Перед деплоем в production

SBOM текущего артефакта совпадает с тем, что прошёл CI?
Нет ли KEV-записей, добавленных в каталог после последней сборки?
Архивирован ли SBOM для последующего аудита?

Где release gate особенно важен

Зависимости, добавленные AI-ассистентом

Когда разработчик использует Copilot, Claude или другой AI-инструмент, новая зависимость может появиться в package.json или go.mod без осознанного выбора. AI-генерация ускоряет написание кода, но не знает о KEV-статусе пакета на момент запроса. Это именно тот случай, где автоматический SBOM-gate на уровне PR критически важен: он видит новую зависимость раньше, чем она уходит в прод.

Инструменты вроде HighVibe решают эту задачу на уровне конкретного изменения в PR — анализируя, что именно изменилось в зависимостях, и сигнализируя о risk до merge, а не после. Это дополняет SBOM-gate в CI: PR-уровень даёт ранний сигнал команде, CI-gate — финальный барьер перед релизом.

Транзитивные зависимости

70–90% современных приложений состоит из open source компонентов [19]. Большинство KEV-попаданий приходит не на прямые зависимости, а на транзитивные. SBOM-сканирование с Syft охватывает оба уровня.

Legacy-компоненты

KEV-каталог содержит уязвимости вплоть до 2002 года [5]. Компонент, который не обновлялся годами, может неожиданно получить KEV-статус. Без постоянного мониторинга это остаётся незамеченным до инцидента.

Типичные ошибки при построении release gate

Ошибка 1. Gate работает только при сборке, а не постоянно.

KEV обновляется несколько раз в неделю. Компонент, прошедший gate в понедельник, может получить KEV-запись в среду. Нужен continuous monitoring существующих SBOM против обновляемого KEV-фида.

Ошибка 2. KEV-фид берётся раз в месяц вместо актуального.

Закэшированная копия недельной давности упустит новые KEV-добавления. CISA публикует machine-readable JSON; автоматизируйте его получение как часть pipeline.

Ошибка 3. Блокируют по CVSS, игнорируют KEV.

CVSS-порог создаёт сотни false positive. Команда привыкает игнорировать алерты. Когда появляется реальная KEV-угроза, она теряется в шуме. Приоритет: сначала KEV-фильтр, потом CVSS.

Ошибка 4. VEX-исключения без срока действия.

Обоснование not_affected актуально только для текущей конфигурации и версии компонента. Без expiry-даты исключение живёт вечно и создаёт ложное ощущение безопасности.

Ошибка 5. SBOM генерируется из source, а не из финального артефакта.

Source SBOM и build/container SBOM могут существенно отличаться: в процессе сборки добавляются runtime-библиотеки, base image зависимости, сигнатуры. Финальный gate должен работать с финальным артефактом [20].

Ошибка 6. Нет аудит-следа.

SBOM и результаты gate-проверки должны сохраняться как иммутабельные артефакты сборки. При инциденте (Log4Shell, XZ Utils) именно они позволяют за минуты определить, какие деплойменты затронуты.

EPSS как дополнительный сигнал: когда использовать

KEV бинарен и ретроспективен: уязвимость попадает в него после подтверждения эксплуатации. EPSS (Exploit Prediction Scoring System, FIRST) даёт вероятностный прогноз: насколько велик шанс эксплуатации в следующие 30 дней [21].

EPSS v4, вышедший в марте 2025 года, обрабатывает более 250 000 точек данных о threat intelligence ежедневно и теперь умеет скорить CVE, находящиеся в NVD backlog — то есть даже те, по которым официальный анализ ещё не завершён [3].

Практическая схема использования KEV + EPSS:

Если CVE есть в KEV → блокируем (уровень 1).
Если CVE нет в KEV, но EPSS ≥ 0.5 → предупреждение (уровень 2, ускоренный SLA).
Если EPSS < 0.5 и нет KEV → информационный лог (уровень 3).

Академическое исследование «Vulnerability Management Chaining» [13] показало: двухступенчатый фильтр KEV → EPSS → CVSS обеспечивает 18-кратную эффективность по сравнению с чистым CVSS-подходом при сохранении 85.6% coverage реально эксплуатируемых уязвимостей.

Как это выглядит в реальном pipeline (GitHub Actions)

name: Release Gate

on:
  push:
    branches: [main]

jobs:
  sbom-kev-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh \
            | sh -s -- -b /usr/local/bin
          syft . -o cyclonedx-json > sbom.json

      - name: Scan vulnerabilities
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh \
            | sh -s -- -b /usr/local/bin
          grype sbom:sbom.json -o json > vuln-report.json

      - name: KEV gate
        run: |
          curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
            | jq -r '.vulnerabilities[].cveID' > kev_ids.txt

          KEV_HITS=$(jq -r '.matches[].vulnerability.id' vuln-report.json \
            | grep -Fxf kev_ids.txt)

          if [ -n "$KEV_HITS" ]; then
            echo "::error::BLOCKED — KEV vulnerabilities found:"
            echo "$KEV_HITS"
            exit 1
          fi
          echo "PASSED: no KEV hits"

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.sha }}
          path: sbom.json

Весь gate занимает 60–90 секунд и добавляет к pipeline один результирующий сигнал.

Инструменты для построения полного workflow

Генерация SBOM:

Syft (Anchore, open source) — контейнеры, файловые системы, широкий спектр языков [17].
cdxgen (CycloneDX, open source) — особенно силён в Java, Node.js, Python.

Сканирование уязвимостей:

Grype (Anchore, open source) — принимает SBOM на вход, агрегирует NVD, GitHub Advisories и другие фиды.
OSV-Scanner (Google, open source) — хорошо работает с Go и Python-экосистемами.

Мониторинг и VEX:

OWASP Dependency-Track — open source платформа для continuous monitoring SBOM против KEV и других фидов [18].
sbomify — SaaS-платформа с интеграцией Google OSV и Dependency-Track, поддержкой VEX [6].

KEV-фид:

CISA KEV JSON feed — machine-readable, обновляется несколько раз в неделю [4].

Форматы:

CycloneDX — предпочтителен для security workflows и VEX-аннотаций [7].
SPDX — сильнее в лицензионном комплаенсе [8].

Регуляторный контекст в 2025–2026

Требования к SBOM перестали быть «best practice» и стали условием работы на ряде рынков.

EO 14028 (США, 2021) закрепил SBOM для федеральных поставщиков. EU Cyber Resilience Act вводит требования SBOM для продуктов с digital elements, реализуемых в ЕС [9]. PCI DSS 4.0 с марта 2025 года по контролям 6.3.2 и 11.3.1.1 требует живой, поиск по которому возможен, инвентарь всех компонентов [10]. FDA в июне 2025 года выпустила обновлённое руководство по cybersecurity в медицинских устройствах, включая требования к SBOM в premarket submissions [22].

Для команд в России и СНГ: прямых регуляторных требований к SBOM пока нет, однако нормы ФСТЭК по supply chain security нарастают, и enterprise-заказчики в финансовом и промышленном секторах всё активнее включают SBOM в требования к поставщикам ПО.

HighVibe: release gate на уровне PR, а не только CI

CI-gate на основе SBOM × KEV — правильный последний рубеж. Но к моменту, когда pipeline его достигает, изменение уже влито в main, артефакт собран, а команда ждёт деплоя. Остановить релиз на этом этапе — значит откатить работу, пересобрать, снова прогнать все тесты.

Более ранний сигнал — на уровне PR, до merge — стоит дешевле во всех смыслах: разработчик ещё в контексте изменения, фикс занимает минуты, а не часы.

Именно здесь работает HighVibe — дополнительный слой контроля безопасности для команд, которые уже ускорили разработку с ИИ. Логика та же, что у SBOM-gate, но применена к конкретному diff:

Что HighVibe анализирует в PR:

Новые и обновлённые зависимости — прямые и транзитивные. Если пакет появился в go.mod, package.json или requirements.txt, HighVibe проверяет его против KEV и advisory-фидов до того, как PR уйдёт на ревью.
Изменения в CI/CD-конфигурациях — Dockerfile, .github/workflows, Makefile. Именно здесь чаще всего незаметно появляются зависимости с уязвимостями в base image или build-инструментах.
Контекст релиза — не просто «есть ли уязвимость», а «критична ли она для того, что меняется именно в этом PR».

Что команда получает:

Не ещё один длинный security-отчёт. Короткий сигнал: конкретный компонент, KEV-ссылка, рекомендованный следующий шаг — обновить версию, убрать зависимость, добавить VEX-обоснование. Только то, что действительно блокирует безопасный merge.

Как это соотносится с CI-gate:

HighVibe и SBOM-gate в CI — не конкуренты, а два барьера на разных этапах. PR-уровень даёт ранний сигнал разработчику; CI-gate — финальную автоматическую проверку перед деплоем. Вместе они закрывают наиболее частый сценарий: AI-ассистент предложил зависимость с KEV-статусом, разработчик не заметил при ревью, CI поймал — но уже в сборке.

Если команда ещё не настроила SBOM-gate в CI, HighVibe даёт точку входа: видимость новых зависимостей прямо в PR без необходимости строить полный pipeline с нуля.

highvibe.dev

Выводы и следующие шаги

Release gate на основе SBOM + KEV — это не очередной сканер и не ещё один отчёт. Это конкретный операционный ответ на вопрос «можно ли выпускать»: бинарный, воспроизводимый, понятный команде.

Что делать прямо сейчас:

Начать генерировать SBOM при каждой сборке (Syft + CycloneDX). Даже без gate — это уже ценность.
Добавить KEV-пересечение как blocking step в CI: 50 строк кода, нулевые лицензионные расходы.
Настроить continuous monitoring: KEV обновляется несколько раз в неделю, point-in-time scan недостаточен.
Начать документировать VEX-исключения: это дисциплина, которую аудиторы и регуляторы будут требовать раньше, чем кажется.
Добавить PR-уровень контроля: gate в CI останавливает уже готовую сборку, а сигнал на уровне PR — пока изменение ещё легко отменить.

Перед релизом нужен один ответ: зелёный или красный. Связка SBOM × KEV даёт именно это.

Источники

[1] Picus Security — "Comparing CVSS, EPSS, KEV, SSVC, LEV, and PXS" — https://www.picussecurity.com/resource/blog/comparing-cvss-epss-kev-ssvc-lev-and-pxs-from-scores-to-security-proof

[2] Intruder — "EPSS vs CVSS: What's The Best Approach To Vulnerability Prioritization?" — https://www.intruder.io/blog/epss-vs-cvss

[3] Zafran — "Prioritizing Vulnerabilities: Best Practices for Risk-Based Patching" — https://www.zafran.io/ctem-academy/prioritizing-vulnerabilities-risk-based-patching

[4] CISA — "Known Exploited Vulnerabilities Catalog" — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

[5] Cyble — "2025 CISA KEV Catalog Hits 1,484 Exploited Vulnerabilities" — https://cyble.com/blog/cisa-kev-2025-exploited-vulnerabilities-growth/

[6] sbomify — "What Is a KEV? Understanding CISA's Known Exploited Vulnerabilities Catalog" — https://sbomify.com/2025/12/30/what-is-kev-cisa-known-exploited-vulnerabilities/

[7] CycloneDX — "Vulnerability Exploitability eXchange (VEX)" — https://cyclonedx.org/capabilities/vex/

[8] Jit — "A Guide to Generating SBOM with Syft and Grype" — https://www.jit.io/resources/appsec-tools/a-guide-to-generating-sbom-with-syft-and-grype

[9] Anchore — "Why SBOMs Are No Longer Optional in 2025" — https://anchore.com/blog/why-sboms-are-no-longer-optional-in-2025/

[10] Cybeats — "2025 SBOM Deadline: PCI DSS 4.0 Controls 6.3.2 & 11.3.1.1" — https://www.cybeats.com/blog/pci-dss-4-0-sboms-a-2025-readiness-guide

[11] Kusari — "Understanding the Proposed CISA 2025 SBOM Minimum Elements" — https://www.kusari.dev/blog/understanding-the-proposed-cisa-2025-sbom-minimum-elements

[12] Flashpoint — "SBOM 102: How to Operationalize SBOM Data Into Real-Time Vulnerability Management" — https://flashpoint.io/blog/sbom-operationalize-vulnerability-management/

[13] arXiv — "Vulnerability Management Chaining: An Integrated Framework for Efficient Cybersecurity Risk Prioritization" — https://arxiv.org/html/2506.01220v3

[14] CISA — "Vulnerability Exploitability eXchange (VEX) – Use Cases" — https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Document_508c.pdf

[15] Grab The Axe — "VEX in DevSecOps: How to Use the Vulnerability Exploitability eXchange to Prioritize Real Threats" — https://grabtheaxe.com/vex-devsecops-prioritize-real-threats/

[16] sbom.se — "What is VEX?" — https://sbom.se/en/tracks/fundamentals-about-sbom/what-is-vex

[17] GitHub Anchore/Syft — https://github.com/anchore/syft

[18] sbomify — "SBOM Scanning: How to Detect Vulnerabilities in Your Software Components" — https://sbomify.com/2026/02/01/sbom-scanning-vulnerability-detection/

[19] Anchore — "SBOMs in 2025: Trends & Predictions" — https://anchore.com/blog/software-supply-chain-security-in-2025-sboms-take-center-stage/

[20] GitHub Anchore/sbom-examples — https://github.com/anchore/sbom-examples

[21] Cloudsmith — "CVSS vs EPSS: Smarter Vulnerability Risk Prioritization" — https://cloudsmith.com/blog/vulnerability-scoring-systems

[22] sbomify — "FDA Medical Device SBOM Requirements" — https://sbomify.com/2026/01/09/fda-medical-device-sbom-requirements/