Sécurité de la chaîne d’approvisionnement logicielle

Pourquoi les dépendances sont une surface d’attaque

L’essentiel du code d’un service moderne n’a pas été écrit par l’équipe qui l’exploite. Un petit service web peut déclarer vingt dépendances directes et, par le jeu de leurs propres dépendances, installer plusieurs centaines de paquets ; le conteneur dans lequel il est livré ajoute l’espace utilisateur d’un système d’exploitation, et le pipeline qui le construit exécute des compilateurs, des plug-ins et des actions de CI écrits par d’autres personnes encore. La section 0.3 a présenté les dépendances comme une économie d’effort assortie d’un coût de maintenance. Cette section s’intéresse à leur coût en matière de sécurité : chacun de ces composants, et chaque personne ou système capable de les modifier, fait partie de votre surface d’attaque.

Une attaque de la chaîne d’approvisionnement logicielle compromet quelque chose que vous consommez afin de vous atteindre, généralement en touchant de nombreuses victimes à la fois. Elle peut arriver par quatre grandes voies. Du code malveillant provenant d’une source de confiance : le compte d’un mainteneur est piraté par hameçonnage, un mainteneur devient hostile, ou un projet est confié à un inconnu. Des imitations malveillantes : le typosquatting publie reqeusts à côté de requests ; la dependency confusion (confusion de dépendances), démontrée par Alex Birsan en février 2021, publie sur le registre public un paquet portant le même nom que le paquet interne d’une entreprise et un numéro de version plus élevé, que certains outils de build préfèrent alors. Une altération dans le pipeline : le code source est sain, mais le système de build, les clés de signature ou le registre sont compromis. Des vulnérabilités involontaires : aucun attaquant n’a participé à l’écriture du code, mais un bogue grave dans une dépendance transitive très utilisée expose tous ceux qui la livrent.

Les dernières années ont montré à quelle vitesse la première voie se propage. En mars 2025, les tags de version d’une GitHub Action populaire, tj-actions/changed-files, ont été déplacés vers un commit malveillant qui affichait les secrets de CI dans les journaux de build, touchant des milliers de dépôts qui référençaient l’action par tag. En septembre 2025, un mainteneur de paquets npm très utilisés comme chalk et debug a été piégé par hameçonnage au moyen d’un faux site de support npm, et des versions malveillantes ont été publiées puis retirées en quelques heures ; plus tard le même mois, un ver auto-propagateur, surnommé Shai-Hulud, a volé des jetons npm et s’en est servi pour publier des versions infectées d’autres paquets.

Quatre incidents, racontés avec exactitude

event-stream (2018). event-stream était un paquet npm populaire, téléchargé environ deux millions de fois par semaine, dont l’auteur d’origine n’avait plus le temps de s’occuper. En septembre 2018, il a cédé les droits de publication à un bénévole qui avait proposé son aide. Le nouveau mainteneur a ajouté une dépendance, flatmap-stream, dont le paquet publié contenait une charge utile chiffrée qui ne s’activait que dans le build de Copay, une application de portefeuille bitcoin, et tentait de voler les portefeuilles aux soldes importants. Un développeur a remarqué le code suspect en novembre 2018. Rien dans le modèle de npm n’avait été cassé : un nom de confiance avait simplement changé de mains.

SolarWinds (2020). Des attaquants, attribués plus tard par le gouvernement américain au service de renseignement extérieur russe, ont obtenu l’accès à l’environnement de build de SolarWinds, l’éditeur du produit de gestion de réseau Orion. Un implant (baptisé SUNSPOT par les enquêteurs) surveillait les builds d’Orion et remplaçait pendant la compilation un fichier source par une version dotée d’une porte dérobée, puis remettait l’original en place. Les mises à jour qui en résultaient, publiées entre mars et juin 2020, étaient construites par le propre pipeline de SolarWinds et signées avec son certificat authentique. Environ 18 000 clients les ont installées ; les attaquants ont ensuite choisi un nombre bien plus restreint d’agences gouvernementales et d’entreprises pour poursuivre l’intrusion. FireEye a découvert la campagne en décembre 2020 en enquêtant sur sa propre violation. La leçon pour les architectes : une signature prouve qui a construit quelque chose, pas que le build était sain.

Log4Shell (2021). La CVE-2021-44228, divulguée le 9 décembre 2021 et notée 10,0 selon le CVSS, était une faille de Log4j 2, la bibliothèque de journalisation Java dominante. Log4j résolvait les lookups écrits dans les messages de journal, y compris les lookups JNDI capables de charger une classe depuis un serveur distant ; un attaquant capable de faire journaliser une chaîne, comme un nom d’utilisateur ou un en-tête de requête, pouvait donc exécuter du code sur le serveur. Aucun attaquant n’avait touché à la chaîne d’approvisionnement ; les dégâts venaient de l’ampleur et de la profondeur avec lesquelles la bibliothèque était intégrée. Les organisations ont passé des semaines à trouver où elles l’utilisaient, plusieurs versions correctives successives ont été nécessaires pour combler des failles apparentées, et celles qui disposaient d’un inventaire exact ont répondu à la question en quelques heures.

xz utils (2024). xz est une bibliothèque de compression utilisée, par l’intermédiaire d’autres bibliothèques, par le serveur OpenSSH sur plusieurs distributions Linux. Pendant environ deux ans, un compte nommé Jia Tan a apporté des contributions utiles et, aidé par d’autres comptes qui pressaient le mainteneur d’origine, débordé, d’accepter de l’aide, est devenu co-mainteneur. Les versions 5.6.0 et 5.6.1, publiées en février et mars 2024, contenaient une porte dérobée qui aurait permis au détenteur d’une clé privée précise d’exécuter des commandes via SSH. Le code malveillant était caché dans des fichiers de test binaires et activé par un script de build modifié qui n’existait que dans les tarballs de publication, pas dans le dépôt public. Le 29 mars 2024, Andres Freund, développeur chez Microsoft, l’a révélé après avoir cherché pourquoi les connexions SSH sur un système de test consommaient un temps processeur inhabituel et prenaient environ une demi-seconde de plus ; la faille a été suivie sous la référence CVE-2024-3094. Comme elle a été détectée tôt, elle n’avait atteint pour l’essentiel que des distributions de développement et en publication continue (rolling release), et non des distributions stables.

Les nomenclatures logicielles

Une nomenclature logicielle (SBOM, software bill of materials) est une liste lisible par machine des composants d’un logiciel, avec leurs versions, leurs identifiants et les relations entre eux. Elle ne rend pas le logiciel plus sûr à elle seule ; elle permet de répondre aux questions. Quand le prochain Log4Shell est annoncé, un stockage interrogeable des SBOM de chaque artefact déployé transforme sommes-nous touchés, et où ? en une simple requête.

Deux formats dominent. SPDX, de la Linux Foundation, est né comme format de conformité des licences ; sa version 2.2.1 est la norme internationale ISO/IEC 5962:2021, et SPDX 3.0 (2024) ajoute des profils pour la sécurité, les builds et l’IA. CycloneDX, un projet OWASP conçu pour les cas d’usage de sécurité, est normalisé par Ecma International sous la référence ECMA-424 ; la version 1.7 est sortie en octobre 2025. Les deux peuvent identifier les composants par une package URL (purl), comme pkg:npm/express@4.21.2, ce sur quoi s’appuient les bases de données de vulnérabilités pour leurs correspondances. L’idée complémentaire de VEX (Vulnerability Exploitability eXchange) permet à un fournisseur d’indiquer qu’un composant vulnérable listé n’est pas exploitable dans son produit, par exemple parce que la fonction vulnérable n’est jamais appelée, ce qui réduit le bruit pour les clients.

Les pouvoirs publics ont fait entrer les SBOM dans les pratiques courantes. Le décret présidentiel américain 14028, Improving the Nation’s Cybersecurity, signé le 12 mai 2021, a défini des mesures relatives à la chaîne d’approvisionnement logicielle pour les logiciels vendus à l’administration fédérale, dont la fourniture d’une SBOM aux acheteurs ; la National Telecommunications and Information Administration a ensuite publié les éléments minimaux d’une SBOM (fournisseur, nom du composant, version, autres identifiants uniques, relations de dépendance, auteur des données de la SBOM et horodatage). La politique américaine s’est depuis éloignée des obligations uniformes : en janvier 2026, le mémorandum M-26-05 de l’Office of Management and Budget a abrogé l’obligation antérieure faite aux fournisseurs d’attester de pratiques de développement sécurisé, laissant les agences fixer des exigences fondées sur les risques et demander des SBOM lorsqu’elles le jugent utile. Dans l’UE, le règlement sur la cyberrésilience, décrit plus loin, fait de la nomenclature des logiciels (SBOM) un élément de la documentation technique des produits comportant des éléments numériques.

Générez les SBOM pendant le build, à partir de ce qui a réellement été résolu et empaqueté, plutôt qu’à partir du manifeste écrit par un développeur ; stockez-les avec l’artefact, indexées par son digest ; et transmettez-les à un service qui revérifie chaque SBOM stockée lorsqu’une nouvelle vulnérabilité est publiée.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {"timestamp": "2026-10-20T09:14:02Z",
               "component": {"bom-ref": "orders-service", "type": "application",
                             "name": "orders-service", "version": "4.12.0"}},
  "components": [
    {"bom-ref": "log4j-core", "type": "library", "name": "log4j-core",
     "group": "org.apache.logging.log4j", "version": "2.24.3",
     "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.24.3",
     "hashes": [{"alg": "SHA-256", "content": "9f2c..."}]},
    {"bom-ref": "jackson-databind", "type": "library", "name": "jackson-databind",
     "version": "2.18.2",
     "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.2"}
  ],
  "dependencies": [
    {"ref": "orders-service", "dependsOn": ["log4j-core", "jackson-databind"]}
  ]
}

SLSA : des niveaux pour l’intégrité du build

SLSA (Supply-chain Levels for Software Artifacts, prononcé salsa) est un cadre, aujourd’hui maintenu au sein de l’Open Source Security Foundation, qui décrit des niveaux progressifs de protection contre les altérations. La version 1.0 (2023) définissait une piste Build ; la version 1.2 a restructuré la spécification en plusieurs pistes et ajouté une piste Source. L’élément central est la provenance : une déclaration signée, généralement au format d’attestation in-toto, indiquant quelle plateforme de build a produit un artefact, à partir de quelle révision du code source, avec quelle définition de build et quels paramètres. Un consommateur vérifie la provenance par rapport à des attentes comme construit par notre CI à partir de la branche main de github.com/fooddelivery/orders.

La piste Source comporte quatre niveaux : gestion de versions (L1), historique continu et immuable avec une provenance pour chaque révision (L2), contrôles techniques appliqués en continu, comme les branches protégées (L3), et revue par deux personnes de chaque modification des branches protégées (L4). Pour la plupart des organisations, la cible réaliste est Build L3 sur une plateforme de build partagée et bien gérée, plus Source L3 ou L4 pour les dépôts importants ; les niveaux disent ce qu’une plateforme doit garantir, et une équipe plateforme peut les atteindre une fois pour tous les services.

Signature et provenance avec Sigstore

Signer les artefacts est possible depuis longtemps, mais la gestion de clés de signature à longue durée de vie était si contraignante que peu de projets open source le faisaient, et les clés volées constituaient elles-mêmes un risque. Sigstore, lancé en 2021 et désormais rattaché à l’Open Source Security Foundation, rend la signature peu coûteuse grâce à la signature sans clé (keyless). Un job de CI prouve son identité à Fulcio, l’autorité de certification de Sigstore, avec un jeton OpenID Connect ; Fulcio émet un certificat valable quelques minutes qui nomme cette identité, par exemple un workflow précis dans un dépôt précis ; l’outil signe l’artefact et inscrit la signature dans Rekor, un journal de transparence public en ajout seul ; la clé privée éphémère est ensuite détruite. Les vérificateurs contrôlent la signature, l’identité figurant dans le certificat et l’entrée du journal, au lieu de faire confiance à une clé qui aurait pu fuiter.

L’outil cosign applique ce principe aux images de conteneur et à d’autres artefacts, et les écosystèmes de paquets ont adopté les mêmes idées : npm peut publier des paquets avec des déclarations de provenance qui les relient au dépôt source et au build (2023), et PyPI prend en charge la publication de confiance (trusted publishing) depuis la CI sans jetons à longue durée de vie (2023) et des attestations fondées sur Sigstore (2024). Au déploiement, un contrôleur d’admission dans Kubernetes, comme le policy controller de Sigstore ou Kyverno, peut refuser toute image qui n’est pas signée par l’identité attendue ou qui n’a pas la provenance attendue. Souvenez-vous de SolarWinds : la signature et la provenance prouvent d’où vient quelque chose ; seuls l’isolation du build, la revue et la détection rendent fiable ce qui en sort.

Lockfiles, épinglage et mises à jour automatisées

Un manifeste comme package.json ou pyproject.toml indique des plages de versions acceptables ; un lockfile (fichier de verrouillage : package-lock.json, poetry.lock, uv.lock, go.sum, Cargo.lock) enregistre les versions exactes résolues, généralement avec une empreinte cryptographique de chacune. Commiter le lockfile et installer à partir de lui en CI (npm ci, pip install --require-hashes) garantit que chaque build utilise les mêmes octets relus, et qu’un paquet republié avec un contenu différent échoue à la vérification d’empreinte. L’épinglage s’applique aussi à l’outillage de build : référencez les actions de CI par leur empreinte de commit complète, et non par un tag que leur propriétaire, ou un attaquant, peut déplacer, ce qui est précisément ce qui a permis à l’incident tj-actions de se propager ; référencez les images de base par digest.

Épingler sans mettre à jour crée le risque inverse : les anciennes versions accumulent les vulnérabilités connues et les montées de version deviennent trop lourdes pour être tentées. Des bots de mise à jour comme Dependabot et Renovate ouvrent de petites pull requests fréquentes que la CI teste automatiquement. Un raffinement utile est un âge minimal de publication : attendre quelques jours avant d’adopter une nouvelle version de routine, car la plupart des versions malveillantes sont détectées et retirées en quelques heures ou quelques jours ; les correctifs de sécurité en sont exemptés et passent en priorité.

Les outils d’analyse de la composition logicielle (SCA), comme OWASP Dependency-Check, Trivy, Grype ou des services commerciaux, confrontent vos dépendances aux bases de données de vulnérabilités. Leur faiblesse est le bruit : des centaines de résultats, pour la plupart dans des chemins de code que vous n’appelez jamais. Priorisez à l’aide des données d’exploitation (la vulnérabilité figure-t-elle dans le catalogue Known Exploited Vulnerabilities de la CISA, quel est son score EPSS ?), de l’analyse d’atteignabilité quand vos outils la proposent, et de l’exposition (le service est-il exposé à internet ?). La section 8.8 traite de la gestion des vulnérabilités en tant que processus.

Conteneurs et intégrité du build

Une image de conteneur embarque l’espace utilisateur d’un système d’exploitation en plus de votre code, et chaque paquet qu’elle contient fait partie de la chaîne d’approvisionnement. Partez d’images de base minimales (distroless, Alpine ou images de distribution allégées), qui contiennent moins de paquets susceptibles d’être vulnérables ; reconstruisez les images régulièrement pour que les correctifs de l’image de base arrivent même quand votre code n’a pas changé ; analysez les images en CI, puis en continu dans le registre, car de nouvelles vulnérabilités visant d’anciennes images sont publiées chaque jour ; et déployez les images par digest, pour que ce qui a été analysé soit bien ce qui s’exécute.

Le système de build est la cible la plus précieuse de la chaîne, car il touche à tout, comme l’a montré SolarWinds. Exécutez les builds sur des runners éphémères, créés pour un seul job et détruits ensuite, afin qu’un attaquant ne puisse pas persister d’un build à l’autre. Rendez les builds hermétiques, avec toutes leurs entrées déclarées et récupérées par empreinte, et sans accès réseau pendant la compilation, pour qu’aucune entrée non déclarée ne puisse s’y glisser. Tenez les secrets à longue durée de vie à l’écart de la CI en utilisant la fédération OIDC pour obtenir des identifiants cloud à courte durée de vie pour chaque job, et donnez à chaque pipeline le moindre privilège dont il a besoin, afin qu’une pull request issue d’un fork ne puisse pas atteindre les identifiants de déploiement. Protégez le chemin de mise en production par la protection des branches et une revue par deux personnes. Enfin, les builds reproductibles, où le même code source produit toujours un résultat identique au bit près, permettent à des parties indépendantes de reconstruire et de comparer ; le projet Reproducible Builds et des distributions comme Debian ont rendu reproductibles la plupart de leurs paquets, et une divergence est un indice sérieux d’altération.

Le règlement européen sur la cyberrésilience

Le règlement sur la cyberrésilience (Cyber Resilience Act, CRA), règlement (UE) 2024/2847, fixe des exigences horizontales de cybersécurité pour les produits comportant des éléments numériques mis à disposition sur le marché de l’UE : produits matériels et logiciels, y compris leurs solutions de traitement de données à distance. Il est entré en vigueur le 10 décembre 2024 et s’applique par étapes. Les règles relatives à la notification des organismes d’évaluation de la conformité s’appliquent à partir du 11 juin 2026. Les obligations de signalement de l’article 14 s’appliquent à partir du 11 septembre 2026 : un fabricant doit signaler toute vulnérabilité activement exploitée ou tout incident grave ayant des répercussions sur la sécurité de son produit, par une alerte précoce au plus tard 24 heures après en avoir pris connaissance, une notification plus complète au plus tard 72 heures après, puis un rapport final (pour une vulnérabilité, au plus tard 14 jours après la mise à disposition d’une mesure de correction ; pour un incident grave, dans un délai d’un mois), via la plateforme unique de signalement gérée par l’ENISA, l’agence de l’Union européenne pour la cybersécurité. La plupart des autres obligations s’appliquent à partir du 11 décembre 2027.

Les exigences essentielles de l’annexe I relèvent autant de l’architecture que de la procédure : les produits doivent être conçus avec un niveau de sécurité approprié, mis à disposition avec une configuration sécurisée par défaut, limiter les surfaces d’attaque, protéger la confidentialité et l’intégrité des données, minimiser les données, et pouvoir enregistrer les événements de sécurité et recevoir des mises à jour de sécurité. Les fabricants doivent recenser et documenter les composants, notamment en établissant une nomenclature des logiciels (SBOM) couvrant au moins les dépendances de premier niveau, traiter les vulnérabilités au moyen d’une politique de divulgation coordonnée des vulnérabilités, et fournir des mises à jour de sécurité pendant une période d’assistance qui devrait normalement être d’au moins cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Les amendes pour manquement aux exigences essentielles ou aux obligations des fabricants peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu.

Le champ d’application est déterminant. Les logiciels libres et ouverts développés ou fournis en dehors d’une activité commerciale ne relèvent pas du CRA, et un régime allégé s’applique aux intendants de logiciels ouverts qui soutiennent de tels logiciels destinés à un usage commercial. Le logiciel purement en tant que service (SaaS) échappe généralement au CRA, sauf s’il constitue la solution de traitement de données à distance d’un produit ; les fournisseurs de services cloud et d’autres services numériques peuvent relever plutôt de la directive SRI 2 (NIS2). Savoir si un produit donné entre dans le champ d’application, et quelle procédure d’évaluation de la conformité s’applique, est une question juridique propre à chaque organisation ; la conséquence pour l’architecture est que les SBOM, le traitement des vulnérabilités, les mécanismes de mise à jour et la journalisation de sécurité deviennent des preuves qui doivent exister, et non de bonnes intentions.