Bedrohungen eines KI-Entwicklungsablaufs modellieren

Wählen Sie ein begrenztes Szenario

Beginnen Sie mit einem verständlichen Ablauf. Ein Agent liest zum Beispiel ein Issue, bearbeitet ein Repository, führt Tests aus und öffnet einen Pull Request. Beziehen Sie die Systeme ein, die diese Aktionen ermöglichen.

Listen Sie wichtige Schutzgüter auf: Quellcode, Kundeninformationen, Zugangsdaten, Release-Artefakte und Dienstverfügbarkeit. Ermitteln Sie ihre Verantwortlichen. Bestimmen Sie anschließend die Menschen und Systeme, die jedes Schutzgut lesen oder ändern können.

OWASP empfiehlt, das System zu modellieren, Bedrohungen zu identifizieren, Reaktionen auszuwählen und das Ergebnis zu prüfen. Nutzen Sie die Methode früh und aktualisieren Sie sie bei Systemänderungen. Leitfaden zur Bedrohungsmodellierung.

Zeichnen Sie die Vertrauensgrenzen

Zeichnen Sie für den fiktiven Ablauf vom Issue zum PR diese Verbindungen:

Issue → agent → repository → test runner → artifact store → deployment

Ergänzen Sie Modellanbieter und Secret-Speicher. Markieren Sie, wo Inhalte aus einer weniger vertrauenswürdigen Quelle kommen. Markieren Sie, wo eine Identität eine neue Fähigkeit erhält, etwa beim Wechsel vom Lesen eines Issues zum Schreiben von Repository-Dateien.

Das Anwendungsdiagramm allein zeigt nicht das gesamte Entwicklungsrisiko. Eine Produktionsdatenbank kann privat sein, während ein CI-Job Zugangsdaten offenlegt. Beziehen Sie temporäre Umgebungen und Supportzugriff ein, wenn sie das Szenario beeinflussen.

Beschreiben Sie einen konkreten Fehlerpfad

Vermeiden Sie Einträge wie „KI könnte unsicher sein“. Nennen Sie Akteur, Aktion, betroffenes Schutzgut und Folge. Ergänzen Sie die Bedingungen, unter denen das Szenario eintreten kann.

Dies sind Beispiele und keine vollständige Bedrohungsliste. Ihre Daten, Werkzeuge und Betriebsumgebung bestimmen die relevanten Szenarien.

Wählen Sie eine Reaktion mit einem Verantwortlichen

Priorisieren Sie Folgen und glaubwürdige Exposition. Stellen Sie eine numerische Bewertung nicht als Genauigkeit dar, die Sie nicht besitzen. Dokumentieren Sie Unsicherheit und Nachweise, die die Priorität ändern könnten.

Eine Reaktion kann die riskante Fähigkeit entfernen, ihren Umfang begrenzen, eine Kontrolle ergänzen oder ein definiertes Restrisiko akzeptieren. Akzeptanz braucht einen befugten Verantwortlichen und eine Begründung. Sie sollte keine ungeprüfte Schlussfolgerung eines Agenten sein.

Machen Sie aus der gewählten Reaktion eine Aufgabe mit beobachtbarer Abnahmebedingung. „Agentensicherheit verbessern“ ist schwer prüfbar. „Der Testjob kann das Produktionssecret nicht lesen“ definiert eine prüfbare Grenze.

Prüfen Sie nach wesentlichen Änderungen

Ein neuer Konnektor, Modellpfad, eine neue Umgebung oder Berechtigung kann das Bedrohungsmodell verändern. Nehmen Sie diese Änderungen als Prüfauslöser auf. Nutzen Sie auch Incidents und fehlgeschlagene Evaluationen, um Annahmen zu aktualisieren.

Probieren Sie die Risikoprüfungsübung, um Daten, Befugnisse, Zielgruppe und Wiederherstellungsbedingungen eines Szenarios zu ändern. Das Ergebnis schlägt Fragen vor. Es ersetzt kein systemspezifisches Bedrohungsmodell und erteilt keine Freigabe für die Arbeit.