Um SBOM (Software Bill of Materials) é a «lista de ingredientes» do seu software: o inventário completo de pacotes, bibliotecas, versões e dependências que uma imagem contém. Tal como um rótulo nutricional, diz-lhe exatamente o que leva lá dentro.
O seu valor torna-se evidente no dia de uma vulnerabilidade crítica: em vez de rastrear à mão dezenas de imagens, consulta o SBOM e sabe em segundos que imagens contêm o componente afetado e em que versão.
Porque importa para as suas imagens
- Resposta rápida a CVE: identifica de imediato se uma nova vulnerabilidade o afeta.
- Segurança da cadeia de fornecimento: sabe de onde vem cada componente.
- Conformidade: cada vez mais referenciais e clientes o pedem como evidência.
- Transparência: se publica imagens, um SBOM gera confiança em quem as usa.
Formatos padrão
| Formato | Origem | Notas |
|---|---|---|
| SPDX | Linux Foundation / ISO | Padrão ISO, muito usado em conformidade |
| CycloneDX | OWASP | Orientado a segurança, rico para análise de vulnerabilidades |
Os dois formatos SBOM dominantes; muitas ferramentas exportam para ambos.
Como gerar o SBOM de uma imagem, passo a passo
- Escolha a ferramenta: o Syft, da Anchore, é um padrão de facto para gerar SBOM de imagens e sistemas de ficheiros; há também opções nativas da nuvem.
- Gere na pipeline: durante o build da AMI, analise o sistema de ficheiros e produza o SBOM, por exemplo em CycloneDX e SPDX.
- Analise vulnerabilidades: passe o SBOM pelo Grype ou Trivy para o cruzar com bases de CVE.
- Assine e arquive: assine o SBOM —por exemplo com cosign— e guarde-o como artefacto associado à versão da imagem.
- Consulte quando for preciso: perante um novo CVE, reveja os SBOM arquivados para saber o alcance.
O contexto regulatório de 2026
O SBOM ganha peso há anos como boa prática de segurança da cadeia de fornecimento. O panorama regulatório é, contudo, matizado: nos Estados Unidos a administração reviu em 2026 os mandatos herdados de atestação de software rumo a uma abordagem mais baseada em risco, enquanto na União Europeia normas como o Cyber Resilience Act empurram a transparência do software e o inventário de componentes. Conclusão prática: independentemente do vaivém normativo, ter SBOM é uma vantagem defensiva e comercial que convém adotar.
Boas práticas
- Gere o SBOM automaticamente em cada build, não à mão.
- Guarde-o versionado junto da imagem a que corresponde.
- Combine-o com análise de vulnerabilidades para que seja acionável.
- Assine-o para garantir a sua integridade e proveniência.
Perguntas frequentes
Um SBOM é o mesmo que uma análise de vulnerabilidades?
Não. O SBOM é o inventário de componentes; a análise cruza esse inventário com bases de CVE para detetar vulnerabilidades. Complementam-se: primeiro sabe o que tem, depois se é vulnerável.
SPDX ou CycloneDX?
O SPDX é um padrão ISO muito usado em conformidade; o CycloneDX é mais orientado a segurança. Muitas ferramentas exportam para ambos, por isso não tem de escolher só um.
Preciso de um SBOM se só consumo imagens de terceiros?
Sim. Pedir ou gerar o SBOM das imagens que usa permite-lhe avaliar o seu risco e responder depressa a vulnerabilidades, mesmo que não as tenha construído.
Na imaxe.cloud apostamos na rastreabilidade: inventariar e documentar o software das nossas imagens faz parte de as construir bem.
