En d\u00e9cembre 2020, le monde a d\u00e9couvert que SolarWinds<\/strong> \u2014 une plateforme de gestion informatique largement reconnue \u2014 avait \u00e9t\u00e9 compromise. Des attaquants ont inject\u00e9 du code malveillant dans le processus de build du logiciel Orion, distribuant une mise \u00e0 jour corrompue \u00e0 environ 18 000 organisations, dont des agences gouvernementales am\u00e9ricaines et des entreprises du Fortune 500. L’attaque ne visait pas directement le d\u00e9p\u00f4t de code source de SolarWinds, mais son pipeline de build<\/em>. Cet incident unique a red\u00e9fini la mani\u00e8re dont l’industrie con\u00e7oit la s\u00e9curit\u00e9 logicielle.<\/p>\n Puis est arriv\u00e9 Log4Shell<\/strong> fin 2021. Une vuln\u00e9rabilit\u00e9 critique d’ex\u00e9cution de code \u00e0 distance dans Apache Log4j \u2014 une biblioth\u00e8que de journalisation Java omnipr\u00e9sente \u2014 a expos\u00e9 pratiquement toutes les entreprises de la plan\u00e8te. Les organisations se sont pr\u00e9cipit\u00e9es pour d\u00e9terminer si elles utilisaient<\/em> m\u00eame Log4j, r\u00e9v\u00e9lant un manque fondamental de visibilit\u00e9 sur les d\u00e9pendances logicielles. La le\u00e7on \u00e9tait claire : on ne peut pas s\u00e9curiser ce que l’on ne peut pas voir.<\/p>\n Plus r\u00e9cemment, la backdoor XZ Utils<\/strong> (CVE-2024-3094) d\u00e9but 2024 a d\u00e9montr\u00e9 un vecteur d’attaque encore plus insidieux. Une campagne patiente d’ing\u00e9nierie sociale \u00e0 long terme a permis \u00e0 un contributeur malveillant d’ins\u00e9rer une porte d\u00e9rob\u00e9e dans une biblioth\u00e8que de compression critique utilis\u00e9e dans presque toutes les distributions Linux. L’attaque ciblait sp\u00e9cifiquement le syst\u00e8me de build, ne s’activant que sous certaines conditions de compilation \u2014 une attaque de la supply chain d’une sophistication extraordinaire.<\/p>\n Ces incidents partagent un fil conducteur commun : les attaquants ne ciblent plus seulement votre code applicatif \u2014 ils ciblent l’ensemble de la cha\u00eene d’outils, de d\u00e9pendances, de processus et d’infrastructures qui livre le logiciel en production.<\/strong> C’est la cha\u00eene d’approvisionnement logicielle, et la s\u00e9curiser est devenu l’un des d\u00e9fis les plus critiques de l’ing\u00e9nierie moderne.<\/p>\n Ce guide complet couvre toutes les dimensions de la s\u00e9curit\u00e9 de la supply chain logicielle \u2014 de la gestion des d\u00e9pendances \u00e0 l’int\u00e9grit\u00e9 des builds, en passant par la signature des artefacts, la provenance, les SBOMs et les cadres de conformit\u00e9. Que vous soyez ing\u00e9nieur DevOps, architecte s\u00e9curit\u00e9 ou responsable technique, ce guide fournit une feuille de route pratique et de bout en bout pour renforcer votre cha\u00eene d’approvisionnement logicielle.<\/p>\n Avant de pouvoir s\u00e9curiser la supply chain, nous devons en comprendre les composants. Une cha\u00eene d’approvisionnement logicielle moderne se compose de cinq \u00e9tapes interconnect\u00e9es :<\/p>\n C’est l\u00e0 que les d\u00e9veloppeurs \u00e9crivent, r\u00e9visent et commitent le code. L’\u00e9tape du source inclut les syst\u00e8mes de contr\u00f4le de version (Git), les processus de revue de code, les r\u00e8gles de protection de branches et la signature des commits. Les menaces \u00e0 ce stade incluent les comptes d\u00e9veloppeurs compromis, les commits malveillants et les modifications non autoris\u00e9es des fichiers de configuration CI\/CD (empoisonnement de pipeline).<\/p>\n Les applications modernes d\u00e9pendent fortement de biblioth\u00e8ques et packages tiers. Une application Node.js typique peut importer des centaines, voire des milliers de d\u00e9pendances transitives. L’\u00e9tape des d\u00e9pendances englobe les registres de packages (npm, PyPI, Maven Central), les fichiers de verrouillage (lockfiles), la r\u00e9solution de versions et l’analyse de vuln\u00e9rabilit\u00e9s. C’est l’une des \u00e9tapes de la supply chain les plus fr\u00e9quemment exploit\u00e9es.<\/p>\n L’\u00e9tape de build transforme le code source et les d\u00e9pendances en artefacts d\u00e9ployables. Cela inclut la compilation, le bundling, la construction d’images de conteneurs et l’ex\u00e9cution des tests. Les syst\u00e8mes de build \u2014 qu’il s’agisse de Jenkins, GitHub Actions, GitLab CI ou d’autres \u2014 sont des cibles de haute valeur car compromettre un processus de build peut injecter du code malveillant dans chaque artefact produit.<\/p>\n Les sorties de build \u2014 images de conteneurs, binaires, packages \u2014 sont stock\u00e9es dans des registres d’artefacts (Docker Hub, Amazon ECR, Artifactory, etc.). L’\u00e9tape des artefacts implique la signature, la v\u00e9rification, l’attachement de m\u00e9tadonn\u00e9es et le contr\u00f4le d’acc\u00e8s. Sans contr\u00f4les d’int\u00e9grit\u00e9 appropri\u00e9s, les artefacts peuvent \u00eatre alt\u00e9r\u00e9s apr\u00e8s le build.<\/p>\n La derni\u00e8re \u00e9tape livre les artefacts aux environnements de production. Le d\u00e9ploiement implique les plateformes d’orchestration (Kubernetes), les contr\u00f4leurs d’admission, l’application des politiques et la v\u00e9rification en temps r\u00e9el. C’est la derni\u00e8re ligne de d\u00e9fense \u2014 le point o\u00f9 vous v\u00e9rifiez que ce que vous d\u00e9ployez est exactement ce qui a \u00e9t\u00e9 construit.<\/p>\n Chaque \u00e9tape pr\u00e9sente des surfaces d’attaque uniques et n\u00e9cessite des mesures d\u00e9fensives sp\u00e9cifiques. Le reste de ce guide d\u00e9taille chacune d’entre elles.<\/p>\n Les d\u00e9pendances sont sans doute le composant le plus vuln\u00e9rable de la cha\u00eene d’approvisionnement logicielle. Les \u00e9tudes montrent syst\u00e9matiquement que plus de 80 % du code des applications modernes provient de d\u00e9pendances open source. Cela cr\u00e9e une surface d’attaque \u00e9norme, difficile \u00e0 surveiller et \u00e0 contr\u00f4ler.<\/p>\n La confusion de d\u00e9pendances<\/strong> (aussi appel\u00e9e confusion d’espace de noms) exploite la mani\u00e8re dont les gestionnaires de packages r\u00e9solvent les d\u00e9pendances. Lorsqu’une organisation utilise des packages internes dont les noms n’existent pas sur les registres publics, un attaquant peut publier un package malveillant portant le m\u00eame nom sur le registre public. Si le gestionnaire de packages est mal configur\u00e9, il peut r\u00e9cup\u00e9rer le package de l’attaquant au lieu du package interne. Ce vecteur d’attaque a \u00e9t\u00e9 rendu c\u00e9l\u00e8bre par le chercheur en s\u00e9curit\u00e9 Alex Birsan en 2021, affectant Apple, Microsoft et d’autres grandes entreprises.<\/p>\n Le typosquatting<\/strong> cible les d\u00e9veloppeurs qui commettent des erreurs typographiques en sp\u00e9cifiant les noms de packages. Les attaquants publient des packages malveillants dont les noms ressemblent \u00e9troitement \u00e0 des biblioth\u00e8ques populaires \u2014 par exemple, Les comptes mainteneurs compromis<\/strong> permettent aux attaquants de publier des mises \u00e0 jour malveillantes sur des packages l\u00e9gitimes et largement utilis\u00e9s. L’incident Pour une analyse approfondie de ces vecteurs d’attaque et des d\u00e9fenses pratiques, consultez notre guide d\u00e9taill\u00e9 : Confusion de d\u00e9pendances et empoisonnement d’artefacts : attaques et d\u00e9fenses<\/a>.<\/p>\n Fichiers de verrouillage et \u00e9pinglage de versions :<\/strong> Commitez toujours les lockfiles ( Configuration du registre priv\u00e9 :<\/strong> Configurez les gestionnaires de packages pour r\u00e9soudre les packages internes exclusivement depuis votre registre priv\u00e9. Utilisez des packages scop\u00e9s (par ex., Analyse de vuln\u00e9rabilit\u00e9s :<\/strong> Int\u00e9grez des outils d’analyse de composition logicielle (SCA) dans votre pipeline CI\/CD. Des outils comme Revue des d\u00e9pendances et liste d’autorisation :<\/strong> \u00c9tablissez un processus de revue pour les nouvelles d\u00e9pendances. \u00c9valuez les packages en fonction de l’activit\u00e9 de maintenance, du nombre de contributeurs, des statistiques de t\u00e9l\u00e9chargement et des vuln\u00e9rabilit\u00e9s connues. Certaines organisations maintiennent une liste de packages approuv\u00e9s et exigent une revue de s\u00e9curit\u00e9 avant d’en ajouter de nouveaux.<\/p>\n L’\u00e9tape de build est celle o\u00f9 le code source et les d\u00e9pendances sont transform\u00e9s en artefacts d\u00e9ployables. Si un attaquant peut compromettre le processus de build, il peut injecter du code malveillant dans la sortie sans modifier le code source \u2014 exactement comme cela s’est produit lors de l’attaque SolarWinds. L’int\u00e9grit\u00e9 du build garantit que le processus de build lui-m\u00eame est digne de confiance.<\/p>\n Un build reproductible<\/strong> est un build qui produit une sortie identique \u00e0 partir du m\u00eame code source, des m\u00eames d\u00e9pendances, du m\u00eame environnement de build et des m\u00eames instructions de build. La reproductibilit\u00e9 est une propri\u00e9t\u00e9 de s\u00e9curit\u00e9 puissante car elle permet une v\u00e9rification ind\u00e9pendante : n’importe qui peut reconstruire \u00e0 partir des m\u00eames entr\u00e9es et confirmer que la sortie correspond. Si la sortie diff\u00e8re, cela indique une alt\u00e9ration.<\/p>\n Obtenir des builds reproductibles n\u00e9cessite d’\u00e9liminer les sources de non-d\u00e9terminisme :<\/p>\n Un build herm\u00e9tique<\/strong> est isol\u00e9 de l’environnement h\u00f4te et du r\u00e9seau. Il ne peut acc\u00e9der qu’aux entr\u00e9es explicitement d\u00e9clar\u00e9es \u2014 pas d’appels r\u00e9seau, pas d’acc\u00e8s aux chemins du syst\u00e8me de fichiers h\u00f4te en dehors du bac \u00e0 sable de build, pas de d\u00e9pendance \u00e0 des outils pr\u00e9install\u00e9s. Les builds herm\u00e9tiques garantissent que la sortie du build ne d\u00e9pend que des entr\u00e9es d\u00e9clar\u00e9es, rendant impossible pour un attaquant d’injecter des d\u00e9pendances ou des outils suppl\u00e9mentaires pendant le processus de build.<\/p>\n Les syst\u00e8mes de build comme Bazel<\/strong>, Buck2<\/strong> et Pants<\/strong> sont con\u00e7us pour les builds herm\u00e9tiques d\u00e8s leur conception. Pour les builds de conteneurs, des outils comme BuildKit<\/strong> avec isolation r\u00e9seau et ko<\/strong> pour les applications Go offrent des capacit\u00e9s de build herm\u00e9tique.<\/p>\n Pour un guide complet sur l’impl\u00e9mentation de builds reproductibles et herm\u00e9tiques dans votre pipeline CI\/CD, consultez : Int\u00e9grit\u00e9 du build : builds reproductibles en CI\/CD<\/a>.<\/p>\n Au-del\u00e0 du processus de build lui-m\u00eame, la plateforme de build n\u00e9cessite un renforcement :<\/p>\n Une fois qu’un build produit un artefact \u2014 une image de conteneur, un binaire, un package \u2014 comment s’assurer qu’il n’a pas \u00e9t\u00e9 alt\u00e9r\u00e9 avant le d\u00e9ploiement ? La signature d’artefacts<\/strong> fournit une preuve cryptographique qu’un artefact a \u00e9t\u00e9 produit par un processus de build de confiance et n’a pas \u00e9t\u00e9 modifi\u00e9 depuis.<\/p>\n La signature de code traditionnelle repose sur des cl\u00e9s cryptographiques \u00e0 longue dur\u00e9e de vie. Cela cr\u00e9e des d\u00e9fis op\u00e9rationnels significatifs : g\u00e9n\u00e9ration de cl\u00e9s, stockage s\u00e9curis\u00e9, rotation, r\u00e9vocation et distribution. Si une cl\u00e9 de signature est compromise, chaque artefact sign\u00e9 avec cette cl\u00e9 est suspect. La gestion des cl\u00e9s a historiquement \u00e9t\u00e9 si contraignante que de nombreuses \u00e9quipes renoncent tout simplement \u00e0 la signature.<\/p>\n Sigstore<\/strong> est un projet open source qui simplifie fondamentalement la signature d’artefacts en \u00e9liminant le besoin de cl\u00e9s \u00e0 longue dur\u00e9e de vie. Sigstore se compose de plusieurs composants :<\/p>\n Dans un pipeline CI\/CD, la signature keyless avec Sigstore fonctionne comme suit :<\/p>\n Au moment du d\u00e9ploiement, vous v\u00e9rifiez la signature en consultant le journal de transparence Rekor et en validant que l’identit\u00e9 du signataire correspond \u00e0 votre workflow CI\/CD attendu.<\/p>\n Pour un tutoriel pratique sur l’impl\u00e9mentation de Sigstore et Cosign dans votre pipeline, consultez : Signer et v\u00e9rifier les images de conteneurs avec Sigstore et Cosign<\/a>.<\/p>\n La signature vous dit qui<\/em> a produit un artefact, mais ne vous dit pas comment<\/em> il a \u00e9t\u00e9 produit. La provenance<\/strong> r\u00e9pond aux questions critiques : quel code source a \u00e9t\u00e9 utilis\u00e9 ? Quel processus de build a \u00e9t\u00e9 ex\u00e9cut\u00e9 ? Quelles d\u00e9pendances ont \u00e9t\u00e9 incluses ? Quel builder a \u00e9t\u00e9 utilis\u00e9 ? La provenance fournit un enregistrement v\u00e9rifiable de l’origine et du processus de build de l’artefact.<\/p>\n SLSA<\/strong> (Supply-chain Levels for Software Artifacts, prononc\u00e9 \u00ab salsa \u00bb) est un framework d\u00e9velopp\u00e9 par Google et l’OpenSSF qui d\u00e9finit des niveaux croissants de s\u00e9curit\u00e9 de la supply chain. \u00c0 son c\u0153ur, SLSA sp\u00e9cifie un format de provenance standard qui capture :<\/p>\n La provenance SLSA est g\u00e9n\u00e9r\u00e9e par la plateforme de build (et non par le script de build), ce qui est crucial \u2014 cela signifie qu’un script de build compromis ne peut pas falsifier sa propre provenance. Des plateformes comme GitHub Actions et Google Cloud Build disposent de g\u00e9n\u00e9rateurs de provenance SLSA natifs.<\/p>\n in-toto<\/strong> est un framework pour s\u00e9curiser l’int\u00e9grit\u00e9 de l’ensemble de la cha\u00eene d’approvisionnement logicielle. Alors que SLSA se concentre principalement sur la provenance du build, in-toto fournit un cadre d’attestation plus g\u00e9n\u00e9ral qui peut capturer n’importe quelle \u00e9tape de la supply chain \u2014 revue de code, tests, analyse, approbation et d\u00e9ploiement.<\/p>\n Une attestation in-toto suit le format DSSE (Dead Simple Signing Envelope)<\/strong> et se compose de :<\/p>\n Plusieurs attestations peuvent \u00eatre attach\u00e9es \u00e0 un seul artefact, cr\u00e9ant un ensemble riche de m\u00e9tadonn\u00e9es que les moteurs de politiques peuvent \u00e9valuer au moment du d\u00e9ploiement.<\/p>\n Pour un guide d\u00e9taill\u00e9 sur la g\u00e9n\u00e9ration et la v\u00e9rification de la provenance et des attestations, consultez : Provenance des artefacts et attestations : SLSA et in-toto<\/a>.<\/p>\n Un SBOM<\/strong> (Software Bill of Materials) est un inventaire exhaustif de tous les composants, biblioth\u00e8ques et d\u00e9pendances d’un artefact logiciel. Consid\u00e9rez-le comme une \u00e9tiquette nutritionnelle pour le logiciel \u2014 il indique aux consommateurs exactement ce qu’il contient. Les SBOMs sont devenus une exigence r\u00e9glementaire dans de nombreux contextes et sont essentiels pour la gestion des vuln\u00e9rabilit\u00e9s et la r\u00e9ponse aux incidents.<\/p>\n Lorsque Log4Shell a frapp\u00e9 en d\u00e9cembre 2021, les organisations capables de d\u00e9terminer rapidement si elles utilisaient Log4j \u2014 et o\u00f9 \u2014 ont pu r\u00e9agir en quelques heures. Les organisations sans cette visibilit\u00e9 ont mis des semaines ou des mois. Les SBOMs fournissent cette visibilit\u00e9 de mani\u00e8re proactive, avant qu’un incident ne survienne.<\/p>\n Les SBOMs servent plusieurs objectifs :<\/p>\n Deux formats principaux de SBOM dominent le secteur :<\/p>\n Les SBOMs doivent \u00eatre g\u00e9n\u00e9r\u00e9s dans le cadre du pipeline CI\/CD, aussi pr\u00e8s que possible de l’\u00e9tape de build. Les outils courants pour la g\u00e9n\u00e9ration de SBOMs incluent :<\/p>\n G\u00e9n\u00e9rer un SBOM n’est que la premi\u00e8re \u00e9tape. Pour rendre les SBOMs dignes de confiance, ils doivent \u00eatre sign\u00e9s et attach\u00e9s aux artefacts en tant qu’attestations. En utilisant Cosign, vous pouvez attester un SBOM \u00e0 une image de conteneur :<\/p>\n Cela cr\u00e9e une attestation sign\u00e9e qui lie le SBOM \u00e0 un digest d’artefact sp\u00e9cifique, garantissant que le SBOM ne peut pas \u00eatre s\u00e9par\u00e9 de l’artefact qu’il d\u00e9crit ni falsifi\u00e9. Les consommateurs peuvent alors v\u00e9rifier \u00e0 la fois la signature de l’artefact et l’attestation du SBOM avant le d\u00e9ploiement.<\/p>\n Pour un atelier pratique sur la g\u00e9n\u00e9ration, l’analyse et l’attestation de SBOMs, consultez notre atelier SBOM dans la s\u00e9rie S\u00e9curit\u00e9 CI\/CD<\/a>.<\/p>\n Plusieurs cadres et standards proposent des approches structur\u00e9es de la s\u00e9curit\u00e9 de la supply chain. Comprendre ces cadres aide les organisations \u00e0 prioriser les investissements et \u00e0 d\u00e9montrer leur conformit\u00e9.<\/p>\n SLSA d\u00e9finit quatre niveaux de maturit\u00e9 croissante en mati\u00e8re de s\u00e9curit\u00e9 de la supply chain :<\/p>\n Pour une checklist de conformit\u00e9 pratique et des conseils d’impl\u00e9mentation pour chaque niveau SLSA, consultez : Les niveaux SLSA expliqu\u00e9s : checklist de conformit\u00e9 pratique<\/a>.<\/p>\n Le SSDF<\/strong> (SP 800-218) fournit un ensemble de pratiques de haut niveau, ind\u00e9pendantes des technologies, pour le d\u00e9veloppement logiciel s\u00e9curis\u00e9. Il est organis\u00e9 en quatre groupes :<\/p>\n Le SSDF est particuli\u00e8rement pertinent pour les organisations qui fournissent des logiciels au gouvernement f\u00e9d\u00e9ral am\u00e9ricain, car il est r\u00e9f\u00e9renc\u00e9 par l’Executive Order 14028 et les m\u00e9morandums OMB associ\u00e9s.<\/p>\n Le OWASP SCVS<\/strong> fournit un cadre sp\u00e9cifiquement ax\u00e9 sur l’analyse des composants logiciels et la gestion des risques de la supply chain. Il d\u00e9finit des exigences de v\u00e9rification dans six cat\u00e9gories : BOM, identit\u00e9 logicielle, provenance, int\u00e9grit\u00e9 des packages, analyse des composants et lign\u00e9e. Le SCVS est utile comme checklist d\u00e9taill\u00e9e pour \u00e9valuer les pratiques de s\u00e9curit\u00e9 de la supply chain de votre organisation.<\/p>\n Le projet OpenSSF Scorecard<\/strong> \u00e9value automatiquement les projets open source selon un ensemble d’heuristiques de s\u00e9curit\u00e9 \u2014 protection de branches, \u00e9pinglage des d\u00e9pendances, releases sign\u00e9es, tests CI, et plus encore. Ex\u00e9cuter Scorecard sur vos d\u00e9pendances vous aide \u00e0 \u00e9valuer leur posture de s\u00e9curit\u00e9 et \u00e0 identifier les risques. Int\u00e9grer Scorecard dans votre processus de revue des d\u00e9pendances ajoute une couche de d\u00e9fense suppl\u00e9mentaire.<\/p>\n S\u00e9curiser une cha\u00eene d’approvisionnement logicielle est un parcours, pas un projet unique. La feuille de route phas\u00e9e suivante fournit un chemin pratique, de l’hygi\u00e8ne fondamentale aux postures de s\u00e9curit\u00e9 avanc\u00e9es.<\/p>\n Se concentrer sur la visibilit\u00e9 et les contr\u00f4les de base :<\/p>\n Ajouter des contr\u00f4les d’int\u00e9grit\u00e9 cryptographiques :<\/p>\n Appliquer les politiques au moment du d\u00e9ploiement :<\/p>\n Poursuivre la d\u00e9fense en profondeur et l’am\u00e9lioration continue :<\/p>\n La th\u00e9orie est importante, mais la pratique est essentielle. Les ateliers suivants fournissent une exp\u00e9rience pratique avec les outils et techniques abord\u00e9s dans ce guide :<\/p>\n Choisir les bons outils est essentiel pour une s\u00e9curit\u00e9 de la supply chain efficace. Les guides comparatifs suivants vous aident \u00e0 \u00e9valuer les options dans les cat\u00e9gories cl\u00e9s :<\/p>\n Pour des comparaisons d\u00e9taill\u00e9es de ces outils, incluant des matrices de fonctionnalit\u00e9s et des recommandations, consultez notre Comprendre le mod\u00e8le de la cha\u00eene d’approvisionnement logicielle<\/h2>\n
1. Code source<\/h3>\n
2. D\u00e9pendances<\/h3>\n
3. Build<\/h3>\n
4. Artefacts<\/h3>\n
5. D\u00e9ploiement<\/h3>\n
Risques et d\u00e9fenses li\u00e9s aux d\u00e9pendances<\/h2>\n
Attaques courantes sur les d\u00e9pendances<\/h3>\n
reqeusts<\/code> au lieu de requests<\/code>, ou lodash-utils<\/code> imitant lodash<\/code>. Ces packages contiennent souvent du code d’exfiltration de donn\u00e9es ou de minage de cryptomonnaies.<\/p>\nevent-stream<\/code> en 2018 et la compromission de ua-parser-js<\/code> en 2021 en sont des exemples notables. Parce que les packages sont l\u00e9gitimes et de confiance, le code malveillant se propage rapidement.<\/p>\nStrat\u00e9gies d\u00e9fensives<\/h3>\n
package-lock.json<\/code>, Pipfile.lock<\/code>, go.sum<\/code>, Cargo.lock<\/code>) dans le contr\u00f4le de version. Les lockfiles enregistrent les versions exactes et les hachages d’int\u00e9grit\u00e9 de chaque d\u00e9pendance, garantissant des installations reproductibles. \u00c9pinglez les d\u00e9pendances \u00e0 des versions exactes plut\u00f4t que d’utiliser des plages de versions pour \u00e9viter les mises \u00e0 jour inattendues.<\/p>\n@votreentreprise\/nom-du-package<\/code>) et configurez les mappages de registres pour pr\u00e9venir les attaques par confusion de d\u00e9pendances. Des outils comme Artifactory et Nexus peuvent servir de proxy pour les registres publics tout en fournissant une couche suppl\u00e9mentaire d’analyse et de contr\u00f4le.<\/p>\nTrivy<\/code>, Grype<\/code>, Snyk<\/code> et Dependabot<\/code> analysent les d\u00e9pendances par rapport aux bases de donn\u00e9es de vuln\u00e9rabilit\u00e9s (NVD, OSV, GitHub Advisory Database) et peuvent bloquer les builds qui introduisent des vuln\u00e9rabilit\u00e9s connues. Pour une comparaison des outils d’analyse disponibles, consultez nos guides comparatifs des outils de s\u00e9curit\u00e9 CI\/CD<\/a>.<\/p>\nInt\u00e9grit\u00e9 du build : builds reproductibles et herm\u00e9tiques<\/h2>\n
Builds reproductibles<\/h3>\n
\n
SOURCE_DATE_EPOCH<\/code> pour normaliser les horodatages.<\/li>\nBuilds herm\u00e9tiques<\/h3>\n
S\u00e9curit\u00e9 de la plateforme de build<\/h3>\n
\n
.github\/workflows\/<\/code>, .gitlab-ci.yml<\/code>, Jenkinsfile<\/code>) devraient \u00eatre prot\u00e9g\u00e9s par des r\u00e8gles de protection de branches et n\u00e9cessiter une revue de code pour les modifications.<\/li>\nSignature et v\u00e9rification des artefacts avec Sigstore et Cosign<\/h2>\n
Le d\u00e9fi de la signature traditionnelle<\/h3>\n
Sigstore : signature sans cl\u00e9 pour la supply chain logicielle<\/h3>\n
\n
Signature keyless en CI\/CD<\/h3>\n
\n
Provenance et attestations : SLSA et in-toto<\/h2>\n
Provenance SLSA<\/h3>\n
\n
Attestations in-toto<\/h3>\n
\n
Nomenclatures logicielles (SBOMs)<\/h2>\n
Pourquoi les SBOMs sont importants<\/h3>\n
\n
Formats de SBOM<\/h3>\n
\n
G\u00e9n\u00e9ration de SBOM<\/h3>\n
\n
Attestation de SBOM<\/h3>\n
cosign attest --predicate sbom.spdx.json --type spdxjson <image><\/code><\/pre>\nCadres et standards<\/h2>\n
SLSA (Supply-chain Levels for Software Artifacts)<\/h3>\n
\n
NIST SSDF (Secure Software Development Framework)<\/h3>\n
\n
OWASP Software Component Verification Standard (SCVS)<\/h3>\n
OpenSSF Scorecard<\/h3>\n
Feuille de route d’impl\u00e9mentation<\/h2>\n
Phase 1 : Fondations (Semaines 1-4)<\/h3>\n
\n
Phase 2 : Int\u00e9grit\u00e9 (Semaines 5-12)<\/h3>\n
\n
slsa-github-generator<\/code>.<\/li>\nPhase 3 : V\u00e9rification (Semaines 13-20)<\/h3>\n
\n
Phase 4 : Avanc\u00e9 (En continu)<\/h3>\n
\n
Ateliers pratiques<\/h2>\n
\n
Outils et comparaisons<\/h2>\n
\n\n
\n \nCat\u00e9gorie<\/th>\n Outils<\/th>\n Cas d’usage<\/th>\n<\/tr>\n<\/thead>\n \n Scanners de vuln\u00e9rabilit\u00e9s<\/strong><\/td>\n Trivy, Grype, Snyk, Clair<\/td>\n Analyse des d\u00e9pendances et des images de conteneurs pour les vuln\u00e9rabilit\u00e9s connues<\/td>\n<\/tr>\n \n Signature d’artefacts<\/strong><\/td>\n Cosign, Notation, GPG<\/td>\n Signature cryptographique des artefacts pour garantir l’int\u00e9grit\u00e9 et l’authenticit\u00e9<\/td>\n<\/tr>\n \n G\u00e9n\u00e9ration de SBOM<\/strong><\/td>\n Syft, Trivy, cdxgen, CycloneDX CLI<\/td>\n Cr\u00e9ation d’inventaires de composants logiciels au format SPDX ou CycloneDX<\/td>\n<\/tr>\n \n Provenance<\/strong><\/td>\n SLSA GitHub Generator, Witness, in-toto<\/td>\n G\u00e9n\u00e9ration de provenance de build et d’attestations v\u00e9rifiables<\/td>\n<\/tr>\n \n Application des politiques<\/strong><\/td>\n Kyverno, OPA Gatekeeper, Sigstore Policy Controller<\/td>\n Application des politiques de supply chain au moment du d\u00e9ploiement via l’admission Kubernetes<\/td>\n<\/tr>\n \n Gestion des d\u00e9pendances<\/strong><\/td>\n Dependabot, Renovate, Socket.dev<\/td>\n Mises \u00e0 jour automatis\u00e9es des d\u00e9pendances, surveillance et d\u00e9tection de packages malveillants<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n