Geração de SBOM, registada durante o build
O CRACI é uma ferramenta de geração de SBOM que regista o que cada build de GitHub Actions efetivamente descarregou, em vez de analisar ficheiros depois. Cada SBOM indica o seu grau de completude.
Em resumo: execute os seus jobs de GitHub Actions em runners do CRACI e cada job recebe uma SBOM dos pacotes que obteve, incluindo dependências transitivas e pacotes restaurados de caches de CI, exportada em CycloneDX ou SPDX. Cada SBOM tem um estado de completude e é monitorizada quanto a novas vulnerabilidades após o lançamento. Ferramentas de análise como o Syft e o Trivy reconstroem uma SBOM a partir de ficheiros; o CRACI regista-a a partir do build. Porque é que as SBOM geradas durante o build são diferentes.
Registada durante o build, não analisada depois
A maioria dos geradores de SBOM lê ficheiros depois do build e reconstrói aquilo que julga ter entrado nele. O CRACI gera a SBOM dentro do seu próprio runner de CI. Um proxy que reconhece pacotes observa o tráfego de cada job para as fontes de pacotes, pelo que a SBOM lista o que o job efetivamente descarregou, incluindo as dependências transitivas, e não o que um manifesto diz que deveria ser necessário. Para que o registo exista, não é preciso lockfile, nem árvore de dependências instalada, nem um passo de análise adicional.
Todas as camadas de dependências transitivas
A maior parte do que um build descarrega não é uma dependência direta. É uma dependência de uma dependência, várias camadas abaixo, e parte dela nem sequer aparece num lockfile: binários pré-compilados que um script de build descarrega, pacotes restaurados de uma cache, pacotes do sistema operativo. O CRACI regista todos os pacotes que o job obteve, a qualquer profundidade, para que as vulnerabilidades sejam cruzadas com a árvore completa. Em comparações lado a lado com outras ferramentas de SBOM, este registo mais completo revelou vulnerabilidades que as outras ferramentas não reportaram.
Os pacotes restaurados de caches de CI ficam na SBOM
As caches são o ponto onde o registo durante o build costuma falhar: um pacote restaurado de uma cache nunca passa por um registo de pacotes, pelo que um proxy, por si só, não o veria. O CRACI faz acompanhar a cache das evidências de dependências, para que os pacotes restaurados de uma cache de CI fiquem na SBOM do job que os restaurou.
Um estado de completude para cada job
O acompanhamento de vulnerabilidades só consegue cruzar os componentes que a sua SBOM lista. Um pacote que falta na SBOM é uma vulnerabilidade sobre a qual ninguém é alertado. Por isso, em vez de apresentar todas as SBOM como completas, o CRACI indica a completude de cada job e de cada cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Fica a saber em que SBOM pode confiar e quais merecem uma segunda análise.
Os ecossistemas e formatos com que trabalha
O CRACI regista pacotes de fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como as predefinições de descarga do Yocto e do OpenEmbedded, e trata os mirrors npm e PyPI do JFrog Artifactory como fontes conhecidas. O suporte para Maven e Java está no roadmap. As SBOM são exportadas em CycloneDX e SPDX, com as dependências transitivas incluídas, prontas a partilhar com clientes, parceiros e auditores.
Licenças declaradas em cada componente
Cada pacote registado leva a sua licença declarada para a SBOM. Pode ver que dependências estão sujeitas a uma licença comercial ou de outra forma restritiva antes de lançar o produto, e as licenças copyleft são detetadas antes de chegarem ao seu produto.
Proveniência através da API
A SBOM é uma parte do que o CRACI regista para cada job. A REST API pública devolve SBOM, traços de rede e dados de proveniência, tudo registado a partir do mesmo build.
Monitorizada após o lançamento
Uma SBOM é a forma de uma empresa saber o que está dentro do software que distribui, e clientes e reguladores pedem-na cada vez mais: o Cyber Resilience Act obriga os fabricantes a elaborá-la para os produtos vendidos na UE. O CRACI reavalia continuamente as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades, agrega as conclusões de todos os builds e repositórios e suporta VEX. As SBOM que recolhe dos seus próprios fornecedores são monitorizadas a par dos seus builds.
Uma SBOM registada face a uma SBOM analisada
Os scanners são a ferramenta certa para software que não foi a sua empresa a compilar. Para as suas próprias versões, é isto que muda quando se regista o build. Um scanner lê o lockfile ou o resultado do build e deduz o que entrou nele. O CRACI vê o tráfego que entra no build, pelo que as dependências ocultas trazidas por hooks de instalação, scripts de build e imagens base também acabam na SBOM.
| Funcionalidade | CRACI | Ferramenta de SBOM baseada em scanner |
|---|---|---|
| Como é produzida a lista de componentes | Registada a partir do tráfego de pacotes do próprio build | Reconstruída a partir de ficheiros, a posteriori |
| Precisa de um lockfile ou de dependências instaladas | Não | Normalmente, de um ou de outro |
| Pacotes restaurados de caches de CI | As evidências acompanham a cache | Só se os ficheiros estiverem presentes na análise |
| Estado de completude por job | Cinco estados, por job e por cache | |
| Ligação assinada entre artefacto e build | Sem proveniência assinada | Com um passo de assinatura separado |
| Software que não foi a sua empresa a compilar | Adicione antes a SBOM do fornecedor | |
| Sistemas de CI | GitHub Actions hoje; outros sistemas de CI no roadmap | Funciona em qualquer CI |
- Incluído
- Em parte
- Não incluído
- No roadmap
Está a comparar ferramentas concretas? Consulte Ferramentas de SBOM comparadas para o Syft, Trivy, cdxgen, Microsoft SBOM Tool, Dependency-Track e outras. Para uma visão mais ampla, consulte ferramentas de segurança da cadeia de abastecimento de software comparadas.
SBOM basics: SPDX, CycloneDX and OpenVEX
O que uma SBOM regista, como os formatos SPDX e CycloneDX diferem na prática e o que o OpenVEX acrescenta sobre se uma vulnerabilidade afeta realmente um produto.
Petteri Pulkkinen e Erika Marttinen em Kubernetes Community Days Helsinki 2026, de 16:50 a 22:05 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Geração de SBOM: perguntas frequentes
O que é a geração de SBOM?
A geração de SBOM consiste em produzir uma lista de materiais de software (software bill of materials): uma lista legível por máquina dos componentes e dependências de um software. Pode ser feita a partir dos ficheiros de código-fonte, durante o build ou através da análise de um artefacto final, como uma imagem de contentor. O CRACI gera a SBOM durante o build, a partir do que o build efetivamente descarregou.
Como é que o CRACI gera uma SBOM?
Os seus jobs de GitHub Actions são executados em runners do CRACI. Durante a execução de cada job, um proxy que reconhece pacotes observa o tráfego para as fontes de pacotes e regista os pacotes que o job descarrega, incluindo dependências transitivas e pacotes restaurados de caches de CI. Cada job recebe a sua própria SBOM com um estado de completude.
Tenho de alterar os meus workflows?
Basta alterar runs-on para craci. O CRACI substitui o runner, não o GitHub Actions, pelo que os seus workflows e as respetivas execuções continuam no GitHub.
Que ecossistemas de pacotes o CRACI regista?
Fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como as predefinições de descarga do Yocto e do OpenEmbedded. Os mirrors npm e PyPI do JFrog Artifactory são tratados como fontes conhecidas. O suporte para Maven e Java está no roadmap.
Em que formatos de SBOM posso exportar?
CycloneDX e SPDX, incluindo as dependências transitivas e a licença declarada de cada componente.
O que significa o estado de completude?
Complete significa que o CRACI observou evidências completas do job e que todas as caches restauradas estavam completas. Complete with connections significa que o job também usou ligações de rede personalizadas que convém rever. Incomplete significa que alguma condição pode ter deixado dependências de fora. Unavailable significa que não foi possível avaliar as evidências, e Not recorded significa que o job é anterior à indicação de completude.
O CRACI encontra vulnerabilidades na SBOM?
Sim. O CRACI reavalia continuamente as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades, agrega as conclusões de todos os builds e repositórios e suporta VEX. As equipas de segurança fazem a triagem do que é encontrado e enviam-no às equipas responsáveis pela correção.
O CRACI consegue gerar uma SBOM para software que não compilei?
Não. O CRACI regista os builds executados nos seus runners. Para o software que compra, adicione a SBOM do fornecedor e o CRACI monitoriza-a a par dos seus próprios builds. Para uma imagem de terceiros que não compilou, um scanner é a opção prática; consulte Ferramentas de SBOM comparadas.
Veja a SBOM do seu próprio build
Marque uma demo, execute um dos seus workflows de GitHub Actions no CRACI e veja o que ele efetivamente descarregou
Marcar uma demo