JFrog-CISO: KI verändert den Schwachstellen-Rückstau, statt ihn nur zu vergrößern

Ein Blogbeitrag von JFrog argumentiert, dass KI die Form des Schwachstellen-Rückstaus verändert hat: Er ist länger, wächst schneller, als Release-Zyklen es verkraften, und das bewährte Patchen nach Schweregrad funktioniert nicht mehr. Der Autor schreibt aus Sicht eines CISO und sagt, Unternehmen benötigten laufend aktuelles Wissen über ihre Software-Artefakte.
- Laut Cloud Security Alliance committen KI-gestützte Entwickler drei- bis viermal schneller, führen aber Sicherheitsbefunde mit der zehnfachen Rate ein.
- Die Zahl veröffentlichter Schwachstellen stieg 2025 laut JFrog-Beitrag um 92 Prozent.
- Der Beitrag hält die Priorisierung nach Schweregrad für überholt, weil KI-Agenten niedrige und mittlere Lücken zu schweren Exploits verketten.
- Unit 42 berichtet, dass Angreifer binnen fünfzehn Minuten nach Veröffentlichung nach neuen CVEs scannen.
- JFrog bringt ein einziges System of Record für Artefakte, Herkunftsnachweise und Richtlinien als Kontrollpunkt für KI-geschriebenen Code ins Spiel.
Ein Rückstau, der schneller wächst als die Release-Zyklen
Der Beitrag beginnt mit Zahlen aus externen Quellen, um den Druck auf Sicherheitsteams zu beschreiben. Die Cloud Security Alliance berichtet, dass KI-gestützte Entwickler Code-Commits drei- bis viermal schneller erzeugen als ihre Kollegen, dabei aber Sicherheitsbefunde mit der zehnfachen Rate einführen. Das schaffe, so der Beitrag, Sicherheitsschulden, die schneller wachsen, als sie abgebaut werden können.
Der Vibe Security Radar der Georgia Tech erfasste allein in einem Monat 35 CVEs, die direkt auf KI-Coding-Tools zurückgehen. Forscher schätzen, dass die tatsächliche Zahl in Open-Source-Paketen fünf- bis zehnmal höher liegt. Die britische NCSC warnte in diesem Frühjahr vor einer "Patch-Welle" und führte sie darauf zurück, dass über Jahre schnelle Auslieferung Vorrang vor dem Abbau von Schwachstellenschulden hatte. Dem Beitrag zufolge stieg die Zahl veröffentlichter Schwachstellen 2025 um 92 Prozent, noch vor der jüngsten Beschleunigung.
Priorisierung nach Schweregrad reicht nicht mehr
Die qualitative Veränderung hält der Autor für die bedeutsamere. Zwei Jahrzehnte lang haben Teams kritische Lücken sofort gepatcht, hohe eingeplant und mittlere sowie niedrige warten lassen. Der Beitrag nennt diesen Ansatz überholt.
Die April-Empfehlung des Australian Cyber Security Center zu Frontier-Modellen riet Organisationen, ihre Risikotoleranz neu zu bewerten und Schwachstellen unabhängig vom Schweregrad zu patchen. Hintergrund sind verkettete Schwachstellen, bei denen niedriger eingestufte Lücken sich zu einer ernsteren Bedrohung verbinden. Neue KI-Agenten seien darin besonders gut, heißt es im Beitrag. Sein Beispiel: Eine Informationslücke mittleren Schweregrads und eine Path-Traversal-Lücke niedrigen Schweregrads, beide bislang zurückgestellt, lassen sich nun gemeinsam ausnutzen.
Auch das Reaktionsfenster ist kleiner geworden. Unit 42 berichtet, dass Angreifer binnen fünfzehn Minuten nach Veröffentlichung nach neuen CVEs scannen. Eine kritische Pre-Auth-RCE im Notebook-Projekt Marimo wurde innerhalb von zehn Stunden nach Bekanntgabe ausgenutzt, allein auf Grundlage des Advisory-Textes.
Für Softwarehersteller gelte: Mittlere und niedrige Probleme gelangen zu den Kunden und werden von deren Scannern markiert. Sie können Support-Tickets, Sicherheitswarnungen oder vertragliche Behebungspflichten auslösen. Kunden könnten zwar nach Schweregrad filtern, doch wegen Null-Toleranz-Richtlinien täten sie das selten. Entwicklungsteams müssten daher das gesamte Spektrum an Schwachstellen beheben, ohne dass mehr Ressourcen zur Verfügung stehen.
Die Lage der CISOs und die Lehre aus SolarWinds
Laut Proofpoints Voice of the CISO 2026 sollen 79 Prozent der CISOs KI-Risiken ohne zusätzliche Ressourcen managen, wie der Beitrag ausführt. Anschließend schildert der Autor ein Gespräch auf der diesjährigen Konferenz swampUP mit Tim Brown, der während des SUNBURST-Angriffs CISO von SolarWinds war.
Verursacht wurde der Angriff durch 3.000 Zeilen Schadcode, die unter Umgehung der Quellcodeverwaltung in die Build-Umgebung eingeschleust wurden. Zur Reaktion gehörte ein Umbau der Pipeline mit drei getrennten Builds für Entwicklung, Staging und Produktion. Der Zugriff wurde von 400 auf 36 und dann auf 2 Personen reduziert, binäre Vergleiche zwischen den Builds sollten Manipulationen erkennen, und neue Funktionen wurden sechs Monate lang pausiert. Die SEC erwog, Brown persönlich anzuklagen. Der Beitrag sagt, das Verfahren sei nach drei Jahren eingestellt worden, und der Stress habe zu einem Herzinfarkt geführt.
Der Autor zieht daraus eine Lehre über fehlplatziertes Vertrauen: die Annahme, Code sei sicher oder Systeme seien korrekt konfiguriert, ohne dies zu überprüfen. Kontrollen, die früher in einem Prüfzyklus von sechs Monaten liefen, müssten nun kontinuierlich laufen. Im Zeitalter agentischer KI gingen Bedrohungen sowohl von autonomen Agenten als auch von abtrünnigen Mitarbeitern aus, was das Management nicht-menschlicher Identitäten und die Sandbox-Isolierung von Agenten unverzichtbar mache.
Was der Beitrag empfiehlt und wie JFrog sich positioniert
Die zentrale Fähigkeit sei laut Beitrag das präzise und kontinuierliche Wissen über Software-Artefakte, ihren Einsatz und ihre Verantwortlichen sowie ein Reaktionsplan für den Fall einer Kompromittierung. Ohne dieses Wissen, so der Autor, ließen sich regulatorische Fristen nicht einhalten. Dazu zählen die 24-Stunden-Frühwarnung nach dem EU Cyber Resilience Act und die 72-Stunden-Meldung an die ENISA bei aktiv ausgenutzten Schwachstellen in Produkten, die in der EU verkauft werden.
Nur der CISO stehe an der Schnittstelle von Geschäftsleitung, Entwicklung und Kunden und könne daher für einen einheitlichen Plan eintreten, sagt der Autor, die Verantwortung werde aber geteilt. Brown betonte Kommunikation und Zusammenarbeit.
Auf der Produktseite erklärt JFrog, man baue nicht noch einen Scanner, der Probleme erst im Nachhinein meldet. Beschrieben wird eine Plattform, in der Artefakte, Herkunftsnachweise, Governance, Abhängigkeiten, Richtlinien und Release-Pfade in einem zentralen System of Record liegen. Wenn Agenten Code schreiben, prüfen und ausliefern, müsse die Plattform laut Beitrag der Kontrollpunkt sein. Das bedeute, nicht-menschliche Entitäten zu verwalten, überprüfbare Herkunft sicherzustellen, Richtlinien in Pipeline-Geschwindigkeit durchzusetzen und ein unveränderliches Build-Protokoll zu führen. Das Unternehmen behauptet, dieser Ansatz erlaube es Teams, schneller auszuliefern und dabei Standards einzuhalten, die sie gegenüber Aufsichtsbehörden, Kunden und Vorstand vorweisen können.
JFrog: The Year the Vulnerability Backlog Changed Shape


