KI-Modell-Risikobewertung: Erkennen Sie vor dem Deployment, welchen Modellen Sie vertrauen können

Als wir überlegten, wie wir KI-Modellrisiken in Evo sichtbar machen, lag die naheliegende Antwort darin, unsere bisherige Bewertungsmethode zu übernehmen: Problem finden, Schweregrad zuweisen, sichtbar machen. Erledigt.

Im Mittelpunkt des neuen Ansatzes steht ein echter Risikoscore, der der Denkweise von Security-Teams entspricht: Wahrscheinlichkeit × Auswirkung. Die Wahrscheinlichkeit ergibt sich aus der Attack Success Rate (ASR), also dem Anteil realer adversarialer Angriffe, die gegen ein Modell erfolgreich sind. Die Auswirkung beschreibt, wie groß der Schaden ist, wenn das Ziel des Angreifers erreicht wird. Daraus berechnen wir einen einzigen Score von 0 bis 1000 (je niedriger, desto besser).

Da die beiden Werte miteinander multipliziert werden, kann keiner für sich allein ausschlaggebend sein: Ein seltener, aber katastrophaler Angriff wird durch seine geringe Wahrscheinlichkeit abgewertet, ein häufiger, aber harmloser Angriff durch seine geringe Auswirkung. Ganz oben stehen die wirklich wichtigen Angriffe: jene, die häufig erfolgreich sind und dabei echten Schaden anrichten.

Neue Methodik für den Risikoscore

Anders als eine Checkliste oder eine Sicherheitsbewertung eines Anbieters basiert die ASR auf realen adversarialen Tests, etwa Extraktions-Prompts, Eskalationen über mehrere Gesprächsrunden, Persona-basierten Jailbreaks und Tree-of-Attack-Strategien. Modellbasierte Bewertungsinstanzen bestätigen dabei, ob jeder Angriff tatsächlich erfolgreich war.

Diese Angriffe sind weder theoretisch noch bloße Modellwerte ohne Schutzmaßnahmen. Jeder Angriff im Benchmark wird gegen eine Baseline-Abwehr mit gehärtetem System-Prompt getestet. Der Risikoscore zeigt also, was selbst bei einer standardmäßigen Schutzmaßnahme noch durchkommt: Angriffe, die in der Produktion funktionieren, nicht nur im Labor.

Der Score ist handlungsrelevant, weil er sich an den Auswirkungen orientiert: Er berücksichtigt, was tatsächlich schiefgeht, wenn ein Angriff erfolgreich ist, und nicht nur, ob er gelingt. Und er bleibt nicht bei einer Zahl stehen. Evo schlüsselt jeden Score nach dem konkreten Ziel des Angreifers auf: PII-Extraktion, Extraktion des System-Prompts durch Injection und unsichere Codegenerierung. So sehen Sie genau, wo ein bestimmtes Modell Schwächen hat und welche Schutzmaßnahme dafür geeignet ist. Diese Granularität liefert Ihnen die nötigen Informationen, bevor Sie über ein Deployment entscheiden.

Das ist für Security-Teams sofort relevant. Sie sehen das Risiko eines Modells aufgeschlüsselt nach den konkreten Angreiferzielen, gegen die es anfällig ist, statt eines abstrakten Urteils wie „sicher/unsicher“. Sie müssen nicht mehr fragen, ob ein Modell generell sicher ist, sondern können klären, ob es für das geplante Vorhaben sicher ist.

Der erste Ansatz – ein Problem finden, einen Schweregrad zuweisen und weitermachen – hatte einen schwerwiegenden Mangel. Davon hörten wir direkt von unseren Kunden.

Security-Teams sahen bei einem Befund, dass ein Modell ein Problem mit der „Offenlegung von Informationen“ hatte, und stellten immer dieselbe erste Frage: Was bedeutet das konkret, und was soll ich dagegen tun? Das Label zeigte ihnen, dass etwas nicht stimmte. Es sagte ihnen aber nicht, wie schwerwiegend das Problem war, in welchem Kontext es auftrat, gegen welche Art von Angriff es sich richtete oder welche Schutzmaßnahme sie entwickeln sollten.

Also haben wir den Ansatz neu entwickelt. Das hat sich geändert – und darum.

Die Lücke wurde in Gesprächen mit Kunden immer wieder deutlich. Als wir konkrete Zahlen präsentierten – GPT-3.5 mit einem Score von 397/1000 für unsichere Inhalte, GPT-4 mit 317/1000 für Voreingenommenheit und Fairness –, hörten die Teams auf zu fragen, ob ein Modell sicher sei, und begannen, Modelle zu vergleichen.

Das Problem ist nicht der Score, sondern der Kontext.

Bei den meisten KI-Risikobewertungen wird ein Modell wie ein statisches Artefakt behandelt. Man führt einige Tests durch, weist eine Kategorie zu und veröffentlicht eine Sicherheitsbewertung. Anschließend versuchen Teams, auf dieser Grundlage über ein Deployment zu entscheiden.

Doch KI-Risiken funktionieren nicht so. Dasselbe Modell birgt je nach Einsatz grundlegend unterschiedliche Risiken. Ein Coding-Agent ist mit dem Diebstahl von Zugangsdaten, Backdoors, von Angreifern gesteuerten Befehlen und Dependency-Poisoning konfrontiert. Ein Kunden-Chatbot muss sich gegen Jailbreaks, die Generierung schädlicher Inhalte und die Extraktion von Prompts behaupten. Ein persönlicher Assistent mit Zugriff auf E-Mails, Kalender und Dokumente ist einer ganz anderen Angriffsfläche ausgesetzt.

Ein Risikoscore, der den Deployment-Kontext nicht berücksichtigt, ist kein Risikoscore. Er ist eine Schätzung. Evo bezieht diesen Kontext in die Gewichtung der Auswirkungen ein. So spiegelt der Score wider, wie ein Modell tatsächlich eingesetzt wird – und nicht, wie es sich losgelöst von seinem Einsatz verhält.

Ein zweites Problem sind indirekte Angriffe. Die meisten Modellbewertungen konzentrieren sich auf direkte Prompts: Eine Person gibt etwas Bösartiges ein, und wir prüfen, ob das Modell widersteht. Das ist wichtig, lässt aber die gefährlichere Angriffsklasse außer Acht, die auf agentische Systeme abzielt: Bei einer indirekten Prompt Injection werden schädliche Anweisungen in Daten eingebettet, die der Agent liest, etwa in einem abgerufenen Dokument, einem Tool-Ergebnis oder einem Codekommentar. Die nutzende Person sieht diese Anweisungen nie. Der Agent verarbeitet sie als Kontext. Befolgt das Modell sie, kann es sensible Daten preisgeben, Tools missbrauchen oder nicht autorisierte Aktionen ausführen. Tests, die nur das Modell prüfen, erkennen das nicht.

Das ist keine rein theoretische Sorge. Ein Unternehmen wandte sich wegen eines dringenden Vorfalls an uns, der direkt durch das Risiko eines LLM-Modells verursacht wurde. Bei einer globalen Bank eskalierte ein ähnlicher Vorfall bis zum CEO. Ein nationaler Kreditgeber wollte Einblick in die MCP-Nutzung gewinnen und Schutzmaßnahmen einführen. Diese Teams fragten nicht abstrakt nach der Sicherheit von Modellen, sondern nach ihrem Verhalten in einem konkreten agentischen Kontext.

Wir wollten, dass Risk Intelligence eine andere Frage beantwortet: Wie verhält sich dieses Modell unter Angriffen in dem Einsatzszenario, das Sie tatsächlich planen?

Was wir entwickelt haben: auswirkungsbasierte Risikobewertung bis hin zum Ziel des Angreifers

1. Welche Modelle und KI-Funktionen werden in der Codebasis genutzt? Security-Teams müssen wissen, wo KI zum Einsatz kommt, welche Modelle aufgerufen werden und welche Funktionen oder Tools zum System gehören.

2. Wie verhält sich jedes Modell unter Angriffen? Teams benötigen Risikoprofile, die auf adversarialen Tests statt auf statischen Behauptungen oder allgemeinen Sicherheitsdokumentationen beruhen.

3. Wie können wir auf die Ergebnisse reagieren? Ein Score ist nur dann nützlich, wenn er Teams dabei hilft, Modelle zu vergleichen, Schutzmaßnahmen zu priorisieren und Richtlinien anwendungs- und repositoryübergreifend durchzusetzen.

Das zentrale Ergebnis ist ein einzelner Risikoscore von 0 bis 1000, gewichtet nach den realen Auswirkungen dessen, was ein Angreifer erreichen kann. Die Attack Success Rate ist die gemessene Grundlage dafür.

Der Score zeigt Ihnen, wie angreifbar ein Modell ist. Die Taxonomie zeigt, welche Angriffe dazu beigetragen haben und warum sie für Ihren Deployment-Kontext relevant sind.

Evo ordnet Befunde in einer dreistufigen Taxonomie ein, die sich an den Auswirkungen orientiert – also daran, was tatsächlich schiefgeht. Eine übergeordnete Auswirkungskategorie (zum Beispiel die Offenlegung von Informationen) wird in eine Unterkategorie und dann auf der detailliertesten Ebene in das konkrete Ziel des Angreifers aufgeschlüsselt (zum Beispiel PII-Extraktion). Direkte und indirekte Angriffe werden in der gesamten Taxonomie als separate Angriffsflächen erfasst, da sie unterschiedliche Schutzmaßnahmen erfordern. Ein Coding-Agent mit hoher ASR für indirekte Injection über Codekommentare benötigt eine andere Schutzmaßnahme als ein Chatbot mit hoher ASR für Jailbreaks. Die Taxonomie macht diesen Unterschied deutlich.

Außerdem wird jedes Angreiferziel den Frameworks zugeordnet, über die Ihr Team bereits berichtet: OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS und NIST. Ein Befund ist somit kein proprietäres Snyk-Label, das Sie erst übersetzen müssen, sondern lässt sich direkt in die Standards einordnen, denen Sie bereits unterliegen. Diese Zuordnung sehen Sie neben dem Score auf der Registerkarte „Risikoprofil“.

Diese Genauigkeit bringt Teams vom Score zum Maßnahmenplan. Und sie ermöglicht Evo, Risikobefunde direkt mit der Durchsetzung von Richtlinien zu verknüpfen – nicht als separaten Workflow, sondern als Teil desselben Ablaufs.

Abdeckung von Funktionen, nicht nur von Modellen

Grobe Risikolabels reichen nicht aus. Einem Team mitzuteilen, dass ein Modell ein Problem mit der „Offenlegung von Informationen“ oder „unsicheren Inhalten“ hat, schafft vielleicht Bewusstsein, sagt aber nicht, was behoben werden muss. Eine hilfreiche Risikobewertung schlüsselt jeden Befund nach dem konkreten Ziel des Angreifers auf. Beispiele sind die Extraktion des System-Prompts durch Injection, die nicht autorisierte Ausführung von Tools, die Generierung schädlicher Inhalte, unsichere Codegenerierung oder die Exfiltration sensibler Daten.

Diese Detailtiefe hilft Teams dabei, zu entscheiden, welche Schutzmaßnahmen sie entwickeln und welche Richtlinien sie durchsetzen sollten und ob ein Modell für einen bestimmten Anwendungsfall geeignet ist. Außerdem hilft sie Führungskräften, Risiken auf verschiedenen Ebenen zu verstehen. Eine übergeordnete Kategorie kann zeigen, wo das Unternehmen Risiken ausgesetzt ist. Eine detailliertere Angriffsfläche kann aufzeigen, ob Angriffe direkt oder indirekt erfolgen. Ein konkretes Angreiferziel sagt den Engineering-Teams genau, was fehlgeschlagen ist.

Risiken stecken nicht allein in Modellen. Sie entstehen durch das Zusammenspiel eines Modells mit den Tools, die es aufrufen kann, und den Funktionen, die es nutzt. Ein Modell, das isoliert gut abschneidet, kann sich ganz anders verhalten, wenn es mit einem Dateisystem-Tool, einer Codeausführungsumgebung oder einem Speicher für sensible Daten kombiniert wird.

Evo ordnet die Abdeckung von Funktionen neben dem Modellrisiko ein und zeigt Teams übersichtlich, welche Funktionen genutzt werden, welchen Modellen sie zugeordnet sind und wie die kombinierte Angriffsfläche aussieht. Diesen Überblick über den Bestand benötigen Security-Teams, bevor sie fundierte Deployment-Entscheidungen treffen können.

Das ist besonders für Coding-Agenten relevant, bei denen dasselbe Modell in einem Moment Pull Requests überprüft und im nächsten Deployment-Befehle ausführt. Das Risikoprofil verändert sich erheblich – je nachdem, was das Modell gerade tut und auf welche Tools es dabei zugreifen kann.

Von Erkenntnissen zur Durchsetzung

Evo unterstützt Teams dabei, das Verhalten von Modellen unter Angriffen zu verstehen, bevor sie ihnen in der Produktion vertrauen. Beim Scannen einer Codebasis erkennt Evo die verwendeten KI-Modelle und Funktionen und ergänzt sie um Risikoprofile, die auf adversarialen Tests beruhen. Diese Profile basieren auf der Attack Success Rate, die anhand realer adversarialer Angriffe gemessen und nach Auswirkung gewichtet wird. So spiegelt der Score die Konsequenzen wider und nicht nur die Anzahl der Angriffe.

Risk Intelligence ordnet die Befunde außerdem in einer detaillierten Taxonomie ein, von übergeordneten Kategorien bis hin zu konkreten Angreiferzielen. Jeder Befund wird OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS und NIST zugeordnet. So können Teams vom zusammenfassenden Score zum konkreten erfolgreichen Angriffsmuster gelangen und es dem Framework zuordnen, über das sie bereits berichten. Da Risk Intelligence mit der Policy Engine von Evo verbunden ist, können Teams Erkenntnisse in verbindliche Maßnahmen umsetzen. Sie können Modelle vor einer Entscheidung vergleichen, erkennen, welche Modelle in bestimmten Deployment-Kontexten das höchste Risiko bergen, sofort einsatzbereite Richtlinien verwenden und Schwellenwerte an ihre Risikotoleranz anpassen.

An der Lücke zwischen Risikoscore und Richtliniendurchsetzung scheitern die meisten KI-Sicherheitsprogramme. Teams erhalten einen Befund, wissen aber nicht, was sie damit anfangen sollen.

Evo schließt diese Lücke, indem Risk Intelligence direkt mit der Policy Engine verbunden wird. Zeigt ein Modell für ein bestimmtes Angreiferziel oder Angriffsmuster einen hohen Risikoscore, können Teams Schwellenwerte festlegen, Richtlinien anwenden und risikoreiche Modelle in sensiblen Kontexten blockieren – alles im selben Workflow.

Für Snyk-Kunden erweitert das ein vertrautes Vorgehen: Risiken dort aufdecken, wo Entwickler arbeiten, Wichtiges priorisieren und Richtlinien konsequent durchsetzen. Der Unterschied: Die Richtlinie gilt jetzt auch für die Auswahl von KI-Modellen und die Konfiguration von Agenten – nicht nur für Code.

Warum das jetzt wichtig ist

KI-Sicherheit darf nicht auf Vermutungen beruhen. Wenn Modelle und Agenten in reale Anwendungen einziehen, müssen Teams verstehen, wie sich diese Systeme unter Angriffen verhalten.

KI-Modell-Risikobewertung ermöglicht es Unternehmen, das Modellverhalten zu messen, Risiken je nach Anwendungsfall zu vergleichen, Abhilfemaßnahmen zu priorisieren und die Einführung von KI umfassend zu steuern. Die Frage lautet nicht mehr einfach: „Ist dieses Modell sicher?“ Die bessere Frage lautet: „Wie verhält sich dieses Modell unter Angriffen in dem Einsatzszenario, das wir planen?“

Die meisten Teams, mit denen wir sprechen, arbeiten mit KI-Modellen, für die sie sich nicht ausdrücklich entschieden haben. Sie haben diese von einem Anbieter übernommen, über ein Entwickler-Tool eingeführt oder bei einem Audit entdeckt. Der neue Bericht von Snyk State of Agentic Adoption, Volume II wertete anonymisierte KI-BOM-Telemetriedaten von 3.044 Unternehmen aus. Das Muster ist eindeutig: Auf jedes Modell, das einem Team bekannt ist, kommen ungefähr 2,8 weitere KI-Komponenten, Bibliotheken, MCP-Server und SDKs, die nicht verwaltet werden. Zudem können die meisten Unternehmen keine vollständige Bestandsaufnahme ihrer Ressourcen vorlegen. Als ein Team den Aufwand abschätzte, ergab sich: Eine vollständige KI-Bestandsaufnahme hätte 4 bis 5 Wochen und 10 bis 12 Stakeholder in Anspruch genommen. Das Problem mit der Modellinventarisierung besteht also bereits, bevor die Diskussion über Risikobewertungen überhaupt beginnt.

Die Nachfrage nach solchen Funktionen wächst rasant. Erweiterte AI-SPM-Funktionen sind für bestehende Kunden ab sofort verfügbar. Wirkungsbasierte Risikobewertungen, die auf der Angriffs-Erfolgsrate realer adversarialer Tests basieren, werden Ende August 2026 verfügbar sein. Buchen Sie noch heute eine Demo, um mehr zu erfahren.