En huit mois, le même groupe a percé Instructure trois fois. Pendant ce temps, des centaines d'écoles signent des contrats SaaS sans même savoir qui héberge leurs données. On a déporté la valeur business dans le cloud sans déporter la responsabilité cyber. Le résultat est désormais sous nos yeux : la fuite n'est plus un événement, c'est un service récurrent.

Le problème n'est plus le périmètre, c'est l'agrégation

Pendant vingt ans, les RSSI ont durci des périmètres. Pare-feu, EDR, SIEM, ZTNA — tout ce qu'il faut pour contrôler ce qui entre et sort. Très bien. Sauf qu'aujourd'hui, 70 % de la valeur business d'une organisation moyenne ne réside plus derrière ce périmètre. Elle est chez Salesforce, chez Workday, chez Notion, chez Instructure, chez n'importe quel fournisseur SaaS dont le contrat tient sur une page et dont le SOC 2 Type II n'a jamais été lu en interne.

Le problème n'est même plus que ces fournisseurs soient mal sécurisés individuellement. Le problème, c'est qu'ils agrègent. Quand ShinyHunters compromet Instructure, ils ne touchent pas une école — ils touchent 9 000 écoles d'un coup. Quand un opérateur Salesforce se fait piéger via OAuth, ce ne sont pas dix entreprises qui sont exposées, c'est l'ensemble du portefeuille du fournisseur qui passe en ligne de fuite potentielle. L'économie SaaS a créé des points de concentration de risque dont l'ampleur n'avait pas d'équivalent dans le monde on-premise.

Le SOC 2 ne vous sauvera pas

Je vois passer des dizaines de questionnaires de tiers chaque mois en mission. La grande majorité demande la même chose : "Êtes-vous conforme à SOC 2 ? Avez-vous ISO 27001 ? Faites-vous des pentests annuels ?". Cases cochées, contrat signé, on passe à la suite. Personne ne vérifie ce que ces certifications couvrent réellement.

SOC 2 Type II atteste qu'un fournisseur a mis en place les contrôles qu'il a lui-même définis et qu'il les applique depuis quelques mois. Ça ne dit rien sur la qualité des contrôles, ni sur leur pertinence face à un attaquant motivé. Un fournisseur peut être SOC 2 et ne pas appliquer le MFA sur ses comptes admin. C'est légal, c'est conforme, c'est documenté. Et ça finit par 3,65 To de données sur un site de leak.

La même critique vaut pour ISO 27001. Le standard est utile pour structurer un SMSI, mais il ne mesure pas la robustesse face à un attaquant moderne. Combien de certifiés ISO 27001 ont été compromis ces deux dernières années ? Faites le compte. La liste est longue.

Le pattern OAuth, la nouvelle porte d'entrée préférée

Trois des plus grosses opérations cybercriminelles de ces derniers mois — celles attribuées à ShinyHunters — partagent un même vecteur : l'abus de l'écosystème Salesforce via des tokens OAuth volés ou détournés. Le mécanisme est connu, documenté, simple à comprendre. Et pourtant, dans 90 % des organisations que j'audite, la gouvernance des intégrations OAuth est inexistante.

Concrètement : combien de tokens OAuth actifs avez-vous dans votre tenant Microsoft 365, Google Workspace ou Salesforce ? À quels scopes donnent-ils accès ? Quand ont-ils été créés ? Par qui ? Sont-ils encore utilisés ? Une grande partie des fuites SaaS actuelles n'exploite pas une vulnérabilité technique mais une dette de gouvernance : un token créé en 2022 pour une intégration de POC oubliée, jamais révoqué, qui donne accès à l'intégralité des objets Salesforce d'une organisation.

C'est exactement le genre de chose que personne ne pense à auditer. Et c'est exactement le genre de chose qui apparaît dans les chronologies post-incident des grosses fuites SaaS de 2025-2026.

Mon avis d'expert

Le modèle de responsabilité partagée que pratiquent les éditeurs SaaS est devenu une fiction confortable pour tout le monde. L'éditeur dit "vous êtes responsable de la configuration et des accès". Le client dit "j'ai signé un SOC 2, l'éditeur est responsable de la sécurité de la plateforme". Au milieu, personne ne fait le travail. Et quand l'incident arrive, on découvre que la "responsabilité partagée" se traduit en pratique par une responsabilité diluée — c'est-à-dire personne. Tant que les contrats SaaS ne contiendront pas d'engagement de moyens techniques vérifiables et de pénalités significatives en cas de fuite, la situation continuera de se dégrader. Et les RSSI continueront d'hériter d'une exposition dont ils n'ont jamais eu les leviers de contrôle.

Ce qu'il faut commencer à faire maintenant

Cartographier. Avant tout. Combien d'applications SaaS utilisez-vous réellement ? Pas combien vous avez de contrats — combien d'applications. Dans une PME de 200 personnes que j'ai auditée récemment, la DSI déclarait 18 applications SaaS. Le scan effectif via les logs de proxy en a remonté 147. Le shadow SaaS est partout, et chaque application non gouvernée est un canal d'exfiltration potentiel.

Ensuite, gouverner les intégrations. Pas seulement les comptes utilisateurs : les tokens machine, les service accounts, les OAuth apps. Avec une vraie procédure de revue trimestrielle, et une révocation par défaut au bout de X mois sans usage. Microsoft 365 propose désormais des reports natifs sur les applications OAuth actives ; Salesforce aussi. Personne ne les lit.

Tester la résilience, pas la conformité

Sortez du cycle questionnaire-checklist-audit. Demandez à vos fournisseurs critiques : "Que se passe-t-il pour mes données si vous êtes ransomé demain ? Avez-vous un plan de continuité testé ? Combien de temps mes données seraient-elles indisponibles ? Sous quelle forme me les restitueriez-vous ?" Ces questions n'apparaissent jamais dans les RFP standardisés. Elles devraient.

Prévoir le pire

Vos meilleurs fournisseurs SaaS vont être compromis. Pas peut-être : sûrement. La question est de savoir comment vous, en tant qu'organisation cliente, allez réagir le jour où ça arrivera. Avez-vous une procédure de réponse à un incident chez un fournisseur ? Avez-vous identifié les communications à envoyer à vos propres parties prenantes ? Savez-vous quoi répondre à vos clients qui demanderont si leurs données étaient stockées chez ce fournisseur ?

La plupart des organisations découvrent ces questions le lundi matin, dans l'urgence, en lisant un communiqué de presse de leur fournisseur. C'est beaucoup trop tard.

Conclusion

Le SaaS-mageddon n'est pas un événement futur. Il est en cours, par vagues. Instructure trois fois, Snowflake, MOVEit, Okta, Cushman & Wakefield, des dizaines d'autres dans les douze derniers mois. Chaque vague emporte des centaines, parfois des milliers d'organisations clientes qui découvrent rétroactivement la dépendance qu'elles avaient construite.

L'industrie cyber n'a pas encore digéré ce changement de paradigme. Les RSSI sont mesurés sur des KPI hérités de l'ère on-premise : disponibilité du SIEM, taux de couverture EDR, MTTR sur les incidents internes. Personne n'est mesuré sur la capacité à anticiper, contenir et récupérer d'une compromission fournisseur — pourtant, c'est devenu le scénario de risque numéro un pour la plupart des organisations.

La bonne nouvelle, c'est qu'il y a encore de la marge pour faire mieux. La mauvaise, c'est que ça commence par accepter que la sécurité périmétrique classique ne suffit pas, et que cartographier ses fournisseurs SaaS est aussi important que cartographier son réseau interne. Beaucoup d'entreprises n'ont pas encore fait ce saut conceptuel. Elles le feront — dans l'ordre, ou dans la panique.

Besoin d'un regard expert sur votre exposition SaaS ?

Discutons de votre cartographie fournisseurs, de votre gouvernance OAuth et de votre plan de réponse à un incident tiers.

Prendre contact