CRACI vs Snyk

Deux questions différentes

Si vous utilisez déjà Snyk, vous avez une bonne réponse à une question : parmi les paquets open source que mon projet déclare, lesquels présentent des vulnérabilités connues ou des problèmes de licence, et comment les corriger ? Snyk est avant tout un outil d'analyse de la composition logicielle (SCA), et il fait bien ce travail. Il couvre aussi le code propriétaire, les images de conteneurs et l'infrastructure as code.

CRACI répond à une autre question : qu'est-ce que ce build a réellement récupéré, et d'où ? CRACI est un runner CI. Vos jobs GitHub Actions s'y exécutent et, pendant ce temps, il enregistre chaque dépendance externe qu'ils récupèrent. La SBOM, la provenance et les preuves de conformité proviennent toutes de cet enregistrement.

Les deux outils se situent à des points différents du pipeline : il s'agit donc moins d'un face-à-face que d'une carte de ce que chacun couvre.

Ce que Snyk fait bien

Snyk est conçu pour les développeurs. Il fonctionne dans l'IDE, dans la CLI, sur vos dépôts via des intégrations SCM, et dans la CI. Pour les dépendances open source, il priorise les résultats selon des facteurs tels que l'atteignabilité, la maturité des exploits et les scores EPSS et CVSS, et il peut ouvrir des pull requests qui appliquent la mise à niveau à votre place. Il surveille les projets pour détecter les vulnérabilités nouvellement divulguées et prend en charge les politiques de licences.

Au-delà des dépendances, Snyk Code (SAST), Snyk Container et Snyk Infrastructure as Code couvrent un terrain auquel CRACI ne touche pas du tout. CRACI n'est pas un outil d'analyse statique et ne scanne pas votre Terraform. Si vous en avez besoin, Snyk ou un outil similaire reste dans votre stack.

Snyk intervient aussi plus tôt, à partir des dépendances que votre projet déclare, et accompagne ses corrections de pull requests de mise à niveau, de priorisation, de retours dans l'IDE et de politiques de licences. Si vous voulez inciter les développeurs à mettre à niveau dès l'éditeur, c'est pleinement le terrain de Snyk.

Ce qui distingue CRACI

Il enregistre le build au lieu de lire le manifeste

Snyk construit son arbre de dépendances à partir du manifeste et des lockfiles de votre projet. Cela fonctionne bien lorsque le manifeste raconte toute l'histoire. Les builds en font souvent davantage : ils exécutent des scripts d'installation, téléchargent des toolchains, restaurent des caches, récupèrent des images de base et téléchargent des binaires de release avec curl.

CRACI voit cette activité parce qu'il est le runner. Un proxy qui comprend les paquets observe le trafic vers les sources de paquets pendant l'exécution du job. Les écosystèmes détectés comprennent npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache est donc toujours pris en compte.

CRACI vous indique aussi à quel point chaque SBOM est complète. La complétude est indiquée par job et par cache, en cinq états : Complete, Complete with connections, Incomplete, Unavailable et Not recorded. Vous savez quand l'enregistrement présente une lacune, au lieu de supposer qu'il n'y en a pas.

Il contrôle le réseau du build

Comme le build s'exécute sur CRACI, vous pouvez lui fixer une politique de trafic sortant. Les politiques sont en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés et des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec. CRACI peut vous alerter lorsqu'un job enfreint sa politique.

Un scanner examine ce qu'un projet déclare. Un contrôle à l'exécution limite ce que le build peut atteindre pendant qu'il tourne. Ce sont des couches complémentaires.

Il enregistre le build lui-même

CRACI génère la SBOM dans son propre runner, à partir de ce que le build a réellement récupéré. L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance.

Il produit les preuves de conformité à partir du même enregistrement

Pour des réglementations comme le Cyber Resilience Act de l'UE, vous devez montrer ce que contient chaque release et comment vous en suivez les vulnérabilités. CRACI agrège les vulnérabilités entre les builds et les dépôts, continue de réévaluer les SBOM surveillées et les exporte en CycloneDX ou SPDX. Il automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement logicielle dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA. Pour en savoir plus, consultez les preuves CRA et la conformité au CRA.

Un inventaire de ce qui est déployé et où

La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée au lieu de le reconstituer à partir de notes de version et de tableurs.

Une remarque sur l'accès aux SBOM

Snyk peut exporter des SBOM en CycloneDX et SPDX avec la commande snyk sbom. D'après la documentation de Snyk, cette commande n'est disponible que pour les clients des plans Snyk Enterprise. Avec CRACI, chaque build sur le runner produit une SBOM sans frais supplémentaires : CRACI ne facture que les minutes de build. Consultez les tarifs pour les conditions actuelles.

Quand utiliser les deux

Une configuration courante ressemble à ceci :

• Snyk dans l'IDE et sur les pull requests, pour repérer les dépendances vulnérables, les problèmes de code et les erreurs de configuration IaC avant le merge, et pour ouvrir des pull requests de correction.
• CRACI comme runner de vos workflows GitHub Actions, pour enregistrer ce que chaque build a récupéré, appliquer la politique de trafic sortant, produire la SBOM et les données de provenance de chaque build, et conserver les preuves pour les audits.

Les GitHub Actions de Snyk peuvent s'exécuter sur les runners CRACI comme n'importe quelle autre étape. CRACI remplace le runner, pas GitHub Actions, et les exécutions apparaissent toujours dans l'interface GitHub.

Snyk seul convient le mieux si vous ne livrez pas de logiciel sur un marché réglementé, si vos builds sont simples et pilotés par les manifestes, et si votre priorité est de corriger rapidement les problèmes connus. Envisagez d'ajouter CRACI lorsque vous avez besoin de preuves de ce qui est entré dans chaque release, d'un contrôle sur ce que les builds peuvent atteindre, ou de SBOM que vous pouvez défendre lors d'un audit.

CRACI et Snyk : questions fréquentes

Tarifs, export de SBOM et rôle de chaque outil

CRACI est-il une alternative à Snyk ?

Pour une partie de ce que fait Snyk. CRACI enregistre la SBOM de chaque build GitHub Actions, continue de réévaluer les SBOM surveillées pour détecter les nouvelles vulnérabilités et permet aux équipes sécurité de trier les résultats et de les envoyer à l'équipe chargée de la correction. Il ne fait ni SAST, ni scan de conteneurs ou d'IaC, ni analyse d'atteignabilité : c'est donc une alternative lorsque votre question porte sur ce à partir de quoi chaque release a été construite, pas un remplaçant du scan de code de Snyk.

CRACI remplace-t-il Snyk ou fonctionne-t-il à ses côtés ?

La plupart des équipes utilisent les deux côte à côte. Snyk travaille dans l'IDE et sur les pull requests, et repère les dépendances vulnérables, les problèmes de code et les erreurs de configuration IaC avant le merge. CRACI est le runner de vos workflows GitHub Actions : il enregistre ce que chaque build a récupéré, applique la politique de trafic sortant et produit la SBOM et les données de provenance. Les GitHub Actions de Snyk s'exécutent sur les runners CRACI comme n'importe quelle autre étape.

Comment les tarifs de CRACI se comparent-ils à ceux de Snyk ?

Ils ne facturent pas la même chose. En septembre 2026, Snyk propose un plan Free, Team à partir de $25 par mois et un plan Enterprise. CRACI ne facture que les minutes de build, $0.002 par minute vCPU ($0.004 pour un runner 2 vCPU par défaut), sans abonnement mensuel ni frais par SBOM ; consultez les tarifs pour les conditions actuelles.

Quel plan Snyk inclut l'export de SBOM ?

D'après la documentation de Snyk, la commande snyk sbom, qui exporte en CycloneDX et SPDX, n'est disponible que sur les plans Snyk Enterprise. Avec CRACI, chaque build sur le runner produit une SBOM, exportée en CycloneDX ou SPDX avec les dépendances transitives et un état de complétude par job et par cache.

Que fait Snyk que CRACI ne fait pas ?

Snyk Code (SAST), Snyk Container et Snyk Infrastructure as Code couvrent un terrain auquel CRACI ne touche pas. Snyk priorise aussi les résultats open source selon l'atteignabilité, la maturité des exploits, EPSS et CVSS, ouvre des pull requests de mise à niveau et donne aux développeurs un retour dans l'IDE. CRACI ne propose pas d'analyse d'atteignabilité.

Quels systèmes CI Snyk et CRACI prennent-ils en charge ?

Snyk fonctionne dans l'IDE, dans la CLI, via des intégrations SCM et dans les pipelines CI. CRACI est aujourd'hui un runner pour GitHub Actions ; d'autres systèmes CI figurent sur la roadmap, dont GitLab CI et Jenkins. CRACI remplace le runner, pas GitHub Actions : les exécutions apparaissent donc toujours dans GitHub.

CRACI aide-t-il pour le Cyber Resilience Act ?

Oui. CRACI enregistre ce que contient chaque release, continue d'en suivre les vulnérabilités, exporte les SBOM en CycloneDX ou SPDX et soumet en votre nom les notifications de vulnérabilités prévues par le CRA. Il automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves dont votre démarche CRA a besoin ; la conformité au CRA reste la démarche du fabricant. Réservez une démo pour voir les preuves issues de l'un de vos propres builds.