CRACI vs une stack SBOM maison

En bref

Une stack maison construite avec Syft ou Trivy, Grype, Dependency-Track, Cosign et Renovate ne coûte rien en licences, s'exécute partout et donne à une équipe plateforme compétente un contrôle total. CRACI est un runner GitHub Actions géré qui enregistre ce que chaque build a récupéré, contrôle les destinations auxquelles il peut se connecter, surveille ce qui a été livré et exporte les preuves. La différence tient moins aux fonctionnalités qu'à l'origine de la SBOM et à celui qui entretient les jointures. Si vous construisez sur GitLab, Jenkins ou Windows, ou si tout doit s'exécuter sur votre propre infrastructure, la stack maison est aujourd'hui la recommandation honnête.

À quoi ressemble la stack

Une installation complète à construire soi-même comporte généralement sept couches. Chacune est un vrai projet, avec sa propre maintenance.

1. Génération. Syft (« generating a Software Bill of Materials (SBOM) from container images and filesystems »), Trivy, cdxgen (un projet OWASP qui crée des BOM CycloneDX « from source and container images ») ou le Microsoft SBOM Tool, qui écrit du SPDX et attend en ligne de commande un dossier de dépôt du build, un nom de paquet, une version et un fournisseur.
2. Rapprochement. Grype scanne les images, les systèmes de fichiers et les SBOM, avec EPSS, KEV et un score de risque. OSV-Scanner confronte les lockfiles, les SBOM et les images de conteneur à OSV.dev.
3. Gestion. OWASP Dependency-Track ingère les SBOM CycloneDX et les surveille dans le temps. Son serveur d'API requiert au moins 2 Go de RAM et 2 cœurs de CPU (8 Go et 4 cœurs recommandés), et sa documentation oriente les déploiements en production vers Docker Compose avec une base de données séparée.
4. Signature. Cosign signe les images, les blobs et les attestations de SBOM, avec une signature sans clé via Fulcio et un journal de transparence Rekor. Les GitHub artifact attestations reposent sur Sigstore et fournissent une provenance SLSA v1.0 Build Level 2.
5. Mises à jour. Renovate ou Dependabot ouvrent des pull requests pour maintenir les dépendances à jour.
6. Contrôle du trafic sortant. StepSecurity Harden-Runner peut auditer ou bloquer les connexions sortantes des jobs GitHub Actions. Son offre Community est gratuite pour les dépôts publics sur des runners hébergés par GitHub ; les dépôts privés et les runners auto-hébergés nécessitent l'offre Enterprise. L'alternative est votre propre proxy et des règles de pare-feu autour de runners auto-hébergés.
7. Reporting. Quelqu'un transforme la sortie de tout ce qui précède en documents pour un auditeur, un client ou une documentation technique CRA.

Le coût se cache dans les jointures

Choisir un générateur, c'est choisir ses angles morts

Lancez plusieurs générateurs de SBOM sur le même dépôt et ils ne s'accorderont pas sur ce qu'il contient. Chacun lit un ensemble de fichiers différent et les résout différemment : la liste de composants obtenue dépend donc autant de l'outil choisi que du projet. Le champ fournisseur de la NTIA montre la même chose sous un autre angle : la plupart des générateurs n'ont aucune source pour le renseigner, si bien qu'il reste vide quel que soit le contenu du dépôt.

Aucun de ces outils n'est cassé. Chacun prend une décision différente et documentée sur ce qui compte comme composant et sur les fichiers auxquels se fier. Mais une stack maison hérite des décisions que vous avez retenues, et le reste du pipeline (rapprochement, surveillance, reporting) ne peut pas être plus complet que cette première étape.

L'assemblage vous revient

Chaque outil a son propre rythme de release, sa base de données de vulnérabilités, son format de sortie et sa configuration. Quelqu'un doit épingler les versions, mettre à jour les bases de données, tenir Dependency-Track et sa base de données à jour de leurs correctifs, renouveler les identités de signature, décider quelle SBOM va où, et remarquer lorsqu'une étape se met silencieusement à produire moins. C'est un travail de plateforme continu, pas une installation ponctuelle.

Les outils sont aussi des dépendances

Les outils de sécurité s'exécutent dans vos builds avec accès à vos secrets : ils ont donc leur place dans votre modèle de menaces. En mars 2026, Aqua Security a publié un avis décrivant comment des identifiants compromis ont servi à publier une release malveillante de Trivy et à faire pointer de force la plupart des tags trivy-action vers du code de vol d'identifiants pendant environ 12 heures. Aqua l'a documenté publiquement, et cela aurait pu arriver à n'importe quel projet largement utilisé. Cela montre pourquoi le contrôle du trafic sortant sur le runner compte : une politique de refus par défaut limite les destinations vers lesquelles une étape compromise peut envoyer des données, mais pas tous les canaux (l'avis décrit aussi un mécanisme de repli qui créait des dépôts sur le compte GitHub de la victime).

Quand la stack maison est le bon choix

• Votre CI n'est pas GitHub Actions. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. Les équipes sur GitLab, Jenkins et CircleCI peuvent exécuter tous les outils open source ci-dessus.
• Vous construisez sur Windows ou macOS. Les runners CRACI sont sous Linux (x86-64 et ARM64) aujourd'hui ; Windows et macOS figurent sur la roadmap.
• Tout doit s'exécuter sur votre infrastructure. CRACI exploite aujourd'hui des runners gérés sur une infrastructure européenne, avec des runners hébergés par le client sur la roadmap pour Enterprise.
• Vous avez une équipe plateforme qui veut s'en charger. Si maintenir la stack est un investissement délibéré et que vous exploitez déjà bien Dependency-Track, gardez-la.
• Vous avez besoin d'une SBOM pour un questionnaire. Pour une demande occasionnelle et à faible enjeu, un générateur lancé à la main peut suffire.

Ce que CRACI remplace, et ce qu'il ne remplace pas

CRACI couvre plusieurs couches en un seul endroit, en partant du build. Vous remplacez runs-on par craci, et les exécutions apparaissent toujours dans l'interface GitHub. Un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement, et les preuves de dépendances suivent les caches CI. Chaque job et chaque cache reçoit un état de complétude : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

• Génération : CycloneDX et SPDX à partir du build enregistré, dépendances transitives comprises.
• Surveillance : résultats agrégés sur l'ensemble des builds et des dépôts, avec une réévaluation continue des SBOM surveillées.
• Provenance : l'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance.
• Trafic sortant : politique par job avec 24 presets de sources logicielles intégrés, validée avant le démarrage du job, qui bloque tout en cas d'échec et envoie des alertes en cas de violation.
• Export : SBOM en CycloneDX ou SPDX, vulnérabilités comprises ; pas d'export de rapport.

Il ne remplace pas tout. Les listes de blocage de paquets figurent sur la roadmap. Si vous avez besoin d'une provenance signée, gardez Cosign ou les GitHub artifact attestations. Renovate ou Dependabot restent utiles pour maintenir à jour toutes les dépendances, pas seulement les vulnérables. Si Dependency-Track est l'outil de travail de votre équipe sécurité, la SBOM CycloneDX se télécharge via l'API REST de CRACI et peut l'alimenter.

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 tableurs.

Pour le Cyber Resilience Act

Le CRA demande aux fabricants de recenser et de documenter les vulnérabilités et les composants de leurs produits, « notamment en établissant une nomenclature des logiciels » (annexe I, partie II). Le signalement des vulnérabilités activement exploitées s'applique à partir de septembre 2026, avec 24 heures pour la première notification. Une stack maison peut y contribuer, à condition que quelqu'un soit responsable de la chaîne de preuves qui relie chaque release à sa SBOM. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA, et il soumet en votre nom les notifications prévues par le CRA. Quelle que soit la voie choisie, déterminer ce qui est activement exploité reste du ressort de votre équipe. Voir la conformité au CRA et la génération de SBOM au build.