Geração de SBOM entre equipas de engenharia: uma política, cada pipeline

Porque é que scanners por equipa não somam um programa de SBOM

Aponte cinco ferramentas ao mesmo produto e obtém cinco SBOM. As diferenças são estruturais, não erros:

• Entradas diferentes, lidas em momentos diferentes. Uma ferramenta lê o lockfile, outra a árvore de dependências instalada, outra a imagem de contentor, outra o binário. Cada uma vê uma fatia diferente do produto.
• Nomes diferentes para a mesma coisa. Uma identifica os componentes por package URL, outra por CPE, outra apenas pelo nome do ficheiro. Duas SBOM que descrevem a mesma biblioteca não podem ser cruzadas por uma chave comum.
• Profundidade diferente. Algumas listam apenas as dependências diretas, outras a árvore transitiva completa, e outras listam também ferramentas de build. A razão pela qual os geradores discordam sobre o mesmo repositório é mostrada em geradores de SBOM open source.
• Algumas ferramentas respondem a outra pergunta. Os scanners de vulnerabilidades de infraestrutura reportam o que está instalado nos hosts em execução. Isso é útil para as operações, e não é uma descrição do produto que distribui.

A consequência: não consegue juntar, eliminar duplicados nem comparar SBOM entre produtos, e não consegue mostrar a um auditor um único processo, porque não existe nenhum.

Método	Entrada que lê	Quando	O que lhe escapa	Identificador típico
Scanner de lockfiles ou manifestos	Lockfiles e manifestos no checkout	Antes ou depois do build	Tudo o que nenhum lockfile lista: hooks de instalação, downloads feitos por scripts de build, imagens base	Package URL
Scanner de imagens de contentor	Bases de dados de pacotes e ficheiros na imagem	Depois do build	Ferramentas usadas só no build, código compilado no binário, tudo o que não tem registo de pacote	Package URL para pacotes do sistema operativo e de linguagens
Scanner de binários ou firmware	Strings e assinaturas no binário	Depois do build	Certeza: versões e componentes são inferidos	CPE ou nome inferido
Scanner de vulnerabilidades de hosts	Software instalado em servidores em execução	Em operação	O produto tal como é entregue aos clientes	CPE ou nome de produto do fornecedor
Registo durante o build	O que o build de release descarregou	Durante o build	Software que não construiu; o que não conseguiu ver é assinalado como incompleto	Package URL

A política de SBOM: o que normalizar

Normalize a SBOM, não o scanner. A política fixa o resultado e o processo; cada pipeline cumpre-a com o melhor gerador que consegue executar. Cada linha abaixo é algo que pode verificar.

Requisito	A regra	Porquê	Como verificar
Âmbito	Cada release de produto entregue a um cliente, incluindo firmware e imagens de contentor. Ferramentas internas opcionais.	Clientes e reguladores perguntam pelo que distribui.	Cada release no registo de releases tem uma SBOM.
Formato e versão	Um formato principal, CycloneDX ou SPDX, com uma versão mínima. Aceite o outro a pedido.	Um formato significa um parser, um validador e um repositório. A BSI TR-03183-2 pede CycloneDX 1.6 ou posterior ou SPDX 3.0.1 ou posterior, um mínimo sensato para clientes da UE.	A validação do esquema reporta o formato e a versão.
Campos mínimos	Um package URL em cada componente que o tenha, um CPE apenas onde não exista nenhum, fornecedor, versão, licença declarada, relações de dependência, nome e versão da ferramenta, data e hora e contexto de geração.	São estes os campos usados no cruzamento, na revisão de licenças e nas auditorias. Alinhe-os com os elementos mínimos em o que é uma SBOM.	Uma verificação de campos no pipeline conta os valores em falta.
Quando é gerada	No build de CI que produz a release, sempre. Não na altura da auditoria, não num portátil.	Um novo build não é o mesmo build; consulte SBOM geradas durante o build.	O ID de build da SBOM corresponde ao ID de build da release.
Profundidade	A árvore transitiva completa, não apenas o nível superior.	O mínimo do CRA são as dependências de nível superior; as vulnerabilidades e os clientes vão mais fundo.	Existem relações de dependência abaixo do primeiro nível.
Onde é guardada	Com o artefacto da release, recuperável por produto e versão.	Uma SBOM que ninguém encontra quando chega um alerta de segurança não é uma evidência.	Obtenha a SBOM de uma release aleatória por produto e versão.
Retenção	Pelo menos o período de suporte do produto mais a retenção de documentação que os seus regulamentos exigem.	O CRA fixa um período de retenção para a documentação técnica, e a SBOM faz parte dela.	Compare o período da política com a retenção de cada ferramenta.
Validação	Cada SBOM é validada contra o esquema no pipeline; uma SBOM inválida faz falhar o build ou a release gate.	SBOM inválidas falham silenciosamente nas ferramentas do cliente.	O registo da release gate mostra um passo de validação.
Responsabilidade	A equipa de produto é responsável pela geração; a segurança de produto é responsável pela política, pelas regras de validação e pelos relatórios de cobertura.	A geração precisa do responsável pelo pipeline; a consistência precisa de um único responsável pelas regras.	Cada pipeline indica um responsável.
Exceções	Um registo de exceções nominal e com prazo: equipa, motivo, data de fim.	A política sobrevive a equipas que ainda não a conseguem cumprir.	Nenhuma exceção ultrapassou a sua data de fim.

A lista de verificação em boas práticas de SBOM cobre as regras para uma única SBOM; esta política é a camada acima delas. Cada equipa declara como o seu pipeline cumpre a política, num ficheiro junto ao pipeline:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Gere no build, não por equipa a posteriori

A geração durante o build é o padrão a atingir. Descreve o build que foi distribuído, inclui dependências ocultas que nenhum lockfile lista, e um único mecanismo produz SBOM com a mesma forma para todas as equipas desse pipeline. A diferença explica-se mais facilmente com uma cozinha: um scanner prova a sopa e adivinha a receita; um registador observa o que entra na cozinha.

Um scanner continua a ser a ferramenta certa para imagens que não construiu, para binários de terceiros e para produtos legados sem CI. Diga-o na política e registe o contexto de geração, para que quem lê saiba o que cada SBOM viu.

Situação	Método de geração	Contexto de geração a registar
Release construída numa CI que controla	Registar o build, ou executar um gerador dentro do job de release	"Registada durante o build" ou "após a instalação, a partir de ficheiros"
Imagem de contentor construída em CI	Registar o build da imagem; analisar o resultado para os pacotes do sistema operativo se o registador não os cobrir	ID de build e digest da imagem
Imagem ou appliance de terceiros	Scanner de imagens, mais a SBOM do fornecedor, se existir	"Resultado de análise, não construído por nós"
Binário de fornecedor	Pedir a SBOM de build do fornecedor; análise de binários como verificação	Fornecedor, versão, como foi obtido
Produto legado sem pipeline	Analisar o artefacto distribuído; planear um pipeline	"Resultado de análise" e uma exceção com data de fim

CI mista: GitHub Actions, GitLab e Jenkins na mesma organização

A política é agnóstica em relação à CI por conceção: define o resultado, pelo que um pipeline GitLab ou Jenkins a pode cumprir com um passo de gerador, e um pipeline GitHub Actions pode usar o registo durante o build. Regras para um passo de gerador:

• Execute-o no job de release, depois do passo de instalação, não num job separado que instala outra vez.
• Fixe a versão do gerador, e fixe as actions de CI a um commit, não a uma tag. A razão pela qual isso importa em particular para scanners é explicada em geradores de SBOM open source.
• Registe o contexto de geração como "após a instalação, a partir de ficheiros", para que quem lê saiba o que o gerador viu.
• Valide o resultado contra o mesmo esquema que todos os outros pipelines.

Geradores open source como Syft, Trivy e cdxgen conseguem todos escrever CycloneDX e SPDX, pelo que a regra de formato não obriga a escolher uma ferramenta. Para os comparar, consulte ferramentas de SBOM comparadas.

Hoje o CRACI suporta GitHub Actions; GitLab CI e Jenkins estão no roadmap, sem data. A consequência para a implementação: comece o registo durante o build onde se usa GitHub Actions, mantenha os passos de gerador nos restantes casos e acompanhe ambos no mesmo relatório de cobertura.

Quando um cliente quer uma versão de formato específica

Um cliente pede CycloneDX 1.6, e as suas ferramentas escrevem 1.7. Acontece porque a ferramenta de ingestão do cliente ou a sua própria política está fixada numa versão; o mínimo da BSI é 1.6, por isso os clientes da UE indicam-na frequentemente. As suas opções:

1. Pergunte se a versão mais recente é aceite. Muitas vezes é.
2. Converta com a CycloneDX CLI, valide depois contra a versão de destino e verifique o que se perdeu: os campos que só existem na especificação mais recente são descartados.
3. Para um pedido de SPDX, a mesma CLI converte de e para SPDX JSON 2.3. A sua documentação avisa que a conversão entre SPDX e CycloneDX "pode resultar na perda de alguma informação".

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

O validador verifica contra CycloneDX 1.7, a menos que indique --input-version. Regra da política: mantenha a SBOM original como registo. Uma cópia convertida é uma entrega derivada; guarde a derivação (ferramenta, versão, data) com ela. Mais sobre como responder a estes pedidos em pedidos de SBOM de clientes, e sobre os dois formatos em CycloneDX vs SPDX.

Dados de licenças para o departamento jurídico

A mesma SBOM pode servir a equipa jurídica, se a política pedir os campos certos. O jurídico precisa da licença de cada componente, da diferença entre uma licença declarada (o que o pacote diz) e uma concluída (o que alguém verificou), das obrigações copyleft e de uma lista dos componentes sem licença. O CycloneDX 1.6 marca as licenças como declaradas ou concluídas, e o SPDX tem campos separados para ambas.

• Exija identificadores ou expressões de licença SPDX, como MIT ou Apache-2.0 OR MIT.
• Assinale NOASSERTION e as licenças em falta para revisão. Em SPDX, NOASSERTION significa que não foi feita qualquer determinação ou que não foi dada informação; não é uma licença.
• Encaminhe as licenças copyleft para o jurídico antes da release, não depois.

Uma SBOM contém licenças declaradas. Uma revisão de conformidade de licenças, com licenças concluídas, avisos e obrigações, é trabalho jurídico ou tarefa para uma ferramenta especializada; consulte conformidade de licenças open source.

Implementar equipa a equipa

Fase	Responsável	Critério de saída	Obstáculo típico
1. Inventário: produtos, pipelines, sistemas de CI e geradores atuais, uma linha por pipeline de release	Segurança de produto	Cada produto distribuído tem uma linha	Ninguém sabe que pipeline constrói uma release
2. Publicar a política com o registo de exceções	Segurança de produto	Política aprovada e publicada	Debate sobre que ferramenta impor (a política não impõe nenhuma)
3. Piloto com uma ou duas equipas que tenham um motivo: um pedido de cliente, um prazo, um produto que a ferramenta atual não consegue tratar	Equipas piloto	As releases piloto saem com SBOM conformes	As equipas sem um motivo urgente despriorizam-no
4. Adicionar gates de validação nos pipelines piloto	Equipas piloto	Uma SBOM inválida faz falhar a release	Receio de bloquear releases; comece com um aviso
5. Expandir por sistema de CI; retirar um scanner por equipa só quando a substituição cumprir a política	Equipas de produto	Meta de cobertura atingida por sistema de CI	Pipelines sem responsável
6. Reportar a cobertura mensalmente	Segurança de produto	O relatório chega à gestão todos os meses	Métricas calculadas à mão

A folha de cálculo de inventário da fase 1 deve ser a última; abandonar as folhas de cálculo é o tema de automação de SBOM. Um produto baseado em Yocto é um piloto comum, porque os scanners de uso geral têm dificuldades com ele; consulte porque é que os scanners de SBOM falham builds Yocto.

Medir a cobertura

Os números que a gestão e os auditores pedem, cada um definido como um rácio:

• Cobertura de releases: releases distribuídas com uma SBOM conforme à política ÷ releases distribuídas.
• Cobertura de produtos: produtos com pelo menos uma SBOM conforme no período de suporte atual ÷ produtos em suporte.
• Taxa de aprovação na validação: SBOM que passam a validação ÷ SBOM geradas.
• Cobertura de identificadores: componentes com um package URL (ou um CPE) ÷ componentes.
• Cobertura de licenças: componentes com uma licença declarada ÷ componentes.
• Completude: SBOM cujo gerador indica que estão completas ÷ SBOM. Só é possível onde a ferramenta o reporta.
• Tempo até à SBOM: tempo desde a release até a SBOM estar disponível.

Um exemplo de relatório mensal (valores ilustrativos):

Métrica	Pipelines GitHub Actions	Pipelines GitLab e Jenkins	Todos
Cobertura de releases	46 / 48	19 / 27	65 / 75
Taxa de aprovação na validação	100%	92%	97%
Cobertura de identificadores	99%	88%	95%
Exceções em aberto	1	4	5

Como evidência para um regulador ou um auditor, o conjunto é a política, o registo de exceções, o relatório de cobertura e algumas SBOM de exemplo. Mostra um único processo, aplicado e medido. Para o lado do CRA, consulte o guia do CRA.

Onde entra o CRACI

Para pipelines GitHub Actions, o CRACI é o runner: define runs-on: craci, e cada job recebe uma SBOM registada sem um passo de gerador. Cada SBOM inclui um estado de completude, as dependências transitivas, um package URL por pacote e a licença declarada de cada componente, e é exportada como CycloneDX ou SPDX. As regras de política de licenças podem bloquear um build, as SBOM monitorizadas são reavaliadas continuamente, e o histórico de builds mostra que builds continham uma dependência vulnerável. Isso dá a essas equipas, por predefinição, as linhas "gerada no build de release", "identificador" e "licença" da política. Podem ser adicionadas SBOM de terceiros, para que os componentes adquiridos sejam monitorizados a par dos seus builds.

Consulte geração de SBOM no CRACI e SBOM em GitHub Actions.

Quando o CRACI não é a resposta

• Equipas em GitLab CI ou Jenkins: hoje não, está no roadmap. Use um passo de gerador que cumpra a política.
• GitHub Enterprise Server: hoje não é suportado.
• Análise de infraestrutura e de hosts, ou seja, o que está instalado nos servidores e configurações incorretas: é outra tarefa; mantenha essas ferramentas.
• Análise de binários ou firmware de imagens de fornecedores que não constrói: o CRACI regista builds e não analisa binários.
• Retenção longa: o CRACI guarda os dados de build durante 180 dias por predefinição, com retenção personalizada no Enterprise. Se a sua política exigir SBOM durante mais tempo, exporte-as para o seu próprio repositório.

Geração de SBOM entre equipas: perguntas frequentes

Como normalizamos a geração de SBOM entre equipas que usam ferramentas diferentes?

Normalize o resultado, não a ferramenta. Escreva uma política que fixe o formato e a versão, os campos mínimos, quando a SBOM é gerada, onde é guardada, durante quanto tempo é mantida e quem a valida. Deixe cada pipeline cumpri-la com o melhor gerador que consegue executar e meça a cobertura face à política.

O que deve incluir uma política de SBOM?

Âmbito, formato e versão mínima, campos mínimos (package URL, fornecedor, versão, licença declarada, dependências, ferramenta, data e hora, contexto de geração), geração no build de release, profundidade transitiva completa, armazenamento com a release, retenção, validação no pipeline, responsabilidade e um registo de exceções com prazo.

Cada equipa deve executar o seu próprio scanner, ou as SBOM devem vir do build?

Do build, sempre que possível. Uma SBOM gerada durante o build descreve o build que foi distribuído e dá a todas as equipas desse pipeline SBOM com a mesma forma. Mantenha os scanners para o que não construiu: imagens de terceiros, binários de fornecedores e produtos legados sem pipeline.

Um cliente quer a nossa SBOM numa versão mais antiga do CycloneDX. O que fazemos?

Pergunte primeiro se a versão mais recente é aceite. Se não for, converta uma cópia com a CycloneDX CLI (cyclonedx convert com --output-version v1_6), valide-a contra essa versão e verifique que campos foram descartados. Mantenha o original como registo e guarde a forma como a cópia foi derivada.

Como fazemos chegar ao jurídico os dados de licenças das nossas SBOM?

Exija na política identificadores ou expressões de licença SPDX, assinale NOASSERTION e as licenças em falta para revisão e encaminhe as licenças copyleft para o jurídico antes da release. A SBOM contém licenças declaradas; licenças concluídas, avisos e obrigações exigem uma revisão de licenças.

Como medimos a cobertura de SBOM entre produtos?

Como rácios: releases distribuídas com uma SBOM conforme, produtos em suporte com uma SBOM conforme, taxa de aprovação na validação, componentes com um package URL, componentes com uma licença declarada, SBOM completas onde a ferramenta o reporta e tempo desde a release até à SBOM. Reporte-os mensalmente por sistema de CI.

Que evidências precisamos para mostrar a um auditor que a geração de SBOM é consistente?

A política, o registo de exceções, o relatório mensal de cobertura e algumas SBOM de exemplo com o respetivo contexto de geração. Em conjunto, mostram um único processo, aplicado a cada release e medido, que é o que um auditor ou um cliente verifica.