Listas de materiais de software (SBOM): o inventário da sua própria cadeia de suprimentos

O que é

Uma lista de materiais de software (Software Bill of Materials, SBOM) é a lista de peças de um produto de software: pacotes, versões, fornecedores, licenças, checksums e as relações entre eles («contém», «depende de»). Dois formatos se firmaram. O SPDX, da Linux Foundation, é, segundo o site do projeto, um padrão internacional de acesso livre, publicado como ISO/IEC 5962:2021; suas raízes estão na gestão de licenças. O CycloneDX é um projeto da OWASP, padronizado como ECMA-424 conforme o site do projeto, que descreve, além da SBOM, listas de materiais para serviços, hardware e criptografia, bem como o Vulnerability Exploitability eXchange (VEX) – um documento com o qual um fabricante informa se uma vulnerabilidade reportada é de fato explorável no seu produto. Como complemento, o framework SLSA define níveis para o comprovante de procedência (provenance): uma declaração sobre qual build, a partir de qual código-fonte, gerou o artefato.

Por que importa

Quando se descobre uma vulnerabilidade numa biblioteca amplamente usada, a primeira pergunta é: onde essa versão está em execução? Sem lista de materiais, a resposta é «recompilar todos os projetos e varrê-los»; com a lista, basta uma consulta sobre os arquivos armazenados. O mesmo inventário responde a questões de licença (atribuição, copyleft) e, segundo relatos comuns, é cada vez mais exigido como item de entrega. Só que a lista, sozinha, não diz se um componente está inalterado e se vem da fonte esperada; para isso é preciso o comprovante de procedência.

Como aplicar

• Gerar a lista de materiais na execução do release, e a partir do artefato compilado (imagem de contêiner, wheel, JAR), não apenas do arquivo de manifesto: só assim aparecem a imagem base, os pacotes do sistema e os componentes embutidos que o manifesto desconhece.
• Definir um formato internamente e exportar o outro quando necessário; ambos os projetos mantêm listas de ferramentas e conversores.
• Guardar o arquivo junto do artefato, com o mesmo identificador de versão, e assiná-lo se os artefatos forem assinados.
• Cruzar regularmente as listas de todas as versões entregues com bancos de dados de vulnerabilidades; registrar como declaração VEX os achados que, após análise, não são exploráveis, para que o mesmo achado não seja reavaliado toda semana.
• Formular regras de licença como verificação automática sobre a lista (licenças permitidas, a revisar, proibidas).
• Manter lockfiles e instalações com verificação de hash; a lista de materiais documenta, mas não impõe nada.

Armadilhas

Uma lista gerada a partir do manifesto do código-fonte diverge do conteúdo real da imagem. Listas envelhecem: valem para exatamente um build, não para «a aplicação». As ferramentas muitas vezes não reconhecem bibliotecas copiadas para dentro do projeto ou renomeadas. Um achado no cruzamento é uma pergunta, não um diagnóstico: só a verificação de se o caminho vulnerável é alcançável no próprio produto define a urgência, e é exatamente para isso que o VEX existe.