Quando a equipe passa a gerar SBOM para cada release, o scanner de vulnerabilidades enxerga mais componentes do que nunca — e, junto com eles, chegam alertas de CVEs que, naquela build específica, não podem ser exploradas. O Vulnerability Exploitability eXchange, ou VEX, existe para resolver exatamente esse problema: é um documento emitido por quem produz, empacota ou distribui software que afirma, em formato legível por máquina, se uma vulnerabilidade afeta ou não um produto. A ação prioritária é dupla: exigir documentos VEX dos fornecedores críticos e começar a emitir VEX para o software próprio, com o resultado integrado à triagem do pipeline.
O ruído que o SBOM criou
O SBOM entrega transparência sobre a composição do software, mas transparência tem custo operacional. O scanner passa a apontar toda dependência que contém uma CVE catalogada, mesmo quando o componente foi compilado sem o código vulnerável, já foi corrigido naquela versão ou nunca é executado em produção. O projeto OpenVEX, mantido pela comunidade que também constrói as ferramentas de adoção, descreve o efeito com precisão: a transparência dos SBOMs tende a multiplicar falsos positivos nos scanners, e sem um mecanismo automatizado de triagem a taxa de alertas sem risco real explode. O desdobramento é conhecido de quem opera SOC: alerta ignorado vira prática, e a CVE que importava morre no mesmo balde de ruído das que não importavam.
O VEX ataca o problema pela raiz: em vez de o consumidor adivinhar se a CVE se aplica, quem conhece o produto — o fornecedor — emite uma declaração verificável sobre o impacto real. O documento complementa o SBOM sem depender dele: o desenho do formato, registrado nos requisitos mínimos da CISA, prevê integração com SBOMs, bases de vulnerabilidade e advisories, mas não exige nenhum deles. Quem consome software de terceiros ganha uma fonte autoritativa de triagem; quem produz software ganha um canal para provar, com evidência auditável, que a vulnerabilidade do momento não alcança seu produto.
O que é um documento VEX
Um documento VEX é um contêiner de metadados com uma ou mais declarações. Cada declaração cruza três eixos: um produto identificado de forma estável (no OpenVEX, por package URL, o purl), uma vulnerabilidade (normalmente uma CVE, com apelidos possíveis) e um status de impacto. O tempo é parte do dado: cada declaração vale para um instante, versões novas do documento enriquecem e substituem as antigas, e a versão do documento precisa ser incrementada sempre que qualquer conteúdo muda. Na prática, os requisitos mínimos publicados pela CISA em abril de 2023 estabelecem que um documento VEX sempre precisa de um autor identificado e de ao menos uma declaração, e que a autoria deve preferencialmente estar associada criptograficamente à assinatura do documento.
Há três implementações maduras que expressam VEX: CSAF, usado por grandes fornecedores em advisories; CycloneDX, que embute declarações dentro do próprio SBOM; e OpenVEX, arquivos JSON-LD minimalistas, independentes do formato do SBOM. Para quem está começando, a decisão relevante não é o formato, e sim o fluxo: documento versionado, publicado em URL estável, com autor verificável.
A especificação ilustra o mecanismo com um caso real: para o log4shell (CVE-2021-44228), o projeto Spring Boot emitiu declaração de não afetação com justificativa de código vulnerável fora do caminho de execução, porque o starter padrão de logging não inclui o log4j-core explorável. O alerta do scanner continua existindo; o que muda é a resposta automática e auditável.
Status e justificativas
O coração do VEX são os rótulos de status. São quatro, e cada um demanda uma reação diferente do pipeline:
| Status | Significado | Ação recomendada |
|---|---|---|
| not_affected | o produto não é afetado pela vulnerabilidade | suprimir o alerta e registrar a justificativa |
| affected | o produto é afetado | abrir tratamento com prioridade definida pelo contexto |
| fixed | a vulnerabilidade foi corrigida na versão citada | forçar atualização para a versão corrigida |
| under_investigation | o impacto ainda está em análise | manter o alerta ativo com prazo de revisão |
Suprimir alerta é a operação de maior risco do fluxo, e por isso é a mais regulada. Na especificação OpenVEX, uma declaração com status not_affected exige uma justificativa de rótulo fixo ou uma declaração de impacto que explique o motivo. Os rótulos de justificativa cobrem os casos reais: componente ausente, código vulnerável ausente, código fora do caminho de execução, código que o adversário não consegue controlar e mitigações internas já existentes. Dois deles recebem aviso da própria especificação: justificativas baseadas em mitigações internas ou em controle impossível pelo atacante podem ser difíceis de provar de forma conclusiva, e a história da exploração está cheia de bypass de mitigações consideradas definitivas.
Como operar o VEX no pipeline
A adoção se divide em consumir e emitir, e as duas frentes podem andar em paralelo:
- P1 — inventário de fornecedores: listar os fornecedores cuja falha pararia o negócio e verificar quais já publicam VEX ou CSAF com declarações de impacto.
- P1 — consumo no scanner: configurar a ferramenta de varredura para ler documentos VEX do fornecedor e suprimir apenas alertas com não afetação justificada — o mesmo espírito de triagem antecipada do OSV-Scanner no CI/CD, agora com a palavra do fabricante.
- P2 — emissão própria: gerar VEX no processo de release, um documento por build, com purl exato e timestamp.
- P2 — governança do documento: URL estável, versão incrementada a cada mudança e política de reemissão após cada patch de segurança.
Na escolha de ferramenta, o critério que diferencia é o consumo nativo de VEX: a comparação entre scanners, como a feita entre Trivy e Checkov para IaC, deve incluir a pergunta sobre leitura de declarações de impacto. Sem consumo de VEX, o SBOM vira gerador de ruído caro.
Sinais de que o fluxo está doente: documento sem timestamp, declaração de não afetação sem justificativa, purl que não casa com nenhuma entrada do SBOM e ausência de versão nova depois de um patch de segurança publicado. Cada um desses sinais indica que a triagem automática vai falhar justamente no incidente em que ela precisaria funcionar.
Erros que anulam o benefício
Quatro armadilhas aparecem em quase toda implantação. Primeira: tratar o VEX como fonte completa — o formato não obriga o autor a listar todos os produtos e componentes existentes, então ausência de declaração não é prova de não afetação. Segunda: suprimir alerta sem justificativa registrada, quebrando a auditoria. Terceira: não versionar o documento, o que destrói o histórico de evolução do impacto. Quarta: aceitar VEX de origem não verificável — se a autoria não pode ser confirmada, o documento vira vetor de engenharia social defensiva, com alguém publicando não afetação para abrir caminho.
Um sinal prático de maturidade: quando uma CVE de impacto mundial estoura, o time consegue responder em minutos quantos produtos da casa são afetados, citando documento e versão — não em dias, refazendo análise manual componente por componente.