Представьте: вы пытаетесь объяснить иностранцу, почему красный сигнал светофора не всегда означает «стоять», иногда это — «можно ехать, если ты — скорая помощь». Примерно так до недавнего времени выглядело наше общение с Trivy.
Сканер находил уязвимости, DefectDojo их послушно складировал. А мы каждый раз вручную разбирали кучу тикетов, отделяя реальные угрозы от ложных срабатываний. Особенно болезненно это ощущалось во время подготовки релиза, когда каждая минута на счету.
Проблема была не в инструментах — они исправно работали и возвращали отчеты о найденных уязвимостях — а в отсутствии «взаимопонимания». Нужно было как-то намекнуть Trivy, что конкретная уязвимость не эксплуатируется в нашем контексте, ее следует пометить как 'not_affected' и больше не отвлекать нас. Таким «мостиком» стал для нас OpenVEX.
Меня зовут Роман Корчагин, я занимаюсь процессами безопасной разработки в контейнерной платформе «Штурвал». В статье расскажу:
как мы интегрировали генерацию VEX-файлов в пайплайн;
как синхронизировали данные между DefectDojo и Trivy в кластерах заказчиков;
где храним VEX-файлы и как проверяем, что «заглушки» действительно работают;
и почему разработчики больше не вздрагивают при слове «сканирование».
С чего все началось
К моменту внедрения VEX мы имели рабочий набор инструментов:
CI/CD-пайплайн с подключенными сканерами;
DefectDojo как единое ASOC-хранилище, аккумулирующее результаты сканирования;
интеграцию DefectDojo для постановки задач разработчикам и закрепления ответственных.
Но один вопрос встал ребром: как информировать Trivy в пользовательском кластере, что по конкретным CVE уже проведен анализ, и обнаруженные «находки»:
не применимы;
имеют другую критичность в данной архитектуре;
или могут быть проигнорированы.
Здесь на помощь пришел VEX, который с версии 0.49.0 поддерживает Trivy для всех видов сканирования.
Что такое VEX
VEX (Vulnerability Exploitability Exchange) — это спецификация, задача которой — устранять ложные срабатывания и фокусироваться на уязвимостях, представляющих непосредственную угрозу.
Первой реализацией идеи VEX является OpenVEX — спецификация с открытым исходным кодом, библиотека и набор инструментов, выпущенная компанией Chainguard в январе 2023 года.
Практическое применение VEX
Вернемся к нашей безопасной сборочной.
👉🏻 Задача №1. Доставка разметки найденных уязвимостей пользователям
OpenVEX — это машиночитаемый JSON-файл, поддерживаемый Trivy через флаг –vex. Источником могут быть: файл в файловой системе, OCI-артефакт и репозиторий. При формировании релиза мы собираем результаты разметки в vex, которые становятся доступными нашим пользователям.
👉🏻 Задача №2. Переиспользование в пайплайне
Некоторые «заглушенные находки» могут долго устраняться по разным причинам: библиотека не патчится, проект не поддерживается и подобное. Чтобы команда инженеров не возвращалась к одной и той же уязвимости снова и снова, VEX может быть переиспользован в сканировании внутри пайплайна.
Система статусов VEX позволяет четко классифицировать состояние уязвимостей в программных продуктах. При публикации документа VEX присваиваются следующие статусы:
not_affected — уязвимость не требует устранения;
affected — необходимо устранить или обработать уязвимость;
fixed — уязвимость устранена в указанных версиях;
under_investigation — статус уязвимости уточняется, ожидается обновление.
Пример: CVE в ingress nginx
Если просканировать образ ingress-nginx/controller версии v1.12.2, Trivy может обнаружить внутри исполняемого файла уязвимость CVE-2025-31133, связанную с runc. В нашей сборке эксплуатация невозможна: компонент не взаимодействует напрямую с runc и использует только API. Значит, в VEX будет фигурировать это исключение:
{
"vulnerability": {
"name": "CVE-2025-31133"
},
"products": [
{
"@id": "<Ваш Registry>/ingress-nginx/controller:v1.12.2"
}
],
"status": "not_affected",
"justification": "vulnerable_code_cannot_be_controlled_by_adversary"
}Для достоверности и предотвращения «подмены образа» рекомендую использовать формат с sha256, тогда @id будет выглядеть примерно так: pkg:oci/controller@sha256%3Aebea964f28a4ce1e0a4ee3cdd1507151a1496f3e20bef32cae10e2e2b3b7252f?arch=amd64&repository_url="<Ваш Registry>/%2Fingress-nginx%2Fcontroller
Что изменилось после внедрения
Когда мы встроили OpenVEX, то быстро прошли стадию «О, еще один стандарт» и осознали, какие проблемы он решает в цепочке поставки безопасного ПО. Их оказалось три:
Систематизация экспертизы. Раньше результаты сканирования Trivy попадали в DefectDojo плоским списком, и отделить реальные угрозы от контекстных особенностей можно было только руками и долгими обсуждениями в чатах. Теперь экспертное заключение упаковано в VEX-файл, где фиксируется, какая уязвимость действительно влияет на безопасность пользовательской инфраструктуры, а какая остается в коде, но не создает риска из-за особенностей его применения. Мы перестали терять этот контекст между релизами.
Прозрачность эксплуатации. Операторы систем и команды, которые принимают решения о выкатке в прод, получили наконец понятный механизм оценки. Вместо ручного разбора каждой критической «находки» (прим. finding в объектах DefectDojo) из отчета Trivy они видят готовую квалификацию: эта угроза реальна и требует вмешательства, а здесь — риск отсутствует, и у этого есть обоснование. Таким образом, VEX позволяет принимать обоснованные решения по устранению проблем без повторного анализа.
Замыкание контура обмена знаниями. Когда мы начали прикладывать VEX-файлы к релизам, смежные команды и внешние потребители наших компонентов перестали дублировать исследования. Они видят: по этой уязвимости уже проведен анализ, статус "not_affected" подтвержден и задокументирован.
Теперь мы не просим поверить на слово, а делимся результатами своей работы в виде машиночитаемого и при этом полностью прозрачного формата. И это, на мой взгляд, главный вклад VEX в общее повышение защищенности — когда вместо изоляции мы выстраиваем экосистему, в которой каждый следующий участник цепочки начинает не с нуля, а с уже проверенных данных.
Полезные ссылки:
What is OpenVex — концептуальный обзор OpenVex
OpenVEX github — ссылка на репозиторий
DevSecOps Talks — еще один канал про DevSecOps
Kubernetes-сообщество «Штурвала» — место, где всегда помогут
Приходите 30 июля на конференцию Kuber Community Day, которая пройдет в Москве. Там будем говорить о мониторинге здоровья Kubernetes-кластеров, стоимости неудачных деплоев, применении ИИ в кубере, разберем Argo Project и многое другое. В программе — доклады от практиков из X5 Tech, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Инфосистемы Джет», Hilbert Team, обмен опытом и нетворкинг.