CRACI vs Dependency-Track

Ce que Dependency-Track fait bien

OWASP Dependency-Track est un choix solide pour l'analyse de composants. Il est open source sous licence Apache 2.0, il suit l'utilisation des composants sur toutes les versions de toutes les applications de votre portefeuille, et il récupère des renseignements sur les vulnérabilités auprès de plusieurs sources, dont la National Vulnerability Database et GitHub Advisories. Son moteur de politiques couvre des règles de sécurité, de licences et opérationnelles, et il consomme et produit des documents VEX CycloneDX. Sa conception orientée API convient à la CI/CD : les pipelines importent les SBOM via /api/v1/bom.

Les équipes des secteurs réglementés l'apprécient parce qu'il est transparent, auto-hébergé et construit autour d'un format standard. Son point faible n'est pas l'analyse. C'est ce qu'on lui donne à analyser.

L'analyse dépend de ses données d'entrée

Dependency-Track consomme des SBOM ; il n'en génère pas. Chaque résultat, chaque violation de politique et chaque vue de portefeuille dépend de la SBOM envoyée par votre pipeline. Si la SBOM oublie une dépendance, Dependency-Track ne peut pas la signaler. Si deux générateurs se contredisent, Dependency-Track affiche la SBOM que vous avez importée.

En pratique, les générateurs de SBOM se contredisent beaucoup, et les raisons figurent dans leur propre documentation :

• Aucune base commune. Chaque générateur décide lui-même de ce qui compte comme composant et des fichiers auxquels se fier : deux d'entre eux appliqués au même dépôt renvoient donc des listes qui se recoupent mais diffèrent.
• Passer à côté de l'évidence. Un outil qui résout les dépendances à partir des lockfiles n'a rien à résoudre dans un dépôt qui n'en versionne aucun, comme express 5.2.1. Il peut tout de même renvoyer une liste, composée de tout ce qu'il reconnaît d'autre, comme des GitHub Actions et des fichiers de workflow.
• Des écarts selon la configuration. Syft choisit ses catalogueurs selon le type de scan : une seule option change donc ce que le même outil, dans la même version, signale pour la même copie du dépôt.
• Pas de manifeste, pas de SBOM. Un dépôt sans aucun manifeste de dépendances ne donne à un scanner de fichiers rien sur quoi travailler, et ce que renvoie alors chaque outil en dit plus sur l'outil que sur le projet.
• Des métadonnées pauvres. La plupart des générateurs n'ont aucune source pour le champ fournisseur de la NTIA : il reste vide, quel que soit le contenu du dépôt.

CRACI ne peut pas être comparé de cette manière. Il enregistre des builds au lieu de scanner un répertoire : il ne peut donc pas être exécuté de la même façon. Il ne s'agit pas de dire que ces outils sont mauvais, mais qu'un scan statique d'un dépôt est une estimation de ce qu'un build utilisera, et que cette estimation varie selon l'outil, ses réglages et les fichiers présents.

Ce que CRACI change à la source

La SBOM vient du 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. 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 preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache reste donc dans l'enregistrement. La SBOM, en CycloneDX ou SPDX, inclut toutes les dépendances transitives que le build a réellement utilisées.

Elle vous dit quand elle est incomplète

Chaque SBOM CRACI porte un état de complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Vous savez si chaque SBOM est un enregistrement complet ou si elle comporte une lacune. Cela compte lorsqu'un auditeur vous demande comment vous savez que votre inventaire est complet.

CRACI enregistre la SBOM à l'intérieur du build

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.

Il contrôle ce que le build peut atteindre

Comme CRACI exécute le job, il peut appliquer une politique de trafic sortant : refus ou autorisation par défaut, avec 24 presets intégrés de sources logicielles et des sources personnalisées typées. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec. Dependency-Track peut vous dire après coup qu'un composant présente un risque ; une politique de trafic sortant limite d'emblée les sources auprès desquelles un build peut se fournir.

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.

Remplacer Dependency-Track par CRACI

CRACI couvre les deux moitiés d'un travail qui demandait un générateur et Dependency-Track. Il produit la SBOM dans le build, continue de réévaluer les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées, agrège les résultats sur l'ensemble des builds et des dépôts, et permet aux équipes de sécurité de les trier et d'envoyer chacun à l'équipe responsable du correctif. Il n'y a aucune étape d'import à maintenir ni aucun serveur à exploiter.

Soyez lucide sur ce à quoi vous renoncez. Le moteur de politiques de Dependency-Track est mature. CRACI dispose de policy gates qui bloquent les builds et d'une politique de licences, tandis que les commentaires et les alertes à seuil sont sur la roadmap. Dependency-Track est aussi open source et auto-hébergé, alors que CRACI est aujourd'hui un service managé, avec des runners hébergés par le client sur la roadmap pour Enterprise. Si ces points comptent plus que la qualité de l'inventaire, conservez Dependency-Track.

Pourquoi c'est important dans les secteurs réglementés

En vertu du Cyber Resilience Act de l'UE, les fabricants doivent savoir ce que contient chaque release d'un produit et en traiter les vulnérabilités, avec des obligations de signalement pour les vulnérabilités activement exploitées à partir de septembre 2026. Une vulnérabilité que vous ne pouvez pas voir parce que votre SBOM a oublié le composant reste votre vulnérabilité.

CRACI 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, et exporte les SBOM en CycloneDX ou SPDX, vulnérabilités comprises. L'inventaire et la surveillance proviennent du même enregistrement de ce à partir de quoi chaque release a été construite. Consultez la conformité au CRA, l'IoT industriel et les télécoms.