Une modélisation de menaces qui vit dans une page Confluence que personne ne lit, c'est du théâtre. Celles qui protègent les vrais systèmes sont mises à jour quand le système change — à l'heure de la PR, pas à l'heure de l'audit.
Nous traitons le modèle de menaces comme une section du README de chaque service que nous shippons. Trois sous-sections : actifs, frontières de confiance, risques mitigés. Un nouvel endpoint force une mise à jour. Une nouvelle intégration tierce force une mise à jour. Si le modèle et le code divergent, nous avons échoué avant même l'arrivée d'un attaquant.
Trois patterns se sont avérés porteurs. Primo : nommer explicitement la frontière de confiance — « ce endpoint accepte des requêtes non authentifiées, valide le JWT, puis entre dans le plan de confiance ». Deuxio : capturer l'hypothèse qui justifie chaque mitigation — les hypothèses sont ce qui casse silencieusement. Tertio : relier chaque menace à un test qui exerce la mitigation ; le test est la seule preuve qu'elle fonctionne encore.
Ce que nous ne faisons pas : STRIDE par routine, arbres d'attaque que personne ne lit, « plateformes de sécurité » tierces qui produisent un PDF de 200 pages une fois par an. Tout cela produit de la paperasse, pas de la sécurité.
Le coût : environ 30 minutes par service par trimestre, plus l'overhead PR quand une frontière bouge. Le retour : quand l'audit arrive, le modèle de menaces est le document que l'auditeur veut. Il existe déjà.