Threat modeling avec STRIDE : guide pratique DevSecOps

Le threat modeling avec STRIDE est la technique la plus utilisée pour anticiper les menaces sur un système avant de l'avoir construit. En 45 minutes de refinement, une équipe identifie des failles architecturales que les outils automatiques ne détecteront jamais, parce que ce sont des choix de conception, pas des bugs de code. Ce guide s'adresse aux équipes DevSecOps qui veulent intégrer STRIDE au quotidien, pas seulement le connaître en théorie : méthode en 4 étapes, exemple complet sur une API JWT couvrant les 6 catégories de menaces, place des outils assistés par IA, et intégration au backlog agile.

Lien avec le cadre conceptuel

Ce guide est la suite pratique du cadre conceptuel présenté dans Menaces, risques et vulnérabilités. Si vous n'avez pas encore lu ce guide, commencez par là.

---

Ce que vous allez apprendre

• Comprendre les 6 catégories STRIDE et le contrôle technique associé à chacune
• Conduire une session de threat modeling en 4 étapes chronométrées
• Construire un Data Flow Diagram (DFD) minimal et identifier les limites de confiance
• Appliquer STRIDE de bout en bout sur un exemple réaliste d'API d'authentification
• Situer la place des outils assistés par IA dans la démarche, sans leur déléguer la décision
• Traduire les menaces identifiées en user stories de sécurité et en vérifications CI/CD

---

Pourquoi STRIDE et pas autre chose

STRIDE est simple à enseigner, simple à appliquer en équipe et couvre les menaces les plus courantes dans les systèmes web et Cloud Native. Ses 6 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.

Lettre	Catégorie	Contre quoi	Contrôle associé
S	Spoofing	Usurpation d'identité	Authentification forte
T	Tampering	Altération de données	Intégrité, signatures
R	Repudiation	Non-traçabilité des actions	Journalisation, audit trails
I	Information Disclosure	Exposition de données sensibles	Chiffrement, contrôle d'accès
D	Denial of Service	Indisponibilité	Rate limiting, circuit breakers
E	Elevation of Privilege	Escalade de droits	Moindre privilège, RBAC

Glissez pour voir

Le Threat Modeling Manifesto, référence citée par la fiche threat modeling de l'OWASP, résume toute démarche à 4 questions : sur quoi travaillons-nous, qu'est-ce qui peut mal tourner, que faisons-nous à ce sujet, et avons-nous fait du bon travail. Les 4 étapes détaillées plus loin répondent directement à ces questions, dans un format chronométré adapté au rythme d'un sprint.

Quand utiliser STRIDE : idéal pour les nouvelles fonctionnalités, les changements d'architecture ou les intégrations avec des systèmes externes. Pas pour auditer du code déjà en production : les scanners de code statique (SAST, pour Static Application Security Testing) font mieux pour ça.

---

Les 4 étapes d'une session de threat modeling

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

1. Décrire le système : construire un Data Flow Diagram (DFD) simple listant composants, flux de données et limites de confiance (trust boundaries). 10 minutes.

2. Identifier les menaces STRIDE : pour chaque flux et chaque composant, poser la question : quelles catégories STRIDE s'appliquent ici ? 20 minutes.

3. Évaluer et prioriser : pour chaque menace identifiée, évaluer la probabilité et l'impact avec DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability, une grille de notation sur 5 critères qui donne un score de risque) ou simplement Critique/Élevé/Moyen/Faible. 10 minutes.

4. Décider des mitigations : accepter, corriger, transférer. Les corrections deviennent des user stories de sécurité dans le backlog. 10 minutes.

---

Template de DFD minimal

Vous n'avez pas besoin d'un outil dédié pour démarrer. Un tableau blanc ou un Miro suffit largement pour la première session. Ce qui compte, c'est de représenter clairement les éléments qui traversent une frontière de confiance, pas de produire un schéma esthétique.

Un DFD utile fait apparaître :

• Les acteurs (utilisateur, service externe, admin)
• Les composants (application, base de données, cache, queue)
• Les flux de données (requêtes HTTP, appels SQL, messages)
• Les limites de confiance, lignes qui marquent la frontière entre zones de confiance différentes

[Utilisateur] --HTTPS--> [API Gateway] --appel interne--> [Service Auth]
                                    |                           |
                              trust boundary               [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 qui traverse la frontière entre l'utilisateur et votre système.

---

Exemple appliqué : API d'authentification

Prenons une API d'authentification classique avec JWT (JSON Web Token, un jeton signé qui transporte l'identité de l'utilisateur). L'exemple suivant couvre les 6 catégories STRIDE sur ce même système, pour montrer qu'aucune catégorie ne doit être sautée par habitude.

S, Spoofing

Menace : Un attaquant usurpe l'identité d'un utilisateur en rejouant un token JWT expiré ou volé.

Questions à poser :

• Les tokens ont-ils une expiration courte (15 min) ?
• Les refresh tokens sont-ils révocables ?
• Y a-t-il une vérification de l'empreinte client (IP, user-agent) ?

Mitigation :

• JWT avec expiration courte et refresh token stocké en cookie HttpOnly
• Révocation des tokens via liste de blocage en mémoire
• Story backlog : "En tant que système, je dois invalider tous les tokens actifs d'un utilisateur sur demande ou détection d'anomalie"

T, Tampering

Menace : Un attaquant modifie le payload du JWT pour s'octroyer des rôles supplémentaires.

Questions à poser :

• L'algorithme de signature est-il robuste (RS256 ou ES256) ?
• L'API rejette-t-elle les tokens avec alg: none ?
• La clé de signature est-elle bien protégée ?

Mitigation :

• Forcer RS256, rejeter tout autre algorithme
• Secret géré dans un gestionnaire de secrets avec rotation automatique
• Test d'intégration : vérifier que alg: none est rejeté

R, Repudiation

Menace : Un utilisateur nie avoir modifié son adresse e-mail ou initié une action sensible, faute de traçabilité fiable des appels effectués via l'API.

Questions à poser :

• Chaque action sensible (changement de mot de passe, suppression de compte) est-elle journalisée avec un horodatage ?
• Les logs d'audit sont-ils protégés contre une altération a posteriori ?
• L'auteur de l'action est-il lié de façon fiable au token utilisé au moment de l'action ?

Mitigation :

• Audit trail en écriture seule pour les actions sensibles, avec horodatage et identifiant de session
• Hachage chaîné des entrées de log pour détecter toute altération
• Story backlog : "En tant qu'utilisateur, je dois pouvoir consulter l'historique des actions effectuées sur mon compte"

I, Information Disclosure

Menace : Les messages d'erreur exposent le nom d'utilisateur dans les logs : "Mot de passe incorrect pour user@company.com".

Questions à poser :

• Les réponses d'erreur sont-elles génériques côté client ?
• Les logs de production contiennent-ils des données personnelles ou des credentials ?
• Les tokens apparaissent-ils dans les URLs (et donc dans les logs de proxy) ?

Mitigation :

• Réponse unique : "Identifiants incorrects" sans préciser lequel
• Règle de lint dans le pipeline : interdire les patterns password=, token=, secret= dans les logs
• Story backlog : "En tant que développeur, je dois utiliser un logger wrapper qui masque les champs sensibles"

D, Denial of Service

Menace : Un attaquant sature l'endpoint de connexion avec des tentatives de credential stuffing (essais automatisés d'identifiants volés), rendant le service indisponible pour les utilisateurs légitimes.

Questions à poser :

• Existe-t-il une limite de débit (rate limiting) par IP et par compte sur les endpoints d'authentification ?
• Un circuit breaker (un mécanisme qui coupe automatiquement les appels vers un service en train de saturer, pour éviter que la panne se propage) protège-t-il la base de données en cas d'afflux de requêtes ?
• Les tentatives échouées déclenchent-elles un verrouillage temporaire ?

Mitigation :

• Rate limiting par IP et par identifiant de compte, avec backoff progressif
• Détection de credential stuffing via un service de réputation d'IP
• Story backlog : "En tant que système, je dois bloquer temporairement un compte après plusieurs échecs de connexion rapprochés"

E, Elevation of Privilege

Menace : Un utilisateur standard accède à des endpoints admin en manipulant l'URL ou les paramètres.

Questions à poser :

• Les rôles sont-ils vérifiés côté serveur (pas seulement côté client) ?
• Les IDs de ressources sont-ils vérifiables côté serveur (pas de BOLA, Broken Object Level Authorization, la faille qui permet d'accéder aux données d'un autre utilisateur en changeant simplement un identifiant dans l'URL) ?
• L'API a-t-elle un modèle de permissions documenté ?

Mitigation :

• Autorisation vérifiée sur chaque endpoint, pas seulement au login
• UUIDs non séquentiels pour les IDs exposés
• Test d'autorisation systématique dans la suite d'intégration

---

Intégrer le threat modeling dans le flux agile

Le threat modeling n'a pas besoin d'être un processus lourd pour produire de la valeur. L'enjeu est de le répéter souvent, en petit format, plutôt que d'organiser un grand exercice annuel vite oublié.

Dans le refinement (recommandé)

Lors du refinement d'une user story qui introduit un nouveau flux de données ou une nouvelle intégration, ajoutez 10 à 15 minutes de threat modeling :

1. Dessinez le DFD du flux impacté au tableau
2. Passez les 6 lettres STRIDE en 2 minutes chacune
3. Notez les menaces identifiées
4. Créez les stories de sécurité associées dans le même sprint ou dans le backlog de sécurité

Dans la Definition of Done

Ajoutez un critère dans votre Definition of Done (DoD, l'ensemble des conditions qu'une story doit remplir pour être considérée terminée) pour les features qui touchent des données sensibles ou des accès :

- [ ] Threat modeling STRIDE réalisé et documenté dans le ticket
- [ ] Menaces critiques mitigées ou acceptées explicitement
- [ ] Stories de sécurité créées pour les mitigations non urgentes

Lors de la conception d'architecture

Pour les changements d'architecture (nouvelle intégration, nouveau service), organisez une session dédiée de 90 minutes : 20 minutes pour construire le DFD ensemble, 40 minutes pour parcourir STRIDE (5 minutes par catégorie, 2 séquences), 20 minutes pour prioriser et décider, et 10 minutes pour documenter dans l'ADR (Architecture Decision Record, un document court qui trace une décision d'architecture et son contexte).

---

Les erreurs courantes à éviter

Pièges fréquents

Trop vouloir en faire : un threat modeling de 4 heures pour une feature de login n'a pas de sens. La règle : 30 à 60 minutes pour une feature, 90 minutes pour un module, 1 jour pour un système complet.

Modéliser sans décider : identifier des menaces sans les prioriser ni les traiter revient à faire du théâtre de sécurité. Chaque session doit se terminer avec des décisions.

Ne pas impliquer les développeurs : le threat modeling fait par les équipes sécurité seules n'est pas connu des développeurs. La session doit être collaborative.

Traiter STRIDE comme un audit : STRIDE est un outil de conception, pas d'audit. Il se fait avant ou pendant le développement, pas après.

---

Threat modeling assisté par IA : accélérateur, pas remplaçant

Depuis 2023, des outils assistés par IA générative accélèrent la première étape du threat modeling : la génération d'une liste de menaces STRIDE à partir d'une description d'architecture. STRIDE GPT, projet open source qui s'appuie sur des modèles de langage, transforme en quelques minutes une description texte ou un dépôt GitHub en un premier jet de menaces, de scores de risque et de tests à écrire, sous des formats exploitables comme Markdown ou SARIF (Static Analysis Results Interchange Format, un format JSON standardisé pour échanger des résultats d'analyse entre outils de sécurité). Des éditeurs commerciaux comme IriusRisk ou ThreatModeler ont ajouté des fonctionnalités comparables à leurs catalogues de menaces.

Ces outils ne remplacent pas la session collaborative. Un modèle de langage qui reçoit une description vague produit des menaces génériques, sans lien avec les vraies limites de confiance du système, et peut passer à côté d'un flux critique que l'équipe connaît par cœur. La pratique qui se stabilise en 2026 consiste à utiliser l'IA comme générateur de brouillon et validateur de complétude (a-t-on bien couvert les 6 catégories sur chaque flux sensible), puis à laisser l'équipe trancher la priorisation et les mitigations. Le projet TaaC-AI, référencé par la fiche threat modeling de l'OWASP, suit la même logique de threat modeling as code enrichi par un modèle de langage.

Des extensions académiques comme STRIDE-AI adaptent la grille aux systèmes d'IA générative et aux agents autonomes, avec des catégories de menaces propres à ces systèmes (empoisonnement de modèle, injection de prompt). Ces extensions restent expérimentales et ne concernent pas la majorité des équipes qui appliquent STRIDE à des API classiques.

---

Quand passer d'un tableau blanc à un outil dédié ?

Le DFD au tableau et les post-its colorés (un par catégorie STRIDE) suffisent pour les premières sessions, celles où l'équipe apprend encore la méthode. Ce qui compte à ce stade, c'est la conversation que génère l'exercice, pas le rendu final : un schéma imparfait mais discuté vaut mieux qu'un diagramme soigné produit seul dans son coin.

Le passage à un outil dédié devient pertinent quand deux signaux apparaissent ensemble : l'équipe maîtrise déjà les 4 étapes sans les relire, et le volume de sessions augmente (plusieurs par sprint, sur des systèmes qui partagent des composants). Des outils open source comme OWASP Threat Dragon permettent alors de conserver un historique des DFD et des menaces d'une session à l'autre, et des outils assistés par IA (voir plus haut) peuvent générer un premier jet de menaces à partir de ce DFD, sans dispenser l'équipe de la discussion finale.

---

Du threat modeling au pipeline CI/CD

Le threat modeling identifie des risques de conception. Beaucoup de ces risques peuvent être traduits en vérifications automatiques dans le pipeline CI/CD (intégration et déploiement continus), ce qui transforme une décision ponctuelle en garde-fou permanent.

Exemples de traductions :

Menace STRIDE	Type de vérification automatisable
Secrets exposés dans les logs (I)	Scanner de secrets dans le code
Dépendances avec vulnérabilités connues (T/I)	Analyse des composants (SCA, Software Composition Analysis)
Headers de sécurité absents (I)	Tests de sécurité dynamiques (DAST, Dynamic Application Security Testing)
Endpoint sans authentification (S/E)	Tests d'intégration d'autorisation
Absence de rate limiting (D)	Tests de charge sur les endpoints sensibles
Processus exécuté sans isolation (E)	Analyse statique de configuration

Glissez pour voir

Tests de sécurité : SAST, DAST, SCA Comment transformer les menaces STRIDE en vérifications automatisées dans le pipeline.

---

À retenir

• STRIDE est efficace en 30 à 60 minutes. Plus long, c'est qu'on cherche à tout modéliser, ce n'est pas le but.
• Les 6 catégories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) couvrent la majorité des menaces des systèmes web et Cloud Native.
• Les résultats d'un threat modeling se traduisent en user stories de sécurité, pas en documents PDF.
• Commencez par les flux qui franchissent les limites de confiance : c'est là que les risques sont les plus élevés.
• Un threat modeling sans décision est un coût sans valeur.
• Les outils assistés par IA accélèrent le brouillon de menaces, mais la priorisation reste une décision d'équipe.
• Traduisez les menaces en vérifications CI/CD pour transformer une décision ponctuelle en garde-fou permanent.

---

FAQ : questions fréquentes

Qu'est-ce que STRIDE en cybersécurité ?

STRIDE est une méthode de threat modeling qui classe les menaces en six catégories : Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service et Elevation of Privilege. Elle aide les équipes à identifier les failles de conception avant de coder.

Quelle est la différence entre STRIDE et DREAD ?

STRIDE identifie les catégories de menaces (Spoofing, Tampering, etc.), tandis que DREAD évalue leur gravité sur cinq critères : Damage, Reproducibility, Exploitability, Affected users, Discoverability. Les deux méthodes sont complémentaires : STRIDE trouve les menaces, DREAD les priorise.

Comment faire un threat modeling avec STRIDE ?

Une session STRIDE suit quatre étapes : décrire le système avec un Data Flow Diagram, identifier les menaces STRIDE pour chaque flux, évaluer leur probabilité et impact, puis décider des mitigations à transformer en user stories de sécurité.

Pourquoi utiliser STRIDE plutôt qu'une autre méthode de threat modeling ?

STRIDE est privilégié car il est simple à enseigner, rapide à appliquer en équipe et ses six catégories correspondent directement à des contrôles techniques connus des développeurs, contrairement à des méthodes plus complexes comme PASTA.

Quand faut-il faire un threat modeling STRIDE ?

STRIDE convient aux nouvelles fonctionnalités, aux changements d'architecture et aux intégrations avec des systèmes externes. Il n'est pas adapté pour auditer du code déjà en production, un rôle que remplissent mieux les scanners SAST.

Les outils IA peuvent-ils remplacer une session de threat modeling STRIDE ?

Non. Les outils IA comme STRIDE GPT accélèrent la génération d'un premier jet de menaces à partir d'une description d'architecture, mais un modèle de langage sans contexte produit des menaces génériques. La session collaborative en équipe reste nécessaire pour prioriser et décider des mitigations.

---

Prochaines étapes

Security by Design Intégrer la sécurité dès la conception : SDL, Privacy by Design, STRIDE dans le cycle.

OWASP Top 10 appliqué au DevSecOps Utiliser les catégories OWASP pour la sensibilisation et les quality gates.

Tests de sécurité Transformer les menaces identifiées en tests automatisés : SAST, DAST, SCA.

Pipeline CI/CD sécurisé Le pipeline comme garde-fou : où placer chaque vérification automatisée.

Menaces, risques et vulnérabilités Le cadre conceptuel complet, avec STRIDE, PASTA et MITRE ATT&CK.

×

📖 Voir la documentation →