Boas práticas de SBOM

Gerar SBOM

1. Gere na CI, para cada versão

Uma SBOM criada à mão fica desatualizada antes de alguém a ler. Faça dela um passo do pipeline que compila a versão, ou use um runner que a produza sem passo nenhum, para que nenhuma versão seja distribuída sem ela. Para GitHub Actions, consulte como gerar uma SBOM no GitHub Actions.

2. Descreva o build que foi distribuído

Por defeito, os builds não são reprodutíveis. Compilar o mesmo commit duas vezes não garante as mesmas dependências, porque as versões são resolvidas no momento do build e os passos podem variar. Uma SBOM feita num portátil ou numa análise posterior descreve um build semelhante, não aquele que distribuiu. Só uma SBOM do build de CI que produziu a versão prova o que nela se encontra. Consulte SBOM geradas durante o build.

3. Cubra mais do que o lockfile

Um lockfile não é um registo do que foi distribuído. Os scripts de instalação descarregam código, os scripts de build do Rust obtêm ficheiros e os builds de contentores trazem uma imagem base com os seus próprios pacotes de sistema operativo. Decida o que a SBOM tem de cobrir e depois teste-o: procure na sua SBOM um pacote da sua imagem base e uma ferramenta de build.

4. Inclua as dependências transitivas e as relações

As vulnerabilidades costumam estar abaixo das suas dependências diretas. Uma lista plana mostra que um componente está presente, mas não o que deve atualizar. Mantenha o grafo de dependências na SBOM, para que uma conclusão venha acompanhada do pacote que a traz.

5. Indique o que não conseguiu ver

Os 2026 Minimum Elements pedem aos autores de SBOM que identifiquem explicitamente a informação desconhecida. Uma SBOM parcial que o admite vale mais do que uma SBOM parcial que parece concluída. Registe também a ferramenta, a sua versão e o contexto de geração, para que quem lê possa avaliar o que o ficheiro cobre.

Conservar SBOM

6. Mantenha uma SBOM por versão, associada ao artefacto

Quando um cliente com uma versão antiga pergunta se está exposto, precisa da SBOM dessa versão, não da mais recente. Armazene cada SBOM com o build e o artefacto que descreve, e decida durante quanto tempo a conserva em função do tempo de suporte da versão. Os hashes na SBOM ajudam a associá-la ao artefacto exato.

7. Escolha um formato e um identificador, e mantenha-os

Normalize em CycloneDX ou SPDX, numa versão do formato e em package URLs como identificadores. A maior parte das dificuldades em comparar SBOM vem de ferramentas que dão nomes diferentes à mesma coisa. Valide cada ficheiro no pipeline e peça o mesmo formato aos fornecedores.

Usar SBOM

8. Monitorize o que foi distribuído, não apenas o que está a compilar

O momento mais valioso para uma SBOM é o dia a seguir à publicação de um aviso de segurança sobre software lançado no ano passado. Nesse momento, uma análise num pull request não ajuda. Reavalie as SBOM armazenadas das versões suportadas face aos novos dados de vulnerabilidades, para que um novo aviso se transforme numa lista de versões afetadas.

9. Encaminhe as conclusões para um responsável e registe a decisão

Uma SBOM com mil vulnerabilidades correspondentes é uma lista, não um plano. Ordene as conclusões com um método de priorização, envie cada uma à equipa responsável pela correção e registe por que motivo não agiu sobre as restantes, por exemplo numa declaração VEX.

10. Use a mesma SBOM para clientes e auditores

Clientes, auditores e reguladores fazem perguntas semelhantes. Responda-lhes a partir da SBOM que as suas próprias equipas usam, em vez de produzir um documento separado que se vai desviando. Se partilhar SBOM, decida quem as pode ver e como recebem atualizações, e peça o mesmo aos seus fornecedores.

Erros comuns

Erro	Porque prejudica	Em alternativa
Uma SBOM por repositório	Não diz nada sobre nenhuma versão específica	Uma por versão, associada ao artefacto
Gerar apenas na altura da auditoria	Descreve um build que ninguém distribuiu	Em cada versão, na CI
Tratar a SBOM como concluída	Surgem novos avisos de segurança após o lançamento	Continuar a monitorizá-la
Comparar apenas o número de componentes	Mais não é melhor se as entradas estiverem erradas	Verificar pacotes específicos que sabe estarem presentes

Como o CRACI trata disto

O CRACI cobre as práticas que dependem do build. É um runner de GitHub Actions que regista cada pacote que cada job obtém, incluindo dependências ocultas que nenhum lockfile lista, numa SBOM CycloneDX ou SPDX com um estado de completude. Conserva todos os builds anteriores e as respetivas SBOM dentro da retenção do seu plano, reavalia as SBOM monitorizadas à medida que surgem novas vulnerabilidades e mostra que builds continham uma dependência vulnerável. As equipas de segurança fazem a triagem das conclusões e enviam-nas às equipas responsáveis pela correção. Consulte gestão de SBOM para ver como se comparam os gestores, ou as melhores ferramentas de SBOM.

Boas práticas de SBOM: perguntas frequentes

Quando deve gerar uma SBOM?

Durante o build de CI que produz a versão, todas as vezes. Uma SBOM criada nesse momento descreve o que foi distribuído, enquanto uma criada mais tarde descreve uma recompilação ou uma análise.

Durante quanto tempo deve conservar as SBOM?

Pelo menos enquanto der suporte à versão, além do que os seus reguladores ou contratos exigirem. Precisa da SBOM de uma versão antiga para saber se os respetivos utilizadores são afetados por uma nova vulnerabilidade.

As SBOM devem ser automatizadas?

Sim. Uma SBOM manual está desatualizada na versão seguinte. Gere as SBOM no pipeline, valide-as aí e armazene-as com o build.

Deve partilhar a sua SBOM com os clientes?

Partilhe-a quando um cliente ou regulador a pedir, em condições que lhe sejam aceitáveis. Uma SBOM revela o que usa, pelo que muitas empresas a partilham a pedido em vez de a publicar.

Qual é a diferença entre uma SBOM e a gestão de SBOM?

Uma SBOM é um ficheiro. A gestão de SBOM é o trabalho contínuo de armazenar SBOM por versão, monitorizá-las quanto a novas vulnerabilidades e disponibilizá-las às pessoas que delas precisam.