CRACI vs stack de SBOM DIY | O que implica construir a sua

A resposta curta

Uma stack DIY construída com Syft ou Trivy, Grype, Dependency-Track, Cosign e Renovate não tem custos de licença, corre em qualquer lado e dá a uma equipa de plataforma capaz controlo total. O CRACI é um runner gerido de GitHub Actions que regista o que cada build obteve, controla a que se pode ligar, monitoriza o que foi distribuído e exporta as evidências. A diferença tem menos a ver com funcionalidades e mais com a origem da SBOM e com quem mantém as junções. Se faz builds em GitLab, Jenkins ou Windows, ou se tudo tem de correr na sua própria infraestrutura, o DIY é hoje a recomendação honesta.

Como é a stack

Uma solução completa construída por si tem normalmente sete camadas. Cada uma é um projeto real, com a sua própria manutenção.

Geração. Syft ("generating a Software Bill of Materials (SBOM) from container images and filesystems"), Trivy, cdxgen (um projeto OWASP que cria BOM CycloneDX "from source and container images") ou o Microsoft SBOM Tool, que escreve SPDX e espera uma pasta de saída do build, um nome de pacote, uma versão e um fornecedor na linha de comandos.
Cruzamento. O Grype analisa imagens, sistemas de ficheiros e SBOM, com EPSS, KEV e pontuação de risco. O OSV-Scanner cruza lockfiles, SBOM e imagens de contentor com o OSV.dev.
Gestão. O OWASP Dependency-Track importa SBOM CycloneDX e monitoriza-as ao longo do tempo. O seu servidor de API precisa de, pelo menos, 2 GB de RAM e 2 núcleos de CPU (8 GB e 4 núcleos recomendados), e a sua documentação remete as implementações de produção para Docker Compose com uma base de dados separada.
Assinatura. O Cosign assina imagens, blobs e atestações de SBOM, com assinatura sem chaves através do Fulcio e um registo de transparência Rekor. As GitHub artifact attestations assentam no Sigstore e fornecem proveniência SLSA v1.0 Build Level 2.
Atualizações. O Renovate ou o Dependabot abrem pull requests para manter as dependências atualizadas.
Controlo de egress. O StepSecurity Harden-Runner pode auditar ou bloquear as ligações de saída de jobs de GitHub Actions. O seu plano Community é gratuito para repositórios públicos em runners alojados no GitHub; os repositórios privados e os runners self-hosted precisam do plano Enterprise. A alternativa é o seu próprio proxy e regras de firewall em torno de runners self-hosted.
Relatórios. Alguém transforma o resultado de tudo isto nos documentos de que um auditor, um cliente ou um processo técnico do CRA precisa.

Funcionalidade	CRACI	Stack DIY
Executa os seus builds	Os jobs correm em runners do CRACI	As ferramentas correm como passos da sua CI
SBOM registada a partir do build	Obtenções observadas, incluindo pacotes em cache	Reconstruída a partir de ficheiros, a posteriori
Completude da SBOM	Indicada por job e por cache	Depende do gerador, das suas definições e de ter instalado primeiro ou não
Política de egress no runner	Negação ou permissão por defeito, falha em modo fechado	Harden-Runner ou o seu próprio proxy
Proveniência assinada	Sem proveniência assinada	Cosign ou GitHub artifact attestations
Monitorização das SBOM distribuídas	As SBOM monitorizadas são reavaliadas continuamente	Dependency-Track, depois de o alojar
Política de portefólio, VEX e triagem	Triagem, VEX e política de licenças	Políticas e VEX do Dependency-Track
Evidências e relatórios para o CRA	SBOM em CycloneDX ou SPDX, registos via API; sem exportação de relatórios	Monta os relatórios a partir de cada ferramenta
Outros sistemas de CI, Windows e macOS	Hoje Linux em GitHub Actions; outros sistemas de CI, Windows e macOS no roadmap	Geradores e scanners correm em qualquer CI
Corre na sua própria infraestrutura	Hoje gerido; runners alojados pelo cliente no roadmap, Enterprise	Ferramentas open source que aloja
Custo	$0.002 por vCPU-minuto ($0.004 com 2 vCPU), medido ao segundo; sem mensalidade e sem custo por SBOM	Licenças gratuitas. Paga em tempo de engenharia, alojamento e manutenção.

Incluído
Em parte
Não incluído
No roadmap

O custo está nas junções

Escolher um gerador é escolher os seus pontos cegos

Aponte vários geradores de SBOM ao mesmo repositório e não concordarão quanto ao que ele contém. Cada um lê um conjunto diferente de ficheiros e resolve-os de forma diferente, pelo que a lista de componentes que obtém é uma propriedade tanto da ferramenta que escolheu como do projeto. O campo de fornecedor da NTIA mostra o mesmo pelo outro lado: a maioria dos geradores não tem origem para ele, pelo que sai vazio, seja o que for que o repositório contenha.

Nenhuma destas ferramentas está avariada. Cada uma toma uma decisão diferente e documentada sobre o que conta como componente e em que ficheiros confiar. Mas uma stack DIY herda as decisões que escolheu, e o resto do pipeline (cruzamento, monitorização, relatórios) só pode ser tão completo quanto esse primeiro passo.

A cola é sua

Cada ferramenta tem a sua própria cadência de lançamentos, base de dados de vulnerabilidades, formato de saída e configuração. Alguém fixa as versões, atualiza as bases de dados, mantém o Dependency-Track e a respetiva base de dados com patches, roda as identidades de assinatura, decide que SBOM vai para onde e percebe quando um passo começa silenciosamente a produzir menos. Isso é trabalho contínuo de plataforma, não uma configuração única.

As ferramentas também são dependências

As ferramentas de segurança correm dentro dos seus builds com acesso aos seus segredos, pelo que pertencem ao seu modelo de ameaças. Em março de 2026, a Aqua Security publicou um aviso de segurança que descreve como foram usadas credenciais comprometidas para publicar uma versão maliciosa do Trivy e para fazer force-push da maioria das tags de trivy-action para código que roubava credenciais, durante cerca de 12 horas. A Aqua documentou o caso publicamente, e poderia ter acontecido a qualquer projeto amplamente utilizado. Mostra porque é que o controlo de egress no runner importa: uma política de negação por defeito limita para onde um passo comprometido pode enviar dados, embora não em todos os canais (o aviso descreve também um recurso alternativo que criava repositórios na conta GitHub da vítima).

Quando o DIY é a escolha certa

A sua CI não é GitHub Actions. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. As equipas em GitLab, Jenkins e CircleCI podem executar todas as ferramentas open source acima.
Faz builds em Windows ou macOS. Os runners do CRACI são hoje Linux (x86-64 e ARM64); Windows e macOS estão no roadmap.
Tudo tem de correr na sua infraestrutura. O CRACI executa hoje runners geridos em infraestrutura europeia, com runners alojados pelo cliente no roadmap para Enterprise.
Tem uma equipa de plataforma que quer assumir isto. Se manter a stack é um investimento deliberado e já opera bem o Dependency-Track, mantenha-o.
Precisa de uma SBOM para um questionário. Para um pedido ocasional e de baixo risco, um gerador executado à mão pode bastar.

O que o CRACI substitui e o que não substitui

O CRACI cobre várias camadas num só lugar, a começar pelo build. Altera runs-on para craci, e as execuções continuam a aparecer na interface do GitHub. Um proxy que reconhece pacotes regista o que cada job obtém de origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência, e a evidência das dependências acompanha as caches de CI. Cada job e cada cache recebem um estado de completude: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Geração: CycloneDX e SPDX a partir do build registado, incluindo dependências transitivas.
Monitorização: conclusões agregadas de todos os builds e repositórios, com as SBOM monitorizadas reavaliadas continuamente.
Proveniência: a API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência.
Egress: política por job com 24 predefinições integradas de origens de software, validada antes de o job arrancar, com falha em modo fechado e alertas em caso de violação.
Exportação: SBOM em CycloneDX ou SPDX, incluindo vulnerabilidades; sem exportação de relatórios.

Não substitui tudo. As listas de bloqueio de pacotes estão no roadmap. Se precisar de proveniência assinada, mantenha o Cosign ou as GitHub artifact attestations. O Renovate ou o Dependabot continuam a fazer sentido para manter atualizadas todas as dependências, não apenas as vulneráveis. Se o Dependency-Track é onde a sua equipa de segurança trabalha, a SBOM CycloneDX pode ser descarregada através da API REST do CRACI e alimentá-lo.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de o reconstituir a partir de notas de lançamento e folhas de cálculo.

Para o Cyber Resilience Act

O CRA pede aos fabricantes que identifiquem e documentem as vulnerabilidades e os componentes contidos nos produtos com elementos digitais, nomeadamente elaborando uma lista de materiais de software (Anexo I, parte II). O reporte de vulnerabilidades ativamente exploradas aplica-se a partir de setembro de 2026, com 24 horas para a primeira notificação. Uma stack DIY pode suportar isso, desde que alguém seja responsável pelo rasto de evidências de cada versão até à respetiva SBOM. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA, e submete as notificações do CRA em seu nome. Seja qual for o caminho escolhido, decidir o que está a ser ativamente explorado continua a caber à sua equipa. Consulte a conformidade com o CRA e a geração de SBOM durante o build.

CRACI vs uma stack de SBOM DIY