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 peut identifier les failles architecturales que les outils automatiques ne détecteront jamais — parce que ce sont des choix de conception, pas des bugs de code.

Relation avec menaces-risques.mdx

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à.

---

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à.

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

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

1. Décrire le système — Construire un Data Flow Diagram (DFD) simple : composants, flux de données, 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. Utiliser DREAD 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é. Un tableau blanc ou un Miro suffit. Ce qui compte, c’est de représenter :

• 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.

---

Exemple appliqué : API d’authentification

Prenons une API d’authentification classique avec JWT.

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 + 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é

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”

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) ?
• 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. Voici comment l’intégrer naturellement.

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 lettre 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 définition of Done

Ajoutez un critère dans votre DoD 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 min : construire le DFD ensemble
• 40 min : parcourir STRIDE (5 min par catégorie, 2 séquences)
• 20 min : prioriser et décider
• 10 min : documenter dans l’ADR (Architecture Decision Record)

---

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.

---

Quel support utiliser ?

Vous n’avez pas besoin d’un outil dédié pour débuter. Un tableau blanc, des post-its colorés (un par catégorie STRIDE) et 45 minutes suffisent pour une première session productive avec l’équipe.

Ce qui compte, c’est la conversation que génère l’exercice, pas le rendu final. Quand l’équipe est à l’aise avec la méthode, des outils spécialisés peuvent automatiser la génération des listes de menaces à partir du DFD. Les guides d’implémentation de ce site détaillent les options disponibles.

---

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).

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
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 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.

---

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.

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

×

📖 Voir la documentation →