Supply chain attack

01 — DéfinitionQu'est-ce qu'une attaque supply chain ?

Une supply chain attack est une attaque cyber qui compromet une organisation indirectement, via un de ses fournisseurs, éditeurs logiciels, prestataires, composants open source ou partenaires. Au lieu d'attaquer directement la cible finale, l'attaquant s'introduit dans un maillon amont de confiance dont les accès ou produits sont ensuite utilisés pour atteindre multiples victimes.

Le concept est ancien — les services de renseignement pratiquent depuis longtemps l'interposition dans les chaînes d'approvisionnement matérielles (modification d'équipements en transit documentée notamment dans les révélations Snowden). Mais le passage à la sphère logicielle, combiné avec la dépendance massive des organisations modernes à des composants tiers, a fait émerger un risque systémique d'une ampleur inédite.

Mécanique générale

1. L'attaquant identifie un fournisseur ou composant amont largement utilisé.
2. Il compromet ce fournisseur ou prend le contrôle du composant (corruption, insertion de collaborateur, rachat, takeover de compte).
3. Il injecte sa charge dans les mises à jour, produits, services ou accès qui transitent vers les clients.
4. Les victimes finales reçoivent et exécutent le composant compromis, en faisant confiance à la source légitime.
5. L'attaquant active sa charge sur les cibles intéressantes (parfois seulement quelques-unes parmi des milliers d'infectées, pour rester discret).

Ce qui rend ces attaques redoutables

• Effet multiplicateur : une seule compromission touche des milliers ou dizaines de milliers de victimes.
• Confiance implicite : les composants amont sont installés et mis à jour sans inspection détaillée — c'est le principe même de leur utilisation.
• Signature légitime : les binaires malveillants sont signés par les certificats de l'éditeur compromis.
• Furtivité : les connexions sortantes sont masquées dans du trafic légitime, les comportements ressemblent à ceux du logiciel original.
• Temps de détection long : plusieurs mois en moyenne avant détection publique, comme SolarWinds (9 mois).
• Impact géopolitique : beaucoup d'attaques attribuées à des acteurs étatiques, enjeux diplomatiques forts.

Une supply chain attack retourne la défense en profondeur : les contrôles classiques — pare-feu, EDR, sensibilisation — supposent que les logiciels installés sont dignes de confiance. Quand cette hypothèse tombe, tout l'édifice vacille. Il faut donc ajouter des contrôles spécifiques au couche amont du logiciel, ce que les référentiels modernes commencent enfin à imposer.

02 — TypologiesLes grandes familles d'attaques

1. Compromission de mise à jour logicielle légitime

L'attaquant s'introduit dans l'infrastructure de build ou de distribution d'un éditeur logiciel et injecte du code malveillant dans une version officielle. Les clients qui installent la mise à jour reçoivent le malware avec la légitimité complète de l'éditeur.

Exemples : SolarWinds Orion (2020), 3CX Phone (2023), CCleaner (2017), ASUS Live Update (2019), MeDoc (2017, vecteur de NotPetya).

2. Compromission de bibliothèque open source

Plusieurs variantes :

• Injection dans un package existant : l'attaquant prend le contrôle d'un compte mainteneur et publie une version malveillante. Cas classique : event-stream (npm, 2018), ua-parser-js (npm, 2021), node-ipc (2022).
• Infiltration longue durée : un attaquant contribue au projet pendant des années pour gagner la confiance et obtenir les droits de mainteneur, puis injecte sa backdoor. Cas emblématique : XZ Utils (2024) — backdoor dans sshd découverte par hasard par un ingénieur Microsoft.
• Typosquatting : publication de packages aux noms voisins de packages populaires (colorss au lieu de colors).
• Dependency confusion : exploitation de la priorité des registries publics sur les registries internes pour injecter du code (technique décrite par Alex Birsan en 2021).

3. Compromission de prestataire avec accès privilégié

L'attaquant compromet un prestataire (MSP, MSSP, consultant, intégrateur) qui dispose d'accès légitimes et privilégiés à de nombreux clients. Une seule compromission ouvre l'accès aux systèmes de multiples victimes.

Exemples : Kaseya VSA (2021, MSPs à leur tour passerelles vers leurs clients), multiples attaques via prestataires RH, comptables, techniques.

4. Compromission d'infrastructure partagée

L'attaquant exploite une vulnérabilité dans une plateforme utilisée par de nombreuses organisations : éditeur SaaS, cloud provider, plateforme de transfert de fichiers.

Exemple phare : MOVEit Transfer (2023) — vulnérabilité 0day exploitée par Cl0p qui a touché plus de 2 700 organisations et 93 millions de personnes.

5. Compromission matérielle ou firmware

Moins fréquente dans le domaine civil public mais documentée :

• Modification de firmware de composants réseau ou stockage pendant la chaîne logistique.
• Attaques sur BMC (Baseboard Management Controllers) de serveurs.
• Compromissions d'appareils IoT lors de la fabrication.
• Enquête Supermicro de 2018 (contestée mais révélatrice des préoccupations).

6. Attaque par composant tiers dans une application

Log4Shell (CVE-2021-44228, décembre 2021) est l'exemple le plus spectaculaire. La bibliothèque de journalisation Java Log4j, présente dans des millions d'applications y compris celles de Minecraft, Apple, AWS, Cloudflare, contenait une vulnérabilité critique permettant l'exécution de code à distance. Les organisations ignoraient souvent qu'elles utilisaient cette bibliothèque, embarquée de façon transitive dans leurs applications.

7. Takeover de domaine, compte ou certificat

• Takeover de package npm/PyPI via récupération de domaine d'email expiré du mainteneur.
• Vol de certificats de signature de code (cas Stuxnet qui utilisait des certificats volés à Realtek et JMicron).
• Compromission de CI/CD : vol de secrets GitHub Actions ou équivalent pour injecter du code dans des pipelines.

8. Attaques via intégrations SaaS

Des plugins, applications connectées, intégrations tierces qui disposent d'autorisations OAuth sur des comptes Google, Microsoft 365, Salesforce, etc. peuvent être détournées pour accéder aux données des clients. Cas : Okta (2022, via Sitel), Discord (multiples compromissions d'intégrations), Microsoft 365 tenants compromis via apps OAuth malveillantes.

03 — Cas emblématiquesLes attaques qui ont marqué la discipline

SolarWinds / SUNBURST (décembre 2020)

L'archétype moderne de la supply chain attack. Des attaquants du service de renseignement russe SVR (identifiés comme APT29 / Cozy Bear / Midnight Blizzard) ont pénétré SolarWinds et injecté une backdoor (« SUNBURST ») dans les mises à jour de leur produit Orion, largement utilisé pour la supervision réseau. La backdoor a été diffusée entre mars et juin 2020 à environ 18 000 organisations, dont des agences fédérales américaines (Treasury, Commerce, DHS, State Department, Energy, NIH) et des entreprises majeures (Microsoft, FireEye, Cisco, Intel, VMware, Deloitte).

Les attaquants ont ensuite exploité environ 100 cibles jugées intéressantes avec une discrétion remarquable. Découvert par FireEye en décembre 2020, l'incident a déclenché une vague réglementaire internationale (Executive Order 14028) et transformé l'approche de la supply chain security.

Kaseya VSA (juillet 2021)

Le groupe REvil a exploité une vulnérabilité 0day dans le logiciel Kaseya VSA, utilisé par des MSP pour administrer à distance les systèmes de leurs clients. Le ransomware a été propagé vers les clients des MSP eux-mêmes, touchant environ 1 500 organisations en cascade. La chaîne suédoise Coop a dû fermer 800 supermarchés. Rançon demandée : 70 millions de dollars. Le FBI a finalement saisi la clé de déchiffrement quelques mois plus tard.

Log4Shell (décembre 2021)

La vulnérabilité CVE-2021-44228 dans Apache Log4j — bibliothèque open source présente dans des millions d'applications Java — a permis l'exécution de code à distance par une simple chaîne de caractères envoyée dans un champ loggé. Score CVSS maximal de 10. Plus de 93 % des environnements d'entreprise étaient affectés selon Wiz, avec une exploitation massive dans les heures suivant la divulgation. Le « bug du siècle » a déclenché une prise de conscience globale sur la sécurité de l'open source et accéléré le déploiement des SBOM.

3CX (mars 2023)

Le client softphone de 3CX, utilisé par 600 000 entreprises dans le monde, a été compromis via une supply chain attack emboîtée : 3CX avait utilisé un autre logiciel (X_TRADER de Trading Technologies), lui-même compromis par le groupe Lazarus (Corée du Nord). Les développeurs 3CX ont inconsciemment utilisé une version compromise qui a introduit une backdoor dans le client 3CX, distribuée à des centaines de milliers de clients. Cas rare de supply chain attack à double niveau.

MOVEit (mai-juin 2023)

Le groupe Cl0p a exploité une vulnérabilité 0day dans MOVEit Transfer, logiciel de transfert de fichiers sécurisé édité par Progress Software. L'attaque a touché plus de 2 700 organisations et exposé les données de 93 millions de personnes, dont des clients de BBC, British Airways, Boots, American Airlines, Ernst & Young, Shell, PwC. Coûts estimés cumulés : plus de 10 milliards de dollars.

XZ Utils (mars 2024)

Un cas qui a stupéfié la communauté sécurité. Un contributeur du projet open source XZ Utils (utilitaire de compression largement intégré dans Linux) avait travaillé plusieurs années pour gagner la confiance et devenir co-mainteneur. Il a ensuite injecté une backdoor sophistiquée dans liblzma qui s'activait via sshd (serveur SSH) pour permettre l'exécution de code à distance.

Découverte quasi-fortuite par Andres Freund, ingénieur Microsoft, qui enquêtait sur des performances anormales (~500 ms de latence supplémentaire). Si la backdoor avait atteint les distributions stables (Debian, Ubuntu LTS, RHEL), l'impact aurait été catastrophique. L'incident a révélé la fragilité de l'écosystème open source dépendant de mainteneurs isolés et sous-financés.

PolyFill.io (juin 2024)

Le service polyfill.io, utilisé par plus de 100 000 sites web pour fournir des polyfills JavaScript, a été compromis après rachat par une entité chinoise. Le service a commencé à injecter du code malveillant qui redirigeait des utilisateurs vers des sites de phishing ou d'arnaque. Cas typique de script tiers compromis sur le web.

Autres cas notables

• NotPetya (2017) : propagé via mise à jour compromise du logiciel ukrainien MeDoc, a causé ~10 milliards de dollars de dégâts mondiaux (Maersk, Merck, FedEx).
• CCleaner (2017) : mise à jour compromise installée par 2,3 millions d'utilisateurs.
• ASUS Live Update (2019, ShadowHammer) : mises à jour compromises diffusées à 500 000 machines, 600 cibles visées.
• Codecov (2021) : script bash modifié, impact sur les pipelines CI/CD.
• Okta / Sitel (2022) : via un prestataire, impact sur les clients Okta.
• JumpCloud (2023) : IAM compromis, impact sur clients crypto.
• Snowflake / TicketMaster (2024) : comptes sans MFA chez Snowflake, données de dizaines d'entreprises exfiltrées.
• Ivanti (multiples incidents 2023-2024) : VPN et solutions de gestion exploités pour atteindre les clients.

04 — SystémiquePourquoi un risque devenu structurel

La dépendance logicielle moderne

Un logiciel d'entreprise moderne est composé à 80-90 % de code non écrit en interne : bibliothèques open source, frameworks, dépendances indirectes. Une application typique embarque plusieurs centaines à milliers de composants lorsqu'on comptabilise les dépendances transitives.

Cette réalité, indispensable à l'efficacité du développement moderne, crée une surface d'attaque composite où chaque composant devient un vecteur potentiel. L'étude Sonatype State of the Software Supply Chain 2024 indique :

• Plus de 700 milliards de téléchargements de packages open source par an.
• Croissance de 1 300 % sur 4 ans des packages open source malveillants détectés.
• 1 sur 6 projets open source contient au moins une vulnérabilité connue.

Fragilité de l'écosystème open source

Le cas XZ Utils a mis en lumière un problème structurel : de nombreux composants critiques du logiciel mondial sont maintenus par quelques bénévoles sans financement suffisant. L'étude « The Core Economic Study of the Open Source Software Supply Chain » (Harvard Business School, 2024) a quantifié la valeur de l'open source à plus de 8 000 milliards de dollars, soutenu par une minorité de mainteneurs isolés.

Réponses en cours :

• OpenSSF (Open Source Security Foundation) : initiative de la Linux Foundation avec financement des géants tech.
• Alpha-Omega project : financement direct de la sécurité des projets critiques.
• Sovereign Tech Fund (Allemagne) : financement public de projets open source critiques.
• GitHub Advanced Security : gratuit pour les projets open source.
• Initiatives européennes : EU Open Source Programme Office.

Multiplication des prestataires

Une entreprise moyenne utilise aujourd'hui 130 applications SaaS selon l'étude BetterCloud 2024, chacune représentant un fournisseur avec potentiellement des accès privilégiés. La surface d'attaque indirecte est proportionnelle.

Motivations des attaquants

• Étatiques : espionnage (SolarWinds, XZ), sabotage (NotPetya), influence (cas ukrainiens pré-guerre).
• Criminels : ransomware à grande échelle (Kaseya, MOVEit), extorsion massive.
• Hacktivistes : perturbation, exposition de données.
• Insider threats : employés ou contributeurs mal intentionnés.

Géopolitique et supply chain

La supply chain est devenue un enjeu de souveraineté :

• Débats sur la dépendance aux hyperscalers américains (Cloud Act).
• Restrictions sur Kaspersky aux USA et au niveau européen.
• Enquêtes sur Huawei et autres équipementiers chinois.
• Émergence de certifications souveraines (SecNumCloud).
• Réglementations forçant la transparence (CRA, executive orders).

05 — DétectionIdentifier une attaque supply chain

Pourquoi la détection est si difficile

• Le composant compromis est légitimement installé.
• Sa signature cryptographique est valide.
• Ses connexions sortantes peuvent imiter du trafic légitime.
• Les attaquants sophistiqués limitent leur exploitation à quelques cibles pour rester discrets.
• Les indicateurs de compromission (IOC) arrivent souvent après coup, parfois plusieurs mois.

Signaux de détection possibles

Analyse comportementale

• Connexions sortantes inhabituelles d'un logiciel qui n'a pas besoin d'Internet ou vers des destinations nouvelles.
• Création de processus anormale par des binaires légitimes.
• Activités post-exploitation : énumération, mouvements latéraux, persistance — ces comportements tombent sous le regard des EDR modernes.
• Horaires inhabituels, volumétrie anormale.
• Détection d'anomalies par ML : plateformes XDR/NDR entraînées sur le comportement normal.

Monitoring de la chaîne logicielle

• SBOM continu et veille CVE sur les composants utilisés.
• Vérification de signatures et provenance des artefacts.
• Hash de binaires comparés avant et après déploiement.
• Alertes sur nouveaux packages publiés sur npm/PyPI/Maven correspondant aux dépendances utilisées.
• File integrity monitoring sur les fichiers système critiques.

Threat intelligence

• Veille sur les IOC publiés après compromission d'éditeurs.
• Abonnements aux alertes éditeurs (Microsoft, Cisco, Ivanti, VMware).
• Feeds CTI (threat intelligence) sur les campagnes supply chain actives.
• Notifications ANSSI et CERT-FR pour les entités qualifiées.
• Partage communautaire : ISAC, communautés sectorielles.

Alertes par les fournisseurs

• Notifications directes de l'éditeur compromis (obligatoires sous NIS2).
• Communications via portails support.
• Annonces publiques via bulletins de sécurité.

Cas d'école : détection de SolarWinds

La backdoor SUNBURST de SolarWinds a été détectée par les équipes de FireEye / Mandiant parce qu'un token de second facteur MFA utilisé pour un accès à leur infrastructure avait déclenché une alerte subtile (réception d'un code alors qu'aucun employé ne l'avait demandé). En remontant le fil de leur propre compromission, ils ont découvert le vecteur SolarWinds Orion. Leçon clé : un fournisseur sophistiqué a détecté par hasard une compromission que personne n'aurait sinon trouvée.

Cas d'école : XZ Utils

La backdoor XZ Utils a été découverte par Andres Freund, ingénieur Microsoft travaillant sur PostgreSQL, qui remarquait des performances anormales de ssh (~500 ms de latence supplémentaire) et une consommation CPU inhabituelle. En investiguant, il a identifié le code malveillant dans liblzma. Leçon clé : la curiosité et l'expertise individuelle peuvent détecter ce que les outils automatisés manquent.

06 — PréventionDéfense en profondeur contre les supply chain

07 — RéglementationLe cadre légal en construction

NIS2 — article 21 (UE)

La directive NIS2 impose explicitement des mesures de gestion des risques liés à la chaîne d'approvisionnement. L'article 21.2(d) exige la sécurité de la chaîne d'approvisionnement, incluant :

• Évaluation des fournisseurs de services directs.
• Gestion des vulnérabilités tiers.
• Notifications d'incidents affectant la chaîne.
• Documentation et traçabilité.

Cyber Resilience Act — CRA (UE)

Le CRA impose aux éditeurs de produits avec éléments numériques :

• Exigences de sécurité dès la conception (security by design).
• Gestion des vulnérabilités tout au long du cycle de vie.
• SBOM obligatoire.
• Notifications d'incidents exploités dans les 24 heures.
• Période de support minimale (5 ans ou durée raisonnable).
• Conformité CE obligatoire pour mise sur le marché européen.

DORA (UE, secteur financier)

DORA impose aux entités financières européennes un cadre strict de gestion des risques liés aux prestataires TIC critiques (cloud, SaaS, outsourcing IT), avec supervision européenne directe des prestataires désignés comme critiques (les hyperscalers par exemple).

Executive Order 14028 (USA)

Signé par le président Biden en mai 2021 après SolarWinds, il impose :

• SBOM obligatoire pour les logiciels vendus au gouvernement fédéral.
• Exigences de sécurité au développement.
• Publication par le NIST du SSDF (Secure Software Development Framework).
• Zero Trust pour les agences fédérales.
• Obligations de notification d'incidents.

M-22-18 et Self-Attestation Form (USA)

Circulaire du bureau de gestion et du budget (OMB) qui impose aux fournisseurs du gouvernement fédéral américain une attestation formelle de respect des pratiques du NIST SSDF. Toute entreprise vendant au gouvernement fédéral doit signer cette attestation.

Obligations sectorielles

• TPRM bancaire (EBA Guidelines sur l'externalisation).
• ENISA Guidelines pour les administrations.
• PGSSI-S santé avec exigences sur sous-traitants (HDS).
• PCI DSS exige la gestion des prestataires ayant accès aux données carte.

Initiatives françaises

• ANSSI guides TPRM : pour les opérateurs essentiels.
• SecNumCloud : référentiel pour cloud de confiance, inclut la chaîne d'approvisionnement.
• Doctrine Cloud au Centre : favorise les solutions souveraines pour les administrations.

08 — FAQQuestions fréquentes

Une PME est-elle vraiment exposée aux attaques supply chain ?

Oui, autant voire plus que les grandes entreprises. Les PME utilisent les mêmes logiciels open source, les mêmes SaaS, les mêmes prestataires IT — donc sont vulnérables aux mêmes compromissions. Elles manquent souvent des ressources de détection et de réponse des grands groupes. Les attaques comme Kaseya ou MOVEit ont touché massivement des PME. Approche pragmatique : se concentrer sur quelques contrôles essentiels — MFA partout, mises à jour systématiques, monitoring basique, inventaire des fournisseurs critiques, plan de réponse simple. Une PME bien défendue peut limiter considérablement son exposition sans atteindre les niveaux sophistiqués des grandes organisations.

Faut-il éviter l'open source pour se protéger ?

Non, ce serait contre-productif. L'open source n'est pas intrinsèquement moins sûr que le logiciel propriétaire — il est simplement plus transparent (c'est d'ailleurs ce qui a permis la détection de la backdoor XZ Utils par lecture du code). Les logiciels propriétaires subissent aussi des supply chain attacks (SolarWinds, 3CX, Kaseya, MOVEit — tous propriétaires). La bonne approche : utiliser l'open source en l'encadrant (SBOM, SCA, pinning de versions, monitoring), contribuer à son écosystème, favoriser les projets bien maintenus, éviter les dépendances obscures peu maintenues. Le choix entre open source et propriétaire doit se faire sur critères fonctionnels et stratégiques, pas sur une supposée sécurité intrinsèque.

Le SBOM suffit-il à se protéger ?

Non, le SBOM est nécessaire mais pas suffisant. Il apporte la visibilité : savoir ce qu'on utilise, détecter rapidement si une vulnérabilité affecte un de nos composants. Mais il ne protège pas activement. Il faut le compléter : par la veille CVE continue, par les signatures (Sigstore), par la provenance (SLSA), par le VEX (qui dit quelles CVE sont réellement exploitables), par l'architecture Zero Trust. Le SBOM est la fondation d'une démarche supply chain security, pas la finalité. Les organisations qui génèrent des SBOM sans les exploiter n'en tirent aucun bénéfice réel.

Les attaques supply chain vont-elles augmenter ou diminuer ?

Augmenter à court terme, possiblement stabiliser à moyen terme. Les attaques supply chain sont trop efficaces pour être abandonnées par les attaquants. L'IA amplifie leur capacité à identifier des points d'entrée, à produire du code malveillant sophistiqué, à automatiser les compromissions. Côté défense, les réglementations (NIS2, CRA, Executive Order) imposent progressivement les bonnes pratiques. Les outils (SBOM, SLSA, Sigstore, plateformes TPRM) matureront. Les attaquants s'adapteront vers des techniques plus sophistiquées (infiltration longue durée comme XZ Utils, attaques sur les builds plutôt que les sources). Le véritable enjeu est de ne pas laisser le ratio coût/bénéfice en faveur des attaquants sur les prochaines années.

Les hyperscalers sont-ils eux-mêmes des risques supply chain ?

Oui, et c'est un débat actif. AWS, Microsoft Azure, Google Cloud opèrent des infrastructures utilisées par des millions d'organisations. Leur compromission (ou celle d'un service central) aurait un impact systémique. Des incidents mineurs se sont déjà produits : SolarWinds a touché des clients Microsoft, l'incident Okta 2022 impliquait un prestataire. Les hyperscalers investissent massivement en sécurité et ont des capacités sans équivalent, mais leur centralité crée un risque de concentration. Les régulations DORA et les initiatives de cloud souverain (SecNumCloud) répondent partiellement à cette préoccupation. La multiplicité des providers et la capacité à basculer restent les meilleures protections, mais elles ont un coût de complexité significatif.