Supply Chain Security : SBOM, SLSA et Sigstore en 2026

L'attaque SolarWinds en 2020, la compromission de CodeCov en 2021, le cauchemar Log4Shell fin 2021, la backdoor XZ Utils en 2024 — la supply chain logicielle est devenue le vecteur d'attaque favori des groupes les plus sophistiqués. Et pour cause : compromettre une dépendance utilisée par des milliers de projets offre un effet de levier incomparable. Vous pouvez verrouiller votre code, durcir vos serveurs, former vos développeurs — si une bibliothèque tierce embarque une backdoor, tout s'effondre. La réponse de l'industrie se structure autour de trois piliers complémentaires. Le SBOM (Software Bill of Materials) dresse l'inventaire exact de ce que contient votre logiciel. SLSA (Supply-chain Levels for Software Artifacts) certifie que votre processus de build est intègre. Sigstore fournit la cryptographie pour signer et vérifier vos artefacts sans gérer de clés. Ce guide vous montre comment déployer ces trois briques concrètement dans vos pipelines existants.

SBOM : inventaire logiciel comme fondement de la sécurité supply chain

Le Software Bill of Materials (SBOM) est devenu un instrument central de la sécurité de la chaîne d'approvisionnement logicielle depuis que l'Executive Order américain de mai 2021 en a rendu la fourniture obligatoire pour les logiciels vendus au gouvernement fédéral américain. Un SBOM est un inventaire exhaustif et structuré de tous les composants logiciels qui constituent une application : bibliothèques tierces, frameworks, dépendances transitives avec leurs numéros de version exacts et leurs licences respectives. Cette transparence sur le contenu du logiciel permet à ses utilisateurs d'évaluer rapidement leur exposition lors de la divulgation d'une nouvelle vulnérabilité critique affectant un composant répertorié, sans attendre une communication de l'éditeur qui peut prendre des jours ou des semaines.

Les formats standardisés CycloneDX et SPDX permettent l'interopérabilité entre les outils de génération et d'analyse des SBOM, facilitant l'automatisation du processus. CycloneDX, initialement développé par l'OWASP, est particulièrement adapté aux besoins de sécurité avec des extensions pour les vulnérabilités (VEX, Vulnerability Exploitability eXchange) et les services. SPDX, projet de la Linux Foundation, est davantage orienté conformité des licences et est devenu une norme ISO (ISO/IEC 5962:2021). Les deux formats sont supportés par les principaux outils de génération (Syft, cdxgen, Trivy) et d'analyse (Dependency-Track, Grype) qui permettent d'automatiser la gestion des SBOM dans les pipelines CI/CD des organisations qui les adoptent.

La gestion des SBOM à l'échelle organisationnelle nécessite une plateforme centralisée capable d'ingérer, de stocker et d'analyser les SBOM de l'ensemble du portefeuille applicatif. OWASP Dependency-Track est la solution open source de référence pour ce cas d'usage : elle ingère les SBOM au format CycloneDX, les enrichit avec les données de vulnérabilités provenant de NVD et d'autres sources threat intelligence, et génère des alertes en temps réel lorsqu'une vulnérabilité critique affecte un composant présent dans l'un des SBOM managés. Cette plateforme devient un tableau de bord de risque supply chain qui permet aux équipes sécurité de prioriser leurs actions de remédiation selon l'exposition réelle et l'exploitabilité des vulnérabilités détectées dans le parc logiciel de l'organisation.

Le framework SLSA pour la sécurité de la chaîne de build

Supply-chain Levels for Software Artifacts (SLSA) est un framework de sécurité développé par Google et adopté par la Open Source Security Foundation (OpenSSF) qui définit des niveaux progressifs de sécurité pour les chaînes de build logicielles. SLSA organise ses exigences en quatre niveaux (SLSA 1 à 4) qui reflètent une protection croissante contre les attaques qui ciblent le processus de construction des logiciels plutôt que le code source lui-même. Au niveau SLSA 1, les builds doivent être scriptés et automatisés, avec génération de provenance (metadata décrivant comment l'artefact a été produit). Aux niveaux supérieurs, les exigences se renforcent : builds hermétiques isolés, provenance signée cryptographiquement et vérifiable, et résistance aux attaquants qui auraient compromis des parties du système de build.

La provenance SLSA est le document clé qui atteste de l'origine et du processus de construction d'un artefact logiciel. Elle contient des informations sur le dépôt source utilisé (avec son hash de commit exact), le système de build employé, les paramètres de build et les dépendances consommées lors de la construction. Cette provenance, signée cryptographiquement par le système de build, permet à tout consommateur de vérifier de manière indépendante et fiable qu'un artefact distribué a bien été produit par le processus déclaré à partir du code source annoncé, sans altération intermédiaire. Les plateformes CI/CD comme GitHub Actions, GitLab CI ou Google Cloud Build proposent des générateurs de provenance SLSA conformes qui permettent aux équipes DevOps d'atteindre le niveau SLSA 2 ou 3 sans effort de développement significatif de leur part.

L'adoption de SLSA dans un programme de sécurité supply chain se déroule progressivement, en commençant par inventorier le niveau SLSA actuel des projets critiques et en définissant des roadmaps d'amélioration réalistes par projet. Les builds entièrement manuels (SLSA 0) doivent être prioritairement migrés vers des pipelines automatisés documentés (SLSA 1), puis vers des builds avec provenance vérifiable (SLSA 2). L'atteinte du niveau SLSA 3, qui impose des builds hermétiques et une provenance non falsifiable par les développeurs eux-mêmes, représente un niveau de maturité avancé qui nécessite généralement des investissements significatifs dans l'infrastructure de build et peut prendre plusieurs trimestres à atteindre pour un portefeuille applicatif important.

Sigstore : infrastructure de signature cryptographique pour l'open source

Sigstore est un projet open source de la Linux Foundation qui fournit une infrastructure de signature cryptographique gratuite et facile d'accès pour les logiciels open source et les artefacts produits par les pipelines CI/CD. Son composant principal, Cosign, permet de signer des images de conteneurs, des binaires, des fichiers de configuration et des SBOM avec des paires de clés éphémères liées à l'identité OIDC du signataire (compte GitHub, Google ou Microsoft). Cette approche "keyless signing" (signature sans gestion de clés long terme) simplifie drastiquement l'adoption de la signature cryptographique, qui était historiquement freinée par la complexité de la gestion des clés GPG à l'échelle des projets open source et des organisations.

Le journal de transparence Rekor, second composant majeur de Sigstore, enregistre de manière immuable et publiquement vérifiable toutes les signatures produites via le framework. Chaque signature est inscrite dans un journal Merkle append-only qui permet à quiconque de vérifier qu'une signature existait à un moment précis et qu'elle n'a pas été rétroactivement créée ou modifiée. Ce journal de transparence joue un rôle similaire à la Certificate Transparency pour les certificats TLS : il rend les actions de signature publiquement auditables et détecte les compromissions d'identités de signataires qui auraient produit des signatures non autorisées. Les principaux projets open source comme Kubernetes, Sigstore lui-même, et des dizaines d'autres projets CNCF utilisent désormais Cosign pour signer leurs releases officielles.

L'intégration de Sigstore dans les pipelines CI/CD d'entreprise permet d'étendre les bénéfices de la signature transparente aux logiciels propriétaires et aux images de conteneurs internes. Cosign s'intègre nativement dans GitHub Actions, Tekton Chains et d'autres plateformes CI/CD populaires pour signer automatiquement les artefacts produits lors des builds en production. Les politiques d'admission Kubernetes peuvent vérifier ces signatures avant tout déploiement, garantissant que seuls les artefacts signés par des pipelines CI/CD de confiance peuvent être exécutés dans les clusters de production. Cette vérification automatique à l'exécution ferme la boucle de sécurité supply chain entre la production des artefacts et leur déploiement, détectant les images non autorisées avant qu'elles ne puissent s'exécuter et causer des dommages dans l'environnement de production de l'organisation.

Détection et réponse aux attaques supply chain en entreprise

La détection des attaques supply chain nécessite une combinaison de contrôles préventifs et de capacités de détection en temps réel qui couvrent l'ensemble de la chaîne de développement et de livraison logicielle. La surveillance des dépendances tierces pour détecter les typosquatting (packages aux noms proches des packages légitimes populaires) et les compromissions de comptes de mainteneurs (dependency confusion, account takeover) constitue une ligne de défense essentielle. Des outils spécialisés comme Socket.dev, Phylum ou les fonctionnalités de détection de packages malveillants de Snyk analysent en temps réel les nouvelles versions des packages publiées dans les registres publics (npm, PyPI, Maven) et alertent sur les comportements suspects : ajout soudain de code réseau dans une bibliothèque utilitaire, modification des permissions demandées ou changement de mainteneur inattendu.

La réponse aux incidents de compromission supply chain présente des défis spécifiques liés à l'étendue potentielle de l'impact : contrairement à une compromission d'un système interne, une dépendance malveillante peut avoir été utilisée par des centaines ou des milliers d'organisations avant d'être détectée. La procédure de réponse doit inclure l'inventaire rapide de tous les systèmes et applications utilisant le composant compromis (grâce aux SBOM centralisés), l'évaluation de l'exploitabilité de la compromission dans chaque contexte d'utilisation, la mise en quarantaine des systèmes potentiellement compromis et la coordination avec les équipes de développement pour le déploiement urgent de versions corrigées. La disponibilité immédiate des SBOM à jour réduit dramatiquement le temps de réponse initial, qui peut faire la différence entre une compromission contenue et un incident de sécurité majeur aux conséquences durables.

La gouvernance d'un programme de sécurité supply chain repose sur une collaboration étroite entre les équipes de développement, les équipes sécurité et les équipes d'approvisionnement qui gèrent les relations avec les fournisseurs de logiciels et les prestataires externes. Des procédures d'évaluation de la posture de sécurité supply chain des fournisseurs tiers, incluant l'exigence de SBOM avec les livraisons logicielles et la vérification du niveau SLSA des artefacts fournis, permettent d'étendre les exigences de sécurité au-delà du périmètre technique interne de l'organisation. Ces pratiques, formalisées dans les clauses contractuelles et les politiques d'achat informatique, transforment la sécurité supply chain d'une préoccupation technique en une exigence de gouvernance partagée par l'ensemble de l'écosystème de partenaires et de fournisseurs de l'organisation, réduisant ainsi le risque systémique lié à la complexité croissante des chaînes d'approvisionnement logicielles modernes.

Mise en conformité NIS 2 et exigences réglementaires sur la sécurité supply chain

La directive européenne NIS 2, transposée en droit français depuis octobre 2024, introduit des exigences explicites sur la sécurité de la chaîne d'approvisionnement logicielle et numérique pour les entités essentielles et importantes qu'elle couvre. L'article 21 de NIS 2 impose aux entités concernées de gérer les risques liés à leurs fournisseurs et prestataires de services, en évaluant la posture de sécurité de leurs partenaires et en incluant des clauses de sécurité dans les contrats. Cette exigence va au-delà de la simple vérification de conformité au moment de l'achat : elle impose une surveillance continue de la posture de sécurité supply chain et une capacité à répondre rapidement aux incidents de sécurité affectant les composants fournis par des tiers.

Les normes sectorielles renforcent ces exigences réglementaires dans des contextes spécifiques. Le standard PCI DSS v4.0, applicable aux environnements de paiement, exige dans son exigence 6.3.2 la maintenance d'un inventaire des logiciels sur mesure et des logiciels tiers, ce qui s'aligne directement avec la pratique SBOM. La norme IEC 62443 pour la cybersécurité des systèmes industriels impose également une analyse des risques supply chain pour les composants logiciels et matériels utilisés dans les systèmes de contrôle industriel. Ces exigences multi-référentielles créent un environnement réglementaire qui rend la mise en place d'un programme SBOM+SLSA+Sigstore non seulement souhaitable d'un point de vue sécurité, mais de plus en plus obligatoire d'un point de vue de la conformité réglementaire pour les organisations opérant dans les secteurs critiques couverts par ces référentiels.

SBOM : savoir exactement ce que contient votre logiciel

Un SBOM est l'équivalent numérique de la liste d'ingrédients sur un produit alimentaire. Pour chaque composant de votre application, il référence le nom, la version, la licence et l'origine. Deux formats dominent : SPDX (standardisé ISO/IEC 5962) et CycloneDX (maintenu par l'OWASP). En pratique, CycloneDX est plus adapté à la sécurité car il inclut nativement les VEX (Vulnerability Exploitability eXchange). Mon conseil : partez sur CycloneDX si votre objectif premier est la sécurité.

Pour générer un SBOM, Syft (d'Anchore) est la référence open-source. Une commande suffit : syft packages dir:. -o cyclonedx-json. Ce SBOM peut ensuite être analysé par Grype pour détecter les CVE. L'Executive Order 14028 américain exige un SBOM pour tout logiciel vendu au gouvernement fédéral. En Europe, le Cyber Resilience Act imposera une obligation similaire dès 2027. Intégrez la génération de SBOM dans votre pipeline CI/CD sécurisé dès maintenant.

SLSA : certifier l'intégrité de votre processus de build

Le SBOM vous dit ce qu'il y a dans votre logiciel. SLSA (prononcez "salsa") garantit que le processus de construction n'a pas été altéré. Développé par Google, ce framework définit trois niveaux de maturité. Le niveau 1 produit une provenance documentée. Le niveau 2 utilise un service de build hébergé avec des logs inaltérables. Le niveau 3 isole et durcit le build : pas d'accès réseau pendant la compilation, environnement éphémère, reproductibilité vérifiable.

Sur GitHub Actions, atteindre SLSA 3 se fait avec le slsa-github-generator. La provenance générée est une attestation in-toto vérifiable par n'importe quel consommateur de votre artefact. C'est exactement ce qui manquait lors de l'attaque SolarWinds : personne ne pouvait vérifier que le binaire distribué correspondait au code source audité. Pour comprendre les attaques sur les pipelines, notre article sur les attaques CI/CD et GitOps détaille les vecteurs exploités.

Sigstore : signer sans gérer de clés

La signature cryptographique d'artefacts existe depuis longtemps (GPG, clés PEM), mais la gestion des clés est un cauchemar opérationnel. Sigstore résout ce problème avec le mode keyless : votre identité CI (l'OIDC token de GitHub Actions) sert de preuve. Fulcio émet un certificat éphémère, Cosign signe l'artefact, et Rekor enregistre la signature dans un log de transparence immuable.

# Signer une image OCI (mode keyless)
cosign sign ghcr.io/myorg/myapp@sha256:abc123

# Vérifier la signature
cosign verify --certificate-identity https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main --certificate-oidc-issuer https://token.actions.githubusercontent.com ghcr.io/myorg/myapp@sha256:abc123

En production, configurez un admission controller Kubernetes (comme Kyverno) pour rejeter les images non signées. Pour les politiques Kubernetes, notre article sur Policy as Code avec OPA et Kyverno vous guide dans cette mise en place.

Workflow complet de défense supply chain

Les trois piliers fonctionnent en synergie. Voici le workflow recommandé pour un projet conteneurisé :

1. Build — Compiler dans un environnement isolé (SLSA 3). Générer le SBOM avec Syft.
2. Scan — Analyser le SBOM avec Grype ou Dependency-Track. Gate bloquante sur les CVE critiques.
3. Sign — Signer l'image avec Cosign keyless. Attacher le SBOM comme attestation OCI.
4. Store — Pousser l'image signée et le SBOM sur un registry OCI compatible (Harbor, GHCR, ECR).
5. Verify — L'admission controller Kubernetes vérifie signature et SBOM avant admission.
6. Monitor — Dependency-Track surveille les nouvelles CVE qui affectent vos SBOM existants.

Ce workflow ajoute 2-3 minutes à votre pipeline. C'est dérisoire comparé au coût d'une compromission. Selon le rapport Sonatype State of the Software Supply Chain 2025, les attaques supply chain ont augmenté de 245% en un an.

Surveiller les dépendances en continu

Générer un SBOM au moment du build ne suffit pas. Une CVE découverte trois mois après votre release affecte vos artefacts déjà déployés. OWASP Dependency-Track résout ce problème : vous uploadez vos SBOM, et la plateforme surveille en continu les nouvelles vulnérabilités. Elle interroge la base NVD du NIST, OSV.dev et les advisories GitHub.

Quand une nouvelle CVE est publiée, vous recevez une alerte avec la liste exacte des projets affectés et des versions à mettre à jour. C'est ce mécanisme qui a permis aux organisations équipées de réagir en quelques heures lors de Log4Shell. Pour la gestion des secrets liés à ces dépendances, consultez notre guide sur le secrets management cloud.