OpenVEX в CI/CD: как перестать бороться с ложными CVE и научить Trivy понимать контекст

Представьте: вы пытаетесь объяснить иностранцу, почему красный сигнал светофора не всегда означает «стоять», иногда это — «можно ехать, если ты — скорая помощь». Примерно так до недавнего времени выглядело наше общение с 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 будет фигурировать это исключение:

Для достоверности и предотвращения «подмены образа» рекомендую использовать формат с 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, обмен опытом и нетворкинг.