CRACI et Dependabot

Gardez Dependabot. Voici ce qu'il couvre.

Si votre code se trouve sur GitHub, vous utilisez probablement déjà Dependabot. Il fait trois choses utiles. Les alertes Dependabot vous préviennent lorsqu'une dépendance de votre dépôt correspond à une vulnérabilité connue. Les security updates ouvrent des pull requests qui mettent à niveau les dépendances vulnérables. Les version updates maintiennent les dépendances à jour même quand rien n'est vulnérable.

Tout cela repose sur le graphe de dépendances de GitHub, qui analyse les manifestes et les lockfiles de votre dépôt. GitHub peut exporter ce graphe sous forme de SBOM SPDX. Pour des écosystèmes comme Go, Gradle et Maven, des actions toutes prêtes peuvent soumettre les dépendances résolues au moment du build via la dependency submission API.

Pour tenir les dépendances à jour de leurs correctifs avec peu d'efforts, Dependabot est difficile à battre, et CRACI n'ouvre pas de pull requests. Ce que CRACI ajoute, c'est l'autre moitié : un enregistrement de ce que chaque build a réellement récupéré, surveillé pour détecter de nouvelles vulnérabilités, afin que vous sachiez quels builds livrés un nouvel avis de sécurité affecte et quelles pull requests de mise à jour fusionner en premier.

Les questions auxquelles Dependabot ne répond pas

Dependabot est construit autour du dépôt. Il scanne la branche par défaut et s'appuie sur vos manifestes et vos lockfiles. La documentation de GitHub est claire à ce sujet : les alertes ne peuvent pas détecter tous les problèmes de sécurité, vous devez tenir à jour les manifestes et les lockfiles pour une détection exacte, et seuls les avis examinés par GitHub déclenchent des alertes.

Il reste donc des questions qu'on finira par poser à un responsable de la sécurité ou de la conformité :

• Qu'a réellement téléchargé le build de la release 4.2, y compris les outils et images absents de tout manifeste ?
• Un build pouvait-il atteindre un hôte quelconque sur Internet pendant son exécution ?
• Pouvez-vous prouver que le binaire reçu par un client provient de ce build ?
• Pouvez-vous produire ces preuves pour un auditeur des mois plus tard ?

Pour y répondre, il faut une vue depuis l'intérieur du build, là où CRACI s'exécute.

Ce que CRACI ajoute

Visibilité pendant le build

CRACI est un runner compatible avec GitHub Actions. Vous remplacez runs-on par craci, et vos jobs s'exécutent sur CRACI dans des machines virtuelles isolées, tandis que les exécutions restent visibles dans l'interface GitHub. Pendant chaque job, un proxy qui comprend les paquets enregistre le trafic vers les sources de paquets : sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, plus des presets de téléchargement. Les paquets restaurés depuis les caches CI sont conservés, car les preuves de dépendances suivent le cache.

Chaque SBOM indique son degré de complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. C'est différent d'un graphe qui ne vaut que ce que valent les fichiers qu'il analyse.

La différence se voit en pratique. L'export du graphe de dépendances de GitHub est construit à partir de ce que GitHub sait du dépôt : il peut donc lister des composants qu'aucun scanner de fichiers ne trouve, et il reflète la branche par défaut plutôt que le commit à partir duquel le build a été fait. Aucun de ces comportements n'est mauvais pour ce à quoi le graphe est destiné. Ils montrent pourquoi une vue du dépôt et un enregistrement de build sont deux choses différentes. (CRACI ne peut pas être comparé de cette manière, car il enregistre des builds au lieu de scanner des répertoires.)

Contrôles à l'exécution

Dependabot vous signale un paquet vulnérable une fois qu'il figure dans votre manifeste. Il n'a aucune prise sur ce à quoi un build peut se connecter. CRACI si, car il exécute le build. Les politiques de trafic sortant sont en refus ou en autorisation par défaut, avec 24 presets intégrés de sources logicielles, des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git, et des règles explicites TLS, TCP, UDP et ICMP. Les politiques sont validées avant le démarrage du job, bloquent tout en cas d'échec et déclenchent une alerte en cas de violation.

Provenance

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

Preuves de conformité

Des réglementations comme le Cyber Resilience Act de l'UE demandent aux fabricants de savoir ce que contient chaque release et d'en traiter les vulnérabilités. CRACI agrège les vulnérabilités sur l'ensemble des builds et des dépôts, continue de réévaluer les SBOM surveillées à mesure que de nouveaux avis paraissent, et exporte les SBOM en CycloneDX ou SPDX, vulnérabilités comprises. 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 ce qu'est le CRA et les preuves pour le CRA.

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

La vue d'inventaire de CRACI montre exactement quelles versions logicielles sont déployées sur quels produits, dans le monde entier. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version affectée au lieu de le reconstituer à partir de notes de version et de tableurs.

Comment les équipes utilisent les deux

• Dependabot tient les dépendances à jour de leurs correctifs sur la branche par défaut et ouvre des pull requests lorsque des avis de sécurité paraissent.
• CRACI exécute les jobs GitHub Actions, enregistre ce que chaque build a récupéré, limite les destinations auxquelles les builds peuvent se connecter, surveille ce que chaque build a récupéré pour détecter de nouvelles vulnérabilités, et conserve les preuves de release.

Il n'y a rien à migrer. Dependabot continue de fonctionner sur vos dépôts, et vos workflows continuent de s'exécuter sur GitHub Actions, simplement sur un autre runner.

CRACI et Dependabot : questions fréquentes

Ce que couvre chaque outil, SBOM, tarifs et conformité

CRACI remplace-t-il Dependabot ?

Non. Gardez Dependabot activé. Il signale les dépendances vulnérables de vos dépôts et ouvre des pull requests pour les mettre à niveau. CRACI exécute vos jobs GitHub Actions et enregistre ce que chaque build a réellement récupéré, contrôle les destinations auxquelles les builds peuvent se connecter et surveille ce qui a été livré pour y détecter de nouvelles vulnérabilités.

Les vues de vulnérabilités de CRACI remplacent-elles les alertes Dependabot ?

Non. Elles répondent à une autre question. Les alertes Dependabot portent sur la branche par défaut d'un dépôt. CRACI agrège les vulnérabilités sur l'ensemble des builds et des dépôts et continue de réévaluer les SBOM surveillées : vous voyez ainsi quels builds partagent une dépendance vulnérable, et les équipes de sécurité peuvent trier les résultats et les envoyer à l'équipe responsable du correctif. Des policy gates peuvent bloquer un build ; les alertes à seuil sont sur la roadmap.

CRACI ouvre-t-il des pull requests comme Dependabot ?

Non. Les security updates et version updates de Dependabot ouvrent des pull requests ; pas CRACI. Ce que CRACI apporte, c'est l'enregistrement du build : lorsqu'un nouvel avis de sécurité paraît, vous savez quels builds livrés il affecte et quelles pull requests de mise à jour fusionner en premier.

En quoi les SBOM de GitHub et de CRACI diffèrent-elles ?

GitHub exporte le graphe de dépendances sous forme de SBOM SPDX, construite à partir des manifestes et des lockfiles du dépôt et de la dependency submission API, et elle reflète la branche par défaut. CRACI enregistre la SBOM pendant l'exécution de chaque build et l'exporte en CycloneDX ou SPDX, avec un état de complétude par job et par cache qui vous indique si l'enregistrement comporte une lacune.

CRACI aide-t-il lorsqu'une dépendance ne figure dans aucun manifeste ?

Oui, si le build la récupère depuis une source de paquets. Comme CRACI enregistre le trafic pendant le job, un outil téléchargé par un script ou un paquet restauré depuis un cache apparaît quand même dans l'enregistrement du build, et l'état de complétude de la SBOM vous indique si quelque chose n'a pas pu être enregistré.

Combien coûtent Dependabot et CRACI ?

Les security updates et version updates de Dependabot sont incluses dans tous les plans GitHub, y compris Free (en septembre 2026). CRACI ne facture que les minutes de build : $0.002 par minute vCPU ($0.004 pour un runner par défaut à 2 vCPU), mesurées à la seconde, sans frais mensuels ni frais par SBOM. Consultez les tarifs pour les conditions actuelles.

CRACI est-il réservé aux équipes soumises à des exigences de conformité ?

Non, mais c'est là que les preuves sont les plus rentables. Si vous vendez des logiciels dans l'UE, le Cyber Resilience Act fait d'un inventaire des composants par release et du traitement des vulnérabilités une partie du travail. Pour tous les autres, savoir ce que récupèrent vos builds reste la base de la réponse aux incidents de la chaîne d'approvisionnement. Réservez une démo pour voir l'enregistrement de build de l'un de vos propres workflows.