Lista de materiais de software (SBOM)

Uma Lista de Materiais de Software (SBOM) é um inventário formal e legível por máquina de cada componente contido em um software: bibliotecas, suas versões, licenças e informações do fornecedor.

Assim como o rótulo de um alimento lista seus ingredientes, um SBOM permite responder em segundos: este produto contém a versão vulnerável de X? Sem um SBOM, essa pergunta pode exigir dias de investigação manual.

Quando surge uma vulnerabilidade crítica, a primeira questão operacional é a exposição: quais dos nossos produtos distribuem o componente afetado?

Durante o incidente Log4Shell, as organizações que tinham SBOMs consultaram seus inventários e fizeram a triagem em poucas horas. As que não tinham passaram semanas pesquisando diretórios de compilação. Órgãos reguladores e grandes compradores exigem cada vez mais SBOMs como condição de aquisição.

• Análise rápida do impacto de vulnerabilidades
• Conformidade de licenças e acompanhamento de obrigações
• Transparência da cadeia de fornecimento para clientes e auditores

Dois padrões abertos predominam. As ferramentas geralmente conseguem converter de um para o outro.

• SPDX — um padrão da Fundação Linux, forte em licenciamento e amplamente aceito pelos órgãos reguladores
• CycloneDX — um padrão da OWASP, voltado para segurança, que oferece suporte a dados de vulnerabilidades e relações entre dependências

Evite inventar seu próprio formato; consumidores e ferramentas de varredura esperam esses padrões.

Cada entrada de componente deve conter informações de identidade suficientes para ser comparada com fontes de vulnerabilidades. Os campos principais:

• nome e versão — exatos, não um intervalo
• PURL (URL de pacote) — um identificador universal, como pkg:npm/lodash@4.17.21
• resumo criptográfico — para verificar a integridade
• licença — identificador de licença SPDX
• fornecedor — quem o produziu

Gere SBOMs automaticamente a partir do código-fonte ou de um artefato compilado. Syft é um gerador comum para vários ecossistemas que produz ambos os padrões.

Um SBOM gerado em diferentes etapas registra realidades diferentes.

• SBOM do código-fonte — o que o manifesto declara; pode não incluir código agrupado ou incorporado
• SBOM de compilação — o que a compilação realmente incorporou; é o mais preciso para o lançamento
• SBOM de execução / implantado — o que está de fato presente na imagem em execução, incluindo pacotes do OS

Para garantir a cadeia de fornecimento, gere o SBOM durante a compilação a partir do artefato real e analise também o contêiner final quanto a pacotes no nível do OS.

Um SBOM se torna poderoso quando é fornecido a um mecanismo de correspondência que associa componentes a CVEs conhecidas. Isso desacopla a geração da análise: você pode analisar um SBOM antigo no dia em que uma nova CVE for divulgada.

Um SBOM pode mostrar um componente vulnerável que não é realmente explorável no seu produto (a função vulnerável nunca é chamada). Um documento VEX (Intercâmbio de Explorabilidade de Vulnerabilidades eXchange) registra essa avaliação.

O VEX reduz o ruído: em vez de cada cliente entrar em pânico por causa de uma CVE listada, você publica uma declaração de not_affected com justificativa ou de affected com remediação. Isso transforma um inventário bruto em uma triagem que permite agir.

Um SBOM só é confiável se for autêntico e estiver associado ao artefato exato que descreve. Assine-o e anexe-o como um atestado, em vez de um arquivo avulso.

SBOMs manuais ficam desatualizados imediatamente. Integre a geração ao fluxo de entrega para que cada lançamento produza e armazene um SBOM como artefato de compilação, de preferência assinado e analisado na mesma tarefa.

• Gere a partir do artefato compilado, não apenas do repositório
• Armazene SBOMs em um registro consultável, indexado pela versão
• Faça novas varreduras periódicas nos SBOMs armazenados, usando fontes atualizadas de CVEs
• Condicione os lançamentos ao resultado da varredura de vulnerabilidades

Os SBOMs falham silenciosamente quando são tratados como um mero item de uma lista de verificação.

• Desatualizado — gerado uma vez e nunca regenerado
• Incompleto — não inclui pacotes do OS nem código vinculado estaticamente ou incorporado
• Não verificado — não há resumo criptográfico que o associe ao artefato implantado
• Não utilizado — produzido, mas nunca analisado nem consultado

O objetivo é um SBOM preciso, regenerado, assinado e analisado continuamente, não um arquivo JSON avulso.

Aplique o que aprendeu a um cenário de incidente.

Agora você pode fazer um inventário do conteúdo do seu software e agir com base nele.

• Um SBOM é uma lista legível por máquina de cada componente, no formato SPDX ou CycloneDX
• Identifique os componentes por PURL, versão, resumo criptográfico e licença
• Gere durante a compilação e depois forneça o SBOM a um mecanismo de correspondência (grype, osv-scanner) para identificar CVEs
• Use VEX para declarar a explorabilidade real e reduzir falsos alarmes
• Assine e automatize na integração contínua; faça novas varreduras nos SBOMs armazenados usando fontes atualizadas

A seguir: comprovar a origem dos artefatos por meio da assinatura.