Der Engpass, der gerne ignoriert wird: Warum Threat Modeling meist im Backlog bleibt
Threat Modeling gilt als eine der wirkungsvollsten Maßnahmen im Security-Portfolio und bleibt in der Praxis trotzdem chronisch ungenutzt. Nicht weil Organisationen den Wert nicht erkennen, sondern weil der Aufwand prohibitiv hoch ist. Ein vollständiges Threat Model für ein mittelkomplexes System? Zwei bis fünf Tage Workshop-Zeit, ein erfahrener Security Architect als Moderator, und am Ende ein Dokument, das sechs Monate später bereits veraltet ist.
Das Ergebnis ist vorhersehbar: Threat Modeling findet statt, wenn Compliance es fordert oder nach einem Sicherheitsvorfall. Der Rest des Portfolios bleibt ohne Betrachtung. In Organisationen mit Dutzenden oder Hunderten von Services ist das keine Ausnahme – es ist eher der Normalzustand.
Das eigentliche Problem ist strukturell: Threat Modeling wurde als manuelle, expertengetriebene Disziplin konzipiert, in einer Zeit, in der Software langsamer gebaut wurde und Systemlandschaften überschaubarer waren. Diese Grundannahmen gelten heute nicht mehr.
Die wahren Kosten des manuellen Threat Modelings
Der hohe Aufwand ist als direkte Kosten sofort sichtbar: Workshop-Stunden, Vorbereitung, Dokumentation. Die versteckten Kosten sind sogar noch höher: Ein Security Architect, der drei Tage für ein Threat Model aufwendet, fehlt in dieser Zeit für drei andere Projekte. Wächst das Team, skaliert dieses Problem mindestens linear.
Hinzu kommt das Expertise-Problem. Qualitativ hochwertiges Threat Modeling nach STRIDE oder PASTA setzt tiefes Verständnis von Angriffsvektoren, Architekturmustern und Business-Kontext voraus. Diese Kombination ist selten. Organisationen, die nicht mindestens einen dedizierten Threat-Modeling-Spezialisten beschäftigen, produzieren häufig Ergebnisse von inkonsistenter Qualität – oder verzichten ganz darauf.
Tipp: Der EACG Threat Modeling-Kurs ist direkt über die TrustSource-Seite verfügbar und gibt schnell einen guten Einstieg.
Der dritte Kostenfaktor sind Opportunitätskosten im SDLC. Bedrohungen, die in der Designphase identifiziert werden, kosten einen Bruchteil dessen, was eine Identifikation bzw. Adressierung nach Inbetriebnahme kostet. Das ist keine neue Erkenntnis, aber die Implikation wird selten konsequent umgesetzt: Wenn Threat Modeling nur für 10 % der Systeme stattfindet, sind 90 % des Portfolios systematisch unterbewertet.
Reproduzierbarkeit ist ein weiteres unterschätztes Problem. Zwei Teams, die dasselbe System unabhängig voneinander modellieren, kommen zu unterschiedlichen Ergebnissen. Dabei ist die Ursache nicht, dass eine Team schlechter ist oder falsch liegt, sondern weil der Prozess stark von individuellen Annahmen und Erfahrungswerten abhängt. Das macht Vergleiche bzw. Eine konsistente Qualität über Zeit und Teams hinweg schwierig.
STRIDE at Scale: Was Automatisierung in der Praxis bedeutet
Automatisiertes Threat Modeling bedeutet nicht, menschliches Urteilsvermögen zu ersetzen. Es bedeutet, die mechanischen, zeitaufwendigen Teile des Prozesses zu systematisieren, damit Security Engineers mehr Zeit für die Fragen aufwenden können, die tatsächlich Nachdenken erfordern.
Konkret lassen sich folgende Prozessschritte sinnvoll automatisieren:
Datenflussanalyse: Aus IaC-Code (Terraform, CloudFormation), Architekturdiagrammen oder Service-Meshes lassen sich Datenflüsse und Trust Boundaries extrahieren. Was manuell Stunden dauert, kann automatisiert in Minuten ein strukturiertes Datenflussdiagramm produzieren.
STRIDE-Kategorisierung: Auf Basis identifizierter Komponenten und Datenflüsse lassen sich STRIDE-Kategorien regelbasiert zuordnen. Ein API-Gateway ohne Authentifizierung triggert Spoofing-Findings. Eine unverschlüsselte Datenbankverbindung triggert Information-Disclosure-Findings. Diese Muster sind formalisierbar.
Szenariengeneration: Automatisierte Systeme können aus einem Komponentenmodell plausible Bedrohungsszenarien generieren – entweder regelbasiert oder LLM-gestützt. Das Ergebnis ist keine fertige Risikobeurteilung, aber eine strukturierte Ausgangsbasis für die menschliche Überprüfung.
Asset-Inventar-Integration: Automatisiertes Threat Modeling wird erst dann wirklich skalierbar, wenn es mit dem Asset-Inventar der Organisation verbunden ist, sodass neue Services automatisch in den Modellierungsprozess einbezogen werden.
Was weiterhin menschliches Urteilsvermögen erfordert: die Bewertung von Business-Kontext und Schadenshöhe, die Priorisierung von Findings und die Entscheidung, welche Risiken akzeptiert werden. Automatisierung liefert die Struktur; Security Engineers liefern die Interpretation.
Beispiel eines automatisiert erzeugten Threat-Modells in TrustSource unter Zuhilfenahme von IaC-, Architecture-, SBOM, Schwachstellen- und SAST-Informationen
Automatisiertes Threat Modeling in der DevSecOps-Pipeline
Die technische Integration folgt einem klaren Muster: Threat Modeling muss an die Stellen im Entwicklungsprozess gebunden werden, an denen sicherheitsrelevante Änderungen entstehen.
Trigger-Mechanismen: Architekturänderungen – neue Services, geänderte Datenflüsse, neue externe Integrationen – sollten automatisch eine Threat-Model-Aktualisierung auslösen. Das kann über IaC-Änderungen in Pull Requests oder über dedizierte Architecture-as-Code-Definitionen erfolgen.
Pull-Request-Integration: Findings aus dem Threat-Modeling-Prozess können direkt als PR-Kommentare oder Checks in den Review-Prozess eingebettet werden. Das verlagert Security-Feedback dorthin, wo Entwickler ohnehin arbeiten.
Jira-Integration: Identifizierte Bedrohungen werden als strukturierte Tickets mit Schweregrad, STRIDE-Kategorie und Verlinkung zum Threat Model angelegt – nicht als formlose Security-Findings, sondern als priorisierbare Backlog-Items.
Vulnerability-Management-Anbindung: Threat-Modeling-Findings können als Kontext für bestehende Vulnerability-Management-Prozesse dienen – insbesondere um zu unterscheiden, welche CVEs in welchem Threat-Kontext tatsächlich relevant sind.
Der Übergang ins Risikomanagement erfordert einen definierten Eskalationspfad: Welche Findings werden direkt vom Team bearbeitet? Welche erfordern eine Security-Review? Automatisierung macht diese Schwellen überwind- und durchsetzbar.
Automatisierungsansätze im Vergleich
Nicht alle Automatisierungsansätze sind gleichwertig. Eine pragmatische Bewertung:
Regelbasierte Template-Engines sind das niedrigschwelligste Einstiegsszenario. Sie bieten hohe Konsistenz und niedrige False-Positive-Raten bei bekannten Architekturmustern, stoßen aber schnell an Grenzen bei komplexen oder ungewöhnlichen Systemen. Wartung der Regel-Bibliothek ist aufwendig.
Graph-basierte Modellierung bildet Systemarchitekturen als Graphen ab und erlaubt traversierungsbasierte Analyse von Angriffspfaden. Dieser Ansatz skaliert gut und ist gut auditierbar, erfordert aber initiale Investitionen in Datenmodell und Integration.
LLM-gestützte Analyse bietet die höchste Flexibilität und kann auch bei unstrukturierten Architekturbeschreibungen plausible Bedrohungsszenarien generieren. Die Herausforderungen liegen in der Konsistenz, der Tendenz zu False Positives und der Schwierigkeit, Ergebnisse zu auditieren. LLMs sind als Grundlage, nicht aber als einziger Analysemechanismus geeignet.
Für die meisten Organisationen empfiehlt sich ein hybrides Modell: regelbasierte Basisanalyse für hohe Konsistenz, LLM-Unterstützung für Szenariengeneration und Kontextualisierung, menschliche Überprüfung für finale Bewertung.
Vom Security-Gatekeeping zur Security-Enablement
Skaliertes Threat Modeling verändert die Rolle von Security-Teams grundlegend. Das klassische Modell – Security prüft, Product Engineering setzt um – funktioniert bei hundert parallelen Produktentwicklungen nicht mehr.
Das neue Modell: Security Engineers definieren die Struktur, die Methodik und die Qualitätskriterien. Product Teams führen das Threat Modeling durch, unterstützt durch Automatisierung und klare Leitlinien. Security Engineers reviewen Ergebnisse und eskalierten Findings, statt jeden Prozessschritt selbst durchzuführen.
Diese Verlagerung erfordert kulturelle Investitionen: Training, klare Verantwortlichkeiten und Tooling, das Product Teams nicht überfordert. Das zahlt sich in Form von Ownership aus: Teams, die ihr eigenes Threat Model entwickelt haben, sind motivierter, identifizierte Risiken tatsächlich zu adressieren.
Threat Model Coverage als KPI macht diesen Wandel messbar: Welcher Anteil des Service-Portfolios verfügt über ein aktuelles Threat Model? Diese Kennzahl kann in Security-Scorecards und OKR-Prozesse integriert werden und schafft Transparenz über den tatsächlichen Abdeckungsgrad.
Ein pragmatischer Einstieg: Schritt für Schritt zur Skalierung
Kein Threat-Modeling-Programm wird über Nacht skaliert. Der pragmatische Weg führt über definierte Pilotprojekte:
-
Reife bewerten: Gibt es einen dokumentierten Threat-Modeling-Prozess? Werden Ergebnisse konsistent festgehalten? Wie hoch ist die aktuelle Coverage? Diese Bestandsaufnahme definiert den Ausgangspunkt.
-
Pilotprojekt wählen: Ein Team mit hoher Security-Affinität, ein gut dokumentiertes System, ein überschaubarer Scope. Automatisierungstools einführen, Prozess iterieren, Learnings dokumentieren.
-
Tooling evaluieren: Bestehende Optionen – von Microsoft Threat Modeling Tool über OWASP Threat Dragon bis zu kommerziellen Plattformen wie TrustSource – auf Integrationsfähigkeit in die bestehende Pipeline prüfen, nicht primär auf Feature-Vollständigkeit.
-
Coverage schrittweise ausbauen: Ausgehend vom Pilot auf weitere Teams und Systeme ausweiten. Automatisierung ermöglicht dabei, den Aufwand pro Threat Model zu reduzieren. Dabei geht es nicht darum, den Prozessschritt zu auszulassen, aber die Grundlage zu legen, sich damit zu beschäftigen.
-
Nicht auf Tool-Reife warten: Jedes Threat Model, das heute mit unvollständiger Automatisierung erstellt wird, ist besser als keines. Perfektion ist der Feind des Fortschritts, gerade in der frühen Skalierungsphase.
Fazit
Drei Kernergebnisse, die dieser Artikel belegt:
- Automatisierung macht Threat Modeling wirtschaftlich skalierbar. Der manuelle Aufwand war bisher der größte Hemmschuh; nicht fehlendes Bewusstsein oder mangelnde Methodik.
- STRIDE und strukturierte Automatisierung ergänzen sich. Agenten können den Großteil der mechanischen Analysearbeit übernehmen; menschliches Urteilsvermögen bleibt bei Priorisierung und Kontextualisierung unverzichtbar.
- Der kulturelle Wandel ist genauso wichtig wie das Tooling. Skaliertes Threat Modeling erfordert, dass Product Teams Security-Ownership übernehmen – und Security-Teams die Infrastruktur liefern, die das ermöglicht.