Automatisation des SBOM : le build remplace les tableurs

Pourquoi les SBOM manuelles cessent de fonctionner

Elles sont périmées dès le build suivant. Les dépendances changent à chaque release, et un tableur ne change que lorsque quelqu'un pense à le mettre à jour.
Elles s'arrêtent à ce que l'on voit. Les dépendances directes sont faciles à lister. Les dépendances transitives qui se trouvent en dessous ne le sont pas, et personne ne peut les suivre à la main.
Elles se multiplient. Plusieurs produits, avec chacun plusieurs versions maintenues, cela fait des dizaines de fichiers, chacun avec son responsable et sa propre idée de la vérité.
Elles ne répondent pas à la question qui compte. Quand une nouvelle vulnérabilité apparaît, vous devez savoir quelles releases contiennent le paquet. Chercher dans un dossier de tableurs est lent, et vous ne pouvez pas vous fier à la réponse.
Ce n'est pas ce que les autres demandent. Les clients et les outils attendent un format lisible par machine, comme CycloneDX ou SPDX. Voir comment répondre à une demande de SBOM d'un client.

Ce que fait une bonne automatisation des SBOM

Elle produit une SBOM pour chaque build, sans que personne n'ait à lancer quoi que ce soit ni à y penser.
Elle couvre l'arbre complet, dépendances transitives comprises, à tous les niveaux.
Elle relie chaque SBOM à un seul build, pour que vous sachiez quel fichier décrit quelle release.
Elle dit ce qu'elle n'a pas pu voir, au lieu de présenter une liste partielle comme complète.
Elle exporte un format standard, pour que la SBOM fonctionne avec le prochain outil et le prochain client.
Elle continue de surveiller ce qui a été livré, car une release saine le lundi peut être touchée le mardi.

Trois façons de tenir ses SBOM, comparées

Question	Tableur	Scanner en CI	Enregistrée pendant le build
Quand est-elle mise à jour ?	Quand quelqu'un y pense	Quand l'étape de scan s'exécute	À chaque build
D'où viennent les données ?	Des personnes	Des lockfiles ou du résultat final	De ce que le build a réellement récupéré
Dépendances transitives ?	Rarement	Celles qu'il parvient à déduire	À tous les niveaux
Dépendances cachées, comme les téléchargements des scripts d'installation ?	Non	Manquées	Enregistrées
Paquets restaurés depuis un cache CI ?	Non	Selon l'outil	Enregistrés et marqués comme mis en cache
Surveillance des vulnérabilités ?	Manuelle	Généralement un outil distinct	Intégrée avec CRACI

Automatiser avec un scanner est un vrai progrès par rapport à un tableur, mais cela reste une estimation de ce qui est entré dans le build. Pour le raisonnement, voir pourquoi le build est la source de vérité.

Ce que deviennent vos tableurs

Les données de composants en sortent : les versions et les paquets viennent du build, et plus personne n'a à les saisir. Il reste ce que seule votre équipe sait, par exemple quels produits existent, qui en est responsable et quelles versions sont encore maintenues. C'est la partie qui mérite le temps d'une personne.

Comment CRACI s'en charge

CRACI remplace vos runners hébergés par GitHub par des runners plus rapides et moins chers, et enregistre la SBOM pendant l'exécution de chaque build. Vous indiquez runs-on: craci, et vos exécutions apparaissent toujours dans GitHub. Les builds standard obtiennent une SBOM complète sans configuration. Les builds qui ont leurs propres registres de paquets ou des configurations de conteneurs inhabituelles peuvent en nécessiter une.

Enregistrée, pas scannée. CRACI voit le trafic qui entre dans chaque build, y compris les dépendances cachées que les outils basés sur les lockfiles manquent. Chaque composant de la SBOM était dans le build.
Un état de complétude pour chaque job, pour que vous sachiez quand un build n'a pas pu être entièrement enregistré, et pourquoi.
Export en CycloneDX et SPDX, y compris les dépendances transitives et les vulnérabilités trouvées dans les composants.
Une vue unique sur tous les produits. La vue d'inventaire montre quelles versions logicielles sont déployées dans quels produits, et CRACI réévalue en continu les SBOM surveillées.

Pour le déployer dans des équipes aux pipelines différents, consultez la génération de SBOM entre équipes d'ingénierie.

Automatisation des SBOM : questions fréquentes

Qu'est-ce que l'automatisation des SBOM ?

Produire une nomenclature logicielle dans le cadre du build, pour que chaque release ait la sienne sans que personne ne la crée à la main. Les meilleures configurations surveillent aussi chaque SBOM pour détecter de nouvelles vulnérabilités une fois la release livrée.

Pouvons-nous garder nos SBOM dans Excel ?

Un tableur peut servir de premier inventaire, mais il est difficile à tenir à jour et n'atteint pas les dépendances transitives. Ce n'est pas non plus un format SBOM standard. Les clients et les outils de sécurité attendent généralement CycloneDX ou SPDX, et le Cyber Resilience Act demande un format couramment utilisé et lisible par machine.

L'automatisation des SBOM nécessite-t-elle une nouvelle étape dans chaque pipeline ?

Avec la plupart des générateurs, oui : vous ajoutez une étape à chaque workflow et vous la tenez à jour. CRACI enregistre la SBOM dans le runner : il n'y a donc aucune étape à ajouter à vos jobs.

Quels écosystèmes CRACI enregistre-t-il ?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, les paquets Debian et Ubuntu (apt), les paquets Alpine (apk) et les sources Git, ainsi que les téléchargements Yocto et OpenEmbedded. Maven et Java figurent sur la roadmap.

Quels systèmes CI et plateformes CRACI prend-il en charge ?

GitHub Actions aujourd'hui, les autres systèmes CI étant sur la roadmap. Les runners sont aujourd'hui en Linux x86-64 et ARM64, Windows et macOS étant sur la roadmap.

Et les composants que nous achetons à des fournisseurs ?

Vous pouvez ajouter des SBOM de fournisseurs à CRACI, pour que les composants achetés soient surveillés aux côtés de vos propres builds.

Combien cela coûte-t-il ?

CRACI ne facture que les minutes de build : $0.002 par vCPU-minute ($0.004 pour un runner par défaut de 2 vCPU), décompté à la seconde, sans frais mensuels ni frais par SBOM.