SBOM e VEX: componentes e impacto das vulnerabilidades

Sytance · Atualizado

Uma SBOM identifica os componentes de software de um produto. Vulnerability Exploitability eXchange (VEX) comunica se uma vulnerabilidade específica afeta esse produto. A avaliação depende da versão do produto, da configuração e da forma como utiliza o componente.

Inventário, correspondência e impacto dos componentes

O inventário regista se um componente está presente. Uma correspondência de vulnerabilidade indica que um aviso identifica o componente ou a respetiva versão. A análise de impacto verifica depois se o código vulnerável está presente e pode ser explorado na compilação e utilização efetivas do produto.

O CycloneDX utiliza VEX para comunicar a avaliação de um produto específico. Por exemplo, um componente pode estar presente, embora uma funcionalidade vulnerável opcional tenha sido excluída durante a compilação. Esta distinção exige informações e análise da compilação.

Os quatro estados OpenVEX

O OpenVEX define quatro estados. Cada estado aplica-se à versão do produto e à vulnerabilidade identificadas na declaração.

Estado OpenVEXSignificado
under_investigationO impacto ainda está a ser avaliado
affectedO produto identificado é afetado
fixedA versão identificada inclui uma correção
not_affectedO produto identificado não é afetado

Um descodificador opcional num gateway

Considere um gateway fictício com uma biblioteca de análise sintática que inclui um descodificador opcional. Suponha que uma vulnerabilidade afeta esse descodificador. A avaliação começa por determinar que compilação da biblioteca está presente na imagem fornecida e se o descodificador foi aí incluído.

Se as definições da compilação e a análise do binário confirmarem que o descodificador vulnerável está ausente, podem sustentar uma declaração not_affected com o motivo vulnerable_code_not_present. A declaração aplica-se a essa compilação.

Se o código estiver presente, mas não for claro se é executado, mantenha a avaliação em investigação enquanto verifica os pontos de entrada e os percursos de execução. Se o produto for afetado e uma versão posterior incluir a correção, a versão anterior continua afetada; a versão posterior recebe uma declaração própria.

Motivos para o estado not_affected

O OpenVEX exige que uma declaração not_affected inclua uma justificação ou uma declaração de impacto. As justificações legíveis por máquina distinguem componentes inexistentes, ausência de código vulnerável, código fora do percurso de execução, limites ao controlo do atacante e medidas de mitigação integradas.

Cada motivo tem condições diferentes. Uma restrição de rede não elimina o código vulnerável. Para o motivo de mitigação integrada, o OpenVEX especifica uma proteção que impede a exploração e que o utilizador não pode desativar nem reconfigurar.

Para concluir que o código está fora do percurso de execução, identifique a função afetada, os percursos verificados e os limites da configuração. Reavalie a conclusão se essas condições mudarem. Se a conclusão depender de uma definição controlada pelo cliente, comunique claramente essa dependência.

Utilização de uma declaração VEX de um fornecedor

Uma declaração VEX de um fornecedor pode ajudar a filtrar alertas ou a alterar a respetiva prioridade. Antes de a utilizar, confirme que a fonte é fidedigna e que corresponde à versão do produto. Verifique a data de publicação, as revisões, a configuração aplicável e as ações recomendadas.

Se um fornecedor fidedigno e a sua própria análise discordarem, preserve ambos os registos e resolva a divergência. Uma declaração genérica sobre uma família de produtos pode não abranger uma compilação personalizada com componentes ou opções diferentes.

Uma SBOM continua a ser útil após a publicação de uma declaração VEX. Novos avisos podem alterar o que tem de ser investigado, e uma versão revista do produto pode invalidar uma conclusão antiga. Mantenha as atualizações do inventário e as avaliações de impacto interligadas, preservando os respetivos históricos separados.

Leituras adicionais