Como a VEX transforma uma SBOM, que é uma lista de peças, em evidência de auditoria passível de verificação

Principais conclusões

• Uma declaração do Vulnerability Exploitability eXchange (VEX) atribui um status a uma vulnerabilidade em um ou mais produtos.
• Uma declaração VEX é a afirmação de seu autor; portanto, um auditor verifica quem a emitiu, se ela sofreu alterações e quais análises fundamentam essa afirmação.
• A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) define quatro status VEX, e uma declaração com o status “não afetado” deve explicar o motivo, por meio de um valor de justificativa ou de uma declaração por escrito sobre o impacto.
• Vários formatos podem conter VEX, e o CycloneDX utiliza seus próprios rótulos de status e justificação; portanto, seus documentos podem precisar ser convertidos para os nomes da CISA.
• Quando não houver uma correção do desenvolvedor original, um fornecedor pode indicar “não afetado” com uma justificativa, “afetado” com uma declaração de ação ou “corrigido” assim que uma versão corrigida estiver na compilação.

Uma lista de materiais de software (SBOM) informa o que está contido em uma versão, mas não quais das vulnerabilidades identificadas por um scanner correspondentes a esses componentes realmente se aplicam ao seu produto. O VEX (Vulnerability Exploitability eXchange) preenche essa lacuna: é a forma como um fornecedor ou terceiro declara se uma vulnerabilidade conhecida afeta um produto de software.

As orientações da CISA sobre o VEX tratam cada declaração como uma afirmação de seu autor. O grau de confiança que um leitor pode depositar em uma declaração depende de quem a emitiu, de como está assinada e de quais evidências o quadro de conformidade do auditor aceita. Neste artigo, “evidência de auditoria verificável” significa uma afirmação que o auditor pode conferir com base na análise subjacente a ela. Uma declaração VEX não constitui, por si só, uma prova.

O que é o Vulnerability Exploitability eXchange

Conforme descrito pela CISA, o VEX é uma forma de indicar o status de um produto ou componente de software em relação a uma vulnerabilidade. Nos Requisitos Mínimos para o VEX da CISA, versão 1.0.0 de abril de 2023, um documento VEX é um contêiner para uma ou mais declarações. Cada declaração transmite um único status para uma única vulnerabilidade em um ou mais produtos.

O VEX foi projetado para se integrar a SBOMs, bancos de dados de vulnerabilidades e alertas de segurança, mas a CISA afirma que não exige nenhum deles. O documento de casos de uso da CISA, de abril de 2022, descreve um documento VEX como, por si só, uma forma de alerta de segurança.

O VEX é um formato de dados. Não se trata de uma lei, e os requisitos mínimos da CISA deixam claro que não constituem uma política oficial da agência e não impõem conformidade. Os elementos mínimos da SBOM para 2026, definidos pela CISA e seus parceiros, também não incluem o VEX.

Um fornecedor ou um terceiro pode elaborar um documento VEX. O autor deve ser identificado como pessoa física ou jurídica e é responsável pelo conteúdo.

O que o VEX comprova e o que não comprova para um auditor

Como o autor é responsável pelo conteúdo de um documento VEX, tudo o que nele consta constitui uma afirmação desse autor. As orientações da CISA determinam que os documentos e declarações devem ser assinados, com a identidade do autor vinculada criptograficamente à assinatura. Também exigem um número de versão mais alto sempre que o conteúdo for alterado, além de carimbos de data e hora da primeira emissão e da última atualização. Isso permite que um auditor verifique quem fez a afirmação, quando e se ela sofreu alterações desde então.

Do documento de casos de uso da CISA: A publicação de abril de 2022 afirma que os status do VEX não têm como objetivo encerrar uma discussão. Eles existem para ajudar os consumidores a tomar decisões informadas, de modo que o leitor possa questionar um status em vez de considerá-lo definitivo.

A CISA e seus parceiros publicaram os “Elementos Mínimos para uma Lista de Componentes de Software (SBOM) de 2026” em 29 de julho de 2026. A seção intitulada “Correlação da SBOM com Alertas de Segurança” aborda o VEX e a Estrutura Comum de Alertas de Segurança (CSAF). O documento afirma que uma atualização de status ajuda a evitar esforços desnecessários quando uma fonte confiável avalia que um risco potencial não se traduz em risco real. Esse benefício depende da confiança na fonte; portanto, a identidade do emissor determina se um leitor pode agir com base em uma atualização de status.

A associação do VEX a um SBOM também requer um SBOM completo. O elemento “Cobertura” do documento de 2026 estabelece que um destinatário deve poder concluir que uma vulnerabilidade recém-relatada não o afeta se o SBOM não listar o componente, e essa conclusão só é segura se o SBOM listar tudo. O mesmo documento coloca a verificação da precisão, cobertura e integridade de um SBOM fora de seus elementos mínimos; portanto, uma declaração VEX que se baseie em um SBOM pode herdar quaisquer erros presentes no SBOM.

Além disso, uma declaração VEX se refere apenas a vulnerabilidades em um componente; portanto, não indica se o pacote que você baixou foi adulterado ou se é malicioso. Se o seu produto for desenvolvido com base em pacotes de código aberto, a confiabilidade das suas declarações VEX dependerá exclusivamente do seu registro do que foi incluído em cada compilação.

Alguns revisores também solicitam a análise por trás de cada descoberta. No caso de dispositivos médicos, a orientação não vinculativa sobre segurança cibernética pré-comercialização da Administração de Alimentos e Medicamentos dos EUA (FDA), de fevereiro de 2026, exige que os fabricantes realizem uma avaliação de riscos de segurança e proteção para cada vulnerabilidade conhecida em seus componentes, além dos controles de risco que a abordam. Um relatório sem análise por trás oferece pouco para o revisor testar; portanto, os campos que apresentam o raciocínio — abordados a seguir — são os mais importantes.

Os quatro tipos de status e o que uma declaração de não afetação deve explicar

Os requisitos mínimos da CISA, versão 1.0.0, estabelecem que cada declaração deve utilizar um dos quatro status. Dois deles exigem um detalhe específico, e a tabela mostra quais são.

O documento de casos de uso de abril de 2022 exige uma declaração de impacto para cada declaração não afetada. Os requisitos mínimos de abril de 2023 permitem que uma justificativa substitua essa declaração.

Os requisitos mínimos definem cinco valores de justificação, sendo que o último é mais rigoroso do que o próprio nome sugere:

• A mensagem “Componente ausente” é exibida quando o subcomponente vulnerável não está incluído no produto.
• A mensagem “Código vulnerável ausente” refere-se a um componente que está presente, enquanto o código vulnerável não está, geralmente porque a configuração de compilação o exclui.
• O código vulnerável que não está no caminho de execução refere-se ao código que não pode ser executado, dada a forma como o produto o utiliza.
• “Código vulnerável que não pode ser controlado pelo adversário” refere-se a um código que está presente e é utilizado, mas que um invasor não consegue manipular para explorar a vulnerabilidade.
• Já existem medidas de mitigação integradas que exigem proteções embutidas que um invasor não possa burlar, que um usuário não possa configurar ou desativar e que impeçam totalmente a exploração por meio de vetores de ataque conhecidos.

Cada valor geralmente requer um tipo diferente de comprovação: uma SBOM ou outro registro de composição, uma configuração de compilação, uma análise do caminho de chamada, uma análise do tratamento de entradas ou a própria medida de mitigação. Os requisitos da CISA permitem que uma declaração inclua notas explicativas sobre como o status foi determinado; portanto, registre essa comprovação ali mesmo ou ao lado da declaração. O valor da justificativa, por si só, não explicará ao revisor por que você fez essa afirmação.

Atribua o status de acordo com o trabalho que você já realizou. O status “Afetado” indica aos leitores que o produto está vulnerável e que o autor recomenda medidas. Não o utilize para uma constatação que você ainda não analisou: enquanto a análise estiver em andamento, marque a constatação como “em investigação”. A CISA espera que esse status seja alterado quando a investigação for concluída; portanto, uma declaração que o mantenha sem atualizações indica ao revisor que a análise pode ter estagnado.

Formatos e especificações compatíveis com o VEX

Os requisitos mínimos da CISA para 2023 indicam três formatos que podem conter ou ser usados para gerar documentos VEX: CSAF, CycloneDX e OpenVEX. Os requisitos definem seus elementos de dados independentemente de qualquer formato. O Software Package Data Exchange (SPDX), que não é mencionado na lista da CISA, também pode conter todos os quatro status: seu perfil de segurança na versão 3.0.1 possui uma classe de relação VEX para cada um deles. A especificação VEX de cada formato define seus próprios campos, e as versões e status variam.

Nem todos os formatos utilizam os rótulos da CISA. A documentação do projeto OpenVEX indica que o CycloneDX VEX define seus próprios rótulos de status e justificativa; portanto, pode ser necessário traduzir os documentos para que correspondam aos nomes da CISA. Este artigo utiliza os nomes da CISA em todo o texto. Escolha o formato com o qual sua cadeia de ferramentas e seus clientes já estão familiarizados, uma vez que os elementos de dados VEX não dependem disso.

Quando não há correção no upstream

O que você precisa comprovar depende da existência ou não de uma correção. Se o desenvolvedor original tiver publicado uma correção e você a incluir na sua versão, a declaração pode indicar que o problema foi corrigido e citar as versões do produto que a contêm. Uma declaração de correção geralmente não requer análise para determinar se o código vulnerável pode ser executado, pois aponta para uma solução. Sua comprovação é normalmente o artefato corrigido e um registro de versão. A declaração continua sendo uma afirmação do emissor; portanto, as versões exatas são importantes. O documento de casos de uso da CISA recomenda listar as versões explicitamente sempre que possível, pois intervalos de versão complexos são mais difíceis de interpretar.

Sem uma correção, você tem três opções. Você pode analisar a descoberta e indicar que não há impacto, com uma justificativa; indicar que há impacto, com uma declaração de ação; ou incorporar uma versão corrigida à sua compilação e indicar que o problema foi resolvido. A primeira opção exige uma análise que fica desatualizada à medida que o código muda. O documento de casos de uso da CISA alerta que uma declaração sobre todas as versões também abrange versões futuras e pode incluir versões que já estão no fim da vida útil. O exemplo citado é a afirmação de que um programa em Rust não pode ser afetado por uma vulnerabilidade do Java, o que se torna enganoso se uma versão posterior adotar o Java e ninguém atualizar o documento. A segunda opção tem sua própria restrição. Se a análise mostrar que seu produto está exposto, a declaração de ação não pode orientar os leitores a atualizarem para uma versão corrigida que ainda não existe. Ela deve descrever uma medida de mitigação ou outra ação que os leitores possam tomar.

A terceira dificuldade é aquela causada por componentes sem manutenção. Pode ser que ninguém no desenvolvimento original esteja criando a correção de que você precisaria; portanto, alguém precisa aplicar um patch na versão que você utiliza e, em seguida, confirmar se ela ainda se comporta da maneira esperada pelo seu produto. A alternativa à aplicação de um patch é substituir o componente, o que geralmente implica em retrabalho em todos os pontos do seu código onde ele é utilizado.

Uma ordem prática quando você é quem faz as afirmações:

1. Certifique-se de que a SBOM corresponda ao que é entregue. Se algum componente estiver listado por engano, corrija a SBOM em vez de emitir uma declaração de que esse componente não foi afetado.
2. Aplique as correções disponíveis e, em seguida, emita comunicados de correção indicando as versões que as contêm.
3. Para componentes sem correção, opte entre incluir uma versão corrigida em sua compilação, verificar se há uma declaração de “não afetado” ou emitir uma declaração de “afetado” acompanhada de uma ação.
4. Marque como “em investigação” tudo o que ainda estiver em análise e atualize a declaração quando o trabalho estiver concluído. Qualquer alteração aumenta a versão do documento.

Cada etapa deixa um registro que um auditor pode verificar: a SBOM corrigida, as versões corrigidas, a análise nas notas de status e o histórico de versões do documento.

Controlando o que entra na compilação

Como o status VEX não consegue indicar se um pacote foi adulterado ou se corresponde ao código-fonte publicado pelo projeto, a integridade da compilação precisa de um mecanismo de controle próprio.

O SecureChain da TuxCare analisa o código-fonte de cada pacote em busca de malware e padrões de código suspeitos, bloqueia qualquer pacote que não passe na verificação e recompila o restante a partir do código-fonte em ambientes isolados e reforçados. Enquanto o desenvolvedor original continuar lançando correções, o SecureChain aplica os patches em cada pacote de acordo com um SLA contratual. Todos os pacotes são entregues com proveniência de Nível 3 do SLSA (Níveis da Cadeia de Suprimentos para Artefatos de Software), SBOMs e declarações VEX. Para a terceira opção acima, quando o desenvolvedor original deixa de corrigir um componente, o SecureChain transfere automaticamente para o Suporte de Ciclo de Vida Ilimitado (ELS), que continua fornecendo correções após o término da manutenção do desenvolvedor original. A cobertura abrange os ecossistemas JavaScript, Python, Java, Go e PHP.

Se você não souber dizer o que foi incluído em uma compilação, ou se suas descobertas ficarem paralisadas porque os pacotes do upstream deixaram de receber correções, pergunte à nossa equipe como o SecureChain lida com isso.

Perguntas frequentes

O VEX é obrigatório por lei?

O formato Vulnerability Exploitability eXchange (VEX) não é uma lei. A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) afirma que seus requisitos mínimos para o VEX não constituem uma política oficial e não exigem conformidade, e que os elementos mínimos da lista de materiais de software (SBOM) para 2026 não incluem o VEX como um campo obrigatório. No entanto, um contrato com o cliente ainda pode exigir seu uso.

Quem pode escrever uma instrução VEX?

Uma declaração do Vulnerability Exploitability eXchange (VEX) pode ser emitida pelo fornecedor do software ou por um terceiro, de acordo com a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA). O autor deve ser identificado como pessoa física ou jurídica e é responsável pelo conteúdo. O autor também pode indicar uma função, como, por exemplo, “fornecedor”.

O que há em um arquivo VEX?

Um arquivo do Vulnerability Exploitability eXchange (VEX) — que a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) denomina “documento VEX” — contém metadados do documento e pelo menos uma declaração. Cada declaração indica um status para uma vulnerabilidade em um ou mais produtos, além de quaisquer detalhes necessários para esse status, como uma declaração de ação ou uma justificativa.

O que significa quando uma vulnerabilidade não possui status VEX?

Não é possível tirar nenhuma conclusão disso. A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) afirma que o Vulnerability Exploitability eXchange (VEX) não implica nenhum status padrão além do que uma declaração especifica explicitamente, e um documento pode estar incompleto. Uma vulnerabilidade sem declaração não foi declarada como não afetada.

Um documento VEX precisa de assinatura?

A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) afirma que os documentos e declarações do Vulnerability Exploitability eXchange (VEX) devem ser assinados, o que torna a assinatura uma recomendação. A identidade do autor deve estar vinculada à assinatura, e a assinatura de um documento deve abranger todos os seus metadados e declarações. As implementações devem oferecer suporte a mecanismos de assinatura comumente aceitos.

É possível usar o VEX sem um SBOM?

Sim. A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) afirma que o Vulnerability Exploitability eXchange (VEX) foi projetado para se integrar a uma lista de materiais de software (SBOM), bancos de dados de vulnerabilidades e alertas de segurança, mas não exige nenhum desses elementos. Quando houver uma SBOM, os identificadores de produto do VEX devem fazer referência aos identificadores já existentes nela.

Resumo

Nome do artigo

Como a VEX transforma uma SBOM em evidência de auditoria passível de teste

Descrição

Saiba como o VEX (Vulnerability Exploitability eXchange) indica se uma vulnerabilidade afeta seu produto e o que ele pode ou não comprovar.

Autor

Artem Karasev

Nome da editora

TuxCare

Logotipo da editora