Warum AI-native Apps traditionelle AppSec-Modelle sprengen

AI-native Anwendungen verhalten sich anders als die Software, die Sicherheitsteams normalerweise schützen. Statt vorhersehbaren Logikpfaden zu folgen, generieren diese Systeme Code spontan, verändern Benutzereingaben und treffen zur Laufzeit kontextabhängige Entscheidungen. Das Verhalten eines Modells wird durch eine Mischung aus Trainingsdaten, Feinabstimmung, Prompts und Variablen der Retrieval-Quellen geprägt, die seine Entscheidungen auf eine Weise beeinflussen, die Entwickler möglicherweise nicht vorhersehen.

Dadurch erweitert sich die Angriffsfläche über Code und Konfiguration hinaus. Ein Prompt kann die Schlussfolgerungen eines Modells umlenken, ein vergifteter Datensatz kann zukünftige Ausgaben verfälschen, und ein unzureichend eingeschränkter Agent kann Aktionen ausführen, die Entwickler nie programmiert haben. All das passt nicht in die statischen, reproduzierbaren Muster, auf die sich traditionelle AppSec-Tools verlassen.

Das Ergebnis ist eine Bedrohungslandschaft voller Fragen, die Legacy-Scanner nicht beantworten können. Welches Modell steuert einen wichtigen Workflow, und welche Daten haben es geprägt? Wie verhält sich ein RAG-System, wenn sich seine Retrieval-Quelle ändert? Dabei handelt es sich um grundlegende Sicherheitsfragen, doch traditionellen Tools fehlt die nötige Transparenz, um sie zu beantworten. AI-native Software hat das Problem grundlegend verändert, und ältere Annahmen gelten nicht mehr.

Traditionelle AppSec setzt vorhersehbare Codepfade voraus

Traditionelle AppSec-Praktiken gehen davon aus, dass Software vorhersehbaren Pfaden folgt. Static Application Security Testing (SAST) funktioniert, weil sich Code nachverfolgen lässt, und Dynamic Application Security Testing (DAST) funktioniert, weil sich Schnittstellen reproduzierbar verhalten. Beide Ansätze beruhen auf der Annahme, dass Entwickler die Logik geschrieben haben und sie sich jedes Mal gleich verhält.

AI-native Anwendungen stellen diese Grundlage infrage. Ein LLM kann bei ähnlichen Eingaben unterschiedliche Ausgaben erzeugen, weil sich sein Verhalten abhängig von Prompts, Kontext und abgerufenen Informationen verändert. Diese Variabilität ist nicht auf Codeänderungen zurückzuführen, sondern auf die internen Schlussfolgerungen des Modells.

Diese Variabilität untergräbt die Vorhersehbarkeit, auf die traditionelle Scanner angewiesen sind. SAST kann nichtdeterministische Logik nicht abbilden, und DAST kann Interaktionen nicht wiederholen, wenn sich Ausgaben zur Laufzeit verändern. Keiner der beiden Ansätze kann spontan generierte Logik bewerten. Wenn ein Modell statt statischem Code das Kernverhalten bestimmt, können Legacy-Tools keine zuverlässigen Bewertungen liefern.

AI-native Bedrohungsklassen passen nicht in alte Kategorien

Die Diskrepanz wird noch deutlicher, wenn man die Bedrohungskategorien selbst betrachtet. Traditionelle Scanner erkennen Schwachstellen im Code zuverlässig, doch AI-native Risiken haben ihren Ursprung oft außerhalb des Codes. Sie entstehen durch das Verhalten und entziehen sich damit dem Zugriff der meisten vorhandenen Tools.

Prompt Injection macht das deutlich: Eine einzige Eingabe kann die Schlussfolgerungen eines Modells umlenken, Schutzmaßnahmen umgehen oder interne Daten offenlegen, ohne den Code anzutasten. Data Poisoning birgt ein ähnliches Risiko zu einem früheren Zeitpunkt im Lebenszyklus: Verunreinigte Trainingsdaten führen lange nach der Bereitstellung zu schädlichen oder ausnutzbaren Ausgaben.

RAG-Workflows bergen Risiken, weil manipulierte Retrieval-Quellen das Modellverhalten beeinflussen können, ohne dass Codeänderungen erforderlich sind. Die umfassendere Modell-Lieferkette, zu der vortrainierte Modelle, Embeddings und Drittanbieter-Agenten gehören, führt undurchsichtige Abhängigkeiten ein, die Teams oft ohne vollständige Transparenz übernehmen.

All diese Bedrohungen entstehen zur Laufzeit und nicht im statischen Code. So entsteht eine Klasse von Schwachstellen, die traditionelle Scanner nicht erkennen können. Das Ergebnis sind immer mehr blinde Flecken, für deren Bewältigung die meisten AppSec-Programme nie ausgelegt waren.

Der Knackpunkt: AppSec fehlt die Transparenz auf Modellebene

Diese neuen Bedrohungsklassen machen ein tiefer liegendes Problem sichtbar: Den meisten AppSec-Programmen fehlt nahezu jede Transparenz auf Modellebene. Teams können Softwareabhängigkeiten erfassen, verfolgen aber nur selten, welche Modelle in der Produktion laufen oder durch welche Daten und Trainingsprozesse sie geprägt wurden.

Auch wichtige Interaktionen bleiben undurchsichtig. Es gibt keine standardisierte Möglichkeit, Prompts nachzuverfolgen, Schutzmaßnahmen zu überprüfen oder Entscheidungen zur Inferenzzeit zu beobachten. Traditionelle Protokolle erfassen API-Aufrufe, nicht aber die Schlussfolgerungsschritte oder Agentenaktionen, die das KI-Verhalten bestimmen.

Daher können traditionelle Scanner weder Modell-Drift noch unerwartete Agentenaktionen oder durch externe Daten verursachte Änderungen erkennen. Sie wurden nie dafür entwickelt, das Verhalten auf Modellebene zu beobachten. Ohne neue Methoden für mehr Transparenz sind blinde Flecken somit unvermeidlich.

AI-native Apps benötigen ein neues Sicherheitsartefakt: die AI Bill of Materials (AI-BoM)

Diese Transparenzlücke zeigt, dass AI-native Systeme ein neues Sicherheitsartefakt benötigen. Die AI Bill of Materials (AI-BoM) bietet eine strukturierte Möglichkeit, die verwendeten Modelle, die Daten, durch die sie geprägt wurden, sowie die Prompts oder Agenten zu dokumentieren, die ihr Verhalten beeinflussen. Ähnlich macht eine SBOM die Komponenten der Software-Lieferkette transparent.

Durch die Zusammenführung dieser Elemente wird der Kontext wiederhergestellt, der AppSec-Programmen fehlt. Teams erhalten einen klaren Überblick über die Herkunft der Modelle, den Einfluss der Daten und sich verändernde Risiken. Die AI-BoM unterstützt außerdem Governance und Compliance, indem sie zeigt, wie KI-Systeme aufgebaut sind und worauf sie basieren. Mit zunehmender Komplexität der Workflows dient sie als verlässlicher Bezugspunkt, um Risiken zu bewerten und zu erkennen.

Die AI-BoM schafft die Grundlage wieder, die AppSec benötigt. Ohne sie müssen Teams auf Verhaltensweisen reagieren, die sie nicht sehen können. Mit ihr lässt sich KI in dasselbe strukturierte und verantwortungsvolle Sicherheitsframework integrieren, das auch für Software im großen Maßstab zum Einsatz kommt.

Warum agentisches Verhalten zum Knackpunkt wird

Wenn Teams damit beginnen, Modelle, Datensätze und Prompts mithilfe einer AI-BoM zu dokumentieren, lässt sich eine weitere Herausforderung nicht mehr ignorieren: KI-Systeme erzeugen nicht mehr nur Ausgaben, sondern führen auch Aktionen aus. Autonome Agenten können Tools aufrufen, Dateien schreiben, Systeme aktualisieren und Workflows auf Grundlage von Zielen statt festgelegter Logik auslösen. Ihr Verhalten verändert sich mit dem Kontext und den abgerufenen Informationen. So entsteht ein Maß an Autonomie, für dessen Analyse traditionelle AppSec nie ausgelegt war.

Legacy-Ansätze können Funktionen und Kontrollflüsse bewerten, aber weder Absichten nachvollziehen noch die verzweigten Aktionsketten abbilden, die ein Agent zur Laufzeit bilden könnte. Diese Pfade verändern sich von Moment zu Moment – nicht, weil sich der Code ändert, sondern weil sich die den Aktionen zugrunde liegenden Schlussfolgerungen ändern.

AI-native Anwendungen zu schützen bedeutet, nicht nur den Code zu verfolgen, sondern auch das Verhalten, das er im Laufe der Zeit hervorbringt. Dazu muss sichtbar sein, wie Agenten handeln, womit sie interagieren und wie sich ihre Entscheidungen entwickeln. Diese dynamische Autonomie markiert den Knackpunkt für traditionelle AppSec und macht ein neues Sicherheitsmodell unvermeidlich.

Was ein moderner, auf Modelle abgestimmter Sicherheitsansatz erfordert

Die Grenzen von Legacy-AppSec zu erkennen, ist erst der Anfang. Als Nächstes gilt es zu definieren, wie ein Sicherheitsmodell aussieht, das dem tatsächlichen Verhalten von KI-Systemen Rechnung trägt. Wenn Logik dynamisch ist und Agenten autonom handeln können, muss sich der Fokus der Sicherheit von der Analyse statischer Artefakte auf das Verständnis des gesamten Lebenszyklus des Modellverhaltens verlagern.

Das beginnt mit Transparenz. Teams müssen klar erkennen können, welche Modelle verwendet werden, welche Daten sie geprägt haben, wie sie sich zur Inferenzzeit verhalten und welche Aktionen ihre Agenten auslösen können. Ohne diesen Kontext werden alle nachgelagerten Sicherheitskontrollen reaktiv.

Auch Schutzmaßnahmen müssen sich weiterentwickeln. Es reicht nicht mehr aus, die Codequalität oder eine saubere Konfiguration zu überprüfen. Moderne Schutzmaßnahmen müssen das Modellverhalten bewerten, Prompt-Flows nachverfolgen und erkennen, wenn Ausgaben von erwarteten Mustern abweichen. Sie sollten Schlussfolgerungen melden können, die in unsicheres Terrain führen – nicht nur Fehler, die im Code stecken.

Da diese Systeme adaptiv sind, ist eine kontinuierliche Überwachung erforderlich. Modell-Drift, Data Poisoning, unsichere Ausgaben und unerwartete Tool-Nutzung können sich schrittweise oder auf einen Schlag bemerkbar machen. Traditionelle regelmäßige Scans übersehen solche Veränderungen. AI-native Systeme müssen kontinuierlich beobachtet werden, damit Teams relevante Änderungen sofort erkennen können.

Und schließlich muss sich all dies in bestehende Entwicklungs-Workflows integrieren lassen. Wenn Sicherheit erst nach der Bereitstellung ins Spiel kommt, müssen Unternehmen Kontrollen nachträglich an Verhaltensweisen anpassen, die sich bereits etabliert haben. Werden diese Fähigkeiten früher im Lebenszyklus eingebunden, können Teams handeln, bevor sich Risiken festsetzen.

Ein auf Modelle abgestimmter Sicherheitsansatz ersetzt AppSec nicht. Er erweitert AppSec und trägt der Art Rechnung, wie KI-Systeme denken, entscheiden und handeln.

AppSec entwickelt sich zur KI-Sicherheitsorchestrierung weiter

Ein auf Modelle abgestimmter Ansatz schafft die Grundlage, doch Unternehmen benötigen weiterhin eine Möglichkeit, ihn in die Praxis umzusetzen. Hier beginnt sich Anwendungssicherheit zu etwas Neuem zu entwickeln: zur Orchestrierung des gesamten KI-Systems. Statt Modelle, Prompts, Datensätze und Agenten als undurchsichtige Komponenten zu behandeln, muss die Sicherheit sie koordinieren, ihr Verhalten beobachten und während des Betriebs Schutzmaßnahmen anwenden.

Evo steht für diesen Wandel. Evo erweitert Sicherheit über Code und Konfiguration hinaus, indem es spezialisierte Agenten orchestriert, die das Verhalten von Modellen überwachen, Bedrohungen auf Modellebene erkennen und Schutzmaßnahmen in Echtzeit anwenden. Diese Agenten ermöglichen es Teams, die Komponenten von KI-Systemen zu verstehen und zu kontrollieren, die für traditionelle AppSec unsichtbar sind: Schlussfolgerungen, Retrieval-Entscheidungen und Aktionen autonomer Workflows.

Snyk Studio ergänzt diesen Ansatz am anderen Ende des Lebenszyklus. Es unterstützt KI-Coding-Assistenten bei der Codegenerierung und stellt sicher, dass von KI geschriebener Code von Anfang an sicher ist, statt später korrigiert werden zu müssen. Studio steht für „secure at inception“, während Evo sicheres Verhalten gewährleistet, wenn Modelle ausgeführt werden, sich anpassen und handeln.

Gemeinsam erweitern sie die Definition von Anwendungssicherheit. In einer AI-native Welt bedeutet Anwendungssicherheit, den Code, der eine Anwendung ausführt, die sie steuernden Modelle und die in ihrem Auftrag handelnden Agenten abzusichern. Evo bringt diese Elemente zusammen. Es lenkt AppSec in eine Zukunft, die auf Orchestrierung statt statischer Analyse beruht.

Traditionelle AppSec ist nicht falsch – sie ist unvollständig

Traditionelle AppSec ist nicht gescheitert. Die Rahmenbedingungen haben sich verändert. AI-native Software stellt langjährige Annahmen darüber infrage, wie Logik geschrieben wird, wie sich Systeme verhalten und wo Risiken entstehen. Code ist nicht länger die einzige Quelle der Wahrheit. Verhalten, Kontext und modellgesteuerte Entscheidungsfindung prägen Anwendungen auf eine Weise, die statische Tools nie zu interpretieren vermochten.

Um diese neue Systemklasse zu schützen, muss kontinuierlich sichtbar sein, wie Modelle Schlussfolgerungen ziehen, wie Agenten handeln und wie sich Workflows entwickeln. Unternehmen, die diesen Wandel früh erkennen, vermeiden blinde Flecken, die die Entwicklung verlangsamen und sie verborgenen Risiken aussetzen. Sie arbeiten schneller, entwickeln mit mehr Zuversicht und nutzen KI als Beschleuniger statt als unkontrollierbare Variable.

Snyk trägt dazu bei, diesen Wandel voranzutreiben. Indem wir Sicherheit von Code auf Modelle, Prompts und agentisches Verhalten ausweiten, entwickeln wir AppSec von einer codezentrierten Disziplin hin zu einem auf KI abgestimmten Ansatz weiter. Das ist die Richtung, die die Branche einschlagen muss – und auf die wir hinarbeiten.

Möchten Sie AI-native Anwendungen mit integrierten Schutzmaßnahmen entwickeln? Entdecken Sie den umfassenden Leitfaden zum Schutz agentischer Apps und zur Orientierung in der neuen Bedrohungslandschaft.