Remediation-Agenten verständlich erklärt: Warum Beheben besser ist als Finden

Sechs neue Sicherheitsprobleme für jedeseine behobene Problem. Das ist das Verhältnis, das die Snyk-Forschung ermittelt hat – und der Grund, warum die Community der AI Security Engineers eine Stunde Livestream-Zeit dem Beheben statt dem Finden gewidmet hat.

Play Video: Remediation Agents Demystified: Your AI Teammate for Fixing Security Bugs

Remediation Agents Demystified kombinierte einen Fireside Chat mit einer Live-Demo. Gérald Crescione, Leiter der globalen AI-Security-Engineers-Community, moderierte die Veranstaltung gemeinsam mit Ryan McMorrow, der bei Snyk die Produkte für die Behebung von Sicherheitsproblemen leitet, und Brendan Hann, Senior Product Marketing Manager für Snyks Developer Experience und die Agentic-AppSec-Lösung.

Remediation Agent, derzeit als Public Preview verfügbar, ist Snyks Antwort auf das Problem des hohen Problemvolumens, das wir beobachten. Während das Team das Produkt weiterhin öffentlich entwickelt und iteriert, bietet Snyk den Remediation Agent allen aktuellen Snyk-Kunden ohne zusätzliche Kosten an – im Austausch für umsetzbares Feedback aus der Community. Dieses Feedback kann im Subreddit der Community geteilt werden.

Warum die Behebungsrate stagnierte

Die Coding-Agenten, die Entwickler heute überall einsetzen, optimieren auf funktionierenden Code, nicht auf sicheren, funktionierenden Code. Daher steigt das Problemvolumen, während die Behebungsrate stagniert. AppSec-Tools begegneten dem mit deterministischen Empfehlungen: Sie verwenden Version 1.0, die Schwachstelle ist in Version 1.1 behoben, also führen Sie ein Upgrade durch. So weit, so gut – außer, dass weiterhin jemand nachweisen muss, dass das Upgrade nichts beschädigt hat, und kein Tool dies im Namen der Entwickler übernahm. Sobald der Sprung drei oder vier Hauptversionen umfasste, fanden die meisten Teams nie das nötige Vertrauen, um den Merge überhaupt durchzuführen.

Hann ordnete diesen Engpass in einen umfassenderen Wandel ein. KI hat drei unterschiedliche, aber miteinander verbundene Belastungen geschaffen: Angriffe werden inzwischen mit KI automatisiert; Agenten schreiben Software schneller als je zuvor und führen im gleichen Tempo Schwachstellen ein; und KI erreicht die Produktion, oft ohne Governance. Die Behebung war schon immer ein Engpass, argumentierte er, aber jetzt ist sie wichtiger, weil sich auch die Werkzeuge der Angreifer verändert haben. Modelle der Frontier-Klasse brechen aus Sandboxen aus und verknüpfen zuvor ignorierbare Findings mit niedriger Kritikalität zu neuartigen Zero-Day-Schwachstellen. Der Rückstand akzeptierter Risiken ist selbst zu einer Angriffsfläche geworden.

Agentic AppSec deckt diese Kombination ab: präventive Kontrollen, Erkennung auf Frontier-Niveau und autonome Behebung – oder, in Hanns Worten, Teams mit einem Team aus Agenten auszustatten, das ihr AppSec-Programm tatsächlich für sie ausführen kann.

Warum es nicht funktioniert, einfach ein LLM auf den Rückstand anzusetzen

Die Snyk-Forscher taten zunächst das Naheliegende: Sie setzten ein LLM auf den Sicherheitsrückstand an und sahen, was passiert.

Das Modell erwies sich als äußerst eifrig und nur gelegentlich als richtig. Entwickler mussten weiterhin jede Änderung prüfen und die meisten davon ablehnen, was ungefähr so viel Zeit kostete wie die manuelle Behebung der Probleme. Ein größeres Modell hätte mehr vom Gleichen produziert.

Der Wendepunkt kam, als das Team eine andere Frage stellte: Was wäre, wenn das LLM alles wüsste, was Snyk weiß? Zehn Jahre Best Practices für die Anwendungssicherheit, ökosystemspezifisches Wissen über Upgrades und hart erarbeitete Erfahrung damit, welche Fixes gemergt werden und welche nicht.

Daraus entstand der Remediation Agent, den McMorrow als Harness oder Orchestrierungsschicht zwischen dem bevorzugten Modell des Entwicklers und einer aufrufbaren Intelligenzschicht beschrieb, die jedes von Snyk erfasste Problem und jede CVE abdeckt. Auf Abruf kann der Agent Folgendes abrufen:

• Bewertungen der Änderungsrisiken für Open-Source-Upgrades, mit einer Einschätzung, wie wahrscheinlich es ist, dass ein Upgrade Ihren Build beschädigt, basierend auf einer Datenbank mit jeder Paketversion und jeder darin enthaltenen Breaking Change

• Paketintegrität und Reachability-Scores, einschließlich der Frage, ob der anfällige Code in der Produktion ausnutzbar ist

• Generierung von SAST-Fixes über die Agent-Fix-Funktion von Snyk

• Ökosystem-Playbooks von Snyks eigenen Security Engineers, die abdecken, wie ein erfahrener Praktiker eine transitive Abhängigkeit aktualisieren oder eine bestimmte Klasse von SAST-Findings beseitigen würde

McMorrows Analogie lautete, dass das LLM eine Open-Book-Prüfung erhält und Snyk das Buch bereitstellt. Anschließend bewertet Snyk die Hausaufgaben des Agenten, führt Scans erneut aus, um zu bestätigen, dass das Problem tatsächlich verschwunden ist, und führt alle Unit-Tests im Projekt aus, um sicherzustellen, dass die Änderungen den Build nicht beschädigt haben.

Die von ihm mitgeteilten internen Ergebnisse waren eine Verbesserung von 94 % bei mergbaren SCA-Fixes und von 13 % bei mergbaren SAST-Fixes. Die Mehrheit der intern generierten SAST-Fixes wird inzwischen unverändert gemergt – bei deutlich geringeren Token-Kosten als beim naiven Ansatz.

Hann ergänzte die drei Muster, mit denen Snyks Designpartner den größten Erfolg hatten:

1. Kampagnen zum Abbau des Rückstands, bei denen Findings mit niedriger und informativer Priorität beseitigt werden, die Angreifer heute miteinander verknüpfen

2. Unternehmensweite Rollouts, bei denen jeder Entwickler einen Remediation Agent an seiner Seite erhält

3. Einsatz des Remediation Agents in agentischen Entwicklungsumgebungen (ADE), um zu verhindern, dass neue Probleme in die Codebasis gelangen

Die Demo: IDE und CLI

McMorrow führte den Agenten live mit OWASP Juice Shop aus und zeigte beide Einstiegspunkte.

1. Der IDE-Weg

Der IDE-Weg benötigt zwei Komponenten: einen /snyk-fix Skill und den Snyk Studio MCP-Server, die beide mit einem einzigen curl-Befehl aus dem Recipes-Repository von Snyk installiert werden können. Damit erhalten Sie den vollständigen Ablauf in Cursor, Windsurf, Antigravity oder VS Code mit einem Claude-Plugin – von SAST- und SCA-Scans über das Nachschlagen von Informationen, Codeänderungen, erneuten Scan, Testlauf und Bericht bis zum Pull Request. Auf der Bühne aktualisierte der Agent eine anfällige multer Abhängigkeit über eine Hauptversion hinweg, bestätigte, dass keine inkompatible API-Änderung die Nutzung des Festplattenspeichers durch die App beeinträchtigte, und aktualisierte die Lock-Datei.

2. Der CLI-Weg

In der CLI ist snyk fix --agentic --experimental --sca partizipativer. Sie listet jedes Paket auf, das sie vermutlich aktualisieren kann, zusammen mit der aktuellen Version, der von Snyk empfohlenen Zielversion, weil diese die meisten kritischen Probleme und schwerwiegenden Probleme behebt, sowie einem Änderungsrisiko-Score. Entwickler können:

• Alles beheben

• Nur Elemente mit geringem Änderungsrisiko beheben

• Bestimmte Findings auswählen

• Mit dem Agenten sprechen

McMorrow demonstrierte die letzte Option, indem er fragte, warum ein Sprung um Glob eine Hauptversion als hohes Risiko eingestuft wurde. Der Agent nannte als Begründung: die Umstellung auf eine Promise-basierte API, den veralteten Callback-Stil, Pfadtrennzeichen, die nur noch als Escape-Zeichen verwendet werden, sowie dass die Klasse Glob kein Event-Emitter mehr ist. Außerdem listete er die transitiven Schwachstellen auf, die durch das Upgrade behoben würden. Die neueste Version nutzt anschließend dieselbe Änderungsrisiko-Intelligenz, um die erforderlichen Codeänderungen vorzunehmen und so ein Upgrade mit hohem Risiko in eines mit geringem Risiko zu verwandeln.

Auf die Frage, woher die Begründung stammt, erklärte McMorrow, dass das Änderungsrisiko aus der Analyse von Release Notes und Breaking Changes im gesamten Open-Source-Ökosystem abgeleitet wird. Designpartner haben nur wenige False Positives gemeldet. Sie sind hauptsächlich ein SAST-seitiges Problem, und der Agent nutzt die bestehenden Engines von Snyk Code, um sie herauszufiltern.

Der Mensch im Prozess, dann der Mensch über dem Prozess

Jeder Weg der Demo endete mit einem Pull Request. „Wir gehen nicht hin und nehmen verrückte Codeänderungen vor“, wie Hann es formulierte, und der Entwickler behält die endgültige Freigabe, bis ein Agent genug Vertrauen erworben hat, damit jemand seine Arbeit ohne weitere Prüfung mergen würde.

Snyks eigene Teams führen den Agenten heute über die CLI aus, und eine autonome Variante befindet sich in aktiver Entwicklung: Snyk startet eine Sandbox, installiert den Agenten, lädt den Anwendungscode und gibt einen fertigen PR zurück. Früher stoppte Snyks CI-Pipeline bei neuen Schwachstellen und übergab das Problem an den Entwickler zurück; jetzt generiert sie stattdessen die Fixes, und Sie mergen die Arbeit des Agenten zusammen mit Ihrem eigenen Commit. Die Entwickler, berichtete McMorrow, freuen sich darüber, nicht noch einmal eingreifen zu müssen.

Hann verwies auf „Backlog Zero“ als realistisches Ziel sowie auf das Blockieren bösartiger Pakete und Slopsquatting auf Entwicklergeräten und Organisationsebene. McMorrow zufolge geht es langfristig um Kontrolle, Governance und Vertrauen: um den Übergang vom Menschen im Prozess zum Menschen über dem Prozess. Der Unterschied besteht darin, wer entscheidet: „Im Prozess“ bedeutet Pair Programming mit einem Agenten, während „über dem Prozess“ einen Agenten bezeichnet, der selbst entscheidet und weiß, wann er Sie hinzuziehen muss. Cresciones Ergänzung: Das ist das Berufsbild der Zukunft – AI Security Engineers, die ein ganzes Agentenrudel in ihrem Auftrag orchestrieren.

Selbst Hand anlegen

Für die ersten Schritte benötigen Sie ein Snyk-Konto und entweder die CLI oder eine unterstützte ADE sowie Ihren eigenen Modell-API-Key, da Bring-your-own-LLM für die Open Preview standardmäßig gilt. Open-Source-Maintainer können die gesamte Plattform über das Secure Developer Program kostenlos nutzen; dieses umfasst eine vollständige Enterprise-Lizenz.

Einen Fix gefunden, der nicht das gewünschte Ergebnis liefert? Teilen Sie uns dies in r/AISecEng mit. Ihr Feedback hilft dabei, die weitere Entwicklung des Remediation Agents zu gestalten, während Snyk das Produkt weiterhin öffentlich entwickelt und iteriert.