SBOM, proveniência e assinatura: o que verificar em uma release

Um pacote pode chegar ao servidor com o nome esperado e ainda ser diferente do que a equipe aprovou. Para investigar sua origem, é útil separar três perguntas: quais componentes estão presentes, como o build aconteceu e se a evidência corresponde ao arquivo recebido.

Três evidências, três perguntas

Uma SBOM é um inventário de componentes e relações. O CycloneDX oferece um formato para representar essas informações. Ela ajuda a localizar bibliotecas e versões, mas não demonstra que o código está livre de falhas.

A proveniência de build do SLSA descreve a produção de um artefato. Sua utilidade depende da confiabilidade do processo que emite a declaração e da verificação das informações relevantes para quem consome.

A assinatura oferece evidência criptográfica que precisa ser verificada contra uma identidade ou chave confiável. A documentação do Sigstore mostra verificações com identidade, emissor OIDC e digest. Uma assinatura válida não comprova, por si, que o software é seguro.

Vincule os registros ao artefato real

O roteiro de adoção proposto começa pelo build que já existe. Gere um identificador de conteúdo, como um digest, para o artefato que será publicado. Mantenha a associação entre esse identificador, a revisão de código aprovada, a SBOM e as evidências do build.

Em um exemplo hipotético, a equipe aprova uma imagem de aplicação e depois executa um novo build no momento do deploy. Mesmo com o mesmo código, dependências ou etapas externas podem produzir outro resultado. Promover o artefato já verificado reduz essa diferença e facilita a investigação.

Faça a verificação no ponto de consumo

• Confira se o digest recebido corresponde ao artefato autorizado.
• Valide a assinatura contra a identidade e o emissor esperados.
• Verifique se a proveniência aponta para o build e a origem permitidos.
• Associe a SBOM àquela release, evitando inventários genéricos do projeto.
• Defina o que acontece quando uma evidência está ausente ou inválida.

Não adianta gerar evidências se ninguém as verifica antes da implantação. A regra de aceitação deve ser explícita e testável: uma assinatura de outro projeto pode ser criptograficamente válida e ainda não autorizar aquele deploy.

Adote por etapas e teste a recusa

Comece com uma aplicação e documente o caminho do artefato. Depois teste um digest alterado, uma identidade diferente e uma declaração que não corresponde ao pacote. Execute os testes em ambiente isolado e observe se a publicação é realmente bloqueada.

Por fim, mantenha um registro de qual release está em cada ambiente. Quando uma vulnerabilidade for divulgada, esse vínculo permite cruzar o inventário de componentes com o software em execução. A qualidade da resposta depende de dados completos e atualizados, não apenas da existência de um arquivo chamado SBOM.