Docker: Ein KI-Code-Reviewer mit reinem Lesezugriff erfindet eine CVE und einen Angriff

Ein vorsichtiger Aufbau und eine langweilige Änderung

Die Geschichte, die Pratik Kumar Singh im Rahmen von Dockers Wettbewerb Agent Hall of Shame geteilt hat, handelt von einem Platform Engineer, der für sein Team einen Code-Review-Bot gebaut hat. Sobald jemand Code pusht, liest der Bot die Änderungen und schreibt ein Review in die Pipeline, ähnlich wie es ein menschlicher Kollege bei einer ersten Durchsicht tun würde.

Laut Docker war der Aufbau bewusst vorsichtig gewählt. BuaJi läuft mit lokalen Modellen über Ollama, die Modellgewichte liegen also auf der eigenen Hardware des Engineers, und keine Anfrage geht an einen KI-Anbieter. Der Bot läuft als Job in seiner CI-Pipeline, die gesamte Lösung ist damit selbst gehostet, und der Quellcode des Unternehmens verlässt nie das Haus.

Außerdem gab er dem Bot eine feste Regel mit: Er darf lesen und kommentieren, mehr nicht. Er kann weder terraform apply noch kubectl apply ausführen und auch keinen Commit pushen.

Die Änderung, die den Vorfall auslöste, war ein Versionssprung einer mitgelieferten PostgreSQL-Kopie von 16.11 auf 16.13. Docker beschreibt sie als so langweilig und verantwortungsvoll, wie eine Codeänderung nur sein kann, denn ihr einziger Zweck besteht darin, öffentlich bekannte Sicherheitslücken zu schließen.

Was BuaJi schrieb

Der Bot antwortete mit rund 1.500 Wörtern, in denen er die Änderung ablehnte. Ein normaler Review-Kommentar umfasst laut Docker ein bis zwei Sätze. Dem Bericht zufolge enthielt der Text Folgendes:

• Er bezeichnete das Versionsupdate als „architektonische Übernahme“.
• Er behauptete, der neue PostgreSQL-Build diene dazu, interne Daten an ein Drittunternehmen zu schicken, das er beim Namen nannte, obwohl es dieses Unternehmen nicht gibt.
• Er verwies namentlich auf Kubernetes-Ressourcen, die nie existierten, obwohl BuaJi keinen Zugriff auf den Cluster hatte.
• Er schrieb Go-Skripte, um „die infizierten PostgreSQL-Knoten zu isolieren“, obwohl nichts infiziert war.
• Er forderte den Engineer auf, sofort sämtliche IAM-Zugriffe zu widerrufen, was die gesamte Organisation ausgesperrt hätte.

Die Argumentation stützte sich auf eine CVE-Nummer, die von niemandem je vergeben wurde. Docker weist darauf hin, dass sich eine CVE-Kennung zu den am leichtesten überprüfbaren Dingen in der Sicherheitswelt zählt, weil man sie in Sekunden in einem öffentlichen Register nachschlagen kann. Der Bericht wirkte trotzdem überzeugend: sauberes Markdown, YAML, das sich hätte parsen lassen, und ein dringlicher, selbstsicherer Ton. Der Engineer brauchte etwa zwei Minuten, um die CI-Logs zu lesen, stellte fest, dass nichts davon stimmte, und ging zur Tagesordnung über.

Warum reiner Lesezugriff nicht genügte

Docker betont, dass die Nur-Lese-Regel wie vorgesehen funktioniert hat. BuaJi konnte seine eigenen Empfehlungen nicht umsetzen, und der Vorfall kostete den Engineer zwei Minuten. Die Lücke liegt laut Docker darin, dass die Regel kontrolliert, was der Bot tun kann, nicht aber, was er sagen kann. Die Person, die den Output liest, hat meist genau den Zugriff, der dem Agenten verwehrt wurde. Der Bot konnte also Skripte schreiben und sie jemandem übergeben, der sie ausführen kann.

Docker skizziert ein Szenario: Ein jüngerer Engineer hat nachts um zwei Bereitschaft, ist halb wach und steht vor einem langen, alarmierenden Bericht. Alle IAM-Zugriffe in der Produktion zu widerrufen wäre für sich genommen ein Ausfall, und ein ungeprüftes Go-Skript auf Datenbankknoten auszuführen könnte noch schlimmer sein. In diesem Fall hätte die Person den Schaden in bester Absicht angerichtet. Kein Berechtigungsmodell würde dabei anschlagen, so Docker, weil keine Berechtigung verletzt wurde. Falsch war allein der Inhalt des Berichts.

Was Docker Sandboxes ändern und was nicht

Docker benennt die Grenzen offen: Eine Sandbox ist kein Faktenchecker, und keine MicroVM-Grenze macht einen Review-Kommentar korrekt. Eine solche Grenze ändert aber, was erfundener Output anrichten kann, sobald er existiert.

In der Geschichte lebte die Nur-Lese-Regel in einer Konvention, die ein einzelner Engineer in seiner eigenen Pipeline konfiguriert hatte. Solche Regeln können laut Docker aufweichen, wenn jemand in Eile ist, ein Kollege eine Konfiguration kopiert und einen Abschnitt weglässt oder eine vorübergehende Ausnahme zum Dauerzustand wird.

Docker Sandboxes führen Agenten in isolierten MicroVMs aus, jede mit eigenem Kernel, eigenem Dateisystem und einem Netzwerk, das standardmäßig alles blockiert. Laut Docker kann ein Agent darin alles Mögliche erfinden, doch die Erfindung hat keinen Ort, an den sie gelangen könnte, sofern der Zugriff nicht vorab erlaubt wurde. Die Nur-Lese-Regel wird so zu einer Eigenschaft der Umgebung statt zu etwas, das sich ein Mensch merken muss, und das Policy-Log kann belegen, dass ein Bericht, der behauptet, einen Cluster untersucht zu haben, dazu nie in der Lage war.

Das schützt vor dem Agenten, so Docker, nicht aber vor dem Menschen, der den Output liest. Dafür empfiehlt Docker, die Review-Ausgabe eines Agenten wie eine Eingabe des Agenten zu behandeln: als nicht vertrauenswürdig, bis etwas sie überprüft.