Security Threat Model

Security Threat Model ist ein offizieller, kuratierter OpenAI-Skill für Codex. Laut Anbieter führt er ein KI-Modell durch eine fokussierte Anwendungssicherheitsanalyse eines Code-Repositories oder eines klar abgegrenzten Projektpfads. Das Ergebnis ist kein allgemeiner Architekturüberblick und keine lose Sammlung von Checklisten, sondern ein nachvollziehbares Bedrohungsmodell mit Belegen aus dem untersuchten Repository. Der Skill liegt im offiziellen Repository openai/skills unter skills/.curated/security-threat-model; die zugehörige Lizenzdatei nennt Apache License 2.0.

Zweck und Arbeitsweise

Der Skill beginnt mit der Klärung des Untersuchungsumfangs. Dazu gehören das Repository oder der Zielpfad, die angenommene Nutzung, das Bereitstellungsmodell, die Internet-Erreichbarkeit und die erwarteten Authentifizierungsbedingungen. Anschließend soll der Agent die realen Komponenten, Einstiegspunkte, Datenspeicher und externen Integrationen aus dem Quellbestand ableiten. Laufzeitverhalten wird ausdrücklich von CI, Build- und Entwicklungswerkzeugen sowie Tests und Beispielen getrennt. Diese Trennung verhindert, dass ein Hilfsskript oder eine Testkonfiguration ohne Beleg als Produktionsarchitektur bewertet wird.

Trust Boundaries und schützenswerte Werte

Ein zentraler Schwerpunkt sind konkrete Vertrauensgrenzen zwischen Komponenten. Für jede Grenze werden Protokoll, Authentifizierung, Verschlüsselung, Validierung und mögliche Ratenbegrenzung betrachtet. Der Skill fordert außerdem eine Liste der Werte, die Risiken auslösen können. Dazu zählen Zugangsdaten, personenbezogene oder vertrauliche Daten, Integritätszustände, verfügbare Rechenressourcen, Konfigurationen, Modelle, Build-Artefakte und Audit-Protokolle. Einstiegspunkte können HTTP-Endpunkte, Datei-Uploads, Parser, Dekoder, Job-Auslöser, Administrationswerkzeuge sowie Protokoll- und Fehlersenken sein.

Angreifer und Missbrauchspfade

Statt abstrakte Schwachstellen aufzuzählen, verbindet der Skill realistische Angreiferfähigkeiten mit konkreten Zielen. Mögliche Ziele sind Datenabfluss, Privilegienausweitung, Manipulation von Integritätszuständen oder Verfügbarkeitsverlust. Jede Bedrohung soll betroffene Werte, einen plausiblen Missbrauchspfad und qualitative Einschätzungen für Eintrittswahrscheinlichkeit und Auswirkung erhalten. Die Gesamtpriorität wird aus diesen Faktoren und vorhandenen Kontrollen abgeleitet. Annahmen, die das Ergebnis stark beeinflussen, müssen sichtbar bleiben.

Belege und Grenzen

Laut Anbieter darf der Agent keine Komponenten, Datenflüsse oder Sicherheitskontrollen erfinden. Architekturbehauptungen werden mit Evidence Anchors aus Repository-Pfaden, Symbolen, Konfigurationsschlüsseln oder kurzen Belegstellen verknüpft. Fehlt eine Information, wird sie als Annahme und offene Frage dokumentiert. Der Skill verlangt außerdem, Geheimnisse nicht auszugeben. Werden Schlüssel, Passwörter oder Tokens gefunden, sollen sie redigiert und nur ihre Existenz sowie ihr Ort beschrieben werden. Das schützt sensible Daten, ohne die Untersuchung zu verschleiern.

Ergebnis und Qualitätssicherung

Das gewünschte Ergebnis ist ein kompakter Markdown-Bericht mit einem einzelnen Mermaid-Flussdiagramm, das Komponenten und Vertrauensgrenzen übersichtlich zeigt. Der Bericht soll bestehende und empfohlene Gegenmaßnahmen unterscheiden, konkrete Orte für Verbesserungen nennen und verbleibende Risiken festhalten. Vor dem Abschluss prüft der Agent, ob alle Einstiegspunkte, Grenzen und Laufzeitbereiche abgedeckt sind. Laut Anbieter soll der Bericht als Datei mit dem Namen des untersuchten Repository- oder Verzeichnisnamens und dem Zusatz threat-model.md gespeichert werden.

Einordnung für Teams

Der Skill eignet sich für einen ersten, repository-nahen AppSec-Arbeitsstand, für Architektur-Reviews mit Sicherheitsfokus und für die Vorbereitung einer vertieften Prüfung. Er ersetzt weder eine unabhängige Sicherheitsbewertung noch Tests in einer isolierten Umgebung. Die Aussagekraft hängt von der Vollständigkeit des Repositorys, der Qualität der Architekturbelege und den bestätigten Betriebsannahmen ab. Der Anbieter sieht ausdrücklich einen Validierungsschritt mit ein bis drei gezielten Fragen vor. Wenn diese Antworten ausbleiben, müssen die offenen Annahmen und ihr Einfluss auf die Priorisierung im Bericht stehen.