---
title: "Das abgeschlossene Bedrohungsmodell"
date: 2026-03-13T07:35:00+01:00
draft: false
image: "2026-03-13_Abgeschlossenes-Bedrohungsmodell.jpg"
tags: ["Anti-Pattern", "Application-Security", "Threat Modeling", "DevSecOps"]
keywords: ["Threat Modeling Manifesto", "Continuous Refinement", "Adam Shostack", "Four-Questions-Framework", "Definition of Done", "Angriffsfläche"]
description: "Einmalig erstellte Bedrohungsmodelle veralten unbemerkt und erzeugen eine gefährliche Vollständigkeitsillusion."
---

## 🔍 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.

## 📚🔍

- Adam Shostack: Threats – What Every Engineer Should Learn From Star Wars [https://threatsbook.com/](https://threatsbook.com/)
- OWASP Threat Modeling Cheat Sheet [https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
- OWASP Threat Modeling Process [https://owasp.org/www-community/Threat_Modeling_Process](https://owasp.org/www-community/Threat_Modeling_Process)
- Adam Shostack: Threat Modeling: Designing for Security [https://shostack.org/books/threat-modeling-book](https://shostack.org/books/threat-modeling-book)
- OpenSSF: Threat Modeling the Supply Chain for Software Consumers [https://openssf.org/blog/2023/09/27/threat-modeling-the-supply-chain-for-software-consumers/](https://openssf.org/blog/2023/09/27/threat-modeling-the-supply-chain-for-software-consumers/)
- Threat Modeling Manifesto (2020) [https://www.threatmodelingmanifesto.org/](https://www.threatmodelingmanifesto.org/)