A Reality Check on SBOM-based Vulnerability Management: An Empirical Study and A Path Forward

Título: Uma Verificação da Realidade na Gestão de Vulnerabilidades Baseada em SBOM: Um Estudo Empírico e um Caminho a Seguir

1. O Problema

O Software Bill of Materials (SBOM) é uma ferramenta crítica para a segurança da cadeia de suprimentos de software (SSC), destinada a listar todos os componentes de software (diretos e transitivos) utilizados em um projeto. No entanto, a utilidade prática do SBOM está sendo comprometida por dois problemas fundamentais:

1. Inconsistência e Imprecisão na Geração: Estudos anteriores mostram que diferentes geradores de SBOM produzem resultados inconsistentes quando alimentados com arquivos de manifesto de projeto (ex: requirements.txt, package.json). Isso ocorre porque esses arquivos definem apenas dependências diretas e intervalos de versão, deixando a resolução de dependências transitivas para o momento da instalação, o que gera ambiguidade.
2. Taxa Extremamente Alta de Falsos Positivos: Mesmo quando um SBOM preciso é gerado, os scanners de vulnerabilidade downstream (que comparam o SBOM com bancos de dados de vulnerabilidades) produzem uma quantidade massiva de alertas irrelevantes. O problema central é que esses scanners operam apenas no nível do pacote/versão, ignorando se o código vulnerável específico dentro do pacote é, na verdade, alcançável (invocado) pela aplicação. Isso resulta em fadiga de alerta, onde desenvolvedores ignoram avisos críticos devido ao ruído excessivo.

2. Metodologia

Os autores realizaram um estudo empírico em larga escala envolvendo 2.414 repositórios de código aberto em quatro linguagens de programação (Python, Rust, Ruby e PHP). A metodologia foi dividida em duas fases principais:

• Fase 1: Validação da Geração de SBOM (Precisão)

  • Hipótese: O uso de arquivos de bloqueio (lock files) gerados por gerenciadores de pacotes "fortes" (Strong PMs) como entrada para geradores de SBOM eliminaria inconsistências.
  • Ferramentas: Utilizaram os geradores populares Syft e Trivy.
  • Processo:
    1. Coletaram repositórios com arquivos de projeto e/ou lock files.
    2. Para repositórios sem lock file, utilizaram scripts automatizados para gerar lock files a partir dos arquivos de projeto usando gerenciadores fortes (Poetry para Python, Cargo para Rust, Bundler para Ruby, Composer para PHP).
    3. Geraram SBOMs a partir desses lock files.
    4. Compararam os SBOMs gerados com a "verdade fundamental" (Ground Truth) extraída diretamente dos lock files usando métricas de Similaridade de Jaccard e Precisão.

• Fase 2: Validação de Vulnerabilidades (Falsos Positivos)

  • Ferramentas: Utilizaram os scanners Grype e Trivy sobre os SBOMs gerados na Fase 1.
  • Validação Manual: Selecionaram uma amostra representativa de 16 repositórios (4 por linguagem) para uma verificação manual profunda.
  • Análise de Alcançabilidade: Para cada vulnerabilidade reportada, os autores verificaram manualmente se as funções vulneráveis específicas estavam sendo chamadas no código-fonte.
  • Análise Automatizada (Go): Realizaram uma prova de conceito automatizada em 12 projetos Go, onde o banco de dados de vulnerabilidades fornece metadados estruturados de símbolos, para validar a viabilidade da análise de alcançabilidade automatizada.

3. Principais Contribuições

1. Estabelecimento de uma Base de Alta Fidelidade: Demonstraram empiricamente que o uso de lock files como entrada primária permite que geradores de SBOM (Syft e Trivy) produzam resultados idênticos e 100% precisos em relação à verdade fundamental, eliminando a variabilidade observada em estudos anteriores que usavam arquivos de manifesto.
2. Quantificação da Taxa de Falsos Positivos: Revelaram que, mesmo com SBOMs perfeitos, os scanners de vulnerabilidade atuais apresentam uma taxa de falsos positivos de 92,0% em sua amostra validada.
3. Identificação da Causa Raiz: Pinpointaram que a principal causa dos falsos positivos é a falta de análise de código inalcançável (unreachable code). Os scanners alertam sobre pacotes vulneráveis mesmo que a função específica vulnerável nunca seja chamada pela aplicação.
4. Proposta de Pipeline Prático: Validaram que a análise de chamadas de função (function call analysis) pode reduzir os falsos positivos em 61,9% (e até 74,4% em projetos Go), propondo um pipeline de duas etapas para segurança da cadeia de suprimentos.

4. Resultados Chave

• Consistência e Precisão do SBOM:
  • Ao usar lock files, a Similaridade de Jaccard entre Syft e Trivy foi de 1,0 (perfeita) em todas as linguagens testadas.
  • A precisão dos SBOMs gerados contra a verdade fundamental foi de 100% para todas as linguagens (Python, Rust, Ruby, PHP).
  • Nota: Projetos Python que usam apenas requirements.txt (gerenciador fraco) geram SBOMs incompletos. A migração para gerenciadores fortes (como Poetry) é essencial.
• Taxa de Falsos Positivos:
  • Dos 113 alertas de vulnerabilidade reportados pelos scanners em 16 repositórios, apenas 9 foram confirmados como verdadeiros positivos após análise manual.
  • 92,0% dos alertas eram falsos positivos.
  • A análise de alcançabilidade (verificando se a função vulnerável é chamada) eliminou 61,9% desses falsos positivos restantes, reduzindo o ruído de 113 para 42 alertas.
• Caso de Estudo (Python): Um repositório Python popular (gym) que usava pip (fraco) e requirements.txt gerou um SBOM com apenas 5 dependências (de 15 listadas) e falhou em detectar dependências transitivas. Ao migrar para o gerenciador forte Poetry e gerar um lock file, o SBOM resultante foi preciso (32 dependências) e a varredura de vulnerabilidades mostrou que o repositório estava seguro (nenhuma vulnerabilidade encontrada).

5. Significado e Recomendações

O estudo conclui que o SBOM por si só não é uma "bala de prata" para a segurança da cadeia de suprimentos. O problema atual não é apenas a geração do SBOM, mas a falta de contexto na análise de vulnerabilidades.

Caminho a Seguir (Pipeline Proposto):

1. Etapa 1: Geração de SBOM Precisa (Ground Truth):
   • Desenvolvedores devem padronizar o uso de Gerenciadores de Pacotes Fortes que geram lock files.
   • Os lock files devem ser o único arquivo de entrada para geradores de SBOM, garantindo que o SBOM reflita exatamente o que está em produção.
2. Etapa 2: Análise de Alcançabilidade (Reachability Analysis):
   • Ferramentas de segurança devem evoluir além da correspondência de versões de pacotes.
   • É necessário implementar análise de chamadas de função (estática ou dinâmica) para determinar se o código vulnerável é realmente executado.
   • Isso transformará alertas ruidosos em inteligência acionável, reduzindo a fadiga de alerta e permitindo que os desenvolvedores foquem em riscos reais.

Limitação Atual e Chamada para Ação:
A automação da análise de alcançabilidade é dificultada pela falta de metadados estruturados (símbolos afetados) nos bancos de dados de vulnerabilidades atuais (como NVD e GHSA), que geralmente fornecem apenas texto não estruturado. Os autores chamam a comunidade para padronizar a inclusão de metadados de símbolos afetados nos avisos de vulnerabilidade para permitir a automação em larga escala.

Em resumo, o artigo fornece evidências empíricas robustas de que a segurança da cadeia de suprimentos exige uma mudança de paradigma: de uma abordagem baseada apenas em "pacotes presentes" para uma abordagem baseada em "código executável", fundamentada em lock files precisos.