CRACI vs Snyk

Duas perguntas diferentes

Se já usa o Snyk, tem uma boa resposta para uma pergunta: quais dos pacotes open source que o meu projeto declara têm vulnerabilidades conhecidas ou problemas de licenças, e como os corrijo? O Snyk é, na sua essência, uma ferramenta de análise de composição de software (SCA), e faz bem esse trabalho. Cobre também código próprio, imagens de contentores e infraestrutura como código.

O CRACI responde a uma pergunta diferente: o que é que este build realmente descarregou, e de onde? O CRACI é um runner de CI. Os seus jobs de GitHub Actions correm nele e, enquanto correm, regista todas as dependências externas que obtêm. A SBOM, a proveniência e as evidências de conformidade vêm todas desse registo.

As duas ferramentas situam-se em pontos diferentes do pipeline, razão pela qual isto é menos um confronto direto e mais um mapa de quem cobre o quê.

O que o Snyk faz bem

O Snyk foi feito para programadores. Funciona no IDE, na CLI, nos seus repositórios através de integrações SCM e na CI. Para dependências open source, prioriza as conclusões com fatores como a alcançabilidade, a maturidade do exploit e as pontuações EPSS e CVSS, e pode abrir pull requests que aplicam a atualização por si. Monitoriza os projetos em busca de vulnerabilidades recém-divulgadas e suporta políticas de licenças.

Para além das dependências, o Snyk Code (SAST), o Snyk Container e o Snyk Infrastructure as Code cobrem terreno em que o CRACI não toca de todo. O CRACI não é uma ferramenta de análise estática e não analisa o seu Terraform. Se precisa disso, o Snyk ou uma ferramenta semelhante mantém-se no seu conjunto de ferramentas.

O Snyk também começa mais cedo, a partir das dependências que o seu projeto declara, e integra as suas correções em pull requests de atualização, priorização, feedback no IDE e políticas de licenças. Se quer que os programadores sejam encaminhados para as atualizações logo a partir do editor, isso é claramente território do Snyk.

Onde o CRACI difere

Regista o build em vez de ler o manifesto

O Snyk constrói a sua árvore de dependências a partir do manifesto e dos lockfiles do seu projeto. Isso funciona bem quando o manifesto conta toda a história. Mas os builds fazem muitas vezes mais: executam scripts de instalação, descarregam toolchains, restauram caches, obtêm imagens base e vão buscar binários de release com curl.

O CRACI vê essa atividade porque é o runner. Um proxy que reconhece pacotes observa o tráfego para as fontes de pacotes enquanto o job corre. Os ecossistemas detetados incluem fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como predefinições de descarga. As evidências de dependências acompanham as caches de CI, pelo que um pacote restaurado de uma cache continua a ser contabilizado.

O CRACI diz-lhe também quão completa é cada SBOM. A completude é indicada por job e por cache, em cinco estados: Complete, Complete with connections, Incomplete, Unavailable e Not recorded. Fica a saber quando o registo tem uma lacuna, em vez de presumir que não tem.

Controla a rede do build

Como o build corre no CRACI, pode definir uma política de egress para ele. As políticas são de negação ou permissão por defeito, com 24 predefinições integradas de fontes de software e fontes personalizadas tipadas para npm, PyPI, apt, apk, o proxy Go, Nix, Cargo, registos OCI e Git. As políticas são validadas antes de o job arrancar e falham em modo fechado. O CRACI pode alertá-lo quando um job viola a sua política.

Um scanner analisa o que um projeto declara. Um controlo em tempo de execução limita o que o build pode alcançar enquanto corre. São camadas complementares.

Regista o próprio build

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

Produz evidências de conformidade a partir do mesmo registo

Para regulamentos como o EU Cyber Resilience Act, tem de mostrar o que está em cada versão e como acompanha as vulnerabilidades nela presentes. O CRACI agrega vulnerabilidades de todos os builds e repositórios, continua a reavaliar as SBOM monitorizadas e exporta-as em CycloneDX ou SPDX. Automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de software de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA. Saiba mais sobre evidências para o CRA e conformidade com 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 lançamento e folhas de cálculo.

Uma nota sobre o acesso a SBOM

O Snyk pode exportar SBOM em CycloneDX e SPDX com o comando snyk sbom. Segundo a documentação do Snyk, esse comando está disponível apenas para clientes em planos Snyk Enterprise. Com o CRACI, cada build no runner produz uma SBOM sem custo adicional: o CRACI fatura apenas os minutos de build. Consulte os preços para as condições atuais.

Quando usar ambos

Uma configuração comum é a seguinte:

• Snyk no IDE e nos pull requests, a apanhar dependências vulneráveis, problemas de código e configurações incorretas de IaC antes do merge, e a abrir pull requests de correção.
• CRACI como runner dos seus workflows de GitHub Actions, a registar o que cada build obteve, a aplicar a política de egress, a produzir a SBOM e os dados de proveniência de cada build e a guardar as evidências para auditorias.

As GitHub Actions do Snyk podem correr em runners do CRACI como qualquer outro passo. O CRACI substitui o runner, não o GitHub Actions, e as execuções continuam a aparecer na interface do GitHub.

O Snyk sozinho é a melhor opção se não lança software para um mercado regulado, os seus builds são simples e orientados por manifestos, e a sua prioridade é corrigir rapidamente problemas conhecidos. Considere acrescentar o CRACI quando precisar de evidências do que entrou em cada versão, de controlo sobre o que os builds podem alcançar ou de SBOM que possa defender numa auditoria.

CRACI e Snyk: perguntas frequentes

Preços, exportação de SBOM e onde se encaixa cada ferramenta

O CRACI é uma alternativa ao Snyk?

Para parte do que o Snyk faz. O CRACI regista a SBOM de cada build de GitHub Actions, continua a reavaliar as SBOM monitorizadas face a novas vulnerabilidades e permite às equipas de segurança fazer a triagem das conclusões e enviá-las à equipa responsável pela correção. Não faz SAST, análise de contentores ou de IaC, nem análise de alcançabilidade, pelo que é uma alternativa quando a sua pergunta é com o que foi construída cada versão, e não um substituto da análise de código do Snyk.

O CRACI substitui o Snyk ou funciona ao lado dele?

A maioria das equipas usa-os lado a lado. O Snyk trabalha no IDE e nos pull requests, apanhando dependências vulneráveis, problemas de código e configurações incorretas de IaC antes do merge. O CRACI é o runner dos seus workflows de GitHub Actions: regista o que cada build obteve, aplica a política de egress e produz a SBOM e os dados de proveniência. As GitHub Actions do Snyk correm em runners do CRACI como qualquer outro passo.

Como se comparam os preços do CRACI e do Snyk?

Cobram coisas diferentes. Em setembro de 2026, o Snyk tem um plano Free, o Team a partir de $25 por mês e um plano Enterprise. O CRACI cobra apenas os minutos de build, $0.002 por vCPU-minuto ($0.004 para um runner predefinido de 2 vCPU), sem mensalidade e sem custo por SBOM; consulte os preços para as condições atuais.

Que plano do Snyk inclui a exportação de SBOM?

Segundo a documentação do Snyk, o comando snyk sbom, que exporta CycloneDX e SPDX, está disponível apenas nos planos Snyk Enterprise. Com o CRACI, cada build no runner produz uma SBOM, exportada em CycloneDX ou SPDX com dependências transitivas e um estado de completude por job e por cache.

O que faz o Snyk que o CRACI não faz?

O Snyk Code (SAST), o Snyk Container e o Snyk Infrastructure as Code cobrem terreno em que o CRACI não toca. O Snyk também prioriza as conclusões open source por alcançabilidade, maturidade do exploit, EPSS e CVSS, abre pull requests de atualização e dá feedback aos programadores no IDE. O CRACI não oferece análise de alcançabilidade.

Que sistemas de CI suportam o Snyk e o CRACI?

O Snyk funciona no IDE, na CLI, através de integrações SCM e em pipelines de CI. O CRACI é hoje um runner para GitHub Actions; outros sistemas de CI estão no roadmap, entre eles o GitLab CI e o Jenkins. O CRACI substitui o runner, não o GitHub Actions, pelo que as execuções continuam a aparecer no GitHub.

O CRACI ajuda com o Cyber Resilience Act?

Sim. O CRACI regista o que está em cada versão, continua a acompanhar as vulnerabilidades nela presentes, exporta SBOM em CycloneDX ou SPDX e submete as notificações de vulnerabilidades do CRA em seu nome. Automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de que o seu processo de CRA precisa; cumprir o CRA continua a ser um processo do fabricante. Marque uma demo para ver as evidências de um dos seus próprios builds.