Sécuriser la Chaîne d’Approvisionnement Logicielle : Sigstore, SLSA et le Nouveau Modèle de Confiance des Conteneurs

L’attaque SolarWinds de 2020 a constitué un tournant décisif. Les attaquants n’ont pas compromis directement les organisations visées. Ils ont infiltré le pipeline de construction logicielle d’un fournisseur de confiance, inséré du code malveillant dans une mise à jour légitime, et l’ont distribuée à des milliers de clients qui avaient toutes les raisons de faire confiance à ce qu’ils installaient. La faille a compromis le Trésor américain, le Département de la Sécurité intérieure, et des centaines d’organisations du secteur privé. Les dommages n’étaient pas la conséquence de mots de passe faibles ou de serveurs non patchés — ils découlaient du caractère fondamentalement non fiable de la chaîne d’approvisionnement logicielle.

Cette prise de conscience a alimenté l’un des mouvements de sécurité d’infrastructure les plus importants des années 2020. En 2026, la pile de sécurité de la chaîne d’approvisionnement logicielle — Sigstore pour la signature d’artefacts, SLSA pour l’attestation d’intégrité des constructions, les SBOMs pour la transparence des dépendances, et les registres de conteneurs renforcés — a mûri de projets de recherche en exigences de production dans les organisations d’ingénierie sérieuses.

Le Problème que SolarWinds a Rendu Incontestable

Le logiciel moderne n’est pas écrit de zéro. Il est assemblé. Une application d’entreprise typique intègre des centaines de dépendances open source, qui elles-mêmes en intègrent des centaines d’autres. L’application moyenne contient plus de lignes de code tiers que de code propriétaire. Chacune de ces dépendances représente un vecteur d’attaque potentiel.

La vulnérabilité Log4Shell, fin 2021, l’a démontré avec une clarté terrifiante. Une faille critique dans Log4j, une bibliothèque de journalisation Java omniprésente utilisée dans tout, des serveurs d’entreprise aux systèmes embarqués, a exposé des centaines de millions d’applications à l’échelle mondiale. Le problème n’était pas que Log4j était peu connue — elle était partout précisément parce qu’elle était fiable et largement adoptée. Son omniprésence constituait la surface de vulnérabilité.

Le modèle d’attaque par dépendances s’est depuis répandu. Des packages malveillants téléversés sur npm, PyPI et RubyGems — délibérément nommés pour ressembler à des packages légitimes populaires (typosquatting) — sont devenus un vecteur de menace courant. Les attaques sur la chaîne d’approvisionnement ont progressé de plus de 730% entre 2019 et 2022 selon le rapport annuel de Sonatype sur l’état de la chaîne d’approvisionnement logicielle, et la tendance s’est poursuivie à la hausse.

Sigstore : Tout Signer, Ne Faire Confiance à Rien de Non Signé

Sigstore est un projet de la Linux Foundation qui fournit une infrastructure ouverte et gratuite pour signer des artefacts logiciels — images de conteneurs, binaires, attestations de construction — et vérifier ces signatures de manière transparente. L’intuition centrale est que la provenance logicielle (d’où vient quelque chose et qui l’a construit) devrait être aussi vérifiable que les certificats HTTPS sur les sites web.

L’approche traditionnelle de la signature de code nécessitait de gérer des clés privées, ce qui est genuinement difficile à faire de manière sécurisée à l’échelle. Les clés fuient, se perdent ou sont renouvelées de façon incohérente. La solution de Sigstore est d’utiliser des certificats de courte durée liés à une identité OIDC (l’identité GitHub ou Google d’un développeur) plutôt que des clés privées persistantes. L’événement de signature est enregistré dans un journal de transparence public et en ajout seul nommé Rekor, qui permet à quiconque de vérifier qu’un artefact spécifique a été signé par une identité spécifique à un moment précis.

En 2025, Sigstore avait traité des milliards de signatures. Le Python Package Index (PyPI) a commencé à déployer des attestations de provenance basées sur Sigstore. GitHub a intégré Sigstore dans ses workflows Actions, permettant à tout dépôt de générer automatiquement des attestations de construction signées. Le registre npm de GitHub a suivi. Pour toute organisation tirant des packages de ces registres, l’infrastructure pour vérifier qu’un package a bien été construit à partir du code source déclaré — et n’a pas été altéré en transit — existe désormais et constitue de plus en plus la base de référence attendue.

SLSA : Les Niveaux d’Intégrité de Construction

Sigstore indique qui a signé un artefact. SLSA (Supply-chain Levels for Software Artifacts, prononcé « salsa ») indique à quel point le processus de construction qui l’a produit était digne de confiance. SLSA est un cadre développé chez Google et désormais géré par l’OpenSSF (Open Source Security Foundation) qui définit quatre niveaux gradués de sécurité de la chaîne d’approvisionnement.

Au niveau 1 de SLSA, les constructions sont documentées. Au niveau 2, les constructions sont versionnées et utilisent un service de construction. Au niveau 3, le service de construction est renforcé contre les altérations — les sources et les étapes de construction sont enregistrées dans une provenance vérifiable. Le niveau 4 (le plus strict, pas encore largement adopté) exige une révision par deux parties de tous les changements et un processus de construction hermétique et reproductible.

L’effet pratique est que SLSA donne aux équipes d’approvisionnement, aux auditeurs de sécurité et aux ingénieurs de plateforme un vocabulaire pour demander « dans quelle mesure cet artefact est-il fiable ? » plutôt que simplement « a-t-il été signé ? » Une image de conteneur construite depuis un environnement de construction éphémère et isolé avec une provenance enregistrée au niveau 3 de SLSA est meaningfully plus fiable qu’une construite localement sur le laptop d’un développeur et poussée directement vers un registre, que les deux soient signées ou non.

Les principaux fournisseurs de cloud ont évolué pour prendre en charge les attestations SLSA nativement. Google Cloud Build génère une provenance SLSA niveau 3. GitHub Actions prend en charge la génération d’attestations SLSA. Le décret exécutif du gouvernement fédéral américain sur l’amélioration de la cybersécurité nationale a mandaté des lignes directrices NIST qui s’alignent sur les principes SLSA pour les logiciels achetés par les agences fédérales.

Mandats SBOM : Savoir ce qui Se Trouve dans Votre Logiciel

Un Software Bill of Materials (SBOM) est un inventaire lisible par machine de tous les composants d’un logiciel — ses dépendances directes, leurs dépendances transitives, leurs versions, et leurs obligations de licence connues. Le concept est emprunté à la fabrication, où une nomenclature est un document standard.

Le décret exécutif américain de mai 2021 a rendu les SBOMs obligatoires pour les logiciels vendus au gouvernement fédéral. Le Cyber Resilience Act de l’UE, entré en vigueur en 2024, étend des exigences similaires largement aux produits logiciels vendus sur le marché européen. En 2026, produire et consommer des SBOMs devient rapidement une pratique d’ingénierie standard dans les organisations qui prennent au sérieux le risque lié à la chaîne d’approvisionnement, et non plus simplement une case à cocher pour la conformité.

Les deux formats de SBOM dominants sont SPDX (maintenu par la Linux Foundation) et CycloneDX (maintenu par l’OWASP). La plupart des grands outils de construction et plateformes CI/CD disposent désormais de plugins ou d’un support natif pour générer automatiquement des SBOMs dans le cadre du processus de construction. Le travail difficile n’est pas de générer le SBOM — c’est de l’opérationnaliser : intégrer les données SBOM dans les workflows de gestion des vulnérabilités pour que, lorsqu’un nouveau CVE apparaît dans une dépendance transitive, les équipes d’ingénierie reçoivent des alertes exploitables plutôt que du bruit générique des scanners.

Confiance des Conteneurs et le Modèle de Sécurité des Registres

Les conteneurs sont devenus l’unité dominante d’emballage et de déploiement logiciel. Les images de conteneurs sont elles-mêmes des artefacts de la chaîne d’approvisionnement : un Dockerfile référence une image de base depuis un registre, qui a été construite à partir de code source, qui tire ses propres dépendances. Chaque couche est une surface d’attaque potentielle.

La réponse a été un renforcement des registres de conteneurs et des workflows qui les entourent. Cosign, partie du projet Sigstore, permet de signer des images de conteneurs et de stocker leurs signatures dans un registre compatible OCI. Des outils d’application de politiques comme Kyverno et OPA/Gatekeeper permettent aux clusters Kubernetes de rejeter des images de conteneurs non signées ou non attestées au moment de l’admission — empêchant les images non vérifiées de s’exécuter en production, quoi que les développeurs ou les systèmes automatisés tentent de déployer.

Le concept de « constructeur de confiance » — un environnement CI/CD éphémère, isolé et auditable qui produit des artefacts signés avec une provenance enregistrée — est passé de bonne pratique théorique à exigence opérationnelle dans les environnements à haute sécurité. La pile de sécurité de la chaîne d’approvisionnement devient de l’infrastructure : invisible quand elle fonctionne correctement, catastrophique quand elle est absente.

Sources et lectures complémentaires

• Framework SLSA — Documentation Officielle (OpenSSF)
• Sigstore — Signature Logicielle Gratuite pour Tous
• État de la Chaîne d’Approvisionnement Logicielle — Sonatype
• Sécuriser la Chaîne d’Approvisionnement Logicielle — CISA
• S2C2F : Framework de Consommation Sécurisée de la Chaîne d’Approvisionnement — OpenSSF
• Décret Exécutif sur la Cybersécurité & Exigences SBOM — NIST