La génération de SBOM, enregistrée pendant le build
CRACI est un outil de génération de SBOM qui enregistre ce que chaque build GitHub Actions a réellement récupéré, au lieu de scanner des fichiers après coup. Chaque SBOM indique son niveau de complétude.
En bref : exécutez vos jobs GitHub Actions sur des runners CRACI et chaque job obtient une SBOM des paquets qu'il a récupérés, y compris les dépendances transitives et les paquets restaurés depuis les caches CI, exportée en CycloneDX ou SPDX. Chaque SBOM porte un état de complétude et reste surveillée après la mise en production pour détecter de nouvelles vulnérabilités. Les outils de scan comme Syft et Trivy reconstituent une SBOM à partir de fichiers ; CRACI l'enregistre à partir du build. Pourquoi les SBOM générées au build sont différentes.
Enregistrée pendant le build, pas scannée après coup
La plupart des générateurs de SBOM lisent des fichiers une fois le build terminé et reconstituent ce qui, selon eux, y est entré. CRACI génère la SBOM dans son propre runner CI. Un proxy qui comprend les paquets observe le trafic de chaque job vers les sources de paquets : la SBOM liste donc ce que le job a réellement récupéré, dépendances transitives comprises, et non ce qu'un manifeste dit qu'il devrait nécessiter. Ni lockfile, ni arborescence installée, ni étape de scan supplémentaire ne sont nécessaires pour que l'enregistrement existe.
Les dépendances transitives, à tous les niveaux
L'essentiel de ce qu'un build récupère n'est pas une dépendance directe. C'est la dépendance d'une dépendance, plusieurs niveaux plus bas, et une partie n'apparaît jamais dans un lockfile : binaires précompilés téléchargés par un script de build, paquets restaurés depuis un cache, paquets du système d'exploitation. CRACI enregistre chaque paquet récupéré par le job, à tous les niveaux de profondeur, afin que les vulnérabilités soient recherchées sur l'arbre complet. Lors de comparaisons directes avec d'autres outils SBOM, cet enregistrement plus complet a révélé des vulnérabilités que les autres outils n'avaient pas signalées.
Les paquets restaurés depuis les caches CI restent dans la SBOM
C'est souvent sur les caches que l'enregistrement pendant le build échoue : un paquet restauré depuis un cache ne passe jamais par un registre, si bien qu'un proxy seul ne le verrait pas. CRACI transmet les preuves de dépendances avec le cache, de sorte que les paquets restaurés depuis un cache CI restent dans la SBOM du job qui les a restaurés.
Un état de complétude pour chaque job
Le suivi des vulnérabilités ne peut porter que sur les composants listés dans votre SBOM. Un paquet absent de la SBOM, c'est une vulnérabilité pour laquelle personne ne sera alerté. Plutôt que de présenter chaque SBOM comme complète, CRACI indique la complétude de chaque job et de chaque cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Vous savez quelles SBOM sont fiables et lesquelles méritent un second examen.
Les écosystèmes et les formats que vous livrez
CRACI enregistre les paquets provenant de npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et de sources Git, ainsi que des presets de téléchargement Yocto et OpenEmbedded, et considère les miroirs npm et PyPI de JFrog Artifactory comme des sources connues. La prise en charge de Maven et Java figure sur la roadmap. Les SBOM s'exportent en CycloneDX et SPDX, dépendances transitives comprises, prêtes à être partagées avec vos clients, partenaires et auditeurs.
Les licences déclarées de chaque composant
Chaque paquet enregistré apporte sa licence déclarée dans la SBOM. Vous voyez quelles dépendances relèvent d'une licence commerciale ou restrictive avant de livrer, et les licences copyleft sont repérées avant de se retrouver dans votre produit.
La provenance via l'API
La SBOM n'est qu'une partie de ce que CRACI enregistre pour chaque job. La REST API publique renvoie les SBOM, les traces réseau et la provenance, toutes enregistrées à partir du même build.
Surveillée après la mise en production
Une SBOM permet à une entreprise de savoir ce que contient le logiciel qu'elle livre, et clients comme régulateurs l'exigent de plus en plus : le Cyber Resilience Act impose aux fabricants d'en établir une pour les produits vendus dans l'UE. CRACI réévalue en continu les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées, agrège les résultats de l'ensemble des builds et des dépôts, et prend en charge VEX. Les SBOM que vous recueillez auprès de vos propres fournisseurs sont surveillées aux côtés de vos builds.
Une SBOM enregistrée face à une SBOM scannée
Les scanners sont le bon outil pour les logiciels que vous n'avez pas construits. Pour vos propres releases, voici ce que change l'enregistrement du build. Un scanner lit le lockfile ou le résultat du build et en déduit ce qui y est entré. CRACI voit le trafic qui entre dans le build : les dépendances cachées qu'apportent les hooks d'installation, les scripts de build et les images de base se retrouvent donc elles aussi dans la SBOM.
| Fonctionnalité | CRACI | Outil SBOM basé sur un scanner |
|---|---|---|
| Comment la liste des composants est produite | Enregistrée à partir du trafic de paquets du build lui-même | Reconstituée après coup à partir de fichiers |
| Nécessite un lockfile ou des dépendances installées | Non | Généralement l'un ou l'autre |
| Paquets restaurés depuis les caches CI | Les preuves suivent le cache | Seulement si les fichiers sont présents au moment du scan |
| État de complétude par job | Cinq états, par job et par cache | |
| Lien signé entre l'artefact et le build | Pas de provenance signée | Avec une étape de signature distincte |
| Logiciels que vous n'avez pas construits | Ajoutez plutôt la SBOM du fournisseur | |
| Systèmes CI | GitHub Actions aujourd'hui ; autres systèmes CI sur la roadmap | Fonctionne dans n'importe quelle CI |
- Inclus
- En partie
- Non inclus
- Sur la roadmap
Vous comparez des outils précis ? Consultez le comparatif des outils SBOM pour Syft, Trivy, cdxgen, le Microsoft SBOM Tool, Dependency-Track et d'autres. Pour une vue d'ensemble, consultez le comparatif des outils de sécurité de la chaîne d'approvisionnement logicielle.
SBOM basics: SPDX, CycloneDX and OpenVEX
Ce qu'enregistre une SBOM, en quoi les formats SPDX et CycloneDX diffèrent en pratique, et ce qu'OpenVEX apporte pour savoir si une vulnérabilité affecte réellement un produit.
Petteri Pulkkinen et Erika Marttinen lors de Kubernetes Community Days Helsinki 2026, 16:50 à 22:05 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Génération de SBOM : questions fréquentes
Qu'est-ce que la génération de SBOM ?
La génération de SBOM consiste à produire une nomenclature logicielle (software bill of materials) : une liste lisible par machine des composants et dépendances d'un logiciel. Elle peut se faire à partir des fichiers source, pendant le build, ou en analysant un artefact final tel qu'une image de conteneur. CRACI génère la SBOM pendant le build, à partir de ce que le build a réellement récupéré.
Comment CRACI génère-t-il une SBOM ?
Vos jobs GitHub Actions s'exécutent sur des runners CRACI. Pendant l'exécution de chaque job, un proxy qui comprend les paquets observe son trafic vers les sources de paquets et enregistre les paquets qu'il récupère, y compris les dépendances transitives et les paquets restaurés depuis les caches CI. Chaque job obtient sa propre SBOM, avec un état de complétude.
Dois-je modifier mes workflows ?
Vous remplacez runs-on par craci. CRACI remplace le runner, pas GitHub Actions : vos workflows et leurs exécutions restent dans GitHub.
Quels écosystèmes de paquets CRACI enregistre-t-il ?
npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement Yocto et OpenEmbedded. Les miroirs npm et PyPI de JFrog Artifactory sont considérés comme des sources connues. La prise en charge de Maven et Java figure sur la roadmap.
Dans quels formats puis-je exporter une SBOM ?
CycloneDX et SPDX, y compris les dépendances transitives et la licence déclarée de chaque composant.
Que signifie l'état de complétude ?
Complete signifie que CRACI a observé des preuves complètes pour le job et que chaque cache restauré était complet. Complete with connections signifie que le job a également utilisé des connexions réseau personnalisées qui méritent d'être examinées. Incomplete signifie qu'une condition a pu laisser des dépendances de côté. Unavailable signifie que les preuves n'ont pas pu être évaluées, et Not recorded signifie que le job est antérieur au suivi de la complétude.
CRACI détecte-t-il des vulnérabilités dans la SBOM ?
Oui. CRACI réévalue en continu les SBOM surveillées à mesure que de nouvelles vulnérabilités sont publiées, agrège les résultats de l'ensemble des builds et des dépôts, et prend en charge VEX. Les équipes sécurité trient ce qu'il détecte et le transmettent aux équipes chargées de la correction.
CRACI peut-il générer une SBOM pour un logiciel que je n'ai pas construit ?
Non. CRACI enregistre les builds qui s'exécutent sur ses runners. Pour les logiciels que vous achetez, ajoutez la SBOM du fournisseur et CRACI la surveille aux côtés de vos propres builds. Pour une image tierce que vous n'avez pas construite, un scanner est le choix pratique ; voir Comparatif des outils SBOM.
Découvrez la SBOM de votre propre build
Réservez une démo, exécutez l'un de vos workflows GitHub Actions sur CRACI et voyez ce qu'il a réellement récupéré
Réserver une démo