Sécurité de la supply chain logicielle

En mars 2024, un développeur curieux remarque que sa connexion SSH prend 500 ms de plus que d'habitude. En creusant, il découvre une backdoor planquée dans XZ Utils, un utilitaire de compression présent sur quasiment tous les serveurs Linux. Le code malveillant permettait une exécution de code à distance via SSH. Cette attaque sophistiquée a été préparée pendant deux ans par un contributeur devenu mainteneur du projet.

Bienvenue dans le monde des attaques supply chain : l'attaquant ne cible plus directement votre application, il compromet un composant en amont pour toucher tous ceux qui en dépendent.

Passer à l'action

Cette page explique les menaces. Pour un parcours pratique étape par étape, consultez Par où commencer.

Ce que vous allez apprendre

• Reconnaître les six portes d'entrée d'une attaque supply chain et le périmètre réel à protéger.
• Situer les quatre couches de responsabilité et la progression R1, R2, R3.
• Expliquer pourquoi ces attaques fonctionnent et qui les mène.
• Retenir les attaques marquantes de 2024-2025 et les erreurs qu'elles révèlent.
• Repérer quelle leçon du module traite quel maillon de la chaîne.

Qu'est-ce qu'une attaque supply chain ?

Une attaque supply chain cible les composants utilisés pour construire un logiciel plutôt que le logiciel lui-même. L'idée est simple : compromettre un composant utilisé par 10 000 projets, c'est compromettre potentiellement 10 000 projets d'un coup.

Les 6 vecteurs d'attaque

Le schéma rassemble les six portes d'entrée qui mènent toutes à votre application : aucune ne passe par votre propre code, toutes passent par ce que vous consommez.

Exemples réels : SolarWinds (CI/CD), event-stream (mainteneur), ua-parser-js (npm), Codecov (script d'upload bash). Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Les attaquants exploitent six portes d'entrée principales :

1. Typosquatting : L'attaquant publie un package au nom quasi identique (lodahs au lieu de lodash). Une faute de frappe lors de l'installation suffit à compromettre votre projet.

2. Dependency confusion : Votre organisation utilise un package privé nommé auth-utils sur son registre interne. L'attaquant publie auth-utils sur npm public en version 99.0.0. Certains gestionnaires de paquets privilégient le registre public.

3. Maintainer compromis : Un mainteneur épuisé abandonne son projet. L'attaquant le reprend, gagne la confiance de la communauté, puis injecte du code malveillant dans une mise à jour anodine.

4. CI/CD compromis : Les pipelines ont accès aux secrets et peuvent modifier le code déployé. Une action GitHub modifiée peut exfiltrer vos tokens ou injecter du code dans vos artefacts.

5. Vulnérabilités connues : Des CVE non patchées dans vos dépendances (Log4Shell, XZ Utils) offrent des portes ouvertes aux attaquants.

6. Images non signées : Sans signature, impossible de détecter si une image Docker a été modifiée entre sa création et son déploiement.

Le modèle complet par familles

Ces six portes d'entrée sont une vue d'ensemble. Pour le modèle exhaustif structuré en familles (du producteur au cloud), avec les vecteurs ancrés et les exemples réels, voyez Menaces par familles.

Le périmètre réel : bien plus que les artefacts

Les 6 vecteurs ci-dessus ciblent surtout les composants et les pipelines. Mais sécuriser la supply chain, c'est couvrir tout le chemin du code à la production : le poste du développeur, la source, le build, les runners, la release, le déploiement, le runtime, les secrets, les fournisseurs, l'IA et le cloud. C'est le périmètre que structure la démarche SOCLE en 14 domaines, regroupés en cinq zones.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Signer et tracer les artefacts (SLSA, le cadre de niveaux de sécurité du build, SBOM, la liste des composants livrés, et signature) reste essentiel, mais ne couvre qu'une partie de ce périmètre : un mainteneur malveillant, un poste compromis ou un secret fuité passent sous le radar de la provenance. Le référentiel SOCLE détaille les exigences de chaque domaine, et le modèle de menaces par familles montre où frappe l'attaquant à chaque étape.

Les 4 couches de la supply chain

Une lecture complémentaire, par responsabilité, aide à répartir l'effort entre les équipes :

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Couche	Ce qu'elle contient	Exemples de risques	Qui gère
1. Composants OSS	Dépendances npm, PyPI, Maven, images de base	Typosquatting, maintainer takeover, CVE	Développeurs
2. Pipeline/Build	CI/CD, runners, scripts de build, caches	Secrets exfiltrés, actions compromises	DevOps/SRE
3. Artefacts/Runtime	Images déployées, binaires, registres	Manipulation post-build, registre compromis	Ops/Sécurité
4. Tiers/Fournisseurs	SaaS, infogérants, APIs externes	Fournisseur compromis, données exposées	RSSI/Achats

Glissez pour voir

L'angle mort des tiers

La plupart des programmes de sécurité supply chain s'arrêtent aux couches 1-2. Or, un fournisseur SaaS compromis ou un infogérant négligent peut annuler tous vos efforts sur le code. C'est le sujet du TPRM (Third Party Risk Management).

Monter en maturité : R1, R2, R3

Personne ne sécurise les 14 domaines d'un coup. La démarche hiérarchise l'effort en trois niveaux de robustesse : on vise R1 partout (l'hygiène atteignable), R2 en production, R3 sur le sensible. C'est cette progression, pas une course à l'exhaustivité, qui guide la montée en maturité.

Chaque niveau ajoute des exigences : on vise R1 partout, R2 en production, R3 sur le sensible. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Chaque niveau s'applique à chaque domaine : un domaine peut être à R1 pendant qu'un autre vise R3. Les niveaux exacts par exigence sont dans le référentiel SOCLE.

Le cycle des preuves : SLSA, SBOM, signature

Au sein de ce périmètre, un cycle outillé structure la génération et la vérification des preuves sur les artefacts. C'est le cœur du monde SLSA, et un excellent point d'entrée pratique, à condition de se rappeler qu'il ne couvre qu'une partie du périmètre.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Étape	Question clé	Outils/standards	En savoir plus
Inventorier	Qu'est-ce que j'utilise ?	SBOM, OBOM, Syft	SBOM, XBOM
Signer	D'où ça vient ?	Sigstore, Cosign, Gitsign	Sigstore
Vérifier	Est-ce conforme ?	SLSA, Kyverno, Kusari	SLSA, Kusari
Gouverner	Qui valide, révise, conserve ?	VEX, GUAC, workflows	VEX, GUAC
Contractualiser	Mes tiers respectent-ils ça ?	CRA, NIS2, TPRM, clauses	CRA, TPRM

Glissez pour voir

Par où commencer ?

Ne cherchez pas à tout faire d'un coup. Le guide Par où commencer propose un parcours en 4 niveaux adaptés à votre maturité actuelle.

Pourquoi ces attaques fonctionnent

Les attaques supply chain exploitent des faiblesses structurelles de notre écosystème logiciel.

La confiance implicite est le cœur du problème. Quand vous tapez npm install, vous faites confiance à des centaines de mainteneurs que vous ne connaissez pas. Personne ne lit le code des 500 dépendances transitives avant de les installer.

L'effet de levier est considérable. Compromettre un seul package populaire comme lodash touche potentiellement des millions de projets. C'est bien plus rentable que d'attaquer une entreprise à la fois.

La détection est un cauchemar. Le code malveillant vient d'une source "légitime" : un mainteneur de confiance, un registre officiel. Il passe les revues de code parce que personne ne soupçonne une mise à jour mineure.

La surface d'attaque est immense. Un projet moderne embarque des centaines de composants tiers. Chacun est un point d'entrée potentiel. Et les dépendances ont elles-mêmes des dépendances.

Les attaquants jouent le temps long. L'attaquant de XZ Utils a contribué pendant deux ans avant d'injecter sa backdoor. Cette patience rend la menace quasi indétectable.

Menace persistante

Contrairement aux attaques classiques où l'urgence prime, les attaques supply chain sont patiemment préparées. L'attaquant investit des mois, voire des années, pour maximiser l'impact au moment opportun.

Qui attaque et pourquoi

Les profils d'attaquants

Les attaques supply chain attirent des acteurs variés, des opportunistes aux services de renseignement.

Les États-nations mènent souvent les attaques les plus sophistiquées. L'attaque XZ Utils présente les caractéristiques que beaucoup d'analystes associent à une opération étatique (deux ans de préparation, code obfusqué, ciblage de l'infrastructure SSH), sans attribution officielle. L'objectif ? Espionnage, sabotage, ou création d'accès persistants pour des opérations futures.

Les groupes criminels cherchent le profit direct. Un ver comme Shai-Hulud collecte des secrets (tokens npm et GitHub, clés cloud) que l'on peut revendre ou réutiliser. D'autres déploient du cryptomining ou préparent des ransomwares.

Les hacktivistes utilisent le "protestware" pour faire passer des messages politiques. En 2022, le mainteneur de node-ipc a saboté son propre package pour protester contre l'invasion de l'Ukraine, effaçant des fichiers sur les machines russes.

Les opportunistes exploitent le typosquatting à grande échelle. Ils publient des milliers de packages aux noms similaires à des packages populaires, espérant capturer des tokens d'authentification ou des variables d'environnement.

Ce qu'ils cherchent

Quel que soit l'attaquant, les objectifs se recoupent : credentials (tokens API, clés SSH), accès persistants (backdoors pour revenir), données sensibles (code source, secrets métier), ressources de calcul (cryptomining), et points de pivot pour attaquer d'autres cibles depuis votre infrastructure.

Comment ils attaquent

1. Empoisonnement de dépendances

L'attaquant publie un package malveillant qui ressemble à un package légitime.

Typosquatting : un nom proche qui piège les fautes de frappe.

npm install lodahs    # ❌ Malveillant (faute de frappe)
npm install lodash    # Légitime

Dependency confusion : un package public avec le nom d'un package privé interne. Les gestionnaires de paquets privilégient souvent le registre public. Réserver son scope (@company/) sur le registre public ferme cette porte pour les paquets scopés ; les noms sans scope restent exposés.

# Votre package privé interne (registre interne, nom sans scope)
auth-utils

# L'attaquant publie le même nom sur npm public
auth-utils  # Version 99.0.0, peut être installée à la place

Maintainer takeover : reprise d'un package abandonné, puis injection de code malveillant lors d'une mise à jour anodine. Le mainteneur original a souvent disparu, personne ne vérifie.

2. Compromission des pipelines CI/CD

Les pipelines ont accès aux secrets et peuvent modifier le code déployé.

Actions GitHub compromises : une action modifiée exfiltre les secrets ou injecte du code dans les artefacts. C'est ce qui s'est passé avec tj-actions/changed-files en mars 2025.

Secrets dans les logs : un script malveillant affiche les variables sensibles dans les logs publics. Le code injecté ressemblait à echo "::debug::$NPM_TOKEN", une ligne anodine qui exfiltrait les secrets vers les logs accessibles publiquement.

Runners partagés : sur des runners mutualisés, un job malveillant peut accéder aux données des jobs précédents (artefacts, cache, fichiers temp).

3. Attaques sur les registres

Compromission de comptes mainteneurs : sans 2FA, un simple phishing suffit à publier une version malveillante d'un package populaire.

Failles des registres : vulnérabilités permettant de modifier des packages sans authentification. Rare mais dévastateur.

4. Compromission d'infrastructure tierce

Rachat de domaines : un domaine ou un service légitime est racheté par une entité malveillante. C'est ce qui s'est passé avec Polyfill.io, racheté début 2024 et accusé en juin 2024 de servir du code malveillant à plus de 100 000 sites selon Sansec, un chiffre dont l'ampleur réelle reste discutée.

CDN compromis : injection de code dans tous les fichiers distribués. Un changement sur le CDN touche instantanément tous les consommateurs.

Qui est concerné dans votre organisation

La sécurité supply chain n'est pas qu'un problème technique, elle implique toute l'organisation.

Les développeurs sont en première ligne. Chaque npm install, chaque nouvelle dépendance ajoutée au projet est une décision de sécurité. Les scripts postinstall s'exécutent sur leur machine avec leurs droits.

Les DevOps et SRE contrôlent l'un des vecteurs les plus exposés : les pipelines CI/CD. Ils gèrent les secrets, les runners, les accès aux registres. Une erreur de configuration peut exposer tous les tokens de l'organisation.

Les architectes définissent les règles : quelles dépendances autoriser, quels registres utiliser, quelle surface d'attaque accepter. Leurs décisions structurent la posture de sécurité pour des années.

Le RSSI porte la responsabilité de la gouvernance. Avec le CRA, dont les obligations de signalement s'appliquent depuis le 11 septembre 2026, il doit s'assurer que les processus sont en place : SBOM, évaluation des risques fournisseurs, notification d'incidents.

Le juridique entre dans la boucle avec les nouvelles réglementations. Les contrats clients exigent des SBOM, le CRA impose des obligations de conformité. Les sanctions peuvent atteindre 15 M€.

Les attaques marquantes 2024-2025

XZ Utils Backdoor (mars 2024)

CVE-2024-3094 : l'une des attaques supply chain les plus sophistiquées jamais documentées.

Un contributeur nommé "Jia Tan" a gagné la confiance du mainteneur pendant deux ans. Il a introduit du code malveillant dans les versions 5.6.0 et 5.6.1 de liblzma. La backdoor modifiait sshd pour permettre une exécution de code à distance.

Impact potentiel : exécution de code à distance sur les systèmes qui embarquaient ces versions de liblzma, là où sshd y était lié indirectement par systemd (cas de certaines distributions). Les versions stables des grandes distributions n'avaient, pour l'essentiel, pas encore reçu ces versions.

Leçons de XZ Utils

• La confiance open source repose sur peu de mainteneurs souvent épuisés
• Les attaques peuvent être préparées sur le très long terme
• Un comportement anormal (500 ms de latence) peut révéler une compromission
• Le code malveillant était caché dans les fichiers de test, pas dans le code principal

Polyfill.io CDN (juin 2024)

Le domaine polyfill.io, utilisé par 100 000+ sites web selon Sansec (l'alerte date du 25 juin 2024), avait été racheté début 2024 par une société chinoise (Funnull). Le code servi a ensuite été modifié pour rediriger une partie des visiteurs vers des sites d'arnaque et de paris en ligne. D'autres estimations sont bien supérieures.

Leçons de Polyfill.io

• Les CDN tiers sont un vecteur sous-estimé
• Un changement de propriétaire peut transformer un service légitime en menace
• Auto-héberger les ressources critiques réduit la surface d'attaque
• Cloudflare et Fastly ont dû créer des miroirs d'urgence

tj-actions/changed-files (mars 2025)

CVE-2025-30066 : Compromission en cascade d'actions GitHub.

L'attaque a commencé par reviewdog/action-setup@v1, puis s'est propagée à tj-actions/changed-files. Les attaquants ont redirigé la plupart des tags de version vers un commit malveillant, pour exfiltrer les secrets CI/CD dans les logs. Le correctif est la version 46.0.1.

Impact : l'action était utilisée par plus de 23 000 dépôts, et plusieurs ont laissé fuiter des secrets dans leurs logs publics.

Leçons de tj-actions

• Les tags Git mutables (@v1) sont dangereux : un tag peut être modifié
• Toujours épingler sur un SHA immutable
• Une action compromise accède à tous les secrets du workflow
• Effet cascade : une action peut en compromettre d'autres

Shai-Hulud npm Worm (septembre-novembre 2025)

Un malware auto-réplicant a infecté des packages npm populaires. Lancé par un script postinstall, il collectait les credentials (tokens npm et GitHub, clés cloud). Avec un token de mainteneur, il s'auto-propageait en republiant les autres packages du compte.

Impact : plus de 500 packages touchés dans la première vague de septembre 2025 selon la CISA, puis une seconde vague en novembre 2025 (Shai-Hulud 2.0, exécutée dès le preinstall). Les décomptes varient selon les éditeurs.

Leçons de Shai-Hulud

• Les scripts postinstall et preinstall npm sont un vecteur majeur
• Un malware auto-réplicant peut se propager de package en package
• Les environnements de développement sont des cibles de choix
• La machine du développeur peut avoir plus d'accès que la production

Le contexte réglementaire

Face à la multiplication des attaques, les régulateurs passent à l'action.

Le Cyber Resilience Act européen (2026-2027)

Le CRA est le changement majeur à anticiper. Ses obligations de signalement s'appliquent depuis le 11 septembre 2026, et l'application complète arrive le 11 décembre 2027. Tout produit numérique vendu dans l'UE devra :

• Établir un SBOM (inventaire des composants) dans sa documentation technique, tenue à disposition des autorités de surveillance
• Être conçu "secure by design" avec documentation des choix de sécurité
• Proposer des mises à jour de sécurité pendant la période de support (cinq ans au minimum, sauf durée d'usage prévue plus courte)
• Notifier les vulnérabilités activement exploitées : alerte précoce sous 24 heures, puis notification sous 72 heures

Sanctions : jusqu'à 15 M€ ou 2,5% du chiffre d'affaires mondial (le montant le plus élevé), pour les manquements aux exigences essentielles.

NIS2 : déjà en vigueur

La directive NIS2 est en vigueur depuis janvier 2023, et les États membres devaient la transposer avant le 17 octobre 2024 : le calendrier réel dépend de la loi nationale. Les entités des secteurs critiques (énergie, santé, transport, finance...) doivent gérer les risques de leur chaîne d'approvisionnement et notifier les incidents importants : alerte précoce sous 24 h, puis notification sous 72 h. Les dirigeants portent une responsabilité dans l'approbation des mesures.

Aux États-Unis

L'Executive Order 14028 impose aux fournisseurs du gouvernement fédéral de produire des SBOM et d'attester leur conformité au NIST SSDF. Pas de conformité, pas de marché public.

Frameworks volontaires

Plusieurs référentiels guident les bonnes pratiques : SLSA (niveaux de provenance du build et de la source, via ses Build et Source Tracks), NIST SSDF (pratiques de développement sécurisé) et OpenSSF Scorecard (score 0-10 pour évaluer les projets open source avant adoption). La démarche SOCLE assemble ces référentiels en un profil unique, hiérarchisé par niveaux R1-R3.

Les erreurs qui coûtent cher

Erreurs critiques

Chaque attaque majeure révèle des erreurs évitables. Ces patterns se répètent systématiquement, les éviter réduit nettement la surface d'attaque.

Erreur	Conséquence	Incident
Tags mutables (@v1)	Compromission silencieuse	tj-actions 2025
Dépendances transitives ignorées	Vulnérabilité cachée	Log4Shell
Scripts postinstall non audités	Code arbitraire exécuté	Shai-Hulud
CDN tiers pour scripts	Injection de code	Polyfill.io
Un seul mainteneur	Takeover	XZ Utils
Secrets en variables CI	Exfiltration via logs	tj-actions

Glissez pour voir

Opérationnaliser : les 3 piliers d'exécution

Au-delà de la compréhension des menaces, trois domaines structurent votre posture opérationnelle supply chain. Ces piliers transforment les concepts (SLSA, SBOM, Sigstore) en contrôles bloquants et processus exécutables.

Le premier pilier est l'enforcement : rendre signatures et attestations obligatoires en CI/CD et à l'admission Kubernetes. Il s'appuie sur Kyverno pour l'admission et sur le pare-feu d'artefacts pour l'entrée des dépendances. Le deuxième est le durcissement du registre d'artefacts : immutabilité, RBAC, attachements OCI et rétention. Il n'a pas encore de guide dédié, seulement les bases dans Registres de conteneurs et Harbor. Le troisième, la réponse à incident, a le sien : Réagir à un incident supply chain déroule la portée, le confinement et les obligations de notification CRA et NIS2.

Programme end-to-end

Ces trois piliers complètent le parcours pratique en 4 niveaux. Ensemble, ils forment un programme complet : comprendre les menaces → construire les contrôles → imposer l'enforcement → réagir aux incidents.

La démarche SOCLE : un cadre pour tout le périmètre

Tout ce qui précède (menaces, couches, niveaux, preuves) s'assemble dans la démarche SOCLE, la norme ouverte qui couvre les 14 domaines sous un même axe menace, exigence, preuve, hiérarchisé par niveaux R1-R3. Plutôt qu'empiler des outils, on part d'exigences opposables et ancrées, et chaque outil (SLSA, Cosign, SBOM, OSV-Scanner) y répond.

• Le référentiel des exigences liste les exigences par domaine et par famille, avec leur niveau.
• Le modèle de menaces par familles cartographie les attaques, du producteur au cloud.

Que couvre chaque leçon du module ?

Ce module suit le trajet d'un logiciel, de la menace à la réponse à incident, et chaque leçon prend en charge un maillon. La vue d'ensemble que vous lisez est la première : elle donne le vocabulaire et les grandes attaques, les leçons suivantes les traitent une à une.

Le panorama des menaces (menaces par familles) classe les attaques du producteur au cloud, et la leçon sur le producteur malveillant détaille le cas où la source elle-même est hostile. Par où commencer propose ensuite un diagnostic et un parcours en quatre niveaux, puis la leçon supply chain security reprend, côté DevOps, les attaques réelles et les mesures de base (SBOM, SLSA, Sigstore, installation des dépendances) : elle s'appuie sur les mêmes attaques que cette page, mais sans son cadrage par couches et par niveaux SOCLE, et c'est cette page qui vous dit quelle leçon du module traite quel maillon. La leçon confiance transitive montre comment la confiance se propage de dépendance en dépendance.

La partie inventaire commence avec le SBOM, la liste des composants livrés. Le xBOM élargit l'idée aux autres inventaires, l'OBOM observe ce qui tourne réellement en production, et le VEX dit si une vulnérabilité listée est exploitable.

La partie preuve s'appuie sur la signature : l'écosystème Sigstore présente la signature sans clé, Fulcio délivre les certificats éphémères, Rekor tient le journal public qui rend ces signatures vérifiables après l'expiration du certificat, et Cosign signe et vérifie les images en orchestrant le tout. in-toto ajoute les attestations de build, que l'empoisonnement par variables d'environnement met à l'épreuve : une pipeline signée peut quand même être détournée de l'intérieur. La leçon sur la provenance SLSA aide ensuite à choisir un niveau réaliste.

La fin du module élargit la défense. Les attaques sur les gestionnaires de paquets montrent comment une dépendance piégée s'exécute en CI/CD, le pare-feu d'artefacts filtre les paquets entrants, le TPRM technique évalue les fournisseurs, et la réponse à incident déroule les gestes le jour où une compromission est avérée. Le lab guidé « build vérifiable » clôt le module par une pratique guidée.

À retenir

1. Une attaque supply chain cible ce que vous consommez, pas votre code : un composant amont compromis touche tous ses utilisateurs.
2. Le périmètre dépasse les artefacts : poste, source, build, release, runtime, secrets et fournisseurs comptent autant que la signature.
3. On monte en maturité par niveaux : R1 partout, R2 en production, R3 sur le sensible.
4. Les attaquants jouent le temps long et exploitent la confiance implicite (XZ Utils, Polyfill.io, tj-actions, Shai-Hulud).
5. Épinglez par SHA ou digest : un tag mutable laisse passer une compromission silencieuse.
6. La réglementation s'applique (NIS2 en vigueur, CRA : signalement depuis le 11 septembre 2026, application complète le 11 décembre 2027) et exige SBOM, évaluation des fournisseurs et notification d'incident.
7. Chaque leçon du module outille un maillon : inventaire, preuve, attaques et défenses, réponse à incident.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →