Der Stand der Secrets-Ausbreitung 2026: Wichtige Erkenntnisse aus dem GitGuardian-Bericht

Im Jahr 2025 hat GitGuardian 28,65 Millionen neue hartcodierte Secrets in öffentlichen GitHub-Commits erkannt. Das entspricht einem Anstieg von 34 % gegenüber dem Vorjahr und dem größten Jahressprung, den das Unternehmen je verzeichnet hat. Diese Zahl umfasst nur öffentliche Repositories. Das vollständige Bild — unter Einbeziehung interner Systeme, Kollaborationstools und selbst gehosteter Infrastruktur — ist deutlich schlimmer.

Drei Themen ziehen sich durch die Daten:

1. KI-gestützte Entwicklung hat sich vom Experiment zum Standard entwickelt und beschleunigt das Durchsickern von Zugangsdaten auf jeder Ebene des Stacks.
2. Interne Systeme sind weitaus stärker exponiert, als die meisten Organisationen annehmen: Private Repositories, Slack-Kanäle und selbst gehostete GitLab-Instanzen bergen alle erhebliche Risiken für Zugangsdaten.
3. Behebung bleibt das kritische Versagen der Branche: 64 % der im Jahr 2022 als gültig bestätigten Secrets waren im Januar 2026 — vier Jahre nach dem ersten Leak — immer noch ausnutzbar.

Dieser Artikel analysiert jeden Befund mit den Daten und dem Kontext, den IT- und Sicherheitsteams benötigen, um intern für Veränderungen zu argumentieren.

Zentrale Erkenntnisse

• KI ist der dominierende Treiber für die Exposition von Zugangsdaten. Acht der zehn am schnellsten wachsenden Arten von geleakten Secrets sind mit KI-Diensten verbunden. LLM-Infrastruktur leckt 5× schneller als die Kernanbieter von Modellen.
• Interne Repositories enthalten mit 6× höherer Wahrscheinlichkeit ein hartcodiertes Secret als öffentliche. „Privat" ist keine Sicherheitskontrolle.
• Ein Viertel aller internen Vorfälle stammt von außerhalb der Codebasis. Slack, Jira und Confluence machen 28 % der Leaks aus — mit einer höheren Rate kritischer Schweregrade als codebasierte Befunde.
• Behebung ist der limitierende Faktor der Branche. 64 % der im Jahr 2022 als gültig bestätigten Secrets waren im Januar 2026 immer noch ausnutzbar.
• Ausschließlich validierungsbasierte Priorisierung übersieht 46 % der kritischen Secrets. Generische Zugangsdaten — private Schlüssel, benutzerdefinierte Token, Passwörter — können nicht automatisch validiert werden, verursachen aber die Hälfte aller kritischen Vorfälle.
• Entwickler-Workstations und CI/CD-Runner sind eine unterschätzte Angriffsfläche. Der Shai-Hulud-2-Angriff fand 294.842 Secret-Vorkommen auf 6.943 kompromittierten Maschinen; 59 % waren CI/CD-Runner.
• Drittanbieter und Auftragnehmer sind ein unkontrollierter Secrets-Vektor. GitGuardian fand 1.834 kritische Vorfälle bei 13 Beratungsfirmen, die potenziell 1.203 Kundenorganisationen betreffen.
• MCP-Konfigurationsdateien sind eine neue und weitgehend unüberwachte Leak-Oberfläche. Im Jahr 2025 wurden 24.008 einzigartige Secrets in MCP-bezogenen Konfigurationen auf öffentlichem GitHub exponiert — 8,8 % waren zum Zeitpunkt der Erkennung als gültig bestätigt.

Wie groß ist das Problem der Secrets-Ausbreitung im Jahr 2025?

Secrets-Ausbreitung bezeichnet die unkontrollierte Verbreitung hartcodierter Zugangsdaten (API-Schlüssel, Passwörter, Token und Zertifikate) über Codebasen, Konfigurationsdateien und Kollaborationstools hinweg. Seit 2021 sind geleakte Secrets auf öffentlichem GitHub um 152 % gestiegen, während die Entwicklerpopulation um 98 % wuchs. Die Lücke weitet sich jedes Jahr, und 2025 produzierte den größten jemals verzeichneten Volumenanstieg in einem Jahr.

Ausmaß in Zahlen

Das Ausmaß des Problems ist strukturell. Mehr Menschen schreiben mehr Code, integrieren mehr Drittanbieterdienste und generieren mehr Zugangsdaten, die durchsickern können.

Eine Metrik blieb stabil: Secrets pro Repository. Die Dichte blieb ungefähr gleich, was darauf hindeutet, dass GitHubs Push Protection seine Aufgabe erfüllt, gängige Zugangsdaten abzufangen, bevor sie öffentlich werden. Aber Dichtekontrolle kann das Volumenwachstum nicht aufhalten. Wenn sich die Gesamtzahl der Commits vervierfacht, produziert selbst eine stabile Leak-Rate pro Repository eine Rekordzahl exponierter Zugangsdaten.

Wie KI eine neue Generation geleakter Secrets befeuert

KI-gestützte Entwicklung hat verändert, welche Secrets durchsickern, wie schnell sie sich ansammeln und wo sie landen. Acht der zehn am schnellsten wachsenden Arten geleakter Secrets im Jahresvergleich sind mit KI-Diensten verbunden. Der KI-Infrastruktur-Boom ist derzeit der dominierende Treiber für die Exposition von Zugangsdaten.

Der KI-Infrastruktur-Boom

Im Jahr 2025 erkannte GitGuardian 1.275.105 Secrets, die zu KI-Diensten gehören — ein Anstieg von 81 % gegenüber 2024.

Am schnellsten wachsende spezifische Detektoren (KI-bezogen):

Der bedeutendere Trend ist, was jenseits der Modellanbieter selbst durchsickert. LLM-Infrastruktur (die Orchestrierungs-, Retrieval- und Speicherschicht, die Kernmodelle umgibt) leckt 5× schneller als die Modellanbieter. Allein Supabase rangiert jetzt unter den Top 20 der am häufigsten geleakten Secrets insgesamt mit über 248.600 Vorkommen.

Das Muster ist konsistent: Entwickler, die KI-gestützte Anwendungen erstellen, verbinden ein Modell mit einer Retrieval-Schicht, einem Orchestrierungstool, einer Vektordatenbank, einem Experiment-Tracker und einem Überwachungsdienst. Jede Integration fügt eine neue Zugangsberechtigung hinzu. Jede Zugangsberechtigung ist ein potenzielles Leck.

Mit dem Entstehen neuer KI-Anbieter gibt es unvermeidlich eine Verzögerung, bis die Erkennungsabdeckung nachzieht. GitHub Push Protection konzentriert sich auf bekannte Muster. Neuartige Anbieter schlüpfen durch. Bis ein Detektor erstellt ist, können bereits Tausende von Schlüsseln öffentlich sein.

Claude Code und KI-gestützte Commits leaken Secrets mit 2× der Baseline

Anthropics Claude Code wuchs von 22 mitautorierten Commits im Januar 2025 auf 2,16 Millionen im Dezember. Über das gesamte Jahr:

• Claude Code-gestützte Commits = 0,4 % von allem, was öffentlich gescannt wurde
• Claude Code-gestützte Commits = 0,9 % aller Leaks
• Leak-Rate: 3,2 % vs. 1,5 % Baseline über alle öffentlichen GitHub-Commits

Claude Code Leak-Rate im Jahr 2025:

Claude Code-Commits waren auch durchweg größer — etwa 2× die Codezeilen pro Commit ab April. Größere Commits bedeuten mehr Angriffsfläche für die Exposition von Zugangsdaten in einer einzelnen Überprüfung.

Die wichtige Nuance: Der Entwickler behält die Kontrolle über jeden Commit. KI-Coding-Assistenten sind Werkzeuge. Die erhöhte Leak-Rate spiegelt menschliche Entscheidungen wider — Aufsichtsmängel, Zeitdruck oder bewusste Entscheidungen, Warnungen zu umgehen — nicht autonomes KI-Verhalten.

Die Schlussfolgerung für Sicherheitsteams: Behandeln Sie KI-generierte Änderungssätze als Überprüfungseinheiten mit höherer Auswirkung, halten Sie automatisiertes Scannen im Entwickler-Workflow aufrecht und halten Sie die Behebung schnell genug, damit ein geleaktes Secret nicht lange genug gültig bleibt, um ausgenutzt zu werden.

24.000 Secrets in MCP-Konfigurationsdateien

Was ist MCP? Model Context Protocol ist der Standard, der Anfang 2025 entstand, um große Sprachmodelle mit externen Tools und Datenquellen zu verbinden. Wenn ein Entwickler möchte, dass sein KI-Agent eine Datenbank abfragt, das Web durchsucht oder mit einer SaaS-Plattform interagiert, übernimmt MCP die Verbindung — und diese Verbindungen erfordern Zugangsdaten.

Zentrale Erkenntnisse:

• 24.008 einzigartige Secrets in MCP-bezogenen Konfigurationsdateien auf öffentlichem GitHub im Jahr 2025 exponiert
• 2.117 als gültig bestätigt (8,8 %) zum Zeitpunkt der Erkennung

Top 5 gültige Secret-Typen in MCP-Konfigurationen:

Warum MCP-Konfigurationen weiterhin leaken: Offizielle MCP-Setup-Anleitungen normalisieren Hartcodierung. Beliebte Quickstart-Dokumentationen zeigen API-Schlüssel, die als Kommandozeilenargumente in Serverkonfigurationsdateien übergeben oder inline in JSON-Dateien gespeichert werden, die in die Versionskontrolle committet werden. Wenn offizielle Dokumentation Hartcodierung als Standard behandelt, folgt Ausbreitung.

Der Smithery.ai-Fall: GitGuardians Forschungsteam offenbarte eine kritische Schwachstelle in einem der am häufigsten verwendeten MCP-Server-Registries. Ein einziger Path-Traversal-Bug im Docker-Build-Prozess der Plattform exponierte ein überprivilegiertes Token, das beliebige Codeausführung über alle 3.000+ gehosteten MCP-Server ermöglichte — und Zugang zu den API-Schlüsseln und Secrets von Tausenden von Kunden über Hunderte von Diensten hinweg.

MCP-Zugangsdatenverwaltung — Mindeststandards:

• Speichern Sie niemals Secrets in MCP-Konfigurationsdateien. Verwenden Sie Umgebungsvariablen, die von einem dedizierten Secrets-Manager verwaltet werden, keine Inline-Werte in JSON oder CLI-Argumenten.
• Clients, nicht Server, sollten die Secrets besitzen. MCP-Server sollten Zugangsdaten zur Abfragezeit von Clients anfordern, anstatt sie in serverseitige Konfigurationen einzubetten.
• Schließen Sie MCP-Konfigurationsverzeichnisse von der Versionskontrolle aus via .gitignore.
• Verbinden Sie sich nur über TLS mit Remote-MCP-Servern.
• Scannen Sie vor dem Pushen. Pre-Commit-Scanning-Tools erkennen Secrets in MCP-Konfigurationsdateien, bevor sie die Versionskontrolle erreichen.
• Erfordern Sie manuelle Genehmigung vor jeder MCP-Aktion, die Produktionssysteme, Datenbanken oder Deployment-Pipelines berührt.

Secrets, die in Code, Konfigurationen und Chat-Nachrichten liegen, sind ein Sicherheitsvorfall, der darauf wartet zu passieren. Passwork gibt Ihrem Team einen einzigen, sicheren Ort zum Speichern, Teilen und Rotieren von Zugangsdaten — damit sie niemals hartcodiert in einem Repository landen oder in einen Slack-Kanal eingefügt werden. Entdecken Sie Passworks Secrets-Management-Funktionen

Interne Systeme sind ein gefährlicher blinder Fleck

Der folgenreichste Befund im Bericht 2026 ist einer, der die geringste Medienberichterstattung erhält: Die Gefahr ist dort am größten, wo sich Organisationen am sichersten fühlen. Interne Repositories, Kollaborationstools und selbst gehostete Infrastruktur werden standardmäßig als sicher behandelt — aber die Daten sagen etwas anderes.

Interne Repositories leaken 6× mehr als öffentliche

Der Grund ist das „Security through Obscurity"-Antimuster. Entwicklungsteams neigen dazu, innerhalb eines geschlossenen Perimeters weniger vorsichtig zu sein. Sie nehmen an, dass das Exponieren eines Secrets in einem privaten Repository weniger schädlich ist, weil es nicht öffentlich überprüft werden kann. Das Ergebnis ist ein stilles Anwachsen hartcodierter Zugangsdaten, die „später" entfernt werden sollen — und selten werden.

Interne Repositories enthalten auch die wertvollsten Zugangsdaten:

• CI/CD-Token
• Cloud-Zugriffsschlüssel
• Datenbank-Zugangsdaten
• Token für interne Tools

Das sind genau die Assets, die ein Angreifer will, sobald er einen Fuß in der Tür hat. Ein einzelnes exponiertes Secret in einem privaten Repository kann zum schnellen Weg für laterale Bewegung durch die gesamte Infrastruktur werden.

Expositionsraten nach Branche (öffentliche Repositories):

Diese Zahlen repräsentieren nur das, was extern sichtbar ist. Interne Exposition ist durchweg 6× höher.

Beratungsfirmen verwandeln Secrets-Ausbreitung in Drittanbieterrisiko

Auftragnehmer und Beratungsfirmen arbeiten gleichzeitig in mehreren Kundenumgebungen. Sie halten Zugangsdaten, Token und Konfigurationswissen für jeden Kunden, den sie betreuen — und sie arbeiten oft in persönlichen Accounts oder Repositories außerhalb der GitHub-Organisation ihres Kunden.

GitGuardians Analyse von 13 Beratungsfirmen:

Der Red Hat-Breach (Oktober 2025): Die Cybercrime-Gruppe „Crimson Collective" exfiltrierte 570 GB Daten aus 28.000 Repositories auf Red Hats interner Consulting-GitLab-Instanz, was etwa 800 Organisationen weltweit betraf. Die geleakten Daten enthielten:

• API-Schlüssel und Datenbank-Zugangsdaten
• Authentifizierungstoken und VPN-Konfigurationen
• Infrastrukturdetails und interne Architektur

Betroffene Organisationen umfassten Bank of America, JPMorgan Chase, IBM, Cisco, die U.S. Navy und die NSA. Die Angreifer nutzten die gesammelten Zugangsdaten, um direkt in die Kundeninfrastruktur vorzudringen.

Jede Organisation, die Auftragnehmer oder Beratungsfirmen einsetzt, hat ein Drittanbieter-Secrets-Problem, ob es entdeckt wurde oder nicht.

Einer von vier internen Leaks stammt von außerhalb der Codebasis

Woher interne Vorfälle stammen:

Kollaborationstools (Slack, Jira, Confluence) machen 28 % der Vorfälle aus, mit einer 13 Prozentpunkte höheren Rate kritischer Schweregrade als codebasierte Leaks. Secrets, die über diese Tools geteilt werden, sind tendenziell Produktionszugangsdaten, die während der Incident Response oder dringender Fehlerbehebung geteilt werden, wenn Menschen schnell handeln und nicht an Sicherheitshygiene denken.

Die 4 % Überschneidung zwischen SCM- und ODS-Befunden bedeutet, dass dies weitgehend separate Leak-Populationen sind. Das Scannen nur von Repositories übersieht etwa ein Viertel der Gesamtexposition einer Organisation.

80.000 Secrets auf selbst gehosteten GitLab- und Docker-Registries

GitGuardian identifizierte Tausende von selbst gehosteten GitLab-Instanzen und Docker-Registries, die ohne Authentifizierung öffentlich zugänglich waren.

Zusammenfassung der Befunde:

Gültigkeitsraten nach Zugangsdatentyp (Docker vs. GitLab):

Je näher ein Asset an der Produktion ist, desto höher ist die Wahrscheinlichkeit, gültige Zugangsdaten zu finden. Die Leak-Rate von selbst gehostetem GitLab und Docker ist 3–4× höher als von öffentlichem GitHub.

Die Forschung deckte auch 300.000+ E-Mail-Adressen (einschließlich 2.000 mit .gov-Domains) und Verweise auf interne Datenbankhosts und nicht-öffentliche Infrastruktur auf.

Der „Matrjoschka"-Effekt: Öffentlich exponierte Leaks enthalten gültige Secrets, die Zugang zu privater Infrastruktur gewähren, die wiederum mehr Secrets exponiert und den initialen Breach auf jeder Ebene verstärkt.

64 % der geleakten Secrets von 2022 sind 2026 immer noch gültig

Erkennung ohne Behebung ist keine Sicherheit — es ist Dokumentation. Die Längsschnittdaten im Bericht 2026 machen diesen Fall deutlich.

Gültigkeit von ursprünglich 2022 geleakten Secrets, über die Zeit erneut getestet:

Diese Zugangsdaten lagen vier Jahre lang in öffentlichem Code, ausnutzbar für jeden, der sie findet. Die Persistenz ist ein operatives Signal, dass Behebung — nicht Erkennung — der limitierende Faktor der Branche ist.

Warum Rotation selten stattfindet:

Zugangsdaten sind keine isolierten Zeichenketten. Sie sind eingebettet in:

• Build-Systeme und CI/CD-Pipelines
• Mehrere Repositories (dupliziert)
• Container-Images (zum Build-Zeitpunkt eingebacken)
• CI-Variablen und Umgebungskonfigurationen
• Vendor- und Drittanbieter-Integrationen

Die kurzfristige Wahl, die viele Teams treffen, ist nicht die sicherste — es ist die, die vermeidet, etwas kaputt zu machen: nichts tun.

NHI-Richtlinienverletzungsverteilung (GitGuardian-Kundendaten):

Die Erstellungsgeschwindigkeit übertrifft die Identitätsreife. KI macht es einfacher, Projekte zu erstellen und Dienste zu verbinden, aber auch einfacher, unsichere Muster im großen Maßstab zu reproduzieren, wenn der Standardansatz „einfach einen Schlüssel hinzufügen" ist.

Warum ausschließlich validierungsbasierte Priorisierung scheitert

Eine weit verbreitete Annahme in der Secrets-Sicherheit: Wenn ein Secret nicht validiert werden kann — als derzeit aktiv bestätigt — wird es herabgestuft. Der Bericht 2026 stellt dies direkt in Frage.

46 % der kritischen Secrets sind für validierungsbasierte Tools unsichtbar

Die Lücke existiert, weil die Validierungsabdeckung immer unvollständig ist:

• APIs ändern sich ohne Ankündigung
• Neue Dienste werden ständig gestartet
• Jeder Anbieter erfordert dedizierte Infrastruktur zur Validierung
• Regionale und branchenspezifische Plattformen vermehren sich

Nicht validierbare Secrets standardmäßig zu ignorieren ist keine konservative Strategie. Es ist ein systematischer blinder Fleck.

Generische Secrets verursachen die Hälfte aller kritischen Vorfälle

„Generische Secrets" — private Schlüssel, benutzerdefinierte API-Token, Passwörter und Zugriffsmechanismen, die durch Entropie-Checks und Kontext statt anbieterspezifischer Muster erkannt werden — werden routinemäßig herabgestuft, weil sie nicht automatisch validiert werden können.

Die Daten sagen, dass dies ein Fehler ist:

• 35 % der kritischen Vorfälle gehen auf generische Zugangsdaten zurück
• 51 % der Vorfälle mit hohem oder kritischem Risiko gehen auf generische Zugangsdaten zurück

Die gemeinsame Forschung mit Google (2025): GitGuardian und Google analysierten eine Million geleakte private Schlüssel gegen Certificate Transparency Logs. Zentrale Erkenntnisse:

• 4,5 % der geleakten Schlüssel wurden vertrauenswürdigen X.509-Zertifikaten zugeordnet
• Die Hälfte hatte zum Zeitpunkt des Leaks ein gültiges Zertifikat
• 4.000+ HTTPS-Zertifikate werden pro Jahr kompromittiert wegen eines geleakten Schlüssels
• Betroffene Organisationen umfassten mehrere Fortune-500-Unternehmen und eine vertrauenswürdige Zertifizierungsstelle
• GitGuardian sendete 4.000+ Warn-E-Mails an 600 Organisationen — Antwortrate: unter 10 %

Gültig bedeutet nicht immer gefährlich

Das umgekehrte Problem ist ebenso real. Etwa 10 % der gültigen Secrets haben von Natur aus geringe Auswirkungen — Sandbox-Token, Test-Umgebungszugangsdaten, Service-Accounts mit niedrigen Privilegien und Zugang nur zu trivialen Daten.

Ohne kontextuelle Risikobewertung rotieren Teams Zugangsdaten in Erkennungsreihenfolge oder Validierungsreihenfolge, nicht in Bedrohungsreihenfolge.

Die vier Fähigkeiten, die effektive Secrets-Sicherheit erfordert:

Teams, die immer noch validierungsbasierte Ansätze verwenden, sind systematisch genau den Bedrohungen ausgesetzt, die am wichtigsten sind — während sie Engineering-Zeit für Zugangsdaten verbrennen, die wenig echte Gefahr darstellen.

Die Entwickler-Workstation als übersehene Angriffsfläche

Der Shai-Hulud-2-Supply-Chain-Angriff gab GitGuardian direkte empirische Daten darüber, wie Secrets auf Entwicklermaschinen im großen Maßstab tatsächlich aussehen. Durch das Kompromittieren von npm-Paketen und deren Ausführung bei der Installation sammelte die Malware systematisch Umgebungsdateien und führte strukturierte lokale Secret-Scans auf Tausenden von echten Maschinen durch.

Shai-Hulud-2-Befunde auf 6.943 kompromittierten Maschinen:

Jedes aktive Secret erschien an etwa acht verschiedenen Stellen auf derselben Maschine — Dotfiles, Shell-Profile, Build-Outputs, IDE-Konfigurationen und Tool-Caches. Jede Kopie ist ein unabhängiger Vektor für Diebstahl.

GitHub-Token dominierten den validierten Satz:

• 581 Personal Access Tokens
• 386 OAuth-Token
• 104 Fine-grained PATs
• 101 GitLab-Token

Jedes davon ermöglicht Repository-Zugriff, Workflow-Manipulation oder laterale Bewegung durch die Software-Supply-Chain. Und da 59 % der kompromittierten Maschinen CI/CD-Runner waren, erstreckt sich diese Exposition weit über den einzelnen Entwickler hinaus in die gemeinsame Build-Infrastruktur.

GitGuardian betrachtet diese Zahlen als konservativ. Der Angriff lief nur dort, wo das bösartige Paket installiert wurde. Er erreichte keine Agent-Speicherordner, IDE-Caches oder die wachsende Angriffsfläche von KI-generierten Artefakten, die jetzt routinemäßig Zugangsdaten enthalten.

Passwork ist als selbst gehostete Lösung mit voller Kontrolle über Ihre Daten verfügbar. Es ersetzt geteilte .env-Dateien, in Chats eingefügte Zugangsdaten und in CI/CD-Konfigurationen eingebackene Token — durch einen strukturierten Tresor, rollenbasierten Zugriff und ein vollständiges Audit-Log. Entdecken Sie Passworks Deployment-Optionen

Der Weg nach vorn: Von reaktiver Erkennung zu NHI-Governance

Erkennung erfasst, was bereits existiert. Das Ziel ist, der Exposition zuvorzukommen — vollständige Sichtbarkeit über jede Zugangsberechtigung in der Umgebung: wem sie gehört, worauf sie zugreift und ob sie überhaupt noch existieren sollte. Dieser Wandel, vom Jagen von Leaks zur Governance nicht-menschlicher Identitäten, ist das, was NHI-Governance in der Praxis bedeutet.

Schritt 1: Secrets in Vault-Plattformen zentralisieren

Machen Sie den Tresor zur Quelle der Wahrheit. Wenn Teams Zugangsdaten zuverlässig von einem einzigen, zugriffskontrollierten Ort abrufen können, hören sie auf, fragmentierte Speicherstrategien zu erfinden — einer der Haupttreiber der Secrets-Ausbreitung. Passworks Tresorstruktur ist genau dafür konzipiert: organisierte, verschlüsselte und zugriffskontrollierte Speicherung für API-Schlüssel, Datenbankpasswörter, Zertifikate, SSH-Schlüssel und Service-Account-Zugangsdaten.

Schritt 2: Rotation automatisieren

Wenn ein Secret existieren muss, sollte es nicht ewig leben. Regelmäßiger Austausch von Zugangsdaten verkürzt das Zeitfenster, in dem ein Angreifer ein geleaktes Secret ausnutzen kann, und zwingt Teams, Zugangsdaten als Objekte mit einem Lebenszyklus zu behandeln, nicht als einmalige Setup-Aufgaben. Rotation ist weitaus einfacher, sobald eine Vault-Strategie vorhanden ist — der Tresor wird zum einzigen Ort, der aktualisiert werden muss, anstatt jeden Ort aufzuspüren, an den eine Zugangsberechtigung kopiert wurde.

Schritt 3: Entwickler-Workflows reparieren

Entwickler codieren Secrets hart, weil es der schnellste Weg ist, Code zum Laufen zu bringen. Beseitigen Sie die Notwendigkeit für geteilte .env-Dateien und kopierte Token, indem Sie den vault-basierten Abruf von Zugangsdaten ebenso schnell machen. Der sichere Weg muss einfacher sein als der unsichere.

Schritt 4: Scannen früher verlagern

Pre-Commit-Scanning und Erkennung auf Workstation-Ebene stoppen Vorfälle, bevor sie irgendwo dauerhaft landen. Moderne Scanning-Tools liefern verwertbare Signale mit niedrigen Falsch-Positiv-Raten — eine deutliche Verbesserung gegenüber den störungsanfälligen Tools, die in der Vergangenheit das Vertrauen der Entwickler untergraben haben.

Schritt 5: Zu identitätsbasierter Authentifizierung übergehen

Der langfristige Ausweg aus langlebigen statischen Secrets ist kurzlebiger, identitätsgesteuerter Zugriff. Frameworks wie SPIFFE, implementiert durch das Open-Source-Projekt SPIRE, ersetzen Shared-String-Authentifizierung durch stark attestierte Workload-Identität. Jede Workload erhält Just-in-Time, kurzlebige Zugangsdaten anstelle eines statischen Schlüssels, der jahrelang kopiert, geleakt und ausgenutzt werden kann.

Drei Prinzipien für 2026

Drei Governance-Fragen, die jede Organisation beantworten muss

1. Welche nicht-menschlichen Identitäten existieren in unserer Umgebung?
2. Wem gehören sie?
3. Worauf können sie zugreifen?

Wenn eine dieser Fragen nicht mit Sicherheit beantwortet werden kann, überholt die KI-Einführung die Sicherheitslage.

Zentrale Erkenntnisse für IT- und Sicherheitsteams

Der GitGuardian-Bericht 2026 ist ein detaillierter Bericht über ein sich beschleunigendes Problem. Hier ist, was die Daten in der Praxis erfordern:

Organisationen, die Zugangsdatenverwaltung als Lebenszyklus-Disziplin behandeln — mit zentralisierten Tresoren, automatisierter Rotation und durchgesetzter Zugriffskontrolle — werden für die Ära der agentischen KI am besten positioniert sein. Diejenigen, die es als Aufräumaufgabe behandeln, werden weiterhin feststellen, dass ihre Secrets ihre Sicherheitsannahmen überdauern.

Die Daten sind eindeutig: Secrets, die in Code, Konfigurationen und Chat-Nachrichten liegen, sind ein Sicherheitsvorfall, der darauf wartet zu passieren. Passwork gibt Ihrem Team einen einzigen, sicheren Ort zum Speichern, Teilen und Rotieren von Zugangsdaten — mit rollenbasiertem Zugriff, einem vollständigen Audit-Log und selbst gehostetem Deployment, das alles innerhalb Ihrer eigenen Infrastruktur hält. Testen Sie Passwork in Ihrer Infrastruktur

FAQ

Was ist Secrets-Ausbreitung?

Secrets-Ausbreitung ist die unkontrollierte Verbreitung hartcodierter Zugangsdaten — API-Schlüssel, Passwörter, Token, Zertifikate und Verbindungszeichenfolgen — über Codebasen, Konfigurationsdateien, CI/CD-Pipelines und Kollaborationstools hinweg. Sie tritt auf, wenn Zugangsdaten schneller erstellt werden, als sie nachverfolgt, rotiert oder widerrufen werden, und hinterlässt Organisationen mit einem wachsenden Bestand ausnutzbarer Zugriffswege, den sie nicht vollständig erfassen können.

Wie viele Secrets wurden 2025 auf GitHub geleakt?

GitGuardian erkannte 2025 28,65 Millionen neue hartcodierte Secrets in öffentlichen GitHub-Commits — ein Anstieg von 34 % gegenüber 2024 und der größte jemals verzeichnete Jahressprung. Diese Zahl umfasst nur öffentliche Repositories. Interne Repositories, Kollaborationstools und selbst gehostete Infrastruktur erhöhen die Gesamtexposition erheblich.

Welcher Prozentsatz der geleakten Secrets wird nie widerrufen?

64 % der im Jahr 2022 als gültig bestätigten Secrets waren im Januar 2026 immer noch gültig und ausnutzbar, was bedeutet, dass sie vier Jahre lang in öffentlichem Code lagen, ohne rotiert oder widerrufen zu werden. Die Gültigkeitsrate lag bei etwa 70 %, als derselbe Datensatz im Januar 2025 erneut getestet wurde, was trotz vier Jahren Exposition nur einen allmählichen Rückgang zeigt.

Warum sind interne Repositories gefährlicher als öffentliche?

Interne Repositories enthalten mit 6× höherer Wahrscheinlichkeit ein hartcodiertes Secret als öffentliche — 32,2 % vs. 5,6 % im Jahr 2025. Teams neigen dazu, innerhalb eines geschlossenen Perimeters weniger vorsichtig zu sein, in der Annahme, dass ein privates Repository von Natur aus sicher ist. Interne Repositories enthalten auch die wertvollsten Zugangsdaten: CI/CD-Token, Cloud-Zugriffsschlüssel und Datenbank-Zugangsdaten — genau das, was Angreifer anvisieren, sobald sie einen Fuß in der Tür haben.

Wie erhöht KI-gestütztes Coding das Risiko von Secrets-Leaks?

KI-Coding-Assistenten generieren größere Commits mit mehr Code pro Änderung, was die Angriffsfläche für die Exposition von Zugangsdaten erhöht. Claude Code-mitautorisierte Commits leakten Secrets mit 3,2 % — mehr als das Doppelte der 1,5 %-Baseline über alle öffentlichen GitHub-Commits. LLM-Infrastruktur-Secrets leaken 5× schneller als Secrets von Kernmodellanbietern. Jede neue KI-Dienst-Integration fügt Zugangsdaten hinzu, die hartcodiert, kopiert und geleakt werden können.

Was sind MCP-Konfigurationsdateien und warum leaken sie Secrets?

Model Context Protocol (MCP) ist der Standard für die Verbindung großer Sprachmodelle mit externen Tools und Datenquellen. MCP-Konfigurationsdateien definieren, wie ein KI-Agent sich mit Datenbanken, APIs und Diensten verbindet — und diese Verbindungen erfordern Zugangsdaten. Im Jahr 2025 fand GitGuardian 24.008 einzigartige Secrets in MCP-Konfigurationsdateien auf öffentlichem GitHub, wobei 2.117 als gültig bestätigt wurden. Offizielle MCP-Setup-Anleitungen normalisieren oft das Hartcodieren von Zugangsdaten direkt in Konfigurationsdateien, was das Problem fortpflanzt.

Was ist ausschließlich validierungsbasierte Priorisierung und warum scheitert sie?

Ausschließlich validierungsbasierte Priorisierung ist die Praxis, Secrets herabzustufen, die nicht als derzeit aktiv bestätigt werden können. Sie scheitert, weil 46 % der kritischen Secrets nicht validiert werden können — sie gehören zu Diensten ohne Validierungs-Checker oder zu generischen Zugangsdatentypen wie privaten Schlüsseln und benutzerdefinierten Token. Teams, die diesen Ansatz verwenden, übersehen fast die Hälfte ihrer gefährlichsten Leaks, während sie Behebungsaufwand für Zugangsdaten mit geringem Risiko verbrennen. Effektive Priorisierung erfordert kontextuelle Risikobewertung, nicht nur eine Gültigkeitsprüfung.

Was ist NHI-Governance und warum ist sie wichtig?

Non-Human Identity (NHI)-Governance ist die Praxis, den vollständigen Lebenszyklus von Maschinenidentitäten — Service-Accounts, API-Schlüssel, Agent-Token und andere nicht-menschliche Zugangsdaten — mit derselben Strenge zu verwalten, die auf menschliche Benutzerkonten angewendet wird. Sie beantwortet drei Fragen: Welche NHIs existieren in der Umgebung, wem gehören sie und worauf können sie zugreifen. Da KI-gestützte Entwicklung die Erstellung von Zugangsdaten beschleunigt, ist NHI-Governance die Disziplin, die verhindert, dass die Erstellungsgeschwindigkeit die Sicherheitslage dauerhaft überholt.

OAuth-Token-Diebstahl und Credential-Angriffe: Rückblick April 2026

APT28 entführte 18.000 Router, um OAuth-Token zu stehlen. Storm-2372 umging MFA, ohne ein Passwort zu berühren. 28,6 Millionen Secrets wurden auf GitHub geleakt. Die größten Vorfälle im April 2026 — und was sie gemeinsam haben.

Passwork BlogAlex Muntyan

Einblick in echte Supply-Chain-Angriffe: Bitwarden CLI, Axios und Vercel

Warum Ihr Netzwerk angreifen, wenn Angreifer eine vertrauenswürdige Abhängigkeit mit Millionen von Downloads kompromittieren und still in Tausende von Organisationen gleichzeitig eindringen können? Drei Kampagnen aus 2026 beweisen, dass Supply-Chain-Angriffe keine Einzelfälle mehr sind.

Passwork BlogAlex Muntyan

Passwort-Chaos: Warum es ein Geschäftsproblem ist und wie Sie es beheben

Ein vergessenes Passwort kostet 70 Dollar. Ein Breach kostet 4,44 Millionen Dollar. Beides beginnt gleich — Zugangsdaten, die über Slack geteilt, in Tabellen gespeichert, nie rotiert werden. Hier erfahren Sie, was Passwort-Chaos tatsächlich kostet und wie Sie es eliminieren.

Passwork BlogAlex Muntyan