Automatização de SBOM

Porque é que as SBOM manuais deixam de funcionar

• Ficam desatualizadas no build seguinte. As dependências mudam a cada versão, e uma folha de cálculo só muda quando alguém se lembra de a atualizar.
• Ficam-se pelo que as pessoas conseguem ver. É fácil listar as dependências diretas. As dependências transitivas que estão por baixo delas não são, e ninguém as consegue seguir à mão.
• Multiplicam-se. Vários produtos, cada um com várias versões suportadas, significam dezenas de ficheiros, cada um com o seu responsável e a sua própria versão da verdade.
• Não respondem à pergunta que importa. Quando surge uma nova vulnerabilidade, precisa de saber que versões contêm o pacote. Procurar numa pasta de folhas de cálculo é lento, e não pode confiar na resposta.
• Não são o que os outros pedem. Clientes e ferramentas esperam um formato legível por máquina, como CycloneDX ou SPDX. Consulte como responder a um pedido de SBOM de um cliente.

O que faz uma boa automatização de SBOM

1. Produz uma SBOM para cada build, sem que ninguém tenha de executar ou de se lembrar de nada.
2. Cobre a árvore completa, incluindo as dependências transitivas, a qualquer profundidade.
3. Associa cada SBOM a um build, para que saiba que ficheiro descreve que versão.
4. Indica o que não conseguiu ver, em vez de apresentar uma lista parcial como se fosse completa.
5. Exporta num formato padrão, para que a SBOM funcione com a próxima ferramenta e o próximo cliente.
6. Continua a vigiar o que foi distribuído, porque uma versão sem problemas na segunda-feira pode estar afetada na terça-feira.

Três formas de manter SBOM, comparadas

Pergunta	Folha de cálculo	Scanner na CI	Registada durante o build
Quando é atualizada?	Quando alguém se lembra	Quando o passo de análise é executado	Em cada build
De onde vêm os dados?	Das pessoas	De lockfiles ou do resultado final	Do que o build efetivamente obteve
Dependências transitivas?	Raramente	As que consegue deduzir	A qualquer profundidade
Dependências ocultas, como descargas de scripts de instalação?	Não	Não detetadas	Registadas
Pacotes restaurados de uma cache de CI?	Não	Depende da ferramenta	Registados e marcados como provenientes da cache
Monitorização de vulnerabilidades?	Manual	Normalmente, uma ferramenta separada	Integrada no CRACI

Automatizar com um scanner é uma verdadeira melhoria face a uma folha de cálculo, mas continua a adivinhar o que entrou no build. Para o raciocínio completo, consulte porque é que o build é a fonte de verdade.

O que acontece às suas folhas de cálculo

Os dados dos componentes saem dali: as versões e os pacotes vêm do build, pelo que ninguém tem de os escrever. Fica o conhecimento que só a sua equipa tem, como que produtos existem, quem é responsável por eles e que versões continuam a ter suporte. É nisso que vale a pena uma pessoa investir tempo.

Como o CRACI trata disto

O CRACI substitui os seus runners alojados no GitHub por runners mais rápidos e de menor custo, e regista a SBOM durante a execução de cada build. Define runs-on: craci, e as suas execuções continuam a aparecer no GitHub. Os builds padrão obtêm uma SBOM completa sem configuração. Os builds com registos de pacotes próprios ou configurações de contentores pouco habituais podem precisar de alguma.

• Registada, não analisada. O CRACI vê o tráfego que entra em cada build, incluindo as dependências ocultas que as ferramentas baseadas em lockfiles não detetam. Todos os componentes da SBOM estiveram no build.
• Um estado de completude em cada job, para que saiba quando não foi possível registar um build na totalidade e porquê.
• Exportação em CycloneDX e SPDX, incluindo as dependências transitivas e as vulnerabilidades encontradas nos componentes.
• Uma vista de todos os produtos. A vista de inventário mostra que versões de software estão implementadas em que produtos, e o CRACI reavalia continuamente as SBOM monitorizadas.

Para o implementar em equipas com pipelines diferentes, consulte a geração de SBOM entre equipas de engenharia.

Automatização de SBOM: perguntas frequentes

O que é a automatização de SBOM?

Produzir uma lista de materiais de software (software bill of materials) como parte do build, para que cada versão tenha uma sem que ninguém a crie à mão. As melhores configurações também monitorizam cada SBOM quanto a novas vulnerabilidades depois de a versão ser distribuída.

Podemos manter as nossas SBOM em Excel?

Uma folha de cálculo pode servir como primeiro inventário, mas é difícil mantê-la atualizada e não chega às dependências transitivas. Também não é um formato de SBOM padrão. Os clientes e as ferramentas de segurança esperam geralmente CycloneDX ou SPDX, e o Cyber Resilience Act pede um formato de uso comum e legível por máquina.

A automatização de SBOM exige um novo passo em cada pipeline?

Com a maioria dos geradores, sim: acrescenta um passo a cada workflow e mantém-no atualizado. O CRACI regista a SBOM no runner, pelo que não há nenhum passo a acrescentar aos seus jobs.

Que ecossistemas o CRACI regista?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, pacotes Debian e Ubuntu (apt), pacotes Alpine (apk) e fontes Git, bem como descargas do Yocto e do OpenEmbedded. Maven e Java estão no roadmap.

Que sistemas de CI e plataformas o CRACI suporta?

GitHub Actions hoje, com outros sistemas de CI no roadmap. Os runners são hoje Linux x86-64 e ARM64, com Windows e macOS no roadmap.

E os componentes comprados a fornecedores?

Pode adicionar SBOM de fornecedores ao CRACI, para que os componentes comprados sejam monitorizados a par dos seus próprios builds.

Quanto custa?

O CRACI cobra apenas os minutos de build: $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), medidos ao segundo, sem taxa mensal e sem custo por SBOM.