Modélisation des menaces pour les équipes SaaS : deux ateliers, un schéma, un registre que vous utiliserez vraiment

La plupart des équipes SaaS découvrent leurs menaces dans un rapport de test d'intrusion ou lors d'un incident. La modélisation des menaces déplace cette découverte sur un tableau blanc, avant que le code n'existe ou avant la prochaine version, et elle coûte deux ateliers. La méthode ci-dessous est celle que nous menons avec les équipes produit : dessiner le système comme un diagramme de flux de données avec des frontières de confiance, passer STRIDE sur chaque frontière, construire un arbre d'attaque pour l'actif qui compte le plus, classer ce qu'on a trouvé sur une carte de chaleur, et repartir avec un registre qui a des responsables. Aucun outil n'est nécessaire au-delà d'un tableau blanc et des composants de cet article.

Atelier 1 : dessiner le système en flux de données

Les pointillés autour de « Notre VPC » et « Tiers » sont les frontières de confiance, et chaque flux qui en traverse une est l'endroit où vit une menace. Quatre-vingt-dix minutes suffisent pour un diagramme de niveau 1 de la plupart des produits ; la discussion sur l'emplacement réel des frontières (le fournisseur LLM est-il dans votre zone de confiance ? le webhook de paiement ?) est la partie la plus précieuse de la séance.

Où le système est exposé

L'anneau dit quelque chose que le diagramme de flux ne dit pas : trois des huit points d'entrée ne sont pas du code exposé aux clients (CI/CD, accès des ingénieurs, console cloud), et les statistiques d'incidents confirment que c'est là que commencent la plupart des compromissions de SaaS.

STRIDE sur chaque frontière

Pour chaque flux qui traverse une frontière, poser les six questions STRIDE : l'émetteur peut-il être usurpé (Spoofing), les données altérées (Tampering), l'action niée (Repudiation), l'information divulguée (Information disclosure), le service refusé (Denial of service), les privilèges élevés (Elevation) ? Écrit dans un tableau, cela ressemble à un devoir ; dit à voix haute devant le schéma, cela prend quarante minutes et produit la liste brute du registre ci-dessous. Les trouvailles classiques d'un SaaS sont l'isolation des locataires (un identifiant dans l'URL non vérifié contre le locataire de la session), l'usurpation de webhook, des URL présignées qui survivent à la session de l'utilisateur, et l'injection de prompt par du contenu client envoyé au LLM.

Atelier 2 : un arbre d'attaque pour l'actif qui compte

Le chemin surligné est le moins cher, et d'après notre expérience la trouvaille la plus fréquente d'un premier modèle de menaces SaaS : une référence directe non sécurisée où la vérification du locataire vit dans l'interface plutôt que dans la requête. Un WHERE tenant_id = :session_tenant sur chaque requête, imposé par la couche d'accès aux données, coupe la branche.

Classer ce qu'on a trouvé

La vraisemblance, c'est « à quelle fréquence cela arrive-t-il à des entreprises comme nous », pas « est-ce possible » ; l'impact s'exprime dans les termes du client (ses données, son argent, son régulateur). Les flèches vers les cibles sont les contrôles que vous vous apprêtez à engager, ce qui fait de la carte de chaleur une conversation budgétaire autant que sécuritaire.

Les deux séances, heure par heure

Qui est dans la salle : le tech lead, un développeur qui connaît la couche de données, une personne produit qui connaît les promesses faites aux clients, une personne exploitation ou sécurité, et un animateur. Six personnes au maximum ; au-delà, le schéma cesse d'être dessiné et commence à être présenté.

Ce avec quoi vous repartez

Un registre de sept lignes, chacune avec un nom et un statut, vaut plus qu'un rapport de quarante pages que personne n'ouvre. Relisez-le à chaque changement d'architecture significatif et une fois par trimestre ; un modèle de menaces est un document vivant ou il n'est rien.

En résumé

La modélisation des menaces est bon marché quand c'est une conversation autour d'un schéma et coûteuse quand c'est un livrable. Deux ateliers, un diagramme de flux de données, un arbre d'attaque et un registre avec des responsables donnent à une équipe SaaS l'essentiel de ce qu'une méthode formelle promet, et font remonter la trouvaille présente dans presque chaque premier modèle : l'isolation des locataires imposée dans la mauvaise couche. Pour la suite du registre, nos articles sur la liste de contrôle d'audit de sécurité cloud et la sécurisation de la CI/CD prennent le relais.

Sources : Shostack, Threat Modeling: Designing for Security ; le Threat Modeling Manifesto ; OWASP Threat Modeling et OWASP Top 10 pour les applications LLM ; documentation STRIDE de Microsoft ; statistiques d'accès initial du Sophos State of Ransomware 2026 et du Verizon DBIR 2026. Lus le 15 octobre 2026.