Security-Review skaliert nicht mit: wie man Bedrohungsmodellierung an das Volumen anpasst
In den meisten Häusern prüft ein kleines Sicherheitsteam Änderungen stichprobenartig. Das war schon vorher eine Auswahl und ist bei erhöhtem Volumen eine Zufallsstichprobe mit geringer Trefferwahrscheinlichkeit. Mehr Sicherheitspersonal löst das nicht, weil die Zahl der Änderungen schneller wächst als jedes Team.
Bedrohungsmodellierung je Änderung ist bei hohem Volumen unmöglich; je Architekturbereich ist sie machbar und hält länger, weil Architektur sich seltener ändert. Aus dem Modell entstehen prüfbare Anforderungen je Bereich, die als Tests und Regeln auf jeder Änderung laufen. Eine menschliche Neubewertung lösen vier automatisch erkennbare Ereignisse aus: neue Außenschnittstelle, neue Datenkategorie, neue Abhängigkeit mit erhöhten Rechten, verschobene Vertrauensgrenze. Das Sicherheitsteam baut Regeln statt Reviews zu machen.
Der Wechsel: vom Ereignis zur Struktur
Eine Bedrohungsmodellierung je Änderung ist unmöglich. Eine je Architekturbereich ist machbar und hält länger, weil sich Architektur seltener ändert als Code. Das Modell beschreibt, welche Vertrauensgrenzen es gibt, welche Daten sie überschreiten und was dort schiefgehen kann. Es wird nur dann neu bewertet, wenn sich eine dieser Grenzen verschiebt.
Die Verbindung zur Änderung
Aus dem Modell entstehen prüfbare Anforderungen je Bereich: In diesem Bereich muss jede Eingabe validiert werden; hier darf keine Ausgabe ungefiltert erfolgen; dort ist eine Autorisierungsprüfung Pflicht. Diese Anforderungen werden zu Tests und Regeln, die auf jeder Änderung laufen. Der Sicherheitsblick findet damit einmal je Bereich statt und wirkt auf jede Änderung darin.
Der Auslöser für eine Neubewertung
Nicht jede Änderung, sondern vier Ereignisse: eine neue Außenschnittstelle, eine neue Datenkategorie, eine neue Abhängigkeit mit erhöhten Rechten, oder ein Wechsel der Vertrauensgrenze — etwa wenn ein interner Dienst plötzlich von außen erreichbar wird. Diese vier lassen sich automatisch erkennen und lösen eine menschliche Bewertung aus. Alles andere läuft durch die Gates.
Was das Sicherheitsteam stattdessen tut
Es baut Regeln statt Reviews zu machen. Eine Person, die eine Prüfung als Regel formuliert, wirkt auf jede künftige Änderung; dieselbe Person in einem Review wirkt auf eine. Dieser Wechsel ist kulturell schwierig, weil Reviews sichtbar sind und Regeln nicht — er ist aber die einzige Form, in der ein kleines Team mit hohem Volumen mithalten kann.
Was menschlich bleibt
Die Bewertung neuer Angriffsflächen, die Entscheidung über tragbare Risiken und die Untersuchung nach einem Vorfall. Das sind genau die Aufgaben, für die man Sicherheitsleute einstellt — und für die im heutigen Modell selten Zeit bleibt, weil sie mit Stichproben ausgelastet sind.
Häufige Fragen
Wie oft muss ein Bedrohungsmodell aktualisiert werden?
Nicht nach Kalender, sondern nach Ereignis: neue Außenschnittstelle, neue Datenkategorie, neue Abhängigkeit mit erhöhten Rechten oder eine verschobene Vertrauensgrenze. Alle vier lassen sich technisch erkennen und automatisch melden.
Ersetzen automatische Prüfungen den Penetrationstest?
Nein. Gates prüfen bekannte Muster auf jeder Änderung; ein Penetrationstest sucht das Unbekannte im Zusammenspiel. Beides ist nötig, aber mit unterschiedlicher Frequenz — Gates immer, Penetrationstests periodisch und nach größeren Architekturänderungen.
Wie bekommt man ein Sicherheitsteam dazu, Regeln statt Reviews zu machen?
Über die Zahl: Wie viele Änderungen hat das Team im letzten Quartal tatsächlich gesehen, und wie viele gab es? Diese Gegenüberstellung führt das Gespräch schneller als jedes Argument, weil sie zeigt, dass die heutige Arbeitsweise bereits eine Stichprobe ist.
Was ist mit Änderungen an sicherheitskritischen Bereichen?
Die bleiben in der höchsten Risikoklasse mit menschlicher Freigabe durch zwei Rollen. Der Punkt des Modells ist nicht, Sicherheitsprüfung abzuschaffen, sondern sie dort zu konzentrieren, wo sie wirkt, statt sie über alles gleich dünn zu verteilen.
Bringen Sie einen Pull Request mit, der zu groß war.
30 Minuten, kein Vertrieb. Wir gehen ihn durch und sagen, was ein Modell daran geändert hätte.
AI Engineering Review ansehen →
