O que o CRACI substitui na sua stack e com o que funciona em conjunto

A resposta curta: o que muda e o que fica

Mapeie a sua própria stack com esta tabela. Cada linha é uma tarefa que uma ferramenta da sua stack faz hoje, o que essa tarefa precisa de ver para a fazer e se o CRACI a faz a partir da posição que ocupa.

Tarefa na sua stack	O que a tarefa precisa de ver	CRACI	O que mantém, e porquê
Runners de CI para jobs Linux no GitHub Actions: alojados no GitHub, de um fornecedor terceiro ou uma frota self-hosted	Um sítio onde executar o job	Substitui	Runners para Windows, macOS, GitHub Enterprise Server e sistemas de CI que não o GitHub Actions, que o CRACI não suporta hoje
Agentes de monitorização de rede ou de egress adicionados aos runners que mantém	O tráfego de saída do job	Substitui nos runners CRACI	Agentes nos runners que mantém noutro lado
Geradores de SBOM executados em CI, equipa a equipa: scanners de manifestos, lockfiles ou imagens usados para produzir SBOM	O que o build realmente incorporou	Substitui para builds no CRACI	Geradores para software que não constrói no CRACI, como imagens que descarrega e nunca constrói
A geração de SBOM integrada do Yocto (create-spdx) para a cobertura da cadeia de abastecimento	Cada fonte e ferramenta que o build BitBake obteve	Substitui para a cobertura da cadeia de abastecimento	create-spdx, se depende dos metadados das receitas: patches aplicados e CVE marcadas como corrigidas
Acompanhamento de vulnerabilidades a partir de SBOM: carregar SBOM, cruzar avisos de segurança, vigiar novos avisos	Uma SBOM exata por versão, mantida atualizada	Substitui para builds no CRACI; é possível adicionar SBOM de fornecedores	Uma ferramenta dedicada se precisar do que o CRACI não faz: reachability, métricas de remediação como MTTR ou prazos por severidade
SBOM e listas de componentes mantidas em folhas de cálculo	Uma SBOM exata por versão, mantida atualizada	Substitui	Nada
Verificação de licenças declaradas e política de licenças	A licença declarada de cada componente	Em parte	Análise de licenças em texto integral e ao nível de excertos, avisos de atribuição
SAST e code scanning	O seu código-fonte	Funciona em conjunto	Mantenha; corre sem alterações como passo do workflow num runner CRACI
Secret scanning e push protection	O seu repositório e os seus commits	Funciona em conjunto	Mantenha
DAST e testes de API	O seu serviço em execução	Funciona em conjunto	Mantenha
Análise de binários e firmware de terceiros	Um binário acabado que não construiu	Funciona em conjunto	Mantenha
Análise de excertos e assinaturas para código copiado ou incluído (vendored)	O conteúdo dos ficheiros no repositório	Funciona em conjunto	Mantenha
Priorização baseada em reachability	O seu grafo de chamadas	Funciona em conjunto	Mantenha, se depende dela
Análise de IaC, clusters e configurações incorretas	A configuração e a infraestrutura em execução	Funciona em conjunto	Mantenha
Verificações de postura de CI/CD na configuração dos workflows	Ficheiros e definições dos workflows	Funciona em conjunto	Mantenha
Gestão de tickets, gestão de casos PSIRT, publicação de avisos de segurança	O seu processo	Funciona em conjunto	Mantenha
Automação de conformidade: recolha de evidências para auditorias SOC 2 ou ISO 27001	Os seus controlos em vários sistemas	Funciona em conjunto	Mantenha; os registos do CRACI são evidências que essa ferramenta pode recolher

O antes e o depois

Antes: runners alojados no GitHub, um gerador de SBOM diferente no workflow de cada equipa, o create-spdx do Yocto a acrescentar tempo de build e SBOM carregadas numa ferramenta de acompanhamento ou numa folha de cálculo, com code scanning, secret scanning, análise de binários e gestão de tickets à volta. Depois: runners CRACI que executam cada job, aplicam a sua política de egress, registam a sua SBOM e a mantêm sob monitorização. As ferramentas que leem código, repositórios, binários e o seu processo ficam inalteradas.

O que o CRACI substitui, e porquê

Cada uma destas tarefas acontece durante o build. O CRACI pode assumi-las porque é onde o build corre. Para cada uma: o mecanismo, aquilo de que abdica e um exemplo.

Os seus runners

O CRACI é um runner para GitHub Actions. Altera runs-on para craci e as execuções continuam a aparecer no GitHub como qualquer outro job de Actions. Cada job tem a sua própria máquina virtual, em Linux x86-64 ou ARM64, com um tamanho de 1 a 32 vCPU, medida ao segundo. Não é preciso reescrever workflows: os passos existentes, incluindo os de análise, continuam a correr.

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 mensalidade e sem custo por SBOM. Isso torna-o um dos runners de CI mais acessíveis. Executa builds cerca de duas vezes mais depressa do que os runners alojados no GitHub, graças a hardware mais rápido, filas de espera mais curtas e cache.

Runner, por minuto	CRACI	Alojado no GitHub	Diferença
2 vCPU x64	$0.004	$0.006	CRACI cerca de 33% mais barato
2 vCPU ARM64	$0.004	$0.005	CRACI 20% mais barato
32 vCPU x64	$0.064	$0.082	CRACI cerca de 22% mais barato
32 vCPU ARM64	$0.064	$0.050	CRACI 28% mais caro

Preços de tabela do GitHub em setembro de 2026. O GitHub arredonda cada job para o minuto inteiro seguinte; o CRACI mede ao segundo. Exemplo: um build de 10 minutos num runner x64 de 2 núcleos alojado no GitHub custa $0.060. Com cerca do dobro da velocidade, demora 5 minutos num runner CRACI de 2 vCPU e custa $0.020, cerca de 67% menos. Consulte preços e preços de runners de CI.

Aquilo de que abdica. Runners Windows e macOS, outros sistemas de CI e runners alojados pelo cliente não estão disponíveis hoje; GitLab CI, Jenkins, Windows, macOS e runners alojados pelo cliente estão no roadmap. O GitHub Enterprise Server não é suportado. Os runners são geridos, em infraestrutura europeia. Se está a comparar runners geridos com a sua própria frota, consulte runners geridos vs self-hosted.

Agentes de egress nos runners que mantém

Um agente de egress vigia ou limita o tráfego de um runner operado por outra entidade. No CRACI, é o próprio runner que aplica a política de egress: negar ou permitir por omissão, 24 predefinições de fontes de software integradas, fontes personalizadas tipadas para registos de pacotes e Git, e regras de rede explícitas. A política é validada antes de o job começar e falha em modo fechado (fail closed), e o CRACI alerta sobre violações da política. Nos runners CRACI não é necessário um agente separado.

Exemplo: uma dependência comprometida tenta enviar os segredos do job para um host de que o build nunca precisou. Com uma política de negação por omissão, a ligação é bloqueada, mesmo num ataque que ninguém viu antes, porque a política permite apenas aquilo de que o build precisa, em vez de procurar hosts maliciosos conhecidos.

Aquilo de que abdica. A política abrange os jobs em runners CRACI. Os runners que mantém noutro lado continuam a precisar do seu próprio controlo.

O gerador de SBOM no workflow de cada equipa

Um gerador lê os ficheiros que tem à frente, como um manifesto, um lockfile ou uma imagem, e reconstrói o que entrou. Geradores diferentes devolvem listas diferentes a partir do mesmo checkout, e as equipas costumam escolher o seu, pelo que a organização acaba com vários inventários que não batem certo.

O CRACI regista os pacotes que cada job realmente incorporou, incluindo pacotes restaurados de caches de CI, e as dependências ocultas que as ferramentas baseadas em lockfiles não veem: código descarregado por hooks de instalação do npm, scripts de build de Rust que descarregam durante o build, e a imagem base e as suas camadas de sistema operativo num build de contentor. Cada componente da SBOM esteve no build. A SBOM de cada job indica a sua completude, como Complete, Complete with connections, Incomplete, Unavailable ou Not recorded, para que uma lacuna fique visível em vez de silenciosa. O resultado é um único inventário para cada repositório que faz build no CRACI, exportado como CycloneDX ou SPDX. Ecossistemas registados hoje: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk e fontes Git, além de downloads de Yocto e OpenEmbedded.

Exemplo: expressjs/express 5.2.1 não inclui nenhum lockfile no repositório. Um gerador que resolve dependências a partir de lockfiles não tem nada para resolver aí, e pode ainda assim devolver um documento que não lista nenhuma das dependências npm declaradas em package.json. Um build do mesmo projeto no CRACI regista os pacotes que npm install obteve. Mais sobre o método em SBOM em tempo de build e ferramentas de SCA e SBOM comparadas; para uma stack de geradores feita por conta própria, consulte a stack de SBOM DIY.

Aquilo de que abdica. Os ecossistemas que o CRACI ainda não regista. Maven e Java estão no roadmap, e tudo o que não está na lista acima não é abrangido. Mantenha um gerador para esses builds.

A geração de SBOM integrada do Yocto

O Yocto escreve a sua própria SBOM SPDX através do create-spdx, e é minucioso quanto ao que o BitBake constrói. Não consegue ver o que acontece fora dos metadados do BitBake. O CRACI executa o build BitBake e regista o que este obteve. Num build lado a lado de core-image-sato num runner ARM64 nativo com 32 vCPU, a SBOM do CRACI tinha todos os componentes da SBOM do Yocto, mais 88 que esta não incluía: 23 pacotes do host na máquina de build, 10 fontes do GitHub, incluindo a GitHub Action actions/upload-artifact, e 55 outras fontes e ferramentas obtidas durante o build. Registou todas as 653 versões de crates Rust com package URLs pkg:cargo, para que possam ser cruzadas com avisos de segurança. O build sem a geração de SBOM do Yocto demorou menos 43%: cerca de $9.96 contra $5.68 por build ao preço do CRACI.

Aquilo de que abdica. O SPDX do Yocto inclui metadados das receitas que o CRACI não regista: os patches aplicados e as CVE marcadas como corrigidas. Se depende deles, mantenha o create-spdx ativo. O método e a comparação completa estão em builds Yocto no CRACI.

Transformar SBOM em acompanhamento de vulnerabilidades

Uma ferramenta de acompanhamento autónoma tem de ser alimentada com uma SBOM e confia no que lhe derem. O CRACI produz a SBOM e guarda o registo. As SBOM monitorizadas são reavaliadas continuamente à medida que são publicados novos avisos de segurança. O histórico de builds mostra que builds continham uma dependência vulnerável, direta ou transitiva, para que saiba durante que período esteve afetado, dentro do período de retenção do seu plano. As conclusões são triadas para a equipa responsável pela correção, o CRACI notifica as pessoas relevantes de uma vulnerabilidade e da sua severidade, e as policy gates podem bloquear um build com base em conclusões, incluindo um build que contenha uma CVE específica. O VEX é suportado. É possível adicionar SBOM de fornecedores, para que os componentes adquiridos sejam monitorizados juntamente com os seus próprios builds.

Exemplo: é publicado um aviso de segurança para um crate que um dos seus serviços compilou há três meses. O CRACI cruza-o com todas as SBOM monitorizadas e mostra que builds continham essa versão, sem que ninguém volte a carregar nada.

Aquilo de que abdica. O CRACI não oferece análise de reachability nem métricas de remediação como MTTR, prazos por severidade ou tendências do backlog. Se depende delas, mantenha a ferramenta que as fornece. Consulte acompanhamento de vulnerabilidades para a capacidade completa.

A folha de cálculo

Para equipas sem ferramentas de SBOM, o que o CRACI substitui é a montagem manual: alguém copia listas de dependências para uma folha de cálculo antes de uma versão ou de uma auditoria. Um build no CRACI produz a SBOM como efeito secundário da sua execução, por isso a lista existe para cada build, e não apenas para aqueles de que alguém se lembrou.

Com o que o CRACI funciona em conjunto, e como

Estas ferramentas leem coisas que o CRACI nunca lê. O CRACI não lê o seu código-fonte à procura de falhas, não testa serviços em execução e não analisa binários que não construiu. Continuam a correr como correm hoje.

Ferramentas que leem o seu código e repositório

SAST, secret scanning e push protection, análise de excertos e assinaturas, análise de IaC e verificações de postura de CI/CD inspecionam todas o seu código, os seus commits ou a sua configuração. Os passos do seu workflow correm sem alterações num runner CRACI, e as funcionalidades ao nível do repositório não são afetadas porque nunca correram no runner. Um passo de code scanning pode estar no mesmo job que o seu build. O SAST está fora do âmbito por opção: há muitas ferramentas SAST excelentes que funcionam em conjunto com o CRACI. Consulte SAST vs SCA para ver como os dois tipos de conclusão diferem.

Ferramentas que inspecionam o que não construiu

A análise de binários e firmware de fornecedores, os scanners de imagens que descarrega mas nunca constrói e o DAST contra serviços em execução olham todos para algo que foi construído noutro lado ou que já está em execução. O CRACI regista builds; um binário que chega de um fornecedor foi construído num sítio que o CRACI nunca viu. Se o fornecedor lhe entregar uma SBOM, o CRACI pode monitorizá-la juntamente com os seus próprios builds.

A priorização baseada em reachability lê o seu grafo de chamadas, que o CRACI não analisa. Mantenha-a se depende dela; consulte análise de reachability para saber o que pode e não pode dizer-lhe.

Sistemas de processo

A gestão de tickets, a gestão de casos PSIRT, a publicação de avisos de segurança e as plataformas de automação de conformidade gerem o seu processo em vários sistemas. O CRACI encaminha as conclusões para a equipa responsável e guarda as evidências do build; mantenha as suas ferramentas de processo para o resto. Os registos saem do CRACI como SBOM CycloneDX ou SPDX e através da API, que devolve SBOM, registos de tráfego de rede e dados de proveniência. Para o lado da auditoria, consulte verificações de SBOM para SOC 2. Para trabalho de licenças para além das licenças declaradas, como avisos e revisão de texto integral, consulte conformidade de licenças open source. O CRACI inclui a licença declarada de cada componente e aplica regras de política de licenças, incluindo bloquear um build por causa de uma licença.

Como encontrar o ponto de substituição na sua própria stack

Cinco perguntas a que pode responder numa tarde. Cada resposta diz-lhe se uma linha da sua stack muda.

1. Os seus builds correm no GitHub Actions em Linux? Se sim, os runners mudam. Se não, o CRACI não substitui nada hoje.
2. Quem gera SBOM hoje e quantos geradores diferentes estão em uso? Cada gerador num repositório que passa para o CRACI é uma linha que sai.
3. Constrói imagens Yocto? Se sim, verifique se alguém depende dos patches aplicados e das CVE corrigidas no output do create-spdx antes de o desligar.
4. Para onde vão as SBOM depois de geradas: uma ferramenta de acompanhamento, uma folha de cálculo, lado nenhum? Essa ferramenta ou processo é a segunda linha que sai, a menos que precise dela para reachability ou métricas de remediação.
5. Quais das suas ferramentas de segurança leem código, repositórios ou binários de terceiros? Essas ficam. Anote-as, para que ninguém espere que o CRACI as substitua.

Um exemplo prático

Um fabricante de dispositivos ilustrativo, não baseado em nenhuma empresa real: builds Linux em runners alojados no GitHub, duas equipas a usar dois geradores de SBOM diferentes, uma linha de produtos Yocto com o create-spdx ativo, SBOM reunidas numa folha de cálculo partilhada, um conjunto de code scanning e um sistema de tickets. A sua equipa de segurança responde sim às perguntas 1 e 3, encontra dois geradores na pergunta 2 e uma folha de cálculo na pergunta 4, e indica code scanning, secret scanning e o sistema de tickets na pergunta 5. Ninguém usa os metadados de patches do SPDX do Yocto.

Passa para o CRACI	Fica
Runners alojados no GitHub para os jobs Linux	Code scanning, executado como passo nos runners CRACI
Os dois geradores de SBOM	Secret scanning
create-spdx, já que ninguém precisa dos seus metadados de patches	O sistema de tickets
A folha de cálculo de SBOM

Na linha dos runners, um build de 10 minutos que custa $0.060 num runner x64 de 2 núcleos alojado no GitHub custa cerca de $0.020 no CRACI com o ganho de velocidade. Os custos das outras ferramentas ficam para a própria empresa preencher.

Quando o CRACI não é a resposta

• Os seus pipelines correm em GitLab CI, Jenkins, Azure DevOps ou outro sistema de CI. O CRACI suporta hoje apenas o GitHub Actions, com GitLab CI e Jenkins no roadmap, por isso ainda não substitui nada.
• Os seus builds precisam de runners Windows ou macOS ou de GitHub Enterprise Server, ou têm de correr na sua própria infraestrutura.
• O seu principal problema é o ruído do code scanning no seu próprio código. Isso é um problema de afinação do SAST; consulte SAST vs SCA e como reduzir o ruído das vulnerabilidades.
• O seu principal risco é firmware e binários que recebe de fornecedores, não código que constrói.
• A sua stack é sobretudo Java e Maven, que estão no roadmap, ou .NET, que não está na lista de ecossistemas que o CRACI regista.
• Precisa hoje de priorização baseada em reachability ou de gestão de casos PSIRT.

Para a visão passo a passo do produto, consulte como funciona o CRACI; para a própria SBOM, geração de SBOM.

O que o CRACI substitui: perguntas frequentes

O que é que o CRACI substitui?

Os seus runners de GitHub Actions para jobs Linux, os geradores de SBOM que as equipas executam em CI para os builds que passam para o CRACI, o create-spdx do Yocto para a cobertura da cadeia de abastecimento, os agentes de egress nos runners e o acompanhamento autónomo de vulnerabilidades a partir de SBOM para esses builds. Não substitui ferramentas que leem o seu código, repositórios ou binários de terceiros.

O CRACI é um complemento à nossa ferramenta de SCA, ou substitui alguma coisa?

Substitui tarefas na camada de build: o runner, a geração de SBOM e o acompanhamento que decorre da SBOM. Se isso substitui a sua ferramenta de SCA depende do uso que lhe dá. Se lê o seu código, faz análise de excertos ou de binários ou lhe dá reachability, essas partes ficam.

Continuamos a precisar do nosso gerador de SBOM se executarmos builds no CRACI?

Não para builds que correm no CRACI e usam os ecossistemas que ele regista. O CRACI regista os pacotes que cada job incorporou e exporta a SBOM como CycloneDX ou SPDX. Mantenha um gerador para software que não constrói no CRACI, como imagens que descarrega, e para ecossistemas que o CRACI ainda não regista, como o Maven.

Continuamos a precisar da geração de SBOM integrada do Yocto (create-spdx)?

Para a cobertura da cadeia de abastecimento, não: num build lado a lado de core-image-sato, a SBOM do CRACI tinha todos os componentes da do Yocto, mais 88 que esta não incluía, e o build sem create-spdx demorou menos 43%. Mantenha o create-spdx ativo se depende dos patches aplicados e das CVE marcadas como corrigidas, que o CRACI não regista.

O CRACI substitui o code scanning ou o secret scanning?

Não. O CRACI não lê o seu código-fonte nem os seus commits à procura de falhas ou segredos. Mantenha essas ferramentas. Os passos de code scanning correm sem alterações no seu workflow num runner CRACI, e as funcionalidades ao nível do repositório não são afetadas.

O CRACI substitui a análise de binários ou de firmware?

Não. O CRACI regista os builds que executa. Para firmware e binários que recebe de fornecedores, a análise de binários é a ferramenta certa. Se um fornecedor lhe entregar uma SBOM, o CRACI pode monitorizá-la juntamente com os seus próprios builds.

Podemos manter os nossos passos de segurança atuais no GitHub Actions em runners CRACI?

Sim. O CRACI substitui o runner, não o GitHub Actions: define runs-on como craci e os seus workflows, passos e resultados ficam no GitHub. Os passos de análise, de testes e quaisquer outros continuam a correr como antes.