CRACI vs Endor Labs | Alcançabilidade vs observação do build

A resposta curta

O Endor Labs é uma plataforma de segurança aplicacional construída em torno da alcançabilidade. Analisa o seu código-fonte e as suas dependências para determinar que vulnerabilidades conhecidas a sua aplicação pode chamar e ajuda-o depois a corrigir essas primeiro. Cobre também código próprio, segredos, contentores e pacotes maliciosos.

O CRACI é um runner de CI para GitHub Actions. Os seus jobs correm nele e, enquanto correm, regista todas as dependências externas que obtêm e controla o que podem alcançar na rede. O Endor Labs diz-lhe que conclusões importam. O CRACI dá-lhe um registo do que entrou em cada versão. Os dois complementam-se, sem sobreposição nas suas funções principais.

Visão geral

Funcionalidade	CRACI	Endor Labs
Executa os seus builds	Os jobs correm em runners do CRACI	Analisa dentro da sua CI existente
Dependências registadas a partir do build	Obtenções observadas, incluindo pacotes de caches de CI	Inventário criado pela análise do código-fonte
Política de egress de rede do build	Negação ou permissão por defeito, falha em modo fechado	Fora do seu âmbito: não executa builds
Exportação de SBOM (CycloneDX, SPDX)	Cada build, com completude por job e por cache	SBOM Hub, com VEX baseado em alcançabilidade
Proveniência assinada de artefactos	Sem proveniência assinada	endorctl artifact sign, com proveniência
Monitorização contínua	As SBOM monitorizadas são reavaliadas continuamente	O risco é atualizado à medida que surgem vulnerabilidades
Alcançabilidade ao nível da função		Análise estática de programas em dependências diretas e transitivas
SAST, segredos e contentores		AI SAST, deteção de segredos, análise de contentores
Bloqueio de pacotes maliciosos	Listas de bloqueio de pacotes a nível da organização	Package Firewall, um proxy à frente dos registos
Sistemas de CI	Hoje GitHub Actions; GitLab CI e Jenkins no roadmap	GitHub Actions, GitLab, Jenkins, CircleCI, Buildkite, Bitbucket
Preços	$0.002 por vCPU-minuto ($0.004 com 2 vCPU), medido ao segundo; sem mensalidade e sem custo por SBOM	Plano Developer gratuito; Core e Pro com preço por programador contribuidor, através da equipa comercial (em setembro de 2026).

Incluído
Não incluído
No roadmap

O que o Endor Labs faz bem

A página inicial de Endor Labs — endorlabs.com

A alcançabilidade é o grande destaque. O Endor Labs usa análise estática de programas para fazer análise de alcançabilidade ao nível da função em dependências diretas e transitivas, seguindo os caminhos de código desde o seu código-fonte até à função vulnerável. Quando não é possível um build completo, a alcançabilidade ao nível da dependência e a pré-calculada oferecem alternativas menos precisas. O Endor Labs afirma que isto reduz as conclusões de SCA em 92%, ao filtrar vulnerabilidades que não podem ser chamadas no seu código. Para uma equipa afogada em alertas de dependências, é o alívio mais direto disponível.

A vertente da correção também é forte. A análise do impacto de atualizações procura alterações incompatíveis antes de atualizar e atribui um risco de remediação, os pull requests automatizados trazem a atualização, e os Endor Patches aplicam uma correção de segurança upstream à versão que já executa, quando uma atualização não é praticável.

Para além das dependências open source, a plataforma inclui AI SAST, deteção de segredos, análise de contentores, deteção de pacotes maliciosos e um Package Firewall que funciona como proxy entre o seu repositório de artefactos e os registos públicos. O seu SBOM Hub gera e importa SBOM CycloneDX e SPDX, produz documentos VEX baseados em alcançabilidade e continua a atualizar o risco à medida que são publicadas novas vulnerabilidades. O Endor Labs integra-se com GitHub Actions, GitLab, Jenkins, CircleCI, Buildkite e Bitbucket, e as linguagens suportadas incluem C e C++, Java, Go, Rust, Python e JavaScript.

O CRACI não faz qualquer análise de alcançabilidade, SAST, segredos ou contentores. Se precisar disso, mantenha o Endor Labs ou uma ferramenta semelhante.

Onde o CRACI é diferente

O build é a fonte da verdade

O Endor Labs trata o código-fonte como a verdade de base para o seu inventário, o que apanha dependências diretas, transitivas e fantasma que um manifesto por si só deixaria escapar. O CRACI parte de outro ponto: o próprio build. Um proxy que reconhece pacotes no runner observa o tráfego para origens de pacotes durante a execução do job, em origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. A evidência acompanha as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado. Como o runner vê o tráfego, as dependências obtidas por scripts de instalação ou passos de transferência também são observadas, e não apenas as indicadas num manifesto.

Cada SBOM traz um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Quando o registo tem uma lacuna, é informado disso.

Controlo sobre o que o build pode alcançar

Como o CRACI é o runner, pode definir uma política de egress para cada job: negação ou permissão por defeito, com 24 predefinições integradas de origens de software e origens personalizadas tipadas para registos e Git. As políticas são validadas antes de o job arrancar e falham em modo fechado. O Package Firewall do Endor Labs filtra que pacotes entram através do seu repositório de artefactos. A política do CRACI limita todas as ligações que o build faz. São camadas diferentes que funcionam bem em conjunto.

Proveniência e monitorização do que foi distribuído

O Endor Labs assina artefactos; o CRACI não. Os dados do CRACI vêm do runner que observou o build, e a API devolve SBOM, traços de rede e proveniência. O CRACI agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas.

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.

Qual é o mais adequado

O seu problema é o volume de alertas: comece pelo Endor Labs. A alcançabilidade e a análise do impacto de atualizações visam diretamente isso.
O seu problema é provar o que está numa versão: o CRACI regista-o a partir do build.
Preocupa-o o que os builds podem transferir: a política de egress do CRACI limita o runner, e o Package Firewall do Endor Labs filtra pacotes. Use ambos se o risco for elevado.
Usa GitLab, Jenkins ou CircleCI: o Endor Labs cobre-os hoje. O CRACI suporta apenas GitHub Actions, pelo que esses pipelines teriam de passar para GitHub Actions para correrem no CRACI. O GitLab CI e o Jenkins estão no roadmap.

Para o Cyber Resilience Act

O Endor Labs inclui o Cyber Resilience Act da UE entre os requisitos de evidências que o SBOM Hub suporta, e o seu resultado VEX ajuda a explicar porque é que uma vulnerabilidade não afeta um produto. 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: SBOM geradas durante o build com completude indicada, dados de proveniência, acompanhamento contínuo de vulnerabilidades e exportação de SBOM em CycloneDX ou SPDX. Nenhuma das ferramentas torna um produto conforme por si só. Saiba mais em o que é o CRA e conformidade com o CRA.

Adicionar o CRACI ao lado do Endor Labs

Nada na sua configuração do Endor Labs tem de mudar. Instale a GitHub App do CRACI e altere runs-on para craci nos workflows que pretende registar. As execuções continuam a aparecer na interface do GitHub, e um passo de endorctl corre num runner do CRACI como qualquer outro passo. Saiba mais sobre a geração de SBOM durante o build e a integração de CI/CD.