1,27 Millionen Zugangsdaten für KI-Dienste sind im vergangenen Jahr in öffentlichem Code aufgetaucht, 81 Prozent mehr als im Vorjahr. Die Zahl stammt aus GitGuardians fünftem State-of-Secrets-Sprawl-Bericht und ist nur ein Ausschnitt des Problems. In öffentlich einsehbaren MCP-Konfigurationsdateien allein fanden sich 24.008 Secrets. Wer die Sicherheit einer Codebasis verantwortet, hat es längst nicht mehr mit einer überschaubaren Liste zu tun. Es ist ein Grundrauschen, das jeden Tag neue Fundstücke produziert.
Diese Funde verfallen außerdem nur langsam. Von den Zugangsdaten, die GitGuardian 2022 als gültig bestätigt hatte, waren im Januar 2026 noch 64 Prozent unverändert aktiv. Ein geleaktes Passwort verschwindet nicht mit dem Commit, in dem es aufgetaucht ist. Es bleibt erreichbar, oft über Jahre, und führt zu denselben Systemen wie am ersten Tag. Wer heute ein Monitoring aufsetzt, hat es deshalb auch mit einem Altbestand zu tun, der nie geschlossen wurde.
Warum geleakte Zugangsdaten länger leben als ihr Commit
Das Problem ist nicht die Erkennung. Öffentliche Repositories nach Schlüsselmustern zu durchsuchen, ist technisch gelöst und skaliert gut. Was nicht mitskaliert, ist alles, was nach dem Alarm passiert. Zuerst muss jemand entscheiden, ob der gefundene Schlüssel überhaupt zur eigenen Organisation gehört. Dann gilt es einzuschätzen, wie gefährlich er ist. Bei 1,27 Millionen Fundstellen pro Jahr ist das eine Personalfrage, keine Routinearbeit.
Dazu kommt, dass KI-gestützte Entwicklung die Zahl der Ablageorte vervielfacht hat. Zugangsdaten landen im Quellcode und in CI/CD-Pipelines – und dazu in MCP-Konfigurationsdateien, in Caches von KI-Werkzeugen, in Terminal-Sitzungsprotokollen und in der Ausgabe von Agenten, die für Menschen Code schreiben. Jeder dieser Orte ist von außen einsehbar. Die Angriffsfläche wuchs damit schneller als die Fähigkeit irgendeines Teams, sie zu prüfen.
Der Engpass hat sich also verschoben, statt neu zu entstehen. Erkennen ist billig geworden, Bewerten teuer. Die folgenden zwei Fragen entscheiden, ob ein Public-Secrets-Monitoring nützt oder nur Lärm macht.
Zwei Fragen entscheiden über jedes Fundstück
Denk an eine Notaufnahme. Der Alarm ist der Patient, der ohne Anmeldung hereinkommt. Bevor jemand behandelt, muss geklärt werden: Gehört dieser Mensch zu uns, und wie dringend ist sein Zustand? Bei geleakten Zugangsdaten ist es genauso, und beide Fragen lassen sich nicht mit einem Blick beantworten.
Die erste Frage lautet: Ist das tatsächlich unseres? Ein Schlüssel in einem öffentlichen Repository kann zur eigenen Organisation gehören, zu einem Dienstleister, zu einem Auftragnehmer oder zu einer Entwicklerin, die die Firmendomain in einer Testumgebung verwendet hat. Die schwierigen Fälle laufen in beide Richtungen. Ein Cloud-Schlüssel im privaten Repository eines eigenen Entwicklers wirkt alarmierend, bis man bemerkt, dass er zum privaten Konto gehört. Ein Schlüssel von einer völlig unbekannten Person in einem unbekannten Repository wirkt irrelevant, bis der umgebende Code einen internen Dienst referenziert. Beide Schlüssel sind aktiv. Der Unterschied zwischen „kritisch, sofort eskalieren“ und „nicht unseres, ignorieren“ ist die erste Information, die ein Prüfer braucht.
Die zweite Frage lautet: Wie ernst ist es? Ein nicht widerrufenes Produktionsdatenbank-Passwort aus einem halben Jahr alten öffentlichen Commit ist eine andere Situation als ein Test-API-Schlüssel in einer Sandbox. Eine Zahl auf einer Skala von eins bis zehn plättet diesen Unterschied zu einem Rangwert. Dabei geht die Begründung verloren, der daraus folgende Bearbeitungspfad und alles, was eine Teamleitung an ihr Team weitergeben könnte.
Ohne verlässliche Antworten auf beide Fragen bleibt nur die Wahl zwischen zwei Übeln. Überprüfung bedeutet, alles anzusehen und Analystenstunden an Vorfälle zu verschwenden, die nie die eigenen waren. Unterprüfung bedeutet, schnell genug zu sein und dabei die echten Fälle zu übersehen. Mit steigendem Volumen hält keine der beiden Strategien stand.
Wie Triage- und Deep-Analysis-Agent zusammenarbeiten
GitGuardians Public Secrets Monitoring setzt zwei KI-Agenten auf jeden öffentlichen Vorfall bei GitHub und Docker Hub an. Ein Triage-Agent erstellt eine erste Einschätzung. Die aussichtsreichsten Fälle gehen an einen zweiten Agenten, der tiefer gräbt. Das erinnert an die Notaufnahme: Erst sichtet jemand grob, dann übernimmt die Fachabteilung für die Fälle, bei denen sich der Aufwand lohnt.
Die Schlussfolgerungen erscheinen an drei Stellen. Jeder Vorfall wird als „Related“, „Uncertain“ oder „Unrelated“ markiert, mit nachlesbarer Begründung statt einer Wahrscheinlichkeit, die man interpretieren muss. Nur der Deep-Analysis-Agent darf ein „Related“ bestätigen. Wer ein solches Urteil sieht, weiß also, dass der Fall beide Prüfstufen passiert hat. Zusätzlich berechnet ein Agent einen Risikowert, der berücksichtigt, was das Secret ist, wo es aufgetaucht ist und worauf es zugreifen kann. Dieser Wert wird einmal gesetzt und driftet nicht; alles, was als „Unrelated“ eingestuft wurde, erhält null Punkte. Sortiert man nach Risiko, rutscht der Lärm automatisch nach unten.
Dazu kommen drei vorkonfigurierte Ansichten: unternehmensbezogene Vorfälle, unklare Fälle und solche, die nachweislich nicht das Unternehmen betreffen. Teams öffnen damit eine vorsortierte Warteschlange statt einer flachen Liste. Die Menge der Fundstücke bleibt gleich – nur die Reihenfolge der Bearbeitung ändert sich.
Was die Begründung leistet
Der zweite Teil der Neuerung ist ein Analyse-Tab, der zeigt, wie die Agenten vom Fund zum Urteil gelangt sind. Er legt die Überlegungen der Triage offen, die tiefergehende Untersuchung, sofern sie gelaufen ist, und die Zeitleiste beider Schritte. Die meisten Werkzeuge in dieser Kategorie liefern eine Klassifikation und erwarten, dass man sie glaubt. Das ist viel verlangt von einem Team, das später eine Schlüsselrotation gegenüber einer Entwicklungsabteilung rechtfertigen muss, die danach nicht gefragt hat.
Wer anderer Meinung ist als das System, kann nachsehen, welche Signale zu dem Urteil geführt haben, und abwägen, ob das eigene Wissen über die Umgebung schwerer wiegt. Eine Rückmeldungsschleife erlaubt es, Fehlurteile zu markieren, und GitGuardian nutzt dieses Signal, um spätere Versionen der Analyse zu verbessern. So bleibt die KI-Analyse ein nachprüfbarer Vorschlag, den ein Mensch bestätigen oder verwerfen kann.
Standardmäßig aktiv, zehnfacher Produktivitätsfaktor
Für neue Workspaces von Public Secrets Monitoring ist die Agentenanalyse standardmäßig aktiv. Sie erhalten das Urteil zur Unternehmenszugehörigkeit, den Risikowert, den Analyse-Tab und die neuen Ansichten sofort. Bestehende Workspaces werden schrittweise umgestellt, weil viele Teams ihre Abläufe auf die bisherigen Tags und Bewertungen aufgebaut haben. Sie sollten verstehen, was sich ändert, bevor es sich ändert. Die Funktion befindet sich in der Beta, die Analyse trifft innerhalb eines Tages nach der Erkennung ein, nicht sofort. Wer sie früher nutzen möchte, wendet sich an den Customer Success Manager.
Ein Sicherheitsteam eines großen Unternehmens, das seine GitGuardian-Vorfälle über eine MCP-Server-Integration abwickelt, berichtet von einem zehnfachen Produktivitätsgewinn. Der von Agenten erzeugte Kontext, also Urteil, Begründung und Risikowert, ersetzt die manuelle Untersuchung, die früher jedem Gespräch über eine Behebung vorausging. Die Analystin, die wissen muss, ob ein Vorfall ihrer ist und wie schlimm er steht, bekommt diese Antwort zusammen mit dem Vorfall geliefert, statt sie selbst zu suchen.
Was öffentliches Secrets-Monitoring leistet – und was nicht
Public Secrets Monitoring sitzt an einer sehr spezifischen Stelle im Umgang mit Exposition. Meistens wurde ein Secret zuerst intern preisgegeben, bevor es öffentlich auftauchte. Der öffentliche Alarm ist damit das früheste externe Signal dafür, dass weiter oben in der Kette etwas schiefgelaufen ist. Das macht die Einschätzung folgenreicher, als sie aussieht: Ein Fehlalarm kostet Analystenstunden, ein übersehener Treffer kann bedeuten, dass ein Angreifer zuerst an die Zugangsdaten kommt.
Von Secrets-Managern ist das zu unterscheiden. Diese schützen die Zugangsdaten, die man bewusst unter Verwaltung gestellt hat, kontrollieren Ausgabe, Rotation und Zugriff. Für Secrets, die nie dort abgelegt wurden, haben sie keine Sicht, und genau diese Kategorie landet in öffentlichen Repositories. Erkennung ist eine getrennte Kontrolle, kein Nebenprodukt eines Tresors.
GitGuardian schließt außerdem nichts automatisch. Das System trennt Lärm von lesenswerten Vorfällen, liefert Urteil, Risikowert und Begründung, aber die Entscheidung bleibt beim Team. Wer nach einem Fund handelt, bestätigt zuerst die Zugehörigkeit, widerruft oder rotiert den Schlüssel, sucht dann die interne Quelle und schließt den Vorfall erst, wenn diese Quelle identifiziert und behoben ist. Ein KI-gestütztes Monitoring beschleunigt diesen Weg, es ersetzt ihn nicht. Am meisten bringt es, wenn die wenigen Fundstücke, die wirklich die eigenen sind, schneller mit Begründung auf dem Tisch liegen.
Quelle: blog.gitguardian.com
