OpenVEX no CI/CD: Como Eliminar Falsos Positivos de CVE e Ensinar o Trivy a Entender o Contexto

Imagine tentar explicar a um estrangeiro por que um sinal vermelho de trânsito nem sempre significa 'pare', às vezes significa 'pode ir se você for uma ambulância'. Foi mais ou menos assim que nossa comunicação com o Trivy funcionou até recentemente. O scanner encontrava vulnerabilidades, o DefectDojo as armazenava diligentemente. E nós, a cada vez, tínhamos que analisar manualmente uma pilha de tickets, separando ameaças reais de falsos positivos. Isso era especialmente doloroso durante a preparação de um lançamento, quando cada minuto conta. O problema não estava nas ferramentas – elas funcionavam corretamente e retornavam relatórios sobre as vulnerabilidades encontradas – mas na falta de 'compreensão mútua'. Precisávamos de alguma forma indicar ao Trivy que uma vulnerabilidade específica não era explorável em nosso contexto, que deveria ser marcada como 'not_affected' e não nos incomodar mais. O OpenVEX se tornou essa 'ponte' para nós.

Meu nome é Roman Korchagin, e eu trabalho com processos de desenvolvimento seguro na plataforma de contêineres 'Shturval'. Neste artigo, vou explicar: como integramos a geração de arquivos VEX ao nosso pipeline; como sincronizamos dados entre DefectDojo e Trivy nos clusters dos clientes; onde armazenamos os arquivos VEX e como verificamos se as 'exceções' realmente funcionam; e por que os desenvolvedores não se assustam mais com a palavra 'scanning'.

O Início de Tudo No momento da implementação do VEX, já tínhamos um conjunto de ferramentas funcional: um pipeline CI/CD com scanners conectados; DefectDojo como um repositório centralizado ASOC, acumulando resultados de varredura; e integração com DefectDojo para criar tarefas para desenvolvedores e atribuir responsabilidades. No entanto, uma questão crucial surgiu: como informar ao Trivy em um cluster de usuário que uma análise já foi realizada para CVEs específicos, e que as 'descobertas' encontradas: não são aplicáveis; têm criticidade diferente nesta arquitetura; ou podem ser ignoradas. Foi aqui que o VEX, que é suportado pelo Trivy para todos os tipos de varredura desde a versão 0.49.0, entrou em cena.

O Que é VEX? VEX (Vulnerability Exploitability Exchange) é uma especificação cuja tarefa é eliminar falsos positivos e focar em vulnerabilidades que representam uma ameaça imediata. A primeira implementação dessa ideia é o OpenVEX – uma especificação de código aberto, biblioteca e conjunto de ferramentas lançadas pela Chainguard em janeiro de 2023.

Aplicação Prática do VEX Voltando à nossa construção segura. 👉🏻 Tarefa nº 1. Entrega de marcações de vulnerabilidades encontradas aos usuários OpenVEX é um arquivo JSON legível por máquina, suportado pelo Trivy através do flag –vex. A fonte pode ser: um arquivo no sistema de arquivos, um artefato OCI e um repositório. Ao formar um lançamento, coletamos os resultados da marcação em um arquivo VEX, que se torna acessível aos nossos usuários.

👉🏻 Tarefa nº 2. Reutilização no Pipeline Algumas 'descobertas ignoradas' podem levar muito tempo para serem corrigidas por vários motivos: a biblioteca não é corrigida, o projeto não é mais suportado e assim por diante. Para evitar que a equipe de engenharia retorne à mesma vulnerabilidade repetidamente, o VEX pode ser reutilizado na varredura dentro do pipeline. O sistema de status do VEX permite classificar claramente o estado das vulnerabilidades nos produtos de software. Ao publicar um documento VEX, os seguintes status são atribuídos: not_affected – a vulnerabilidade não requer correção; affected – a vulnerabilidade precisa ser corrigida ou tratada; fixed – a vulnerabilidade foi corrigida nas versões especificadas; under_investigation – o status da vulnerabilidade está sendo esclarecido, aguardando atualização.

Exemplo: CVE no ingress-nginx Se você escanear a imagem ingress-nginx/controller versão v1.12.2, o Trivy pode detectar uma vulnerabilidade CVE-2025-31133 dentro do arquivo executável, relacionada ao runc. Em nossa compilação, a exploração não é possível: o componente não interage diretamente com o runc e usa apenas a API. Portanto, o VEX incluirá esta exceção:

json
{
 "vulnerability": {
 "name": "CVE-2025-31133"
 },
 "products": [
 {
 "@id": "<Seu Registry>/ingress-nginx/controller:v1.12.2"
 }
 ],
 "status": "not_affected",
 "justification": "vulnerable_code_cannot_be_controlled_by_adversary"
}

Para garantir a precisão e evitar a 'substituição de imagem', recomendo usar o formato com sha256, então o @id ficaria assim: pkg:oci/controller@sha256%3Aebea964f28a4ce1e0a4ee3cdd1507151a1496f3e20bef32cae10e2e2b3b7252f?arch=amd64&repository_url="<Seu Registry>/%2Fingress-nginx%2Fcontroller.

O Que Mudou Após a Implementação? Quando integramos o OpenVEX, rapidamente superamos a fase de 'Ah, mais um padrão' e percebemos os problemas que ele resolve na cadeia de suprimentos de software seguro. Descobrimos três deles:

1. Sistematização da Expertise: Anteriormente, os resultados da varredura do Trivy chegavam ao DefectDojo como uma lista plana, e era possível separar ameaças reais de características contextuais apenas manualmente e através de longas discussões em chats. Agora, a conclusão especializada é empacotada em um arquivo VEX, onde é registrado qual vulnerabilidade realmente afeta a segurança da infraestrutura do usuário e qual permanece no código, mas não cria risco devido às especificidades de sua aplicação. Paramos de perder esse contexto entre os lançamentos.

2. Transparência na Exploração: Operadores de sistemas e equipes que tomam decisões sobre implantação em produção finalmente obtiveram um mecanismo de avaliação claro. Em vez de analisar manualmente cada 'descoberta' crítica (nota: finding em objetos DefectDojo) do relatório Trivy, eles veem uma qualificação pronta: esta ameaça é real e requer intervenção, e aqui – o risco está ausente, e há uma justificativa para isso. Assim, o VEX permite tomar decisões informadas sobre a correção de problemas sem reanálise.

3. Fechamento do Ciclo de Troca de Conhecimento: Quando começamos a anexar arquivos VEX aos lançamentos, equipes adjacentes e consumidores externos de nossos componentes pararam de duplicar pesquisas. Eles veem: uma análise já foi realizada para esta vulnerabilidade, o status 'not_affected' foi confirmado e documentado.

Agora, não pedimos para acreditar em nossa palavra, mas compartilhamos os resultados do nosso trabalho em um formato legível por máquina e, ao mesmo tempo, totalmente transparente. E essa, na minha opinião, é a principal contribuição do VEX para o aumento geral da segurança – quando, em vez de isolamento, construímos um ecossistema em que cada participante subsequente da cadeia começa não do zero, mas com dados já verificados.

Links Úteis:

• What is OpenVex — Visão conceitual do OpenVEX
• OpenVEX github — Link para o repositório
• DevSecOps Talks — Outro canal sobre DevSecOps
• Comunidade Kubernetes 'Shturval' — Um lugar onde você sempre encontrará ajuda.

Venha no dia 30 de julho para a conferência Kuber Community Day, que acontecerá em Moscou. Lá, falaremos sobre monitoramento da saúde de clusters Kubernetes, custo de implantações malsucedidas, aplicação de IA em kubernetes, analisaremos o Projeto Argo e muito mais. A programação inclui palestras de profissionais da X5 Tech, MWS, Raiffeisenbank, SberZdorovye, Chislitel Lab, Infosystems Jet, Hilbert Team, troca de experiências e networking.