Sécurité de la Chaîne d’Approvisionnement Logicielle : Guide Complet pour les Équipes d’Ingénierie

par

Introduction : Pourquoi la sécurité de la chaîne d’approvisionnement logicielle est essentielle

En décembre 2020, le monde a découvert que SolarWinds — une plateforme de gestion informatique largement reconnue — avait été compromise. Des attaquants ont injecté du code malveillant dans le processus de build du logiciel Orion, distribuant une mise à jour corrompue à environ 18 000 organisations, dont des agences gouvernementales américaines et des entreprises du Fortune 500. L’attaque ne visait pas directement le dépôt de code source de SolarWinds, mais son pipeline de build. Cet incident unique a redéfini la manière dont l’industrie conçoit la sécurité logicielle.

Puis est arrivé Log4Shell fin 2021. Une vulnérabilité critique d’exécution de code à distance dans Apache Log4j — une bibliothèque de journalisation Java omniprésente — a exposé pratiquement toutes les entreprises de la planète. Les organisations se sont précipitées pour déterminer si elles utilisaient même Log4j, révélant un manque fondamental de visibilité sur les dépendances logicielles. La leçon était claire : on ne peut pas sécuriser ce que l’on ne peut pas voir.

Plus récemment, la backdoor XZ Utils (CVE-2024-3094) début 2024 a démontré un vecteur d’attaque encore plus insidieux. Une campagne patiente d’ingénierie sociale à long terme a permis à un contributeur malveillant d’insérer une porte dérobée dans une bibliothèque de compression critique utilisée dans presque toutes les distributions Linux. L’attaque ciblait spécifiquement le système de build, ne s’activant que sous certaines conditions de compilation — une attaque de la supply chain d’une sophistication extraordinaire.

Ces incidents partagent un fil conducteur commun : les attaquants ne ciblent plus seulement votre code applicatif — ils ciblent l’ensemble de la chaîne d’outils, de dépendances, de processus et d’infrastructures qui livre le logiciel en production. C’est la chaîne d’approvisionnement logicielle, et la sécuriser est devenu l’un des défis les plus critiques de l’ingénierie moderne.

Ce guide complet couvre toutes les dimensions de la sécurité de la supply chain logicielle — de la gestion des dépendances à l’intégrité des builds, en passant par la signature des artefacts, la provenance, les SBOMs et les cadres de conformité. Que vous soyez ingénieur DevOps, architecte sécurité ou responsable technique, ce guide fournit une feuille de route pratique et de bout en bout pour renforcer votre chaîne d’approvisionnement logicielle.

Comprendre le modèle de la chaîne d’approvisionnement logicielle

Avant de pouvoir sécuriser la supply chain, nous devons en comprendre les composants. Une chaîne d’approvisionnement logicielle moderne se compose de cinq étapes interconnectées :

1. Code source

C’est là que les développeurs écrivent, révisent et commitent le code. L’étape du source inclut les systèmes de contrôle de version (Git), les processus de revue de code, les règles de protection de branches et la signature des commits. Les menaces à ce stade incluent les comptes développeurs compromis, les commits malveillants et les modifications non autorisées des fichiers de configuration CI/CD (empoisonnement de pipeline).

2. Dépendances

Les applications modernes dépendent fortement de bibliothèques et packages tiers. Une application Node.js typique peut importer des centaines, voire des milliers de dépendances transitives. L’étape des dépendances englobe les registres de packages (npm, PyPI, Maven Central), les fichiers de verrouillage (lockfiles), la résolution de versions et l’analyse de vulnérabilités. C’est l’une des étapes de la supply chain les plus fréquemment exploitées.

3. Build

L’étape de build transforme le code source et les dépendances en artefacts déployables. Cela inclut la compilation, le bundling, la construction d’images de conteneurs et l’exécution des tests. Les systèmes de build — qu’il s’agisse de Jenkins, GitHub Actions, GitLab CI ou d’autres — sont des cibles de haute valeur car compromettre un processus de build peut injecter du code malveillant dans chaque artefact produit.

4. Artefacts

Les sorties de build — images de conteneurs, binaires, packages — sont stockées dans des registres d’artefacts (Docker Hub, Amazon ECR, Artifactory, etc.). L’étape des artefacts implique la signature, la vérification, l’attachement de métadonnées et le contrôle d’accès. Sans contrôles d’intégrité appropriés, les artefacts peuvent être altérés après le build.

5. Déploiement

La dernière étape livre les artefacts aux environnements de production. Le déploiement implique les plateformes d’orchestration (Kubernetes), les contrôleurs d’admission, l’application des politiques et la vérification en temps réel. C’est la dernière ligne de défense — le point où vous vérifiez que ce que vous déployez est exactement ce qui a été construit.

Chaque étape présente des surfaces d’attaque uniques et nécessite des mesures défensives spécifiques. Le reste de ce guide détaille chacune d’entre elles.

Risques et défenses liés aux dépendances

Les dépendances sont sans doute le composant le plus vulnérable de la chaîne d’approvisionnement logicielle. Les études montrent systématiquement que plus de 80 % du code des applications modernes provient de dépendances open source. Cela crée une surface d’attaque énorme, difficile à surveiller et à contrôler.

Attaques courantes sur les dépendances

La confusion de dépendances (aussi appelée confusion d’espace de noms) exploite la manière dont les gestionnaires de packages résolvent les dépendances. 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ême nom sur le registre public. Si le gestionnaire de packages est mal configuré, il peut récupérer le package de l’attaquant au lieu du package interne. Ce vecteur d’attaque a été rendu célèbre par le chercheur en sécurité Alex Birsan en 2021, affectant Apple, Microsoft et d’autres grandes entreprises.

Le typosquatting cible les développeurs qui commettent des erreurs typographiques en spécifiant les noms de packages. Les attaquants publient des packages malveillants dont les noms ressemblent étroitement à des bibliothèques populaires — par exemple, reqeusts au lieu de requests, ou lodash-utils imitant lodash. Ces packages contiennent souvent du code d’exfiltration de données ou de minage de cryptomonnaies.

Les comptes mainteneurs compromis permettent aux attaquants de publier des mises à jour malveillantes sur des packages légitimes et largement utilisés. L’incident event-stream en 2018 et la compromission de ua-parser-js en 2021 en sont des exemples notables. Parce que les packages sont légitimes et de confiance, le code malveillant se propage rapidement.

Pour une analyse approfondie de ces vecteurs d’attaque et des défenses pratiques, consultez notre guide détaillé : Confusion de dépendances et empoisonnement d’artefacts : attaques et défenses.

Stratégies défensives

Fichiers de verrouillage et épinglage de versions : Commitez toujours les lockfiles (package-lock.json, Pipfile.lock, go.sum, Cargo.lock) dans le contrôle de version. Les lockfiles enregistrent les versions exactes et les hachages d’intégrité de chaque dépendance, garantissant des installations reproductibles. Épinglez les dépendances à des versions exactes plutôt que d’utiliser des plages de versions pour éviter les mises à jour inattendues.

Configuration du registre privé : Configurez les gestionnaires de packages pour résoudre les packages internes exclusivement depuis votre registre privé. Utilisez des packages scopés (par ex., @votreentreprise/nom-du-package) et configurez les mappages de registres pour prévenir les attaques par confusion de dépendances. Des outils comme Artifactory et Nexus peuvent servir de proxy pour les registres publics tout en fournissant une couche supplémentaire d’analyse et de contrôle.

Analyse de vulnérabilités : Intégrez des outils d’analyse de composition logicielle (SCA) dans votre pipeline CI/CD. Des outils comme Trivy, Grype, Snyk et Dependabot analysent les dépendances par rapport aux bases de données de vulnérabilités (NVD, OSV, GitHub Advisory Database) et peuvent bloquer les builds qui introduisent des vulnérabilités connues. Pour une comparaison des outils d’analyse disponibles, consultez nos guides comparatifs des outils de sécurité CI/CD.

Revue des dépendances et liste d’autorisation : Établissez un processus de revue pour les nouvelles dépendances. Évaluez les packages en fonction de l’activité de maintenance, du nombre de contributeurs, des statistiques de téléchargement et des vulnérabilités connues. Certaines organisations maintiennent une liste de packages approuvés et exigent une revue de sécurité avant d’en ajouter de nouveaux.

Intégrité du build : builds reproductibles et hermétiques

L’étape de build est celle où le code source et les dépendances sont transformés en artefacts déployables. Si un attaquant peut compromettre le processus de build, il peut injecter du code malveillant dans la sortie sans modifier le code source — exactement comme cela s’est produit lors de l’attaque SolarWinds. L’intégrité du build garantit que le processus de build lui-même est digne de confiance.

Builds reproductibles

Un build reproductible est un build qui produit une sortie identique à partir du même code source, des mêmes dépendances, du même environnement de build et des mêmes instructions de build. La reproductibilité est une propriété de sécurité puissante car elle permet une vérification indépendante : n’importe qui peut reconstruire à partir des mêmes entrées et confirmer que la sortie correspond. Si la sortie diffère, cela indique une altération.

Obtenir des builds reproductibles nécessite d’éliminer les sources de non-déterminisme :

  • Horodatages : Les horodatages intégrés font varier les sorties de build entre les exécutions. Utilisez SOURCE_DATE_EPOCH pour normaliser les horodatages.
  • Ordre des fichiers : L’ordre d’énumération du système de fichiers peut varier. Assurez un ordre déterministe des fichiers dans les archives et les couches de systèmes de fichiers.
  • Aléatoire : Certains outils intègrent des valeurs aléatoires (UUIDs, nonces) dans la sortie. Utilisez des graines déterministes ou supprimez les éléments aléatoires.
  • Dépendances flottantes : Assurez-vous que toutes les dépendances sont épinglées à des versions exactes avec des hachages d’intégrité vérifiés lors de l’installation.

Builds hermétiques

Un build hermétique est isolé de l’environnement hôte et du réseau. Il ne peut accéder qu’aux entrées explicitement déclarées — pas d’appels réseau, pas d’accès aux chemins du système de fichiers hôte en dehors du bac à sable de build, pas de dépendance à des outils préinstallés. Les builds hermétiques garantissent que la sortie du build ne dépend que des entrées déclarées, rendant impossible pour un attaquant d’injecter des dépendances ou des outils supplémentaires pendant le processus de build.

Les systèmes de build comme Bazel, Buck2 et Pants sont conçus pour les builds hermétiques dès leur conception. Pour les builds de conteneurs, des outils comme BuildKit avec isolation réseau et ko pour les applications Go offrent des capacités de build hermétique.

Pour un guide complet sur l’implémentation de builds reproductibles et hermétiques dans votre pipeline CI/CD, consultez : Intégrité du build : builds reproductibles en CI/CD.

Sécurité de la plateforme de build

Au-delà du processus de build lui-même, la plateforme de build nécessite un renforcement :

  • Environnements de build éphémères : Utilisez des runners frais et éphémères pour chaque build afin de prévenir les attaques basées sur la persistance. Ne réutilisez jamais les environnements de build entre les jobs.
  • Identifiants à moindre privilège : Les jobs de build ne devraient avoir que les permissions minimales nécessaires. Utilisez des jetons à courte durée de vie et à portée limitée plutôt que des secrets à longue durée de vie.
  • Protection du pipeline-as-code : Les fichiers de configuration CI/CD (.github/workflows/, .gitlab-ci.yml, Jenkinsfile) devraient être protégés par des règles de protection de branches et nécessiter une revue de code pour les modifications.
  • Audit des logs de build : Maintenez des logs de build immuables qui capturent toutes les entrées, sorties et détails de l’environnement pour l’analyse forensique.

Signature et vérification des artefacts avec Sigstore et Cosign

Une fois qu’un build produit un artefact — une image de conteneur, un binaire, un package — comment s’assurer qu’il n’a pas été altéré avant le déploiement ? La signature d’artefacts fournit une preuve cryptographique qu’un artefact a été produit par un processus de build de confiance et n’a pas été modifié depuis.

Le défi de la signature traditionnelle

La signature de code traditionnelle repose sur des clés cryptographiques à longue durée de vie. Cela crée des défis opérationnels significatifs : génération de clés, stockage sécurisé, rotation, révocation et distribution. Si une clé de signature est compromise, chaque artefact signé avec cette clé est suspect. La gestion des clés a historiquement été si contraignante que de nombreuses équipes renoncent tout simplement à la signature.

Sigstore : signature sans clé pour la supply chain logicielle

Sigstore est un projet open source qui simplifie fondamentalement la signature d’artefacts en éliminant le besoin de clés à longue durée de vie. Sigstore se compose de plusieurs composants :

  • Cosign : Un outil pour signer et vérifier les images de conteneurs et autres artefacts OCI. Cosign prend en charge les workflows de signature avec clé et sans clé (keyless).
  • Fulcio : Une autorité de certification qui émet des certificats de signature à courte durée de vie basés sur des jetons d’identité OpenID Connect (OIDC). Au lieu de gérer des clés, vous vous authentifiez auprès de votre fournisseur d’identité (GitHub, Google, etc.) et recevez un certificat temporaire.
  • Rekor : Un journal de transparence inviolable qui enregistre tous les événements de signature. Rekor fournit un enregistrement permanent et auditable de chaque signature d’artefact, permettant la vérification même après l’expiration du certificat à courte durée de vie.

Signature keyless en CI/CD

Dans un pipeline CI/CD, la signature keyless avec Sigstore fonctionne comme suit :

  1. Le système de build termine et produit un artefact (par ex., une image de conteneur).
  2. Cosign demande un certificat de signature à Fulcio, en s’authentifiant avec le jeton OIDC de la plateforme CI/CD (par ex., le jeton OIDC de GitHub Actions).
  3. Fulcio vérifie l’identité et émet un certificat à courte durée de vie qui intègre les claims d’identité (dépôt, workflow, SHA du commit).
  4. Cosign signe l’artefact avec la clé éphémère et enregistre la signature dans Rekor.
  5. La clé éphémère est détruite — aucun secret à longue durée de vie à gérer.

Au moment du déploiement, vous vérifiez la signature en consultant le journal de transparence Rekor et en validant que l’identité du signataire correspond à votre workflow CI/CD attendu.

Pour un tutoriel pratique sur l’implémentation de Sigstore et Cosign dans votre pipeline, consultez : Signer et vérifier les images de conteneurs avec Sigstore et Cosign.

Provenance et attestations : SLSA et in-toto

La signature vous dit qui a produit un artefact, mais ne vous dit pas comment il a été produit. La provenance répond aux questions critiques : quel code source a été utilisé ? Quel processus de build a été exécuté ? Quelles dépendances ont été incluses ? Quel builder a été utilisé ? La provenance fournit un enregistrement vérifiable de l’origine et du processus de build de l’artefact.

Provenance SLSA

SLSA (Supply-chain Levels for Software Artifacts, prononcé « salsa ») est un framework développé par Google et l’OpenSSF qui définit des niveaux croissants de sécurité de la supply chain. À son cœur, SLSA spécifie un format de provenance standard qui capture :

  • Identité du builder : Quelle plateforme de build a produit l’artefact.
  • Référence source : Le dépôt source exact, la branche et le commit.
  • Recette de build : La configuration de build (fichier de workflow, commande de build).
  • Matériaux : Toutes les entrées du build (dépendances, images de base).
  • Métadonnées : Horodatages, informations de reproductibilité et version du builder.

La provenance SLSA est générée par la plateforme de build (et non par le script de build), ce qui est crucial — 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énérateurs de provenance SLSA natifs.

Attestations in-toto

in-toto est un framework pour sécuriser l’intégrité de l’ensemble de la chaîne d’approvisionnement logicielle. Alors que SLSA se concentre principalement sur la provenance du build, in-toto fournit un cadre d’attestation plus général qui peut capturer n’importe quelle étape de la supply chain — revue de code, tests, analyse, approbation et déploiement.

Une attestation in-toto suit le format DSSE (Dead Simple Signing Envelope) et se compose de :

  • Sujet : Le ou les artefacts auxquels l’attestation se réfère (identifiés par leur digest).
  • Type de prédicat : Le type d’attestation (provenance SLSA, résultat d’analyse de vulnérabilités, SBOM, etc.).
  • Prédicat : Les données réelles de l’attestation.

Plusieurs attestations peuvent être attachées à un seul artefact, créant un ensemble riche de métadonnées que les moteurs de politiques peuvent évaluer au moment du déploiement.

Pour un guide détaillé sur la génération et la vérification de la provenance et des attestations, consultez : Provenance des artefacts et attestations : SLSA et in-toto.

Nomenclatures logicielles (SBOMs)

Un SBOM (Software Bill of Materials) est un inventaire exhaustif de tous les composants, bibliothèques et dépendances d’un artefact logiciel. Considérez-le comme une étiquette nutritionnelle pour le logiciel — il indique aux consommateurs exactement ce qu’il contient. Les SBOMs sont devenus une exigence réglementaire dans de nombreux contextes et sont essentiels pour la gestion des vulnérabilités et la réponse aux incidents.

Pourquoi les SBOMs sont importants

Lorsque Log4Shell a frappé en décembre 2021, les organisations capables de déterminer rapidement si elles utilisaient Log4j — et où — ont pu réagir en quelques heures. Les organisations sans cette visibilité ont mis des semaines ou des mois. Les SBOMs fournissent cette visibilité de manière proactive, avant qu’un incident ne survienne.

Les SBOMs servent plusieurs objectifs :

  • Gestion des vulnérabilités : Surveillance continue des composants par rapport aux bases de données de vulnérabilités. Lorsqu’un nouveau CVE est publié, identification immédiate des artefacts affectés.
  • Conformité des licences : Suivi des licences de tous les composants inclus pour garantir la conformité avec les politiques organisationnelles et les exigences légales.
  • Conformité réglementaire : L’Executive Order 14028 et diverses réglementations sectorielles exigent désormais des SBOMs pour les logiciels vendus au gouvernement américain.
  • Réponse aux incidents : Détermination rapide du rayon d’impact d’une vulnérabilité nouvellement découverte dans l’ensemble de votre portefeuille logiciel.

Formats de SBOM

Deux formats principaux de SBOM dominent le secteur :

  • SPDX (Software Package Data Exchange) : Un standard ISO/IEC (ISO/IEC 5962:2021) maintenu par la Linux Foundation. SPDX prend en charge plusieurs formats de sérialisation (JSON, RDF, tag-value, YAML) et est largement utilisé pour la conformité des licences.
  • CycloneDX : Un projet OWASP conçu spécifiquement pour les cas d’usage liés à la sécurité. CycloneDX prend en charge les inventaires de composants, les références de vulnérabilités, les définitions de services et les relations de composition. Il est disponible aux formats JSON et XML.

Génération de SBOM

Les SBOMs doivent être générés dans le cadre du pipeline CI/CD, aussi près que possible de l’étape de build. Les outils courants pour la génération de SBOMs incluent :

  • Syft : Un outil open source d’Anchore qui génère des SBOMs à partir d’images de conteneurs, de systèmes de fichiers et d’archives. Prend en charge les formats SPDX et CycloneDX.
  • Trivy : Le scanner complet d’Aqua Security peut générer des SBOMs en plus de l’analyse de vulnérabilités, fournissant un outil unifié pour les deux fonctions.
  • cdxgen : Un générateur CycloneDX qui prend en charge une large gamme de langages et de gestionnaires de packages.

Attestation de SBOM

Générer un SBOM n’est que la première étape. Pour rendre les SBOMs dignes de confiance, ils doivent être signés et attachés aux artefacts en tant qu’attestations. En utilisant Cosign, vous pouvez attester un SBOM à une image de conteneur :

cosign attest --predicate sbom.spdx.json --type spdxjson <image>

Cela crée une attestation signée qui lie le SBOM à un digest d’artefact spécifique, garantissant que le SBOM ne peut pas être séparé de l’artefact qu’il décrit ni falsifié. Les consommateurs peuvent alors vérifier à la fois la signature de l’artefact et l’attestation du SBOM avant le déploiement.

Pour un atelier pratique sur la génération, l’analyse et l’attestation de SBOMs, consultez notre atelier SBOM dans la série Sécurité CI/CD.

Cadres et standards

Plusieurs cadres et standards proposent des approches structurées de la sécurité de la supply chain. Comprendre ces cadres aide les organisations à prioriser les investissements et à démontrer leur conformité.

SLSA (Supply-chain Levels for Software Artifacts)

SLSA définit quatre niveaux de maturité croissante en matière de sécurité de la supply chain :

  • SLSA Niveau 1 — La provenance existe : Le processus de build génère une provenance décrivant comment l’artefact a été construit. C’est le niveau de base — le simple fait d’avoir une provenance est une amélioration significative par rapport à l’absence totale.
  • SLSA Niveau 2 — Build hébergé, provenance signée : Le build s’exécute sur un service de build hébergé, et la provenance est signée par la plateforme de build. Cela empêche les développeurs de falsifier la provenance sur leurs machines locales.
  • SLSA Niveau 3 — Builds renforcés : La plateforme de build fournit une isolation forte entre les jobs de build, des environnements éphémères et une génération de provenance inviolable. C’est le niveau qui prévient la plupart des attaques pratiques de la supply chain.
  • SLSA Niveau 4 — Hermétique, reproductible : Le build est entièrement hermétique (pas d’accès réseau, pas d’entrées non déclarées) et idéalement reproductible. C’est le standard d’excellence, offrant le plus haut niveau d’assurance.

Pour une checklist de conformité pratique et des conseils d’implémentation pour chaque niveau SLSA, consultez : Les niveaux SLSA expliqués : checklist de conformité pratique.

NIST SSDF (Secure Software Development Framework)

Le SSDF (SP 800-218) fournit un ensemble de pratiques de haut niveau, indépendantes des technologies, pour le développement logiciel sécurisé. Il est organisé en quatre groupes :

  • Préparer l’organisation (PO) : Établir les politiques de sécurité, les rôles et la formation.
  • Protéger le logiciel (PS) : Protéger le code source, les environnements de build et les artefacts contre les accès non autorisés et l’altération.
  • Produire un logiciel bien sécurisé (PW) : Concevoir, implémenter et tester le logiciel en intégrant la sécurité.
  • Répondre aux vulnérabilités (RV) : Identifier, analyser et remédier aux vulnérabilités dans les logiciels publiés.

Le SSDF est particulièrement pertinent pour les organisations qui fournissent des logiciels au gouvernement fédéral américain, car il est référencé par l’Executive Order 14028 et les mémorandums OMB associés.

OWASP Software Component Verification Standard (SCVS)

Le OWASP SCVS fournit un cadre spécifiquement axé sur l’analyse des composants logiciels et la gestion des risques de la supply chain. Il définit des exigences de vérification dans six catégories : BOM, identité logicielle, provenance, intégrité des packages, analyse des composants et lignée. Le SCVS est utile comme checklist détaillée pour évaluer les pratiques de sécurité de la supply chain de votre organisation.

OpenSSF Scorecard

Le projet OpenSSF Scorecard évalue automatiquement les projets open source selon un ensemble d’heuristiques de sécurité — protection de branches, épinglage des dépendances, releases signées, tests CI, et plus encore. Exécuter Scorecard sur vos dépendances vous aide à évaluer leur posture de sécurité et à identifier les risques. Intégrer Scorecard dans votre processus de revue des dépendances ajoute une couche de défense supplémentaire.

Feuille de route d’implémentation

Sécuriser une chaîne d’approvisionnement logicielle est un parcours, pas un projet unique. La feuille de route phasée suivante fournit un chemin pratique, de l’hygiène fondamentale aux postures de sécurité avancées.

Phase 1 : Fondations (Semaines 1-4)

Se concentrer sur la visibilité et les contrôles de base :

  • Inventorier votre supply chain : Cartographier tous les dépôts, systèmes de build, registres d’artefacts et cibles de déploiement. Identifier toutes les dépendances tierces de vos projets.
  • Activer l’analyse des dépendances : Intégrer Trivy, Grype ou Dependabot dans tous les pipelines CI/CD. Configurer des alertes automatisées pour les vulnérabilités critiques et de haute sévérité.
  • Commiter les lockfiles : S’assurer que tous les projets utilisent et commitent des lockfiles. Épingler les dépendances à des versions exactes.
  • Appliquer la protection de branches : Exiger la revue de code et les vérifications de statut pour toutes les fusions vers les branches principales. Protéger les fichiers de configuration CI/CD.
  • Générer des SBOMs : Ajouter la génération de SBOMs à vos pipelines de build. Stocker les SBOMs aux côtés des artefacts dans votre registre.

Phase 2 : Intégrité (Semaines 5-12)

Ajouter des contrôles d’intégrité cryptographiques :

  • Implémenter la signature d’artefacts : Déployer Cosign avec la signature keyless en utilisant l’identité OIDC de votre plateforme CI/CD. Signer toutes les images de conteneurs et les artefacts critiques.
  • Générer la provenance de build : Activer la génération de provenance SLSA dans vos pipelines de build. Les utilisateurs de GitHub Actions peuvent utiliser les workflows réutilisables slsa-github-generator.
  • Configurer les registres privés : Mettre en place Artifactory ou Nexus comme proxy pour les registres publics. Configurer les gestionnaires de packages pour résoudre d’abord depuis les registres privés afin de prévenir la confusion de dépendances.
  • Atteindre SLSA Niveau 2 : Avec des builds hébergés et une provenance signée, la plupart des équipes peuvent atteindre SLSA Niveau 2 à la fin de cette phase.

Phase 3 : Vérification (Semaines 13-20)

Appliquer les politiques au moment du déploiement :

  • Déployer des contrôleurs d’admission : Utiliser les contrôleurs d’admission Kubernetes (Kyverno, OPA Gatekeeper, Sigstore Policy Controller) pour appliquer la vérification des signatures et de la provenance avant le déploiement.
  • Attester les SBOMs : Signer les SBOMs et les attacher aux artefacts en tant qu’attestations in-toto. Vérifier les attestations de SBOM dans le cadre des politiques de déploiement.
  • Renforcer les environnements de build : Passer à des runners de build éphémères et isolés. Minimiser les privilèges de l’environnement de build. Atteindre SLSA Niveau 3.
  • Automatiser la conformité : Utiliser des outils de policy-as-code pour vérifier en continu la conformité avec SLSA, le SSDF et les politiques de sécurité organisationnelles.

Phase 4 : Avancé (En continu)

Poursuivre la défense en profondeur et l’amélioration continue :

  • Builds hermétiques : Étudier Bazel, Buck2 ou d’autres systèmes de build prenant en charge les builds entièrement hermétiques sans accès réseau.
  • Builds reproductibles : Travailler vers la reproductibilité des builds pour les artefacts critiques. La vérification indépendante des builds offre le plus haut niveau d’assurance.
  • Modélisation des menaces de la supply chain : Conduire des exercices réguliers de modélisation des menaces axés spécifiquement sur les vecteurs d’attaque de la supply chain.
  • Planification de la réponse aux incidents : Développer et répéter les procédures de réponse aux incidents pour les compromissions de la supply chain, y compris les compromissions de dépendances, les violations de systèmes de build et l’altération d’artefacts.

Ateliers pratiques

La théorie est importante, mais la pratique est essentielle. Les ateliers suivants fournissent une expérience pratique avec les outils et techniques abordés dans ce guide :

Outils et comparaisons

Choisir les bons outils est essentiel pour une sécurité de la supply chain efficace. Les guides comparatifs suivants vous aident à évaluer les options dans les catégories clés :

Catégorie Outils Cas d’usage
Scanners de vulnérabilités Trivy, Grype, Snyk, Clair Analyse des dépendances et des images de conteneurs pour les vulnérabilités connues
Signature d’artefacts Cosign, Notation, GPG Signature cryptographique des artefacts pour garantir l’intégrité et l’authenticité
Génération de SBOM Syft, Trivy, cdxgen, CycloneDX CLI Création d’inventaires de composants logiciels au format SPDX ou CycloneDX
Provenance SLSA GitHub Generator, Witness, in-toto Génération de provenance de build et d’attestations vérifiables
Application des politiques Kyverno, OPA Gatekeeper, Sigstore Policy Controller Application des politiques de supply chain au moment du déploiement via l’admission Kubernetes
Gestion des dépendances Dependabot, Renovate, Socket.dev Mises à jour automatisées des dépendances, surveillance et détection de packages malveillants

Pour des comparaisons détaillées de ces outils, incluant des matrices de fonctionnalités et des recommandations, consultez notre série d’outils et comparaisons de sécurité CI/CD.

Conclusion

La sécurité de la chaîne d’approvisionnement logicielle n’est plus optionnelle — c’est une exigence fondamentale pour toute organisation qui construit et déploie des logiciels. Les attaques contre SolarWinds, Log4j et XZ Utils ont démontré que la sécurité périmétrique traditionnelle est insuffisante lorsque la supply chain elle-même est le vecteur d’attaque.

La bonne nouvelle est que l’écosystème d’outils et de standards a rapidement mûri. Sigstore a rendu la signature d’artefacts accessible à toutes les équipes. SLSA fournit un cadre de maturité clair et incrémental. Les SBOMs deviennent une pratique standard. Les moteurs de politiques peuvent appliquer automatiquement les exigences de la supply chain au moment du déploiement.

Les principes clés à retenir :

  • Vérifier, ne pas faire confiance : Vérifiez cryptographiquement chaque artefact, dépendance et sortie de build. Partez du principe que tout composant non vérifié peut être compromis.
  • Tout automatiser : Les contrôles de sécurité de la supply chain doivent être automatisés et appliqués dans le pipeline. Les processus manuels ne passent pas à l’échelle et sont facilement contournés.
  • Défense en profondeur : Aucun contrôle unique n’est suffisant. Superposez les défenses à chaque étape de la supply chain — source, dépendances, build, artefact et déploiement.
  • Commencer là où vous en êtes : Vous n’avez pas besoin d’atteindre SLSA Niveau 4 du jour au lendemain. Commencez par l’analyse des dépendances et les lockfiles, puis ajoutez progressivement la signature, la provenance, les SBOMs et l’application des politiques.
  • Maintenir la visibilité : On ne peut pas sécuriser ce que l’on ne peut pas voir. Les SBOMs, la provenance et les journaux d’audit fournissent la visibilité nécessaire pour une sécurité efficace et une réponse aux incidents.

Commencez par la feuille de route d’implémentation ci-dessus, réalisez les ateliers pratiques, et renforcez progressivement votre supply chain. Le chemin de zéro à une sécurité complète de la supply chain est incrémental — et chaque étape rend votre logiciel significativement plus sûr.