Fournisseur cloud compromis : comment un tiers devient la porte d'entrée de votre SI (TPRM)

Votre périmètre de sécurité ne s'arrête pas à votre infrastructure. Il s'étend à chaque fournisseur qui y a accès.

La gestion des risques tiers est devenue, pour beaucoup d'organisations, le point faible le plus négligé de leur posture de sécurité. Les risques liés aux tiers ne se résument plus à une clause contractuelle : ils pèsent directement sur la résilience opérationnelle de l'entreprise qui en dépend.

Un matin, des utilisateurs signalent des comportements étranges sur votre plateforme. Des données qui bougent. Des exports qui n'ont pas été déclenchés. Votre équipe sécurité se met en ordre de bataille, passe vos systèmes au crible, vérifie les logs, interroge les outils de détection. Rien. Pas la moindre trace d'intrusion.

Vous contactez votre fournisseur de CRM. Leur réponse arrive en fin de journée : "Nous n'avons constaté aucune activité suspecte de notre côté."

Sauf que deux semaines plus tard, vous apprenez que ce fournisseur utilisait un outil de marketing automation, un tiers de votre tiers, dont les tokens d'accès avaient été volés. Vos données ont été exfiltrées via une connexion qui ressemblait exactement à du trafic légitime. Aucun de vos outils ne pouvait le détecter, parce que la connexion venait d'un système autorisé.

Ce n'est pas un scénario fictif. C'est ce qui s'est passé en août 2025, quand le groupe UNC6395 a compromis Salesloft Drift et accédé aux instances Salesforce de plus de 700 organisations. Les victimes n'avaient rien fait de mal. Leur fournisseur avait été compromis via un autre fournisseur.

"Ce qui m'a marqué quand j'étais du côté offensif, c'est que les fournisseurs cloud sont souvent la voie la plus propre vers une cible. Pas d'alerte, pas de trace anormale. La relation de confiance devient la vulnérabilité.", explique Vladimir Kolla, cofondateur et CTO de Patrowl, ex-pentesteur.

À retenir

• 30 % des violations de données impliquent un tiers en 2025, contre 15 % l'année précédente (Verizon DBIR 2025)

• 97 % des organisations ont subi au moins une violation via leur chaîne d'approvisionnement en 2025

• Le coût moyen d'une violation d'origine tierce atteint 4,8 M$, soit 8 % au-dessus de la moyenne globale

• 62 % des programmes TPRM s'appuient encore sur des questionnaires auto-déclaratifs (Gartner 2026)

• DORA et NIS2 imposent une surveillance continue des tiers : le questionnaire annuel n'est plus suffisant réglementairement

La part des violations passant par un tiers a doublé en un an. Ce n'est pas une tendance graduelle. C'est un changement de tactique des attaquants. Plutôt que d'affronter une cible bien défendue, ils cherchent le fournisseur qui y a accès et qui est moins surveillé. C'est plus rapide, plus discret, et souvent plus efficace.

"Quand on fait un pentest chez un client, une des premières choses qu'on regarde c'est ses fournisseurs cloud. Leurs sous-domaines, leurs APIs exposées, leurs certificats. C'est souvent là qu'on trouve l'entrée la plus rapide.", explique Florent Montel, cofondateur et CFO de Patrowl, ex-pentesteur.

Pensez à votre maison. Vous avez une bonne serrure, une alarme, des volets solides. Mais vous avez aussi donné un double des clés au plombier, au gardien et à la femme de ménage. Si l'un d'eux se fait voler ses clés, peu importe la qualité de votre serrure.

Le cloud fonctionne exactement comme ça.

Un fournisseur SaaS, un outil de marketing automation, une plateforme RH : chacun détient des accès à votre infrastructure. Des tokens OAuth, des connexions API, des webhooks actifs avec des droits étendus. Ces accès sont nécessaires pour que le service fonctionne. Ils représentent aussi autant de portes vers votre SI que vous ne contrôlez pas directement, et donc autant de risque cyber transféré à un tiers sans que la protection des données en pâtisse moins pour autant.

Quand un attaquant cible le fournisseur plutôt que vous, il récupère ces accès sans les forcer. Il entre par la porte du plombier. Le trafic qu'il génère ressemble exactement à du trafic légitime. Aucune règle SIEM ne le détecte, aucun EDR ne l'intercepte, aucune alerte ne se déclenche de votre côté.

Ce que ça signifie en pratique :

• Une connexion OAuth compromise chez un fournisseur donne accès à toutes les ressources que ce fournisseur peut atteindre chez vous

• Un bucket S3 mal configuré côté fournisseur expose vos données sans que vos outils de détection voient quoi que ce soit

• Un logiciel de transfert de fichiers utilisé par votre prestataire logistique peut compromettre vos données clients sans qu'aucune alerte ne remonte chez vous

Incident 1 : Salesloft Drift, 700 organisations compromises via un token OAuth

En août 2025, le groupe UNC6395 a volé les tokens OAuth de Drift, un outil de marketing automation intégré à Salesforce. Avec ces tokens, les attaquants ont accédé directement aux instances Salesforce de tous les clients de Drift qui avaient autorisé cette connexion.

Résultat : plus de 700 organisations touchées. Données clients exfiltrées, informations commerciales compromises. Aucun exploit technique, aucun phishing vers les victimes finales. Une connexion de confiance, détournée. Une des fuites de données les plus étendues de l'année, sans qu'aucune des organisations touchées n'ait elle-même commis d'erreur.

Les équipes sécurité des organisations impactées n'avaient commis aucune erreur. Leur fournisseur avait été compromis via un de ses propres outils. La chaîne de confiance avait deux maillons, et l'attaquant n'avait eu besoin d'en casser qu'un seul.

Ce que ça illustre : vos contrôles de sécurité ne s'appliquent pas aux accès que vous avez délégués à vos fournisseurs.

Incident 2 : Cleo / MOVEit, quand un logiciel commun touche des centaines d'entreprises simultanément

Le groupe Cl0p a systématisé une approche redoutable : cibler un logiciel utilisé par des centaines d'organisations pour les compromettre toutes en même temps. Avec MOVEit en 2023, puis Cleo en 2024-2025.

Les vulnérabilités CVE-2024-50623 et CVE-2024-55956 dans Cleo permettaient d'uploader des fichiers sans authentification et d'exécuter des commandes shell arbitraires. Hertz, Kellogg et Sam's Club n'utilisaient pas Cleo directement : leurs prestataires logistiques l'utilisaient. La chaîne de confiance avait plusieurs niveaux. L'attaquant n'avait besoin de compromettre qu'un seul maillon.

C'est ce qu'on appelle le Nth-party risk : le risque des fournisseurs de vos fournisseurs. Une organisation qui travaille avec 286 fournisseurs en moyenne (chiffre 2025) ne connaît qu'une fraction des outils que ces fournisseurs utilisent eux-mêmes. Cartographier ce risque sans outillage dédié est pratiquement impossible.

Ce que ça illustre : votre exposition ne s'arrête pas à vos fournisseurs directs. Elle s'étend à tout ce qu'ils utilisent pour vous délivrer leur service.

Incident 3 : bucket S3 exposé, 10 To de données clients invisibles depuis votre SI

En 2025, un constructeur automobile mondial a laissé accessibles publiquement 10 To de données clients via un bucket S3 mal configuré et des credentials codés en dur dans des fichiers de configuration. La donnée n'était pas chez le constructeur. Elle était chez un prestataire cloud qui gérait une partie de son infrastructure client.

Les clients du constructeur n'avaient aucune visibilité sur cette exposition. Elle n'apparaissait dans aucun de leurs outils de sécurité. Elle a été découverte par un chercheur externe qui scannait les buckets S3 publics, exactement ce qu'un attaquant aurait fait.

Ce que ça illustre : une misconfiguration cloud côté fournisseur est invisible depuis votre propre infrastructure. La seule façon de la détecter est de regarder depuis l'extérieur, comme un attaquant le ferait.

Incident 4 : Eurofiber France, un seul sous-traitant, des milliers de clients impactés

En novembre 2025, Eurofiber France, opérateur télécom utilisé par de nombreuses grandes organisations françaises, a été compromis. L'attaque ne visait aucun des clients d'Eurofiber directement : elle visait l'opérateur lui-même.

Résultat : des données appartenant à la SNCF, Orange, SFR, Auchan, Airbus et plusieurs ministères se sont retrouvées exposées. Un seul sous-traitant compromis, 3 600 clients impactés en cascade.

Aucune de ces organisations n'avait de prise directe sur ce risque. Leur propre posture de sécurité, aussi solide soit-elle, ne change rien quand la surface d'attaque qui cède est celle d'un fournisseur d'infrastructure partagé par des centaines de clients.

Ce que ça illustre : la taille et la réputation du client n'offrent aucune protection si la faille se situe chez le fournisseur. La surface d'attaque d'un opérateur partagé devient, de fait, celle de chacun de ses clients.

Incident 5 : Cegedim Santé, la plus grande fuite de données médicales jamais révélée en France

En février 2026, le logiciel MLM de Cegedim Santé, utilisé par des milliers de cabinets médicaux à travers la France, a été compromis. L'attaque ne visait aucun hôpital ni aucune clinique : elle visait le SaaS qui les reliait tous.

Résultat : 15 millions de dossiers patients exposés, la plus grande fuite de données médicales jamais révélée dans le pays.

Aucun des cabinets médicaux concernés n'avait été négligent. Chacun avait simplement fait le choix, raisonnable en apparence, d'utiliser un logiciel mutualisé pour la gestion de ses dossiers patients. La faille n'était nulle part chez eux : elle était dans l'infrastructure partagée qui les connectait tous.

Ce que ça illustre : un fournisseur mutualisé, utilisé par un grand nombre de clients de petite taille, devient une cible à très fort effet de levier pour un attaquant. Plus le nombre de clients dépendant d'un même fournisseur est élevé, plus l'incitation à le cibler directement augmente.

En résumé : les questionnaires annuels capturent ce que le fournisseur sait de lui-même, à un instant T. Le cloud change continuellement. Les deux sont incompatibles.

La logique du questionnaire TPRM est simple : vous demandez à votre fournisseur de décrire sa posture de sécurité, il répond, vous évaluez les risques, vous classez le niveau de criticité. C'est une méthode pensée pour évaluer les risques liés aux fournisseurs à un instant donné, pas pour gérer les risques en continu dans un environnement qui change chaque semaine. Le problème est que cette logique repose sur deux hypothèses qui ne tiennent plus dans un environnement cloud.

La première : que la posture d'un fournisseur est stable dans le temps. Une nouvelle instance déployée, une intégration ajoutée, un token créé pour un projet et oublié là : dans un environnement cloud actif, la surface d'attaque change chaque semaine. Ce qu'un fournisseur déclarait en janvier ne correspond plus forcément à ce qu'il expose en juin.

La seconde : que les fournisseurs savent eux-mêmes ce qu'ils exposent. Ce n'est pas toujours le cas. Un bucket S3 mal configuré par une équipe dev, un sous-domaine ouvert pour un projet pilote, une API de test jamais désactivée : ces actifs existent, sont accessibles depuis internet, et le responsable sécurité du fournisseur n'en sait peut-être rien quand il remplit votre questionnaire.

Gartner l'a documenté en 2026 : 62 % des organisations font encore trop confiance à ces auto-déclarations. Le résultat est prévisible : 97 % ont subi une violation via leur chaîne d'approvisionnement la même année.

"Un questionnaire te dit ce que le fournisseur croit exposer. Un scan externe te dit ce qu'il expose vraiment. La différence entre les deux, c'est souvent là que l'incident commence.", note Florent Montel, cofondateur et CFO de Patrowl.

En résumé : le questionnaire annuel n'est plus seulement insuffisant opérationnellement, il ne satisfait plus les exigences réglementaires.

DORA, en vigueur depuis janvier 2025 pour les entités financières, impose une gestion formalisée des risques ICT tiers. Registre des fournisseurs critiques, surveillance continue, plans de sortie testés, droits d'audit contractualisés. Les fournisseurs SaaS qui traitent des fonctions ou des données critiques entrent dans le scope, y compris les outils de gestion de la relation client, les plateformes RH, les outils de collaboration.

NIS2 étend ces obligations à un périmètre plus large : entités essentielles et importantes dans l'énergie, les transports, la santé, les infrastructures numériques. La chaîne d'approvisionnement numérique est explicitement dans le scope. Un incident chez un fournisseur qui affecte une entité couverte peut entraîner des obligations de notification dans les 24 heures et une mise en cause de la responsabilité de l'entité sur sa gestion du risque tiers.

Pour les directions des risques et de la conformité, ces textes transforment le TPRM en obligation avec des conséquences financières directes. Les programmes de gestion des tiers TPRM ne peuvent plus se contenter d'une revue annuelle. L'enjeu n'est plus seulement de réduire le risque, c'est de démontrer que la surveillance est continue et documentée.

"Ce qu'on voit avec nos clients sous DORA, c'est que la question n'est plus 'est-ce qu'on surveille nos fournisseurs' mais 'est-ce qu'on peut le prouver à l'auditeur'. La surveillance continue, c'est aussi une réponse à ça.", note Nicolas Mattiocco, cofondateur et CEO de Patrowl.

La réponse opérationnelle ne passe pas par plus de questionnaires. Elle passe par une visibilité externe sur la posture réelle des fournisseurs tiers, la même visibilité qu'un attaquant aurait s'il scannait leur périmètre avant de les cibler. Voici comment mettre en place cette surveillance étape par étape.

1. Inventoriez vos fournisseurs par niveau d'accès réel

Avant de surveiller, savoir quoi surveiller. Listez tous vos fournisseurs cloud et classez-les selon ce qu'ils peuvent atteindre dans votre SI s'ils sont compromis, pas selon la valeur du contrat.

• Niveau critique : fournisseurs avec accès direct à vos données ou à votre infrastructure (tokens OAuth, connexions API, accès VPN, hébergement de données clients)

• Niveau élevé : fournisseurs avec accès indirect ou accès limité (outils de collaboration, plateformes RH, outils marketing)

• Niveau standard : fournisseurs sans accès à votre SI (prestataires logistiques, services généraux)

Un outil SaaS à 500 euros par mois avec des tokens OAuth vers votre CRM est plus critique qu'un prestataire logistique à 500 000 euros sans accès numérique. La tiérisation doit refléter l'accès réel, pas la valeur contractuelle.

2. Cartographiez ce que chaque fournisseur critique expose depuis internet

Pour chaque fournisseur de niveau critique et élevé, réalisez une cartographie externe de ce qu'il expose publiquement, sans accès à ses systèmes, depuis l'extérieur, exactement comme un attaquant le ferait.

• Sous-domaines actifs : via les certificats SSL publics (outils : crt.sh, Amass, Subfinder)

• Services exposés : ports ouverts, APIs accessibles, interfaces d'administration (outils : Shodan, Censys)

• Certificats SSL : dates d'expiration, domaines couverts, certificats wildcard (certificats qui couvrent tous les sous-domaines d'un domaine, ex : *.patrowl.io)

• Technologies utilisées : stack identifiable via les headers HTTP, les fichiers robots.txt, les offres d'emploi publiées

• Credentials exposés : fuites dans les bases de données publiques (HaveIBeenPwned, DeHashed)

Ce qu'on trouve surprend souvent : des sous-domaines de projets pilotes jamais fermés, des instances cloud créées pour un test et abandonnées, des APIs sans authentification héritées d'une ancienne version du service. Des éléments que le fournisseur lui-même ne sait parfois plus qu'il expose.

2bis. Cartographiez aussi les fournisseurs de vos fournisseurs : le Nth-party risk

Le Nth-party risk désigne le risque introduit par les sous-traitants de vos prestataires directs. C'est la partie la plus difficile à maîtriser, et souvent la plus exploitée.

Dans l'attaque Cleo de 2025, Hertz et Kellogg n'utilisaient pas Cleo directement. Leurs prestataires logistiques l'utilisaient. L'attaquant n'avait besoin de compromettre qu'un seul maillon pour toucher des dizaines d'entreprises en bout de ligne.

Pour cartographier ce risque :

• Demandez à vos fournisseurs critiques la liste de leurs propres sous-traitants qui ont accès aux données ou services qu'ils vous délivrent

• Identifiez les logiciels tiers intégrés dans les services que vous utilisez : outils de transfert de fichiers, plateformes de paiement, SDK embarqués

• Surveillez les CVE publiées sur ces logiciels tiers : une vulnérabilité dans un outil utilisé par votre fournisseur vous concerne directement, même si vous n'utilisez pas cet outil vous-même

• Intégrez une clause contractuelle obligeant vos fournisseurs critiques à vous notifier tout changement de sous-traitant ayant accès à vos données

Vous ne pouvez pas cartographier l'intégralité de la chaîne sans outillage dédié. Mais identifier les deux ou trois niveaux les plus proches de vos données critiques est déjà un gain de visibilité significatif.

3. Évaluez les vulnérabilités connues sur les actifs identifiés

Une fois les actifs cartographiés, croisez-les avec les bases de vulnérabilités connues pour identifier les expositions critiques.

• CVE actives sur les technologies détectées : versions de serveurs web, frameworks identifiables, CMS exposés

• Configurations à risque : headers de sécurité absents, CORS mal configuré (Cross-Origin Resource Sharing : mécanisme qui contrôle quels domaines peuvent appeler vos APIs), authentification basique sur des services sensibles

• Certificats expirés ou proches de l'expiration : un certificat expiré est un signal de négligence opérationnelle, souvent corrélé à d'autres retards de maintenance

• Ports exposés non standard : services de gestion accessibles depuis internet (port 8443, 9200, 3389, 22 sans restriction IP)

Priorisez les CVE avec un score CVSS (indice de sévérité standardisé, de 0 à 10) supérieur à 7 sur des services directement accessibles. Ce sont celles qu'un attaquant exploiterait en premier.

4. Vérifiez les accès délégués actifs dans votre SI

La surveillance externe regarde ce que vos fournisseurs exposent depuis internet. Cette étape complète l'angle inverse : ce que vous leur avez autorisé côté votre propre infrastructure. Les deux ensembles forment la surface d'attaque réelle, l'un sans l'autre laisse un angle mort.

• Tokens OAuth actifs : listez toutes les applications tierces autorisées dans vos outils (Google Workspace, Microsoft 365, Salesforce, HubSpot) et vérifiez que chaque autorisation est toujours nécessaire

• Clés API actives : identifiez toutes les clés API émises vers des tiers, leurs droits d'accès et leur date de dernière utilisation

• Webhooks actifs : cartographiez les webhooks sortants vers des endpoints tiers et vérifiez leur destination

• Accès VPN et comptes de service : listez les accès tiers actifs à votre réseau, avec date de dernière connexion et justification

Révoquez sans hésiter tout accès délégué qui n'est plus actif ou dont le fournisseur n'a plus de contrat actif. Les tokens OAuth et clés API orphelins sont une des surfaces d'attaque les plus fréquemment exploitées.

5. Mettez en place une surveillance continue des changements

La cartographie initiale est un point de départ. Ce qui compte, c'est de détecter les changements entre deux états : un nouveau sous-domaine ouvert, un service qui apparaît sur un port non standard, un certificat qui expire.

• Fréquence minimale recommandée : hebdomadaire pour les fournisseurs critiques, mensuelle pour les fournisseurs de niveau élevé

• Alertes sur nouveaux actifs exposés : tout nouveau sous-domaine ou service détecté chez un fournisseur critique doit déclencher une vérification

• Alertes sur CVE critiques : surveillance des nouvelles CVE sur les technologies identifiées chez vos fournisseurs

• Alertes sur expiration de certificats : 30 jours avant expiration pour les fournisseurs critiques

Un changement non planifié dans l'exposition d'un fournisseur est souvent le premier signal visible d'un incident en cours ou d'une négligence opérationnelle qui crée une fenêtre d'attaque.

6. Validez les expositions critiques avec une vérification humaine

Les scanners automatisés génèrent du bruit. Une CVE détectée n'est pas forcément exploitable dans le contexte réel du fournisseur. Avant d'escalader une alerte ou de contacter un fournisseur, validez que l'exposition est réellement critique.

• Confirmez l'exploitabilité réelle : est-ce que la CVE s'applique à la version précise utilisée ? Est-ce que le service est réellement accessible depuis internet ou filtré ?

• Évaluez l'impact potentiel sur votre SI : si ce service est compromis, quels accès à votre infrastructure le fournisseur détient-il ?

• Documentez chaque finding validé : date de détection, description, niveau de criticité, fournisseur concerné, accès potentiellement impactés

Cette étape de validation humaine est ce qui distingue une surveillance opérationnelle d'une avalanche d'alertes non qualifiées. C'est aussi ce que les auditeurs DORA et NIS2 vérifieront.

"Un scanner peut te dire qu'un port 8443 est ouvert chez ton fournisseur. Il ne peut pas te dire si c'est une interface d'admin sans authentification ou un service interne filtré. C'est là que l'œil du pentesteur fait la différence, entre une alerte qui compte et du bruit qui épuise l'équipe.", complète Vladimir Kolla, cofondateur et CTO de Patrowl.

7. Intégrez le résultat dans votre programme TPRM et votre documentation réglementaire

La surveillance externe des fournisseurs n'est utile que si elle s'intègre dans un processus décisionnel.

• Mettez à jour le registre des fournisseurs avec les résultats de chaque cycle de surveillance

• Documentez les findings et les actions correctives demandées aux fournisseurs (avec délais et suivi)

• Intégrez les alertes critiques dans votre processus d'incident response : un fournisseur avec une CVE critique exploitable doit déclencher les mêmes réflexes qu'un incident interne

• Produisez un reporting trimestriel pour la direction des risques et le COMEX : nombre de fournisseurs surveillés, findings ouverts, findings résolus, tendances

Un tableau de bord centralisé, mis à jour à chaque cycle de surveillance, permet de visualiser en un coup d'œil les risques associés à chaque fournisseur critique et de prioriser les actions correctives sans avoir à reconstruire l'information à chaque audit.

Pour les organisations sous DORA, ce reporting constitue une partie de la documentation exigée pour démontrer la gestion active du risque tiers ICT.

En résumé : surveiller vos fournisseurs comme vous vous surveillez vous-même, depuis l'extérieur, en continu, avec validation humaine sur les findings critiques, et documentation intégrée à votre programme TPRM.

Les programmes TPRM qui s'appuient sur des questionnaires et des audits ponctuels opèrent avec un angle mort structurel : ils ne voient que ce que les fournisseurs leur montrent, au moment de l'évaluation. Entre deux évaluations, ils naviguent à l'aveugle.

Patrowl aborde le problème depuis l'extérieur. En cartographiant en continu la surface d'attaque des fournisseurs critiques, grâce à notre module d'EASM, sans accès à leurs systèmes, sans questionnaire, sans dépendre de leur bonne foi, l'approche donne une visibilité sur ce qu'un attaquant verrait s'il ciblait votre chaîne d'approvisionnement.

Sous-domaines exposés, certificats arrivant à expiration, services cloud mal configurés, APIs sans authentification, instances oubliées d'anciens projets. Tout ce qui est visible depuis internet côté fournisseur est identifié et suivi en temps réel. Chaque anomalie critique est vérifiée par un pentesteur certifié avant de remonter à vos équipes. Pas du scoring automatique : une validation humaine.

Pour les organisations sous DORA ou NIS2, cette surveillance continue produit aussi la traçabilité documentée que les régulateurs exigent pour démontrer une gestion active du risque tiers.

"Le ROI de la visibilité externe sur vos fournisseurs, c'est simple : soit vous dépensez pour surveiller, soit vous dépensez pour gérer l'incident. La deuxième option coûte en moyenne 4,8 millions de dollars et votre réputation.", conclut Florent Montel, cofondateur et CFO de Patrowl.

Savez-vous ce qu'un attaquant verrait de vos fournisseurs cloud critiques en 15 minutes ?

Pendant longtemps, sécuriser son SI voulait dire sécuriser ce qu'on possède. Ses serveurs, ses applications, ses réseaux. Le périmètre avait une forme claire.

Le cloud a changé cette forme. Aujourd'hui, une partie de votre SI tourne chez des fournisseurs que vous n'administrez pas. Des données critiques transitent par des outils que vos équipes n'ont pas déployés. Des connexions de confiance ont été ouvertes pour des projets qui ont changé depuis.

Le résultat : votre périmètre réel est plus large que ce que vous croyez. Et la partie que vous ne voyez pas est précisément celle que les attaquants cherchent en premier.

La question n'est pas de savoir si vos fournisseurs seront ciblés. C'est de savoir si vous le saurez avant qu'ils servent de porte d'entrée vers votre SI, et si vous aurez une fenêtre pour agir.

Qu'est-ce que le TPRM en cybersécurité ?

Le TPRM (Third Party Risk Management) désigne les processus permettant d'identifier, évaluer et surveiller les risques cyber introduits par les fournisseurs et prestataires. En 2025, la part des violations impliquant un tiers a doublé à 30 % selon Verizon. DORA et NIS2 en ont fait une obligation réglementaire formalisée avec des exigences de surveillance continue.

Comment un fournisseur cloud compromis peut-il affecter mon organisation ?

Via les accès qu'il détient sur votre infrastructure : tokens OAuth, connexions API, webhooks, accès VPN. Quand ces accès sont utilisés depuis l'environnement compromis du fournisseur, le trafic apparaît légitime dans vos logs. C'est ce qui s'est passé avec Salesloft Drift en 2025 : 700 organisations impactées sans aucune alerte côté client. Le fournisseur peut aussi servir de vecteur via les logiciels qu'il utilise lui-même pour vous délivrer son service.

Pourquoi le TPRM classique ne suffit plus face aux menaces cloud ?

Parce qu'il capture un état figé. Un fournisseur peut répondre parfaitement à son questionnaire en janvier et avoir un service mal configuré ouvert en mars. Dans un environnement cloud qui change continuellement, la seule réponse pertinente est la surveillance externe continue. 62 % des organisations font encore trop confiance aux auto-déclarations selon Gartner 2026, avec les résultats qu'on connaît.

Quelles obligations réglementaires encadrent le risque fournisseur cloud en France ?

DORA (en vigueur depuis janvier 2025) impose aux entités financières une surveillance continue des fournisseurs ICT critiques, des registres formalisés et des droits d'audit contractualisés. NIS2 étend ces obligations à un périmètre plus large incluant la chaîne d'approvisionnement numérique. Dans les deux cas, le questionnaire annuel ne satisfait plus les exigences : la surveillance doit être continue et documentée.

Qu'est-ce que le Nth-party risk et pourquoi est-il difficile à gérer ?

Le Nth-party risk désigne le risque introduit par les fournisseurs de vos fournisseurs. Dans l'attaque Cleo de 2025, Hertz et Kellogg n'utilisaient pas Cleo directement : leurs prestataires l'utilisaient. L'attaquant n'avait besoin de compromettre qu'un seul maillon pour toucher des dizaines d'entreprises. Cartographier ce risque sans outillage dédié est pratiquement impossible : une organisation avec 286 fournisseurs en moyenne ne connaît qu'une fraction des outils que ces fournisseurs utilisent eux-mêmes.

Comment Patrowl aide à gérer le risque des fournisseurs cloud ?

Patrowl cartographie en continu la surface d'attaque externe de vos fournisseurs critiques, sans accès à leurs systèmes et sans questionnaire. L'approche identifie ce qu'un attaquant verrait depuis internet côté fournisseur : actifs exposés, certificats expirés, services mal configurés, APIs sans authentification. Chaque anomalie critique est validée par un pentesteur avant de remonter à vos équipes. La surveillance continue répond aussi aux exigences documentaires de DORA et NIS2.

Verizon Data Breach Investigations Report 2025 · SecurityScorecard Global Third-Party Breach Report 2025 · CybelAngel "Every Vendor is a Vector" 2026 · Gartner Predicts 2026 · Reco AI "AI & Cloud Security Breaches 2025" · ANSSI Panorama de la cybermenace 2025 · IBM Cost of a Data Breach 2025