Legit Security: KI-Agent repariert nun Open-Source-Pakete

Legit Security: KI-Agent repariert nun Open-Source-Pakete

Legit Security hat seine Funktion Agentic Remediation erweitert. Sie kümmert sich jetzt auch um Schwachstellen in Open-Source-Abhängigkeiten und nicht mehr nur um Code, den ein Unternehmen selbst schreibt. Das Ziel: Entwicklungsteams sollen vom Fund einer Schwachstelle bis zur verifizierten Korrektur kommen, ohne dass jemand das Problem von Hand bewerten muss.

Bisher arbeitete der Agent mit Ergebnissen der statischen Codeanalyse in Eigencode, also Code, den die eigenen Entwickler eines Unternehmens geschrieben haben. Mit der neuen Version richtet sich derselbe Agent auf Pakete, die von außen eingebunden werden. Das Unternehmen bezeichnet diese als die zweite große Quelle von Schwachstellen in moderner Software.

Ein Mengenproblem

Legit Security stellt das Update als Antwort auf eine wachsende Lücke in der Anwendungssicherheit (AppSec) dar. KI-generierter Code beschleunigt die Auslieferung von Software, und die meisten modernen Codebasen bestehen inzwischen größtenteils aus Open-Source-Abhängigkeiten. Jedes neue Paket kann bekannte Schwachstellen mitbringen.

Der klassische AppSec-Ablauf, bei dem menschliche Teams einen Rückstau an Befunden einen nach dem anderen abarbeiten, kommt mit dieser Menge kaum hinterher. Noch schwieriger wird es, wenn der fehlerhafte Code nicht im eigenen Repository des Unternehmens liegt, sondern mehrere Ebenen tief in einem Paket eines Drittanbieters steckt.

"Die eigentliche Herausforderung ist nicht mehr, Schwachstellen zu finden - sondern schnell genug vom Fund zur Korrektur zu kommen", so das Unternehmen. KI-generierter Code habe die Menge der täglich ausgelieferten Software vervielfacht, während Angreifer zunehmend KI nutzen, um Schwachstellen schneller zu finden und auszunutzen, als Verteidiger reagieren können. Diese Sorge deckt sich mit dem breiteren Trend, dass KI die Ausnutzung von Schwachstellen beschleunigt, den Sicherheitsteams schon länger beobachten.

Fünf Schritte zum Pull Request

Bekommt der Agent eine verwundbare Abhängigkeit vorgelegt, arbeitet er eine feste Abfolge ab:

  • Identifizieren des betroffenen Pakets, seiner aktuellen Version und der Frage, ob es sich um eine direkte Abhängigkeit handelt oder um eine transitive, die über ein anderes Paket eingebunden wird.
  • Das sicherste Upgrade wählen, also den kleinstmöglichen Versionssprung, der das Problem behebt. Wo es geht, bleibt der Agent innerhalb der aktuellen Hauptversion, um inkompatible Änderungen zu vermeiden.
  • Die Korrektur anwenden, indem er die Konfiguration der Abhängigkeiten aktualisiert und die Lockfile neu erzeugt. Dabei werden auch weitere Vorkommen der verwundbaren Version an anderer Stelle im Abhängigkeitsbaum erfasst.
  • Überprüfen des Ergebnisses, indem die Abhängigkeit vor und nach der Änderung gescannt wird. Die Prüfung bestätigt, dass die Schwachstelle beseitigt ist und kein neues Problem hinzugekommen ist.
  • Einen Pull Request öffnen, der zur Prüfung bereitsteht und die Korrektur samt Details zur Schwachstelle enthält.

Da jede Korrektur vor dem Erstellen des PR erneut gescannt wird, erhalten Entwickler eine bereits geprüfte Änderung statt eines Versionsvorschlags, den sie selbst noch testen müssen.

Wenn ein Sprung in der Hauptversion nötig ist

Manche Korrekturen gibt es nur in einer neueren Hauptversion, bei der inkompatible API-Änderungen zu einem echten Risiko werden. In solchen Fällen schaltet der Agent einen KI-gestützten Analyseschritt dazwischen. Er untersucht, wie das jeweilige Repository das Paket nutzt, und schlägt die nötigen Änderungen am Quellcode vor. Diese Vorschläge werden anhand der tatsächlichen Repository- und Paketdaten validiert.

Legit Security zieht eine klare Linie zwischen den beiden Teilen einer solchen Korrektur. Das Upgrade der Abhängigkeit selbst wird wie jede andere Korrektur durch einen erneuten Scan verifiziert. Die Anpassung des Codes an den Sprung in der Hauptversion wird dagegen von der KI bewertet und nicht unabhängig überprüft. Laut Unternehmen weist der PR ausdrücklich auf diesen Unterschied hin, damit Entwickler sehen, was bestätigt ist und was vor dem Mergen genauer angeschaut werden sollte.

Unsere Einschätzung

Diese Veröffentlichung passt zu einem Muster, das wir in den vergangenen Wochen branchenweit beobachten: Anbieter bringen KI vom Aufspüren von Problemen hin zu deren tatsächlicher Behebung. Googles Gemini 4 Argon, das Schwachstellen findet und patcht, und Sophos, das KI zur Priorisierung von Korrekturen einsetzt, weisen in dieselbe Richtung.

Für Leser ist das spannendere Detail das Eingeständnis von Legit Security selbst, dass von der KI geschriebene Code-Anpassungen nicht unabhängig überprüft werden. Das deutet darauf hin, dass der menschliche Prüfschritt nicht verschwindet, gerade bei großen Upgrades. Zudem reicht das Risiko durch Abhängigkeiten weiter als nur veraltete Versionen, wie Vorfälle wie der Einbruch bei OpenInfra Europe Artifactory zeigen. Es lohnt sich zu beobachten, ob Teams diesen automatisierten PRs genug vertrauen, um sie zügig zu mergen, und wie oft die von der KI bewerteten Änderungen im Produktivbetrieb standhalten.