Une cyberattaque visant la chaîne d'approvisionnement peut vous atteindre par l'intermédiaire d'un fournisseur, d'une mise à jour logicielle, d'un progiciel open source, d'un sous-traitant ou d'un prestataire de services en qui vous avez déjà confiance. La vérification des fournisseurs doit désormais porter sur la manière dont ceux-ci développent, signent, surveillent et révoquent leurs logiciels, et non plus se limiter à vérifier s’ils cochent les cases d’un questionnaire de sécurité. Commencez par examiner l’étendue des accès, les preuves relatives à la liste des composants logiciels (SBOM), l’historique des incidents, les droits contractuels et la surveillance continue.
Pourquoi une cyberattaque visant la chaîne d'approvisionnement constitue désormais un risque au niveau du conseil d'administration
IBM X-Force a indiqué en 2026 que les attaques de grande envergure visant la chaîne d’approvisionnement ou des tiers avaient presque quadruplé depuis 2020. Ce même indice de 2026 a fait état d’une augmentation de 49% du nombre de groupes de ransomware actifs en 2025 par rapport à 2024, ce qui est significatif car les attaquants utilisent de plus en plus les fournisseurs comme moyen d’accéder simultanément à de nombreuses victimes.
Une cyberattaque visant la chaîne d'approvisionnement est particulièrement efficace, car elle retourne la confiance contre vous. Au lieu de forcer votre porte d'entrée, un intrus infecte un colis, abuse d'un fournisseur de services gérés, compromet un système de compilation ou exploite un outil de transfert de fichiers que votre équipe utilise déjà.
L'intention de recherche ici est à la fois pratique et informative : vous souhaitez savoir en quoi consiste ce type d'attaque, pourquoi il est en hausse et comment évaluer les fournisseurs tiers avant qu'ils ne deviennent un problème pour vous. La réponse n'est pas « achetez un outil ». Les outils sont utiles, mais votre processus doit mettre en évidence les cas où la confiance est accordée sans preuve.
Pour les petites entreprises, le plus délicat réside dans l’évaluation. En 2026, les données publiques primaires fiables sur l’incidence des attaques visant la chaîne d’approvisionnement des PME restent rares ; de nombreux chiffres cités dans les médias proviennent d’enquêtes menées par des fournisseurs ou de rapports secondaires. Ne basez donc pas votre programme sur des statistiques alarmistes. Basez-le plutôt sur une analyse des dépendances : quels fournisseurs ont accès à vos données, à votre code, à vos systèmes d’identité, à votre réseau de production ou à vos clients ?
Qu'est-ce qu'une attaque de la chaîne d'approvisionnement, en termes simples ?
Une attaque par la chaîne d'approvisionnement est une intrusion qui atteint la cible réelle par l'intermédiaire d'un tiers. Ce tiers peut être un fournisseur de services SaaS, une bibliothèque logicielle, un intégrateur cloud, un prestataire de services de paie, un MSP, un outil CI/CD, un SDK mobile, voire l'ordinateur portable d'un sous-traitant.
SolarWinds reste l’exemple d’entreprise par excellence. Le 13 décembre 2020, la CISA a indiqué que les versions 2019.4 HF 5 à 2020.2.1 HF 1 de la plateforme Orion de SolarWinds, publiées entre mars et juin 2020, faisaient l’objet d’exploitations actives. Le 14 décembre 2020, SolarWinds a indiqué à la SEC que la compromission d’Orion était probablement le résultat d’une attaque ciblée visant la chaîne d’approvisionnement et que le code malveillant affectait les mises à jour publiées au cours de cette même période de mars à juin 2020.
MOVEit a révélé une autre tendance. Un avis publié en juin 2023 par la CISA, le FBI et le MS-ISAC indiquait que le groupe de ransomware CL0P avait exploité des vulnérabilités de MOVEit Transfer à partir de mai 2023. De nombreuses victimes n’ont pas été attaquées parce qu’elles utilisaient des mots de passe faibles ; elles ont été exposées parce qu’un outil de transfert largement utilisé s’inscrivait dans un flux de travail sensible.
Les dépendances logicielles apportent une touche particulière. Le 29 mars 2024, la CISA a attribué le numéro CVE-2024-3094 à un code malveillant intégré aux versions 5.6.0 et 5.6.1 de XZ Utils. Cet incident a rappelé que la confiance dans l’open source est à la fois sociale, technique et parfois fragile.
Les incidents récents montrent que le problème lié aux fournisseurs s'aggrave de plus en plus rapidement
L'incident TanStack de 2026 est le genre de cas que les équipes chargées des achats devraient étudier. Le 11 mai 2026, TanStack a indiqué qu’un pirate avait publié 84 versions malveillantes dans 42 paquets npm @tanstack/* entre 19 h 20 et 19 h 26 UTC. Six minutes. C’est moins long que la durée des réunions debout de nombreuses entreprises.
OpenAI a déclaré le 11 mai 2026 que la compromission de TanStack sur npm s’inscrivait dans le cadre d’une attaque plus large visant la chaîne d’approvisionnement logicielle, connue sous le nom de « Mini Shai-Hulud ». Le 12 juin 2026, OpenAI a déclaré qu’elle allait révoquer définitivement un ancien certificat de signature d’application macOS après que les appareils de deux employés ont été affectés par l’incident lié à TanStack. OpenAI a également précisé qu’aucune donnée utilisateur n’avait été compromise, selon des articles publiés en 2026 par BleepingComputer et TechRadar.
D'autres rapports publiés en 2026 ont permis d'élargir le tableau. SecurityWeek a rapporté le 12 mai 2026 que TanStack, Mistral AI et UiPath avaient été touchés par une nouvelle attaque visant la chaîne d'approvisionnement. Axios a rapporté le 31 mars 2026 que des chercheurs de Google avaient établi un lien entre une compromission de la chaîne d'approvisionnement npm impliquant le package Axios et un groupe présumé nord-coréen suivi sous le nom d'UNC1069.
Les groupes spécialisés dans les ransomwares sont à l'affût. ITPro a rapporté le 3 juillet 2026 que Vect et TeamPCP collaboraient dans le cadre d'une campagne impliquant des attaques de la chaîne d'approvisionnement et des actes d'extorsion. Si l'on observe la vitesse des attaques assistées par l'IA, ce schéma correspond à ce que les équipes de sécurité constatent déjà dans des campagnes de plus en plus rapides, telles que Opérations de ransomware basées sur l'IA.
Critères de sélection des fournisseurs qui permettent réellement de réduire les risques
Un questionnaire correct suffit. Un questionnaire en soi, ce n'est que de la poudre aux yeux. Pour un fournisseur disposant d'un accès significatif, il faut des preuves, des droits et un moyen de réagir lorsque le risque lié à ce fournisseur évolue après la signature du contrat.
La norme NIST SP 800-161, révision 1, publiée en 2022, fournit le cadre adéquat : la gestion des risques liés à la chaîne d’approvisionnement numérique doit être intégrée aux évaluations des fournisseurs, aux politiques, aux plans et à la gestion globale des risques de l’entreprise. En d’autres termes, il ne faut pas confiner la sécurité des fournisseurs aux seules formalités administratives liées aux achats.
- Commençons par l'accès à la carte : énumérez les systèmes, les classes de données, les droits d'administration, les jetons, les référentiels et les workflows clients auxquels le fournisseur a accès.
- Demandez si la fonctionnalité SBOM est disponible : Les recommandations de la CISA pour 2024 en matière d'acquisition de logiciels prévoient des questions adressées aux fournisseurs concernant les SBOM validées dans des formats lisibles par machine approuvés par la NTIA ou la CISA.
- Valider les contrôles de compilation : demander comment le fournisseur valide les bibliothèques, les systèmes de compilation, les étapes de packaging et les outils CI/CD, un autre domaine mentionné dans les recommandations de la CISA de 2024 en matière d’acquisition.
- Évaluer les risques liés au personnel : exiger des réponses claires concernant les employés et les prestataires ayant fait l'objet d'une vérification de leurs antécédents, en particulier pour le personnel de soutien disposant d'un accès privilégié.
- Contrat relatif aux droits en cas d'incident : Les notifications, l'accès aux journaux, les droits d'audit, les obligations en matière de révocation de certificats, l'obligation d'informer sur les sous-traitants et les droits de résiliation doivent être consignés par écrit.
- Surveiller en permanence : intégrer la détection des vulnérabilités aux référentiels SBOM afin que les alertes puissent être associées aux produits que vous utilisez réellement, comme le recommande le guide du NIST de 2024 sur les SBOM.
Voici l'écueil que de nombreuses équipes négligent : le fournisseur le plus risqué n'est pas toujours le plus important. Un plugin de niche disposant de droits de mise à jour automatique, un petit MSP bénéficiant de privilèges d'administrateur de domaine ou un outil d'automatisation de l'intégration continue ayant accès aux secrets du référentiel peuvent avoir un impact bien plus important qu'un grand fournisseur dont l'accès aux données est limité.
Si votre entreprise en est encore à la phase de mise en place de son programme de contrôle, associez la sélection des fournisseurs à une stratégie de conformité plus globale. Les conséquences financières d’une négligence des principes fondamentaux de gouvernance sont clairement exposées dans ce guide sur la conformité en matière de cybersécurité en 2026.
Une méthode de classement des fournisseurs tiers fondée sur des chiffres
La plupart des systèmes d’évaluation des risques liés aux fournisseurs sont trop vagues. Les catégories « élevé », « moyen » et « faible » semblent claires, mais elles masquent les discussions qu’il faut mener. Je préfère un simple score d’exposition sur 100 points, car il oblige les équipes à comparer les fournisseurs en fonction de leurs droits d’accès réels.
Attribuez à chaque fournisseur jusqu’à 25 points pour la sensibilité des données, 25 pour le niveau de privilège, 20 pour la dépendance opérationnelle, 15 pour la capacité à mettre à jour les logiciels ou à exécuter du code, et 15 pour la substituabilité. Une plateforme de gestion de la paie contenant les données fiscales des salariés, intégrant une authentification unique et difficile à remplacer pourrait obtenir un score de 80. Un outil de newsletter ne contenant que des contacts marketing publics pourrait obtenir un score de 25.
Maintenant, passons à la mise en œuvre. Si vous avez 60 fournisseurs et seulement 10 heures par mois à consacrer aux contrôles de sécurité, ne répartissez pas ce temps de manière égale. Consacrez-en 70% aux 10 fournisseurs présentant le plus grand risque, 20% aux fournisseurs à risque moyen et 10% à l’intégration des nouveaux fournisseurs. Cela peut paraître brutal, car ça l’est. Mais cela fonctionne mieux que de prétendre que chaque fournisseur mérite le même niveau d’examen.
| Incident ou conseil | Année | Que s'est-il passé ? | Leçon sur la sélection des fournisseurs |
|---|---|---|---|
| SolarWinds Orion | 2020 | Selon la CISA, les versions d'Orion concernées, commercialisées entre mars et juin 2020, ont fait l'objet d'exploitations actives. | Passer en revue les procédures relatives aux mises à jour signées, à l'intégrité des versions et aux obligations de notification des incidents par les fournisseurs. |
| MOVEit Transfer | 2023 | Selon la CISA, le FBI et le MS-ISAC, le groupe CL0P aurait exploité des failles de MOVEit à partir de mai 2023. | Considérez les outils de transfert de fichiers comme présentant un risque élevé lorsqu'ils traitent des flux de données sensibles. |
| XZ Utils CVE-2024-3094 | 2024 | La CISA a attribué un identifiant CVE à un code malveillant présent dans les versions 5.6.0 et 5.6.1 de XZ Utils. | La gestion des dépendances open source nécessite une gestion des versions et un suivi des versions. |
| Vulnérabilité de TanStack sur npm | 2026 | Selon TanStack, 84 versions malveillantes réparties dans 42 paquets ont été publiées en six minutes. | Les contrôles automatisés des paquets s'avèrent plus efficaces que les vérifications manuelles lorsque les attaques se succèdent à un tel rythme. |
Une cyberattaque visant la chaîne logistique peut également se propager via les flux de travail de codage basés sur l'IA, là où se croisent les référentiels, les agents, les gestionnaires de paquets et les secrets. Si vos développeurs adoptent des outils de codage plus intelligents, renseignez-vous sur analyse des dépôts de code et risques liés au codage basé sur l'IA avant de permettre un accès généralisé à ces nouveaux outils.
Clauses contractuelles et contrôles opérationnels sur lesquels vous devez insister
Les dispositions relatives à la sécurité doivent être suffisamment précises pour pouvoir être vérifiées. Une formulation telle que « le fournisseur respecte les meilleures pratiques du secteur » n’est pas suffisante. Demandez à connaître les pratiques adaptées au niveau de risque : fourniture d’une liste des composants logiciels (SBOM), notification des vulnérabilités, contrôles des sous-traitants, journalisation des accès privilégiés, isolation des sauvegardes, preuve de la suppression des données et procédures de révocation des certificats.
Pour les fournisseurs de logiciels, les recommandations de la CISA de 2024 relatives à l’utilisation des SBOM indiquent que celles-ci peuvent faciliter les processus d’approvisionnement, la gestion des fournisseurs, la gestion des risques liés aux tiers, les rapports de conformité et la gestion des vulnérabilités. Cela ne signifie pas pour autant que toutes les SBOM sont utiles. Un inventaire au format PDF obsolète n’a pratiquement aucune valeur comparé à une SBOM lisible par machine que vos outils de gestion des vulnérabilités peuvent exploiter.
Les contrôles d'identité méritent une attention particulière. Les fournisseurs doivent, dans la mesure du possible, recourir à une authentification multifactorielle (MFA) résistante au phishing pour les accès privilégiés, à des comptes de service à portée limitée, à des jetons à durée de vie courte et à des comptes nominatifs plutôt qu'à des identifiants partagés. Si Microsoft 365 ou une autre plateforme d'identité fait partie de la chaîne, réexaminez les raisons pour lesquelles la MFA seule peut s'avérer insuffisante face à certains vecteurs d'attaque dans cet avertissement concernant l'authentification à plusieurs facteurs (MFA) de Microsoft 365.
Le concept de « zero trust » est souvent galvaudé en tant que slogan, mais ce principe s'applique parfaitement à la gestion des accès des fournisseurs : ne jamais accorder à un fournisseur plus d'accès que ne l'exige la tâche à accomplir. Pour une analyse plus approfondie des politiques, en particulier dans les environnements réglementés, sécurité « zero-trust » pour les agences fédérales offre également des enseignements utiles en dehors du cadre gouvernemental.
Un contre-argument est pertinent : les exigences trop strictes des fournisseurs peuvent ralentir les procédures d’approvisionnement et agacer les petits fournisseurs. Mon point de vue est simple : adapter l’exigence à l’ampleur du risque. Un prestataire chargé de la conception n’a pas besoin d’un avenant de sécurité de 40 pages s’il n’a jamais accès aux données de production ; un fournisseur de pipeline de construction en a absolument besoin.
Comment réagir lorsqu'un fournisseur est victime d'une intrusion
Lorsqu'une cyberattaque visant la chaîne d'approvisionnement touche un fournisseur, la rapidité prime sur la qualité des rapports. Suspendez les intégrations à risque, renouvelez les clés de sécurité, identifiez les versions concernées, récupérez les journaux d'événements et déterminez s'il convient de suspendre les mises à jour automatiques. Votre plan d'intervention doit déjà désigner le responsable métier pour chaque fournisseur critique.
Posez des questions précises : quels produits, versions, certificats de signature, référentiels, appareils des employés, sous-traitants et environnements clients ont été touchés ? La révocation des certificats d’OpenAI en 2026, à la suite de l’incident lié à TanStack, constitue un exemple utile, car elle a porté sur la confiance dans les logiciels signés, et pas seulement sur les machines infectées.
La communication doit être concise mais honnête. Indiquez à vos clients ce que vous savez, ce que vous ignorez, les fonctionnalités que vous avez désactivées et quand vous leur fournirez de nouvelles informations. Si vous faites appel à des prestataires de services gérés (MSP), à des intégrateurs cloud ou à des fournisseurs de solutions de sécurité, c’est également à ce moment-là que vos priorités annuelles en matière de cybersécurité doivent devenir des habitudes de travail plutôt que de simples présentations PowerPoint.
Le cas de figure peu probable : un fournisseur peut être irréprochable, mais ce n'est pas forcément le cas de son paquet en amont. C'est pourquoi les référentiels SBOM, la surveillance des dépendances et la traçabilité de la compilation sont essentiels. Vous ne vous contentez pas de vérifier la fiabilité d'un fournisseur. Vous vérifiez l'ensemble de la chaîne qui se cache derrière ce fournisseur.
FAQ
Qu'est-ce qu'une cyberattaque visant la chaîne d'approvisionnement ?
Une cyberattaque visant la chaîne d'approvisionnement compromet une organisation par l'intermédiaire d'un tiers de confiance, tel qu'un éditeur de logiciels, un progiciel open source, un sous-traitant, un fournisseur de services gérés (MSP) ou une plateforme SaaS. L'attaquant abuse de la confiance existante au lieu de s'en prendre directement à la cible finale.
Quels sont les exemples célèbres d'attaques visant la chaîne d'approvisionnement ?
SolarWinds Orion en 2020, l'exploitation de MOVEit Transfer en 2023, la vulnérabilité CVE-2024-3094 de XZ Utils en 2024 et la compromission de TanStack npm en 2026 en sont des exemples bien connus. Bien qu’ils diffèrent sur le plan technique, chacun d’entre eux montre comment un composant de confiance peut présenter un risque en aval.
Comment prévenir une cyberattaque visant la chaîne d'approvisionnement ?
Il est impossible d'empêcher toutes les failles de sécurité chez les fournisseurs, mais vous pouvez en limiter l'impact. Limitez les droits d'accès des fournisseurs, exigez la fourniture de listes de composants logiciels (SBOM), surveillez en permanence les vulnérabilités, utilisez des identifiants à portée restreinte, vérifiez la sécurité des versions et intégrez les obligations de notification des incidents dans les contrats.
Les petites entreprises ont-elles besoin d'une gestion des risques liés aux fournisseurs ?
Oui, mais cela doit être proportionné. Commencez par classer les fournisseurs ayant accès à des fonds, aux données clients, aux systèmes d'identité, aux outils de production ou aux sauvegardes, puis examinez en priorité ceux qui présentent le plus grand risque.
FR 
EN 
ES