VEX: o que diz um documento Vulnerability Exploitability eXchange

O que é o VEX?

O VEX, abreviatura de Vulnerability Exploitability eXchange, é uma declaração legível por máquina sobre se um produto é afetado por uma vulnerabilidade conhecida específica. Um fornecedor publica-a para que quem usa o produto saiba que vulnerabilidades exigem ação e quais não exigem. Na maioria das organizações, esse trabalho do fornecedor cabe à equipa de resposta a incidentes de segurança de produto (PSIRT).

Os Minimum Requirements for VEX da CISA (abril de 2023) definem-no independentemente de qualquer formato de ficheiro: um documento VEX é um contentor para uma ou mais declarações VEX, e cada declaração dá um estado para uma vulnerabilidade num ou mais produtos. O VEX foi concebido para funcionar com SBOM, bases de dados de vulnerabilidades e avisos de segurança, mas não precisa de nenhum deles.

Porque existe o VEX: o ruído das SBOM

Uma SBOM lista todos os componentes de um produto, incluindo as dependências transitivas. Um scanner cruza esses componentes com avisos de segurança e reporta todas as CVE em todas as versões que encontra. Muitas dessas conclusões não se aplicam: a função vulnerável nunca é chamada, uma opção de build exclui-a da compilação ou a configuração do produto bloqueia o ataque. Sem VEX, cada cliente tem de o determinar sozinho, ou abrir um pedido de suporte a perguntar ao fornecedor.

O VEX transfere essa análise para a parte que a pode fazer uma vez, para todos: o fornecedor. O scanner do cliente lê o documento VEX e suprime as conclusões que o fornecedor marcou como não afetando o produto.

Os quatro estados VEX

Cada declaração VEX tem exatamente um de quatro estados:

Estado	Significado	Também exigido
not_affected	Não é necessária remediação nem mitigação. A vulnerabilidade não afeta os produtos indicados.	Uma justificação, ou uma declaração de impacto que explique porquê
affected	A vulnerabilidade afeta os produtos indicados, e o autor recomenda uma ação.	Uma declaração de ação: o que os utilizadores devem fazer
fixed	As versões do produto indicadas contêm uma correção.	Nada mais
under_investigation	O autor está a investigar e ainda não decidiu.	Nada mais; prevê-se que mude

Justificações VEX para not_affected

Uma declaração not_affected tem de dizer porquê. Os requisitos da CISA dizem que deve, idealmente, usar uma de cinco justificações e que, se não o fizer, tem obrigatoriamente de dar uma declaração de impacto em texto livre. O OpenVEX e o CSAF usam as mesmas cinco:

• component_not_present: o componente vulnerável não está incluído no produto.
• vulnerable_code_not_present: o componente está incluído, mas o código vulnerável não está, normalmente devido à forma como foi configurado ou compilado.
• vulnerable_code_not_in_execute_path: o código vulnerável está presente, mas o produto nunca o chama.
• vulnerable_code_cannot_be_controlled_by_adversary: o código está presente e é usado, mas um atacante não o consegue controlar para explorar a vulnerabilidade.
• inline_mitigations_already_exist: proteções integradas que os utilizadores não podem desativar impedem a exploração.

As justificações diferem nas evidências que exigem. component_not_present exige um registo exato do que o produto contém. As três do meio exigem análise de código, como análise de alcançabilidade ou uma revisão manual, e são as que os clientes mais questionam.

O que contém uma declaração VEX

Os requisitos mínimos da CISA enumeram estes elementos:

• Metadados do documento: um identificador do documento, uma versão que aumenta a cada alteração, o autor (uma pessoa ou organização, não uma ferramenta) e quando foi emitido pela primeira vez e atualizado pela última vez.
• Dados do produto: um ou mais identificadores do produto, de preferência os mesmos que a SBOM do produto usa, como um package URL (purl). Uma declaração pode também indicar o subcomponente que contém a vulnerabilidade.
• Dados da vulnerabilidade: um identificador de vulnerabilidade por declaração, normalmente uma CVE, e uma descrição ou uma ligação para uma.
• Estado, com a justificação, a declaração de impacto ou a declaração de ação que exige.
• Metadados da declaração: um identificador, uma versão e carimbos temporais da própria declaração.

Um exemplo de documento VEX

Este documento OpenVEX diz que um produto, example-api 3.2.0, distribui uma versão vulnerável de log4j-core, mas não é afetado pelo Log4Shell, porque a classe vulnerável é removida durante o build:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

O produto e o seu subcomponente são identificados por package URLs, pelo que um scanner os pode cruzar com os componentes da SBOM do produto. A mesma declaração em CycloneDX ou CSAF contém os mesmos factos numa estrutura diferente.

Formatos VEX: OpenVEX, CycloneDX VEX e CSAF VEX

O VEX é um conjunto de requisitos, não um formato de ficheiro. A CISA indica três formatos que o podem transportar, e não são intercambiáveis:

	OpenVEX	CycloneDX VEX	CSAF VEX
O que é	Um pequeno formato JSON criado apenas para VEX	A secção vulnerabilities de um documento CycloneDX	O perfil csaf_vex da norma de avisos de segurança CSAF
Norma	Especificação aberta, v0.2.0	ECMA-424 (CycloneDX 1.6 e posteriores)	OASIS Standard (CSAF 2.0, 2022)
Estados	Os quatro estados VEX	Os seus próprios estados de análise: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Listas de estado do produto: known_not_affected, known_affected, fixed, under_investigation
Justificações	As cinco justificações da CISA	Nove próprias, como code_not_reachable e requires_configuration	As cinco justificações da CISA, como flags
Adequado a equipas que	Querem o ficheiro VEX mais pequeno possível	Já distribuem SBOM CycloneDX	Já publicam avisos de segurança CSAF
Lido pelo Trivy	Sim	Sim, em análises de SBOM	Sim
Lido pelo Grype	Sim	Não indicado	Sim

O OpenVEX é o mais leve: um documento com um autor, um carimbo temporal, uma versão e uma lista de declarações. A sua especificação trata o VEX como uma sequência de declarações, cada uma das quais substitui as anteriores ou acrescenta algo a elas.

O CycloneDX VEX usa a mesma estrutura vulnerabilities que o CycloneDX usa para tudo o resto, com um objeto analysis que contém um estado, uma justificação, valores de resposta como update ou will_not_fix e pormenores em texto livre. Os dados VEX podem estar dentro da SBOM ou num documento CycloneDX separado que aponta para a SBOM com BOM-Link. Note que o seu vocabulário de justificações não é o da CISA, pelo que a conversão de ou para OpenVEX ou CSAF exige um mapeamento. Consulte CycloneDX vs SPDX para o lado da SBOM.

O CSAF VEX é um documento CSAF completo com a categoria csaf_vex. Exige uma árvore de produtos, uma CVE ou outro identificador, notas e, para cada produto, uma declaração de impacto (se não for afetado) ou uma remediação (se for afetado). É mais pesado do que o OpenVEX, mas adequa-se a organizações que já distribuem avisos de segurança CSAF através de um fornecedor CSAF.

VEX vs VDR

Um Vulnerability Disclosure Report (VDR) lista as vulnerabilidades que afetam um produto, juntamente com a sua análise e remediação. O NIST SP 800-161 recomenda os VDR como prática para a cadeia de abastecimento, e o CycloneDX suporta ambos. A diferença, nas palavras dos exemplos do CycloneDX:

• O VDR diz que vulnerabilidades afetam o produto. Pode cobrir vulnerabilidades encontradas no seu próprio código que nunca foram publicadas noutro lado.
• O VEX é sobretudo uma declaração negativa: que vulnerabilidades conhecidas não afetam o produto, e porquê. Cobre apenas vulnerabilidades conhecidas.

Muitos fornecedores publicam ambos: o VDR responde a "o que preciso de corrigir", o VEX responde a "o que posso ignorar".

Como os scanners consomem VEX

Um documento VEX só poupa trabalho se as ferramentas do cliente o lerem. Dois scanners open source amplamente usados fazem-no:

• O Trivy aceita VEX através da sua opção --vex (marcada como experimental), a partir de um ficheiro local, um repositório VEX, uma atestação OCI ou uma referência na SBOM. Lê OpenVEX, CycloneDX VEX em análises de SBOM e CSAF VEX, e deixa de reportar vulnerabilidades marcadas como not_affected.
• O Grype aceita OpenVEX e CSAF VEX através de --vex. Move as correspondências not_affected e fixed para uma lista de ignorados, mostrada com --show-suppressed, e pode opcionalmente acrescentar declarações affected e under_investigation aos resultados.

A correspondência depende dos identificadores. Se o VEX indicar o produto com um identificador diferente do usado pela SBOM, o scanner não os consegue ligar e a conclusão mantém-se.

Quem publica VEX

O VEX vem normalmente do fornecedor: o vendedor, a distribuição open source ou o fabricante do dispositivo que distribui o produto. Dentro do fornecedor, é uma tarefa do PSIRT, parte do mesmo ciclo de vida da gestão de vulnerabilidades que produz avisos de segurança e correções. A Red Hat, por exemplo, publica documentos CSAF VEX num diretório dedicado do seu feed CSAF, ao lado dos seus avisos de segurança. Para saber o que os engenheiros de PSIRT fazem no dia a dia, consulte papel do PSIRT.

Os clientes também escrevem VEX para uso próprio, registando decisões de triagem sobre o produto de um fornecedor para que o seu scanner deixe de as assinalar. Regulamentos como o Cyber Resilience Act da UE pedem aos fabricantes que tratem as vulnerabilidades dos componentes que distribuem, e o VEX é uma forma de dizer aos utilizadores quais se aplicam.

Manter o VEX atualizado

• Os estados mudam. Uma declaração começa normalmente como under_investigation e termina como not_affected, ou como affected e depois fixed. Publique cada alteração; a CISA exige que a versão aumente de cada vez.
• Novas versões exigem novas declarações. Um veredito not_affected para a 3.2.0 nada diz sobre a 3.3.0. Volte a verificá-lo sempre que o componente, a sua versão ou a configuração de build mudarem.
• Mantenha o VEX separado da SBOM. A SBOM descreve uma versão e mantém-se fixa. O VEX continua a mudar depois do lançamento, pelo que publicá-lo como documento próprio evita reemitir SBOM.
• Publique onde as ferramentas procuram. Ao lado da SBOM, como atestação na imagem de contentor ou no seu feed de avisos de segurança, e indique onde na sua política de divulgação. Consulte divulgação coordenada de vulnerabilidades.

Limites do VEX

• É uma afirmação, não uma prova. Uma declaração not_affected é a avaliação do autor. A CISA recomenda ligar criptograficamente a identidade do autor ao documento, mas a maioria dos consumidores continua a confiar no VEX porque confia no fornecedor.
• O silêncio nada significa. O VEX não implica nenhum estado predefinido. Uma vulnerabilidade sem declaração tem estado desconhecido, o que não quer dizer que o produto não seja afetado.
• Os formatos não têm correspondência direta. O CycloneDX usa estados e justificações diferentes dos do OpenVEX e do CSAF, pelo que as conversões perdem detalhe.
• Só é tão bom quanto o inventário. Dizer que um componente não está presente exige saber exatamente o que o produto contém, incluindo as dependências transitivas e tudo o que o build descarregou fora do gestor de pacotes.

O VEX começa com uma SBOM exata

Cada declaração VEX aponta para componentes, e a justificação mais fácil de defender, component_not_present, só é verdadeira se o inventário estiver completo. Uma SBOM gerada pela análise posterior de lockfiles pode listar dependências de desenvolvimento que nunca são distribuídas e não ver pacotes que o build obteve de outra forma.

O CRACI executa builds de GitHub Actions nos seus próprios runners e regista os pacotes que cada job realmente obteve, incluindo dependências transitivas, pacotes restaurados de caches e dependências que nenhum lockfile lista. Cada SBOM tem um estado de completude e pode ser exportada em CycloneDX ou SPDX. As SBOM monitorizadas são continuamente reavaliadas, o histórico de builds mostra que builds anteriores continham uma dependência vulnerável, e o CRACI suporta VEX. Consulte geração de SBOM e acompanhamento de vulnerabilidades.

VEX: perguntas frequentes

O que significa VEX?

VEX significa Vulnerability Exploitability eXchange. É uma declaração legível por máquina sobre se um produto é afetado por uma vulnerabilidade conhecida específica, publicada para que os utilizadores saibam que vulnerabilidades reportadas exigem ação.

Qual é a diferença entre uma SBOM e o VEX?

Uma SBOM lista os componentes de um produto. O VEX diz, para uma determinada vulnerabilidade, se esse produto é afetado. A SBOM raramente muda depois de um lançamento; as declarações VEX mudam à medida que o fornecedor investiga e corrige. É por isso que o VEX é normalmente publicado como documento separado que se refere ao produto, em vez de integrado na SBOM.

Quais são os quatro estados VEX?

not_affected, affected, fixed e under_investigation. Uma declaração not_affected precisa de uma justificação ou de uma declaração de impacto, e uma declaração affected precisa de uma declaração de ação que diga o que os utilizadores devem fazer.

Que formato VEX devo usar?

Use o que os seus consumidores e ferramentas leem. O OpenVEX é o mais pequeno e funciona com o Trivy e o Grype. O CycloneDX VEX adequa-se a equipas que já distribuem SBOM CycloneDX. O CSAF VEX adequa-se a organizações que já publicam avisos de segurança CSAF, o que é comum em software industrial e empresarial. Muitos fornecedores acabam por converter entre eles.

O VEX é o mesmo que um aviso de segurança?

Não. Um aviso de segurança explica uma vulnerabilidade, quem é afetado e como a corrigir, sobretudo para pessoas. O VEX é um estado restrito e legível por máquina por produto e vulnerabilidade, sobretudo para ferramentas. Os dois andam muitas vezes juntos: a norma CSAF tem um perfil de aviso de segurança e um perfil VEX.

Quem escreve documentos VEX?

Normalmente, o fornecedor do produto, muitas vezes a sua equipa de resposta a incidentes de segurança de produto (PSIRT), porque sabe como o produto é compilado e configurado. Os requisitos mínimos da CISA permitem também que terceiros sejam autores de VEX, e cada documento tem de indicar o seu autor.

Os scanners de vulnerabilidades leem VEX?

Vários leem. O Trivy aceita OpenVEX, CycloneDX e CSAF VEX através da sua opção --vex e elimina as conclusões marcadas como not_affected. O Grype aceita OpenVEX e CSAF VEX através de --vex e move as conclusões not_affected e fixed para uma lista de ignorados.