Mais 123% CVE comunicadas por dia em 2026 do que no ano passado.

Comparação

CRACI vs Harness

O Harness é uma plataforma de entrega de software com CI própria e um módulo Supply Chain Security que gera SBOM e proveniência SLSA no pipeline. O CRACI é o runner em que os seus jobs de GitHub Actions correm, pelo que a SBOM, a política de rede e a proveniência vêm do próprio build.

Atualizado a

A resposta curta

O Harness, fundado em 2017 e sediado em São Francisco, vende uma plataforma para tudo o que vem depois de o código estar escrito: integração contínua, entrega contínua, feature flags, gestão de custos de cloud, chaos engineering e testes de segurança. O seu módulo Supply Chain Security (SCS) acrescenta geração de SBOM, proveniência SLSA, barreiras de política OPA e verificações de postura para repositórios e pipelines. Se quer um único fornecedor para todo o pipeline de entrega, em vários fornecedores de Git, o Harness foi feito para isso.

O CRACI é mais restrito e vai mais fundo no build. É um runner de GitHub Actions: enquanto cada job corre, regista todas as dependências externas que o build obtém, aplica uma política de egress à rede do build e produz SBOM, dados de proveniência e monitorização de vulnerabilidades a partir desse registo. O Harness acrescenta passos de cadeia de abastecimento a um pipeline; o CRACI faz do próprio runner o registo de segurança.

Há um ponto prático que vem primeiro. O CRACI suporta hoje apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Os pipelines do Harness CI teriam de passar para GitHub Actions para correrem no CRACI.

Visão geral

Funcionalidade CRACI Harness
Como é produzida a SBOM Registada a partir do que cada job obteve, com estado de completude O Syft ou o cdxgen analisa uma imagem ou um repositório num passo do pipeline
Formatos de SBOM CycloneDX e SPDX SPDX e CycloneDX
Proveniência do build Dados de proveniência via API; não assinados SLSA Build L1 a L3, assinada com cosign
Política de egress de rede do build Negação ou permissão por defeito, validada antes do job, falha em modo fechado Afirma detetar chamadas de rede anómalas do runner
Barreiras de política Bloqueia um build por conclusões, um CVE específico ou uma licença Políticas OPA sobre SBOM, proveniência e implementações
Monitorizar o que foi distribuído As SBOM monitorizadas são reavaliadas continuamente Assinala pipelines e artefactos expostos a um novo CVE
Verificações de postura de CI/CD e repositórios OWASP Top 10 CI/CD Risks e benchmarks CIS
Sistemas de CI Hoje GitHub Actions; GitLab CI e Jenkins no roadmap Harness CI; passos SCS também para GitHub Actions e GitLab CI/CD
Plataformas de runners alojados Linux em x86-64 e ARM64, 1 a 32 vCPU. Windows e macOS no roadmap. Linux AMD64 até 96 núcleos e ARM64 até 64, Windows e macOS em Apple M4.
Infraestrutura de build self-hosted Runners alojados pelo cliente, Enterprise Kubernetes, VM ou bare metal
Entrega, feature flags, gestão de custos O CRACI cobre o build Módulos da mesma plataforma
Preço, Linux com 2 vCPU $0.004 por minuto ($0.002 por vCPU-minuto), medido ao segundo. $0.005 por minuto com 2 núcleos e 7 GB, arredondado ao minuto mais próximo.
Planos Paga por minuto de build: $0.004 por minuto com 2 vCPU, medido ao segundo. Sem mensalidade e sem custo por SBOM. Plano gratuito com 2.000 créditos Harness Cloud por mês; planos pagos, pacotes de créditos e Supply Chain Security através da equipa comercial (em setembro de 2026).
  • Incluído
  • Em parte
  • Não incluído
  • No roadmap

O que o Harness faz bem

A página inicial de Harness
harness.io

Uma só plataforma de entrega. O Harness cobre CI, CD, GitOps, feature flags, infraestrutura como código, chaos engineering e gestão de custos de cloud, com aplicação de políticas baseada em OPA em todos eles. Funciona com GitHub, GitLab, Bitbucket, Azure Repos e os seus próprios repositórios Harness Code, e afirma servir mais de 1.000 clientes empresariais, com mais de 1.200 colaboradores.

Escolha da infraestrutura de build. O Harness Cloud executa builds em máquinas Linux, Windows e macOS geridas pelo Harness: Linux AMD64 de 2 a 96 núcleos, ARM64 de 2 a 64 núcleos à mesma tarifa, e macOS em Apple M4. A virtualização aninhada está disponível em Linux AMD64. Pode também executar builds nos seus próprios clusters Kubernetes, VM ou bare metal. O Test Intelligence executa apenas os testes afetados por uma alteração, e o Build Intelligence e as funcionalidades de cache reutilizam resultados e dependências inalterados.

Funcionalidades de cadeia de abastecimento no pipeline. O passo SBOM Orchestration do módulo SCS gera uma SBOM para uma imagem de contentor ou um repositório de código com o Syft ou o cdxgen, em SPDX ou CycloneDX, e pode importar SBOM de outras ferramentas. O Harness afirma gerar e atualizar SBOM em cada build. As políticas OPA podem bloquear builds e implementações com base em componentes, licenças ou proveniência, e um acompanhamento de remediação segue os artefactos vulneráveis.

Proveniência SLSA. O Harness documenta SLSA Build Level 1, 2 e 3 em SLSA v1.0, com proveniência assinada através de atestações in-toto e cosign. A sua documentação indica que o Level 3 precisa de infraestrutura de build reforçada ou do Harness Cloud, que isola os processos de build uns dos outros.

Verificações de postura e de pipeline. O SCS audita repositórios e pipelines face ao OWASP Top 10 CI/CD Security Risks e a benchmarks CIS, e assinala GitHub Actions não fixadas, não verificadas e com permissões excessivas. O Harness oferece também os seus passos SCS como GitHub Actions e componentes de GitLab CI/CD, pelo que o módulo não está preso ao Harness CI; esses passos precisam de uma conta Harness com uma licença SCS.

Onde o CRACI é diferente

A SBOM vem do build, não de uma análise do seu resultado

O Syft e o cdxgen são scanners: leem uma imagem ou um repositório a posteriori e inferem o que lá está a partir de lockfiles, manifestos e bases de dados de pacotes. Isso funciona bem quando esses ficheiros contam toda a história. Os builds fazem muitas vezes mais: scripts de instalação transferem código, scripts de build de Rust obtêm elementos durante o build, e as caches restauram pacotes que nenhum lockfile menciona.

O CRACI vê esse tráfego porque é o runner. Um proxy que reconhece pacotes regista o que cada job obtém de origens de pacotes, em 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. Regista as dependências ocultas que as ferramentas baseadas em lockfiles deixam escapar, e cada SBOM indica quão completa é, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Uma política na rede do build, não deteção depois dele

O Harness afirma que o seu módulo deteta comportamentos anómalos do runner de CI, incluindo chamadas de rede e escalonamento de privilégios. O CRACI segue o caminho inverso: uma política de egress no runner decide que hosts um job pode alcançar. As políticas são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software e origens personalizadas tipadas, validadas antes de o job arrancar, e falham em modo fechado. Como uma política de negação por defeito permite apenas aquilo de que o build precisa, em vez de procurar hosts maliciosos conhecidos, bloqueia a exfiltração para o servidor de um atacante mesmo num ataque que ninguém viu antes. As violações enviam um alerta.

Proveniência e monitorização a partir do mesmo registo

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; o Harness assina a sua proveniência e documenta os Levels 1 a 3, e se a proveniência assinada ou um nível SLSA for um requisito de aquisição, isso conta a favor do Harness. O CRACI agrega vulnerabilidades de todos os builds e repositórios, continua a reavaliar as SBOM monitorizadas à medida que surgem avisos de segurança e mostra que builds anteriores continham uma dependência vulnerável, para que saiba durante que período esteve afetado.

Preços que se conseguem ler

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 e sem custo por SBOM. O Harness publica as tarifas do Harness Cloud, $0.005 por minuto para uma máquina Linux de 2 núcleos com 7 GB e $0.080 para 32 núcleos, faturadas ao minuto mais próximo, enquanto os seus planos pagos e o módulo SCS têm preço através da equipa comercial. O preço de tabela do CRACI é 20% mais baixo por minuto em ambos os tamanhos ($0.004 face a $0.005, $0.064 face a $0.080); as máquinas do Harness têm mais memória por núcleo.

Qual é o mais adequado

  • Fique com o Harness se quer CI, CD, feature flags e gestão de custos de um só fornecedor, se o seu código está no GitLab, no Bitbucket ou no Azure Repos, se precisa de Windows, macOS ou do seu próprio hardware de build, ou se um SLSA Build Level 3 documentado é um requisito.
  • Escolha o CRACI se o seu código está no GitHub e usa ou planeia usar GitHub Actions, e quer que a SBOM, a política de rede e a proveniência venham do runner que fez o build, com preço por minuto de build.

Tenha bem presente aquilo de que abdica ao escolher o CRACI. Não implementa software, não executa feature flags nem gere custos de cloud, e não verifica repositórios e pipelines face a benchmarks de postura nem analisa código-fonte. Executa hoje apenas jobs Linux, com Windows e macOS no roadmap, e os runners alojados pelo cliente estão no roadmap para Enterprise.

Para produtos regulados

Referenciais como o Cyber Resilience Act da UE esperam que os fabricantes saibam o que está em cada versão e tratem as suas vulnerabilidades, com obrigações de reporte a partir de setembro de 2026. O Harness fornece SBOM, proveniência e resultados de políticas a partir dos seus passos de pipeline. O CRACI produz as evidências a partir do registo do build e exporta SBOM em CycloneDX ou SPDX. Automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que uma empresa precisa para o seu processo mais amplo de CRA; nenhuma das ferramentas torna um produto conforme por si só.

Migrar um pipeline para o CRACI

O CRACI substitui o runner, não o GitHub Actions, e as execuções continuam a aparecer na interface do GitHub. Quando um pipeline corre como workflow de GitHub Actions, corre no CRACI com uma linha:

runs-on: craci

Saiba mais sobre a geração de SBOM durante o build, compare plataformas de CI/CD, veja as alternativas ao Harness ou consulte os preços.

Execute um build real e compare

Aponte um workflow de GitHub Actions para o CRACI e compare a SBOM resultante com a que um passo de scanner produz hoje.

Marcar demo