CRACI vs Safeguard | SBOM do build vs análise e correção

A resposta curta

O Safeguard vende uma plataforma de segurança da cadeia de abastecimento de software. O seu site diz que encontra vulnerabilidades, incluindo algumas que ainda não têm CVE, as filtra com análise de alcançabilidade e faz com que os seus modelos Griffin AI escrevam a correção, executem a sua CI e façam o merge do pull request segundo a sua política. Gera SBOM em CycloneDX e SPDX, regista proveniência SLSA, mapeia evidências para referenciais de conformidade e corre em cloud, on-premise ou isolado da rede. Não executa builds: a sua CLI corre na CI que já tem.

O CRACI compete pelo mesmo orçamento de cadeia de abastecimento a partir de outra posição. É o runner para GitHub Actions: regista os pacotes que cada job realmente trouxe, aplica uma política de egress enquanto o job corre e continua a monitorizar o que foi distribuído. O Safeguard cobre mais terreno em torno do código; o CRACI vai mais fundo no build e no que dele resultou.

Visão geral

Funcionalidade	CRACI	Safeguard
Executa os seus builds	Os jobs correm em runners do CRACI	Liga-se a repositórios e executa uma CLI na CI que já utiliza
De onde vem a SBOM	Registada pelo runner a partir do que cada job obteve, incluindo restauros de cache de CI.	Análises de repositórios, imagens de contentor e manifestos carregados; a sua documentação diz que a CLI executa Syft e Grype.
Estado de completude da SBOM	Por job e por cache, cinco estados	Não indicado
Política de egress de rede do build	Negação ou permissão por defeito, validada antes do job, falha em modo fechado	Fora do seu âmbito: o Safeguard não executa builds
Proveniência assinada	Sem proveniência assinada	Proveniência SLSA e assinatura sigstore ou cosign, segundo o seu site
Monitorizar o que foi distribuído	SBOM monitorizadas reavaliadas continuamente	Análises em cada push, agendadas ou em cada lançamento
Pull requests de correção escritos por IA		A Griffin AI escreve a correção, executa a sua CI e faz o merge segundo a política
Análise de alcançabilidade		Filtra as conclusões para o código alcançável
Segredos e configurações incorretas		A CLI reporta-os em SARIF
Registo de componentes reforçados		Registo Gold de imagens e pacotes reforçados
SBOM de fornecedores	É possível adicionar e monitorizar SBOM de fornecedores	Third Party Risk Manager com verificação de SBOM de fornecedores
Sistemas de CI	Hoje GitHub Actions; GitLab CI e Jenkins no roadmap	A documentação cobre GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps
Implementação	Runners geridos em infraestrutura europeia; runners alojados pelo cliente no roadmap.	Cloud; on-premise e isolada da rede no nível Sovereign.
Atestações de segurança	Certificado ISO 27001; detalhes no Trust Center.	Auditoria SOC 2 Type II em curso; arquitetura concebida para FedRAMP High e IL5, segundo a sua página de segurança.
Preço	$0.002 por vCPU-minuto ($0.004 com 2 vCPU), medido ao segundo; sem mensalidade nem custos por SBOM	Plano gratuito; planos individuais de $9 a $99 por mês; Team a partir de $19 por utilizador por mês; Business e superiores sob orçamento (em setembro de 2026).

Incluído
Não incluído
No roadmap

A coluna do Safeguard reflete o que o seu próprio site e a sua documentação indicam, verificado a 29 de setembro de 2026. "Não indicado" significa que não o conseguimos confirmar aí.

O que o Safeguard faz bem

A página inicial de Safeguard — safeguard.sh

Correções, não apenas conclusões. O Safeguard diz que a Griffin AI prova a alcançabilidade, escreve uma atualização compatível, executa a sua CI e o seu conjunto de testes de regressão num branch isolado e faz o merge segundo os seus policy gates. Todos os planos pagos incluem uma quota mensal de pull requests de correção.
A alcançabilidade primeiro. As conclusões são filtradas para o código vulnerável que a sua aplicação pode realmente alcançar, o que mantém a fila curta.
Para além das dependências. A sua CLI reporta também segredos e configurações incorretas em SARIF, que aparece no separador de code scanning do GitHub, e a plataforma descreve a análise de código-fonte, IaC e contentores.
Componentes reforçados. Um diretório público Gold e um registo de imagens e pacotes reforçados, para que as equipas possam partir de componentes sem CVE conhecidos.
Risco de fornecedores. Um Third Party Risk Manager pontua fornecedores e verifica as SBOM que estes fornecem, e um Portal publica as suas SBOM para os clientes.
Amplitude de CI, opções de implementação e um plano gratuito. A sua documentação cobre GitHub Actions, GitLab CI/CD, Jenkins e Azure DevOps. Oferece implementação on-premise e isolada da rede no nível Sovereign, publica preços self-serve e tem um plano gratuito sem necessidade de cartão.

Onde o CRACI é diferente

Registado a partir do build, não analisado depois

A documentação do Safeguard diz que a sua CLI executa Syft e Grype, e que constrói SBOM a partir de repositórios ligados, imagens de contentor e manifestos carregados, como package.json e requirements.txt. É a forma habitual de construir uma SBOM: ler os ficheiros e deduzir o que entrou. O CRACI vê, em vez disso, o tráfego que entra em cada build. Um proxy que reconhece pacotes regista cada pacote que o job obteve de fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de descarga, e os pacotes restaurados de caches de CI ficam no registo.

É assim que o CRACI regista as dependências ocultas que as ferramentas baseadas em lockfiles não veem: código transferido por hooks de instalação npm, scripts de build em Rust que obtêm dados durante o build e as camadas da imagem base de um build de contentor. Cada SBOM traz um estado de completude por job e por cache (Complete, Complete with connections, Incomplete, Unavailable ou Not recorded), pelo que, quando o registo tem uma lacuna, di-lo.

Controlo durante o build

Um scanner reporta o que encontra a posteriori. Como o CRACI é o runner, decide a que hosts um job se pode ligar enquanto corre. As políticas de egress são de negação ou de permissão por defeito, com 24 predefinições integradas de fontes de software e fontes personalizadas tipadas, validadas antes de o job arrancar, e falham em modo fechado. Com uma política de negação por defeito, um pacote comprometido que tente enviar os seus segredos para um host desconhecido é bloqueado, mesmo num ataque que ninguém viu antes, e o CRACI alerta-o para a violação.

Proveniência e monitorização a partir de um único registo

O Safeguard diz que gera, guarda e verifica proveniência SLSA. A proveniência do CRACI vem do runner onde o job correu: a API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência e não reivindica nenhum nível SLSA. Continua a reavaliar as SBOM do que distribuiu à medida que são publicadas novas vulnerabilidades e mostra todos os builds anteriores que continham uma dependência vulnerável, para que saiba durante quanto tempo esteve exposto.

O runner faz parte do produto

Como o CRACI é o runner, as evidências vêm com a computação: as execuções continuam a aparecer no GitHub, e o CRACI executa builds cerca de duas vezes mais depressa do que os runners alojados no GitHub, graças a hardware mais rápido, tempos de fila mais curtos e cache. O CRACI cobra apenas os minutos de build, $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), medido ao segundo, sem mensalidade nem custos por SBOM. Consulte os preços do CRACI.

Qual se adequa melhor

O Safeguard é a melhor opção quando

Quer que os pull requests de correção sejam escritos, testados e integrados em seu lugar.
Quer análise de alcançabilidade e conclusões sobre segredos e configurações incorretas na mesma plataforma.
Constrói em GitLab, Jenkins ou Azure DevOps.
Precisa hoje de implementação on-premise ou isolada da rede.
Quer um registo de componentes reforçados ou pontuação do risco de fornecedores a par das suas SBOM.

O CRACI é a melhor opção quando

Constrói em GitHub Actions e quer o runner, a política de egress e o registo de dependências num só lugar.
Precisa de uma SBOM do que cada build realmente obteve, com um estado de completude que possa mostrar a um auditor.
Quer monitorizar o que foi distribuído e ter o histórico de builds a partir do mesmo registo.

Substituir o Safeguard pelo CRACI

Para o software que constrói em GitHub Actions, o CRACI assume a função de SBOM e de monitorização: regista a SBOM no build com a completude indicada, continua a reavaliar as SBOM monitorizadas, agrega conclusões de todos os builds e repositórios e permite às equipas de segurança fazer a sua triagem e encaminhar cada uma para a equipa responsável pela correção. Os policy gates podem bloquear um build com base em conclusões, incluindo um CVE específico.

Tenha bem presente aquilo de que abdica. O CRACI não abre pull requests de correção, não tem análise de alcançabilidade, não procura segredos nem configurações incorretas, não oferece um registo de componentes reforçados, não tem proveniência assinada nem nível SLSA, não deteta novos pacotes maliciosos pelo comportamento (assinala versões maliciosas conhecidas depois de publicado um aviso de segurança com CVE) e não tem hoje opção on-premise nem isolada da rede. Executa apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Se a remediação automatizada ou essas opções de implementação importarem mais do que um registo do que serviu de base a cada versão, o Safeguard é a opção mais forte.

O que verificar antes de comprar qualquer ferramenta de SBOM

Estas perguntas aplicam-se a todos os fornecedores desta categoria, incluindo o CRACI.

Como é produzida a SBOM? Pergunte que ferramenta a gera e a partir de quê: lockfiles e manifestos, uma análise da imagem final ou um registo do build. Depois, execute-a num dos seus próprios builds e compare as listas de componentes, incluindo as dependências transitivas.
Confirme as certificações junto do emissor. Um certificado ou uma autorização pode ser confirmado junto da entidade que o emitiu, e "designed for" ou "aligned with" um referencial não é o mesmo que detê-lo. A página de segurança do Safeguard descreve a sua arquitetura como concebida para FedRAMP High e IL5 e a sua auditoria SOC 2 Type II como estando em curso; em linha com essa formulação, o Safeguard não constava do FedRAMP Marketplace quando verificámos, a 29 de setembro de 2026. O CRACI detém a certificação ISO/IEC 27001 emitida pela Into Certification, com detalhes no seu Trust Center.
Peça referências. O site do Safeguard descreve os seus clientes de forma anónima, sob NDA. Seja qual for o fornecedor que considerar, incluindo o CRACI, peça uma chamada de referência com uma equipa semelhante à sua.
Confirme o preço por escrito. Os preços publicados mudam. A página de preços do Safeguard nota que os valores são propostas sujeitas a aprovação final.

Requisitos de SBOM

Vários referenciais pedem uma SBOM e uma forma de tratar as respetivas vulnerabilidades: a US Executive Order 14028 orienta as regras de contratação federal em torno das SBOM, a secção 524B da FDA exige uma para cyber devices, e o Cyber Resilience Act da UE pede aos fabricantes que documentem os seus componentes. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que esses processos precisam: SBOM do build exportadas em CycloneDX ou SPDX, acompanhamento de vulnerabilidades e proveniência através da API. Consulte evidências para o CRA. Nenhuma das ferramentas torna um produto conforme por si só.

Para outras ferramentas nesta área, consulte CRACI vs Anchore, CRACI vs Syft e Grype e ferramentas de SBOM comparadas.

Safeguard: perguntas e respostas

O que é o Safeguard?

O Safeguard (Safeguard.sh Inc, Dublin, Califórnia, segundo o seu site) vende uma plataforma de segurança da cadeia de abastecimento de software. O seu site descreve geração de SBOM em CycloneDX e SPDX, proveniência SLSA, análise de alcançabilidade, pull requests de correção escritos por IA com os seus modelos Griffin, gestão de risco de terceiros, um registo de componentes reforçados e implementação em cloud, on-premise ou isolada da rede.

Como gera o Safeguard as SBOM?

Segundo a sua documentação, o Safeguard constrói SBOM a partir de repositórios ligados, imagens de contentor e manifestos de pacotes carregados, e a sua CLI (safeguard scan) executa Syft e Grype no seu pipeline. A sua comparação com o Anchore apresenta a sua SBOM como CycloneDX e SPDX "via Syft". O CRACI não analisa: executa o build e regista os pacotes que cada job obteve.

O Safeguard fornece runners de CI?

Não. A documentação de CI do Safeguard mostra a sua CLI a correr em pipelines de GitHub Actions, GitLab CI/CD, Jenkins e Azure DevOps que o cliente opera, e nota que a CLI reporta conclusões sem fazer falhar o build; a aplicação acontece nos policy gates da plataforma. O CRACI é o runner: os jobs de GitHub Actions correm no CRACI, que regista o que cada job obteve e controla o que pode alcançar.

Quanto custa o Safeguard?

Em setembro de 2026, a página de preços do Safeguard indica um plano gratuito com 5 pull requests de correção, 100 componentes analisados e 100 chamadas de ferramentas MCP por mês; planos individuais a $9, $25, $49 e $99 por mês; planos Team a $19, $49 e $99 por utilizador por mês, com um mínimo de dois utilizadores; e Business, Enterprise e Sovereign sob orçamento. Os pacotes de conformidade custam $2,099 por referencial por ano. A página nota que os valores são propostas sujeitas a aprovação final, pelo que deve confirmar os preços atuais com o Safeguard. O CRACI cobra apenas os minutos de build: $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), medido ao segundo.

O CRACI pode substituir o Safeguard?

Para as SBOM, a proveniência e a monitorização de vulnerabilidades do software que constrói em GitHub Actions, sim: o CRACI produz a SBOM a partir do próprio build e continua a monitorizá-la. O CRACI não substitui os pull requests de correção por IA, a análise de alcançabilidade, a deteção de segredos e de configurações incorretas, o registo de componentes reforçados nem a implementação isolada da rede do Safeguard, e executa hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap.