Vous scannez déjà vos dépendances. Voici ce qu'un scanner ne peut pas voir.

Ce que votre stack actuelle fait bien

Si vous avez configuré le SCA et la génération de SBOM, vous avez déjà fait le plus dur sur le plan organisationnel : les dépendances sont suivies, les avis de sécurité parviennent aux développeurs, et vous avez un fichier à remettre quand on vous le demande. Gardez cela.

• Le graphe de dépendances de GitHub et Dependabot sont activés par défaut pour de nombreuses équipes. GitHub décrit le graphe de dépendances comme un résumé des manifestes et des lockfiles stockés dans un dépôt, ainsi que des dépendances soumises pour ce dépôt via l'API de soumission de dépendances. Les alertes Dependabot s'appuient dessus et vous préviennent lorsqu'un nouvel avis est publié ou lorsque votre graphe de dépendances change.
• Les outils SCA commerciaux tels que Snyk génèrent aussi des SBOM. Sa commande snyk sbom lit les manifestes et leurs lockfiles, et produit du CycloneDX ou du SPDX. En septembre 2026, la documentation de Snyk la réserve aux clients des plans Snyk Enterprise.
• Les générateurs open source tels que Syft, Trivy et cdxgen sont gratuits, rapides et faciles à ajouter à la CI. Syft se présente comme un outil de génération de Software Bill of Materials (SBOM) à partir d'images de conteneur et de systèmes de fichiers.

Ces outils excellent dans le retour rapide sur une pull request, la large couverture d'écosystèmes et un processus de correction que les développeurs connaissent déjà. CRACI ne remplace pas cela aujourd'hui. Son suivi des vulnérabilités agrège les résultats de l'ensemble des builds et des dépôts et réévalue les SBOM surveillées à mesure que de nouvelles vulnérabilités apparaissent. Les équipes sécurité peuvent trier les résultats et les envoyer à la bonne équipe. Les policy gates peuvent bloquer un build ; les webhooks de vulnérabilités figurent sur la roadmap.

Scanner ou enregistreur

Tous les outils ci-dessus sont des scanners. Vous les dirigez vers une arborescence source, un lockfile ou une image de conteneur, et ils en déduisent ce qui y est entré. Cela fonctionne lorsque les fichiers disent tout. C'est plus difficile lorsque ce n'est pas le cas :

• Le dépôt n'a pas de lockfile : les versions sont donc décidées au moment de l'installation.
• Le build restaure des paquets depuis un cache CI qu'aucun manifeste ne mentionne.
• Une étape de build télécharge directement un outil, un paquet système ou un binaire.
• Un hook d'installation npm ou un script de build Rust récupère du code supplémentaire pendant l'installation, la voie empruntée par le ver Shai-Hulud.
• Un build de conteneur récupère une image de base et ses couches de système d'exploitation, qu'aucun lockfile de langage ne liste.
• Ce que vous livrez est un binaire compilé, et le manifeste à côté ne liste presque rien.

CRACI est un enregistreur : il voit le trafic, ce que les scanners ne font pas. Il exécute le build sur son propre runner compatible avec GitHub Actions, et un proxy qui comprend les paquets observe le trafic vers les sources de paquets pendant l'exécution du job : ces dépendances cachées se retrouvent donc dans la SBOM. Les paquets restaurés depuis un cache conservent leurs preuves. Il n'existe pas de commande craci scan ./dir, car scanner un répertoire après coup est précisément l'étape que CRACI a été conçu pour éviter.

Ce dont dépend un scan

Le résultat d'un scanner dépend de l'outil et de ce vers quoi il est dirigé. Syft, Trivy, cdxgen, Microsoft SBOM Tool, l'export du graphe de dépendances de GitHub et la CLI Socket établissent chacun la liste à partir de ce qu'ils peuvent lire. Les constats ci-dessous découlent du fonctionnement documenté de ces outils.

Aucun composant n'est trouvé par tous les outils

Chaque générateur décide lui-même de ce qui constitue un composant et des fichiers auxquels se fier : le même checkout donne donc à chacun une liste différente. L'export du graphe de dépendances de GitHub fonctionne encore autrement : il est construit à partir de ce que GitHub sait du dépôt plutôt que des fichiers lus par un scanner, et il lit la branche par défaut plutôt qu'un commit épinglé.

Pas de lockfile, pas de dépendances

Express 5.2.1 ne commite aucun lockfile. Dirigé vers un checkout propre, un générateur qui résout les dépendances à partir de lockfiles ou d'une arborescence installée n'a ni l'un ni l'autre sous la main : aucune des dépendances npm déclarées dans package.json n'atteint donc le document. Aucun outil ici n'est défaillant. Ce qui décide si la SBOM contient la moindre dépendance, ce n'est pas l'outil. C'est le fait que quelqu'un ait lancé une installation auparavant.

Une option change la réponse

Le scan de répertoire par défaut de Syft indique ce qu'un projet déclare, pas ce qui est installé sur le disque. Sur un checkout installé de la même release d'express, une seule option de cataloger décide si les paquets npm installés apparaissent ou non dans la liste. Même outil, même version, même arborescence.

Le produit est un binaire

Le dépôt anthropics/claude-code en v2.1.259 ne comporte ni manifeste de dépendances ni lockfile, de quelque type que ce soit. Son paquet npm publié déclare zéro dépendance d'exécution et encapsule un binaire natif précompilé via huit paquets de plateforme. @openai/codex 0.149.1 a la même structure. Un lecteur de manifestes n'a presque rien à décrire, alors que le programme qui s'exécute est un binaire compilé : ce que renvoie chaque outil en dit donc plus sur l'outil que sur le projet.

Même paquet, versions différentes

Lorsque deux outils trouvent la même chose, ils ne s'accordent pas toujours sur ce que c'est. L'un peut épingler une GitHub Action sur un SHA de commit tandis que l'autre indique un tag de release. Une recherche de vulnérabilités fondée sur la mauvaise version renvoie une réponse fausse, avec assurance.

La place de CRACI à côté de votre SCA

Gardez votre SCA sur les pull requests. C'est le bon endroit pour repérer une version vulnérable avant son merge. Ajoutez CRACI là où la question porte sur le build plutôt que sur le diff :

• Que contenait réellement cette release ? La SBOM enregistrée couvre les sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement, y compris les dépendances transitives. Les miroirs JFrog Artifactory pour npm et PyPI fonctionnent aussi.
• Peut-on se fier à la liste ? Chaque job et chaque cache ont un état de complétude : un enregistrement incomplet est donc visible au lieu de rester discrètement lacunaire.
• Sommes-nous touchés par un nouvel avis de sécurité ? Les SBOM surveillées sont réévaluées à mesure que de nouvelles vulnérabilités sont publiées, et les résultats sont agrégés sur l'ensemble des builds et des dépôts.

La SBOM se télécharge en CycloneDX via l'API REST publique, avec la trace réseau et la provenance du job : elle peut donc alimenter tout outil qui lit le CycloneDX, y compris le SCA que vous utilisez déjà. La mise en place tient en une ligne dans le workflow : remplacez runs-on par craci. GitHub Actions est la CI prise en charge aujourd'hui ; GitLab CI, Jenkins et d'autres systèmes CI figurent sur la roadmap.

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 reconstituer l'information à partir de notes de version et de feuilles de calcul.

Pour en savoir plus, consultez la génération de SBOM au build et le suivi des vulnérabilités.