01Le cadre des quatre questions de Shostack
La plupart des approches modernes suivent le cadre des quatre questions d'Adam Shostack (« Threat Modeling: Designing for Security », 2014) : sur quoi travaillons-nous ? Qu'est-ce qui peut mal tourner ? Que faisons-nous pour y remédier ? Avons-nous fait du bon travail ? Ces quatre questions structurent le processus en modélisation du système, identification des menaces, définition des mesures et validation – indépendamment de la méthode retenue dans le détail. Le Threat Modeling Manifesto définit d'ailleurs le threat modeling comme l'analyse de représentations d'un système afin d'en dégager les préoccupations relatives à ses propriétés de sécurité et de protection des données. L'essentiel réside dans le changement de perspective : il ne s'agit pas de vérifier que les exigences sont remplies, mais de se demander systématiquement ce qu'un attaquant pourrait faire de la conception.
02Méthodes : STRIDE, PASTA et arbres d'attaque
STRIDE – formulé en 1999 par Loren Kohnfelder et Praerit Garg chez Microsoft, puis devenu un élément central du Microsoft Security Development Lifecycle – classe les menaces en six catégories, chacune portant atteinte à un objectif de sécurité : Spoofing (authentification), Tampering (intégrité), Repudiation (non-répudiation), Information Disclosure (confidentialité), Denial of Service (disponibilité) et Elevation of Privilege (autorisation). PASTA (Process for Attack Simulation and Threat Analysis ; UcedaVélez/Morana, 2015) adopte quant à elle une approche centrée sur le risque : en sept étapes – de la définition des objectifs au périmètre technique, à la décomposition, à l'analyse des menaces et des vulnérabilités, jusqu'à la modélisation des attaques et à l'analyse des risques et des impacts – la méthode relie des attaques simulées à leur impact métier. Les arbres d'attaque (Bruce Schneier, 1999) modélisent un objectif d'attaque comme nœud racine et le décomposent, via des liens ET/OU, en chemins d'attaque concrets, évaluables par exemple selon leur coût ou leur probabilité de succès. En pratique, ces approches se complètent : STRIDE pour la couverture systématique, PASTA pour la perspective risque, les arbres d'attaque pour l'analyse approfondie de scénarios individuels.
03Diagrammes de flux de données et frontières de confiance
Presque toute analyse repose sur un diagramme de flux de données (DFD) : entités externes, processus, magasins de données et flux de données représentent le système, tandis que les frontières de confiance marquent les transitions entre zones de niveaux de confiance différents – par exemple entre Internet et le backend, ou entre l'application et la base de données. C'est à ces frontières que se concentrent les menaces, ce qui en fait le point de départ naturel de la revue systématique. Pour les systèmes complexes, plusieurs diagrammes à différents niveaux de détail sont courants : une vue d'ensemble du système global, complétée par des vues détaillées des composants critiques. Le diagramme reste un moyen au service d'une fin – un modèle qui nourrit la discussion en équipe importe davantage qu'une exhaustivité parfaite.
04Le Threat Modeling Manifesto
En 2020, un groupe de 15 spécialistes issus de la pratique et de la recherche a publié le Threat Modeling Manifesto, délibérément inspiré du Manifeste agile. Il formule cinq valeurs, parmi lesquelles : une culture de la détection et de la correction des problèmes de conception plutôt qu'une conformité de façade, les personnes et la collaboration plutôt que les processus, les méthodes et les outils, et l'affinement continu plutôt qu'une livraison unique. Quatre principes en concrétisent la mise en œuvre – par exemple, qu'une analyse précoce et fréquente améliore la sécurité et la protection des données, et que le threat modeling doit s'adapter aux pratiques de développement et aux itérations de l'équipe. Le manifeste identifie en outre des schémas favorables, comme la démarche systématique et la diversité des points de vue, ainsi que des anti-patterns tels que le « hero threat modeler » ou la quête de la représentation parfaite.
05Outillage et threat modeling as code
Avec OWASP Threat Dragon, on dispose d'un outil de modélisation libre bénéficiant du statut « production » de l'OWASP, qui, en application web ou de bureau, crée des diagrammes et documente les menaces notamment selon STRIDE, LINDDUN et PLOT4ai (version actuelle 2.6.2, mai 2026) ; le Microsoft Threat Modeling Tool est lui aussi bien établi. OWASP pytm (projet au statut « lab ») emprunte une autre voie : l'architecture est décrite sous forme de code Python, à partir duquel le framework génère des diagrammes de flux de données, des diagrammes de séquence et des rapports de menaces. Ce threat modeling as code rend les modèles versionnables, vérifiables en revue de code et automatisables dans les pipelines CI/CD – architecture et modèle de menaces suivent le même processus de changement. L'automatisation ne remplace pas l'analyse collective en équipe, elle la fait passer à l'échelle : les listes de menaces générées sont un point de départ, pas un résultat final.
06Ancrage dans le SDLC, l'agilité et la Definition of Done
Le NIST Secure Software Development Framework (SP 800-218, version 1.1) fait de la modélisation des menaces une composante à part entière du développement sécurisé : la tâche PW.1.1 exige des formes de modélisation des risques – explicitement le threat modeling, l'attack modeling ou l'attack surface mapping – pour évaluer le risque de sécurité d'un logiciel. Dans les équipes agiles, cela ne fonctionne pas comme un grand atelier ponctuel, mais de manière incrémentale : les fonctionnalités sensibles pour la sécurité, les nouvelles interfaces ou les changements d'architecture déclenchent une analyse ciblée dont les résultats alimentent le backlog ; ancrée comme critère dans la Definition of Done, l'analyse des menaces devient la règle plutôt que l'exception. C'est précisément ce que demande le manifeste : une analyse précoce et fréquente, adaptée aux itérations de l'équipe. Pour les systèmes d'IA agentique, les méthodes classiques atteignent toutefois leurs limites – la Cloud Security Alliance a publié pour cela en 2025 MAESTRO, un framework dédié à sept couches, que nous approfondissons dans notre article de connaissances consacré à MAESTRO dans le domaine Agentic AI Security.
