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

Sechs neue Sicherheitsprobleme für jedes eine behobene Problem. Das ist das Verhältnis, das die Snyk-Forschung ermittelt hat, und deshalb widmete die AI Security Engineers Community eine Stunde Livestream-Zeit dem Beheben statt dem Finden von Problemen.

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 zur Problembehebung leitet, und Brendan Hann, Senior Product Marketing Manager für Snyks Developer Experience und die Agentic-AppSec-Lösung.

Remediation Agent, jetzt als öffentliche Preview verfügbar, ist Snyks Antwort auf das Problem des wachsenden Problemvolumens. Während das Team die Lösung weiter ö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 unverändert blieb

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 unverändert bleibt. AppSec-Tools beantworteten das mit deterministischen Empfehlungen: Sie verwenden Version 1.0, die Schwachstelle ist in Version 1.1 behoben, also führen Sie ein Upgrade durch. Soweit gut – außer, dass weiterhin jemand nachweisen muss, dass das Upgrade nichts beschädigt hat, und kein Tool dies im Namen der Entwickler erledigte. Sobald der Sprung drei oder vier Hauptversionen umfasste, fehlte den meisten Teams das Vertrauen, den Code überhaupt zu mergen.

Hann ordnete diesen Engpass in einen umfassenderen Wandel ein. KI hat drei eigenständige, aber miteinander verbundene Herausforderungen geschaffen: Angriffe werden jetzt 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, so seine Argumentation, aber jetzt ist sie wichtiger, weil sich auch die Tools der Angreifer verändert haben. Frontier-Modelle durchbrechen Sandboxes und verknüpfen zuvor ignorierbare Findings mit niedrigem Schweregrad zu neuartigen Zero-Days. Der Rückstand an akzeptierten 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 einer Gruppe von Agenten auszustatten, die ihr AppSec-Programm tatsächlich für sie ausführen können.

Warum es nicht funktioniert, ein LLM auf den Backlog anzusetzen

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

Das Modell erwies sich als äußerst enthusiastisch 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 bekäme, was Snyk weiß? Zehn Jahre Best Practices für Anwendungssicherheit, ökosystemspezifisches Upgrade-Wissen und hart erarbeitete Erfahrung darüber, 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 Änderungsanfälligkeit für Upgrades von Open-Source-Komponenten. Dabei wird bewertet, wie wahrscheinlich es ist, dass ein Upgrade Ihren Build beschädigt – basierend auf einer Datenbank mit jeder Paketversion und jeder darin enthaltenen Breaking Change

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

• SAST-Fix-Generierung über Snyks Agent-Fix-Funktion

• Ö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 beheben würde

McMorrows Analogie lautete, dass das LLM einen Test mit offenem Buch erhält und Snyk das Buch bereitstellt. Anschließend bewertet Snyk die Arbeit des Agenten, führt Scans erneut aus, um zu bestätigen, dass das Problem tatsächlich behoben ist, und führt alle Unit-Tests im Projekt aus, um sicherzustellen, dass die Änderungen den Build nicht beschädigt haben.

Die von ihm geteilten internen Ergebnisse zeigten 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 informatorischer Priorität beseitigt werden, die Angreifer nun miteinander verknüpfen

2. Unternehmensweite Rollouts, bei denen jeder Entwickler einen Remediation Agent an die Seite gestellt bekommt

3. Einsatz des Remediation Agent 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 am 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 Snyks Recipes-Repository installiert werden können. Damit steht der vollständige Ablauf in Cursor, Windsurf, Antigravity oder VS Code mit einem Claude-Plug-in zur Verfügung – von SAST- und SCA-Scans über Intelligence-Abfragen, Codeänderungen, erneuten Scan, Testlauf, Bericht und 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 der Agent vermutlich aktualisieren kann, zusammen mit der aktuellen Version, der von Snyk empfohlenen Zielversion, weil sie die meisten kritischen Probleme und schwerwiegenden Probleme behebt, sowie einem Score für die Änderungsanfälligkeit. Entwickler können:

• Alles beheben

• Nur Elemente mit niedriger Änderungsanfälligkeit beheben

• Bestimmte Findings auswählen

• Mit dem Agenten sprechen

McMorrow demonstrierte die letzte Option, indem er fragte, warum ein Glob-Sprung über eine Hauptversion als hohes Risiko eingestuft wurde. Der Agent nannte als Begründung: den Wechsel zu einer Promise-basierten API, den veralteten Callback-Stil, dass Pfadtrenner zu reinen Escape-Zeichen werden, und dass die Glob-Klasse 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 Intelligenz zur Änderungsanfälligkeit, um die erforderlichen Codeänderungen vorzunehmen und so ein Upgrade mit hohem Risiko in eines mit niedrigem Risiko zu verwandeln.

Auf die Frage, woher die Begründung stammt, erklärte McMorrow, dass die Begründung zur Änderungsanfälligkeit aus der Analyse von Release Notes und Breaking Changes im gesamten Open-Source-Ökosystem hervorgeht. Designpartner berichteten von wenigen False Positives. Diese sind größtenteils ein SAST-seitiges Problem, und der Agent nutzt die vorhandenen Engines von Snyk Code, um sie herauszufiltern.

Der Mensch im Regelkreis – und anschließend der Mensch über dem Regelkreis

Jeder Weg der Demo endete in 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 genügend Vertrauen erworben hat, damit jemand seine Arbeit blind mergen kann.

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 neu hinzugekommenen Schwachstellen und gab 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 Ingenieure, berichtete McMorrow, lieben es, 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: vom Menschen im Regelkreis zum Menschen über dem Regelkreis. Der Unterschied besteht darin, wer entscheidet: Im Regelkreis bedeutet Pair Programming mit einem Agenten, während über dem Regelkreis ein Agent selbst entscheidet und weiß, wann er Sie hinzuziehen muss. Cresciones Ergänzung: Das ist das Berufsbild der Zukunft – AI Security Engineers, die in ihrem Namen einen Schwarm von Agenten orchestrieren.

Praktisch loslegen

Für den Einstieg benötigen Sie ein Snyk-Konto und entweder die CLI oder eine unterstützte ADE sowie Ihren eigenen Modell-API-Schlüssel, da Bring-your-own-LLM bei der offenen Preview der Standard ist. Open-Source-Maintainer erhalten über das Secure Developer Program, das eine vollständige Enterprise-Lizenz umfasst, kostenlos Zugriff auf die gesamte Plattform.

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 Agent zu gestalten, während Snyk die Lösung öffentlich weiterentwickelt und iteriert.