Remediation Agents einfach erklärt: Warum Beheben wichtiger ist als Finden

Sechs neue Sicherheitsprobleme für jedes eine behobene Problem. Dieses Verhältnis hat die Snyk-Forschung ermittelt. Deshalb widmete die AI Security Engineers Community eine Stunde ihres Livestreams dem Beheben statt dem Finden.

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

Bei Remediation Agents einfach erklärt traf ein Kamingespräch auf eine Live-Demo. Gérald Crescione, Leiter der globalen AI Security Engineers Community, moderierte das Gespräch mit Ryan McMorrow, der bei Snyk die Remediation-Produkte verantwortet, und Brendan Hann, Senior Product Marketing Manager für Snyks Developer Experience und die Agentic AppSec-Lösung.

Der Remediation Agent, der sich derzeit in der öffentlichen Vorschau befindet, ist Snyks Antwort auf die wachsende Zahl von Problemen. Während das Team das Produkt weiterentwickelt und öffentlich iteriert, stellt Snyk allen aktuellen Snyk-Kunden den Remediation Agent ohne zusätzliche Kosten zur Verfügung – im Gegenzug für umsetzbares Feedback aus der Community. Dieses Feedback können Sie im Subreddit der Community teilen.

Warum die Behebungsrate stagnierte

Die Coding-Agents, die Entwickler heute überall einsetzen, optimieren auf funktionierenden Code, nicht auf sicheren, funktionierenden Code. Deshalb steigt die Zahl der Probleme, 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 – führen Sie also ein Upgrade durch. So weit, so gut. Aber irgendjemand muss weiterhin nachweisen, dass das Upgrade nichts beschädigt hat. Kein Tool übernahm das für die Entwickler. Wenn der Sprung drei oder vier Hauptversionen umfasste, fehlte den meisten Teams das Vertrauen, die Änderungen überhaupt zusammenzuführen.

Hann ordnete diesen Engpass in einen umfassenderen Wandel ein. KI hat drei verschiedene, aber miteinander verbundene Herausforderungen geschaffen: Angriffe werden inzwischen automatisiert mit KI ausgeführt; Agents schreiben Software schneller als je zuvor und führen ebenso schnell Schwachstellen ein; und KI hält Einzug in Produktionsumgebungen, oft ohne Governance. Die Behebung war schon immer ein Engpass, argumentierte er. Doch heute ist sie noch wichtiger, weil sich auch die Angriffswerkzeuge verändert haben. Frontier-Modelle entkommen Sandboxes und verknüpfen bislang als unkritisch eingestufte Findings mit niedriger Schwere 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. Hanns Worten zufolge stattet sie Teams mit einer Gruppe von Agents aus, die ihr AppSec-Programm tatsächlich für sie betreiben kann.

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

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

Das Modell zeigte sich äußerst enthusiastisch, lag aber nur gelegentlich richtig. Entwickler mussten weiterhin jede Änderung prüfen und die meisten davon ablehnen. Das kostete ungefähr so viel Zeit wie die Probleme von Hand zu beheben. Ein größeres Modell hätte lediglich mehr davon produziert.

Der Durchbruch kam, als das Team eine andere Frage stellte: Was wäre, wenn das LLM alles wüsste, was Snyk weiß? Zehn Jahre Best Practices in der Anwendungssicherheit, Upgrade-Wissen für einzelne Ökosysteme und wertvolle Erfahrung damit, welche Fixes zusammengeführt werden – und welche nicht.

So entstand der Remediation Agent, den McMorrow als eine Harness- oder Orchestrierungsschicht beschrieb. Sie sitzt zwischen dem Modell der Wahl des Entwicklers und einer abrufbaren Intelligence-Schicht, die alle von Snyk erfassten Probleme und CVEs abdeckt. Bei Bedarf kann der Agent Folgendes abrufen:

• Breakability-Bewertungen für Open-Source-Upgrades. Sie bewerten anhand einer Datenbank aller Paketversionen und ihrer Breaking Changes, wie wahrscheinlich es ist, dass ein Upgrade Ihren Build beeinträchtigt.

• Paketstatus und Reachability-Scores, einschließlich der Information, ob der anfällige Code in der Produktionsumgebung ausnutzbar ist.

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

• Playbooks für einzelne Ökosysteme, verfasst von Snyks eigenen Security Engineers. Sie beschreiben, wie erfahrene Praktiker eine transitive Abhängigkeit aktualisieren oder eine bestimmte Klasse von SAST-Findings beheben würden.

McMorrow verglich es damit, dass das LLM eine Prüfung mit erlaubten Hilfsmitteln ablegt und Snyk ihm das Buch dazu gibt. Anschließend benotet Snyk die Arbeit des Agents: Es führt Scans erneut aus, um zu bestätigen, dass das Problem tatsächlich behoben ist, und lässt alle Unit-Tests im Projekt durchlaufen, um sicherzustellen, dass die Änderungen den Build nicht beschädigt haben.

Die von ihm präsentierten internen Ergebnisse: 94 % mehr mergefähige SCA-Fixes und 13 % mehr mergefähige SAST-Fixes. Inzwischen werden die meisten intern generierten SAST-Fixes unverändert zusammengeführt – und das bei deutlich geringeren Token-Kosten als mit dem naiven Ansatz.

Hann ergänzte die drei Einsatzmuster, mit denen Snyks Design-Partner die größten Erfolge erzielt haben:

1. Kampagnen zum Abbau des Rückstands, bei denen niedrig eingestufte und informative Findings behoben werden, die Angreifer inzwischen miteinander verknüpfen

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

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 Agent live am OWASP Juice Shop vor und zeigte beide Einstiegsmöglichkeiten.

1. Der IDE-Weg

Für den IDE-Weg benötigen Sie zwei Komponenten: einen /snyk-fix-Skill und den Snyk Studio MCP-Server. Beide lassen sich mit einem einzigen curl-Befehl aus Snyks Recipes-Repository installieren. Damit steht Ihnen der gesamte Workflow direkt in Cursor, Windsurf, Antigravity oder VS Code mit einem Claude-Plugin zur Verfügung – von SAST- und SCA-Scans über die Intelligence-Abfrage, Codeänderungen, erneute Scans und Testläufe bis hin zu Bericht und Pull Request. Bei der Vorführung aktualisierte der Agent eine anfällige multer-Abhängigkeit über eine Hauptversion hinweg, bestätigte, dass keine Breaking Changes an der API die Nutzung des App-Speichers auf dem Datenträger beeinträchtigten, und aktualisierte die Lock-Datei.

2. Der CLI-Weg

In der CLI ist snyk fix --agentic --experimental --sca interaktiver. Der Befehl listet alle Pakete auf, die aktualisiert werden können, samt aktueller Version, der von Snyk empfohlenen Zielversion – die möglichst viele kritische und schwerwiegende Probleme behebt – und einem Breakability-Score. Entwickler können:

• Alle Probleme beheben

• Nur die Elemente mit geringer Breakability beheben

• Bestimmte Findings auswählen

• Mit dem Agent sprechen

McMorrow demonstrierte die letzte Option, indem er fragte, warum ein Sprung auf eine neue Hauptversion von Glob als hohes Risiko eingestuft wurde. Der Agent erläuterte die Gründe: Der Wechsel zu einer Promise-basierten API, der veraltete Callback-Stil, Pfadtrennzeichen, die nur noch als Escape-Zeichen dienen, und die Tatsache, dass die Klasse Glob kein Event Emitter mehr ist. Außerdem listete er die transitiven Schwachstellen auf, die das Upgrade beheben würde. Die neueste Version nutzt anschließend dieselben Breakability-Informationen, um die erforderlichen Codeänderungen vorzunehmen und so aus einem Upgrade mit hohem Risiko eines mit geringem Risiko zu machen.

Auf die Frage, woher die Begründung stammt, erklärte McMorrow, dass die Breakability-Analyse auf einer Untersuchung von Release Notes und Breaking Changes im gesamten Open-Source-Ökosystem beruht. Design-Partner berichten von wenigen False Positives. Diese betreffen vor allem SAST; der Agent filtert sie mithilfe der bestehenden Engines von Snyk Code heraus.

Erst Mensch im Prozess, dann Mensch in der Kontrollschleife

Jeder Workflow in der Demo endete mit einem Pull Request. „Wir nehmen keine verrückten Codeänderungen vor“, sagte Hann. Bis ein Agent genügend Vertrauen erworben hat, um seine Arbeit ohne Bedenken direkt zusammenzuführen, behält der Entwickler das letzte Wort.

Snyks eigene Teams nutzen den Agent heute über die CLI. Eine autonome Variante befindet sich in aktiver Entwicklung: Snyk startet eine Sandbox, installiert den Agent, lädt den Anwendungscode und liefert einen fertigen PR zurück. Früher brach Snyks CI-Pipeline bei neu auftretenden Schwachstellen ab und überließ das Problem dem Entwickler. Jetzt generiert sie stattdessen die Fixes, und Sie führen die Arbeit des Agents zusammen mit Ihrem eigenen Commit zusammen. Ingenieure, berichtete McMorrow, sind froh, nicht mehr selbst eingreifen zu müssen.

Hann bezeichnete „Backlog Zero“ als realistisches Ziel und verwies darauf, dass sich bösartige Pakete und Slopsquatting sowohl auf Entwicklergeräten als auch auf Organisationsebene blockieren lassen. McMorrow zufolge geht es langfristig um Kontrolle, Governance und Vertrauen: um den Wechsel vom Menschen im Prozess zum Menschen in der Kontrollschleife. Der Unterschied liegt darin, wer entscheidet: Im Prozess bedeutet Pair-Programming mit einem Agent, in der Kontrollschleife hingegen entscheidet ein Agent selbst und weiß, wann er Sie hinzuziehen muss. Cresciones Ergänzung: Daraus entsteht ein neues Berufsbild – AI Security Engineers, die im Auftrag ihres Unternehmens eine ganze Flotte von Agents orchestrieren.

Selbst ausprobieren

Für den Einstieg benötigen Sie ein Snyk-Konto, entweder die CLI oder eine unterstützte ADE sowie Ihren eigenen Modell-API-Schlüssel, denn bei der offenen Vorschau gilt standardmäßig Bring Your Own LLM. Open-Source-Maintainer erhalten über das Secure Developer Program die gesamte Plattform kostenlos – einschließlich einer vollständigen Enterprise-Lizenz.

Einen Fix gefunden, der nicht ganz passt? Teilen Sie uns das unter r/AISecEng mit. Ihr Feedback hilft dabei, die nächste Entwicklungsphase des Remediation Agents mitzugestalten, während Snyk das Produkt weiterentwickelt und öffentlich iteriert.