🔍 Was beobachte ich?

Die Threat-Modeling-Session liegt sechs Monate zurück. Damals war die Architektur überschaubar, die Abhängigkeiten bekannt. Seitdem kam ein neuer Cloud-Provider dazu, drei Bibliotheken wurden ausgetauscht, und die Auslieferungspipeline hat neue Wege in die Produktion bekommen. Das Bedrohungsmodell weiß davon nichts.

🎯 Was soll eigentlich erreicht werden?

Threat Modeling soll Angriffsflächen sichtbar machen, bevor Angreifer sie finden. Das Threat Modeling Manifesto fordert Continuous Refinement: Das Bedrohungsmodell muss parallel zum System gepflegt, aktualisiert und verfeinert werden – nicht einmalig erstellt und abgelegt.

⚠️ Warum funktioniert das nicht?

Ein einmalig erstelltes Bedrohungsmodell veraltet unbemerkt. Jede Architekturänderung, jede neue Abhängigkeit und jede Cloud-Migration fügt potenzielle Angriffsvektoren hinzu, die im Original nicht auftauchen. Wer neue Funktionen einbaut, ohne das Modell anzupassen, hinterlässt unbekannte Angriffsfläche. Das eingefrorene Modell erzeugt eine Vollständigkeitsillusion – und die ist gefährlicher als kein Modell.

💡 Was funktioniert besser?

Threat Modeling als Prozess, nicht als Projekt: ausgelÜst durch Architekturänderungen, neue Abhängigkeiten und veränderte Einsatzbedingungen. Adam Shostacks Four-Questions-Framework ist leichtgewichtig genug fßr inkrementelle Updates, ohne jedes Mal von vorn anzufangen. Wer Threat Modeling in der Definition of Done verankert, macht aus dem guten Vorsatz eine verlässliche Routine.

📚🔍