La sécurité des tiers : devenue l'une des premières portes d'entrée des attaquants
Une organisation peut chiffrer ses données, segmenter son réseau, patcher ses serveurs et former ses équipes : il lui reste un angle mort qu'elle ne contrôle pas directement. Ses fournisseurs, ses prestataires SaaS, ses intégrations tierces. Et c'est précisément par là que les attaquants entrent de plus en plus souvent.
Le constat n'est plus anecdotique, il est statistique. Le rapport DBIR 2025 de Verizon, qui a analysé plus de 22 000 incidents et 12 195 compromissions confirmées, établit que la part des compromissions impliquant un tiers a doublé en un an, passant de 15 % à 30 %. Autrement dit, près d'une compromission sur trois trouve aujourd'hui son origine, en tout ou partie, en dehors du périmètre de la victime. La menace n'est plus seulement un attaquant à la porte : c'est une faille héritée d'un partenaire de confiance.
Anatomie d'une compromission en cascade : Okta vers Cloudflare
Pour comprendre le mécanisme, un cas d'école suffit, et il concerne une entreprise réputée pour son excellence en sécurité : Cloudflare.
En octobre 2023, Okta, fournisseur d'authentification utilisé par des milliers d'entreprises, révèle que son système de support a été attaqué. Des fichiers HAR téléchargés par des clients, contenant des jetons de session et des cookies, ont été consultés par un attaquant. Okta révoque les jetons et conseille à ses clients de nettoyer ces fichiers.
Mais quelques semaines plus tard, le 14 novembre, un attaquant probablement soutenu par un État infiltre le serveur Atlassian auto-hébergé de Cloudflare. Comment ? En réutilisant un jeton d'accès et trois identifiants de comptes de service dérobés lors de la violation d'Okta. Cloudflare avait bien réagi à l'alerte initiale, mais certains jetons n'avaient pas été correctement renouvelés. Les attaquants accèdent alors au wiki Confluence, à la base Jira et à une partie du code source sur Bitbucket, cherchant méthodiquement la documentation sur l'architecture et la sécurité du réseau mondial de Cloudflare.
Ce qu'il faut retenir de cet enchaînement : Cloudflare n'a pas été piraté par une faille de Cloudflare. La compromission d'un fournisseur d'identité, plusieurs maillons en amont, a suffi à ouvrir la porte. Et le facteur aggravant n'était pas technique mais organisationnel : un secret compromis qu'on a oublié de révoquer. Comme le résume Éric Fourrier, CEO de GitGuardian, les secrets servent de points de pivot dans les chaînes d'attaque : l'attaquant se déplace d'un identifiant volé au suivant, du tiers vers la cible finale.
Ce n'est pas un cas isolé : la vague Salesloft Drift
Si l'on pouvait croire l'épisode Cloudflare exceptionnel, l'année 2025 a démontré le contraire à grande échelle. Entre le 8 et le 18 août 2025, un acteur identifié sous le nom d'UNC6395 a exploité des jetons OAuth dérobés à Salesloft Drift, une application de chatbot intégrée à Salesforce.
Le résultat dépasse l'entendement : plus de 700 organisations ont été touchées, parmi lesquelles Cloudflare (à nouveau), Google, Palo Alto Networks, Proofpoint, Zscaler ou encore Tanium. Là encore, la plateforme Salesforce elle-même n'a pas été piratée. Les attaquants ont simplement hérité des permissions excessives accordées à une application tierce, puis exporté méthodiquement les données des instances Salesforce à la recherche de secrets : clés AWS, identifiants VPN, jetons Snowflake. De quoi alimenter une vague d'attaques en aval.
La leçon de la Cloud Security Alliance est limpide : l'intégration de Drift avait obtenu un accès bien plus large que ce qu'exigeait un chatbot. Quand les jetons ont été volés, les attaquants ont hérité de ce privilège excessif. Le maillon faible n'était pas dans la forteresse, mais dans une application à laquelle la forteresse avait, un jour, accordé trop de droits.
Pourquoi le risque tiers explose
Trois dynamiques convergent pour faire de la sécurité des tiers un sujet de premier plan.
D'abord, la surface d'attaque s'est déplacée vers le SaaS et les intégrations. Chaque connecteur OAuth, chaque API, chaque application tierce branchée sur un système central crée un « tunnel de confiance » que les outils de sécurité classiques peinent à surveiller. L'attaquant n'a plus besoin de percer la cible : il lui suffit de compromettre un fournisseur moins bien défendu et d'emprunter le tunnel.
Ensuite, ces compromissions sont les plus lentes à détecter. Selon le rapport IBM Cost of a Data Breach 2025, les compromissions de la chaîne d'approvisionnement prennent en moyenne 267 jours à identifier et contenir, soit la durée la plus longue de toutes les catégories. La raison est structurelle : l'activité malveillante se fond dans le trafic partenaire légitime pendant des mois.
Enfin, le coût est élevé. Toujours selon IBM, une compromission impliquant un tiers ou la chaîne d'approvisionnement coûte en moyenne 4,91 millions de dollars, le deuxième vecteur le plus coûteux de l'étude. Le risque tiers n'est donc pas seulement fréquent : il est durable et onéreux.
| Indicateur | Valeur |
|---|---|
| Part des compromissions impliquant un tiers | 30 % (15 % un an plus tôt, soit +100 %) |
| Délai moyen de détection et de confinement | 267 jours |
| Coût moyen d'une compromission via la chaîne d'approvisionnement | 4,91 M$ |
Ce que notre veille observe
Le signal se retrouve dans notre flux de veille. Sur les 30 derniers jours, parmi quelque 17 000 signalements cyber consolidés, les compromissions liées à un tiers ou à la chaîne d'approvisionnement forment un motif constant : on dénombre 307 signalements évoquant explicitement un tiers, un fournisseur ou la supply chain, 78 mentionnant des jetons ou identifiants détournés, et 55 portant sur des accès OAuth. La saga Salesforce (Salesloft Drift, puis Gainsight) à elle seule revient dans 30 signalements distincts sur la période.
Surtout, les exemples concrets que nous collectons illustrent l'ampleur du phénomène, au-delà des grands noms. Sur ces seules dernières semaines, notre veille a relevé la compromission d'un fournisseur lié à une entreprise agroalimentaire américaine pesant 5 milliards de dollars, la brèche d'un sous-traitant exposant les données de patients d'un institut d'oncologie, une série de paquets npm et NuGet malveillants conçus pour voler des secrets cloud et des identifiants CI/CD, ou encore une vulnérabilité OAuth dans un plugin Jenkins-Bitbucket ouvrant la voie à du phishing. Le glissement décrit par les grands rapports n'est pas une abstraction : il se matérialise semaine après semaine, où un même incident chez un fournisseur se répercute en cascade sur des dizaines de clients en aval : une seule compromission fournisseur (août 2025) a ainsi impacté plus de 700 organisations en une dizaine de jours.
La sécurité n'est plus une option à facturer
Il faut nommer un travers devenu inacceptable : trop de fournisseurs traitent encore la sécurité comme une fonctionnalité premium, vendue à part, plutôt que comme le socle de leur prestation. L'exemple le plus documenté est celui de l'authentification unique (SSO). Le site sso.tax, surnommé le « SSO Wall of Shame », recense des dizaines d'éditeurs qui placent le SSO derrière un palier « Entreprise », gonflant la facture de 50 %, 200 %, parfois plus de 1 000 %. Le message du site est sans appel : la sécurité ne devrait pas être une fonctionnalité de luxe, et le SSO est une exigence de sécurité fondamentale pour toute entreprise de plus de cinq personnes. Cette pratique punit les organisations en croissance et les pousse à des raccourcis dangereux, exactement l'inverse de ce qu'un fournisseur sérieux devrait encourager.
Le raisonnement vaut bien au-delà du SSO. Quand un client confie ses données les plus précieuses à un prestataire, certains éléments de sécurité ne sont plus négociables : chiffrement des données avec des algorithmes robustes et non obsolètes, segmentation réseau, architecture trois tiers, authentification multifacteur, sensibilisation aux risques du Top 10 OWASP, gestion et rotation des secrets. Ce ne sont pas des options à cocher, ce sont les fondations. Un fournisseur qui les facture en supplément, ou pire qui ne les propose pas, transfère son risque sur son client sans le dire.
C'est pourquoi les clients doivent devenir nettement plus exigeants. Un contrat prévoit souvent une garantie financière d'indemnisation en cas d'incident, mais aucune clause ne répare l'atteinte à l'image auprès de ses propres clients, ni la perte de confiance qui en découle. La meilleure protection n'est pas l'indemnisation après coup, c'est l'exigence en amont. Cette exigence peut s'appuyer sur des garanties vérifiables : certifications ISO 27001, rapports SOC 2, attestations qui démontrent qu'une entreprise entretient une véritable hygiène et une culture cyber, dans ses processus, ses revues de code, la sensibilisation de ses équipes. Ces référentiels ne sont pas une garantie absolue, mais ils prouvent qu'un effort structuré existe.
Car c'est là le cœur du sujet. Il y aura toujours plus fort que soi, et aucune organisation n'est invulnérable. Mais on ne peut pas se revendiquer victime si l'on n'a pas mis les moyens nécessaires pour se protéger. La sécurité n'est plus un luxe que l'on s'offre quand le budget le permet, c'est une nécessité, et la responsabilité de la garantir s'étend à toute la chaîne, du client jusqu'au dernier de ses sous-traitants.
Que faire : reprendre le contrôle sur ce qu'on ne maîtrise pas
On ne peut pas auditer le code de tous ses fournisseurs, mais on peut réduire mécaniquement la surface du risque tiers.
Tout part d'un préalable qui conditionne le reste : questionner la criticité de la donnée avant même de l'externaliser. La première question à se poser n'est pas « quel fournisseur choisir ? », mais « cette donnée doit-elle seulement quitter nos murs ? ». Concrètement, cela suppose de classer ses données par niveau de criticité, puis de confronter chaque externalisation envisagée à ses propres échelles d'impact : si la compromission de cette donnée chez un tiers entraîne un impact que l'organisation juge inacceptable (réglementaire, financier, vital, stratégique), alors la dépendance à ce tiers n'est pas acceptable, quel que soit le niveau de sécurité qu'il affiche. Tout le risque décrit dans cet article découle d'un choix devenu réflexe : confier ses données et ses traitements à des prestataires SaaS et à des clouds que l'on ne maîtrise pas directement. Or pour les données les plus critiques, la meilleure protection contre la compromission d'un tiers reste de ne pas dépendre de ce tiers. Privilégier une solution hébergée localement, ou une infrastructure dont on garde le contrôle direct, élimine d'un coup une part entière de la surface d'attaque : pas de jeton OAuth à se faire voler, pas de fournisseur intermédiaire dont la sécurité échappe à votre gouvernance. Cela ne convient pas à tous les usages, et l'auto-hébergement déplace une partie de la charge de sécurité sur vos propres épaules, comme l'a montré l'incident Cloudflare avec son serveur Atlassian auto-hébergé. Mais la question mérite d'être posée frontalement, et en premier. La souveraineté n'est pas une posture idéologique, c'est une réduction concrète du nombre d'acteurs en qui l'on est forcé de placer sa confiance.
La confiance n'exclue pas le contrôle
La sécurité des tiers oblige à un changement de mentalité. Pendant des années, la sécurité s'est pensée en termes de périmètre : protéger l'intérieur contre l'extérieur. Mais quand 30 % des compromissions transitent par un partenaire de confiance, la frontière n'est plus le mur d'enceinte, elle est dans chaque connexion accordée à un tiers.
La confiance accordée à un fournisseur n'est pas un contrôle de sécurité. Comme le rappelle l'incident Cloudflare, la cybersécurité est une responsabilité partagée qui doit s'étendre à toute la chaîne d'approvisionnement. Ignorer cette réalité, c'est laisser ouverte une porte dont on a confié la clé à quelqu'un d'autre.
Sources
- Verizon, 2025 Data Breach Investigations Report (part des tiers passée de 15 % à 30 % ; 22 000+ incidents, 12 195 compromissions) : verizon.com
- IBM, Cost of a Data Breach Report 2025 (compromission supply chain : 4,91 M$, 267 jours de détection) : ibm.com
- GitGuardian / Solutions Numériques, analyse de l'attaque Okta → Cloudflare (Éric Fourrier) : solutions-numeriques.com
- Cloudflare, BleepingComputer, détail de l'intrusion du serveur Atlassian (2024)
- Google Threat Intelligence Group (GTIG), Cloud Security Alliance, FINRA, campagne Salesloft Drift / UNC6395 (700+ organisations, août 2025)
- sso.tax, The SSO Wall of Shame (recensement des éditeurs facturant le SSO comme une option premium) : sso.tax
- Données primaires : veille LuksMentis (~17 000 signalements cyber sur 30 jours)