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

Comparação

CRACI e Dependabot

O Dependabot é muitas vezes a primeira ferramenta de cadeia de abastecimento que uma equipa no GitHub ativa, e deve continuar ativo. O CRACI acrescenta o que o Dependabot nunca foi concebido para ver: o que os seus builds realmente fizeram.

Atualizado a

Mantenha o Dependabot. Eis o que cobre.

A página inicial de Dependabot
github.com

Se o seu código está no GitHub, provavelmente já usa o Dependabot. Faz três coisas úteis. Os alertas do Dependabot avisam quando uma dependência do seu repositório corresponde a uma vulnerabilidade conhecida. As atualizações de segurança abrem pull requests que atualizam dependências vulneráveis. As atualizações de versão mantêm as dependências em dia, mesmo quando nada está vulnerável.

Tudo isto assenta no grafo de dependências do GitHub, que interpreta os manifestos e lockfiles do seu repositório. O GitHub pode exportar esse grafo como SBOM SPDX. Para ecossistemas como Go, Gradle e Maven, actions pré-criadas podem submeter dependências resolvidas durante o build através da API de submissão de dependências.

Para manter as dependências corrigidas com pouco esforço, é difícil bater o Dependabot, e o CRACI não abre pull requests. O que o CRACI acrescenta é a outra metade: um registo do que cada build realmente trouxe, monitorizado quanto a novas vulnerabilidades, para que saiba que builds distribuídos um novo aviso de segurança afeta e que pull requests de atualização deve integrar primeiro.

As perguntas a que o Dependabot não responde

O Dependabot é construído em torno do repositório. Analisa o branch predefinido e depende dos seus manifestos e lockfiles. A documentação do GitHub é direta quanto a isto: os alertas não conseguem detetar todos os problemas de segurança, deve manter os manifestos e lockfiles atualizados para uma deteção exata, e só os avisos revistos pelo GitHub desencadeiam alertas.

Isso deixa perguntas que, mais cedo ou mais tarde, serão feitas a um responsável de segurança ou de conformidade:

  • O que descarregou realmente o build da versão 4.2, incluindo ferramentas e imagens que não constam de nenhum manifesto?
  • Um build podia alcançar um host arbitrário na internet durante a execução?
  • Consegue provar que o binário que um cliente recebeu veio desse build?
  • Consegue apresentar essas evidências a um auditor meses depois?

Responder a isso exige uma visão a partir do interior do build, que é onde o CRACI funciona.

Funcionalidade CRACI Dependabot
Executa os seus builds Os jobs correm em runners do CRACI Lê dados do repositório, não o build
Dependências registadas a partir do build Obtenções observadas, incluindo restauros de caches de CI Manifestos e lockfiles, mais a API de submissão de dependências
Exportação de SBOM CycloneDX e SPDX, completude por job e por cache Exportação SPDX do grafo de dependências
Política de egress de rede do build Negação ou permissão por defeito, falha em modo fechado Fora do seu âmbito
Alertas de vulnerabilidades Agregados entre builds e repositórios A partir de avisos revistos pelo GitHub
Monitorização de novos avisos SBOM monitorizadas reavaliadas continuamente Alertas do branch predefinido à medida que surgem avisos
Abre pull requests de atualização Atualizações de segurança e de versão
Triagem e encaminhamento para as equipas responsáveis Entre builds e repositórios Alertas por repositório
Funciona sem mudar de runners Os jobs têm de correr no CRACI Integrado nos repositórios do GitHub
Evidências de conformidade SBOM em CycloneDX ou SPDX, registos via API; sem exportação de relatórios Vistas de alertas e a exportação SPDX no GitHub
  • Incluído
  • Em parte
  • Não incluído

O que o CRACI acrescenta

Visibilidade durante o build

O CRACI é um runner compatível com GitHub Actions. Muda runs-on para craci e os seus jobs correm no CRACI em máquinas virtuais isoladas, enquanto as execuções continuam a aparecer na interface do GitHub. Durante cada job, um proxy que reconhece pacotes regista o tráfego para as origens de pacotes: origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. Os pacotes restaurados de caches de CI são mantidos, porque a evidência das dependências acompanha a cache.

Cada SBOM indica a sua completude, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. É diferente de um grafo que só é tão bom quanto os ficheiros que interpreta.

A diferença nota-se na prática. A exportação do grafo de dependências do GitHub é construída a partir do que o GitHub sabe sobre o repositório, pelo que pode listar componentes que nenhum scanner baseado em ficheiros encontra, e reflete o branch predefinido e não o commit que compilou. Nenhum destes comportamentos está errado para aquilo que o grafo foi concebido para fazer. Mostram porque é que uma vista do repositório e um registo do build são coisas diferentes. (O CRACI não pode ser comparado dessa forma, pois regista builds em vez de analisar diretórios.)

Controlos em tempo de execução

O Dependabot informa sobre um pacote vulnerável depois de este estar no seu manifesto. Não tem voto na matéria quanto àquilo a que um build se pode ligar. O CRACI tem, porque executa o build. As políticas de egress são de negação ou de permissão por defeito, com 24 predefinições integradas de origens de software, origens personalizadas tipadas para npm, PyPI, apt, apk, o proxy Go, Nix, Cargo, registos OCI e Git, e regras explícitas de TLS, TCP, UDP e ICMP. As políticas são validadas antes de o job começar, falham em modo fechado e desencadeiam um alerta em caso de violação.

Proveniência

O CRACI gera a SBOM dentro do seu próprio runner, a partir do que o job obteve. A API devolve SBOM, traços de rede e proveniência.

Evidências de conformidade

Regulamentos como o Cyber Resilience Act da UE pedem aos fabricantes que saibam o que está em cada versão do produto e que tratem as vulnerabilidades nela presentes. O CRACI agrega vulnerabilidades entre builds e repositórios, continua a reavaliar as SBOM monitorizadas à medida que surgem novos avisos e exporta SBOM em CycloneDX ou SPDX, incluindo vulnerabilidades. 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. Saiba mais sobre o que é o CRA e as evidências para o CRA.

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 versão e folhas de cálculo.

Como as equipas usam ambos

  • O Dependabot mantém as dependências corrigidas no branch predefinido e abre pull requests quando surgem avisos de segurança.
  • O CRACI executa os jobs de GitHub Actions, regista o que cada build obteve, limita onde os builds se podem ligar, monitoriza o que cada build trouxe quanto a novas vulnerabilidades e guarda as evidências de versão.

Não há nada a migrar. O Dependabot continua a funcionar nos seus repositórios, e os seus workflows continuam a correr em GitHub Actions, apenas num runner diferente.

O CRACI suporta hoje GitHub Actions, que é o mesmo sítio onde o Dependabot funciona. Leia sobre a geração de SBOM durante o build, o acompanhamento de vulnerabilidades e os preços.

CRACI e Dependabot: perguntas frequentes

O que cada ferramenta cobre, SBOM, preços e conformidade

O CRACI substitui o Dependabot?

Não. Mantenha o Dependabot ativo. Assinala dependências vulneráveis nos seus repositórios e abre pull requests que as atualizam. O CRACI executa os seus jobs de GitHub Actions, regista o que cada build realmente trouxe, controla onde os builds se podem ligar e monitoriza o que foi distribuído quanto a novas vulnerabilidades.

As vistas de vulnerabilidades do CRACI substituem os alertas do Dependabot?

Não. Respondem a uma pergunta diferente. Os alertas do Dependabot dizem respeito ao branch predefinido de um repositório. O CRACI agrega vulnerabilidades entre builds e repositórios e continua a reavaliar as SBOM monitorizadas, pelo que pode ver que builds partilham uma dependência vulnerável, e as equipas de segurança podem fazer a triagem das conclusões e enviá-las à equipa responsável pela correção. As políticas podem bloquear um build; os alertas por limiar estão no roadmap.

O CRACI abre pull requests como o Dependabot?

Não. As atualizações de segurança e de versão do Dependabot abrem pull requests; o CRACI não. O que o CRACI acrescenta é o registo do build, para que, quando surge um novo aviso de segurança, saiba que builds distribuídos são afetados e que pull requests de atualização deve integrar primeiro.

Em que diferem as SBOM do GitHub e do CRACI?

O GitHub exporta o grafo de dependências como SBOM SPDX, construído a partir dos manifestos e lockfiles do repositório e da API de submissão de dependências, e reflete o branch predefinido. O CRACI regista a SBOM durante a execução de cada build e exporta-a em CycloneDX ou SPDX, com um estado de completude por job e por cache que indica se o registo teve uma lacuna.

O CRACI ajuda quando uma dependência não consta de nenhum manifesto?

Sim, se o build a obtiver de uma origem de pacotes. Como o CRACI regista o tráfego durante o job, uma ferramenta descarregada por um script ou um pacote restaurado de uma cache continua a aparecer no registo do build, e o estado de completude da SBOM indica se algo não pôde ser registado.

Quanto custam o Dependabot e o CRACI?

As atualizações de segurança e de versão do Dependabot estão incluídas em todos os planos do GitHub, incluindo o Free (em setembro de 2026). 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 custo por SBOM. Consulte os preços para as condições atuais.

O CRACI destina-se apenas a equipas com requisitos de conformidade?

Não, mas é aí que as evidências mais compensam. Se vende software na UE, o Cyber Resilience Act torna um inventário de componentes por versão e o tratamento de vulnerabilidades parte do trabalho. Para todos os outros, saber o que os seus builds obtêm continua a ser a base da resposta a incidentes da cadeia de abastecimento. Marque uma demo para ver o registo do build de um dos seus próprios workflows.

Veja o que o Dependabot não consegue ver

Execute um workflow de GitHub Actions no CRACI e compare o registo do build com o seu grafo de dependências.

Marcar demo