Als Claude Code Security in diesem Jahr vorgestellt wurde, galt das Werkzeug in vielen Beiträgen als vermeintliches Allheilmittel gegen unsicheren Code. Laut dem Autor fielen daraufhin Aktienkurse von Cybersicherheitsfirmen, und es kursierten Texte mit der Frage, ob Sicherheitsfachleute bald überflüssig würden. Unternehmen hätten dagegen vor allem die Verbesserungen und Möglichkeiten der Modelle begrüßt. In den vergangenen Wochen seien dann Vorgaben durch Unternehmen gegangen, die alle Entwickler zur Nutzung von KI-Coding-Werkzeugen verpflichten.
Das Problem sieht der Autor nicht im erzeugten Code selbst, sondern in dessen Umsetzung. Eine gebrochene Annahme über die Eingabeprüfung einer API oder ein wiederholt falsch gesetztes Berechtigungsmuster vervielfache sich, wenn unter Zeitdruck gearbeitet werde.
Bislang habe in der Unternehmenssicherheit die stillschweigende Annahme gegolten, dass Verborgenheit einen Teilschutz biete. Angreifer hätten keine Zeit auf mühsame Entdeckungen verschwendet: Es habe Tage zäher Aufklärung gekostet, das Ökosystem aus Drittanbietern zu kartieren – etwa welcher regionale SaaS-Anbieter Compliance abwickelt, welches interne Werkzeug Lesezugriff auf die Produktion hat oder welche Open-Source-Bibliothek sechs Ebenen tief im Abhängigkeitsbaum steckt. Diese Reibung habe wie eine zufällige Versicherung gewirkt. Anthropics Project Glasswing entferne diese Hürde.
Modelle wie Mythos bräuchten kein kreatives Genie, sondern lediglich Reichweite – und die hätten sie. Ein Agent könne einem Vertrauensgraphen systematisch folgen, ohne zu ermüden oder sich ablenken zu lassen. Der langweilige Pfad über einen vergessenen Zulieferer werde dadurch hochgradig ausnutzbar, gerade weil ihn niemand beobachte. Angreifer bräuchten keinen Zero-Day, wenn ein Agent das Drittanbieter-Ökosystem kartiert, einen Anbieter mit bekannt verwundbarer Framework-Version identifiziert, den Vertrauenspfad bis zur Produktion auflöst und alles miteinander verkettet.
Aus der Kombination von massenhaft neuem, schlecht implementiertem Code und Agenten, die obskurste Schwachstellen finden und verketten, folgert der Autor ein Umdenken. Bisher hätten sich Organisationen darauf konzentriert, ihre kritischsten Anwendungen abzusichern, während Alt-Integrationen und Zulieferer-Werkzeuge im Hintergrund still breiten Zugriff behielten. Das sei nicht länger haltbar.
Sicherheitsteams würden mehr denn je von Schwachstellenmeldungen überrollt – mit demselben Grundproblem der Priorisierung, nur verhundertfacht. Wer jede gemeldete Schwachstelle an die Entwicklung weiterreiche, verliere an Glaubwürdigkeit, wenn alles dringend erscheine.
Der Rat des Autors: zuerst auf das konzentrieren, worüber man sich am meisten Sorgen mache. Eine kritische Schwachstelle in einem System ohne personenbezogene Daten (PII) oder privilegierten Zugriff sei weniger wichtig als eine Kombination geringfügiger Schwachstellen mit tatsächlich hoher geschäftlicher Auswirkung. Erkannte wiederkehrende Muster könnten zudem in die KI-Coding-Werkzeuge zurückgespielt werden, sodass Entwickler im Moment der Implementierung auf ein häufiges Problem hingewiesen werden.
Zur Risikobestimmung nennt der Autor drei Punkte: transitive Abhängigkeiten, Datenflüsse, Berechtigungen und deren wiederkehrende Muster verfolgen; beim Patchen die Ursachen nach dem Risiko des Vertrauenspfads statt nach dem Ansehen eines Assets priorisieren; und das Beheben von Schwachstellenmustern verstärken, bis die eingesetzten KI-Werkzeuge aus jedem Fehler lernen.