Moderne Entwicklungsumgebungen enthalten weit mehr Authentifizierungsmaterial als das Quellcode-Repository allein. Neben den erwartbaren Orten — .env-Dateien, Shell-History, Paketmanager-Konfiguration — finden sich Geheimnisse in CLI-Caches, CI/CD-Konfigurationen und IDE-Einstellungen. Zunehmend stoßen Teams auch auf Zugriffsschlüssel in der Konfiguration von KI-Entwicklungswerkzeugen. Genau deshalb weiten die Entwickler von Zugangsdaten-Malware ihren Suchradius aus: Der Angreifer muss vor dem Sammeln nicht wissen, welcher Schlüssel am wertvollsten ist — er sortiert hinterher, was sich womit öffnen lässt.
Verteidiger sollten das Problem umgekehrt angehen und zuerst bestimmen, welche Zugangsdaten am kritischsten sind. Oben auf dieser Liste stehen Veröffentlichungs-Token für Pakete, denn sie verwandeln Zugangsdatendiebstahl in Softwareverteilung und treiben den Angriff weiter. Solche Token tragen Autorität über ein vertrauenswürdiges Paket, das andere Entwickler, Buildsysteme und Organisationen automatisch beziehen.
Die Empfehlung lautet, die Abhängigkeit von langlebigen Veröffentlichungs-Token zu verringern und auf kurzlebige, verifizierte Authentifizierung über OpenID Connect (OIDC) oder ähnlich eng gefasste Mechanismen umzustellen. Jüngste Aktualisierungen bei Docker und GitHub Actions hätten das Ökosystem in diese Richtung geschoben, unter anderem mit stärkerer Authentifizierung und breiterer Nutzung von Trusted Publishing. Auch die Cloud-Plattformen bewegen sich auf föderierte Token-Dienste wie AWS STS zu. Verbleibende langlebige Veröffentlichungs-Token sollten wie hochsensible Infrastruktur behandelt werden: auffindbar, validiert, mit klarer Zuständigkeit, überwacht und bei Offenlegung rotiert.
Wichtig ist dabei, dass ein Geheimnis nicht in Git eingecheckt sein muss, um für Malware auf dem Entwicklerrechner erreichbar zu sein. Paketautoren schreiben Authentifizierungsschlüssel häufig im normalen Arbeitsablauf in lokale Konfigurationsdateien — ein Grund, weshalb aktuelle Lieferkettenangriffe verstärkt die Arbeitsumgebung der Entwickler selbst ins Visier nehmen.
Sicherheitsteams denken traditionell in Sparten: Source-Control-, CI/CD-, Cloud-, Endpunkt- und Anwendungssicherheit. Zugangsdaten queren all diese Grenzen. Ein einzelner Entwickler authentifiziert sich an einem gewöhnlichen Arbeitstag gegenüber GitHub, npm, AWS, Kubernetes, internen APIs und Buildsystemen; CI/CD-Pipelines tragen oft eine ähnlich breite Auswahl. Wo ein Geheimnis gefunden wird, erzählt daher nur einen Teil der Geschichte: Entscheidend ist, ob es gültig ist, zu welcher Identität es gehört, welches System es akzeptiert, welche Rechte und welche Umgebung es umfasst und wer für die Behebung zuständig ist. Erst das macht aus Secrets-Erkennung ein Management von Zugangsdatenrisiken.
Denn eine Liste mit 100.000 Fundstellen bedeutet nicht 100.000 gleich dringende Vorfälle. Manche Zugangsdaten sind längst ungültig, andere reichen nur in wegwerfbare Entwicklungsumgebungen, eine kleinere Zahl öffnet Produktionsdatenbanken, Cloud-Infrastruktur, Deployment-Systeme oder die Paketveröffentlichung. Umgebungsgrenzen verwischen zudem, wenn Zugangsdaten mehrfach genutzt werden: Ein in Staging gefundenes Token kann sich weiterhin gegen die Produktion authentifizieren.
Die Größenordnung macht manuelle Triage unrealistisch: GitGuardians Studie „State of Secrets Sprawl" zählte allein 2025 rund 28,65 Millionen neu in öffentliche GitHub-Commits eingefügte hartcodierte Geheimnisse — ein Plus von 34 Prozent gegenüber dem Vorjahr. Ein wichtiger Messwert ist laut GitGuardian der Anteil der Geheimnisse, die außerhalb eines Vaults liegen; Behebungspläne, die diese verwaisten Klartext-Schlüssel nicht erfassen, seien zum Scheitern verurteilt.
Die nächste Shai-Hulud-Variante werde mit hoher Wahrscheinlichkeit an neuen Orten suchen und die Zahl 469 überschreiten. Erkennung, Behebung und Prävention müssten deshalb als fortlaufender Zyklus verstanden werden — nicht als Notfallreaktion nach einem Angriff.