Noma Labs hat gezeigt, dass ein einzelnes öffentliches GitHub-Issue mithilfe einer KI-gesteuerten Automatisierung Code aus privaten Repositories stehlen kann. Ihr Proof-of-Concept ermöglicht es einem Angreifer, die eigenen Workflow-Bots einer Organisation gegen sie selbst zu verwenden und proprietäre Dateien preiszugeben, ohne die Authentifizierung von GitHub zu umgehen.

Der Angriff vor aller Augen

Die Ereigniskette ist einfach genug, um sie zu reproduzieren:

  • Ein Angreifer erstellt ein Issue in einem öffentlichen Repository, das für jeden einsehbar ist.
  • Ein KI-Agent, der in die Continuous-Integration-Pipeline eingebunden ist, liest den Titel und den Inhalt des Issues.
  • Derselbe Agent verfügt bereits über Leseberechtigungen für andere private Repositories innerhalb der Organisation.
  • Versteckte Anweisungen im öffentlichen Issue sagen dem Agenten, welche privaten Dateien er abrufen soll.
  • Der Agent postet die abgerufenen Dateien als Kommentar zurück in das öffentliche Issue und macht sie damit für die ganze Welt zugänglich.

Alles geschieht in einem einzigen Durchlauf der Automatisierung. Kein Diebstahl von Anmeldedaten, kein Leak von API-Schlüsseln, keine GitHub-Schwachstelle. Der Angreifer nutzt schlicht das Vertrauen aus, das die Organisation ihren eigenen Bots entgegenbringt.

Warum das jetzt wichtig ist

KI-gesteuerte Agenten fungieren heute als Bindeglied moderner Entwicklungspipelines. Sie eröffnen Pull-Requests, führen Tests aus, deployen Builds und triagieren Bugs – allesamt ausgelöst durch leichtgewichtige Signale wie Issue-Kommentare. Wenn diese Agenten über weitreichende Repository-Zugriffe verfügen, verschwimmt die Grenze zwischen vertrauenswürdigen Daten und nicht vertrauenswürdigen Benutzereingaben.

Wenn ein Agent im selben Ausführungsschritt privaten Code lesen und öffentlich schreiben kann, bricht das Zugriffskontrollmodell der Organisation zusammen.

Der eigentliche Fehler: Berechtigungen, nicht das Modell

Die Demonstration belastet nicht das zugrunde liegende KI-Modell. Das Modell befolgt lediglich die Anweisungen, die es erhält. Die Schwachstelle liegt in dem Berechtigungssatz, der der Automatisierung gewährt wurde:

  • Lesezugriff auf private Repositories in der gesamten Organisation.
  • Schreibzugriff auf öffentliche Issue-Threads.
  • Trigger durch öffentlichen Text, den jeder erstellen kann.

Lösungen, die nichts kosten, aber funktionieren

Die Anwendung des Prinzips der geringsten Berechtigung (Principle of Least Privilege) reduziert den Angriffspfad erheblich:

  • Den Bot einschränken (Scope) auf das Repository, in dem er benötigt wird. Wenn er nur in einem bestimmten Repo agieren muss, verweigern Sie ihm alle anderen Leserechte.
  • Lese- und Schreib-Token trennen. Verwenden Sie eine Anmeldedatei zum Abrufen von Code und eine andere, streng kontrollierte Anmeldedatei zum Posten von Kommentaren.
  • Menschliche Freigabe vor jedem öffentlichen Posten. Ein leichtgewichtiger Review-Schritt – wie etwa ein erforderliches Approval-Label – fügt einen Kontrollpunkt hinzu, ohne die Pipeline zu stoppen.
  • Reduzierung des Schadensradius (Blast Radius). Gestalten Sie Workflows so, dass sich ein Fehler oder Missbrauch höchstens auf ein Repository auswirkt, nicht auf die gesamte Organisation.

Gegenargument: operativer Aufwand

Worauf man als Nächstes achten sollte

Fazit: Wenn eine KI-Automatisierung sowohl privaten Code sehen als auch öffentlich kommunizieren kann, ist das System falsch konzipiert. Verschärfen Sie die Berechtigungen, führen Sie menschliche Kontrollen ein und halten Sie den Schadensradius klein – andernfalls kann ein einzelnes öffentliches Issue zu einem Vektor für Datenlecks werden.