Threat modeling avec STRIDE

Le threat modeling avec STRIDE est la technique la plus employée pour anticiper les menaces sur un système avant de l'avoir construit. En 45 minutes d'atelier, une équipe identifie des failles architecturales que les outils automatiques ne détecteront jamais — parce que ce sont des choix de conception, pas des bogues de code. Le chapitre en a posé le cadre conceptuel celui-ci en fait une pratique.

Pourquoi STRIDE plutôt qu'autre chose

STRIDE est simple à enseigner, simple à appliquer en équipe, et couvre les menaces les plus courantes des systèmes web et natifs du cloud. Ses six catégories correspondent directement à des contrôles techniques que les développeurs connaissent déjà, ce qui évite d'introduire un vocabulaire de sécurité déconnecté du code.

Six lettres, six contrôles — le vocabulaire reste celui des développeurs.

Une session en quatre étapes

Une session efficace suit toujours le même déroulé, qu'elle dure trente minutes ou une demi-journée. Le chronométrage ci-dessous correspond à une fonctionnalité de taille moyenne il se multiplie pour un changement d'architecture complet.

Quatre étapes qui répondent aux quatre questions du Threat Modeling Manifesto.

Le diagramme de flux minimal

Nul besoin d'outil dédié pour démarrer : un tableau blanc suffit largement pour la première session. Ce qui compte est de représenter clairement les éléments qui traversent une frontière de confiance, pas de produire un schéma esthétique. Un diagramme utile fait apparaître les acteurs (utilisateur, service externe, administrateur), les composants (application, base de données, cache, file), les flux de données (requêtes HTTP, appels SQL, messages) et les limites de confiance.

[Utilisateur] --HTTPS--> [Passerelle API] --appel interne--> [Service Auth]
                                |                                  |
                        limite de confiance                [Base de données]
                                |
                       [Service Profil] --------------> [Base de données]

Chaque flux qui franchit une limite de confiance est candidat à une analyse STRIDE. Un flux interne entre deux composants qui se font mutuellement confiance mérite moins d'attention qu'un flux traversant la frontière entre l'utilisateur et votre système.

Exemple appliqué : une API d'authentification

Prenons une API d'authentification classique fondée sur des jetons JWT — des jetons signés qui transportent l'identité de l'utilisateur. L'exemple suivant traite une catégorie de bout en bout, pour montrer le niveau de détail attendu.

Le même travail se répète sur les cinq autres lettres : altération des données en transit, absence de trace exploitable en cas de contestation, exposition de données sensibles dans les réponses ou les logs, saturation du service d'authentification, et escalade de privilèges par manipulation des rôles portés par le jeton. Aucune catégorie ne doit être sautée par habitude.

Intégrer STRIDE au flux agile

L'enjeu est de le répéter souvent, en petit format, plutôt que d'organiser un grand exercice annuel vite oublié.

Trois moments, trois formats — le plus fréquent est aussi le plus court.

Definition of Done (extrait)
[ ] threat modeling STRIDE réalisé et documenté dans le ticket
[ ] menaces critiques mitigées, ou acceptées explicitement
[ ] tickets de sécurité créés pour les mitigations non urgentes

Les erreurs courantes

Les outils assistés par IA

Depuis 2023, des outils fondés sur des modèles de langage accélèrent la première étape : transformer une description d'architecture en un premier jet de menaces, de scores et de tests à écrire, dans des formats exploitables. Ils ne remplacent pas la session collaborative : un modèle qui reçoit une description vague produit des menaces génériques, sans lien avec les vraies limites de confiance, et peut manquer un flux critique que l'équipe connaît par cœur.

Quant au passage du tableau blanc à un outil dédié, il devient pertinent quand deux signaux apparaissent ensemble : l'équipe maîtrise les quatre étapes sans les relire, et le volume de sessions augmente sur des systèmes qui partagent des composants. Un outil permet alors de conserver l'historique des diagrammes et des menaces d'une session à l'autre.

Du threat modeling au pipeline

Le threat modeling identifie des risques de conception. Beaucoup peuvent être traduits en vérifications automatiques, ce qui transforme une décision ponctuelle en garde-fou permanent.

Chaque menace de conception peut devenir une vérification permanente.