Un Software Bill of Materials (SBOM) est un inventaire formel et lisible par machine de chaque composant, biblioth\u00e8que et d\u00e9pendance qui constitue un logiciel. Consid\u00e9rez-le comme l’\u00e9tiquette nutritionnelle de votre application \u2014 sauf qu’au lieu des calories et du sodium, vous r\u00e9pertoriez les paquets, versions, licences et donn\u00e9es de provenance.<\/p>\n
Les SBOMs sont pass\u00e9s du statut de \u00ab nice-to-have \u00bb \u00e0 celui d’exigence r\u00e9glementaire. Deux politiques majeures stimulent leur adoption dans tous les secteurs :<\/p>\n
Sign\u00e9 en mai 2021, l’EO 14028<\/strong> \u2014 \u00ab Improving the Nation’s Cybersecurity \u00bb \u2014 impose que tout logiciel vendu au gouvernement f\u00e9d\u00e9ral am\u00e9ricain inclue un SBOM. Ce d\u00e9cret a charg\u00e9 le NIST de d\u00e9finir les \u00e9l\u00e9ments minimaux d’un SBOM, ce qui a abouti \u00e0 des recommandations align\u00e9es sur les normes SBOM de la NTIA. Si votre organisation vend \u00e0 des agences gouvernementales, la g\u00e9n\u00e9ration de SBOMs n’est plus optionnelle \u2014 c’est un pr\u00e9requis d’approvisionnement.<\/p>\n Le EU Cyber Resilience Act<\/strong>, entr\u00e9 en vigueur en 2024, exige des fabricants et distributeurs de produits comportant des \u00e9l\u00e9ments num\u00e9riques qu’ils fournissent des SBOMs dans le cadre de leur \u00e9valuation de conformit\u00e9. Le CRA s’applique largement \u2014 des appareils IoT aux plateformes SaaS d’entreprise. Avec des \u00e9ch\u00e9ances d’application qui s’acc\u00e9l\u00e8rent en 2026 et 2027, les producteurs de logiciels destin\u00e9s au march\u00e9 europ\u00e9en doivent int\u00e9grer la g\u00e9n\u00e9ration de SBOMs dans leurs processus de build d\u00e8s maintenant.<\/p>\n Outre les moteurs r\u00e9glementaires, les SBOMs apportent des b\u00e9n\u00e9fices op\u00e9rationnels concrets :<\/p>\n La question n’est plus de savoir si<\/em> vous devez g\u00e9n\u00e9rer des SBOMs, mais quel outil<\/em> utiliser. Dans ce comparatif, nous \u00e9valuons trois g\u00e9n\u00e9rateurs SBOM open source de premier plan : Syft<\/strong>, Trivy<\/strong> et CycloneDX CLI<\/strong>.<\/p>\n Syft<\/a> est d\u00e9velopp\u00e9 par Anchore<\/strong> et est con\u00e7u pour faire une seule chose exceptionnellement bien : g\u00e9n\u00e9rer des SBOMs pr\u00e9cis et complets. C’est un outil SBOM d\u00e9di\u00e9, et non un scanner qui produit des SBOMs comme effet secondaire.<\/p>\n La focalisation unique de Syft sur la g\u00e9n\u00e9ration de SBOMs signifie qu’il poss\u00e8de la couverture de catalogueurs la plus approfondie de tous les outils de ce comparatif. Il d\u00e9tecte des composants que d’autres outils manquent \u2014 en particulier les paquets binaires compil\u00e9s dans les binaires Go et Rust, et les d\u00e9pendances imbriqu\u00e9es dans les uber-jars Java. Sa flexibilit\u00e9 de formats de sortie est in\u00e9gal\u00e9e, et il s’int\u00e8gre nativement avec le scanner de vuln\u00e9rabilit\u00e9s Grype d’Anchore.<\/p>\n Syft n’effectue pas lui-m\u00eame de scan de vuln\u00e9rabilit\u00e9s. Vous devez l’associer \u00e0 Grype<\/strong> ou un autre scanner. C’est sans doute un point fort (philosophie Unix : faire une seule chose bien), mais cela implique un outil suppl\u00e9mentaire dans votre pipeline.<\/p>\n Trivy<\/a> est d\u00e9velopp\u00e9 par Aqua Security<\/strong> et a d\u00e9but\u00e9 comme scanner de vuln\u00e9rabilit\u00e9s pour les conteneurs. Au fil du temps, il a \u00e9volu\u00e9 en un outil de s\u00e9curit\u00e9 complet qui g\u00e9n\u00e8re \u00e9galement des SBOMs. Sa capacit\u00e9 SBOM a \u00e9t\u00e9 ajout\u00e9e comme mode de scan aux c\u00f4t\u00e9s du scan de vuln\u00e9rabilit\u00e9s, de mauvaises configurations, de secrets et de licences.<\/p>\n Le plus grand avantage de Trivy est son architecture tout-en-un<\/strong>. Un seul binaire g\u00e8re la g\u00e9n\u00e9ration de SBOMs, le scan de vuln\u00e9rabilit\u00e9s, la d\u00e9tection de mauvaises configurations, le scan de secrets et l’analyse de licences. Cela r\u00e9duit consid\u00e9rablement la complexit\u00e9 de la cha\u00eene d’outils. C’est \u00e9galement le seul outil de ce comparatif capable de scanner directement des clusters Kubernetes et des comptes cloud. Sa base de donn\u00e9es de vuln\u00e9rabilit\u00e9s est mise \u00e0 jour fr\u00e9quemment et couvre de multiples sources (NVD, avis des \u00e9diteurs, GitHub Security Advisories).<\/p>\n Parce que la g\u00e9n\u00e9ration de SBOMs de Trivy est une fonctionnalit\u00e9 parmi d’autres, la profondeur de ses catalogueurs peut \u00eatre inf\u00e9rieure \u00e0 celle de Syft dans les cas limites \u2014 en particulier pour l’analyse binaire des binaires Go\/Rust compil\u00e9s et des artefacts Java profond\u00e9ment imbriqu\u00e9s. Le support SPDX a \u00e9t\u00e9 ajout\u00e9 plus tard que celui de CycloneDX, de sorte que la sortie CycloneDX tend \u00e0 \u00eatre plus compl\u00e8te dans certains sc\u00e9narios. La nature tout-en-un implique \u00e9galement un binaire plus volumineux et des t\u00e9l\u00e9chargements de base de donn\u00e9es initiaux plus longs.<\/p>\n CycloneDX CLI<\/a> fait partie du projet OWASP CycloneDX<\/strong>. Contrairement \u00e0 Syft et Trivy, ce n’est pas principalement un g\u00e9n\u00e9rateur<\/em> de SBOMs \u00e0 partir de code source ou d’images de conteneurs. C’est plut\u00f4t une bo\u00eete \u00e0 outils pour manipuler, convertir, valider, fusionner et comparer<\/strong> des SBOMs CycloneDX. L’\u00e9cosyst\u00e8me CycloneDX plus large inclut des plugins de g\u00e9n\u00e9ration de SBOMs sp\u00e9cifiques aux langages (par ex., L’approche de g\u00e9n\u00e9ration au moment du build<\/strong> de l’\u00e9cosyst\u00e8me CycloneDX produit les SBOMs les plus pr\u00e9cis car elle exploite la r\u00e9solution r\u00e9elle des d\u00e9pendances de l’outil de build \u2014 et non un scan post-hoc du syst\u00e8me de fichiers. La capacit\u00e9 de fusion du CLI est inestimable pour les monorepos et les architectures microservices o\u00f9 vous devez combiner des SBOMs par service en un SBOM au niveau du produit. La validation de sch\u00e9ma garantit que les SBOMs sont conformes aux sp\u00e9cifications avant distribution. Le support VEX est le plus mature dans cet \u00e9cosyst\u00e8me.<\/p>\n L’approche CycloneDX n\u00e9cessite une int\u00e9gration de plugin par langage<\/strong> dans votre syst\u00e8me de build. C’est plus de travail que d’ex\u00e9cuter un seul binaire sur une image de conteneur. Le CLI lui-m\u00eame ne scanne pas les conteneurs ou les syst\u00e8mes de fichiers \u00e0 la recherche de paquets \u2014 vous avez besoin des plugins de langages pour la g\u00e9n\u00e9ration. Le support SPDX est limit\u00e9 par rapport \u00e0 Syft et Trivy. L’outillage est plus fragment\u00e9 (CLI + multiples plugins) par rapport \u00e0 un seul binaire.<\/p>\n La pr\u00e9cision du SBOM est le diff\u00e9renciateur le plus important. Un SBOM incomplet est sans doute pire que l’absence de SBOM \u2014 il procure une fausse confiance.<\/p>\n Les plugins CycloneDX au moment du build<\/strong> l’emportent en pr\u00e9cision pour une raison claire : ils s’int\u00e8grent au r\u00e9solveur du gestionnaire de paquets pendant le build. Quand Syft<\/strong> arrive en deuxi\u00e8me position. Son architecture de catalogueurs est sp\u00e9cifiquement ajust\u00e9e pour analyser les fichiers de verrouillage, les manifestes et les m\u00e9tadonn\u00e9es binaires avec une haute fid\u00e9lit\u00e9. Syft excelle \u00e0 trouver des composants que d’autres outils manquent \u2014 en particulier les binaires Go (qui int\u00e8grent les informations de modules), les binaires Rust et les uber-jars Java avec des d\u00e9pendances embarqu\u00e9es.<\/p>\n Trivy<\/strong> est tr\u00e8s performant pour la plupart des cas d’utilisation mais peut manquer des cas limites dans l’analyse binaire. Sa force r\u00e9side dans l’\u00e9tendue \u2014 il couvre davantage de types de sources (Kubernetes, cloud) m\u00eame si la profondeur par source est l\u00e9g\u00e8rement inf\u00e9rieure \u00e0 celle de Syft dans certains sc\u00e9narios.<\/p>\n Les trois outils s’int\u00e8grent dans les pipelines CI\/CD, mais les sch\u00e9mas d’int\u00e9gration diff\u00e8rent significativement :<\/p>\n Syft fournit une GitHub Action<\/strong> officielle ( Trivy offre la surface d’int\u00e9gration CI\/CD la plus large : une GitHub Action<\/strong> ( L’int\u00e9gration CycloneDX n\u00e9cessite d’ajouter le plugin de langage appropri\u00e9<\/strong> \u00e0 votre configuration de build. Pour Maven, vous ajoutez le plugin \u00e0 votre POM. Pour npm, vous ajoutez un script appelant En pratique, de nombreuses organisations matures combinent ces outils. Voici un sch\u00e9ma de pipeline qui exploite les forces de chacun :<\/p>\n Ce pipeline atteint le meilleur de tous les mondes : les plugins CycloneDX fournissent la pr\u00e9cision au moment du build, Syft ajoute la d\u00e9couverte de paquets au niveau du conteneur, le CLI CycloneDX fusionne et valide le SBOM combin\u00e9, Trivy scanne les vuln\u00e9rabilit\u00e9s comme porte de qualit\u00e9, et cosign fournit l’attestation cryptographique.<\/p>\n La vitesse compte dans les pipelines CI\/CD o\u00f9 chaque minute de temps de build a un co\u00fbt :<\/p>\n Un SBOM non sign\u00e9 est un document \u00ab faites-moi confiance \u00bb. Pour que les SBOMs aient une r\u00e9elle valeur dans la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement, ils doivent \u00eatre sign\u00e9s cryptographiquement et associ\u00e9s \u00e0 l’artefact qu’ils d\u00e9crivent.<\/p>\n Syft + cosign<\/strong> est le workflow d’attestation le plus mature. Anchore a investi massivement dans le support des attestations SLSA et in-toto, et la sortie de Syft est con\u00e7ue pour alimenter directement Trivy<\/strong> prend en charge l’attestation bas\u00e9e sur cosign et peut v\u00e9rifier les attestations existantes. La sortie CycloneDX<\/strong> prend en charge BOM-Link, qui fournit un m\u00e9canisme de liaison bas\u00e9 sur les URI entre les SBOMs et les artefacts qu’ils d\u00e9crivent. Combin\u00e9 avec Sigstore ou in-toto, cela cr\u00e9e une cha\u00eene v\u00e9rifiable de la source au d\u00e9ploiement.<\/p>\n Il n’existe pas de \u00ab meilleur \u00bb outil SBOM unique \u2014 le bon choix d\u00e9pend de vos besoins sp\u00e9cifiques. Pour la profondeur pure de g\u00e9n\u00e9ration de SBOMs, Syft<\/strong> est la r\u00e9f\u00e9rence. Pour la simplicit\u00e9 tout-en-un, Trivy<\/strong> r\u00e9duit consid\u00e9rablement la complexit\u00e9 de la cha\u00eene d’outils. Pour la pr\u00e9cision au moment du build et la gestion du cycle de vie des SBOMs, l’\u00e9cosyst\u00e8me CycloneDX<\/strong> est in\u00e9gal\u00e9.<\/p>\n L’approche la plus solide consiste \u00e0 les combiner : utilisez les plugins CycloneDX au moment du build pour une pr\u00e9cision maximale, Syft pour la d\u00e9couverte au niveau du conteneur, le CLI CycloneDX pour la fusion et la validation, et Trivy pour le scan de vuln\u00e9rabilit\u00e9s. Ajoutez l’attestation cosign par-dessus, et vous disposez d’un pipeline SBOM de qualit\u00e9 production qui satisfait l’EO 14028, l’EU CRA et vos propres besoins de s\u00e9curit\u00e9 op\u00e9rationnelle.<\/p>\n Pr\u00eat \u00e0 construire ce pipeline concr\u00e8tement ? Consultez notre Laboratoire SBOM<\/a> pour un guide pas \u00e0 pas avec de vraies images de conteneurs et des templates CI\/CD.<\/p>\n","protected":false},"excerpt":{"rendered":" Pourquoi les SBOMs sont importants : l’imp\u00e9ratif r\u00e9glementaire et s\u00e9curitaire Un Software Bill of Materials (SBOM) est un inventaire formel et lisible par machine de chaque composant, biblioth\u00e8que et d\u00e9pendance qui constitue un logiciel. Consid\u00e9rez-le comme l’\u00e9tiquette nutritionnelle de votre application \u2014 sauf qu’au lieu des calories et du sodium, vous r\u00e9pertoriez les paquets, versions, … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,50],"tags":[],"post_folder":[],"class_list":["post-519","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-software-supply-chain"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/519","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=519"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/519\/revisions"}],"predecessor-version":[{"id":863,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/519\/revisions\/863"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=519"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=519"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=519"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=519"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}EU Cyber Resilience Act (CRA)<\/h3>\n
Au-del\u00e0 de la conformit\u00e9 : la valeur op\u00e9rationnelle<\/h3>\n
\n
Syft : le g\u00e9n\u00e9rateur SBOM d\u00e9di\u00e9 d’Anchore<\/h2>\n
Capacit\u00e9s cl\u00e9s<\/h3>\n
\n
cosign<\/code> et in-toto<\/code>. Vous pouvez diriger la sortie SBOM de Syft directement dans cosign attest<\/code> pour produire des attestations SBOM sign\u00e9es.<\/li>\n<\/ul>\nPoints forts<\/h3>\n
Limitations<\/h3>\n
Exemple d’utilisation<\/h3>\n
# G\u00e9n\u00e9rer un SBOM CycloneDX \u00e0 partir d'une image de conteneur\nsyft packages registry.example.com\/myapp:latest -o cyclonedx-json > sbom.cdx.json\n\n# G\u00e9n\u00e9rer un SBOM SPDX \u00e0 partir d'un r\u00e9pertoire local\nsyft dir:\/path\/to\/source -o spdx-json > sbom.spdx.json\n\n# Attester le SBOM avec cosign\ncosign attest --predicate sbom.cdx.json --type cyclonedx my-image:latest<\/code><\/pre>\nTrivy : le scanner tout-en-un d’Aqua Security avec mode SBOM<\/h2>\n
Capacit\u00e9s cl\u00e9s<\/h3>\n
\n
trivy image --format cosign-vuln<\/code>, et s’int\u00e8gre avec cosign pour les workflows d’attestation SBOM.<\/li>\n<\/ul>\nPoints forts<\/h3>\n
Limitations<\/h3>\n
Exemple d’utilisation<\/h3>\n
# G\u00e9n\u00e9rer un SBOM CycloneDX \u00e0 partir d'une image de conteneur\ntrivy image --format cyclonedx --output sbom.cdx.json registry.example.com\/myapp:latest\n\n# G\u00e9n\u00e9rer un SBOM SPDX \u00e0 partir d'un syst\u00e8me de fichiers\ntrivy fs --format spdx-json --output sbom.spdx.json \/path\/to\/source\n\n# Scanner un SBOM existant pour les vuln\u00e9rabilit\u00e9s\ntrivy sbom sbom.cdx.json\n\n# Combin\u00e9 : g\u00e9n\u00e9rer un SBOM + scanner en une passe\ntrivy image --format json --list-all-pkgs registry.example.com\/myapp:latest<\/code><\/pre>\nCycloneDX CLI : la bo\u00eete \u00e0 outils SBOM native d’OWASP<\/h2>\n
cyclonedx-maven-plugin<\/code>, cyclonedx-npm<\/code>, cyclonedx-gomod<\/code>) qui produisent des SBOMs pendant le processus de build lui-m\u00eame.<\/p>\nCapacit\u00e9s cl\u00e9s<\/h3>\n
\n
Points forts<\/h3>\n
Limitations<\/h3>\n
Exemple d’utilisation<\/h3>\n
# G\u00e9n\u00e9rer un SBOM pendant le build Maven\nmvn org.cyclonedx:cyclonedx-maven-plugin:makeBom\n\n# G\u00e9n\u00e9rer un SBOM \u00e0 partir d'un projet npm\nnpx @cyclonedx\/cyclonedx-npm --output-file sbom.cdx.json\n\n# Fusionner plusieurs SBOMs\ncyclonedx merge --input-files sbom-api.cdx.json sbom-frontend.cdx.json --output-file product-sbom.cdx.json\n\n# Valider un SBOM par rapport au sch\u00e9ma\ncyclonedx validate --input-file sbom.cdx.json --fail-on-errors\n\n# Comparer deux SBOMs pour voir ce qui a chang\u00e9 entre les versions\ncyclonedx diff --from v1-sbom.cdx.json --to v2-sbom.cdx.json<\/code><\/pre>\nTableau comparatif d\u00e9taill\u00e9<\/h2>\n
\n\n
\n \nFonctionnalit\u00e9<\/th>\n Syft<\/th>\n Trivy<\/th>\n CycloneDX CLI + Plugins<\/th>\n<\/tr>\n<\/thead>\n \n Objectif principal<\/strong><\/td>\n G\u00e9n\u00e9ration de SBOMs<\/td>\n Scanner de s\u00e9curit\u00e9 tout-en-un<\/td>\n Manipulation de SBOMs + g\u00e9n\u00e9ration au moment du build<\/td>\n<\/tr>\n \n Sortie SPDX<\/strong><\/td>\n JSON, tag-value (excellent)<\/td>\n JSON (bon)<\/td>\n Conversion limit\u00e9e uniquement<\/td>\n<\/tr>\n \n Sortie CycloneDX<\/strong><\/td>\n JSON, XML (excellent)<\/td>\n JSON (excellent)<\/td>\n JSON, XML, Protobuf (natif, meilleur)<\/td>\n<\/tr>\n \n Scan de conteneurs<\/strong><\/td>\n Oui (registre, daemon, tarball)<\/td>\n Oui (registre, daemon, tarball)<\/td>\n Non (build uniquement)<\/td>\n<\/tr>\n \n Scan du syst\u00e8me de fichiers<\/strong><\/td>\n Oui<\/td>\n Oui<\/td>\n Via plugins de langages<\/td>\n<\/tr>\n \n Analyse binaire<\/strong><\/td>\n Forte (binaires Go, Rust)<\/td>\n Mod\u00e9r\u00e9e<\/td>\n Aucune<\/td>\n<\/tr>\n \n Scan de vuln\u00e9rabilit\u00e9s<\/strong><\/td>\n Non (utiliser Grype)<\/td>\n Oui (int\u00e9gr\u00e9)<\/td>\n Non (utiliser un outil s\u00e9par\u00e9)<\/td>\n<\/tr>\n \n Pr\u00e9cision (profondeur des d\u00e9pendances)<\/strong><\/td>\n Excellente<\/td>\n Tr\u00e8s bonne<\/td>\n Meilleure (r\u00e9solution au moment du build)<\/td>\n<\/tr>\n \n Fusion\/comparaison de SBOMs<\/strong><\/td>\n Non<\/td>\n Non<\/td>\n Oui (natif)<\/td>\n<\/tr>\n \n Support VEX<\/strong><\/td>\n Via Grype\/Vunnel<\/td>\n Support OpenVEX<\/td>\n VEX CycloneDX natif<\/td>\n<\/tr>\n \n Signature d’attestation<\/strong><\/td>\n Via int\u00e9gration cosign<\/td>\n Via int\u00e9gration cosign<\/td>\n Attestation BOM-Link<\/td>\n<\/tr>\n \n Int\u00e9gration CI\/CD<\/strong><\/td>\n GitHub Action, CLI<\/td>\n GitHub Action, CLI, op\u00e9rateur Kubernetes<\/td>\n Plugin de build par langage<\/td>\n<\/tr>\n \n Vitesse (conteneur typique)<\/strong><\/td>\n Rapide (15\u201330s)<\/td>\n Mod\u00e9r\u00e9e (20\u201360s avec t\u00e9l\u00e9chargement de la BDD)<\/td>\n La plus rapide (int\u00e9gr\u00e9 au build, pas de scan s\u00e9par\u00e9)<\/td>\n<\/tr>\n \n Scan de cluster Kubernetes<\/strong><\/td>\n Non<\/td>\n Oui<\/td>\n Non<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Pr\u00e9cision et compl\u00e9tude : l\u00e0 o\u00f9 cela compte vraiment<\/h2>\n
cyclonedx-maven-plugin<\/code> s’ex\u00e9cute, il voit exactement le m\u00eame arbre de d\u00e9pendances que celui r\u00e9solu par Maven. Pas de devinettes, pas de correspondance heuristique \u2014 il lit directement le graphe r\u00e9solu.<\/p>\nInt\u00e9gration CI\/CD : int\u00e9grer les SBOMs dans votre pipeline<\/h2>\n
Syft en CI\/CD<\/h3>\n
anchore\/sbom-action<\/code>) qui g\u00e9n\u00e8re des SBOMs et les t\u00e9l\u00e9charge optionnellement comme snapshots de d\u00e9pendances GitHub. Pour GitLab, Jenkins ou d’autres syst\u00e8mes CI, le binaire CLI est simple \u00e0 installer et \u00e0 invoquer. Associez-le \u00e0 anchore\/scan-action<\/code> (Grype) pour les contr\u00f4les de vuln\u00e9rabilit\u00e9s.<\/p>\nTrivy en CI\/CD<\/h3>\n
aquasecurity\/trivy-action<\/code>), un op\u00e9rateur Kubernetes (Trivy Operator<\/strong>), et une sortie SARIF pour l’int\u00e9gration avec GitHub Code Scanning. Une seule \u00e9tape Trivy peut produire un SBOM, scanner les vuln\u00e9rabilit\u00e9s, v\u00e9rifier les mauvaises configurations et d\u00e9tecter les secrets \u2014 rempla\u00e7ant trois ou quatre outils distincts.<\/p>\nCycloneDX en CI\/CD<\/h3>\n
@cyclonedx\/cyclonedx-npm<\/code>. Cette approche native au build signifie que le SBOM est g\u00e9n\u00e9r\u00e9 comme artefact de build aux c\u00f4t\u00e9s de votre application, sans \u00e9tape de scan s\u00e9par\u00e9e n\u00e9cessaire.<\/p>\nQuand utiliser quel outil<\/h2>\n
Choisissez Syft quand :<\/h3>\n
\n
Choisissez Trivy quand :<\/h3>\n
\n
Choisissez CycloneDX CLI + Plugins quand :<\/h3>\n
\n
Pipeline combin\u00e9 : utiliser les trois ensemble<\/h2>\n
# \u00c9tape 1 : SBOM au moment du build (graphe de d\u00e9pendances le plus pr\u00e9cis)\n# Dans votre \u00e9tape de build Maven\/npm\/Go :\nmvn org.cyclonedx:cyclonedx-maven-plugin:makeBom\n# Sortie : target\/bom.json (format CycloneDX)\n\n# \u00c9tape 2 : SBOM au niveau du conteneur (capture les paquets OS + d\u00e9pendances runtime)\nsyft packages myapp:${BUILD_TAG} -o cyclonedx-json > container-sbom.cdx.json\n\n# \u00c9tape 3 : Fusionner les SBOMs du build et du conteneur\ncyclonedx merge \\\n --input-files target\/bom.json container-sbom.cdx.json \\\n --output-file merged-sbom.cdx.json\n\n# \u00c9tape 4 : Valider le SBOM fusionn\u00e9\ncyclonedx validate --input-file merged-sbom.cdx.json --fail-on-errors\n\n# \u00c9tape 5 : Scanner le SBOM fusionn\u00e9 pour les vuln\u00e9rabilit\u00e9s\ntrivy sbom merged-sbom.cdx.json --exit-code 1 --severity CRITICAL,HIGH\n\n# \u00c9tape 6 : Signer et attester\ncosign attest --predicate merged-sbom.cdx.json \\\n --type cyclonedx myapp:${BUILD_TAG}<\/code><\/pre>\nConsid\u00e9rations de performance<\/h2>\n
\n
--skip-db-update<\/code> en CI (avec un cache pr\u00e9-charg\u00e9) \u00e9limine cette surcharge.<\/li>\nAttestation et signature : prouver la provenance du SBOM<\/h2>\n
cosign attest<\/code>.<\/p>\ntrivy image --format cosign-vuln<\/code> produit des rapports de vuln\u00e9rabilit\u00e9s pr\u00eats pour l’attestation.<\/p>\nConclusion<\/h2>\n