Threat Modeling im Produktentwicklungsprozess verankern
Das Problem: Threat Modeling als Einmal-Übung
In vielen Unternehmen folgt Threat Modeling einem vorhersehbaren Muster: Ein Workshop wird einberufen, ein Dokument entsteht, es landet im Confluence-Space – und wird danach nicht mehr angefasst. Sechs Monate später hat das Produkt drei neue Features, zwei Infrastrukturkomponenten wurden ausgetauscht, und das Bedrohungsmodell beschreibt noch immer eine Architektur, die so nicht mehr existiert.
Die Symptome sind unverkennbar: Bedrohungsmodelle ohne Versionierung, fehlende Trigger für Aktualisierungen, und vor allem ein organisatorisches Silo zwischen Security-Teams, die das Modell erstellen, und Engineering-Teams, die täglich Architekturentscheidungen treffen. Das Ergebnis ist ein Compliance-Artefakt, das bei Audits vorgelegt werden kann, aber keinen operativen Sicherheitswert mehr liefert.
Das eigentliche Problem liegt nicht im Mangel an Methoden oder Werkzeugen, sondern in der strukturellen Verortung: Threat Modeling wird als punktuelle Aufgabe behandelt, nicht als kontinuierliches Designprinzip. Diese Denkweise zu überwinden ist der erste und entscheidende Schritt.
Grundlagen: Was Threat Modeling im Produktkontext wirklich bedeutet
Threat Modeling ist kein Penetrationstest und keine klassische Risikoanalyse. Während ein Pentest vorhandene Systeme auf ausnutzbare Schwachstellen prüft, fragt Threat Modeling bereits während des Designs: Was könnte schiefgehen, und wie bauen wir es so, dass es nicht schiefgeht?
Im Produktkontext geht es darum, Angriffsflächen systematisch zu identifizieren, bevor sie implementiert werden. Dafür stehen etablierte Methoden zur Verfügung:
- STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) ist der verbreitetste Ansatz für die strukturierte Analyse von Bedrohungskategorien auf Systemebene.
- PASTA (Process for Attack Simulation and Threat Analysis) verfolgt einen risikobasierten, angreiferorientierten Ansatz und eignet sich besonders für komplexe, geschäftskritische Systeme.
- LINDDUN fokussiert auf Datenschutzbedrohungen und ist damit insbesondere für personenbezogene Daten verarbeitende Produkte relevant.
Der Mehrwert dieser Methoden entfaltet sich nicht in einem einmaligen Workshop. Er entsteht durch wiederholte Anwendung: Jede Designentscheidung, jedes neue Datenflussdiagramm, jede Änderung an Trust Boundaries fügt neue Erkenntnisse hinzu. Threat Modeling wird dann zum geteilten Denkrahmen eines Produktteams – nicht zum Sonderprojekt der Security-Abteilung.
Strukturelle Verankerung im SDLC: Vom Gate-Review zum Designprinzip
Die Integration von Threat Modeling in den Software Development Life Cycle (SDLC) erfordert klar definierte Einstiegspunkte – und ebenso klar definierte Trigger für Aktualisierungen.
Anforderungsphase: Bereits bei der Formulierung von User Stories und Systemanforderungen sollten Security-relevante Fragen gestellt werden. „Welche Akteure greifen auf diese Daten zu?” und „Welche Vertrauensgrenzen überquert dieser Datenfluss?” sind keine nachgelagerten Fragen – sie gehören in die Definition of Ready.
Architecture Reviews: Jeder Architecture Review ist ein natürlicher Zeitpunkt, das Bedrohungsmodell zu aktualisieren oder zu validieren. Neue Komponenten, geänderte Integrationen oder veränderte Deployment-Topologien verändern die Angriffsfläche – und müssen im Modell abgebildet werden.
Feature-Iterationen: Nicht jedes Feature erfordert ein vollständiges Re-Modeling, aber ein leichtgewichtiger Threat-Modeling-Check – „Was ändert sich an der Angriffsfläche durch dieses Feature?” – sollte zur Standard-Checkliste gehören.
Trigger-Ereignisse für eine verpflichtende Aktualisierung des Bedrohungsmodells sollten mindestens umfassen: neue externe Schnittstellen, Änderungen an Authentifizierungs- oder Autorisierungsmechanismen, neue Datenkategorien, Infrastrukturmigrationen sowie bekannt gewordene Schwachstellen in verwendeten Komponenten.
Threat Modeling in DevSecOps: Tooling, Automatisierung und Integration
Der DevSecOps-Ansatz verlangt, dass Security-Aktivitäten so früh und so automatisiert wie möglich in die Entwicklungspipeline eingebettet werden. Für Threat Modeling bedeutet das: nicht jede Analyse muss von einem Security-Experten manuell durchgeführt werden.
Praxisrelevante Tools umfassen OWASP Threat Dragon (open source, gut für teambasierte kollaborative Modellierung), IriusRisk (enterprise-tauglich, mit Regelwerken für automatisierte Bedrohungsvorschläge) und das Microsoft Threat Modeling Tool (STRIDE-zentriert, etabliert in Microsoft-nahen Umgebungen). Diese Tools unterstützen die Modellpflege, ersetzen aber kein Urteilsvermögen bei der Bewertung kontextspezifischer Risiken.
Besonders vielversprechend ist der Ansatz, den die TrustSource-Plattform verfolgt: Hier wird das Bedrohungsmodell nicht manuell aufgebaut, sondern aus vorhandenen Artefakten synthetisiert. Infrastructure-as-Code (IaC) liefert die Grundlage für ein operationalisiertes Bill-of-Materials auf Infrastrukturebene (OBOM), Architekturbeschreibungen ergänzen den strukturellen Kontext, die SBOM liefert Lizenz- und Schwachstelleninformationen zu verwendeten Komponenten, und SAST-Ergebnisse in Form von CWEs vervollständigen das Bild. Aus dieser Kombination speist die Plattform eine STRIDE-Analyse – mit dem Effekt, dass die resultierenden Findings deutlich fokussierter sind als bei generischen Modellierungsansätzen.
Ein weiterer Vorteil: Auf Basis dieser Analyse lassen sich konkrete Gegenmaßnahmen vorschlagen, die direkt auf die identifizierten Schwachstellen zugeschnitten sind. Das macht die Ergebnisse anschlussfähig für Engineering-Teams und eignet sich ideal als Diskussionsgrundlage in gemeinsamen Security-Review-Sessions. So entsteht kein abstraktes Dokument, sondern ein praxisnaher Arbeitsstand, der im Team vertieft und weiterentwickelt werden kann. Extrem komfortabel ist es, dass die Ergebnisse automatisch im Risiko-Management eingebunden werden und somit nicht Gefahr laufen, auf einem Brownpaper im Konferenzraum vergessen zu werden.
Was Automatisierung leisten kann: konsistente Datenflussmodelle aus vorhandenen Infrastrukturquellen ableiten, bekannte Bedrohungsmuster auf Architekturelemente mappen, Änderungen im Modell tracken. Was menschliches Urteilsvermögen zwingend erfordert: die Bewertung von Eintrittswahrscheinlichkeit und Schadenpotenzial im Geschäftskontext, die Priorisierung von Maßnahmen und die Entscheidung über akzeptierte Restrisiken.
Rollen, Verantwortlichkeiten und Team-Enablement
Threat Modeling funktioniert nicht als Einzeldisziplin. Wer trägt die Verantwortung, und wer wirkt aktiv mit?
Security Champions sind der Schlüssel zur Skalierung: Entwicklerinnen und Entwickler, die als Bindeglied zwischen Engineering und Security fungieren, Threat Modeling in Sprint-Reviews einbringen und das Bedrohungsmodell aktuell halten. Sie brauchen dafür kein vollständiges Security-Studium – aber gezielte Schulungen, klare Methodenreferenzen und die organisatorische Rückendeckung, Security-Fragen eskalieren zu dürfen.
Architekten verantworten die strukturelle Sicht auf das System und sind natürliche Eigentümer des Datenflussmodells – der Grundlage jeder STRIDE-Analyse.
Product Owner tragen die Verantwortung dafür, dass Security-Anforderungen in die Produktplanung einfließen und nicht als nachgelagerte Aufgabe behandelt werden. Threat Modeling liefert ihnen konkrete Inputs: welche Risiken bestehen, welche Maßnahmen priorisiert werden sollten.
Praktische Enablement-Ansätze: strukturierte Threat-Modeling-Workshops mit realem Produktkontext (keine abstrakten Beispiele), Bereitstellung von Checklisten und Bedrohungskatalogen als Arbeitsgrundlage, sowie regelmäßige Retrospektiven zu abgeschlossenen Threat-Modeling-Zyklen.
Regulatorischer Rückenwind: Anforderungen aus CRA und Co.
Der EU Cyber Resilience Act (CRA) verändert die Rahmenbedingungen für Produktsicherheit grundlegend. Hersteller von Produkten mit digitalen Elementen sind verpflichtet, Cybersicherheit über den gesamten Lebenszyklus zu gewährleisten – und das nachzuweisen. Konkret bedeutet das: Risikoanalysen als Teil des Designprozesses, Dokumentation von Sicherheitsanforderungen, Schwachstellenmanagement und strukturierte Update-Prozesse.
Eine kontinuierliche Threat-Modeling-Praxis erfüllt diese Anforderungen nicht nur inhaltlich, sie produziert gleichzeitig die notwendigen Nachweisdokumente: versionierte Bedrohungsmodelle als Belege für durchgeführte Risikoanalysen, Änderungsprotokolle als Nachweis kontinuierlicher Überprüfung, und strukturierte Finding-Listen als Input für das Schwachstellenmanagement.
Wer Threat Modeling als lebendes Prozessartefakt verankert, schafft damit keine zusätzliche Compliance-Bürde – sondern bedient Nachweispflichten als Nebenprodukt einer ohnehin sinnvollen Sicherheitspraxis.
Erfolgsmessung und kontinuierliche Verbesserung
Was nicht gemessen wird, verbessert sich nicht. Für Threat Modeling gilt das besonders, weil der Nutzen oft schwer direkt sichtbar ist.
Geeignete Metriken umfassen:
- Coverage-Metriken: Welcher Anteil der Systemkomponenten und Datenflüsse ist durch ein aktuelles Bedrohungsmodell abgedeckt?
- Aktualitätsquote: Wie viele Trigger-Ereignisse haben tatsächlich zu einer Modellaktualisierung geführt?
- Finding-to-Fix-Rate: Wie viele identifizierte Bedrohungen wurden mit konkreten Gegenmaßnahmen adressiert?
- Time-to-Model: Wie lange dauert ein Threat-Modeling-Zyklus für eine neue Komponente – ein Indikator für Prozessreife und Toolunterstützung.
Ergänzend sollten Security Incidents retrospektiv gegen das Bedrohungsmodell gespiegelt werden: War die ausgenutzte Schwachstelle im Modell erfasst? Wenn nicht – warum nicht? Diese Rückkopplung ist der wirkungsvollste Treiber für Prozessverbesserung.
Fazit
Drei Kernergebnisse lassen sich festhalten: Erstens entfaltet Threat Modeling seinen Sicherheitswert nur als kontinuierlicher Prozess – nicht als punktuelles Audit-Dokument. Zweitens ermöglicht die Kombination aus IaC, SBOM und SAST-Daten – wie im TrustSource-Ansatz umgesetzt – eine automatisierte, fokussierte STRIDE-Analyse, die Engineering-Teams direkt handlungsfähig macht. Drittens liefert eine strukturell verankerte Threat-Modeling-Praxis als Nebenprodukt genau die Nachweise, die der Cyber Resilience Act fordert – und macht Compliance zur Konsequenz guter Sicherheitsarbeit, nicht zu einer separaten Belastung.