13.000 interne Screenshots landeten auf öffentlichem GitHub – und kein Angreifer hat sie dort abgelegt

Sicherheitsforscher haben mehr als 13.000 interne Screenshots von über 300 Organisationen in öffentlichen GitHub-Repositories entdeckt. Die Screenshots wurden nicht gestohlen. Sie wurden von den Coding-Agenten veröffentlicht, die die Organisationen nutzten, und zwar während der normalen Arbeit.

Der Befund, über den das Sicherheitsunternehmen Glow berichtet, ist eines der lehrreicheren Leaks seit Längerem, weil die üblichen Annahmen nicht zutreffen. Es gab keinen Einbruch, keine kompromittierten Zugangsdaten und keinen böswilligen Insider. Ein automatisiertes Tool tat, was ihm gesagt wurde, und zu dem, was ihm gesagt wurde, gehörte offenbar auch das Committen von Dateien, die das Haus niemals hätten verlassen dürfen.

Wie ein Screenshot in einem öffentlichen Repository landet

Coding-Agenten machen aus vernünftigen Gründen Screenshots. Wenn ein Agent prüfen soll, ob eine Änderung an der Benutzeroberfläche funktioniert hat, öffnet er einen Browser, lädt die Seite, erstellt ein Bild und vergleicht es mit dem erwarteten Ergebnis. Dieses Bild ist ein Beweis. Viele Agenten speichern es im Arbeitsverzeichnis, damit der Schritt später überprüft werden kann.

Von dort ist der Weg zu einem öffentlichen Repository kurz. Wenn das Arbeitsverzeichnis des Agenten der Projektordner ist und der Projektordner ein Git-Repository ist, dann ist ein auf die Festplatte geschriebener Screenshot nur ein `git add` davon entfernt, committet zu werden. Wenn der Agent im Rahmen seines normalen Workflows committet und pusht und nichts die neuen Dateien filtert, landen die Screenshots auf dem Remote, auf das das Repository zeigt.

Und nun wiederhole man das über Tausende Läufe hinweg, in Hunderten Organisationen, über Monate. Niemand hat entschieden, interne Screenshots zu veröffentlichen. Das Standardverhalten der eingesetzten Tools war dafür verantwortlich, und kein Schritt in der Kette prüfte.

Warum das kein kleiner Fehler ist

Ein interner Screenshot ist oft verräterischer, als man denkt. Er kann ein Dashboard mit Kundennamen zeigen, ein Admin-Panel mit Preisangaben, eine Staging-Umgebung, einen Bug-Tracker oder ein Chat-Fenster in der Bildschirmecke. Er kann den Zustand eines Produkts zeigen, das noch nicht auf den Markt gekommen ist. In der Summe sind 13.000 Bilder von 300 Organisationen eine Landkarte dessen, woran diese Unternehmen gearbeitet haben.

Die Bilder bleiben zudem bestehen. Ein in ein öffentliches Repository gepushter Commit bleibt in der Historie, selbst nachdem die Datei aus der aktuellen Version gelöscht wurde, es sei denn, die Historie wird umgeschrieben. Die Offenlegung wird also nicht durch einen späteren Bereinigungs-Commit behoben, und genau das wäre der Schritt, zu dem die meisten Teams zuerst greifen würden.

Warum Agenten das verschlimmern

Ein menschlicher Entwickler, der einen Screenshot für einen Pull Request erstellt, schaut ihn sich normalerweise an, bevor er ihn anhängt. Das Bild ist direkt da, und die Person entscheidet, ob es sicher geteilt werden kann. Dieser Moment der Beurteilung ist der Filter, und er funktioniert die meiste Zeit.

Ein Agent hat einen solchen Moment nicht. Er ist darauf optimiert, die Aufgabe abzuschließen, und das Speichern eines Artefakts gehört zum Abschließen der Aufgabe. Nichts im Ablauf fragt, ob das Artefakt sensibel ist, weil nichts im Ablauf in der Lage ist, das zu wissen. Der Agent ist nicht im menschlichen Sinne unachtsam. Er tut genau das, was die Anweisungen gesagt haben.

Das ist dieselbe Lektion, die in mehreren Bereichen des Agenten-Designs auftaucht. Berechtigungen, die für eine Person, die Befehle eintippt, in Ordnung waren, sind für ein System nicht in Ordnung, das mit Maschinengeschwindigkeit agiert und nie müde wird. Ein Mensch, der einmal pro Woche einen Screenshot committet, ist ein Versehen. Ein Agent, der das bei jedem Lauf in einer ganzen Flotte tut, ist das Ergebnis einer Richtlinie.

Wie die Lösung aussieht

Die Kontrollen, die das verhindert hätten, sind nicht exotisch. Ein Eintrag in `.gitignore` für Screenshot-Verzeichnisse ist die einfachste, und sie funktioniert nur, wenn jemand ihn schreibt, bevor der Agent läuft. Ein Pre-Commit-Hook, der in bestimmten Pfaden nach Bilddateien sucht, fängt ab, was die Ignore-Datei übersieht. Wenn Agenten ein Scratch-Verzeichnis außerhalb des Repositorys für temporäre Artefakte erhalten, wird das Problem an der Wurzel behoben.

Warum die Zahlen weiter steigen

Die Zahl von 13.000 Bildern aus 300 Organisationen ist keine feste Größe. Sie ist eine Momentaufnahme der Repositories, die zum Zeitpunkt des Scans öffentlich waren, und die Zahl wird steigen, je mehr Teams Agenten einsetzen und je mehr Repositories gepusht werden. Die Forscher haben öffentliche Repositories gescannt, was bedeutet, dass die wahre Gesamtzahl – einschließlich privater Repositories, in denen derselbe Fehler passiert ist – von außen nicht feststellbar ist.

Die betroffenen Organisationen sind nicht alle klein. Der Befund nennt mehr als 300 von ihnen, was von Start-ups bis zu größeren Unternehmen reicht, die dieselben Agenten-Tools verwenden. Das liegt in der Natur eines Standardverhaltensproblems: Es macht keinen Unterschied bei der Unternehmensgröße, weil jedes Unternehmen, das das Tool verwendet, dieselbe Standardeinstellung erbt.

Was der Bericht nicht sagt

Der Befund behauptet nicht, dass eines der offengelegten Bilder böswillig verwendet wurde, und es gibt keine Beweise dafür, dass jemand außerhalb der Projekte sie durchgesehen hat. Der Schaden ist potenziell und nicht bewiesen: Das Material war öffentlich, und jeder hätte es ansehen können. Wo in verwandten Fällen ein Schaden nachgewiesen wurde – etwa bei Zugangsdaten, die in eine öffentliche Datei geschrieben wurden –, ist der Schaden unmittelbar.

Er sagt auch nicht, wie viele der Bilder in irgendeiner bedeutsamen Weise sensibel waren. Einige sind mit Sicherheit Screenshots einer leeren Testseite. Aber ein Leak wird nach dem schlimmsten Element darin beurteilt, nicht nach dem Durchschnitt, und 13.000 Bilder aus 300 Organisationen bedeuten, dass das schlimmste Element wahrscheinlich wirklich verräterisch ist.

Das Muster dahinter

Glows Befund ist Teil einer Gruppe ähnlicher Berichte. Forscher haben gezeigt, dass Coding-Agenten auf Softwarepakete verweisen, die nicht existieren, was Angreifer ausnutzen können, indem sie diese Namen registrieren. Andere haben festgestellt, dass Agenten Zugangsdaten oder Tokens an Stellen schreiben, an denen sie nicht hingehören. Der gemeinsame Nenner ist, dass Agenten bei der Arbeit Artefakte erzeugen, und jedes Artefakt ist ein potenzielles Leck.

Die beruhigende Lesart ist, dass sich das beheben lässt und sich größtenteils auf Hygiene reduziert. Die weniger beruhigende Lesart ist, dass die Branche Agenten schneller einsetzt, als sie Leitplanken um deren Output herum aufbaut. Ein Unternehmen, das prüft, was seine Agenten lesen, prüft oft nicht, was sie schreiben.

Was diese Woche zu tun ist

Wenn ein Team Coding-Agenten gegen Repositories laufen lässt, lohnen sich die sofortigen Prüfungen. Sehen Sie nach, ob das Arbeitsverzeichnis des Agenten innerhalb des Repositorys liegt, ob Screenshots oder Logs dort landen und ob der Commit-Schritt irgendetwas filtert. Prüfen Sie die Repository-Historie ebenso wie den aktuellen Baum auf Bilddateien, die nicht öffentlich sein sollten. Und geben Sie Agenten einen Scratch-Pfad außerhalb des Baums für alles Temporäre.

Nichts davon erfordert neue Tools. Es erfordert die Entscheidung, dass Agenten-Output, wie Agenten-Input, etwas ist, das ein Team bewusst und nicht versehentlich steuert.