Secrets management

Ein Entwickler muss schnell eine Datenbankverbindung testen. Er fügt das Passwort direkt in die Konfigurationsdatei ein, pusht den Commit und macht weiter. Das Feature wird ausgeliefert. Das Passwort bleibt bestehen. Sechs Monate später wird das Repository geforkt, die CI/CD-Logs werden indexiert, und diese Anmeldedaten befinden sich an drei Stellen, die niemand überwacht.

So gelangen die meisten hartcodierten Secrets in die freie Wildbahn – durch Bequemlichkeit, die ihren Kontext überdauert. GitGuardian fand 28,65 Millionen neue hartcodierte Secrets, die 2025 zu öffentlichen GitHub-Repositories hinzugefügt wurden – ein Anstieg von 34 % im Jahresvergleich und ein Zuwachs von 152 % seit 2021.

Wichtige Erkenntnisse

• Hartcodierte Secrets sind Anmeldedaten, die direkt in Quellcode, Konfigurationen, Skripte oder Anwendungspakete eingebettet sind – statische Werte, die zur Entwicklungszeit geschrieben werden, anstatt zur Laufzeit aus einer sicheren Quelle injiziert zu werden.
• Private Repositories sind kein sicherer Ort für Secrets. Kompromittierte Entwicklerkonten, CI/CD-Integrationen, Forks und Backups erweitern die Angriffsfläche weit über das hinaus, was „privat" impliziert.
• KI-gestützte Entwicklung verschärft das Problem. Commits von KI-Codierungstools enthalten doppelt so häufig Secrets. Leaks von Anmeldedaten für KI-Dienste stiegen 2025 um 81 % im Jahresvergleich.
• Das Löschen der Zeile reicht nicht aus. Ein einmal committetes Secret verbleibt in der Git-Historie, in Forks, CI/CD-Logs und lokalen Klonen. Rotation oder Widerruf kommen zuerst. Das Entfernen ist der Bereinigungsschritt.
• Die Erkennung muss kontinuierlich und mehrstufig erfolgen. IDE-Plugins fangen Secrets vor dem Commit ab; CI/CD-Scanning erfasst, was durchrutscht; repositoryweite Scans decken historische Expositionen auf. Jede Ebene hat blinde Flecken. Keine davon funktioniert ohne einen definierten Verantwortlichen und einen Triage-Prozess für jeden Fund.
• Die Ursache ist Workflow-Reibung, nicht Nachlässigkeit. Entwickler hartcodieren Secrets, wenn es keine schnellere, genehmigte Alternative gibt. Prävention bedeutet, diese Reibung zu beseitigen – nicht nur Scanner hinzuzufügen.
• Jeder Anmeldedatentyp benötigt einen designierten Speicherort. Maschinen-Secrets gehören in einen Vault oder Secrets-Manager mit Laufzeit-Injection. Menschliche und geteilte Anmeldedaten gehören in einen Unternehmens-Passwort-Manager mit Zugriffskontrollen und Audit-Trails. Anmeldedaten ohne designierten Speicherort landen im Code.

Was sind hartcodierte Secrets?

Hartcodierte Secrets sind Passwörter, API-Schlüssel, Tokens, private Schlüssel oder andere Anmeldedaten, die direkt in Quellcode, Skripte, Konfigurationsdateien oder Anwendungspakete geschrieben werden. Es sind statische Werte, die zur Schreibzeit eingebettet werden, anstatt zur Laufzeit aus einer sicheren Quelle injiziert zu werden. MITRE klassifiziert diese Schwachstelle als CWE-798: Use of Hard-coded Credentials und bewertet die Exploit-Wahrscheinlichkeit als hoch.

Die OWASP-Community-Seite zur Verwendung von hartcodierten Passwörtern behandelt die passwortspezifische Variante, aber der volle Umfang hartcodierter Secrets geht weit über Passwörter hinaus.

Wo tauchen hartcodierte Secrets normalerweise auf?

Hartcodierte Secrets erscheinen überall dort, wo Code geschrieben, gebaut, gespeichert oder bereitgestellt wird – eine weitaus größere Angriffsfläche, als den meisten Teams bewusst ist.

In der Codebasis und Versionskontrolle:

• Anwendungsquellcode und Inline-Kommentare
• Konfigurationsdateien (.properties, .yaml, .json, .xml)
• Versehentlich committete lokale Entwicklungsdateien (.env, .env.local)
• Infrastructure-as-Code-Vorlagen (Terraform, Ansible, CloudFormation)

In Build- und Deployment-Systemen:

• CI/CD-Pipeline-Definitionsdateien mit inline geschriebenen Anmeldedaten
• Build-Logs und Artefakte, die Umgebungswerte ausgeben
• Container-Images mit in Schichten eingebauten Secrets

In verteilten und eingebetteten Systemen:

• Mobile Apps und clientseitige JavaScript-Bundles
• Firmware, IoT-Geräte, Router und eingebettete Controller

In informeller Ablage:

• Dokumentation, interne Wikis und README-Dateien
• Support-Tickets, Jira-Vorgänge und Confluence-Seiten
• Slack-Exporte, E-Mail-Threads und geteilte Tabellenkalkulationen

Ein Hinweis zu .env-Dateien: Sie sind sicherer als das direkte Schreiben von Werten in den Code, aber nur wenn sie von der Versionskontrolle ausgeschlossen, lokal geschützt und niemals in Logs oder Build-Artefakte kopiert werden. Eine einmal committete .env-Datei ist ein hartcodiertes Secret.

Warum hartcodieren Entwickler Secrets?

Die Ursache ist fast nie Nachlässigkeit. Es ist Workflow-Reibung.

1. Schnelles lokales Testen. Das Hartcodieren eines Wertes dauert zehn Sekunden. Das Einrichten einer Vault-Referenz dauert länger, besonders ohne eine Standardvorlage.
2. Vermeidung von Konfigurationsabweichungen. Wenn Entwicklungs-, Staging- und Produktionsumgebungen inkonsistent verwaltet werden, hartcodieren Entwickler manchmal Werte, um sicherzustellen, dass die richtigen Anmeldedaten das richtige System erreichen.
3. Kopieren aus Dokumentation oder Beispielen. Offizielle Dokumentationen und Stack-Overflow-Antworten zeigen häufig Anmeldedaten als Platzhalter. Diese Platzhalter werden durch echte Werte ersetzt und committet.
4. KI-generierter Code. Coding-Assistenten können unsichere Muster aus Trainingsdaten reproduzieren oder Platzhalter-Anmeldedaten einfügen, die funktional aussehen. Das Risiko ist am höchsten, wenn generierter Code die normale Sicherheitsüberprüfung umgeht oder wenn ein Entwickler einen Platzhalter durch einen echten Wert ersetzt, ohne ihn an eine sichere Quelle zu verschieben.
5. Kein standardisierter Secret-Management-Workflow. Wenn es keine genehmigte Methode gibt, Secrets lokal zu handhaben, erfinden Entwickler ihre eigene – und Bequemlichkeit gewinnt meist.
6. Fehlende Pre-Commit-Prüfungen. Ohne automatisierte Gates kann ein hartcodiertes Secret mit einem einzigen Push vom Editor eines Entwicklers in ein geteiltes Repository gelangen.
7. Unklare Eigentümerschaft von Dienstkonten und geteilten Anmeldedaten. Wenn niemand für Anmeldedaten verantwortlich ist, verwaltet sie auch niemand sicher.

Warum sind hartcodierte Secrets so riskant?

Die Zahlen machen den Trend schwer ignorierbar. GitGuardian verfolgte ~11 Millionen neue hartcodierte Secrets auf öffentlichem GitHub in 2021; bis 2025 erreichte diese Zahl 28.649.024 – ein Anstieg von 152 % in vier Jahren.

Erkennung allein schließt die Lücke nicht: 64 % der 2022 als gültig bestätigten Secrets waren 2026 noch aktiv und ausnutzbar. Hartcodierte Secrets sind kein Altlastproblem, das schrittweise gelöst wird – die Angriffsfläche wächst schneller, als die Behebung mithalten kann.

Private Repositories sind kein sicherer Ort für Secrets. Der Repository-Zugriff ist oft breiter als Administratoren annehmen. CI/CD-Tools, Backup-Systeme, Entwickler-Endpunkte, Drittanbieter-Integrationen und Forks erweitern alle die Angriffsfläche. Ein kompromittiertes Entwicklerkonto reicht aus, um jedes Secret in jedem privaten Repository zu extrahieren, das dieses Konto lesen kann.

Verizons 2025 DBIR stellte auch fest, dass Web-Anwendungsinfrastruktur 39 % der offengelegten Secrets in öffentlichen Git-Repositories ausmachte, und 66 % davon waren JWTs. Generische Secrets – die Kategorie, die am schwersten mit Pattern-Matching-Tools zu erkennen ist – machten laut GitGuardian 58 % aller geleakten Anmeldedaten im Jahr 2024 aus.

Passwork ist ein Unternehmens-Passwort- und Secrets-Manager: API-Schlüssel, Tokens, SSH-Schlüssel und Admin-Anmeldedaten – alles in verschlüsselten Tresoren mit rollenbasiertem Zugriff und Audit-Logs, nicht im Code oder in Chat-Threads. Passwork entdecken

Was sollten Sie tun, wenn ein hartcodiertes Secret gefunden wird?

Der Instinkt, die Zeile zu löschen und einen Fix-Commit zu pushen, ist verständlich. Er ist aber auch unzureichend. Sobald ein Secret committet ist, gehen Sie davon aus, dass es irgendwo kopiert, gecacht, geloggt oder indexiert wurde, wo Sie nicht heranreichen.

Incident-Response-Workflow

1. Klassifizieren Sie das Secret. Bestimmen Sie, ob es sich um ein Passwort, einen API-Schlüssel, ein Token, einen privaten Schlüssel, ein Zertifikat oder eine Verbindungszeichenkette handelt.
2. Identifizieren Sie den Eigentümer und den Umfang. Finden Sie heraus, welches System, welche Umgebung, welche Privilegienstufe und welches Konto das Secret kontrolliert.
3. Widerrufen oder rotieren Sie sofort. Behandeln Sie den Wert ab dem Moment des Commits oder der Exposition als kompromittiert.
4. Überprüfen Sie Zugriffsprotokolle. Suchen Sie nach verdächtigen Aktivitäten vor und nach dem Expositionsfenster.
5. Entfernen Sie es aus der Codebasis. Ersetzen Sie den hartcodierten Wert durch eine Referenz zu einer sicheren Quelle.
6. Bereinigen Sie die Repository-Historie bei Bedarf. Verwenden Sie genehmigte Tools wie git filter-repo oder BFG Repo-Cleaner und koordinieren Sie sich mit den Repository-Eigentümern – das Umschreiben der Historie betrifft alle Mitarbeiter.
7. Aktualisieren Sie abhängige Systeme. Bestätigen Sie, dass alle Anwendungen, Jobs und Integrationen den neuen Wert verwenden.
8. Dokumentieren Sie den Vorfall. Erfassen Sie Ursache, Eigentümer, Behebungszeit und welche Kontrolle ein Wiederauftreten verhindern wird.
9. Fügen Sie eine Präventionskontrolle hinzu. Pre-Commit-Hooks, CI/CD-Scanning, Richtlinien-Updates oder Zugriffsüberprüfung – mindestens eine konkrete Änderung vor Abschluss des Vorfalls.

Wie können Organisationen hartcodierte Secrets erkennen?

Einmaliges Scanning reicht nicht aus. Secrets gelangen kontinuierlich in Codebasen, und die Erkennung muss diesem Tempo entsprechen.

Der Verizon 2025 DBIR stellte fest, dass die mediane Zeit zur Behebung entdeckter geleakter Secrets auf GitHub 94 Tage betrug. Diese Lücke besteht, weil Erkennung ohne Eigentümerschaft und Triage-SLAs zu Alarm-Müdigkeit führt, nicht zu Handlung. Jedes erkannte Secret benötigt einen benannten Eigentümer und einen definierten Reaktionspfad.

Wie können Teams hartcodierte Secrets verhindern?

Prävention ist ein mehrschichtiges Problem. Keine einzelne Kontrolle ist für sich allein ausreichend.

Die meisten Organisationen verwalten letztendlich beide Kategorien: Maschinen-Secrets für Anwendungen und Pipelines sowie menschliche Anmeldedaten für geteilte Admin-Konten, Team-Zugriff und operative Workflows. Sie in separaten, unverbundenen Systemen zu halten, schafft eigene Probleme – inkonsistente Zugriffsrichtlinien, doppelte Audit-Trails und Anmeldedaten, die durch die Lücke zwischen den Tools fallen. Passwork deckt beides in einer einzigen Plattform ab, unter einem Zugriffsmodell und einem Audit-Log.

Zwei Anmeldedaten-Kategorien, ein Ort für ihre Verwaltung

Die folgende Tabelle zeigt, wohin jeder Anmeldedatentyp gehört.

Das Ziel ist sicherzustellen, dass jede Anmeldedaten in einem System lebt, das für ihre tatsächliche Verwendung konzipiert ist. Für die meisten Teams bedeutet das eine Plattform, die beide Kategorien handhabt – nicht zwei separate Tools mit separaten Zugriffsmodellen und separaten Audit-Trails. Das ist die Lücke, die Passwork füllt.

Wie Passwork hartcodierte Secrets über den gesamten Stack eliminiert

Hartcodierte Secrets erscheinen, wenn Teams keinen bequemen, zuverlässigen Ort haben, um Anmeldedaten zu speichern und zur Laufzeit abzurufen. Passwork beseitigt diese Lücke. Es handhabt jeden Anmeldedatentyp, den eine Organisation verwaltet – Benutzerpasswörter, geteilte Admin-Konten, API-Schlüssel, Datenbank-Verbindungszeichenketten, SSH-Schlüssel, TLS-Zertifikate und CI/CD-Tokens – mit der Speicherung, Zugriffskontrolle und dem Audit-Trail, die jede Kategorie erfordert.

Derselbe Tresor, in dem ein Betriebsteam Admin-Passwörter speichert, ist dasselbe System, das eine Deployment-Pipeline nach einer Datenbank-Verbindungszeichenkette abfragt. Ein Zugriffsmodell, ein Audit-Log, ein Rotations-Workflow.

Secrets speichern, damit sie nie hartcodiert werden müssen

Passwork organisiert Anmeldedaten in einer strukturierten Tresor-Hierarchie. Teams ordnen Secrets nach Umgebung und Kategorie – infrastructure/production/databases, services/stripe, servers/ssh-keys – und jede Ebene trägt unabhängige Zugriffskontrollen. Ein Secret im richtigen Tresor hat einen benannten Eigentümer, ein Umgebungs-Tag und einen definierten Satz von Konsumenten. Secrets ohne Eigentümer sind diejenigen, die letztendlich in Repositories committet werden.

Benutzerdefinierte Felder unterstützen benannte Secrets direkt: AWS_SECRET_KEY, STRIPE_SECRET, REDIS_AUTH, OAUTH_CLIENT_SECRET. Diese Benennung fließt in den CLI- und SDK-Abruf ein, macht den Tresor selbstdokumentierend und eliminiert die Konfigurationsverwirrung, die Entwickler dazu bringt, einen Wert „nur fürs Erste" hartzucodieren.

CLI-Injection: Die direkte Alternative zu hartcodierten Umgebungsvariablen

passwork-cli exec führt jeden Befehl mit als Umgebungsvariablen injizierten Secrets aus, nur für die Dauer dieses Befehls. Die Anmeldedaten erscheinen nicht in der Shell-Historie, werden nicht auf die Festplatte geschrieben und bleiben nach dem Beenden des Kindprozesses nicht bestehen.

# Run deploy script — secrets exist only for the duration of this command
passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" ./deploy.sh

Dies ersetzt die .env-Datei, die in ein Repository committet wurde, den hartcodierten Wert, der aus einer Chat-Nachricht eingefügt wurde, und die Umgebungsvariable, die in der CI-Ausgabe gedruckt wird. Die Anwendung liest ihre Konfiguration wie vorgesehen aus der Umgebung; der Unterschied ist, woher diese Werte kommen.

Für einen einzelnen Wert in einem Shell-Skript:

DB_PASS=$(passwork-cli get --password-id "$ITEM_ID")
# DB_PASS is available in this shell, never written to disk

Für die Rotation – Aktualisierung der Anmeldedaten nach deren Änderung im Zielsystem:

passwork-cli update --password-id "$ITEM_ID" --password "$NEW_PASS"

Die CLI handhabt Entschlüsselung und Neuverschlüsselung lokal. Passworks Server speichert nur Chiffretext. Selbst eine vollständige Server-Kompromittierung liefert nichts Lesbares.

CI/CD-Integration ohne Hartcodierung von Pipeline-Tokens

CI/CD-Pipelines sind eine Hauptquelle für hartcodierte Secrets – Tokens und Verbindungszeichenketten, die direkt in Pipeline-Dateien committet werden, weil es keine bessere Option gab. Passwork bietet diese Option.

Das Docker-Image passwork/passwork-cli läuft als Job-Image in GitLab CI, GitHub Actions und Bitbucket Pipelines. Die Pipeline speichert nur drei Bootstrap-Anmeldedaten im Secret-Speicher der CI-Plattform: PASSWORK_HOST, PASSWORK_TOKEN und PASSWORK_MASTER_KEY. Alles andere lebt in Passwork.

# GitLab CI — no credentials in the pipeline file
deploy_prod:
  image: passwork/passwork-cli:latest
  script:
    - passwork-cli exec --folder-id "$SECRETS_FOLDER_ID" ./deploy.sh

# GitHub Actions — credentials injected from platform secrets only
- name: Deploy with secrets
  run: |
    docker run --rm \
      -e PASSWORK_HOST="${{ secrets.PASSWORK_HOST }}" \
      -e PASSWORK_TOKEN="${{ secrets.PASSWORK_TOKEN }}" \
      -e PASSWORK_MASTER_KEY="${{ secrets.PASSWORK_MASTER_KEY }}" \
      passwork/passwork-cli:latest \
      exec --folder-id "${{ vars.SECRETS_FOLDER_ID }}" ./deploy.sh

Für Kubernetes unterstützt Passwork einen Init-Container, der Secrets abruft, bevor die Hauptanwendung startet, und einen Sidecar, der sie nach der Rotation aktualisiert – ohne den Pod neu zu starten.

Dienstkonten: Maschinenidentität ohne Ausbreitung von Anmeldedaten

Jede CI/CD-Pipeline oder jedes Automatisierungsskript, das auf Passwork zugreift, verwendet ein dediziertes Dienstkonto mit eigener Rolle, eigenem Token-Paar und Zugriff nur auf die Tresore, die es tatsächlich benötigt. Eine Deployment-Pipeline erhält Nur-Lese-Zugriff auf Produktions-Secrets. Ein Rotationsskript erhält Lese-Schreib-Zugriff auf den Datenbank-Ordner. Wenn eine Pipeline außer Betrieb genommen wird, wird ihr Dienstkonto entfernt.

API-Tokens haben konfigurierbare Lebensdauern. Für einen CI/CD-Job, der minutenlang läuft, lebt das Zugriffstoken 15-60 Minuten. Für einen immer aktiven Rotationsdienst läuft das Zugriffstoken 1-4 Stunden und das Refresh-Token 30 Tage. Die Token-Paar-Rotation erfolgt programmatisch über POST /api/v1/sessions/refresh, sodass die Bootstrap-Anmeldedaten nie dauerhaft langlebig werden.

Zugriffskontrolle, die abbildet, wie Teams tatsächlich arbeiten

Passworks Berechtigungsmodell funktioniert sowohl auf Tresor- als auch auf Ordnerebene. Berechtigungen werden im Ordnerbaum vererbt, können aber auf jeder Ebene überschrieben werden. Das Plattform-Team hat vollständigen Zugriff auf infrastructure/production. Entwickler greifen auf infrastructure/development zu. Das CI/CD-Dienstkonto erhält Nur-Lese-Zugriff auf den benötigten Produktionsordner.

Rollenbasierter Zugriff, Gruppen und AD/LDAP-Synchronisierung bedeuten, dass wenn ein Ingenieur einem Team beitritt, er den Tresor-Zugriff der Gruppe erbt. Wenn er geht, wird der Zugriff einmal entfernt. Das Sicherheits-Dashboard markiert Anmeldedaten als kompromittiert, wenn sie nach dem Widerruf des Benutzerzugriffs nicht rotiert wurden – direkte Erkennung des Fehlermodus, der aktive exponierte Secrets produziert.

Passwort-Komplexitätsrichtlinien setzen Mindestanforderungen für Masterpasswörter und Authentifizierungspasswörter durch. Kontosperrungsrichtlinien begrenzen fehlgeschlagene Anmeldeversuche. SAML SSO bindet den Tresor-Zugriff an den bestehenden Identity-Provider, sodass die Passwork-Authentifizierung demselben Lebenszyklus wie jedes andere Unternehmenssystem folgt.

Audit-Trail und Zero-Knowledge-Architektur

Jeder Lese-, Schreib- und Berechtigungsänderungs-Vorgang wird aufgezeichnet: welches Konto, welche Anmeldedaten, welche Aktion, zu welchem Zeitstempel. Dienstkonten erscheinen im Log unter ihrer eigenen Identität. Das Log wird im CEF-Format für SIEM-Integration exportiert, sodass Passworks Zugriffshistorie in dieselbe Sicherheitsüberwachungsplattform wie Netzwerk- und Endpunkt-Ereignisse einfließt.

Verschlüsselung und Entschlüsselung erfolgen auf dem Client – im Browser, in passwork-cli oder im SDK. Der Server speichert nur Chiffretext. Passwork-Administratoren und Datenbankbetreiber haben keine technische Möglichkeit, gespeicherte Secrets zu lesen, selbst mit direktem Datenbankzugriff. Bei selbst gehosteten Bereitstellungen transitieren verschlüsselte Anmeldedaten niemals ein Drittanbietersystem. Passwork ist ISO 27001-zertifiziert und konform mit DSGVO und NIS2.

Checkliste zur Prävention hartcodierter Secrets

Fazit

Hartcodierte Secrets sind eine vermeidbare Form der Exposition von Anmeldedaten. Die technischen Kontrollen existieren: Secrets-Manager, Pre-Commit-Hooks, CI/CD-Scanning, kurzlebige Anmeldedaten und Zugriff nach minimalen Berechtigungen. Der schwierigere Teil ist der Aufbau des Workflows, der sichere Praktiken zum Weg des geringsten Widerstands für jeden Entwickler bei jedem Commit macht.

Die vollständige Verteidigung ist mehrschichtig. Sichere Speicherung für Maschinen-Secrets. Scanning in jeder Phase der Pipeline. Rotationsrichtlinien mit definierten Eigentümern und SLAs. Entwickler-Workflow-Vorlagen, die die Reibung beseitigen, die zu Abkürzungen führt. Und Zugriffs-Governance für die menschlichen Anmeldedaten, die außerhalb des Anwendungscodes leben – die geteilten Admin-Passwörter, Dienstkonto-Anmeldedaten und Team-Zugriffstokens, die dazu neigen, sich über informelle Kanäle zu verbreiten, wenn keine bessere Option existiert.

Passwork gibt Teams ein einziges System zur Speicherung, zum Zugriff, zur Rotation und zur Prüfung jedes Anmeldedatentyps. Entwickler rufen Secrets zur Laufzeit ab, anstatt sie in Code einzufügen. Pipelines ziehen aus einem Vault, anstatt aus committeten Dateien zu lesen. Betriebsmitarbeiter verwalten geteilte Admin-Passwörter auf derselben Plattform, auf der DevOps Infrastruktur-Secrets handhabt. Wenn Anmeldedaten in einem Repository gefunden werden, beginnt die Reaktion in Passwork: den alten Wert widerrufen, den neuen generieren, abhängige Systeme aktualisieren und über das Audit-Log bestätigen, dass die alten Anmeldedaten nicht mehr verwendet werden.

Wenn Ihr Team weiterhin Service-, Admin- oder Projekt-Passwörter über informelle Kanäle teilt, beginnen Sie damit, sie in Passwork zu zentralisieren und zu definieren, wer jede Anmeldedaten abrufen, rotieren und überprüfen darf. Diese einzelne Änderung beseitigt eine Risikokategorie, die kein Code-Scanning erfassen wird. Passwork kostenlos testen

Häufig gestellte Fragen

Was ist ein Beispiel für ein hartcodiertes Secret?

Ein Datenbank-Passwort, das direkt in eine Quelldatei geschrieben wurde, ein AWS-Zugriffsschlüssel in einer .yaml-Konfiguration, ein privater SSH-Schlüssel in einem Deployment-Skript oder ein JWT-Signatur-Secret im Anwendungscode. Jede Anmeldedaten, die als statischer Wert in Code, einer Konfigurationsdatei, einem Skript oder einem kompilierten Anwendungspaket eingebettet ist, qualifiziert als hartcodiertes Secret.

Sind hartcodierte Secrets dasselbe wie hartcodierte Passwörter?

Hartcodierte Passwörter sind eine Art von hartcodierten Secrets. Die breitere Kategorie umfasst auch API-Schlüssel, OAuth-Tokens, SSH-Schlüssel, private Zertifikate, TLS-Schlüsselmaterial, Verschlüsselungsschlüssel und Datenbank-Verbindungszeichenketten. MITREs CWE-798 deckt die gesamte Klasse unter „Verwendung von hartcodierten Anmeldedaten" ab.

Ist es sicher, Secrets in privaten Repositories zu speichern?

Nein. Private Repositories reduzieren die öffentliche Exposition, machen Secrets aber nicht sicher. Der Zugriff steht oft vielen Entwicklern, automatisierten Tools und Integrationen zur Verfügung. Kompromittierte Entwicklerkonten, falsch konfigurierte Berechtigungen, CI/CD-Pipelines, Backups, Forks und lokale Klone erweitern alle die Angriffsfläche über das hinaus, was „privat" impliziert.

Reicht es aus, ein hartcodiertes Secret aus dem Code zu löschen?

Nein. Wenn das Secret committet wurde, kann es weiterhin in der Git-Historie, in Forks, CI/CD-Logs, Build-Artefakten, lokalen Klonen und Backups existieren. Rotieren oder widerrufen Sie die Anmeldedaten zuerst. Entfernen Sie sie dann aus der Codebasis und bereinigen Sie die Repository-Historie, wenn der Umfang der Exposition dies erfordert.

Reichen Umgebungsvariablen aus, um hartcodierte Secrets zu verhindern?

Umgebungsvariablen helfen, Konfiguration vom Code zu trennen, sind aber keine vollständige Kontrolle. Teams benötigen weiterhin sichere Speicherung für diese Werte, Zugriffskontrollen, Rotationsrichtlinien und Schutz vor Leaks in Logs oder Build-Artefakten. Umgebungsvariablen reduzieren das Risiko von Secrets in Quelldateien; sie ersetzen keine Secrets-Management-Strategie.

Wie lange bleiben geleakte Secrets typischerweise aktiv?

Laut GitGuardians State of Secrets Sprawl 2026-Bericht waren 64 % der 2022 als gültig bestätigten Secrets 2026 noch aktiv und ausnutzbar. Der Verizon 2025 DBIR fand eine mediane Behebungszeit von 94 Tagen für entdeckte Secrets auf GitHub. Lange Lebensdauern von Anmeldedaten sind der Hauptgrund, warum ein einziges geleaktes Secret anhaltenden Schaden verursachen kann.

Lebenszyklus der Secrets-Rotation: Von der Erstellung bis zum Widerruf

Die Rotation von Secrets scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden deckt alle sieben Phasen ab – von der Erstellung und Eigentümerschaft bis zur sicheren Rotation, Notfallwiderruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

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

28,65 Millionen Secrets wurden 2025 auf öffentlichem GitHub geleakt. KI beschleunigt das Problem. Interne Repos sind 6× stärker exponiert als öffentliche. Und 64 % der Secrets von 2022 sind heute noch gültig. Hier erfahren Sie, was die Daten für Ihre Sicherheitslage bedeuten.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Typen, Beispiele und Prävention

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute-Force hat sich skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute umsetzen kann.

Passwork BlogAlex Muntyan

Un desarrollador necesita probar rápidamente una conexión a la base de datos. Pega la contraseña directamente en el archivo de configuración, hace el commit y continúa. La funcionalidad se despliega. La contraseña permanece. Seis meses después, el repositorio se bifurca, los logs de CI/CD se indexan y esa credencial está en tres lugares que nadie monitorea.

Así es como la mayoría de los secretos codificados llegan al exterior — a través de la conveniencia que perdura más allá de su contexto. GitGuardian encontró 28,65 millones de nuevos secretos codificados añadidos a repositorios públicos de GitHub en 2025, un aumento del 34% interanual y un incremento del 152% desde 2021.

Puntos clave

• Los secretos codificados son credenciales incrustadas directamente en código fuente, configuraciones, scripts o paquetes de aplicaciones — valores estáticos escritos en tiempo de desarrollo en lugar de inyectados en tiempo de ejecución desde una fuente segura.
• Los repositorios privados no son un lugar seguro para secretos. Las cuentas de desarrollador comprometidas, las integraciones de CI/CD, las bifurcaciones y las copias de seguridad amplían la superficie de exposición más allá de lo que implica «privado».
• El desarrollo asistido por IA está empeorando el problema. Los commits de herramientas de codificación con IA tienen el doble de probabilidad de contener secretos. Las filtraciones de credenciales de servicios de IA crecieron un 81% interanual en 2025.
• Eliminar la línea no es suficiente. Un secreto confirmado persiste en el historial de Git, las bifurcaciones, los logs de CI/CD y los clones locales. La rotación o revocación es lo primero. La eliminación es el paso de limpieza.
• La detección debe ser continua y en capas. Los plugins de IDE detectan secretos antes del commit; el escaneo de CI/CD detecta lo que se escapa; los escaneos de todo el repositorio revelan la exposición histórica. Cada capa tiene puntos ciegos. Ninguna funciona sin un propietario definido y un proceso de triaje para cada hallazgo.
• La causa raíz es la fricción del flujo de trabajo, no el descuido. Los desarrolladores codifican secretos cuando no hay una alternativa aprobada más rápida. La prevención significa eliminar esa fricción — no solo añadir escáneres.
• Cada tipo de credencial necesita un hogar designado. Los secretos de máquinas pertenecen a una bóveda o gestor de secretos con inyección en tiempo de ejecución. Las credenciales humanas y compartidas pertenecen a un gestor de contraseñas corporativo con controles de acceso y registros de auditoría. Las credenciales que no tienen un hogar designado terminan en el código.

¿Qué son los secretos codificados?

Los secretos codificados son contraseñas, claves API, tokens, claves privadas u otras credenciales escritas directamente en código fuente, scripts, archivos de configuración o paquetes de aplicaciones. Son valores estáticos incrustados en tiempo de escritura en lugar de inyectados en tiempo de ejecución desde una fuente segura. MITRE clasifica esta vulnerabilidad como CWE-798: Use of Hard-coded Credentials y califica su probabilidad de explotación como alta.

La página de la comunidad OWASP sobre el uso de contraseñas codificadas cubre la variante específica de contraseñas, pero el alcance completo de los secretos codificados se extiende mucho más allá de las contraseñas.

¿Dónde suelen aparecer los secretos codificados?

Los secretos codificados aparecen dondequiera que se escriba, compile, almacene o despliegue código — una superficie mucho mayor de lo que la mayoría de los equipos se dan cuenta.

En el código base y control de versiones:

• Código fuente de aplicaciones y comentarios en línea
• Archivos de configuración (.properties, .yaml, .json, .xml)
• Archivos de desarrollo local (.env, .env.local) confirmados por error
• Plantillas de infraestructura como código (Terraform, Ansible, CloudFormation)

En sistemas de compilación y despliegue:

• Archivos de definición de pipelines CI/CD con credenciales escritas en línea
• Logs de compilación y artefactos que muestran valores de entorno
• Imágenes de contenedores con secretos incorporados en las capas

En sistemas distribuidos e integrados:

• Aplicaciones móviles y paquetes de JavaScript del lado del cliente
• Firmware, dispositivos IoT, routers y controladores integrados

En almacenamiento informal:

• Documentación, wikis internas y archivos README
• Tickets de soporte, issues de Jira y páginas de Confluence
• Exportaciones de Slack, hilos de correo electrónico y hojas de cálculo compartidas

Una nota sobre los archivos .env: son más seguros que escribir valores directamente en el código, pero solo si se excluyen del control de versiones, se protegen localmente y nunca se copian en logs o artefactos de compilación. Un archivo .env confirmado una vez es un secreto codificado.

¿Por qué los desarrolladores codifican secretos?

La causa raíz casi nunca es el descuido. Es la fricción del flujo de trabajo.

1. Pruebas locales rápidas. Codificar un valor lleva diez segundos. Configurar una referencia a una bóveda lleva más tiempo, especialmente sin una plantilla estándar.
2. Evitar la deriva de configuración. Cuando los entornos de desarrollo, staging y producción se gestionan de forma inconsistente, los desarrolladores a veces codifican valores para garantizar que la credencial correcta llegue al sistema correcto.
3. Copiar de documentación o ejemplos. Los documentos oficiales y las respuestas de Stack Overflow frecuentemente muestran credenciales como marcadores de posición. Esos marcadores se reemplazan con valores reales y se confirman.
4. Código generado por IA. Los asistentes de codificación pueden reproducir patrones inseguros de los datos de entrenamiento o insertar credenciales de marcador de posición que parecen funcionales. El riesgo es mayor cuando el código generado evita la revisión de seguridad normal o cuando un desarrollador reemplaza un marcador de posición con un valor real sin moverlo a una fuente segura.
5. Sin flujo de trabajo estándar de gestión de secretos. Cuando no hay una forma aprobada de manejar secretos localmente, los desarrolladores inventan la suya propia — y la conveniencia generalmente gana.
6. Falta de verificaciones pre-commit. Sin puertas automatizadas, un secreto codificado puede viajar desde el editor de un desarrollador a un repositorio compartido en un solo push.
7. Propiedad poco clara de cuentas de servicio y credenciales compartidas. Cuando nadie es propietario de una credencial, nadie la gestiona de forma segura.

¿Por qué son tan peligrosos los secretos codificados?

Los números hacen difícil ignorar la tendencia. GitGuardian rastreó ~11 millones de nuevos secretos codificados en GitHub público en 2021; para 2025 esa cifra había alcanzado 28.649.024 — un aumento del 152% en cuatro años.

La detección por sí sola no está cerrando la brecha: el 64% de los secretos confirmados como válidos en 2022 seguían activos y explotables en 2026. Los secretos codificados no son un problema heredado que se está resolviendo gradualmente — la superficie de exposición está creciendo más rápido de lo que la remediación puede mantener el ritmo.

Los repositorios privados no son un lugar seguro para secretos. El acceso al repositorio a menudo es más amplio de lo que los administradores se dan cuenta. Las herramientas de CI/CD, los sistemas de respaldo, los endpoints de desarrolladores, las integraciones de terceros y las bifurcaciones amplían la superficie de exposición. Una cuenta de desarrollador comprometida es suficiente para extraer cada secreto de cada repositorio privado que esa cuenta pueda leer.

El DBIR 2025 de Verizon también encontró que la infraestructura de aplicaciones web representaba el 39% de los secretos divulgados en repositorios públicos de Git, y el 66% de esos eran JWTs. Los secretos genéricos — la categoría más difícil de detectar con herramientas de coincidencia de patrones — representaron el 58% de todas las credenciales filtradas en 2024, según GitGuardian.

Passwork es un gestor corporativo de contraseñas y secretos: claves API, tokens, claves SSH y credenciales de administrador — todo en bóvedas cifradas con acceso basado en roles y registros de auditoría, no en código o hilos de chat. Explorar Passwork

¿Qué debe hacer si se encuentra un secreto codificado?

El instinto de eliminar la línea y hacer un commit de corrección es comprensible. También es insuficiente. Una vez que un secreto se confirma, asuma que ha sido copiado, almacenado en caché, registrado o indexado en algún lugar que no puede alcanzar.

Flujo de trabajo de respuesta a incidentes

1. Clasifique el secreto. Determine si es una contraseña, clave API, token, clave privada, certificado o cadena de conexión.
2. Identifique el propietario y el alcance. Encuentre qué sistema, entorno, nivel de privilegio y cuenta controla el secreto.
3. Revoque o rote inmediatamente. Trate el valor como comprometido desde el momento en que fue confirmado o expuesto.
4. Verifique los logs de acceso. Busque actividad sospechosa antes y después de la ventana de exposición.
5. Elimínelo del código base. Reemplace el valor codificado con una referencia a una fuente segura.
6. Limpie el historial del repositorio si es necesario. Use herramientas aprobadas como git filter-repo o BFG Repo-Cleaner, y coordine con los propietarios del repositorio — reescribir el historial afecta a todos los colaboradores.
7. Actualice los sistemas dependientes. Confirme que todas las aplicaciones, trabajos e integraciones estén usando el nuevo valor.
8. Documente el incidente. Registre la causa raíz, el propietario, el tiempo de remediación y qué control prevendrá la recurrencia.
9. Añada un control de prevención. Hooks pre-commit, escaneo de CI/CD, actualizaciones de políticas o revisión de acceso — al menos un cambio concreto antes de cerrar el incidente.

¿Cómo pueden las organizaciones detectar secretos codificados?

El escaneo puntual no es suficiente. Los secretos entran en los códigos base continuamente, y la detección necesita igualar ese ritmo.

El DBIR 2025 de Verizon encontró que el tiempo medio para remediar secretos filtrados descubiertos en GitHub fue de 94 días. Esa brecha existe porque la detección sin propiedad y SLAs de triaje produce fatiga de alertas, no acción. Cada secreto detectado necesita un propietario designado y una ruta de respuesta definida.

¿Cómo pueden los equipos prevenir los secretos codificados?

La prevención es un problema en capas. Ningún control individual es suficiente por sí solo.

La mayoría de las organizaciones terminan gestionando ambas categorías: secretos de máquinas para aplicaciones y pipelines, y credenciales humanas para cuentas de administrador compartidas, acceso de equipo y flujos de trabajo operativos. Mantenerlos en sistemas separados y no conectados crea sus propios problemas — políticas de acceso inconsistentes, registros de auditoría duplicados y credenciales que caen en la brecha entre herramientas. Passwork cubre ambas en una única plataforma, bajo un modelo de acceso y un registro de auditoría.

Dos categorías de credenciales, un lugar para gestionarlas

La tabla a continuación muestra dónde pertenece cada tipo de credencial.

El objetivo es asegurar que cada credencial viva en un sistema diseñado para cómo se usa realmente. Para la mayoría de los equipos, eso significa una plataforma que maneje ambas categorías — no dos herramientas separadas con modelos de acceso separados y registros de auditoría separados. Esa es la brecha que Passwork llena.

Cómo Passwork elimina los secretos codificados en toda la pila

Los secretos codificados aparecen cuando los equipos carecen de un lugar conveniente y fiable para almacenar credenciales y recuperarlas en tiempo de ejecución. Passwork elimina esa brecha. Maneja cada tipo de credencial que una organización gestiona — contraseñas de usuario, cuentas de administrador compartidas, claves API, cadenas de conexión de base de datos, claves SSH, certificados TLS y tokens de CI/CD — con el almacenamiento, control de acceso y registro de auditoría que cada categoría requiere.

La misma bóveda donde un equipo de operaciones almacena contraseñas de administrador es el mismo sistema que un pipeline de despliegue consulta para una cadena de conexión de base de datos. Un modelo de acceso, un registro de auditoría, un flujo de trabajo de rotación.

Almacenar secretos para que nunca tengan que codificarse

Passwork organiza las credenciales en una jerarquía de bóvedas estructurada. Los equipos organizan los secretos por entorno y categoría — infrastructure/production/databases, services/stripe, servers/ssh-keys — y cada nivel lleva controles de acceso independientes. Un secreto en la bóveda correcta tiene un propietario designado, una etiqueta de entorno y un conjunto definido de consumidores. Los secretos sin propietarios son los que terminan confirmados en repositorios.

Los campos personalizados soportan secretos con nombre directamente: AWS_SECRET_KEY, STRIPE_SECRET, REDIS_AUTH, OAUTH_CLIENT_SECRET. Ese nombrado alimenta la recuperación de CLI y SDK, haciendo que la bóveda se autodocumente y eliminando la confusión de configuración que lleva a los desarrolladores a codificar un valor «solo por ahora».

Inyección CLI: la alternativa directa a las variables de entorno codificadas

passwork-cli exec ejecuta cualquier comando con secretos inyectados como variables de entorno, solo durante la duración de ese comando. La credencial no aparece en el historial del shell, no escribe en disco y no persiste después de que el proceso hijo termine.

# Run deploy script — secrets exist only for the duration of this command
passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" ./deploy.sh

Esto reemplaza el archivo .env confirmado en un repositorio, el valor codificado pegado desde un mensaje de chat y la variable de entorno impresa en la salida de CI. La aplicación lee su configuración del entorno como está diseñada; la diferencia es de dónde vienen esos valores.

Para un solo valor en un script de shell:

DB_PASS=$(passwork-cli get --password-id "$ITEM_ID")
# DB_PASS is available in this shell, never written to disk

Para rotación — actualizar la credencial después de cambiarla en el sistema de destino:

passwork-cli update --password-id "$ITEM_ID" --password "$NEW_PASS"

El CLI maneja el descifrado y re-cifrado localmente. El servidor de Passwork almacena solo texto cifrado. Incluso un compromiso completo del servidor no produce nada legible.

Integración CI/CD sin codificar tokens de pipeline

Los pipelines de CI/CD son una fuente principal de secretos codificados — tokens y cadenas de conexión confirmados directamente en archivos de pipeline porque no había una mejor opción. Passwork proporciona esa opción.

La imagen Docker passwork/passwork-cli se ejecuta como imagen de trabajo en GitLab CI, GitHub Actions y Bitbucket Pipelines. El pipeline almacena solo tres credenciales de arranque en el almacenamiento de secretos de la plataforma CI: PASSWORK_HOST, PASSWORK_TOKEN y PASSWORK_MASTER_KEY. Todo lo demás vive en Passwork.

# GitLab CI — no credentials in the pipeline file
deploy_prod:
  image: passwork/passwork-cli:latest
  script:
    - passwork-cli exec --folder-id "$SECRETS_FOLDER_ID" ./deploy.sh

# GitHub Actions — credentials injected from platform secrets only
- name: Deploy with secrets
  run: |
    docker run --rm \
      -e PASSWORK_HOST="${{ secrets.PASSWORK_HOST }}" \
      -e PASSWORK_TOKEN="${{ secrets.PASSWORK_TOKEN }}" \
      -e PASSWORK_MASTER_KEY="${{ secrets.PASSWORK_MASTER_KEY }}" \
      passwork/passwork-cli:latest \
      exec --folder-id "${{ vars.SECRETS_FOLDER_ID }}" ./deploy.sh

Para Kubernetes, Passwork soporta un contenedor init que obtiene secretos antes de que la aplicación principal comience, y un sidecar que los actualiza después de la rotación — sin reiniciar el pod.

Cuentas de servicio: identidad de máquina sin dispersión de credenciales

Cada pipeline de CI/CD o script de automatización que accede a Passwork usa una cuenta de servicio dedicada con su propio rol, su propio par de tokens y acceso solo a las bóvedas que realmente necesita. Un pipeline de despliegue obtiene acceso de solo lectura a los secretos de producción. Un script de rotación obtiene acceso de lectura-escritura a la carpeta de bases de datos. Cuando un pipeline se retira, su cuenta de servicio se elimina.

Los tokens de API tienen tiempos de vida configurables. Para un trabajo de CI/CD que se ejecuta por minutos, el token de acceso vive de 15 a 60 minutos. Para un servicio de rotación siempre activo, el token de acceso se ejecuta de 1 a 4 horas y el token de actualización por 30 días. La rotación del par de tokens ocurre programáticamente vía POST /api/v1/sessions/refresh, por lo que la credencial de arranque nunca se convierte en permanentemente de larga duración.

Control de acceso que se adapta a cómo trabajan realmente los equipos

El modelo de permisos de Passwork funciona tanto a nivel de bóveda como de carpeta. Los permisos heredan hacia abajo en el árbol de carpetas pero pueden anularse en cualquier nivel. El equipo de plataforma tiene acceso completo a infrastructure/production. Los desarrolladores acceden a infrastructure/development. La cuenta de servicio de CI/CD obtiene acceso de solo lectura a la carpeta de producción que necesita.

El acceso basado en roles, los grupos y la sincronización AD/LDAP significan que cuando un ingeniero se une a un equipo, hereda el acceso a la bóveda del grupo. Cuando se va, el acceso se elimina de una vez. El panel de seguridad marca las credenciales como comprometidas cuando no han sido rotadas después de que se revocó el acceso de un usuario — detectando directamente el modo de fallo que produce secretos expuestos activos.

Las políticas de complejidad de contraseñas aplican requisitos mínimos en contraseñas maestras y contraseñas de autenticación. Las políticas de bloqueo de cuentas limitan los intentos fallidos de inicio de sesión. SAML SSO vincula el acceso a la bóveda con el proveedor de identidad existente, por lo que la autenticación de Passwork sigue el mismo ciclo de vida que cualquier otro sistema corporativo.

Registro de auditoría y arquitectura de conocimiento cero

Cada lectura, escritura y cambio de permisos se registra: qué cuenta, qué credencial, qué acción, en qué marca de tiempo. Las cuentas de servicio aparecen en el log bajo su propia identidad. El log se exporta en formato CEF para integración con SIEM, por lo que el historial de acceso de Passwork fluye a la misma plataforma de monitoreo de seguridad que los eventos de red y endpoint.

El cifrado y descifrado ocurren en el cliente — en el navegador, en passwork-cli o en el SDK. El servidor almacena solo texto cifrado. Los administradores de Passwork y los operadores de base de datos no tienen medios técnicos para leer los secretos almacenados, incluso con acceso directo a la base de datos. Para despliegues autoalojados, los datos de credenciales cifrados nunca transitan por un sistema de terceros. Passwork tiene certificación ISO 27001 y cumple con GDPR y NIS2.

Lista de verificación para prevención de secretos codificados

Conclusión

Los secretos codificados son una forma prevenible de exposición de credenciales. Los controles técnicos existen: gestores de secretos, hooks pre-commit, escaneo de CI/CD, credenciales de corta duración y acceso de mínimo privilegio. La parte más difícil es construir el flujo de trabajo que haga que las prácticas seguras sean el camino de menor resistencia para cada desarrollador en cada commit.

La defensa completa es en capas. Almacenamiento seguro para secretos de máquinas. Escaneo en cada etapa del pipeline. Políticas de rotación con propietarios definidos y SLAs. Plantillas de flujo de trabajo para desarrolladores que eliminen la fricción que causa los atajos. Y gobernanza de acceso para las credenciales humanas que viven fuera del código de aplicación — las contraseñas de administrador compartidas, credenciales de cuentas de servicio y tokens de acceso de equipo que tienden a dispersarse por canales informales cuando no existe una mejor opción.

Passwork brinda a los equipos un único sistema para almacenar, acceder, rotar y auditar cada tipo de credencial. Los desarrolladores recuperan secretos en tiempo de ejecución en lugar de pegarlos en el código. Los pipelines obtienen de una bóveda en lugar de leer de archivos confirmados. El personal de operaciones gestiona contraseñas de administrador compartidas en la misma plataforma donde DevOps maneja los secretos de infraestructura. Cuando se encuentra una credencial en un repositorio, la respuesta comienza en Passwork: revocar el valor antiguo, generar uno nuevo, actualizar los sistemas dependientes y confirmar a través del registro de auditoría que la credencial antigua ya no está en uso.

Si su equipo aún comparte contraseñas de servicio, administrador o proyecto a través de canales informales, comience centralizándolas en Passwork y definiendo quién tiene permitido acceder, rotar y revisar cada credencial. Ese único cambio elimina una categoría de riesgo que ninguna cantidad de escaneo de código detectará. Pruebe Passwork gratis

Preguntas frecuentes

¿Cuál es un ejemplo de un secreto codificado?

Una contraseña de base de datos escrita directamente en un archivo fuente, una clave de acceso de AWS en un archivo de configuración .yaml, una clave privada SSH en un script de despliegue o un secreto de firma JWT en el código de la aplicación. Cualquier credencial incrustada como un valor estático en código, un archivo de configuración, un script o un paquete de aplicación compilado califica como un secreto codificado.

¿Son los secretos codificados lo mismo que las contraseñas codificadas?

Las contraseñas codificadas son un tipo de secreto codificado. La categoría más amplia también incluye claves API, tokens OAuth, claves SSH, certificados privados, material de claves TLS, claves de cifrado y cadenas de conexión de base de datos. El CWE-798 de MITRE cubre toda la clase bajo «uso de credenciales codificadas».

¿Es seguro almacenar secretos en repositorios privados?

No. Los repositorios privados reducen la exposición pública pero no hacen que los secretos sean seguros. El acceso a menudo está disponible para muchos desarrolladores, herramientas automatizadas e integraciones. Las cuentas de desarrollador comprometidas, los permisos mal configurados, los pipelines de CI/CD, las copias de seguridad, las bifurcaciones y los clones locales amplían la superficie de exposición más allá de lo que implica «privado».

¿Es suficiente eliminar un secreto codificado del código?

No. Si el secreto fue confirmado, puede seguir existiendo en el historial de Git, las bifurcaciones, los logs de CI/CD, los artefactos de compilación, los clones locales y las copias de seguridad. Rote o revoque la credencial primero. Luego elimínela del código base y limpie el historial del repositorio si el alcance de la exposición lo justifica.

¿Son las variables de entorno suficientes para prevenir secretos codificados?

Las variables de entorno ayudan a separar la configuración del código, pero no son un control completo. Los equipos aún necesitan almacenamiento seguro para esos valores, controles de acceso, políticas de rotación y protección contra filtraciones en logs o artefactos de compilación. Las variables de entorno reducen el riesgo de secretos en archivos fuente; no reemplazan una estrategia de gestión de secretos.

¿Cuánto tiempo suelen permanecer activos los secretos filtrados?

Según el informe State of Secrets Sprawl 2026 de GitGuardian, el 64% de los secretos confirmados como válidos en 2022 seguían activos y explotables en 2026. El DBIR 2025 de Verizon encontró un tiempo medio de remediación de 94 días para secretos descubiertos en GitHub. Los tiempos de vida largos de las credenciales son la razón principal por la que un solo secreto filtrado puede causar daño sostenido.

Ciclo de vida de rotación de secretos: De la creación a la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, la revocación de emergencia y la evidencia de auditoría.

Passwork BlogAlex Muntyan

El estado de la dispersión de secretos en 2026: Hallazgos clave del informe de GitGuardian

28,65 millones de secretos filtrados en GitHub público en 2025. La IA está acelerando el problema. Los repositorios internos están 6 veces más expuestos que los públicos. Y el 64% de los secretos de 2022 siguen válidos hoy. Esto es lo que significan los datos para su postura de seguridad.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta se ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

A developer needs to test a database connection quickly. They paste the password directly into the config file, push the commit, and move on. The feature ships. The password stays. Six months later, the repository is forked, the CI/CD logs are indexed, and that credential is sitting in three places no one is monitoring.

This is how most hardcoded secrets enter the wild – through convenience that outlasts its context. GitGuardian found 28.65 million new hardcoded secrets added to public GitHub repositories in 2025, a 34% year-over-year increase and a 152% rise since 2021.

Key takeaways

• Hardcoded secrets are credentials embedded directly in source code, configs, scripts, or application packages – static values written at development time instead of injected at runtime from a secure source.
• Private repositories are not a safe place for secrets. Compromised developer accounts, CI/CD integrations, forks, and backups all expand the exposure surface beyond what "private" implies.
• AI-assisted development is making the problem worse. Commits from AI coding tools are twice as likely to contain secrets. Leaks of AI-service credentials grew 81% year-over-year in 2025.
• Deleting the line is not enough. A committed secret persists in Git history, forks, CI/CD logs, and local clones. Rotation or revocation comes first. Removal is the cleanup step.
• Detection must be continuous and layered. IDE plugins catch secrets before commit; CI/CD scanning catches what slips through; repository-wide scans surface historical exposure. Each layer has blind spots. None of them works without a defined owner and triage process for every finding.
• The root cause is workflow friction, not carelessness. Developers hardcode secrets when there is no faster, approved alternative. Prevention means removing that friction – not just adding scanners.
• Every credential type needs a designated home. Machine secrets belong in a vault or secrets manager with runtime injection. Human and shared credentials belong in a corporate password manager with access controls and audit trails. Credentials that have no designated home end up in code.

What are hardcoded secrets?

Hardcoded secrets are passwords, API keys, tokens, private keys, or other credentials written directly into source code, scripts, configuration files, or application packages. They are static values embedded at write time rather than injected at runtime from a secure source. MITRE classifies this vulnerability as CWE-798: Use of Hard-coded Credentials and rates its exploit likelihood as high.

The OWASP community page on use of hard-coded passwords covers the password-specific variant, but the full scope of hardcoded secrets extends well beyond passwords.

Where do hardcoded secrets usually appear?

Hardcoded secrets appear wherever code is written, built, stored, or deployed – which is a much larger surface than most teams realize.

In the codebase and version control:

• Application source code and inline comments
• Configuration files (.properties, .yaml, .json, .xml)
• Local development files (.env, .env.local) committed by mistake
• Infrastructure-as-code templates (Terraform, Ansible, CloudFormation)

In build and deployment systems:

• CI/CD pipeline definition files with credentials written inline
• Build logs and artifacts that echo environment values
• Container images with secrets baked into layers

In distributed and embedded systems:

• Mobile apps and client-side JavaScript bundles
• Firmware, IoT devices, routers, and embedded controllers

In informal storage:

• Documentation, internal wikis, and README files
• Support tickets, Jira issues, and Confluence pages
• Slack exports, email threads, and shared spreadsheets

A note on .env files: they are safer than writing values directly into code, but only if they are excluded from version control, protected locally, and never copied into logs or build artifacts. A .env file committed once is a hardcoded secret.

Why do developers hardcode secrets?

The root cause is almost never carelessness. It is workflow friction.

1. Fast local testing. Hardcoding a value takes ten seconds. Setting up a vault reference takes longer, especially without a standard template.
2. Avoiding configuration drift. When dev, staging, and production environments are inconsistently managed, developers sometimes hardcode values to guarantee the right credential reaches the right system.
3. Copying from documentation or examples. Official docs and Stack Overflow answers frequently show credentials as placeholders. Those placeholders get replaced with real values and committed.
4. AI-generated code. Coding assistants may reproduce insecure patterns from training data or insert placeholder credentials that look functional. The risk is highest when generated code bypasses normal security review or when a developer replaces a placeholder with a real value without moving it to a secure source.
5. No standard secret-management workflow. When there is no approved way to handle secrets locally, developers invent their own -- and convenience usually wins.
6. Missing pre-commit checks. Without automated gates, a hardcoded secret can travel from a developer's editor to a shared repository in a single push.
7. Unclear ownership of service accounts and shared credentials. When no one owns a credential, no one manages it safely.

Why are hardcoded secrets so risky?

The numbers make the trend hard to dismiss. GitGuardian tracked ~11 million new hardcoded secrets on public GitHub in 2021; by 2025 that figure had reached 28,649,024 – a 152% increase in four years.

Detection alone is not closing the gap: 64% of secrets confirmed as valid in 2022 were still active and exploitable in 2026. Hardcoded secrets are not a legacy problem being gradually resolved – the exposure surface is growing faster than remediation can keep up.

Private repositories are not a safe place for secrets. Repository access is often broader than administrators realize. CI/CD tools, backup systems, developer endpoints, third-party integrations, and forks all expand the exposure surface. A compromised developer account is enough to extract every secret in every private repository that account can read.

Verizon's 2025 DBIR also found that web application infrastructure made up 39% of disclosed secrets in public Git repositories, and 66% of those were JWTs. Generic secrets – the category hardest to detect with pattern-matching tools – made up 58% of all leaked credentials in 2024, according to GitGuardian.

Passwork is a corporate password and secrets manager: API keys, tokens, SSH keys, and admin credentials — all in encrypted vaults with role-based access and audit logs, not in code or chat threads. Explore Passwork

What should you do if a hardcoded secret is found?

The instinct to delete the line and push a fix commit is understandable. It is also insufficient. Once a secret is committed, assume it has been copied, cached, logged, or indexed somewhere you cannot reach.

Incident response workflow

1. Classify the secret. Determine whether it is a password, API key, token, private key, certificate, or connection string.
2. Identify the owner and scope. Find which system, environment, privilege level, and account the secret controls.
3. Revoke or rotate immediately. Treat the value as compromised from the moment it was committed or exposed.
4. Check access logs. Look for suspicious activity before and after the exposure window.
5. Remove it from the codebase. Replace the hardcoded value with a reference to a secure source.
6. Clean repository history if needed. Use approved tooling such as git filter-repo or BFG Repo-Cleaner, and coordinate with repository owners -- rewriting history affects all collaborators.
7. Update dependent systems. Confirm that all applications, jobs, and integrations are using the new value.
8. Document the incident. Record root cause, owner, remediation time, and what control will prevent recurrence.
9. Add a prevention control. Pre-commit hooks, CI/CD scanning, policy updates, or access review -- at least one concrete change before closing the incident.

How can organizations detect hardcoded secrets?

One-time scanning is not enough. Secrets enter codebases continuously, and detection needs to match that pace.

The Verizon 2025 DBIR found that the median time to remediate discovered leaked secrets on GitHub was 94 days. That gap exists because detection without ownership and triage SLAs produces alert fatigue, not action. Every detected secret needs a named owner and a defined response path.

How can teams prevent hardcoded secrets?

Prevention is a layered problem. No single control is sufficient on its own.

Most organizations end up managing both categories: machine secrets for applications and pipelines, and human credentials for shared admin accounts, team access, and operational workflows. Keeping them in separate, unconnected systems creates its own problems – inconsistent access policies, duplicate audit trails, and credentials that fall through the gap between tools. Passwork covers both in a single platform, under one access model and one audit log.

Two credential categories, one place to manage them

The table below shows where each credential type belongs.

The goal is to ensure every credential lives in a system designed for how it is actually used. For most teams, that means one platform that handles both categories – not two separate tools with separate access models and separate audit trails. That is the gap Passwork fills.

How Passwork eliminates hardcoded secrets across the stack

Hardcoded secrets appear when teams lack a convenient, reliable place to store credentials and retrieve them at runtime. Passwork removes that gap. It handles every credential type an organization manages – user passwords, shared admin accounts, API keys, database connection strings, SSH keys, TLS certificates, and CI/CD tokens – with the storage, access control, and audit trail that each category requires.

The same vault where an operations team stores admin passwords is the same system a deployment pipeline queries for a database connection string. One access model, one audit log, one rotation workflow.

Storing secrets so they never have to be hardcoded

Passwork organizes credentials in a structured vault hierarchy. Teams arrange secrets by environment and category – infrastructure/production/databases, services/stripe, servers/ssh-keys – and each level carries independent access controls. A secret in the right vault has a named owner, an environment tag, and a defined set of consumers. Secrets without owners are the ones that end up committed to repositories.

Custom fields support named secrets directly: AWS_SECRET_KEY, STRIPE_SECRET, REDIS_AUTH, OAUTH_CLIENT_SECRET. That naming feeds into CLI and SDK retrieval, making the vault self-documenting and eliminating the configuration confusion that drives developers to hardcode a value "just for now."

CLI injection: the direct alternative to hardcoded environment variables

passwork-cli exec runs any command with secrets injected as environment variables, for the duration of that command only. The credential does not appear in shell history, does not write to disk, and does not persist after the child process exits.

# Run deploy script — secrets exist only for the duration of this command
passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" ./deploy.sh

This replaces the .env file committed to a repository, the hardcoded value pasted from a chat message, and the environment variable printed in CI output. The application reads its configuration from the environment as designed; the difference is where those values come from.

For a single value in a shell script:

DB_PASS=$(passwork-cli get --password-id "$ITEM_ID")
# DB_PASS is available in this shell, never written to disk

For rotation — updating the credential after changing it in the target system:

passwork-cli update --password-id "$ITEM_ID" --password "$NEW_PASS"

The CLI handles decryption and re-encryption locally. Passwork's server stores only ciphertext. Even a full server compromise yields nothing readable.

CI/CD integration without hardcoding pipeline tokens

CI/CD pipelines are a primary source of hardcoded secrets — tokens and connection strings committed directly into pipeline files because there was no better option. Passwork provides that option.

The Docker image passwork/passwork-cli runs as a job image in GitLab CI, GitHub Actions, and Bitbucket Pipelines. The pipeline stores only three bootstrap credentials in the CI platform's secret storage: PASSWORK_HOST, PASSWORK_TOKEN, and PASSWORK_MASTER_KEY. Everything else lives in Passwork.

# GitLab CI — no credentials in the pipeline file
deploy_prod:
  image: passwork/passwork-cli:latest
  script:
    - passwork-cli exec --folder-id "$SECRETS_FOLDER_ID" ./deploy.sh

# GitHub Actions — credentials injected from platform secrets only
- name: Deploy with secrets
  run: |
    docker run --rm \
      -e PASSWORK_HOST="${{ secrets.PASSWORK_HOST }}" \
      -e PASSWORK_TOKEN="${{ secrets.PASSWORK_TOKEN }}" \
      -e PASSWORK_MASTER_KEY="${{ secrets.PASSWORK_MASTER_KEY }}" \
      passwork/passwork-cli:latest \
      exec --folder-id "${{ vars.SECRETS_FOLDER_ID }}" ./deploy.sh

For Kubernetes, Passwork supports an init container that fetches secrets before the main application starts, and a sidecar that refreshes them after rotation — without restarting the pod.

Service accounts: machine identity without credential sprawl

Every CI/CD pipeline or automation script that accesses Passwork uses a dedicated service account with its own role, its own token pair, and access only to the vaults it actually needs. A deployment pipeline gets read-only access to production secrets. A rotation script gets read-write access to the databases folder. When a pipeline is retired, its service account is removed.

API tokens have configurable lifetimes. For a CI/CD job that runs for minutes, the access token lives for 15-60 minutes. For an always-on rotation service, the access token runs for 1-4 hours and the refresh token for 30 days. Token pair rotation happens programmatically via POST /api/v1/sessions/refresh, so the bootstrap credential never becomes permanently long-lived.

Access control that maps to how teams actually work

Passwork's permission model works at both vault and folder level. Permissions inherit down the folder tree but can be overridden at any level. The platform team has full access to infrastructure/production. Developers access infrastructure/development. The CI/CD service account gets read-only access to the production folder it needs.

Role-based access, groups, and AD/LDAP synchronization mean that when an engineer joins a team, they inherit the group's vault access. When they leave, access is removed once. The security dashboard flags credentials as compromised when they have not been rotated after a user's access was revoked — directly detecting the failure mode that produces active exposed secrets.

Password complexity policies enforce minimum requirements on master passwords and authentication passwords. Account lockout policies limit failed sign-in attempts. SAML SSO ties vault access to the existing identity provider, so Passwork authentication follows the same lifecycle as every other corporate system.

Audit trail and zero-knowledge architecture

Every read, write, and permission change is recorded: which account, which credential, which action, at what timestamp. Service accounts appear in the log under their own identity. The log exports in CEF format for SIEM integration, so Passwork's access history flows into the same security monitoring platform as network and endpoint events.

Encryption and decryption happen on the client – in the browser, in passwork-cli, or in the SDK. The server stores only ciphertext. Passwork administrators and database operators have no technical means to read stored secrets, even with direct database access. For self-hosted deployments, encrypted credential data never transits a third-party system. Passwork is ISO 27001 certified and compliant with GDPR and NIS2.

Hardcoded secrets prevention checklist

Conclusion

Hardcoded secrets are a preventable form of credential exposure. The technical controls exist: secret managers, pre-commit hooks, CI/CD scanning, short-lived credentials, and least-privilege access. The harder part is building the workflow that makes secure practices the path of least resistance for every developer on every commit.

The full defense is layered. Secure storage for machine secrets. Scanning at every stage of the pipeline. Rotation policies with defined owners and SLAs. Developer workflow templates that remove the friction that causes shortcuts. And access governance for the human credentials that live outside application code – the shared admin passwords, service account credentials, and team access tokens that tend to spread through informal channels when no better option exists.

Passwork gives teams a single system to store, access, rotate, and audit every credential type. Developers retrieve secrets at runtime instead of pasting them into code. Pipelines pull from a vault instead of reading from committed files. Operations staff manage shared admin passwords in the same platform where DevOps handles infrastructure secrets. When a credential is found in a repository, the response starts in Passwork: revoke the old value, generate the new one, update dependent systems, and confirm through the audit log that the old credential is no longer in use.

If your team still shares service, admin, or project passwords through informal channels, start by centralizing them in Passwork and defining who is allowed to access, rotate, and review each credential. That single change removes a category of risk that no amount of code scanning will catch. Try Passwork free

Frequently Asked Questions

What is an example of a hardcoded secret?

A database password written directly in a source file, an AWS access key in a .yaml config, an SSH private key in a deployment script, or a JWT signing secret in application code. Any credential embedded as a static value in code, a configuration file, a script, or a compiled application package qualifies as a hardcoded secret.

Are hardcoded secrets the same as hardcoded passwords?

Hardcoded passwords are one type of hardcoded secret. The broader category also includes API keys, OAuth tokens, SSH keys, private certificates, TLS key material, encryption keys, and database connection strings. MITRE's CWE-798 covers the full class under "use of hard-coded credentials."

Is it safe to store secrets in private repositories?

No. Private repositories reduce public exposure but do not make secrets safe. Access is often available to many developers, automated tools, and integrations. Compromised developer accounts, misconfigured permissions, CI/CD pipelines, backups, forks, and local clones all expand the exposure surface beyond what "private" implies.

Is deleting a hardcoded secret from code enough?

No. If the secret was committed, it may still exist in Git history, forks, CI/CD logs, build artifacts, local clones, and backups. Rotate or revoke the credential first. Then remove it from the codebase and clean repository history if the exposure scope warrants it.

Are environment variables enough to prevent hardcoded secrets?

Environment variables help separate configuration from code, but they are not a complete control. Teams still need secure storage for those values, access controls, rotation policies, and protection against leaks in logs or build artifacts. Environment variables reduce the risk of secrets in source files; they do not replace a secrets management strategy.

How long do leaked secrets typically remain active?

According to GitGuardian's State of Secrets Sprawl 2026 report, 64% of secrets confirmed valid in 2022 were still active and exploitable in 2026. The Verizon 2025 DBIR found a median remediation time of 94 days for discovered secrets on GitHub. Long credential lifetimes are the main reason a single leaked secret can cause sustained damage.

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

The state of secrets sprawl in 2026: Key findings from GitGuardian’s report

28.65 million secrets leaked on public GitHub in 2025. AI is accelerating the problem. Internal repos are 6× more exposed than public ones. And 64% of secrets from 2022 are still valid today. Here is what the data means for your security posture.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

La rotación de secretos falla cuando los equipos la tratan como un simple cambio de contraseña programado: configuran calendarios de rotación, apuntan a una bóveda y lo dan por hecho. Entonces una clave API se filtra desde una variable de CI/CD que nadie inventarió. O un trabajo de rotación se ejecuta dos veces, crea una condición de carrera y tumba un servicio. O un ingeniero se va, y su clave SSH permanece activa durante seis meses porque nadie la asoció a un propietario.

Un ciclo de vida de rotación de secretos es el proceso controlado para crear, almacenar, usar, rotar, revocar y retirar credenciales como claves API, contraseñas, tokens, certificados y claves de cifrado. Su objetivo es reducir la vida útil y el radio de impacto de las credenciales expuestas mientras se mantiene la disponibilidad de los sistemas.

La rotación es un control dentro de ese proceso. Sin la estructura circundante (inventario, propiedad, control de acceso, validación, limpieza y evidencia de auditoría), la rotación por sí sola cambia el valor de una credencial sin reducir su riesgo.

Puntos clave

• Un ciclo de vida de rotación de secretos tiene siete etapas: creación, clasificación, almacenamiento, distribución, rotación, revocación y retiro.
• La rotación es un control dentro de un sistema más amplio, no el sistema en sí. Sin la estructura circundante, la rotación cambia el valor de una credencial sin reducir su riesgo.
• El problema de exposición es estructural, no procedimental. GitGuardian detectó 28,65 millones de nuevos secretos codificados en GitHub público en 2025 — un aumento del 34% interanual. De los secretos confirmados como válidos en 2022, el 64% seguía siendo explotable en enero de 2026 (GitGuardian State of Secrets Sprawl 2026).
• La rotación segura tiene una secuencia específica. Generar el nuevo valor, validarlo contra el sistema objetivo, desplegarlo gradualmente, luego deshabilitar el antiguo. Omitir la validación o migrar todos los consumidores a la vez es lo que causa interrupciones de servicio.
• Los secretos dinámicos eliminan el problema de rotación para cargas de trabajo compatibles. Los secretos estáticos rotados siguen siendo necesarios para sistemas heredados, integraciones de terceros y cargas de trabajo de larga duración que no pueden solicitar credenciales bajo demanda.
• La revocación de emergencia requiere un inventario completo. Si no puede identificar todos los consumidores de un secreto en minutos tras una sospecha de exposición, no puede contener el incidente. El inventario es el prerrequisito para todo lo demás.

¿Qué es el ciclo de vida de rotación de secretos?

El ciclo de vida de rotación de secretos es el modelo de gobernanza integral para gestionar credenciales de máquinas y humanos desde el momento en que se crean hasta el momento en que se destruyen permanentemente. Trata la rotación como una etapa dentro de un proceso operativo más amplio, no como una tarea periódica de cambio de contraseña.

La distinción importa porque la rotación sin los controles circundantes produce una falsa sensación de seguridad. Una credencial que rota cada 30 días pero no tiene propietario designado, ni inventario de consumidores, ni ruta de revocación, sigue siendo un pasivo.

Cada etapa tiene un conjunto distinto de controles. Omitir la clasificación significa que los objetivos de rotación son desconocidos. Omitir la limpieza significa que las credenciales antiguas se acumulan y crean exposición. El modelo de ciclo de vida obliga a los equipos a tratar cada etapa como una decisión operativa deliberada.

Por qué la rotación por sí sola no resuelve el riesgo de credenciales

La rotación reduce la ventana de exposición para una credencial comprometida. No elimina la credencial como superficie de ataque, y no hace nada por las credenciales que nunca se inventariaron, nunca se almacenaron de forma segura, o nunca se revocaron tras una exposición.

La escala del problema de credenciales no gestionadas es estructural. GitGuardian detectó 28,65 millones de nuevos secretos codificados en GitHub público en 2025 — un aumento del 34% respecto al año anterior y el mayor salto anual que la compañía ha registrado. Esa cifra cubre solo repositorios públicos. De los secretos que GitGuardian confirmó como válidos en 2022, el 64% seguía siendo explotable en enero de 2026, cuatro años después de su primera filtración.

El patrón es consistente: los secretos escapan de su entorno previsto, nadie lo nota, y los calendarios de rotación no los detectan porque la copia expuesta está completamente fuera de la bóveda.

La rotación debe entenderse como un control que reduce la vida útil de las credenciales que están correctamente gestionadas. No es un sustituto de eliminar credenciales codificadas, aplicar el privilegio mínimo, auditar accesos, escanear la dispersión de secretos o revocar valores obsoletos. Todos esos controles deben estar implementados para que la rotación logre su efecto previsto.

¿Qué secretos necesitan gestión de ciclo de vida?

Cualquier credencial que otorgue acceso a un sistema, almacén de datos, servicio o identidad necesita gestión de ciclo de vida. El alcance práctico es más amplio de lo que la mayoría de los equipos asumen inicialmente.

El paso de inventario (saber qué secretos existen, dónde residen, quién los posee y a qué acceden) es el prerrequisito para todo lo demás. No se puede rotar lo que no se ha encontrado.

Las siete etapas de un ciclo de vida seguro de rotación de secretos

1. Crear secretos con propiedad y propósito

Cada secreto necesita un propietario designado, un propósito de sistema documentado, una etiqueta de entorno, una clasificación de sensibilidad, una expiración prevista y una ubicación de almacenamiento aprobada antes de salir del paso de creación. Estos son los datos que hacen posible la rotación, revocación y limpieza.

Un secreto creado sin propietario no tiene a nadie responsable de rotarlo. Un secreto creado sin lista de consumidores no tiene a quién notificar cuando cambia. Un secreto creado sin expiración no tiene disparador para revisión.

No permita que los desarrolladores creen secretos en tickets, mensajes de chat, hojas de cálculo o archivos locales. El paso de creación debe dirigirse directamente a una bóveda gestionada o gestor de secretos. Si no es así, el secreto ya está fuera del ciclo de vida antes de haberse usado una vez.

2. Almacenar secretos en una bóveda gestionada, no en el código

El almacenamiento centralizado es lo que hace operable el resto del ciclo de vida. Una bóveda proporciona control de acceso, registro de auditoría, historial de versiones, hooks de rotación y capacidad de revocación. Un archivo .env en un repositorio no proporciona nada de eso.

La dispersión de secretos — credenciales dispersas en repositorios, herramientas de chat, archivos de configuración y almacenes de contraseñas personales — es la consecuencia directa de omitir este paso. La suposición de que los sistemas internos son más seguros que los públicos no resiste la medición.

La investigación de GitGuardian de 2026 encontró que los repositorios internos tienen 6 veces más probabilidades de contener un secreto codificado que los públicos, y que el 28% de los incidentes internos se originan completamente fuera del código — en Slack, Jira y Confluence — con una tasa de severidad crítica más alta que los hallazgos basados en código. «Privado» no es un control de seguridad.

Para equipos donde administradores, personal de TI y unidades de negocio necesitan acceso controlado a credenciales compartidas, un gestor de contraseñas corporativo puede dar soporte al lado humano de la gobernanza de secretos: almacenamiento centralizado, acceso estructurado, registros de propiedad y manejo de credenciales compatible con auditorías. Los secretos máquina a máquina aún requieren controles técnicos conscientes del ciclo de vida, pero el acceso humano a credenciales sensibles no debería residir en hilos de chat, hojas de cálculo o almacenes de contraseñas personales.

3. Otorgar acceso usando el privilegio mínimo

Los consumidores de secretos deberían recibir solo las credenciales que necesitan, con el alcance de permisos más reducido posible, durante el período más corto posible. Esto aplica a usuarios humanos, cuentas de servicio, pipelines de CI/CD e identidades no humanas.

Un pipeline de CI/CD que despliega en staging no necesita credenciales de base de datos de producción. Una cuenta de servicio que lee de un único bucket S3 no necesita acceso de almacenamiento a nivel de cuenta. Un desarrollador que necesita depurar un problema en producción no necesita acceso permanente a la bóveda de producción.

El privilegio mínimo reduce el radio de impacto. Si una credencial es comprometida, el acceso del atacante está limitado por lo que esa credencial tenía permitido hacer. Los secretos sobreaprovisionados convierten cada exposición en un potencial compromiso total del sistema.

4. Usar secretos sin exponerlos

La etapa de uso es donde los secretos más comúnmente escapan de su entorno previsto. Las aplicaciones imprimen valores de configuración en logs. Los desarrolladores pegan credenciales en tickets para compartir contexto. El historial de shell captura cadenas de conexión de base de datos. Las respuestas de error incluyen detalles de autenticación.

La inyección en tiempo de ejecución mantiene los secretos fuera del código. Los servicios deberían recuperar credenciales al iniciarse mediante un cliente de bóveda o sidecar de inyección de secretos, no desde archivos de configuración comprometidos. El CLI de Passwork soporta un modo exec que inyecta credenciales como variables de entorno durante la duración de un comando, sin escribirlas en el historial de shell o el sistema de archivos. Los hooks pre-commit y las herramientas de escaneo de secretos detectan commits accidentales antes de que lleguen a un repositorio.

Los controles específicos que importan aquí: redactar secretos de los logs de aplicación, deshabilitar el registro de credenciales en modos de depuración, escanear pipelines de agregación de logs en busca de patrones de secretos, y nunca incluir credenciales en mensajes de error devueltos a los clientes. Estas no son medidas exóticas — son la base para cualquier entorno de producción que maneje credenciales sensibles.

5. Rotar secretos de forma segura

La rotación es la etapa para la que la mayoría de los equipos tienen algún proceso. Los fallos operativos ocurren en los detalles: validar el nuevo valor antes de activarlo, controlar qué consumidores adoptan la nueva versión y cuándo, monitorizar roturas, y deshabilitar el valor antiguo solo después de confirmar que el nuevo funciona.

La documentación de Secret Manager de Google Cloud es explícita sobre un modo de fallo específico: resolver continuamente el alias latest en cargas de trabajo de producción crea riesgo de interrupción a nivel de todo el servicio si se despliega una versión de secreto incorrecta. El nuevo valor es adoptado inmediatamente por todos los consumidores, sin despliegue gradual y sin reversión automática. Este es un peligro operativo real, no teórico.

La secuencia de rotación segura:

1. Inventariar el secreto, su propietario, sus consumidores y su ruta de dependencias.
2. Generar el nuevo valor sin invalidar el antiguo.
3. Almacenar el nuevo valor como una nueva versión en la bóveda o gestor de secretos.
4. Validar el nuevo valor contra el sistema objetivo antes de que cualquier consumidor lo use.
5. Desplegar a un pequeño subconjunto de consumidores o la siguiente ola de despliegue.
6. Monitorizar fallos de autenticación, tasas de error, latencia y salud de la aplicación.
7. Completar el despliegue a todos los consumidores.
8. Deshabilitar el valor antiguo y monitorizar uso inesperado.
9. Revocar o destruir el valor antiguo después de que cierre la ventana de seguridad.
10. Registrar evidencia de auditoría y actualizar el inventario.

Los pasos 4 y 8 son los que más frecuentemente se omiten. Omitir el paso 4 significa que un valor incorrecto puede llegar a producción. Omitir el paso 8 significa que el valor antiguo permanece activo indefinidamente, anulando el propósito de la rotación.

6. Revocar secretos tras exposición, baja o cambios de alcance

La revocación es distinta de la rotación. La rotación reemplaza una credencial según un calendario. La revocación deshabilita una credencial inmediatamente en respuesta a un evento específico: exposición confirmada, compromiso sospechado, salida de empleado, cambio de rol, incidente con proveedor o desmantelamiento de sistema.

El flujo de trabajo de revocación de emergencia:

1. Detectar o confirmar el evento de exposición.
2. Identificar el propietario del secreto, los consumidores y todos los sistemas dependientes.
3. Deshabilitar o revocar el valor comprometido en el sistema emisor, no solo en la bóveda.
4. Generar una credencial de reemplazo.
5. Actualizar todos los sistemas dependientes con el nuevo valor.
6. Validar que el reemplazo funciona y el valor antiguo ya no otorga acceso.
7. Monitorizar cualquier uso continuado de la credencial revocada.
8. Investigar la exposición: ¿cómo ocurrió, qué se accedió, durante cuánto tiempo?
9. Documentar el incidente, la línea temporal de revocación y los pasos de remediación.

El paso 3 es donde la revocación falla más frecuentemente. Los equipos deshabilitan el secreto en su bóveda pero olvidan invalidarlo en el sistema externo — la base de datos, el proveedor de API, la plataforma de identidad. El valor antiguo permanece válido en el origen. El registro de la bóveda dice revocado; la credencial aún funciona.

7. Retirar y auditar secretos antiguos

Mantener credenciales antiguas «por si acaso» es un instinto común y un riesgo real. Cada valor antiguo que permanece accesible es una credencial que puede usarse — por un atacante que la encontró en un log, una copia de seguridad, un sistema desmantelado o la caché local de un desarrollador.

La secuencia de retiro: deshabilitar primero el valor antiguo, monitorizar el uso inesperado durante una ventana de seguridad definida, luego destruir o archivar según la política y los requisitos de cumplimiento. La duración de la ventana de seguridad depende del tipo de secreto y la criticidad de los sistemas dependientes — típicamente de 24 a 72 horas para la mayoría de credenciales de aplicación, más tiempo para claves de cifrado donde pueda estar involucrado el recifrado.

La evidencia de auditoría para el retiro debe incluir: la fecha en que se deshabilitó el valor antiguo, el período de monitorización, confirmación de que no ocurrió uso inesperado, y la fecha de destrucción o archivo final. Esta es la documentación que satisface a un auditor preguntando «¿cómo sabe que la credencial antigua ha desaparecido?»

Rotación manual vs rotación automatizada

La rotación manual no es inherentemente incorrecta. Para un pequeño conjunto de credenciales de administrador de alta sensibilidad que cambian con poca frecuencia, un proceso manual documentado con puertas de aprobación y registros de auditoría puede ser apropiado. El problema surge cuando la rotación manual es la opción por defecto para todo — no escala, es inconsistente, y la pista de auditoría suele ser una hoja de cálculo con una columna de fecha.

La automatización debería ser la opción por defecto para cualquier tipo de secreto donde el sistema objetivo lo soporte. El hallazgo de IBM de que la IA de seguridad y automatización extensiva redujo los costos de brechas en 1,9 millones de dólares en promedio refleja un principio más amplio: los controles automatizados consistentes superan a los manuales inconsistentes a escala.

Secretos rotados vs secretos dinámicos

Los secretos dinámicos son credenciales emitidas bajo demanda con un TTL o arrendamiento corto. Cada carga de trabajo solicitante obtiene una credencial única que expira automáticamente — no hay nada que rotar porque nada es de larga duración. El motor de secretos de base de datos de HashiCorp Vault es el ejemplo estándar: cada solicitud de aplicación obtiene un usuario de base de datos temporal que expira cuando termina el arrendamiento.

Los secretos rotados son credenciales estáticas que se reemplazan periódicamente con un nuevo valor. Siguen siendo necesarios para sistemas que no pueden emitir credenciales dinámicas: la mayoría de APIs SaaS, muchas bases de datos heredadas, cuentas de servicio de larga duración e integraciones de terceros donde no se controla el emisor de credenciales.

Los secretos dinámicos reducen la superficie de ataque para las cargas de trabajo que pueden soportarlos. No eliminan la necesidad de controles de ciclo de vida sobre las credenciales que no pueden hacerse dinámicas. Ambos modelos coexisten en la mayoría de los entornos reales.

Cómo rotar secretos sin tiempo de inactividad

La estrategia de dos secretos es el patrón central para rotación sin tiempo de inactividad. La credencial antigua y la nueva son ambas válidas simultáneamente durante la ventana de transición. Los consumidores migran al nuevo valor, se confirma que el valor antiguo no está en uso, luego se deshabilita el valor antiguo.

Esto requiere que el sistema externo — la base de datos, el proveedor de API, la plataforma de identidad — soporte múltiples credenciales válidas simultáneamente. La mayoría de los sistemas modernos lo hacen. Para aquellos que no, la ventana de rotación requiere un período de mantenimiento o un enfoque de despliegue blue-green.

Los modos de fallo específicos contra los que diseñar:

• Consumidores que cachean credenciales en memoria y no recargan hasta reiniciar. Planificar reinicios progresivos o un mecanismo de invalidación de caché.
• Trabajos de rotación que se ejecutan concurrentemente y crean versiones conflictivas. Usar bloqueos, diseño idempotente y etiquetas de estado para prevenir doble rotación.
• Verificaciones de salud que no prueban la ruta real de la credencial. Un servicio que reporta saludable pero está usando un valor antiguo cacheado se romperá cuando el valor antiguo se deshabilite.

La documentación de rotación de Google Cloud recomienda vincular las aplicaciones a una versión específica del secreto en lugar del alias latest para cargas de trabajo de producción. Resolver la versión en tiempo de despliegue, almacenar el nombre de la versión en la configuración y desplegarlo a través del pipeline de despliegue estándar. Esto proporciona despliegue gradual, capacidad de reversión y comportamiento predecible entre reinicios.

El patrón de trabajo de rotación reentrante importa para la rotación automatizada: el trabajo debe poder reiniciarse desde cualquier punto sin crear credenciales duplicadas o dejar el sistema en un estado inconsistente. Configurar reintentos, pero también configurar concurrencia máxima para prevenir que ejecuciones paralelas entren en conflicto.

Modos de fallo comunes y cómo prevenirlos

El modo de fallo más costoso es el segundo: actualizar el registro de la bóveda mientras la credencial antigua permanece válida en el sistema externo. Esto es particularmente común con credenciales de base de datos, donde el registro de la bóveda muestra «rotado» pero la contraseña de la base de datos nunca se cambió realmente. La credencial sigue siendo válida, la bóveda la muestra como rotada, y el log de auditoría parece limpio. Probar la revocación en el origen, no solo en la bóveda.

Passwork proporciona a los equipos de TI una bóveda estructurada con acceso basado en roles, registros de propiedad y un log de auditoría completo para credenciales compartidas. Vea cómo encaja en su programa de gobernanza

Cumplimiento y evidencia de auditoría para el ciclo de vida de secretos

Los marcos de cumplimiento no prescriben intervalos de rotación de manera universal. Lo que requieren — a través de entornos PCI DSS, SOC 2, HIPAA y GDPR — es evidencia de que los controles de acceso existen, operan consistentemente y se revisan. El requisito exacto depende del alcance, mapeo de controles e interpretación del auditor. No haga afirmaciones generales sobre lo que una regulación exige sin leer el lenguaje de control específico.

Lo que la gestión del ciclo de vida produce y los auditores quieren ver:

• Registros de inventario que muestren qué secretos existen, quién los posee y a qué acceden
• Evidencia de control de acceso: quién tiene permiso para recuperar cada secreto y por qué
• Registros de rotación: cuándo se rotó cada credencial, mediante qué proceso y si la validación pasó
• Registros de revocación: cuándo se deshabilitaron las credenciales, qué desencadenó la revocación y confirmación de que el valor antiguo ya no funciona
• Revisiones de acceso: confirmación periódica de que las concesiones de acceso siguen siendo apropiadas
• Documentación de incidentes: para cualquier evento de exposición, una línea temporal desde la detección hasta la remediación

La pista de auditoría no es un subproducto de una buena gestión de secretos — es un requisito de diseño. Los sistemas que no registran eventos de rotación, solicitudes de acceso y acciones de revocación no pueden producir la evidencia que el cumplimiento requiere.

El IBM X-Force Threat Intelligence Index 2026 reportó 300.000 credenciales de chatbots de IA observadas a la venta en la dark web. El problema de exposición de credenciales no se está reduciendo. Los auditores y reguladores están prestando atención a la misma tendencia.

Una plantilla práctica de política para el ciclo de vida de rotación de secretos

Una política sin especificaciones operativas es un documento que se firma y se ignora. La plantilla a continuación es un esqueleto — complete los detalles específicos para su entorno, hágala revisar por legal y seguridad, y adjúntela a su programa de gobernanza de secretos.

La fila de excepciones importa. Cada entorno tiene sistemas que no pueden soportar rotación automatizada — aplicaciones heredadas, servicios de terceros con gestión manual de claves, appliances de hardware. Documéntelos explícitamente, defina los controles compensatorios y revíselos según un calendario. Una excepción no documentada es un riesgo no gestionado.

Dónde encaja Passwork en un programa de gobernanza de secretos

Las siete etapas del ciclo de vida necesitan diferentes herramientas en diferentes capas. Los motores de credenciales dinámicas y los sistemas KMS manejan secretos máquina a máquina a escala de infraestructura. Lo que no reemplazan es una capa gobernada para credenciales que los humanos crean, comparten y rotan: cuentas de administrador, credenciales de emergencia, claves de servicio compartidas, claves API gestionadas por equipos de operaciones, y cualquier cosa que actualmente vive en una hoja de cálculo, una bandeja de entrada compartida o el gestor de contraseñas personal de alguien.

Passwork cubre esa capa. Las secciones a continuación mapean sus capacidades a las etapas del ciclo de vida donde las credenciales gestionadas por humanos necesitan más gobernanza.

Almacenamiento y clasificación

Passwork almacena credenciales en bóvedas estructuradas organizadas por carpeta, entorno y equipo. Cada entrada lleva metadatos: URL, inicio de sesión, campos personalizados, etiquetas y notas. Puede reflejar la topología de su infraestructura en el diseño de la bóveda (bóvedas separadas para producción y staging, carpetas por equipo o servicio), lo que hace práctico tanto el alcance del acceso como el inventario de rotación.

El modelo de cifrado importa aquí. El almacenamiento del lado del servidor usa AES-256-CFB. Con el cifrado del lado del cliente (CSE) habilitado, cada bóveda se cifra en el navegador antes de salir del dispositivo. El servidor almacena solo texto cifrado; el descifrado requiere la clave maestra, que se deriva de la contraseña maestra del usuario y nunca se transmite. Para organizaciones que no pueden enrutar credenciales sensibles a través de un servicio externo bajo ninguna circunstancia, el modelo CSE elimina esa dependencia por completo.

Control de acceso y privilegio mínimo

Los permisos basados en roles y grupos permiten otorgar acceso a la bóveda a un equipo en lugar de a individuos. Cuando un ingeniero se une al grupo DevOps, hereda automáticamente el acceso a la bóveda del grupo. Cuando se va, se revoca el acceso una vez — no una vez por bóveda.

El alcance del acceso es granular. Cada bóveda o carpeta tiene permisos independientes. Una cuenta de servicio de CI/CD obtiene acceso de lectura a la carpeta específica que necesita y nada más. Un auditor de seguridad obtiene acceso de solo lectura a bóvedas designadas sin la capacidad de modificar o exportar valores. Passwork se integra con AD/LDAP y soporta SSO con SAML, por lo que el aprovisionamiento y la baja siguen los mismos flujos de trabajo de identidad que el resto de su stack.

Automatización de rotación

El CLI de Passwork (passwork-cli) y el SDK de Python soportan un flujo de trabajo de rotación completo. El patrón estándar es: generar el nuevo valor, aplicarlo al sistema objetivo, validar que el sistema lo acepta, luego escribir el nuevo valor en Passwork. Ese orden es intencional. Actualizar Passwork primero, antes de que el sistema objetivo confirme el cambio, deja las dos fuentes desincronizadas.

Un script de rotación de PostgreSQL usando el CLI:

#!/bin/bash
set -euo pipefail

NEW_PASS=$(openssl rand -base64 32 | tr -d '=+/' | cut -c1-32)

# Apply to the database first
psql -h pg.prod.internal -U postgres \
  -c "ALTER ROLE app_user WITH PASSWORD '${NEW_PASS}';"

# Then update Passwork — only reached if the database command succeeded
passwork-cli update --password-id "$PASSWORK_ITEM_ID" --password "$NEW_PASS"

Si el comando de base de datos falla, set -euo pipefail detiene el script antes de que Passwork se actualice. La bóveda refleja el estado real del sistema objetivo, no un estado esperado.

El modo exec maneja la otra dirección: recuperar secretos en tiempo de ejecución sin escribirlos en disco o en el historial de shell:

passwork-cli exec --password-id "$DB_CREDS_ID" -- ./start-service.sh

La credencial se inyecta como una variable de entorno durante la duración del proceso hijo. No aparece en la salida de ps después de que el proceso termina y no se escribe en ningún log que el CLI produzca.

Para integraciones API, Passwork 7.6.0 añadió endpoints dedicados de rotación de tokens. Las cuentas de servicio tienen su propio par de accessToken y refreshToken. Los pipelines de CI/CD pueden rotar sus propias credenciales API programáticamente mediante POST /api/v1/sessions/refresh sin requerir que un administrador intervenga entre ciclos.

Pista de auditoría y evidencia

Cada evento de acceso, modificación de credencial y cambio de permiso se registra en el historial de acciones de Passwork. El log incluye el actor, marca temporal, tipo de acción y recurso afectado. Para integración con SIEM, la exportación de eventos está disponible en formato CEF, lo que significa que la pista de auditoría de Passwork fluye hacia su monitorización de seguridad central en lugar de quedarse en un silo separado.

Para propósitos de cumplimiento, el historial de acciones responde a la pregunta «quién accedió a qué credencial, cuándo y desde qué sesión» para secretos gestionados por humanos sin un proceso de revisión de acceso separado. Los registros de rotación, concesiones de acceso y eventos de revocación están todos presentes en el mismo log.

Passwork tiene certificación ISO 27001 y es compatible con GDPR y NIS2.

Conclusión

Un programa de secretos seguro no se mide por si las credenciales cambian cada 90 días. Se mide por si la organización sabe qué secretos existen, quién los posee, dónde se usan, con qué rapidez pueden revocarse, y qué evidencia demuestra que los controles funcionan.

El ciclo de vida de rotación de secretos da a los equipos una respuesta estructurada a esas preguntas. Inventario primero: encontrar los secretos, nombrar los propietarios, mapear los consumidores. Eliminar credenciales codificadas del código fuente y archivos de configuración.

Centralizar las credenciales compartidas por humanos en un sistema gestionado con control de acceso y registro de auditoría. Automatizar la rotación y revocación donde el sistema objetivo lo soporte. Incorporar validación y reversión en cada flujo de trabajo de rotación.

Mantener la pista de auditoría. Cuando ocurre un incidente, el log es el único registro que indica qué se accedió, por quién y durante cuánto tiempo.

El calendario de rotación es la parte fácil. El trabajo más difícil viene después: encontrar las claves API sin usar desde 2022, rastrear quién posee las credenciales de la bandeja de entrada compartida de la que dependen tres equipos, retirar la contraseña de base de datos que fue «temporal» hace dieciocho meses.

Ese trabajo comienza con tener un lugar donde poner credenciales que no sea una hoja de cálculo — algún lugar con control de acceso, registros de propiedad y un log. Passwork está construido para esa capa del programa de gobernanza. Pruébelo en su infraestructura y vea hasta dónde llega el inventario antes de que se ejecute el primer ciclo de rotación.

Passwork está disponible como solución autoalojada con control total sobre sus datos. Explore las opciones de despliegue

Preguntas frecuentes

¿Cuál es la diferencia entre rotación de secretos y revocación de secretos?

La rotación de secretos reemplaza una credencial con una nueva versión de forma programada o basada en eventos, mientras mantiene el servicio disponible durante toda la transición. La revocación de secretos deshabilita una credencial inmediatamente en respuesta a un evento específico — exposición, compromiso, baja, o cambio de alcance — sin necesariamente reemplazarla según un calendario. La rotación es planificada; la revocación es reactiva.

¿Con qué frecuencia deben rotarse los secretos?

La frecuencia de rotación debe basarse en el riesgo, no ser uniforme. Las credenciales de alta sensibilidad con amplio acceso — contraseñas de bases de datos de producción, claves API de administrador, tokens de cuentas de servicio — deberían rotar cada 30 a 90 días. Las credenciales de menor sensibilidad con alcance reducido pueden rotar con menos frecuencia. Cualquier credencial debe rotar inmediatamente después de una exposición sospechada o confirmada, independientemente del calendario.

¿Deben rotarse las claves API automáticamente?

Sí, donde el sistema emisor lo soporte. La rotación automatizada es más consistente, más rápida y produce una mejor pista de auditoría que los procesos manuales. Para claves API emitidas por proveedores SaaS de terceros que no soportan rotación automatizada, documentar un runbook de rotación manual con frecuencia definida, pasos de aprobación y requisitos de validación. La investigación de GitGuardian de 2026 encontró que el 64% de los secretos confirmados como válidos en 2022 seguían siendo explotables cuatro años después — una cifra que refleja la brecha entre tener una política de rotación y ejecutarla en todo el inventario de credenciales.

¿Son mejores los secretos dinámicos que los secretos rotados?

Los secretos dinámicos son preferibles para cargas de trabajo que pueden solicitar y renovar credenciales bajo demanda — pipelines de CI/CD, contenedores efímeros, trabajos de corta duración. Eliminan el problema de rotación al hacer que las credenciales expiren automáticamente. Para aplicaciones de larga duración, sistemas heredados e integraciones de terceros que no pueden solicitar credenciales dinámicamente, los secretos estáticos rotados siguen siendo el estándar. La mayoría de los entornos de producción usan ambos modelos, adaptados al tipo de carga de trabajo.

¿Cómo se rotan secretos sin tiempo de inactividad?

Use la estrategia de dos secretos: generar el nuevo valor, validarlo contra el sistema objetivo, desplegarlo a un subconjunto de consumidores, monitorizar errores, completar el despliegue, luego deshabilitar el valor antiguo después de confirmar que todos los consumidores han migrado. Vincular los consumidores a una versión específica del secreto en lugar de un alias latest en producción. La documentación de Secret Manager de Google Cloud advierte que resolver continuamente latest puede causar interrupciones a nivel de todo el servicio si una versión incorrecta se adopta inmediatamente.

¿Qué debería ocurrir después de que un secreto se expone?

Deshabilitar o revocar el valor comprometido en el sistema emisor — no solo en la bóveda. Generar una credencial de reemplazo. Actualizar todos los sistemas dependientes. Validar que el reemplazo funciona y el valor antiguo ya no otorga acceso. Monitorizar cualquier uso continuado de la credencial revocada. Luego investigar: ¿cuánto tiempo estuvo expuesto, qué se accedió y cómo escapó del entorno previsto? Documentar la línea temporal completa como evidencia del incidente.

¿Qué secretos deberían retirarse en lugar de rotarse?

Cualquier credencial que ya no se necesita debería retirarse, no rotarse. Las credenciales para sistemas desmantelados, empleados que se han ido, integraciones discontinuadas y acuerdos de servicio expirados deberían revocarse y destruirse — no mantenerse en un calendario de rotación. Rotar una credencial innecesaria la mantiene viva y en el alcance. La decisión de retiro debería ser parte de cada ciclo de revisión de acceso.

El estado de la dispersión de secretos en 2026: Hallazgos clave del informe de GitGuardian

28,65 millones de secretos se filtraron en GitHub público en 2025. La IA está acelerando el problema. Los repositorios internos están 6 veces más expuestos que los públicos. Y el 64% de los secretos de 2022 siguen siendo válidos hoy. Esto es lo que significan los datos para su postura de seguridad.

Passwork BlogAlex Muntyan

Dentro de ataques reales a la cadena de suministro: Bitwarden CLI, Axios y Vercel

¿Por qué vulnerar su red cuando los atacantes pueden comprometer una dependencia de confianza con millones de descargas y colarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 demuestran que los ataques a la cadena de suministro ya no son incidentes aislados.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Die Rotation von Secrets scheitert, wenn Teams sie als geplante Passwortänderung behandeln: Rotationszeitpläne einrichten, auf einen Tresor verweisen und fertig. Dann wird ein API-Schlüssel aus einer CI/CD-Variable geleakt, die niemand inventarisiert hat. Oder ein Rotationsjob läuft zweimal, erzeugt eine Race Condition und legt einen Dienst lahm. Oder ein Mitarbeiter verlässt das Unternehmen, und sein SSH-Schlüssel bleibt sechs Monate aktiv, weil niemand ihn einem Besitzer zugeordnet hat.

Ein Lebenszyklus der Secrets-Rotation ist der kontrollierte Prozess zum Erstellen, Speichern, Verwenden, Rotieren, Widerrufen und Außerbetriebnehmen von Anmeldedaten wie API-Schlüsseln, Passwörtern, Tokens, Zertifikaten und Verschlüsselungsschlüsseln. Sein Ziel ist es, die Lebensdauer und den Schadensradius kompromittierter Anmeldedaten zu reduzieren und gleichzeitig die Systemverfügbarkeit zu gewährleisten.

Rotation ist eine Kontrolle innerhalb dieses Prozesses. Ohne die umgebende Struktur (Inventar, Eigentümerschaft, Zugriffskontrolle, Validierung, Bereinigung und Prüfnachweise) ändert die Rotation allein den Wert einer Anmeldedaten, ohne ihr Risiko zu reduzieren.

Wichtige Erkenntnisse

• Ein Lebenszyklus der Secrets-Rotation hat sieben Phasen: Erstellung, Klassifizierung, Speicherung, Verteilung, Rotation, Widerruf und Außerbetriebnahme.
• Rotation ist eine Kontrolle innerhalb eines größeren Systems, nicht das System selbst. Ohne die umgebende Struktur ändert die Rotation den Wert einer Anmeldedaten, ohne ihr Risiko zu reduzieren.
• Das Expositionsproblem ist strukturell, nicht prozedural. GitGuardian entdeckte 28,65 Millionen neue hardcodierte Secrets auf dem öffentlichen GitHub im Jahr 2025 – ein Anstieg von 34 % im Jahresvergleich. Von den 2022 als gültig bestätigten Secrets waren 64 % im Januar 2026 noch ausnutzbar (GitGuardian State of Secrets Sprawl 2026).
• Sichere Rotation hat eine bestimmte Reihenfolge. Den neuen Wert generieren, gegen das Zielsystem validieren, schrittweise ausrollen, dann den alten deaktivieren. Das Überspringen der Validierung oder das gleichzeitige Umschalten aller Verbraucher führt zu Ausfällen durch Rotation.
• Dynamische Secrets eliminieren das Rotationsproblem für unterstützte Workloads. Rotierte statische Secrets bleiben für Legacy-Systeme, Drittanbieter-Integrationen und lang laufende Workloads erforderlich, die keine Anmeldedaten auf Abruf anfordern können.
• Notfall-Widerruf erfordert ein vollständiges Inventar. Wenn Sie nicht alle Verbraucher eines Secrets innerhalb von Minuten nach einer vermuteten Exposition identifizieren können, können Sie den Vorfall nicht eindämmen. Das Inventar ist die Voraussetzung für alles andere.

Was ist der Lebenszyklus der Secrets-Rotation?

Der Lebenszyklus der Secrets-Rotation ist das End-to-End-Governance-Modell für die Verwaltung von Maschinen- und Benutzeranmeldedaten von dem Moment an, in dem sie erstellt werden, bis zu dem Moment, in dem sie dauerhaft vernichtet werden. Er behandelt Rotation als eine Phase innerhalb eines breiteren betrieblichen Prozesses, nicht als periodische Passwortänderungsaufgabe.

Die Unterscheidung ist wichtig, weil Rotation ohne die umgebenden Kontrollen ein falsches Sicherheitsgefühl erzeugt. Eine Anmeldedaten, die alle 30 Tage rotiert, aber keinen benannten Besitzer, kein Verbraucherinventar und keinen Widerrufspfad hat, ist immer noch eine Verbindlichkeit.

Jede Phase hat einen eigenen Satz von Kontrollen. Das Überspringen der Klassifizierung bedeutet, dass Rotationsziele unbekannt sind. Das Überspringen der Bereinigung bedeutet, dass alte Anmeldedaten sich ansammeln und Exposition verursachen. Das Lebenszyklusmodell zwingt Teams, jede Phase als bewusste betriebliche Entscheidung zu behandeln.

Warum Rotation allein das Anmeldedatenrisiko nicht löst

Rotation reduziert das Expositionsfenster für eine kompromittierte Anmeldedaten. Sie eliminiert nicht die Anmeldedaten als Angriffsfläche und tut nichts für Anmeldedaten, die nie inventarisiert, nie sicher gespeichert oder nach einer Exposition nie widerrufen wurden.

Das Ausmaß des Problems nicht verwalteter Anmeldedaten ist strukturell. GitGuardian entdeckte 28,65 Millionen neue hardcodierte Secrets auf dem öffentlichen GitHub im Jahr 2025 – ein Anstieg von 34 % gegenüber dem Vorjahr und der größte jährliche Anstieg, den das Unternehmen jemals verzeichnet hat. Diese Zahl deckt nur öffentliche Repositories ab. Von den Secrets, die GitGuardian 2022 als gültig bestätigt hat, waren 64 % im Januar 2026 noch ausnutzbar, vier Jahre nachdem sie erstmals geleakt wurden.

Das Muster ist konsistent: Secrets verlassen ihre vorgesehene Umgebung, niemand bemerkt es, und Rotationszeitpläne erfassen sie nicht, weil sich die exponierte Kopie vollständig außerhalb des Tresors befindet.

Rotation sollte als Kontrolle verstanden werden, die die Lebensdauer von Anmeldedaten reduziert, die ordnungsgemäß verwaltet werden. Sie ist kein Ersatz für die Eliminierung hardcodierter Anmeldedaten, die Durchsetzung von Least Privilege, die Prüfung von Zugriffen, das Scannen nach Secret Sprawl oder das Widerrufen veralteter Werte. All diese Kontrollen müssen vorhanden sein, damit Rotation ihre beabsichtigte Wirkung entfalten kann.

Welche Secrets benötigen Lebenszyklusverwaltung?

Jede Anmeldedaten, die Zugang zu einem System, Datenspeicher, Dienst oder einer Identität gewährt, benötigt Lebenszyklusverwaltung. Der praktische Umfang ist breiter, als die meisten Teams zunächst annehmen.

Der Inventarschritt (zu wissen, welche Secrets existieren, wo sie sich befinden, wem sie gehören und worauf sie zugreifen) ist die Voraussetzung für alles andere. Sie können nicht rotieren, was Sie nicht gefunden haben.

Die sieben Phasen eines sicheren Lebenszyklus der Secrets-Rotation

1. Secrets mit Eigentümerschaft und Zweck erstellen

Jedes Secret benötigt einen benannten Besitzer, einen dokumentierten Systemzweck, ein Umgebungs-Tag, eine Sensitivitätsklassifizierung, ein erwartetes Ablaufdatum und einen genehmigten Speicherort, bevor es den Erstellungsschritt verlässt. Dies sind die Daten, die Rotation, Widerruf und Bereinigung ermöglichen.

Ein Secret, das ohne Besitzer erstellt wird, hat niemanden, der für seine Rotation verantwortlich ist. Ein Secret, das ohne Verbraucherliste erstellt wird, hat niemanden, der bei Änderungen benachrichtigt wird. Ein Secret, das ohne Ablaufdatum erstellt wird, hat keinen Auslöser für eine Überprüfung.

Erlauben Sie Entwicklern nicht, Secrets in Tickets, Chat-Nachrichten, Tabellenkalkulationen oder lokalen Dateien zu erstellen. Der Erstellungsschritt sollte direkt zu einem verwalteten Tresor oder Secret Manager führen. Wenn nicht, ist das Secret bereits außerhalb des Lebenszyklus, bevor es einmal verwendet wurde.

2. Secrets in einem verwalteten Tresor speichern, nicht im Code

Zentralisierte Speicherung ist es, was den Rest des Lebenszyklus betriebsfähig macht. Ein Tresor bietet Zugriffskontrolle, Audit-Logging, Versionshistorie, Rotations-Hooks und Widerrufsfähigkeit. Eine .env-Datei in einem Repository bietet nichts davon.

Secret Sprawl – Anmeldedaten, die über Repositories, Chat-Tools, Konfigurationsdateien und persönliche Passwort-Speicher verstreut sind – ist die direkte Folge des Überspringens dieses Schritts. Die Annahme, dass interne Systeme sicherer sind als öffentliche, hält einer Messung nicht stand.

GitGuardians Forschung von 2026 ergab, dass interne Repositories mit 6-mal höherer Wahrscheinlichkeit ein hardcodiertes Secret enthalten als öffentliche, und dass 28 % der internen Vorfälle vollständig außerhalb der Codebasis entstehen – in Slack, Jira und Confluence – mit einer höheren kritischen Schweregrad-Rate als codebasierte Funde. „Privat" ist keine Sicherheitskontrolle.

Für Teams, in denen Admins, IT-Mitarbeiter und Geschäftsbereiche kontrollierten Zugang zu gemeinsamen Anmeldedaten benötigen, kann ein Unternehmens-Passwortmanager die menschliche Seite der Secrets-Governance unterstützen: zentralisierte Speicherung, strukturierter Zugang, Eigentümerschaftsaufzeichnungen und prüfungsfreundliche Handhabung von Anmeldedaten. Machine-to-Machine-Secrets erfordern weiterhin lebenszyklus-bewusste technische Kontrollen, aber der menschliche Zugang zu sensiblen Anmeldedaten sollte nicht in Chat-Threads, Tabellenkalkulationen oder persönlichen Passwort-Speichern leben.

3. Zugang nach dem Least-Privilege-Prinzip gewähren

Secret-Verbraucher sollten nur die Anmeldedaten erhalten, die sie benötigen, auf den engstmöglichen Berechtigungssatz beschränkt, für den kürzestmöglichen Zeitraum. Dies gilt für menschliche Benutzer, Service-Accounts, CI/CD-Pipelines und nicht-menschliche Identitäten.

Eine CI/CD-Pipeline, die auf Staging deployt, benötigt keine Produktions-Datenbank-Anmeldedaten. Ein Service-Account, der aus einem einzelnen S3-Bucket liest, benötigt keinen kontoweiten Speicherzugang. Ein Entwickler, der ein Produktionsproblem debuggen muss, benötigt keinen permanenten Zugang zum Produktions-Tresor.

Least Privilege reduziert den Schadensradius. Wenn eine Anmeldedaten kompromittiert wird, ist der Zugang des Angreifers auf das beschränkt, was diese Anmeldedaten tun durfte. Übermäßig bereitgestellte Secrets verwandeln jede Exposition in eine potenzielle vollständige Systemkompromittierung.

4. Secrets verwenden, ohne sie zu exponieren

Die Nutzungsphase ist der Zeitpunkt, an dem Secrets am häufigsten ihre vorgesehene Umgebung verlassen. Anwendungen geben Konfigurationswerte in Logs aus. Entwickler fügen Anmeldedaten in Tickets ein, um Kontext zu teilen. Die Shell-Historie erfasst Datenbankverbindungszeichenfolgen. Fehlerantworten enthalten Authentifizierungsdetails.

Laufzeit-Injektion hält Secrets aus dem Code heraus. Dienste sollten Anmeldedaten beim Start über einen Tresor-Client oder Secret-Injection-Sidecar abrufen, nicht aus committeten Konfigurationsdateien. Die Passwork CLI unterstützt einen exec-Modus, der Anmeldedaten als Umgebungsvariablen für die Dauer eines Befehls injiziert, ohne sie in die Shell-Historie oder das Dateisystem zu schreiben. Pre-Commit-Hooks und Secret-Scanning-Tools fangen versehentliche Commits ab, bevor sie ein Repository erreichen.

Die spezifischen Kontrollen, die hier wichtig sind: Secrets aus Anwendungsprotokollen schwärzen, Anmeldedaten-Logging in Debug-Modi deaktivieren, Log-Aggregations-Pipelines auf Secret-Muster scannen und niemals Anmeldedaten in Fehlermeldungen aufnehmen, die an Clients zurückgegeben werden. Dies sind keine exotischen Maßnahmen – sie sind die Basis für jede Produktionsumgebung, die sensible Anmeldedaten verarbeitet.

5. Secrets sicher rotieren

Rotation ist die Phase, für die die meisten Teams einen Prozess haben. Die betrieblichen Fehler passieren in den Details: den neuen Wert validieren, bevor er aktiviert wird, kontrollieren, welche Verbraucher die neue Version wann übernehmen, auf Fehler überwachen und den alten Wert erst deaktivieren, nachdem bestätigt wurde, dass der neue funktioniert.

Die Secret Manager-Dokumentation von Google Cloud ist explizit bezüglich eines bestimmten Fehlermodus: Das kontinuierliche Auflösen des latest-Alias in Produktions-Workloads erzeugt ein dienstweites Ausfallrisiko, wenn eine fehlerhafte Secret-Version ausgerollt wird. Der neue Wert wird sofort von allen Verbrauchern übernommen, ohne schrittweises Rollout und ohne automatisches Rollback. Dies ist ein reales betriebliches Risiko, kein theoretisches.

Die sichere Rotationssequenz:

1. Inventarisieren Sie das Secret, seinen Besitzer, seine Verbraucher und seinen Abhängigkeitspfad.
2. Generieren Sie den neuen Wert, ohne den alten zu invalidieren.
3. Speichern Sie den neuen Wert als neue Version im Tresor oder Secret Manager.
4. Validieren Sie den neuen Wert gegen das Zielsystem, bevor ein Verbraucher ihn verwendet.
5. Rollen Sie auf eine kleine Untergruppe von Verbrauchern oder die nächste Deployment-Welle aus.
6. Überwachen Sie Authentifizierungsfehler, Fehlerraten, Latenz und Anwendungsgesundheit.
7. Vervollständigen Sie das Rollout auf alle Verbraucher.
8. Deaktivieren Sie den alten Wert und überwachen Sie auf unerwartete Nutzung.
9. Widerrufen oder vernichten Sie den alten Wert, nachdem das Sicherheitsfenster geschlossen ist.
10. Dokumentieren Sie Prüfnachweise und aktualisieren Sie das Inventar.

Schritte 4 und 8 werden am häufigsten übersprungen. Das Überspringen von Schritt 4 bedeutet, dass ein fehlerhafter Wert in die Produktion gelangen kann. Das Überspringen von Schritt 8 bedeutet, dass der alte Wert unbegrenzt aktiv bleibt, was den Zweck der Rotation zunichtemacht.

6. Secrets nach Exposition, Offboarding oder Änderungen des Umfangs widerrufen

Widerruf unterscheidet sich von Rotation. Rotation ersetzt eine Anmeldedaten nach einem Zeitplan. Widerruf deaktiviert eine Anmeldedaten sofort als Reaktion auf ein bestimmtes Ereignis: bestätigte Exposition, vermutete Kompromittierung, Mitarbeiteraustritt, Rollenwechsel, Anbietervorfall oder Systemstilllegung.

Der Notfall-Widerrufs-Workflow:

1. Erkennen oder bestätigen Sie das Expositionsereignis.
2. Identifizieren Sie den Besitzer des Secrets, die Verbraucher und alle abhängigen Systeme.
3. Deaktivieren oder widerrufen Sie den kompromittierten Wert beim ausstellenden System, nicht nur im Tresor.
4. Generieren Sie eine Ersatz-Anmeldedaten.
5. Aktualisieren Sie alle abhängigen Systeme mit dem neuen Wert.
6. Validieren Sie, dass der Ersatz funktioniert und der alte Wert keinen Zugang mehr gewährt.
7. Überwachen Sie auf jede weitere Nutzung der widerrufenen Anmeldedaten.
8. Untersuchen Sie die Exposition: Wie ist sie passiert, worauf wurde zugegriffen, wie lange?
9. Dokumentieren Sie den Vorfall, den Widerrufszeitplan und die Behebungsschritte.

Schritt 3 ist der Punkt, an dem der Widerruf am häufigsten fehlschlägt. Teams deaktivieren das Secret in ihrem Tresor, vergessen aber, es beim externen System zu invalidieren – der Datenbank, dem API-Anbieter, der Identitätsplattform. Der alte Wert bleibt an der Quelle gültig. Der Tresor-Eintrag sagt „widerrufen"; die Anmeldedaten funktioniert noch.

7. Alte Secrets außer Betrieb nehmen und prüfen

Alte Anmeldedaten „für alle Fälle" aufzubewahren, ist ein häufiger Instinkt und ein reales Risiko. Jeder alte Wert, der zugänglich bleibt, ist eine Anmeldedaten, die verwendet werden kann – von einem Angreifer, der sie in einem Log, einem Backup, einem stillgelegten System oder einem lokalen Cache eines Entwicklers gefunden hat.

Die Außerbetriebnahme-Sequenz: den alten Wert zuerst deaktivieren, während eines definierten Sicherheitsfensters auf unerwartete Nutzung überwachen, dann gemäß Richtlinie und Compliance-Anforderungen vernichten oder archivieren. Die Länge des Sicherheitsfensters hängt vom Secret-Typ und der Kritikalität der abhängigen Systeme ab – typischerweise 24 bis 72 Stunden für die meisten Anwendungs-Anmeldedaten, länger für Verschlüsselungsschlüssel, bei denen eine Neuverschlüsselung erforderlich sein kann.

Prüfnachweise für die Außerbetriebnahme sollten enthalten: das Datum, an dem der alte Wert deaktiviert wurde, den Überwachungszeitraum, die Bestätigung, dass keine unerwartete Nutzung stattfand, und das Datum der endgültigen Vernichtung oder Archivierung. Dies ist die Dokumentation, die einen Prüfer zufriedenstellt, der fragt: „Woher wissen Sie, dass die alte Anmeldedaten weg ist?"

Manuelle Rotation vs. automatisierte Rotation

Manuelle Rotation ist nicht von Natur aus falsch. Für eine kleine Gruppe hochsensibler Admin-Anmeldedaten, die sich selten ändern, kann ein dokumentierter manueller Prozess mit Genehmigungsschleusen und Prüfprotokollen angemessen sein. Das Problem ist, wenn manuelle Rotation der Standard für alles ist – sie skaliert nicht, sie ist inkonsistent, und der Prüfpfad ist normalerweise eine Tabellenkalkulation mit einer Datumsspalte.

Automatisierung sollte der Standard für jeden Secret-Typ sein, bei dem das Zielsystem sie unterstützt. IBMs Erkenntnis, dass umfassende Sicherheits-KI und Automatisierung die Kosten von Sicherheitsverletzungen um durchschnittlich 1,9 Millionen Dollar reduzierte, spiegelt ein breiteres Prinzip wider: Konsistente, automatisierte Kontrollen übertreffen inkonsistente manuelle in großem Maßstab.

Rotierte Secrets vs. dynamische Secrets

Dynamische Secrets sind Anmeldedaten, die bei Bedarf mit einer kurzen TTL oder Lease ausgestellt werden. Jeder anfragende Workload erhält eine eindeutige Anmeldedaten, die automatisch abläuft – es gibt nichts zu rotieren, weil nichts langlebig ist. HashiCorp Vaults Database Secrets Engine ist das Standardbeispiel: Jede Anwendungsanfrage erhält einen temporären Datenbankbenutzer, der abläuft, wenn die Lease endet.

Rotierte Secrets sind statische Anmeldedaten, die periodisch durch einen neuen Wert ersetzt werden. Sie bleiben für Systeme erforderlich, die keine dynamischen Anmeldedaten ausstellen können: die meisten SaaS-APIs, viele Legacy-Datenbanken, langlebige Service-Accounts und Drittanbieter-Integrationen, bei denen Sie den Anmeldedaten-Aussteller nicht kontrollieren.

Dynamische Secrets reduzieren die Angriffsfläche für Workloads, die sie unterstützen können. Sie eliminieren nicht die Notwendigkeit von Lebenszykluskontrollen für die Anmeldedaten, die nicht dynamisch gemacht werden können. Beide Modelle koexistieren in den meisten realen Umgebungen.

Wie man Secrets ohne Ausfallzeit rotiert

Die Zwei-Secret-Strategie ist das Kernmuster für Rotation ohne Ausfallzeit. Die alte Anmeldedaten und die neue Anmeldedaten sind während des Übergangsfensters gleichzeitig gültig. Die Verbraucher migrieren zum neuen Wert, der alte Wert wird als ungenutzt bestätigt, dann wird der alte Wert deaktiviert.

Dies erfordert, dass das externe System – die Datenbank, der API-Anbieter, die Identitätsplattform – mehrere gleichzeitig gültige Anmeldedaten unterstützt. Die meisten modernen Systeme tun das. Für diejenigen, die das nicht tun, erfordert das Rotationsfenster ein Wartungsfenster oder einen Blue-Green-Deployment-Ansatz.

Die spezifischen Fehlermodi, gegen die man entwerfen sollte:

• Verbraucher, die Anmeldedaten im Speicher zwischenspeichern und nicht bis zum Neustart neu laden. Planen Sie rollende Neustarts oder einen Cache-Invalidierungsmechanismus ein.
• Rotationsjobs, die gleichzeitig laufen und widersprüchliche Versionen erzeugen. Verwenden Sie Sperren, idempotentes Design und Statuslabels, um Doppelrotation zu verhindern.
• Health Checks, die den tatsächlichen Anmeldedaten-Pfad nicht testen. Ein Dienst, der als gesund meldet, aber einen zwischengespeicherten alten Wert verwendet, wird ausfallen, wenn der alte Wert deaktiviert wird.

Die Rotationsdokumentation von Google Cloud empfiehlt, Anwendungen an eine bestimmte Secret-Version zu binden statt an den latest-Alias für Produktions-Workloads. Lösen Sie die Version zur Deployment-Zeit auf, speichern Sie den Versionsnamen in der Konfiguration und rollen Sie sie über die Standard-Deployment-Pipeline aus. Dies gibt Ihnen gestaffeltes Rollout, Rollback-Fähigkeit und vorhersagbares Verhalten über Neustarts hinweg.

Das Muster des wiedereintrittsfähigen Rotationsjobs ist wichtig für automatisierte Rotation: Der Job muss von jedem Punkt aus neu starten können, ohne doppelte Anmeldedaten zu erstellen oder das System in einem inkonsistenten Zustand zu hinterlassen. Konfigurieren Sie Wiederholungen, aber konfigurieren Sie auch maximale Parallelität, um zu verhindern, dass parallele Ausführungen in Konflikt geraten.

Häufige Fehlermodi und wie man sie verhindert

Der teuerste Fehlermodus ist der zweite: den Tresor-Eintrag aktualisieren, während die alte Anmeldedaten beim externen System gültig bleibt. Dies ist besonders häufig bei Datenbank-Anmeldedaten, bei denen der Tresor-Eintrag „rotiert" anzeigt, aber das Datenbankpasswort nie tatsächlich geändert wurde. Die Anmeldedaten ist immer noch gültig, der Tresor zeigt sie als rotiert an, und das Audit-Log sieht sauber aus. Widerruf an der Quelle testen, nicht nur am Tresor.

Passwork bietet IT-Teams einen strukturierten Tresor mit rollenbasiertem Zugriff, Eigentümerschaftsaufzeichnungen und einem vollständigen Audit-Log für gemeinsame Anmeldedaten. Sehen Sie, wie es in Ihr Governance-Programm passt

Compliance und Prüfnachweise für den Secrets-Lebenszyklus

Compliance-Frameworks schreiben Rotationsintervalle nicht auf universelle Weise vor. Was sie erfordern – in PCI DSS-, SOC 2-, HIPAA- und DSGVO-Umgebungen – ist der Nachweis, dass Zugriffskontrollen existieren, konsistent funktionieren und überprüft werden. Die genaue Anforderung hängt von Umfang, Kontroll-Mapping und Prüferinterpretation ab. Machen Sie keine pauschalen Aussagen darüber, was eine Vorschrift vorschreibt, ohne die spezifische Kontrollsprache zu lesen.

Was Lebenszyklusverwaltung produziert, das Prüfer sehen wollen:

• Inventaraufzeichnungen, die zeigen, welche Secrets existieren, wem sie gehören und worauf sie zugreifen
• Zugriffskontrollnachweise: wer die Berechtigung hat, jedes Secret abzurufen und warum
• Rotationsaufzeichnungen: wann jede Anmeldedaten rotiert wurde, durch welchen Prozess und ob die Validierung bestanden wurde
• Widerrufsaufzeichnungen: wann Anmeldedaten deaktiviert wurden, was den Widerruf ausgelöst hat, und Bestätigung, dass der alte Wert nicht mehr funktioniert
• Zugriffsüberprüfungen: periodische Bestätigung, dass Zugriffsgewährungen noch angemessen sind
• Incident-Dokumentation: für jedes Expositionsereignis ein Zeitplan von der Erkennung bis zur Behebung

Der Prüfpfad ist kein Nebenprodukt guter Secrets-Verwaltung – er ist eine Designanforderung. Systeme, die Rotationsereignisse, Zugriffsanfragen und Widerrufsaktionen nicht protokollieren, können die Nachweise nicht erbringen, die Compliance erfordert.

IBMs X-Force Threat Intelligence Index 2026 berichtete über 300.000 KI-Chatbot-Anmeldedaten, die im Dark Web zum Verkauf angeboten wurden. Das Problem der Anmeldedaten-Exposition schrumpft nicht. Prüfer und Regulierungsbehörden achten auf denselben Trend.

Eine praktische Richtlinienvorlage für den Lebenszyklus der Secrets-Rotation

Eine Richtlinie ohne betriebliche Details ist ein Dokument, das unterschrieben und ignoriert wird. Die nachstehende Vorlage ist ein Grundgerüst – füllen Sie die Details für Ihre Umgebung aus, lassen Sie sie von Rechts- und Sicherheitsabteilung überprüfen und fügen Sie sie Ihrem Secrets-Governance-Programm bei.

Die Ausnahmenzeile ist wichtig. Jede Umgebung hat Systeme, die keine automatisierte Rotation unterstützen können – Legacy-Anwendungen, Drittanbieterdienste mit manueller Schlüsselverwaltung, Hardware-Appliances. Dokumentieren Sie sie explizit, definieren Sie die kompensierenden Kontrollen und überprüfen Sie sie nach einem Zeitplan. Eine undokumentierte Ausnahme ist ein nicht verwaltetes Risiko.

Wo Passwork in ein Secrets-Governance-Programm passt

Die sieben Lebenszyklusphasen benötigen unterschiedliche Werkzeuge auf unterschiedlichen Ebenen. Dynamische Credential Engines und KMS-Systeme verarbeiten Machine-to-Machine-Secrets in Infrastrukturmaßstab. Was sie nicht ersetzen, ist eine verwaltete Ebene für Anmeldedaten, die Menschen erstellen, teilen und rotieren: Admin-Accounts, Break-Glass-Anmeldedaten, gemeinsame Dienstschlüssel, API-Schlüssel, die von Betriebsteams verwaltet werden, und alles, was derzeit in einer Tabellenkalkulation, einem gemeinsamen Posteingang oder dem persönlichen Passwortmanager einer Person lebt.

Passwork deckt diese Ebene ab. Die folgenden Abschnitte ordnen seine Fähigkeiten den Lebenszyklusphasen zu, in denen von Menschen verwaltete Anmeldedaten die meiste Governance benötigen.

Speicherung und Klassifizierung

Passwork speichert Anmeldedaten in strukturierten Tresoren, die nach Ordner, Umgebung und Team organisiert sind. Jeder Eintrag enthält Metadaten: URL, Login, benutzerdefinierte Felder, Tags und Notizen. Sie können Ihre Infrastrukturtopologie im Tresor-Layout spiegeln (separate Tresore für Produktion und Staging, Ordner nach Team oder Dienst), was sowohl Zugriffsscoping als auch Rotationsinventarisierung praktisch macht.

Das Verschlüsselungsmodell ist hier wichtig. Die serverseitige Speicherung verwendet AES-256-CFB. Mit aktivierter clientseitiger Verschlüsselung (CSE) wird jeder Tresor im Browser verschlüsselt, bevor er das Gerät verlässt. Der Server speichert nur Chiffretext; die Entschlüsselung erfordert den Masterschlüssel, der aus dem Masterpasswort des Benutzers abgeleitet und niemals übertragen wird. Für Organisationen, die sensible Anmeldedaten unter keinen Umständen über einen externen Dienst leiten können, eliminiert das CSE-Modell diese Abhängigkeit vollständig.

Zugriffskontrolle und Least Privilege

Rollenbasierte und gruppenbasierte Berechtigungen ermöglichen es Ihnen, Tresor-Zugang einem Team zu gewähren statt Einzelpersonen. Wenn ein Ingenieur der DevOps-Gruppe beitritt, erbt er automatisch den Tresor-Zugang der Gruppe. Wenn er das Unternehmen verlässt, widerrufen Sie den Zugang einmal – nicht einmal pro Tresor.

Der Zugriffsumfang ist granular. Jeder Tresor oder Ordner hat unabhängige Berechtigungen. Ein CI/CD-Service-Account erhält Lesezugriff auf den spezifischen Ordner, den er benötigt, und nichts anderes. Ein Sicherheitsprüfer erhält schreibgeschützten Zugang zu bestimmten Tresoren ohne die Möglichkeit, Werte zu ändern oder zu exportieren. Passwork integriert sich mit AD/LDAP und unterstützt SAML SSO, sodass Bereitstellung und Offboarding denselben Identitäts-Workflows folgen wie der Rest Ihres Stacks.

Rotationsautomatisierung

Die CLI von Passwork (passwork-cli) und das Python SDK unterstützen einen vollständigen Rotations-Workflow. Das Standardmuster ist: den neuen Wert generieren, auf das Zielsystem anwenden, validieren, dass das System ihn akzeptiert, dann den neuen Wert in Passwork schreiben. Diese Reihenfolge ist beabsichtigt. Passwork zuerst zu aktualisieren, bevor das Zielsystem die Änderung bestätigt, bringt die beiden Quellen aus dem Gleichgewicht.

Ein PostgreSQL-Rotationsskript mit der CLI:

#!/bin/bash
set -euo pipefail

NEW_PASS=$(openssl rand -base64 32 | tr -d '=+/' | cut -c1-32)

# Apply to the database first
psql -h pg.prod.internal -U postgres \
  -c "ALTER ROLE app_user WITH PASSWORD '${NEW_PASS}';"

# Then update Passwork — only reached if the database command succeeded
passwork-cli update --password-id "$PASSWORK_ITEM_ID" --password "$NEW_PASS"

Wenn der Datenbankbefehl fehlschlägt, stoppt set -euo pipefail das Skript, bevor Passwork aktualisiert wird. Der Tresor spiegelt den tatsächlichen Zustand des Zielsystems wider, nicht einen erhofften Zustand.

Der exec-Modus behandelt die andere Richtung: Secrets zur Laufzeit abrufen, ohne sie auf die Festplatte oder in die Shell-Historie zu schreiben:

passwork-cli exec --password-id "$DB_CREDS_ID" -- ./start-service.sh

Die Anmeldedaten wird als Umgebungsvariable für die Dauer des Kindprozesses injiziert. Sie erscheint nicht in der ps-Ausgabe, nachdem der Prozess beendet ist, und wird in keinem von der CLI erstellten Log geschrieben.

Für API-Integrationen hat Passwork 7.6.0 dedizierte Token-Rotations-Endpoints hinzugefügt. Service-Accounts haben ihr eigenes accessToken- und refreshToken-Paar. CI/CD-Pipelines können ihre eigenen API-Anmeldedaten programmatisch über POST /api/v1/sessions/refresh rotieren, ohne dass ein Administrator zwischen den Zyklen eingreifen muss.

Prüfpfad und Nachweise

Jedes Zugriffsereignis, jede Änderung von Anmeldedaten und jede Berechtigungsänderung wird in der Aktionshistorie von Passwork aufgezeichnet. Das Log enthält den Akteur, den Zeitstempel, den Aktionstyp und die betroffene Ressource. Für die SIEM-Integration ist der Ereignisexport im CEF-Format verfügbar, was bedeutet, dass der Prüfpfad von Passwork in Ihre zentrale Sicherheitsüberwachung fließt, anstatt in einem separaten Silo zu verbleiben.

Für Compliance-Zwecke beantwortet die Aktionshistorie die Frage „Wer hat auf welche Anmeldedaten zugegriffen, wann und von welcher Sitzung aus" für von Menschen verwaltete Secrets ohne einen separaten Zugriffsüberprüfungsprozess. Rotationsaufzeichnungen, Zugriffsgewährungen und Widerrufsereignisse sind alle im selben Log vorhanden.

Passwork verfügt über eine ISO 27001-Zertifizierung und ist DSGVO- und NIS2-konform.

Fazit

Ein sicheres Secrets-Programm wird nicht daran gemessen, ob Anmeldedaten alle 90 Tage geändert werden. Es wird daran gemessen, ob die Organisation weiß, welche Secrets existieren, wem sie gehören, wo sie verwendet werden, wie schnell sie widerrufen werden können und welche Nachweise belegen, dass die Kontrollen funktionieren.

Der Lebenszyklus der Secrets-Rotation gibt Teams eine strukturierte Antwort auf diese Fragen. Zuerst inventarisieren: die Secrets finden, die Besitzer benennen, die Verbraucher zuordnen. Hardcodierte Anmeldedaten aus Quellcode und Konfigurationsdateien entfernen.

Von Menschen gemeinsam genutzte Anmeldedaten in einem verwalteten System mit Zugriffskontrolle und Audit-Logging zentralisieren. Rotation und Widerruf automatisieren, wo das Zielsystem es unterstützt. Validierung und Rollback in jeden Rotations-Workflow einbauen.

Den Prüfpfad aufbewahren. Wenn ein Vorfall passiert, ist das Log der einzige Nachweis, der zeigt, worauf zugegriffen wurde, von wem und wie lange.

Der Rotationszeitplan ist der einfache Teil. Die schwierigere Arbeit kommt danach: die API-Schlüssel finden, die seit 2022 ungenutzt sind, herausfinden, wem die gemeinsamen Posteingangs-Anmeldedaten gehören, auf die drei Teams angewiesen sind, das Datenbankpasswort außer Betrieb nehmen, das vor achtzehn Monaten „temporär" war.

Diese Arbeit beginnt damit, einen Ort zu haben, an dem Anmeldedaten abgelegt werden können, der keine Tabellenkalkulation ist – irgendwo mit Zugriffskontrolle, Eigentümerschaftsaufzeichnungen und einem Log. Passwork ist für diese Ebene des Governance-Programms gebaut. Probieren Sie es in Ihrer Infrastruktur aus und sehen Sie, wie weit das Inventar reicht, bevor der erste Rotationszyklus läuft.

Passwork ist als Self-Hosted-Lösung mit voller Kontrolle über Ihre Daten verfügbar. Entdecken Sie die Bereitstellungsoptionen

Häufig gestellte Fragen

Was ist der Unterschied zwischen Secret-Rotation und Secret-Widerruf?

Secret-Rotation ersetzt eine Anmeldedaten durch eine neue Version auf einer geplanten oder ereignisgesteuerten Basis, während der Dienst während des Übergangs verfügbar bleibt. Secret-Widerruf deaktiviert eine Anmeldedaten sofort als Reaktion auf ein bestimmtes Ereignis – Exposition, Kompromittierung, Offboarding oder Änderung des Umfangs – ohne sie notwendigerweise nach einem Zeitplan zu ersetzen. Rotation ist geplant; Widerruf ist reaktiv.

Wie oft sollten Secrets rotiert werden?

Die Rotationsfrequenz sollte risikobasiert sein, nicht einheitlich. Hochsensible Anmeldedaten mit breitem Zugriff – Produktions-Datenbankpasswörter, Admin-API-Schlüssel, Service-Account-Tokens – sollten alle 30 bis 90 Tage rotiert werden. Weniger sensible Anmeldedaten mit engem Umfang können weniger häufig rotiert werden. Jede Anmeldedaten sollte sofort nach einer vermuteten oder bestätigten Exposition rotiert werden, unabhängig vom Zeitplan.

Sollten API-Schlüssel automatisch rotiert werden?

Ja, wo das ausstellende System es unterstützt. Automatisierte Rotation ist konsistenter, schneller und erzeugt einen besseren Prüfpfad als manuelle Prozesse. Für API-Schlüssel, die von Drittanbieter-SaaS-Anbietern ausgestellt werden, die keine automatisierte Rotation unterstützen, dokumentieren Sie ein manuelles Rotations-Runbook mit definierter Häufigkeit, Genehmigungsschritten und Validierungsanforderungen. GitGuardians Forschung von 2026 ergab, dass 64 % der 2022 als gültig bestätigten Secrets vier Jahre später noch ausnutzbar waren – eine Zahl, die die Lücke zwischen dem Vorhandensein einer Rotationsrichtlinie und deren Ausführung über das gesamte Anmeldedaten-Inventar widerspiegelt.

Sind dynamische Secrets besser als rotierte Secrets?

Dynamische Secrets sind für Workloads vorzuziehen, die Anmeldedaten bei Bedarf anfordern und erneuern können – CI/CD-Pipelines, ephemere Container, kurzlebige Jobs. Sie eliminieren das Rotationsproblem, indem Anmeldedaten automatisch ablaufen. Für lang laufende Anwendungen, Legacy-Systeme und Drittanbieter-Integrationen, die keine Anmeldedaten dynamisch anfordern können, bleiben rotierte statische Secrets der Standard. Die meisten Produktionsumgebungen verwenden beide Modelle, abgestimmt auf den Workload-Typ.

Wie rotiert man Secrets ohne Ausfallzeit?

Verwenden Sie die Zwei-Secret-Strategie: den neuen Wert generieren, gegen das Zielsystem validieren, auf eine Untergruppe von Verbrauchern ausrollen, auf Fehler überwachen, das Rollout abschließen, dann den alten Wert deaktivieren, nachdem bestätigt wurde, dass alle Verbraucher migriert sind. Binden Sie Verbraucher an eine bestimmte Secret-Version statt an einen latest-Alias in der Produktion. Die Secret Manager-Dokumentation von Google Cloud warnt davor, dass das kontinuierliche Auflösen von latest dienstweite Ausfälle verursachen kann, wenn eine fehlerhafte Version sofort übernommen wird.

Was sollte nach der Exposition eines Secrets passieren?

Den kompromittierten Wert beim ausstellenden System deaktivieren oder widerrufen – nicht nur im Tresor. Eine Ersatz-Anmeldedaten generieren. Alle abhängigen Systeme aktualisieren. Validieren, dass der Ersatz funktioniert und der alte Wert keinen Zugang mehr gewährt. Auf jede weitere Nutzung der widerrufenen Anmeldedaten überwachen. Dann untersuchen: Wie lange war sie exponiert, worauf wurde zugegriffen, und wie ist sie der vorgesehenen Umgebung entkommen? Den vollständigen Zeitplan als Incident-Nachweis dokumentieren.

Welche Secrets sollten außer Betrieb genommen statt rotiert werden?

Jede Anmeldedaten, die nicht mehr benötigt wird, sollte außer Betrieb genommen, nicht rotiert werden. Anmeldedaten für stillgelegte Systeme, ausgeschiedene Mitarbeiter, eingestellte Integrationen und abgelaufene Dienstleistungsvereinbarungen sollten widerrufen und vernichtet werden – nicht nach einem Rotationszeitplan gehalten werden. Das Rotieren einer unnötigen Anmeldedaten hält sie am Leben und im Geltungsbereich. Die Entscheidung zur Außerbetriebnahme sollte Teil jedes Zugriffsüberprüfungszyklus sein.

Der Stand des Secret Sprawl 2026: Wichtige Erkenntnisse aus dem GitGuardian-Bericht

28,65 Millionen Secrets wurden 2025 auf dem öffentlichen GitHub geleakt. KI beschleunigt das Problem. Interne Repos sind 6× mehr exponiert als öffentliche. Und 64 % der Secrets von 2022 sind heute noch gültig. Hier ist, was die Daten für Ihre Sicherheitslage bedeuten.

Passwork BlogAlex Muntyan

Einblicke 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 sich lautlos in Tausende von Organisationen gleichzeitig einschleichen können? Drei Kampagnen aus 2026 beweisen, dass Supply-Chain-Angriffe keine isolierten Vorfälle mehr sind.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und wie man sie verhindert

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute Force hat sich skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute umsetzen kann.

Passwork BlogAlex Muntyan

Secret rotation fails when teams treat it as a scheduled password change: set up rotation schedules, point to a vault, and call it done. Then an API key leaks from a CI/CD variable that nobody inventoried. Or a rotation job runs twice, creates a race condition, and takes down a service. Or an engineer leaves, and their SSH key stays active for six months because nobody mapped it to an owner.

A secrets rotation lifecycle is the controlled process for creating, storing, using, rotating, revoking, and retiring credentials such as API keys, passwords, tokens, certificates, and encryption keys. Its goal is to reduce the lifespan and blast radius of exposed credentials while keeping systems available.

Rotation is one control inside that process. Without the surrounding structure (inventory, ownership, access control, validation, cleanup, and audit evidence) rotation alone changes a credential's value without reducing its risk.

Key takeaways

• A secrets rotation lifecycle has seven stages: creation, classification, storage, distribution, rotation, revocation, and retirement.
• Rotation is one control inside a wider system, not the system itself. Without the surrounding structure, rotation changes a credential's value without reducing its risk.
• The exposure problem is structural, not procedural. GitGuardian detected 28.65 million new hardcoded secrets on public GitHub in 2025 – a 34% year-over-year increase. Of secrets confirmed valid in 2022, 64% were still exploitable in January 2026 (GitGuardian State of Secrets Sprawl 2026).
• Safe rotation has a specific sequence. Generate the new value, validate it against the target system, roll it out gradually, then disable the old one. Skipping validation or cutting over all consumers at once is how rotation causes outages.
• Dynamic secrets eliminate the rotation problem for supported workloads. Rotated static secrets remain necessary for legacy systems, third-party integrations, and long-running workloads that cannot request credentials on demand.
• Emergency revocation requires a complete inventory. If you cannot identify all consumers of a secret within minutes of a suspected exposure, you cannot contain the incident. Inventory is the prerequisite for everything else.

What is the secrets rotation lifecycle?

The secrets rotation lifecycle is the end-to-end governance model for managing machine and human credentials from the moment they are created to the moment they are permanently destroyed. It treats rotation as one stage inside a broader operational process, not as a periodic password-change task.

The distinction matters because rotation without the surrounding controls produces a false sense of security. A credential that rotates every 30 days but has no named owner, no consumer inventory, and no revocation path is still a liability.

Each stage has a distinct set of controls. Skipping classification means rotation targets are unknown. Skipping cleanup means old credentials accumulate and create exposure. The lifecycle model forces teams to treat each stage as a deliberate operational decision.

Why rotation alone does not solve credential risk

Rotation reduces the window of exposure for a compromised credential. It does not eliminate the credential as an attack surface, and it does nothing for credentials that were never inventoried, never stored securely, or never revoked after exposure.

The scale of the unmanaged credential problem is structural. GitGuardian detected 28.65 million new hardcoded secrets on public GitHub in 2025 – a 34% increase over the previous year and the largest single-year jump the company has recorded. That figure covers only public repositories. Of the secrets GitGuardian confirmed as valid in 2022, 64% were still exploitable in January 2026, four years after they first leaked.

The pattern is consistent: secrets escape their intended environment, nobody notices, and rotation schedules don't catch them because the exposed copy is outside the vault entirely.

Rotation should be understood as a control that reduces credential lifespan for secrets that are properly managed. It is not a substitute for eliminating hardcoded credentials, enforcing least privilege, auditing access, scanning for secret sprawl, or revoking stale values. All of those controls need to be in place for rotation to deliver its intended effect.

Which secrets need lifecycle management?

Any credential that grants access to a system, data store, service, or identity needs lifecycle management. The practical scope is broader than most teams initially assume.

The inventory step (knowing which secrets exist, where they live, who owns them, and what they access) is the prerequisite for everything else. You cannot rotate what you haven't found.

The seven stages of a secure secrets rotation lifecycle

1. Create secrets with ownership and purpose

Every secret needs a named owner, a documented system purpose, an environment tag, a sensitivity classification, an expected expiry, and an approved storage location before it leaves the creation step. These are the data that makes rotation, revocation, and cleanup possible.

A secret created without an owner has no one responsible for rotating it. A secret created without a consumer list has no one to notify when it changes. A secret created without an expiry has no trigger for review.

Do not allow developers to create secrets in tickets, chat messages, spreadsheets, or local files. The creation step should route directly to a managed vault or secret manager. If it doesn't, the secret is already outside the lifecycle before it's been used once.

2. Store secrets in a managed vault, not in code

Centralized storage is what makes the rest of the lifecycle operable. A vault gives you access control, audit logging, version history, rotation hooks, and revocation capability. A .env file in a repository gives you none of those things.

Secret sprawl – credentials scattered across repositories, chat tools, configuration files, and personal password stores – is the direct consequence of skipping this step. The assumption that internal systems are safer than public ones does not hold up to measurement.

GitGuardian's 2026 research found that internal repositories are 6× more likely to contain a hardcoded secret than public ones, and that 28% of internal incidents originate outside the codebase entirely – in Slack, Jira, and Confluence – with a higher critical severity rate than code-based findings. "Private" is not a security control.

For teams where admins, IT staff, and business units need controlled access to shared credentials, a corporate password manager can support the human side of secrets governance: centralized storage, structured access, ownership records, and audit-friendly credential handling. Machine-to-machine secrets still require lifecycle-aware technical controls, but human access to sensitive credentials should not live in chat threads, spreadsheets, or personal password stores.

3. Grant access using least privilege

Secret consumers should receive only the credentials they need, scoped to the narrowest practical permission set, for the shortest practical period. This applies to human users, service accounts, CI/CD pipelines, and non-human identities.

A CI/CD pipeline that deploys to staging does not need production database credentials. A service account that reads from a single S3 bucket does not need account-wide storage access. A developer who needs to debug a production issue does not need permanent access to the production vault.

Least privilege reduces blast radius. If a credential is compromised, the attacker's access is bounded by what that credential was permitted to do. Over-provisioned secrets turn every exposure into a potential full-system compromise.

4. Use secrets without exposing them

The use stage is where secrets most commonly escape their intended environment. Applications print configuration values to logs. Developers paste credentials into tickets to share context. Shell history captures database connection strings. Error responses include authentication details.

Runtime injection keeps secrets out of code. Services should retrieve credentials at startup via a vault client or secret-injection sidecar, not from committed config files. The Passwork CLI supports an exec mode that injects credentials as environment variables for the duration of a command, without writing them to shell history or the filesystem. Pre-commit hooks and secret scanning tools catch accidental commits before they reach a repository.

The specific controls that matter here: redact secrets from application logs, disable credential logging in debug modes, scan log aggregation pipelines for secret patterns, and never include credentials in error messages returned to clients. These are not exotic measures – they are the baseline for any production environment handling sensitive credentials.

5. Rotate secrets safely

Rotation is the stage most teams have some process for. The operational failures happen in the details: validating the new value before activating it, controlling which consumers adopt the new version and when, monitoring for breakage, and disabling the old value only after confirming the new one works.

Google Cloud's Secret Manager documentation is explicit about one specific failure mode: continuously resolving the latest alias in production workloads creates service-wide outage risk if a bad secret version is rolled out. The new value is adopted immediately by all consumers, with no gradual rollout and no automatic rollback. This is a real operational hazard, not a theoretical one.

The safe rotation sequence:

1. Inventory the secret, its owner, its consumers, and its dependency path.
2. Generate the new value without invalidating the old one.
3. Store the new value as a new version in the vault or secret manager.
4. Validate the new value against the target system before any consumer uses it.
5. Roll out to a small subset of consumers or the next deployment wave.
6. Monitor authentication failures, error rates, latency, and application health.
7. Complete rollout to all consumers.
8. Disable the old value and monitor for unexpected use.
9. Revoke or destroy the old value after the safety window closes.
10. Record audit evidence and update the inventory.

Steps 4 and 8 are the ones most often skipped. Skipping step 4 means a bad value can reach production. Skipping step 8 means the old value stays active indefinitely, defeating the purpose of rotation.

6. Revoke secrets after exposure, offboarding, or scope changes

Revocation is distinct from rotation. Rotation replaces a credential on a schedule. Revocation disables a credential immediately in response to a specific event: confirmed exposure, suspected compromise, employee departure, role change, vendor incident, or system decommission.

The emergency revocation workflow:

1. Detect or confirm the exposure event.
2. Identify the secret's owner, consumers, and all dependent systems.
3. Disable or revoke the compromised value at the issuing system, not just in the vault.
4. Generate a replacement credential.
5. Update all dependent systems with the new value.
6. Validate that the replacement works and the old value no longer grants access.
7. Monitor for any continued use of the revoked credential.
8. Investigate the exposure: how did it happen, what was accessed, for how long?
9. Document the incident, the revocation timeline, and the remediation steps.

Step 3 is where revocation most often fails. Teams disable the secret in their vault but forget to invalidate it at the external system – the database, the API provider, the identity platform. The old value remains valid at the source. The vault record says revoked; the credential still works.

7. Retire and audit old secrets

Keeping old credentials "just in case" is a common instinct and a real risk. Every old value that remains accessible is a credential that can be used – by an attacker who found it in a log, a backup, a decommissioned system, or a developer's local cache.

The retirement sequence: disable the old value first, monitor for unexpected use during a defined safety window, then destroy or archive according to policy and compliance requirements. The safety window length depends on the secret type and the criticality of the dependent systems – typically 24 to 72 hours for most application credentials, longer for encryption keys where re-encryption may be involved.

Audit evidence for retirement should include: the date the old value was disabled, the monitoring period, confirmation that no unexpected use occurred, and the date of final destruction or archival. This is the documentation that satisfies an auditor asking "how do you know the old credential is gone?"

Manual rotation vs automated rotation

Manual rotation is not inherently wrong. For a small set of high-sensitivity admin credentials that change infrequently, a documented manual process with approval gates and audit records can be appropriate. The problem is when manual rotation is the default for everything – it doesn't scale, it's inconsistent, and the audit trail is usually a spreadsheet with a date column.

Automation should be the default for any secret type where the target system supports it. IBM's finding that extensive security AI and automation reduced breach costs by $1.9 million on average reflects a broader principle: consistent, automated controls outperform inconsistent manual ones at scale.

Rotated secrets vs dynamic secrets

Dynamic secrets are credentials issued on demand with a short TTL or lease. Each requesting workload gets a unique credential that expires automatically — there is nothing to rotate because nothing is long-lived. HashiCorp Vault's database secrets engine is the standard example: each application request gets a temporary database user that expires when the lease ends.

Rotated secrets are static credentials that are periodically replaced with a new value. They remain necessary for systems that cannot issue dynamic credentials: most SaaS APIs, many legacy databases, long-lived service accounts, and third-party integrations where you do not control the credential issuer.

Dynamic secrets reduce the attack surface for workloads that can support them. They do not eliminate the need for lifecycle controls on the credentials that cannot be made dynamic. Both models coexist in most real environments.

How to rotate secrets without downtime

The two-secret strategy is the core pattern for zero-downtime rotation. The old credential and the new credential are both valid simultaneously during the transition window. Consumers migrate to the new value, the old value is confirmed unused, then the old value is disabled.

This requires the external system – the database, the API provider, the identity platform – to support multiple simultaneous valid credentials. Most modern systems do. For those that don't, the rotation window requires a maintenance period or a blue-green deployment approach.

The specific failure modes to design against:

• Consumers that cache credentials in memory and don't reload until restart. Plan for rolling restarts or a cache-invalidation mechanism.
• Rotation jobs that run concurrently and create conflicting versions. Use locks, idempotent design, and state labels to prevent double-rotation.
• Health checks that don't test the actual credential path. A service that reports healthy but is using a cached old value will break when the old value is disabled.

Google Cloud's rotation documentation recommends binding applications to a specific secret version rather than the latest alias for production workloads. Resolve the version at deployment time, store the version name in configuration, and roll it out through the standard deployment pipeline. This gives you gradual rollout, rollback capability, and predictable behavior across restarts.

The reentrant rotation job pattern matters for automated rotation: the job must be able to restart from any point without creating duplicate credentials or leaving the system in an inconsistent state. Configure retries, but also configure maximum concurrency to prevent parallel executions from conflicting.

Common failure modes and how to prevent them

The most expensive failure mode is the second one: updating the vault record while the old credential stays valid at the external system. This is particularly common with database credentials, where the vault record shows "rotated" but the database password was never actually changed. The credential is still valid, the vault shows it as rotated, and the audit log looks clean. Test revocation at the source, not just at the vault.

Passwork gives IT teams a structured vault with role-based access, ownership records, and a full audit log for shared credentials. See how it fits into your governance program

Compliance and audit evidence for the secrets lifecycle

Compliance frameworks don't prescribe rotation intervals in a universal way. What they require – across PCI DSS, SOC 2, HIPAA, and GDPR environments – is evidence that access controls exist, operate consistently, and are reviewed. The exact requirement depends on scope, control mapping, and auditor interpretation. Don't make blanket claims about what a regulation mandates without reading the specific control language.

What lifecycle management produces that auditors want to see:

• Inventory records showing which secrets exist, who owns them, and what they access
• Access control evidence: who has permission to retrieve each secret and why
• Rotation records: when each credential was rotated, by what process, and whether validation passed
• Revocation records: when credentials were disabled, what triggered the revocation, and confirmation that the old value no longer works
• Access reviews: periodic confirmation that access grants are still appropriate
• Incident documentation: for any exposure event, a timeline from detection to remediation

The audit trail is not a byproduct of good secrets management – it's a design requirement. Systems that don't log rotation events, access requests, and revocation actions cannot produce the evidence that compliance requires.

IBM's X-Force Threat Intelligence Index 2026 reported 300,000 AI chatbot credentials observed for sale on the dark web. The credential exposure problem is not shrinking. Auditors and regulators are paying attention to the same trend.

A practical policy template for secrets rotation lifecycle

A policy without operational specifics is a document that gets signed and ignored. The template below is a skeleton – fill in the specifics for your environment, get it reviewed by legal and security, and attach it to your secrets governance program.

The exceptions row matters. Every environment has systems that can't support automated rotation – legacy applications, third-party services with manual key management, hardware appliances. Document them explicitly, define the compensating controls, and review them on a schedule. An undocumented exception is an unmanaged risk.

Where Passwork fits in a secrets governance program

The seven lifecycle stages need different tooling at different layers. Dynamic credential engines and KMS systems handle machine-to-machine secrets at infrastructure scale. What they don't replace is a governed layer for credentials that humans create, share, and rotate: admin accounts, break-glass credentials, shared service keys, API keys managed by operations teams, and anything that currently lives in a spreadsheet, a shared inbox, or someone's personal password manager..

Passwork covers that layer. The sections below map its capabilities to the lifecycle stages where human-managed credentials need the most governance.

Storage and classification

Passwork stores credentials in structured vaults organized by folder, environment, and team. Each entry carries metadata: URL, login, custom fields, tags, and notes. You can mirror your infrastructure topology in the vault layout (separate vaults for production and staging, folders by team or service), which makes both access scoping and rotation inventory practical.

The encryption model matters here. Server-side storage uses AES-256-CFB. With client-side encryption (CSE) enabled, each vault is encrypted in the browser before it leaves the device. The server stores only ciphertext; decryption requires the master key, which is derived from the user's master password and never transmitted. For organizations that cannot route sensitive credentials through an external service under any circumstances, the CSE model removes that dependency entirely.

Access control and least privilege

Role-based and group-based permissions let you grant vault access to a team rather than to individuals. When an engineer joins the DevOps group, they inherit the group's vault access automatically. When they leave, you revoke access once – not once per vault.

Access scope is granular. Each vault or folder carries independent permissions. A CI/CD service account gets read access to the specific folder it needs and nothing else. A security auditor gets read-only access to designated vaults without the ability to modify or export values. Passwork integrates with AD/LDAP and supports SAML SSO, so provisioning and offboarding follow the same identity workflows as the rest of your stack.

Rotation automation

Passwork's CLI (passwork-cli) and Python SDK support a full rotation workflow. The standard pattern is: generate the new value, apply it to the target system, validate that the system accepts it, then write the new value to Passwork. That ordering is intentional. Updating Passwork first, before the target system confirms the change, leaves the two sources out of sync.

A PostgreSQL rotation script using the CLI:

#!/bin/bash
set -euo pipefail

NEW_PASS=$(openssl rand -base64 32 | tr -d '=+/' | cut -c1-32)

# Apply to the database first
psql -h pg.prod.internal -U postgres \
  -c "ALTER ROLE app_user WITH PASSWORD '${NEW_PASS}';"

# Then update Passwork — only reached if the database command succeeded
passwork-cli update --password-id "$PASSWORK_ITEM_ID" --password "$NEW_PASS"

If the database command fails, set -euo pipefail stops the script before Passwork is updated. The vault reflects the actual state of the target system, not a hoped-for state.

The exec mode handles the other direction: retrieving secrets at runtime without writing them to disk or shell history:

passwork-cli exec --password-id "$DB_CREDS_ID" -- ./start-service.sh

The credential is injected as an environment variable for the duration of the child process. It does not appear in ps output after the process exits and is not written to any log the CLI produces.

For API integrations, Passwork 7.6.0 added dedicated token rotation endpoints. Service accounts have their own accessToken and refreshToken pair. CI/CD pipelines can rotate their own API credentials programmatically via POST /api/v1/sessions/refresh without requiring an administrator to intervene between cycles.

Audit trail and evidence

Every access event, credential modification, and permission change is recorded in Passwork's action history. The log includes the actor, timestamp, action type, and affected resource. For SIEM integration, event export is available in CEF format, which means Passwork's audit trail flows into your central security monitoring rather than sitting in a separate silo.

For compliance purposes, the action history answers the "who accessed which credential, when, and from which session" question for human-managed secrets without a separate access review process. Rotation records, access grants, and revocation events are all present in the same log.

Passwork holds ISO 27001 certification and is compliant with GDPR and NIS2.

Conclusion

A secure secrets program is not measured by whether credentials change every 90 days. It's measured by whether the organization knows which secrets exist, who owns them, where they are used, how quickly they can be revoked, and what evidence proves the controls work.

The secrets rotation lifecycle gives teams a structured answer to those questions. Inventory first: find the secrets, name the owners, map the consumers. Remove hardcoded credentials from source code and configuration files.

Centralize human-shared credentials in a managed system with access control and audit logging. Automate rotation and revocation where the target system supports it. Build validation and rollback into every rotation workflow.

Keep the audit trail. When an incident happens, the log is the only record that tells you what was accessed, by whom, and for how long.

The rotation schedule is the easy part. The harder work comes after: finding the API keys unused since 2022, tracking down who owns the shared inbox credentials that three teams rely on, retiring the database password that was "temporary" eighteen months ago.

That work starts with having a place to put credentials that isn't a spreadsheet – somewhere with access control, ownership records, and a log. Passwork is built for that layer of the governance program. Try it in your infrastructure and see how far the inventory gets before the first rotation cycle runs.

Passwork is available as a self-hosted solution with full control over your data. Explore deployment options

Frequently Asked Questions

What is the difference between secret rotation and secret revocation?

Secret rotation replaces a credential with a new version on a scheduled or event-driven basis, while keeping the service available throughout the transition. Secret revocation disables a credential immediately in response to a specific event -- exposure, compromise, offboarding, or scope change -- without necessarily replacing it on a schedule. Rotation is planned; revocation is reactive.

How often should secrets be rotated?

Rotation frequency should be risk-based, not uniform. High-sensitivity credentials with broad access -- production database passwords, admin API keys, service account tokens -- should rotate every 30 to 90 days. Lower-sensitivity credentials with narrow scope can rotate less frequently. Any credential should rotate immediately after a suspected or confirmed exposure, regardless of schedule.

Should API keys be rotated automatically?

Yes, where the issuing system supports it. Automated rotation is more consistent, faster, and produces a better audit trail than manual processes. For API keys issued by third-party SaaS providers that don't support automated rotation, document a manual rotation runbook with defined frequency, approval steps, and validation requirements. GitGuardian's 2026 research found that 64% of secrets confirmed valid in 2022 were still exploitable four years later – a figure that reflects the gap between having a rotation policy and executing it across the full credential inventory.

Are dynamic secrets better than rotated secrets?

Dynamic secrets are preferable for workloads that can request and renew credentials on demand -- CI/CD pipelines, ephemeral containers, short-lived jobs. They eliminate the rotation problem by making credentials expire automatically. For long-running applications, legacy systems, and third-party integrations that can't request credentials dynamically, rotated static secrets remain the standard. Most production environments use both models, matched to the workload type.

How do you rotate secrets without downtime?

Use the two-secret strategy: generate the new value, validate it against the target system, roll it out to a subset of consumers, monitor for errors, complete the rollout, then disable the old value after confirming all consumers have migrated. Bind consumers to a specific secret version rather than a latest alias in production. Google Cloud's Secret Manager documentation warns that continuously resolving latest can cause service-wide outages if a bad version is adopted immediately.

What should happen after a secret is exposed?

Disable or revoke the compromised value at the issuing system -- not just in the vault. Generate a replacement credential. Update all dependent systems. Validate that the replacement works and the old value no longer grants access. Monitor for any continued use of the revoked credential. Then investigate: how long was it exposed, what was accessed, and how did it escape the intended environment? Document the full timeline as incident evidence.

Which secrets should be retired instead of rotated?

Any credential that is no longer needed should be retired, not rotated. Credentials for decommissioned systems, departed employees, discontinued integrations, and expired service agreements should be revoked and destroyed – not kept on a rotation schedule. Rotating an unnecessary credential keeps it alive and in scope. The retirement decision should be part of every access review cycle.

The state of secrets sprawl in 2026: Key findings from GitGuardian’s report

28.65 million secrets leaked on public GitHub in 2025. AI is accelerating the problem. Internal repos are 6× more exposed than public ones. And 64% of secrets from 2022 are still valid today. Here is what the data means for your security posture.

Passwork BlogAlex Muntyan

Inside real supply chain attacks: Bitwarden CLI, Axios, and Vercel

Why breach your network when attackers can compromise a trusted dependency with millions of downloads and slip silently into thousands of organizations at once? Three 2026 campaigns prove supply chain attacks are no longer isolated incidents.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

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

En 2025, GitGuardian detectó 28,65 millones de nuevos secretos codificados en commits públicos de GitHub. Esto representa un aumento del 34% respecto al año anterior y el mayor incremento anual jamás registrado por la empresa. Esa cifra cubre únicamente repositorios públicos. El panorama completo, una vez incluidos los sistemas internos, herramientas de colaboración e infraestructura autoalojada, es considerablemente peor.

Tres temas atraviesan los datos:

1. El desarrollo asistido por IA ha pasado de ser experimental a ser la norma, acelerando la filtración de credenciales en cada capa del stack.
2. Los sistemas internos están mucho más expuestos de lo que la mayoría de las organizaciones suponen: los repositorios privados, canales de Slack e instancias autoalojadas de GitLab conllevan un riesgo significativo de credenciales.
3. La remediación sigue siendo el fallo crítico de la industria: el 64% de los secretos confirmados como válidos en 2022 seguían siendo explotables en enero de 2026, cuatro años después de su primera filtración.

Este artículo analiza cada hallazgo con los datos y el contexto que los equipos de TI y seguridad necesitan para impulsar el cambio internamente.

Conclusiones clave

• La IA es el principal impulsor de la exposición de credenciales. Ocho de los diez tipos de secretos filtrados con mayor crecimiento están vinculados a servicios de IA. La infraestructura LLM se filtra 5× más rápido que los proveedores de modelos principales.
• Los repositorios internos tienen 6× más probabilidad de contener un secreto codificado que los públicos. «Privado» no es un control de seguridad.
• Una cuarta parte de todos los incidentes internos se originan fuera del código fuente. Slack, Jira y Confluence representan el 28% de las filtraciones — con una tasa de severidad crítica mayor que los hallazgos basados en código.
• La remediación es el factor limitante de la industria. El 64% de los secretos confirmados como válidos en 2022 seguían siendo explotables en enero de 2026.
• La priorización solo por validación omite el 46% de los secretos críticos. Las credenciales genéricas — claves privadas, tokens personalizados, contraseñas — no pueden validarse automáticamente pero causan la mitad de todos los incidentes críticos.
• Las estaciones de trabajo de desarrolladores y los runners de CI/CD son una superficie de ataque subestimada. El ataque Shai-Hulud 2 encontró 294.842 ocurrencias de secretos en 6.943 máquinas comprometidas; el 59% eran runners de CI/CD.
• Los contratistas externos son un vector de secretos sin control. GitGuardian encontró 1.834 incidentes críticos en 13 firmas de consultoría, afectando potencialmente a 1.203 organizaciones cliente.
• Los archivos de configuración MCP son una nueva superficie de filtración en gran medida no monitoreada. En 2025, 24.008 secretos únicos fueron expuestos en configuraciones relacionadas con MCP en GitHub público — el 8,8% confirmados como válidos en el momento de la detección.

¿Qué tan grande es el problema de la dispersión de secretos en 2025?

La dispersión de secretos es la proliferación descontrolada de credenciales codificadas (claves API, contraseñas, tokens y certificados) a través de bases de código, archivos de configuración y herramientas de colaboración. Desde 2021, los secretos filtrados en GitHub público han crecido un 152%, mientras que la población de desarrolladores creció un 98%. La brecha se amplía cada año, y 2025 produjo el mayor incremento de volumen anual registrado.

Escala en números

La escala del problema es estructural. Más personas escriben más código, integran más servicios de terceros y generan más credenciales que pueden filtrarse.

Una métrica se mantuvo estable: los secretos por repositorio. La densidad permaneció aproximadamente igual, lo que sugiere que Push Protection de GitHub está cumpliendo su función de capturar credenciales comunes antes de que se hagan públicas. Pero el control de densidad no puede detener el crecimiento del volumen. Cuando el número total de commits se cuadruplica, incluso una tasa de filtración estable por repositorio produce un número récord de credenciales expuestas.

Cómo la IA está impulsando una nueva generación de secretos filtrados

El desarrollo asistido por IA ha reconfigurado qué secretos se filtran, con qué rapidez se acumulan y dónde terminan. Ocho de los diez tipos de secretos filtrados con mayor crecimiento interanual están vinculados a servicios de IA. El auge de la infraestructura de IA es el principal impulsor de la exposición de credenciales en este momento.

El auge de la infraestructura de IA

En 2025, GitGuardian detectó 1.275.105 secretos pertenecientes a servicios de IA — un aumento del 81% respecto a 2024.

Detectores específicos con mayor crecimiento (relacionados con IA):

La tendencia más significativa es qué se está filtrando más allá de los propios proveedores de modelos. La infraestructura LLM (la capa de orquestación, recuperación y almacenamiento que rodea a los modelos principales) se filtra 5× más rápido que los proveedores de modelos. Solo Supabase ahora se ubica entre los 20 secretos más filtrados en general, con más de 248.600 ocurrencias.

El patrón es consistente: los desarrolladores que construyen aplicaciones impulsadas por IA conectan un modelo a una capa de recuperación, una herramienta de orquestación, una base de datos vectorial, un rastreador de experimentos y un servicio de monitoreo. Cada integración añade una nueva credencial. Cada credencial es una filtración potencial.

A medida que emergen nuevos proveedores de IA, hay un retraso inevitable antes de que la cobertura de detección se ponga al día. Push Protection de GitHub se enfoca en patrones conocidos. Los proveedores nuevos pasan desapercibidos. Para cuando se construye un detector, miles de claves pueden ya ser públicas.

Claude Code y los commits asistidos por IA filtran secretos al doble de la tasa base

Claude Code de Anthropic pasó de 22 commits coautorados en enero de 2025 a 2,16 millones en diciembre. Durante todo el año:

• Los commits asistidos por Claude Code = 0,4% de todo lo escaneado públicamente
• Los commits asistidos por Claude Code = 0,9% de todas las filtraciones
• Tasa de filtración: 3,2% vs. 1,5% de referencia en todos los commits públicos de GitHub

Tasa de filtración de Claude Code durante 2025:

Los commits de Claude Code también fueron consistentemente más grandes — aproximadamente 2× las líneas de código por commit desde abril en adelante. Los commits más grandes significan más superficie de exposición de credenciales en una sola revisión.

El matiz importante: el desarrollador mantiene el control de cada commit. Los asistentes de codificación con IA son herramientas. La tasa de filtración elevada refleja decisiones humanas — descuido, presión de tiempo o decisiones deliberadas de ignorar advertencias — no comportamiento autónomo de la IA.

La conclusión para los equipos de seguridad: trate los conjuntos de cambios generados por IA como unidades de revisión de mayor impacto, mantenga el escaneo automatizado en el flujo de trabajo del desarrollador y mantenga la remediación lo suficientemente rápida para que un secreto filtrado no permanezca válido el tiempo suficiente para ser explotado.

24.000 secretos en archivos de configuración MCP

¿Qué es MCP? Model Context Protocol es el estándar que surgió a principios de 2025 para conectar modelos de lenguaje grandes con herramientas y fuentes de datos externas. Cuando un desarrollador quiere que su agente de IA consulte una base de datos, busque en la web o interactúe con una plataforma SaaS, MCP maneja la conexión — y esas conexiones requieren credenciales.

Hallazgos clave:

• 24.008 secretos únicos expuestos en archivos de configuración relacionados con MCP en GitHub público en 2025
• 2.117 confirmados como válidos (8,8%) en el momento de la detección

Los 5 principales tipos de secretos válidos en configuraciones MCP:

Por qué las configuraciones MCP siguen filtrándose: Las guías oficiales de configuración de MCP normalizan la codificación directa. La documentación popular de inicio rápido muestra claves API pasadas como argumentos de línea de comandos dentro de archivos de configuración del servidor, o almacenadas en línea en archivos JSON que se envían al control de versiones. Cuando la documentación oficial trata la codificación directa como predeterminada, la dispersión sigue.

El caso Smithery.ai: El equipo de investigación de GitGuardian reveló una vulnerabilidad crítica en uno de los registros de servidores MCP más utilizados. Un solo error de path traversal en el proceso de construcción Docker de la plataforma expuso un token con privilegios excesivos que otorgaba ejecución de código arbitrario en los más de 3.000 servidores MCP alojados — y acceso a las claves API y secretos de miles de clientes en cientos de servicios.

Gestión de credenciales MCP — estándares mínimos:

• Nunca almacene secretos en archivos de configuración MCP. Utilice variables de entorno gestionadas por un gestor de secretos dedicado, no valores en línea en JSON o argumentos CLI.
• Los clientes, no los servidores, deben ser propietarios de los secretos. Los servidores MCP deben solicitar credenciales a los clientes en el momento de la consulta en lugar de incrustarlas en la configuración del lado del servidor.
• Excluya los directorios de configuración MCP del control de versiones mediante .gitignore.
• Conéctese a servidores MCP remotos únicamente a través de TLS.
• Escanee antes de hacer push. Las herramientas de escaneo pre-commit detectan secretos en archivos de configuración MCP antes de que lleguen al control de versiones.
• Requiera aprobación manual antes de cualquier acción MCP que toque sistemas de producción, bases de datos o pipelines de despliegue.

Los secretos en código, configuraciones y mensajes de chat son una brecha esperando suceder. Passwork proporciona a su equipo un lugar único y seguro para almacenar, compartir y rotar credenciales — para que nunca terminen codificadas en un repositorio o pegadas en un canal de Slack. Explore las capacidades de gestión de secretos de Passwork

Los sistemas internos son un punto ciego peligroso

El hallazgo más consecuente del informe 2026 es el que recibe menos cobertura mediática: el peligro es mayor donde las organizaciones se sienten más seguras. Los repositorios internos, las herramientas de colaboración y la infraestructura autoalojada se tratan como seguros por defecto — pero los datos dicen lo contrario.

Los repositorios internos filtran 6× más que los públicos

La razón es el antipatrón de «seguridad por oscuridad». Los equipos de desarrollo tienden a ser menos cautelosos dentro de un perímetro cerrado. Asumen que exponer un secreto en un repositorio privado es menos dañino porque no está sujeto a escrutinio público. El resultado es una acumulación silenciosa de credenciales codificadas programadas para ser eliminadas «más tarde» — y rara vez lo son.

Los repositorios internos también contienen las credenciales más valiosas:

• Tokens de CI/CD
• Claves de acceso a la nube
• Credenciales de bases de datos
• Tokens de herramientas internas

Estos son exactamente los activos que un atacante desea una vez que establece un punto de apoyo. Un solo secreto expuesto en un repositorio privado puede convertirse en un camino rápido hacia el movimiento lateral a través de toda la infraestructura.

Tasas de exposición por industria (repositorios públicos):

Estas cifras representan solo lo que es visible externamente. La exposición interna es 6× mayor en todos los sectores.

Las firmas de consultoría convierten la dispersión de secretos en riesgo de terceros

Los contratistas y firmas de consultoría operan simultáneamente en múltiples entornos de clientes. Poseen credenciales, tokens y conocimiento de configuración de cada cliente al que sirven — y frecuentemente trabajan en cuentas personales o repositorios fuera de la organización de GitHub de su cliente.

Análisis de GitGuardian de 13 firmas de consultoría:

La brecha de Red Hat (octubre de 2025): El grupo de ciberdelincuentes «Crimson Collective» exfiltró 570 GB de datos de 28.000 repositorios en la instancia interna de consultoría de GitLab de Red Hat, afectando aproximadamente a 800 organizaciones en todo el mundo. Los datos filtrados contenían:

• Claves API y credenciales de bases de datos
• Tokens de autenticación y configuraciones de VPN
• Detalles de infraestructura y arquitectura interna

Las organizaciones afectadas incluyeron a Bank of America, JPMorgan Chase, IBM, Cisco, la Armada de EE.UU. y la NSA. Los atacantes utilizaron las credenciales recolectadas para pivotar directamente hacia la infraestructura del cliente.

Cualquier organización que utilice contratistas o firmas de consultoría tiene un problema de secretos de terceros, haya sido descubierto o no.

Una de cada cuatro filtraciones internas se origina fuera del código fuente

Origen de los incidentes internos:

Las herramientas de colaboración (Slack, Jira, Confluence) representan el 28% de los incidentes, con una tasa de severidad crítica 13 puntos porcentuales más alta que las filtraciones basadas en código. Los secretos compartidos a través de estas herramientas tienden a ser credenciales de producción compartidas durante la respuesta a incidentes o la resolución urgente de problemas, cuando las personas se mueven rápido y no piensan en la higiene de seguridad.

El 4% de superposición entre hallazgos de SCM y ODS significa que estas son poblaciones de filtraciones en gran medida separadas. Escanear solo repositorios omite aproximadamente una cuarta parte de la exposición total de una organización.

80.000 secretos en GitLab autoalojado y registros Docker

GitGuardian identificó miles de instancias de GitLab autoalojadas y registros Docker dejados accesibles públicamente sin autenticación.

Resumen de hallazgos:

Tasas de validez por tipo de credencial (Docker vs. GitLab):

Cuanto más cerca está un activo de producción, mayor es la probabilidad de encontrar una credencial válida. La tasa de filtración de GitLab autoalojado y Docker es 3–4× mayor que la de GitHub público.

La investigación también descubrió más de 300.000 direcciones de correo electrónico (incluyendo 2.000 con dominios .gov) y referencias a hosts de bases de datos internas e infraestructura no pública.

El efecto «muñecas rusas»: las filtraciones expuestas públicamente contienen secretos válidos que otorgan acceso a infraestructura privada, que a su vez expone más secretos, multiplicando la brecha inicial en cada capa.

El 64% de los secretos filtrados en 2022 siguen siendo válidos en 2026

La detección sin remediación no es seguridad — es documentación. Los datos longitudinales del informe 2026 demuestran esto claramente.

Validez de secretos originalmente filtrados en 2022, reevaluados a lo largo del tiempo:

Esas credenciales han estado en código público, explotables por cualquiera que las encuentre, durante cuatro años. La persistencia es una señal operativa de que la remediación — no la detección — es el factor limitante de la industria.

Por qué la rotación rara vez ocurre:

Las credenciales no son cadenas aisladas. Están incrustadas en:

• Sistemas de construcción y pipelines de CI/CD
• Múltiples repositorios (duplicadas)
• Imágenes de contenedores (integradas en tiempo de construcción)
• Variables de CI y configuraciones de entorno
• Integraciones de proveedores y terceros

La decisión a corto plazo que muchos equipos toman no es la más segura — es la que evita romper algo: no hacer nada.

Distribución de violaciones de políticas NHI (datos de clientes de GitGuardian):

La velocidad de creación está superando la madurez de identidad. La IA facilita la creación de proyectos y la conexión de servicios, pero también facilita reproducir patrones inseguros a escala cuando el movimiento predeterminado es «simplemente añadir una clave».

Por qué falla la priorización solo por validación

Una suposición generalizada en la seguridad de secretos: si un secreto no puede ser validado — confirmado como actualmente activo — se debe despriorizarlo. El informe 2026 desafía esto directamente.

El 46% de los secretos críticos son invisibles para las herramientas de solo validación

La brecha existe porque la cobertura de validación siempre es incompleta:

• Las APIs cambian sin previo aviso
• Nuevos servicios se lanzan constantemente
• Cada proveedor requiere infraestructura dedicada para validar
• Las plataformas regionales y específicas de la industria proliferan

Ignorar los secretos no validables por defecto no es una estrategia conservadora. Es un punto ciego sistemático.

Los secretos genéricos causan la mitad de todos los incidentes críticos

Los «secretos genéricos» — claves privadas, tokens API personalizados, contraseñas y mecanismos de acceso detectados mediante verificaciones de entropía y contexto en lugar de patrones específicos del proveedor — se despriorizan rutinariamente porque no pueden validarse automáticamente.

Los datos dicen que esto es un error:

• 35% de los incidentes críticos se remontan a credenciales genéricas
• 51% de los incidentes de alta criticidad o críticos se remontan a credenciales genéricas

La investigación conjunta con Google (2025): GitGuardian y Google analizaron un millón de claves privadas filtradas contra los registros de Certificate Transparency. Hallazgos clave:

• El 4,5% de las claves filtradas se correspondían con certificados X.509 de confianza
• La mitad tenía un certificado válido en el momento de la filtración
• Más de 4.000 certificados HTTPS se ven comprometidos por año debido a una clave filtrada
• Las organizaciones afectadas incluyeron múltiples empresas Fortune 500 y una Autoridad de Certificación de confianza
• GitGuardian envió más de 4.000 correos de alerta a 600 organizaciones — tasa de respuesta: menos del 10%

Válido no siempre significa peligroso

El problema inverso es igualmente real. Aproximadamente el 10% de los secretos válidos son inherentemente de bajo impacto — tokens de sandbox, credenciales de entornos de prueba, cuentas de servicio con privilegios bajos con acceso solo a datos triviales.

Sin puntuación de riesgo contextual, los equipos rotan credenciales en orden de detección o validación, no en orden de amenaza.

Las cuatro capacidades que requiere una seguridad de secretos efectiva:

Los equipos que aún operan con enfoques de solo validación están sistemáticamente expuestos exactamente a las amenazas que más importan — mientras consumen tiempo de ingeniería en credenciales que representan poco peligro real.

La estación de trabajo del desarrollador como superficie de ataque pasada por alto

El ataque a la cadena de suministro Shai-Hulud 2 proporcionó a GitGuardian datos empíricos directos sobre cómo se ven realmente los secretos en las máquinas de los desarrolladores a escala. Al comprometer paquetes de npm y ejecutarse en el momento de la instalación, el malware recopiló sistemáticamente archivos de entorno y ejecutó escaneos estructurados de secretos locales en miles de máquinas reales.

Hallazgos de Shai-Hulud 2 en 6.943 máquinas comprometidas:

Cada secreto activo aparecía en aproximadamente ocho ubicaciones diferentes en la misma máquina — dotfiles, perfiles de shell, salidas de construcción, configuraciones de IDE y cachés de herramientas. Cada copia es un vector independiente para el robo.

Los tokens de GitHub dominaron el conjunto validado:

• 581 tokens de acceso personal
• 386 tokens OAuth
• 104 PAT de grano fino
• 101 tokens de GitLab

Cada uno permite acceso a repositorios, manipulación de flujos de trabajo o movimiento lateral a través de la cadena de suministro de software. Y debido a que el 59% de las máquinas comprometidas eran runners de CI/CD, esta exposición se extiende mucho más allá del desarrollador individual hacia la infraestructura de construcción compartida.

GitGuardian considera estas cifras conservadoras. El ataque solo se ejecutó donde se instaló el paquete malicioso. No alcanzó carpetas de memoria de agentes, cachés de IDE o la creciente superficie de artefactos generados por IA que ahora incluyen rutinariamente credenciales.

Passwork está disponible como solución autoalojada con control total sobre sus datos. Reemplaza archivos .env compartidos, credenciales pegadas en chat y tokens integrados en configuraciones de CI/CD — con una bóveda estructurada, acceso basado en roles y un registro de auditoría completo. Explore las opciones de despliegue de Passwork

El camino a seguir: De la detección reactiva a la gobernanza de NHI

La detección captura lo que ya existe. El objetivo es adelantarse a la exposición — visibilidad completa de cada credencial en el entorno: quién la posee, a qué accede y si debería seguir existiendo. Ese cambio, de perseguir filtraciones a gobernar identidades no humanas, es lo que significa la gobernanza de NHI en la práctica.

Paso 1. Centralizar secretos en plataformas de bóveda

Haga de la bóveda la fuente de verdad. Cuando los equipos pueden recuperar credenciales de manera confiable desde una única ubicación con control de acceso, dejan de inventar estrategias de almacenamiento fragmentadas — uno de los principales impulsores de la dispersión de secretos. La estructura de bóveda de Passwork está diseñada exactamente para esto: almacenamiento organizado, cifrado y con control de acceso para claves API, contraseñas de bases de datos, certificados, claves SSH y credenciales de cuentas de servicio.

Paso 2. Automatizar la rotación

Si un secreto debe existir, no debería vivir para siempre. El reemplazo regular de credenciales acorta la ventana en que un atacante puede explotar un secreto filtrado y obliga a los equipos a tratar las credenciales como objetos con un ciclo de vida, no como tareas de configuración de una sola vez. La rotación es mucho más simple una vez que existe una estrategia de bóveda — la bóveda se convierte en la única ubicación a actualizar, en lugar de buscar cada lugar donde se copió una credencial.

Paso 3. Corregir los flujos de trabajo de los desarrolladores

Los desarrolladores codifican secretos directamente porque es la forma más rápida de hacer que el código funcione. Elimine la necesidad de archivos .env compartidos y tokens copiados haciendo que la recuperación de credenciales basada en bóveda sea igualmente rápida. El camino seguro tiene que ser más fácil que el inseguro.

Paso 4. Adelantar el escaneo

El escaneo pre-commit y la detección a nivel de estación de trabajo detienen los incidentes antes de que lleguen a cualquier lugar permanente. Las herramientas de escaneo modernas proporcionan señales accionables con bajas tasas de falsos positivos — una mejora significativa respecto a las herramientas ruidosas que erosionaron la confianza de los desarrolladores en el pasado.

Paso 5. Avanzar hacia la autenticación basada en identidad

La salida a largo plazo de los secretos estáticos de larga duración es el acceso de corta duración basado en identidad. Marcos como SPIFFE, implementados por SPIRE de código abierto, reemplazan la autenticación de cadenas compartidas con identidad de carga de trabajo fuertemente atestiguada. Cada carga de trabajo recibe credenciales de corta duración just-in-time en lugar de una clave estática que puede ser copiada, filtrada y explotada durante años.

Tres principios para 2026

Tres preguntas de gobernanza que toda organización debe responder

1. ¿Qué identidades no humanas existen en nuestro entorno?
2. ¿Quién las posee?
3. ¿A qué pueden acceder?

Si alguna de esas preguntas no puede responderse con confianza, la adopción de IA está superando la postura de seguridad.

Conclusiones clave para equipos de TI y seguridad

El informe 2026 de GitGuardian es un relato detallado de un problema en aceleración. Esto es lo que los datos exigen en la práctica:

Las organizaciones que tratan la gestión de credenciales como una disciplina de ciclo de vida — con bóvedas centralizadas, rotación automatizada y control de acceso aplicado — estarán mejor posicionadas para la era de la IA agéntica. Aquellas que la tratan como una tarea de limpieza seguirán descubriendo que sus secretos sobreviven a sus suposiciones de seguridad.

Los datos son claros: los secretos en código, configuraciones y mensajes de chat son una brecha esperando suceder. Passwork proporciona a su equipo un lugar único y seguro para almacenar, compartir y rotar credenciales — con acceso basado en roles, un registro de auditoría completo y despliegue autoalojado que mantiene todo dentro de su propia infraestructura. Pruebe Passwork en su infraestructura

Preguntas frecuentes

¿Qué es la dispersión de secretos?

La dispersión de secretos es la proliferación descontrolada de credenciales codificadas — claves API, contraseñas, tokens, certificados y cadenas de conexión — a través de bases de código, archivos de configuración, pipelines de CI/CD y herramientas de colaboración. Ocurre cuando las credenciales se crean más rápido de lo que se rastrean, rotan o revocan, dejando a las organizaciones con un inventario creciente de vías de acceso explotables que no pueden contabilizar completamente.

¿Cuántos secretos se filtraron en GitHub en 2025?

GitGuardian detectó 28,65 millones de nuevos secretos codificados en commits públicos de GitHub en 2025 — un aumento del 34% respecto a 2024 y el mayor incremento anual jamás registrado. Esa cifra cubre únicamente repositorios públicos. Los repositorios internos, herramientas de colaboración e infraestructura autoalojada añaden sustancialmente a la exposición total.

¿Qué porcentaje de secretos filtrados nunca se revocan?

El 64% de los secretos confirmados como válidos en 2022 seguían siendo válidos y explotables en enero de 2026, lo que significa que habían estado en código público durante cuatro años sin ser rotados ni revocados. La tasa de validez era aproximadamente del 70% cuando el mismo conjunto de datos fue reevaluado en enero de 2025, mostrando solo un descenso gradual a pesar de cuatro años de exposición.

¿Por qué los repositorios internos son más peligrosos que los públicos?

Los repositorios internos tienen 6× más probabilidad de contener un secreto codificado que los públicos — 32,2% vs. 5,6% en 2025. Los equipos tienden a ser menos cautelosos dentro de un perímetro cerrado, asumiendo que un repositorio privado es inherentemente seguro. Los repos internos también contienen las credenciales más valiosas: tokens de CI/CD, claves de acceso a la nube y credenciales de bases de datos — exactamente lo que los atacantes buscan una vez que establecen un punto de apoyo.

¿Cómo aumenta la codificación asistida por IA el riesgo de filtraciones de secretos?

Los asistentes de codificación con IA generan commits más grandes con más código por cambio, aumentando la superficie de exposición de credenciales. Los commits coautorados por Claude Code filtraron secretos al 3,2% — más del doble del 1,5% de referencia en todos los commits públicos de GitHub. Los secretos de infraestructura LLM se filtran 5× más rápido que los secretos de proveedores de modelos principales. Cada nueva integración de servicio de IA añade credenciales que pueden codificarse, copiarse y filtrarse.

¿Qué son los archivos de configuración MCP y por qué filtran secretos?

Model Context Protocol (MCP) es el estándar para conectar modelos de lenguaje grandes con herramientas y fuentes de datos externas. Los archivos de configuración MCP definen cómo un agente de IA se conecta a bases de datos, APIs y servicios — y esas conexiones requieren credenciales. En 2025, GitGuardian encontró 24.008 secretos únicos en archivos de configuración MCP en GitHub público, con 2.117 confirmados como válidos. Las guías oficiales de configuración de MCP a menudo normalizan la codificación de credenciales directamente en archivos de configuración, lo que propaga el problema.

¿Qué es la priorización solo por validación y por qué falla?

La priorización solo por validación es la práctica de desprirorizar secretos que no pueden confirmarse como actualmente activos. Falla porque el 46% de los secretos críticos no pueden validarse — pertenecen a servicios sin verificadores de validación, o a tipos de credenciales genéricas como claves privadas y tokens personalizados. Los equipos que usan este enfoque omiten casi la mitad de sus filtraciones más peligrosas mientras gastan esfuerzo de remediación en credenciales válidas de bajo riesgo. La priorización efectiva requiere puntuación de riesgo contextual, no solo una verificación de validez.

¿Qué es la gobernanza de NHI y por qué importa?

La gobernanza de identidades no humanas (NHI) es la práctica de gestionar el ciclo de vida completo de las identidades de máquinas — cuentas de servicio, claves API, tokens de agentes y otras credenciales no humanas — con el mismo rigor aplicado a las cuentas de usuarios humanos. Responde a tres preguntas: qué NHI existen en el entorno, quién las posee y a qué pueden acceder. A medida que el desarrollo asistido por IA acelera la creación de credenciales, la gobernanza de NHI es la disciplina que evita que la velocidad de creación supere permanentemente la postura de seguridad.

Robo de tokens OAuth y ataques de credenciales: Revisión de abril de 2026

APT28 secuestró 18.000 routers para robar tokens OAuth. Storm-2372 evadió MFA sin tocar una contraseña. 28,6 millones de secretos se filtraron en GitHub. Los mayores incidentes de abril de 2026 — y qué tienen en común.

Passwork BlogAlex Muntyan

Dentro de ataques reales a la cadena de suministro: Bitwarden CLI, Axios y Vercel

¿Por qué violar su red cuando los atacantes pueden comprometer una dependencia de confianza con millones de descargas e infiltrarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 demuestran que los ataques a la cadena de suministro ya no son incidentes aislados.

Passwork BlogAlex Muntyan

Caos de contraseñas: Por qué es un problema empresarial y cómo solucionarlo

Una contraseña olvidada cuesta $70. Una brecha cuesta $4,44 millones. Ambas comienzan de la misma manera — credenciales compartidas por Slack, almacenadas en hojas de cálculo, nunca rotadas. Esto es lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

In 2025, GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits. That is a 34% increase over the previous year and the largest single-year jump the company has ever recorded. That number covers only public repositories. The full picture, once internal systems, collaboration tools, and self-hosted infrastructure are included, is considerably worse.

Three themes run through the data:

1. AI-assisted development has moved from experiment to default, accelerating credential leakage at every layer of the stack.
2. Internal systems are far more exposed than most organizations assume: private repositories, Slack channels, and self-hosted GitLab instances all carry significant credential risk.
3. Remediation remains the industry's critical failure: 64% of secrets confirmed as valid in 2022 were still exploitable in January 2026, four years after they first leaked.

This article unpacks each finding with the data and context IT and security teams need to make the case for change internally.

Key takeaways

• AI is the dominant driver of credential exposure. Eight of the ten fastest-growing leaked secret types are tied to AI services. LLM infrastructure is leaking 5× faster than core model providers.
• Internal repositories are 6× more likely to contain a hardcoded secret than public ones. "Private" is not a security control.
• A quarter of all internal incidents originate outside the codebase. Slack, Jira, and Confluence account for 28% of leaks — with a higher critical severity rate than code-based findings.
• Remediation is the industry's limiting factor. 64% of secrets confirmed as valid in 2022 were still exploitable in January 2026.
• Validation-only prioritization misses 46% of critical secrets. Generic credentials — private keys, custom tokens, passwords — cannot be auto-validated but drive half of all critical incidents.
• Developer workstations and CI/CD runners are an underestimated attack surface. The Shai-Hulud 2 attack found 294,842 secret occurrences across 6,943 compromised machines; 59% were CI/CD runners.
• Third-party contractors are an uncontrolled secrets vector. GitGuardian found 1,834 critical incidents across 13 consulting firms, potentially affecting 1,203 client organizations.
• MCP configuration files are a new and largely unmonitored leak surface. In 2025, 24,008 unique secrets were exposed in MCP-related configs on public GitHub — 8.8% confirmed valid at the time of detection.

How big is the secrets sprawl problem in 2025?

Secrets sprawl is the uncontrolled proliferation of hardcoded credentials (API keys, passwords, tokens, and certificates) across codebases, configuration files, and collaboration tools. Since 2021, leaked secrets on public GitHub have grown 152%, while the developer population grew 98%. The gap is widening every year, and 2025 produced the largest single-year volume increase on record.

Scale by the numbers

The scale of the problem is structural. More people are writing more code, integrating more third-party services, and generating more credentials that can leak.

One metric held steady: secrets per repository. Density stayed roughly flat, which suggests GitHub's Push Protection is doing its job of catching common credentials before they go public. But density control cannot stop volume growth. When the total number of commits quadruples, even a stable leak rate per repository produces a record number of exposed credentials.

How AI is fueling a new generation of leaked secrets

AI-assisted development has reshaped which secrets leak, how fast they accumulate, and where they end up. Eight of the ten fastest-growing types of leaked secrets year-over-year are tied to AI services. The AI infrastructure boom is the dominant driver of credential exposure right now.

The AI infrastructure boom

In 2025, GitGuardian detected 1,275,105 secrets belonging to AI services — an 81% increase over 2024.

Fastest-growing specific detectors (AI-related):

The more significant trend is what is leaking beyond the model providers themselves. LLM infrastructure (the orchestration, retrieval, and storage layer that surrounds core models) is leaking 5× faster than the model providers. Supabase alone now ranks in the top 20 most-leaked secrets overall, with over 248,600 occurrences.

The pattern is consistent: developers building AI-powered applications connect a model to a retrieval layer, an orchestration tool, a vector database, an experiment tracker, and a monitoring service. Each integration adds a new credential. Each credential is a potential leak.

As new AI providers emerge, there is an inevitable lag before detection coverage catches up. GitHub Push Protection focuses on known patterns. Novel providers slip through. By the time a detector is built, thousands of keys may already be public.

Claude Code and AI-assisted commits leak secrets at 2× the baseline

Anthropic's Claude Code went from 22 co-authored commits in January 2025 to 2.16 million in December. Across the full year:

• Claude Code-assisted commits = 0.4% of everything scanned publicly
• Claude Code-assisted commits = 0.9% of all leaks
• Leak rate: 3.2% vs. 1.5% baseline across all public GitHub commits

Claude Code leak rate over 2025:

Claude Code commits were also consistently larger — approximately 2× the lines of code per commit from April onward. Larger commits mean more surface area for credential exposure in a single review.

The important nuance: the developer remains in control of every commit. AI coding assistants are tools. The elevated leak rate reflects human decisions — oversight, time pressure, or deliberate choices to bypass warnings — not autonomous AI behavior.

The takeaway for security teams: treat AI-generated change sets as higher-impact review units, maintain automated scanning in the developer workflow, and keep remediation fast enough that a leaked secret does not remain valid long enough to be exploited.

24,000 secrets in MCP configuration files

What is MCP? Model Context Protocol is the standard that emerged in early 2025 for connecting large language models to external tools and data sources. When a developer wants their AI agent to query a database, search the web, or interact with a SaaS platform, MCP handles the connection — and those connections require credentials.

Key findings:

• 24,008 unique secrets exposed in MCP-related configuration files on public GitHub in 2025
• 2,117 confirmed valid (8.8%) at the time of detection

Top 5 valid secret types in MCP configs:

Why MCP configs keep leaking: Official MCP setup guides normalize hardcoding. Popular quickstart documentation shows API keys passed as command-line arguments inside server config files, or stored inline in JSON files that get committed to version control. When official documentation treats hardcoding as a default, sprawl follows.

The Smithery.ai case: GitGuardian's research team disclosed a critical vulnerability in one of the most widely used MCP server registries. A single path traversal bug in the platform's Docker build process exposed an overprivileged token that granted arbitrary code execution across all 3,000+ hosted MCP servers — and access to the API keys and secrets of thousands of customers across hundreds of services.

MCP credential management — minimum standards:

• Never store secrets in MCP config files. Use environment variables managed by a dedicated secrets manager, not inline values in JSON or CLI arguments.
• Clients, not servers, should own the secrets. MCP servers should request credentials from clients at query time rather than embedding them in server-side configuration.
• Exclude MCP configuration directories from version control via .gitignore.
• Only connect to remote MCP servers over TLS.
• Scan before pushing. Pre-commit scanning tools detect secrets in MCP config files before they reach version control.
• Require manual approval before any MCP action touching production systems, databases, or deployment pipelines.

Secrets sitting in code, configs, and chat messages are a breach waiting to happen. Passwork gives your team a single, secure place to store, share, and rotate credentials — so they never end up hardcoded in a repository or pasted into a Slack channel. Explore Passwork's secrets management capabilities

Internal systems are a dangerous blind spot

The most consequential finding in the 2026 report is one that receives the least press coverage: the danger is greatest where organizations feel safest. Internal repositories, collaboration tools, and self-hosted infrastructure are treated as secure by default — but the data says otherwise.

Internal repositories leak 6× more than public ones

The reason is the "security through obscurity" antipattern. Development teams tend to be less cautious within a closed perimeter. They assume that exposing a secret in a private repository is less harmful because it is not subject to public scrutiny. The result is a silent buildup of hardcoded credentials scheduled to be removed "later" — and rarely are.

Internal repositories also hold the most valuable credentials:

• CI/CD tokens
• Cloud access keys
• Database credentials
• Internal tooling tokens

These are exactly the assets an attacker wants once they establish a foothold. A single exposed secret in a private repo can become a fast path to lateral movement across the entire infrastructure.

Industry exposure rates (public repositories):

These figures represent only what is visible externally. Internal exposure is 6× higher across the board.

Consulting firms turn secrets sprawl into third-party risk

Contractors and consulting firms operate across multiple client environments simultaneously. They hold credentials, tokens, and configuration knowledge for every client they serve — and they often work in personal accounts or repositories outside their client's GitHub organization.

GitGuardian's analysis of 13 consulting firms:

The Red Hat breach (October 2025): The cybercrime group "Crimson Collective" exfiltrated 570 GB of data from 28,000 repositories on Red Hat's internal consulting GitLab instance, affecting approximately 800 organizations worldwide. The leaked data contained:

• API keys and database credentials
• Authentication tokens and VPN configurations
• Infrastructure details and internal architecture

Affected organizations included Bank of America, JPMorgan Chase, IBM, Cisco, the U.S. Navy, and the NSA. The attackers used the harvested credentials to pivot directly into customer infrastructure.

Any organization that uses contractors or consulting firms has a third-party secrets problem, whether or not it has been discovered yet.

One in four internal leaks originate outside the codebase

Where internal incidents originate:

Collaboration tools (Slack, Jira, Confluence) account for 28% of incidents, with a 13 percentage-point higher critical severity rate than code-based leaks. Secrets shared through these tools tend to be production credentials shared during incident response or urgent troubleshooting, when people are moving fast and not thinking about security hygiene.

The 4% overlap between SCM and ODS findings means these are largely separate leak populations. Scanning only repositories misses roughly a quarter of an organization's total exposure.

80,000 secrets on self-hosted GitLab and Docker registries

GitGuardian identified thousands of self-hosted GitLab instances and Docker registries left publicly accessible without authentication.

Findings summary:

Validity rates by credential type (Docker vs. GitLab):

The closer an asset is to production, the higher the likelihood of finding a valid credential. The leak rate from self-hosted GitLab and Docker is 3–4× higher than from public GitHub.

The research also uncovered 300,000+ email addresses (including 2,000 with .gov domains) and references to internal database hosts and non-public infrastructure.

The "Russian dolls" effect: publicly exposed leaks contain valid secrets that grant access to private infrastructure, which in turn exposes more secrets, compounding the initial breach at each layer.

64% of leaked secrets from 2022 are still valid in 2026

Detection without remediation is not security — it is documentation. The longitudinal data in the 2026 report makes this case clearly.

Validity of secrets originally leaked in 2022, retested over time:

Those credentials have been sitting in public code, exploitable by anyone who finds them, for four years. The persistence is an operational signal that remediation — not detection — is the industry's limiting factor.

Why rotation rarely happens:

Credentials are not isolated strings. They are embedded across:

• Build systems and CI/CD pipelines
• Multiple repositories (duplicated)
• Container images (baked in at build time)
• CI variables and environment configs
• Vendor and third-party integrations

The short-term choice many teams make is not the safest one — it is the one that avoids breaking anything: do nothing.

NHI policy breach distribution (GitGuardian customer data):

Creation velocity is outpacing identity maturity. AI makes it easier to scaffold projects and connect services, but also easier to reproduce insecure patterns at scale when the default move is "just add a key."

Why validation-only prioritization fails

A widespread assumption in secrets security: if a secret cannot be validated — confirmed as currently active — deprioritize it. The 2026 report challenges this directly.

46% of critical secrets are invisible to validation-only tools

The gap exists because validation coverage is always incomplete:

• APIs change without notice
• New services launch constantly
• Each provider requires dedicated infrastructure to validate
• Regional and industry-specific platforms proliferate

Ignoring unvalidatable secrets by default is not a conservative strategy. It is a systematic blind spot.

Generic secrets drive half of all critical incidents

"Generic secrets" — private keys, custom API tokens, passwords, and access mechanisms detected through entropy checks and context rather than provider-specific patterns — are routinely deprioritized because they cannot be automatically validated.

The data says this is a mistake:

• 35% of critical incidents trace back to generic credentials
• 51% of high-or-critical incidents trace back to generic credentials

The Google joint research (2025): GitGuardian and Google analyzed one million leaked private keys against Certificate Transparency logs. Key findings:

• 4.5% of leaked keys mapped to trusted X.509 certificates
• Half had a valid certificate at the time they leaked
• 4,000+ HTTPS certificates are compromised per year because of a leaked key
• Affected organizations included multiple Fortune 500 companies and a trusted Certificate Authority
• GitGuardian sent 4,000+ alert emails to 600 organizations — response rate: under 10%

Valid does not always mean dangerous

The inverse problem is equally real. Approximately 10% of valid secrets are inherently low-impact — sandbox tokens, test environment credentials, low-privilege service accounts with access only to trivial data.

Without contextual risk scoring, teams rotate credentials in detection order or validation order, not threat order.

The four capabilities effective secrets security requires:

Teams still operating on validation-only approaches are systematically exposed to exactly the threats that matter most — while burning engineering time on credentials that pose little real danger.

The developer workstation as an overlooked attack surface

The Shai-Hulud 2 supply chain attack gave GitGuardian direct empirical data on what secrets actually look like on developer machines at scale. By compromising npm packages and executing at install time, the malware systematically harvested environment files and ran structured local secret scans across thousands of real machines.

Shai-Hulud 2 findings across 6,943 compromised machines:

Each live secret appeared in roughly eight different locations on the same machine — dotfiles, shell profiles, build outputs, IDE configs, and tool caches. Each copy is an independent vector for theft.

GitHub tokens dominated the validated set:

• 581 personal access tokens
• 386 OAuth tokens
• 104 fine-grained PATs
• 101 GitLab tokens

Each one enables repository access, workflow manipulation, or lateral movement across the software supply chain. And because 59% of compromised machines were CI/CD runners, this exposure extends well beyond the individual developer into shared build infrastructure.

GitGuardian considers these numbers conservative. The attack only ran where the malicious package was installed. It did not reach agent memory folders, IDE caches, or the growing surface area of AI-generated artifacts that now routinely include credentials.

Passwork is available as a self-hosted solution with full control over your data. It replaces shared .env files, credentials pasted into chat, and tokens baked into CI/CD configs — with a structured vault, role-based access, and a full audit log. Explore Passwork's deployment options

The path forward: From reactive detection to NHI governance

Detection catches what already exists. The goal is to get ahead of exposure — complete visibility into every credential in the environment: who owns it, what it accesses, and whether it should still exist at all. That shift, from chasing leaks to governing non-human identities, is what NHI governance means in practice.

Step 1. Centralize secrets in vault platforms

Make the vault the source of truth. When teams can reliably retrieve credentials from a single, access-controlled location, they stop inventing fragmented storage strategies — one of the primary drivers of secrets sprawl. Passwork's vault structure is designed for exactly this: organized, encrypted, and access-controlled storage for API keys, database passwords, certificates, SSH keys, and service account credentials.

Step 2. Automate rotation

If a secret must exist, it should not live forever. Regular credential replacement shortens the window an attacker can exploit a leaked secret and forces teams to treat credentials as objects with a lifecycle, not one-time setup tasks. Rotation is far simpler once a vaulting strategy is in place — the vault becomes the single location to update, rather than hunting down every place a credential was copied.

Step 3. Fix developer workflows

Developers hardcode secrets because it is the fastest way to get code working. Remove the need for shared .env files and copied tokens by making vault-based credential retrieval equally fast. The secure path has to be easier than the insecure one.

Step 4. Shift scanning earlier

Pre-commit scanning and workstation-level detection stop incidents before they land anywhere permanent. Modern scanning tools provide actionable signal with low false-positive rates — a significant improvement over the noisy tools that eroded developer trust in the past.

Step 5. Move toward identity-based authentication

The long-term exit from long-lived static secrets is short-lived, identity-driven access. Frameworks like SPIFFE, implemented by open-source SPIRE, replace shared-string authentication with strongly attested workload identity. Each workload receives just-in-time, short-lived credentials rather than a static key that can be copied, leaked, and exploited for years.

Three principles for 2026

Three governance questions every organization must answer

1. What non-human identities exist in our environment?
2. Who owns them?
3. What can they access?

If any of those questions cannot be answered with confidence, AI adoption is outpacing security posture.

Key takeaways for IT and security teams

The 2026 GitGuardian report is a detailed account of an accelerating problem. Here is what the data demands in practice:

Organizations that treat credential management as a lifecycle discipline — with centralized vaults, automated rotation, and enforced access control — will be best positioned for the agentic-AI era. Those that treat it as a cleanup task will keep finding that their secrets outlast their security assumptions.

The data is clear: secrets sitting in code, configs, and chat messages are a breach waiting to happen. Passwork gives your team a single, secure place to store, share, and rotate credentials — with role-based access, a full audit log, and self-hosted deployment that keeps everything within your own infrastructure. Try Passwork in your infrastructure

FAQ

What is secrets sprawl?

Secrets sprawl is the uncontrolled proliferation of hardcoded credentials — API keys, passwords, tokens, certificates, and connection strings — across codebases, configuration files, CI/CD pipelines, and collaboration tools. It occurs when credentials are created faster than they are tracked, rotated, or revoked, leaving organizations with an expanding inventory of exploitable access paths they cannot fully account for.

How many secrets were leaked on GitHub in 2025?

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025 — a 34% increase over 2024 and the largest single-year jump ever recorded. That figure covers only public repositories. Internal repositories, collaboration tools, and self-hosted infrastructure add substantially to the total exposure.

What percentage of leaked secrets are never revoked?

64% of secrets confirmed as valid in 2022 were still valid and exploitable as of January 2026, meaning they had been sitting in public code for four years without being rotated or revoked. The validity rate was approximately 70% when the same dataset was retested in January 2025, showing only a gradual decline despite four years of exposure.

Why are internal repositories more dangerous than public ones?

Internal repositories are 6× more likely to contain a hardcoded secret than public ones — 32.2% vs. 5.6% in 2025. Teams tend to be less cautious within a closed perimeter, assuming that a private repository is inherently safe. Internal repos also hold the most valuable credentials: CI/CD tokens, cloud access keys, and database credentials — exactly what attackers target once they establish a foothold.

How does AI-assisted coding increase the risk of secrets leaks?

AI coding assistants generate larger commits with more code per change, increasing the surface area for credential exposure. Claude Code co-authored commits leaked secrets at 3.2% — more than double the 1.5% baseline across all public GitHub commits. LLM infrastructure secrets are leaking 5× faster than core model provider secrets. Each new AI service integration adds credentials that can be hardcoded, copied, and leaked.

What are MCP configuration files and why do they leak secrets?

Model Context Protocol (MCP) is the standard for connecting large language models to external tools and data sources. MCP configuration files define how an AI agent connects to databases, APIs, and services — and those connections require credentials. In 2025, GitGuardian found 24,008 unique secrets in MCP config files on public GitHub, with 2,117 confirmed valid. Official MCP setup guides often normalize hardcoding credentials directly into config files, which propagates the problem.

What is validation-only prioritization and why does it fail?

Validation-only prioritization is the practice of deprioritizing secrets that cannot be confirmed as currently active. It fails because 46% of critical secrets cannot be validated — they belong to services without validation checkers, or to generic credential types like private keys and custom tokens. Teams using this approach miss nearly half their most dangerous leaks while spending remediation effort on low-risk valid credentials. Effective prioritization requires contextual risk scoring, not just a validity check.

What is NHI governance and why does it matter?

Non-human identity (NHI) governance is the practice of managing the full lifecycle of machine identities — service accounts, API keys, agent tokens, and other non-human credentials — with the same rigor applied to human user accounts. It answers three questions: what NHIs exist in the environment, who owns them, and what can they access. As AI-assisted development accelerates credential creation, NHI governance is the discipline that prevents creation velocity from permanently outpacing security posture.

OAuth token theft and credential attacks: April 2026 review

APT28 hijacked 18,000 routers to steal OAuth tokens. Storm-2372 bypassed MFA without touching a password. 28.6 million secrets leaked on GitHub. April 2026’s biggest incidents — and what they have in common.

Passwork BlogAlex Muntyan

Inside real supply chain attacks: Bitwarden CLI, Axios, and Vercel

Why breach your network when attackers can compromise a trusted dependency with millions of downloads and slip silently into thousands of organizations at once? Three 2026 campaigns prove supply chain attacks are no longer isolated incidents.

Passwork BlogAlex Muntyan

Password chaos: Why it’s a business problem and how to fix it

A forgotten password costs $70. A breach costs $4.44 million. Both start the same way — credentials shared over Slack, stored in spreadsheets, never rotated. Here’s what password chaos actually costs and how to eliminate it.

Passwork BlogAlex Muntyan

Einführung

In Unternehmensumgebungen steigt die Anzahl der Passwörter, Schlüssel und digitalen Zertifikate rasant an, und Secrets Management wird zu einer der kritischen Aufgaben für IT-Teams.

Secrets Management umfasst den gesamten Lebenszyklus sensibler Daten: von der sicheren Generierung und verschlüsselten Speicherung bis hin zur automatisierten Rotation und Audit-Trails. Mit der Einführung von Cloud-Infrastruktur, Microservices und DevOps-Praktiken in Organisationen verschärft sich die Herausforderung — Anwendungen benötigen nahtlosen Zugriff auf Anmeldedaten unter Einhaltung von Zero-Trust-Sicherheitsprinzipien.

IT-Abteilungen und DevOps-Teams stehen vor Situationen, in denen es zu viele Secrets gibt, die schwer zu strukturieren, zu kontrollieren und zu schützen sind. In realen Projekten verteilen sich diese Secrets über Konfigurationsdateien, Umgebungsvariablen, Deployment-Skripte und tauchen gelegentlich in öffentlichen Repositories auf.

Was ist Secrets Management

Secrets Management ist eine Best Practice der Cybersicherheit und eine Reihe von Tools zur sicheren Speicherung, Verwaltung, zum Zugriff und zur Rotation von digitalen Authentifizierungsdaten, die von nicht-menschlichen Identitäten wie Anwendungen, Diensten, Servern und automatisierten Workloads verwendet werden.

Solche Secrets umfassen Passwörter, Passphrasen, SSH-, API- und Verschlüsselungsschlüssel, Zugangstokens, digitale Zertifikate und alle anderen Anmeldedaten, die sicheren Zugriff auf die Infrastruktur ermöglichen.

Warum Secrets Management wichtig ist

Der Schutz vertraulicher Informationen ist eine zentrale Priorität für jedes Unternehmen. Secrets erfordern strenge Kontrolle in jeder Phase ihres Lebenszyklus. Hier sind einige Vorteile eines ordnungsgemäßen Secrets Managements:

• Zentralisierte Speicherung. Alle Passwörter, Schlüssel und Tokens werden in einem einzigen geschützten Repository gespeichert, wodurch verhindert wird, dass sie in offenen Dokumenten, Skripten oder Quellcode landen. Dies reduziert das Risiko von Lecks und unbefugtem Zugriff.
• Flexible Zugriffsverwaltung. Das System ermöglicht die individuelle Festlegung, wer auf welche Secrets zugreifen kann — ob einzelne Mitarbeiter, Gruppen oder Dienstkonten. Dies hilft bei der Umsetzung des Prinzips der minimalen Berechtigung und reduziert potenzielle Angriffsvektoren.
• Vollständige Kontrolle und operative Transparenz. Jede Anfrage wird protokolliert: Sie können nachverfolgen, wer wann welche Aktionen durchgeführt hat. Auditing erleichtert die Einhaltung von Vorschriften und macht Sicherheitsprozesse maximal transparent.
• Automatisierte Rotation. Passwörter und Schlüssel werden regelmäßig automatisch aktualisiert — nach Zeitplan oder bei erkannten Bedrohungen. Dies spart IT-Ressourcen und verringert die Wahrscheinlichkeit, veraltete oder kompromittierte Daten zu verwenden.
• Integration mit Infrastruktur und DevOps. Der Zugriff auf Secrets erfolgt über API, CLI, SDK und Plugins, was die Systemintegration mit CI/CD-Pipelines, Cloud-Plattformen, Containern und Datenbanken vereinfacht.
• Schnelle Reaktion auf Vorfälle. Ein zentralisierter Ansatz ermöglicht das schnelle Widerrufen oder Ersetzen gefährdeter Secrets, minimiert die Folgen von Vorfällen und verhindert die Ausbreitung von Bedrohungen innerhalb des Unternehmens.

Ohne eine einheitliche Lösung „wandern" Secrets oft durch Konfigurationsdateien und Quellcode, was deren Aktualisierung erschwert und Kompromittierungsrisiken erhöht. Unternehmenspasswort-Manager lösen diese Aufgabe, aber nicht alle unterstützen die für moderne DevOps-Prozesse erforderliche Automatisierung.

Passwork: Mehr als ein Passwort-Manager

Passwork begann als Unternehmenspasswort-Manager — ein einfaches und praktisches Tool zur Speicherung von Anmeldedaten. Aber moderne IT-Teams benötigen mehr: Automatisierung, Integration und programmatischen Zugriff auf Secrets.

Mit Passwork 7 hat sich die Plattform über die traditionelle Passwortspeicherung hinaus zu einem vollwertigen Secrets-Management-System entwickelt.

API-first-Architektur

Passwork basiert auf API-first-Prinzipien. Das bedeutet, dass jede in der Benutzeroberfläche verfügbare Funktion auch über REST API verfügbar ist.

Die API bietet programmatischen Zugriff auf alle Systemfunktionen: Passwortverwaltung, Tresore, Ordner, Benutzer, Rollen, Tags, Dateianhänge und Ereignisprotokolle. Dies ermöglicht die Automatisierung von Zugriffsbereitstellung und -entzug, die programmatische Aktualisierung von Passwörtern, die Integration von Passwork in CI/CD-Pipelines und den Export von Protokollen zur Analyse.

Zwei Produkte in einem

Mit anderen Worten kombiniert Passwork jetzt zwei vollwertige Produkte:

• Passwort-Manager — intuitive Oberfläche für sichere Speicherung von Anmeldedaten und Teamzusammenarbeit.
• Secrets-Management-System — programmatischer Zugriff über REST API, Python-Connector, CLI und Docker-Container zur Workflow-Automatisierung.

Automatisierungstools

Python-Connector

Der offizielle Python-Connector von Passwork beseitigt die Komplexität der Arbeit mit Low-Level-API-Aufrufen und Kryptographie. Verwalten Sie Secrets über einfache Methoden — ohne manuelle HTTP-Anfragenbehandlung oder Datentransformationen.

Anwendungsbeispiel:

from passwork_client import PassworkClient

client = PassworkClient(host="https://passwork.example.com")
client.set_tokens("ACCESS_TOKEN", "REFRESH_TOKEN")  # pass tokens
client.set_master_key("MASTER_KEY")  # master key for decryption

# create vault and password
vault_id = client.create_vault(vault_name="DevOps", type_id="vault_id_type")
password_data = {
    "Name": "Database PROD", 
    "vaultId": vault_id,
    "title": "DB prod",
    "login": "admin",
    "password": "secure-password",
    "url": "https://db.example.com"
}
password_id = client.create_item(password_data)

# retrieve and use password
secret = client.get_item(password_id)
print(secret['password'])

Hauptfunktionen:

• Einfache Methoden wie create_item(), get_item(), create_vault() erledigen alle Operationen; keine manuellen HTTP-Anfragen erforderlich
• Client-seitige Kryptographie — der Masterpasswort verlässt nie Ihre Umgebung
• Der Connector speichert, stellt wieder her und aktualisiert Tokens automatisch
• Die universelle call()-Methode ermöglicht den Zugriff auf jeden API-Endpunkt, auch solche ohne dedizierte Methoden

Der Python-Connector beschleunigt Automatisierung und Integration ohne unnötige Komplexität.

CLI-Dienstprogramm

Für Shell-Skript- und CI/CD-Automatisierung bietet Passwork CLI ein universelles Tool mit zwei Betriebsmodi:

• exec — extrahiert Secrets, erstellt Umgebungsvariablen und führt Ihren Prozess aus. Passwörter werden nie gespeichert und sind nur während der Ausführung verfügbar.
• api — ruft jede Passwork-API-Methode auf und gibt JSON-Antworten zurück.

Hauptfunktionen:

• Passwörter werden als Umgebungsvariablen eingefügt
• Secrets werden automatisch in CI/CD-Pipelines geladen
• Temporäre Variablen ermöglichen Dienstkonto-Operationen
• Native Integration mit Ansible, Terraform, Jenkins und ähnlichen Tools

Anwendungsbeispiele

Passwort abrufen und Befehl ausführen:

# Export environment variables
export PASSWORK_HOST="https://passwork.example.com"
export PASSWORK_TOKEN="your_token"
export PASSWORK_MASTER_KEY="your_master_key"

# Retrieve password by ID and run MySQL client
passwork-cli exec --password-id "db_password_id" mysql -u admin -h localhost -p $DB_PASSWORD database_name

Skript mit mehreren Secrets ausführen:

passwork-cli exec \
  --password-id "db123,api456,storage789" \
  deploy.sh --db-pass=$DATABASE_PASSWORD --api-key=$API_KEY --storage-key=$STORAGE_KEY

Tresorliste über API abrufen:

passwork-cli api --method GET --endpoint "v1/vaults"

Die CLI unterstützt Tag- und Ordnerfilterung, benutzerdefinierte Felder, Token-Aktualisierung und flexible Konfiguration für diverse Automatisierungsszenarien.

Docker-Container

Für die CI/CD-Integration ermöglicht das offizielle passwork/passwork-cli Docker-Image schnelle CLI-Starts in isolierten Umgebungen.

Startbeispiel:

docker run -it --rm \
  -e PASSWORK_HOST="https://passwork.example.com" \
  -e PASSWORK_TOKEN="your_access_token" \
  -e PASSWORK_MASTER_KEY="your_master_key" \
  passwork-cli exec --password-id "db_password_id" mysql -h db_host -u admin -p $DB_PASSWORD db_name

Hauptfunktionen:

• Bereit für GitLab, Bitbucket Pipelines und docker-compose-Workflows
• Secrets können einfach zwischen Containern übergeben werden

Wie Passwort-Rotation automatisiert wird

Regelmäßige Passwortänderungen sind eine grundlegende Sicherheitsanforderung, aber manuelle Rotation birgt Risiken und kostet Zeit. Passwork ermöglicht vollständige Automatisierung über den Python-Connector.

Rotations-Workflow:

1. Aktuelles Passwort aus Passwork abrufen (get_item)
2. Neues sicheres Passwort generieren
3. Passwort im Zielsystem ändern (z. B. ALTER USER für Datenbanken)
4. Eintrag in Passwork aktualisieren (update_item)
5. Team über den Abschluss benachrichtigen

Beispielimplementierung:

from passwork_client import PassworkClient
import secrets
import psycopg2

def rotate_db_password(passwork_host, accessToken, refreshToken, master_key, password_id, db_params):
    client = PassworkClient(passwork_host)
    client.set_tokens(accessToken, refreshToken)
    client.set_master_key(master_key)
    
    secret = client.get_item(password_id)
    current_password = secret['password']
    new_password = secrets.token_urlsafe(32)
    
    conn = psycopg2.connect(
        dbname=db_params['db'], 
        user=db_params['user'],
        password=current_password, 
        host=db_params['host']
    )
    
    with conn.cursor() as cur:
        cur.execute(f"ALTER USER {db_params['user']} WITH PASSWORD '{new_password}'")
    conn.commit()
    
    client.update_item(password_id, {"password": new_password})
    print("Password successfully rotated and updated in Passwork")

Vorteile:

• Vollständig automatisierte Rotation eliminiert manuelle Aktionen und menschliche Fehler
• Neues Passwort ist sofort für das gesamte Team verfügbar — keine Verzögerungen oder Kommunikationslücken

Sicherheit: Zero Knowledge und Verschlüsselung

Passwork implementiert eine Zero-Knowledge-Architektur: Der Server greift nie auf Secrets im Klartext zu. Selbst Administratoren mit vollem Infrastrukturzugriff können Ihre Daten nicht lesen.

• Server-seitige Verschlüsselung — Alle Secrets werden verschlüsselt auf dem Server gespeichert. Geeignet für interne Netzwerke und Standard-Sicherheitsanforderungen.
• Client-seitige Verschlüsselung (CSE) — Secrets werden vor der Übertragung auf dem Client verschlüsselt; nur Chiffretext erreicht den Server. Der Masterpasswort wird aus dem Masterpasswort des Benutzers abgeleitet. Unverzichtbar für Cloud-Deployments oder strenge Compliance-Anforderungen.

Wahl des Modells:

• Cloud-Deployment oder strenge Compliance → CSE aktivieren
• Internes Netzwerk mit Standardanforderungen → Server-seitige Verschlüsselung ausreichend

Autorisierung und Tokens

Die Passwork API verwendet ein Token-Paar: accessToken und refreshToken.

• Access Token — Kurzlebige Anmeldedaten für API-Anfragen
• Refresh Token — Ermöglicht automatische Access-Token-Erneuerung ohne erneute Autorisierung

Der Python-Connector verwaltet die Token-Aktualisierung automatisch und gewährleistet stabile Integrationen ohne manuellen Eingriff.

Best Practices für die Sicherheit:

• Dedizierte Dienstkonten erstellen — Minimale Berechtigungen zuweisen, Zugriff nur auf erforderliche Tresore und Ordner gewähren
• Tokens regelmäßig rotieren — Ablaufrichtlinien festlegen und Anmeldedaten nach Zeitplan aktualisieren
• Sichere Token-Speicherung — Umgebungsvariablen oder dedizierte Secret-Tresore verwenden (niemals hartcodieren)
• HTTPS erzwingen — Immer verschlüsselte Verbindungen für die API-Kommunikation verwenden

Fazit

Passwork hat sich von einem Passwort-Manager zu einer umfassenden Secrets-Management-Plattform entwickelt. Die offene API, der Python-Connector, CLI und das Docker-Image ermöglichen nahtlose Integration in jeden Workflow bei gleichzeitiger Zentralisierung von Secrets mit granularer Zugriffskontrolle.

• Für Administratoren: Zuverlässige Speicherung mit integrierten Automatisierungsfunktionen.
• Für Entwickler und DevOps: Produktionsreife API und Tools für sichere Secrets-Handhabung.

Passwork konsolidiert, was typischerweise mehrere Lösungen erfordert, in einem einzigen System mit einheitlicher Verwaltung. Dies reduziert den operativen Aufwand, vereinfacht Rotations-Workflows und bietet IT- und Entwicklungsteams transparente Sicherheitskontrollen.

Als Secrets-Management-Plattform liefert Passwork eine geschützte, skalierbare Infrastruktur, die sich an die Bedürfnisse Ihrer Organisation anpasst.

Weiterführende Lektüre

Passwork 7.1: Tresortypen

Table of contents * What are vault types * Basic vault types * Advantages of vault types * Managing vault types * Migration from previous versions * Conclusion: Data control and efficiency Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a

Passwork BlogEirik Salmi

DSGVO-Passwortsicherheit: Leitfaden für effektive Mitarbeiterschulung

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

HIPAA-Anforderungen für das Passwort-Management

Table of contents * Introduction * How HIPAA works * Cybersecurity and clinical efficiency * HIPAA and password management * How to train staff to meet HIPAA standards * How Passwork supports HIPAA compliance * Sustainable HIPAA compliance Introduction In the complex ecosystem of modern healthcare, patient data is essential for secure management. In 2024, the U.

Passwork BlogAna Moore

Introducción

En el entorno corporativo, el número de contraseñas, claves y certificados digitales está aumentando rápidamente, y la gestión de secretos se está convirtiendo en una de las tareas críticas para los equipos de TI.

La gestión de secretos abarca el ciclo de vida completo de los datos sensibles: desde la generación segura y el almacenamiento cifrado hasta la rotación automatizada y los registros de auditoría. A medida que las organizaciones adoptan infraestructura en la nube, microservicios y prácticas DevOps, el desafío se intensifica — las aplicaciones necesitan acceso fluido a las credenciales mientras mantienen los principios de seguridad de confianza cero.

Los departamentos de TI y los equipos DevOps enfrentan situaciones donde hay demasiados secretos que se vuelven difíciles de estructurar, controlar y proteger. En proyectos reales, estos secretos se dispersan en archivos de configuración, variables de entorno, scripts de despliegue y ocasionalmente aparecen en repositorios públicos.

Qué es la gestión de secretos

La gestión de secretos es una práctica recomendada de ciberseguridad y un conjunto de herramientas para almacenar, gestionar, acceder y rotar de forma segura las credenciales de autenticación digital utilizadas por identidades no humanas como aplicaciones, servicios, servidores y cargas de trabajo automatizadas.

Dichos secretos incluyen contraseñas, frases de contraseña, claves SSH, API y de cifrado, tokens de acceso, certificados digitales y cualquier otra credencial que permita el acceso seguro a la infraestructura.

Por qué es importante la gestión de secretos

Proteger la información confidencial es una prioridad clave para cualquier empresa. Los secretos requieren un control estricto en cada etapa de su ciclo de vida. Estos son solo algunos beneficios de una gestión adecuada de secretos:

• Almacenamiento centralizado. Todas las contraseñas, claves y tokens se almacenan en un único repositorio protegido, evitando que terminen en documentos abiertos, scripts o código fuente, reduciendo el riesgo de filtraciones y acceso no autorizado.
• Gestión de acceso flexible. El sistema permite determinar de forma individualizada quién puede acceder a qué secretos, ya sean empleados individuales, grupos o cuentas de servicio. Esto ayuda a implementar el principio de mínimo privilegio y reduce los vectores de ataque potenciales.
• Control completo y transparencia operativa. Cada solicitud se registra: puede rastrear quién, cuándo y qué acciones se realizaron. La auditoría facilita el cumplimiento normativo y hace que los procesos de seguridad sean máximamente transparentes.
• Rotación automatizada. Las contraseñas y claves se actualizan regularmente de forma automática, según un horario o cuando se detectan amenazas. Esto ahorra recursos de TI y reduce la probabilidad de usar datos obsoletos o comprometidos.
• Integración con infraestructura y DevOps. El acceso a los secretos se proporciona a través de API, CLI, SDK y plugins, simplificando la integración del sistema con pipelines CI/CD, plataformas en la nube, contenedores y bases de datos.
• Respuesta rápida a incidentes. Un enfoque centralizado permite revocar o reemplazar rápidamente secretos vulnerables, minimizando las consecuencias de los incidentes y previniendo la propagación de amenazas dentro de la empresa.

Sin una solución unificada, los secretos a menudo «deambulan» por archivos de configuración y código fuente, complicando sus actualizaciones y aumentando los riesgos de compromiso. Los gestores de contraseñas corporativos resuelven esta tarea, pero no todos admiten la automatización necesaria para los procesos DevOps modernos.

Passwork: Más que un gestor de contraseñas

Passwork comenzó como un gestor de contraseñas corporativo — una herramienta simple y conveniente para almacenar credenciales. Pero los equipos de TI modernos necesitan más: automatización, integración y acceso programático a los secretos.

Con Passwork 7, la plataforma evolucionó más allá del almacenamiento tradicional de contraseñas hacia un sistema de gestión de secretos completo.

Arquitectura API-first

Passwork está construido sobre principios API-first. Esto significa que cada función disponible en la interfaz de usuario está disponible a través de REST API.

La API proporciona acceso programático a todas las funciones del sistema: gestión de contraseñas, bóvedas, carpetas, usuarios, roles, etiquetas, archivos adjuntos y registros de eventos. Esto permite automatizar el aprovisionamiento y revocación de acceso, actualizar contraseñas de forma programática, integrar Passwork en pipelines CI/CD y exportar registros para análisis.

Dos productos en uno

En otras palabras, Passwork ahora combina dos productos completos:

• Gestor de contraseñas — interfaz intuitiva para almacenamiento seguro de credenciales y colaboración en equipo.
• Sistema de gestión de secretos — acceso programático a través de REST API, conector Python, CLI y contenedor Docker para automatización de flujos de trabajo.

Herramientas de automatización

Conector Python

El conector Python oficial de Passwork elimina la complejidad de trabajar con llamadas API de bajo nivel y criptografía. Gestione secretos mediante métodos simples — sin necesidad de manejo manual de solicitudes HTTP ni transformaciones de datos.

Ejemplo de uso:

from passwork_client import PassworkClient

client = PassworkClient(host="https://passwork.example.com")
client.set_tokens("ACCESS_TOKEN", "REFRESH_TOKEN")  # pass tokens
client.set_master_key("MASTER_KEY")  # master key for decryption

# create vault and password
vault_id = client.create_vault(vault_name="DevOps", type_id="vault_id_type")
password_data = {
    "Name": "Database PROD", 
    "vaultId": vault_id,
    "title": "DB prod",
    "login": "admin",
    "password": "secure-password",
    "url": "https://db.example.com"
}
password_id = client.create_item(password_data)

# retrieve and use password
secret = client.get_item(password_id)
print(secret['password'])

Características principales:

• Métodos simples como create_item(), get_item(), create_vault() manejan todas las operaciones; no se necesitan solicitudes HTTP manuales
• Criptografía del lado del cliente — la clave maestra nunca sale de su entorno
• El conector guarda, restaura y actualiza tokens automáticamente
• El método universal call() permite acceder a cualquier endpoint de la API, incluso aquellos sin métodos dedicados

El conector Python acelera la automatización e integración sin complejidad innecesaria.

Utilidad CLI

Para la automatización de scripts de shell y CI/CD, Passwork CLI proporciona una herramienta universal con dos modos de operación:

• exec — extrae secretos, crea variables de entorno y ejecuta su proceso. Las contraseñas nunca se guardan y solo están disponibles durante la ejecución.
• api — llama a cualquier método de la API de Passwork y devuelve respuestas JSON.

Características principales:

• Contraseñas inyectadas como variables de entorno
• Secretos cargados automáticamente en pipelines CI/CD
• Variables temporales permiten operaciones de cuentas de servicio
• Integración nativa con Ansible, Terraform, Jenkins y herramientas similares

Ejemplos de uso

Recuperar una contraseña y ejecutar un comando:

# Export environment variables
export PASSWORK_HOST="https://passwork.example.com"
export PASSWORK_TOKEN="your_token"
export PASSWORK_MASTER_KEY="your_master_key"

# Retrieve password by ID and run MySQL client
passwork-cli exec --password-id "db_password_id" mysql -u admin -h localhost -p $DB_PASSWORD database_name

Ejecutar script con múltiples secretos:

passwork-cli exec \
  --password-id "db123,api456,storage789" \
  deploy.sh --db-pass=$DATABASE_PASSWORD --api-key=$API_KEY --storage-key=$STORAGE_KEY

Obtener lista de bóvedas a través de la API:

passwork-cli api --method GET --endpoint "v1/vaults"

El CLI admite filtrado por etiquetas y carpetas, campos personalizados, actualización de tokens y configuración flexible para diversos escenarios de automatización.

Contenedor Docker

Para la integración CI/CD, la imagen oficial passwork/passwork-cli Docker permite lanzamientos rápidos del CLI en entornos aislados.

Ejemplo de lanzamiento:

docker run -it --rm \
  -e PASSWORK_HOST="https://passwork.example.com" \
  -e PASSWORK_TOKEN="your_access_token" \
  -e PASSWORK_MASTER_KEY="your_master_key" \
  passwork-cli exec --password-id "db_password_id" mysql -h db_host -u admin -p $DB_PASSWORD db_name

Características principales:

• Listo para GitLab, Bitbucket Pipelines y flujos de trabajo docker-compose
• Secretos fácilmente compartidos entre contenedores

Cómo automatizamos la rotación de contraseñas

Los cambios regulares de contraseña son un requisito fundamental de seguridad, pero la rotación manual introduce riesgos y desperdicia tiempo. Passwork permite una automatización completa a través del conector Python.

Flujo de trabajo de rotación:

1. Recuperar la contraseña actual de Passwork (get_item)
2. Generar nueva contraseña segura
3. Cambiar la contraseña en el sistema de destino (por ejemplo, ALTER USER para bases de datos)
4. Actualizar el registro en Passwork (update_item)
5. Notificar al equipo de la finalización

Ejemplo de implementación:

from passwork_client import PassworkClient
import secrets
import psycopg2

def rotate_db_password(passwork_host, accessToken, refreshToken, master_key, password_id, db_params):
    client = PassworkClient(passwork_host)
    client.set_tokens(accessToken, refreshToken)
    client.set_master_key(master_key)
    
    secret = client.get_item(password_id)
    current_password = secret['password']
    new_password = secrets.token_urlsafe(32)
    
    conn = psycopg2.connect(
        dbname=db_params['db'], 
        user=db_params['user'],
        password=current_password, 
        host=db_params['host']
    )
    
    with conn.cursor() as cur:
        cur.execute(f"ALTER USER {db_params['user']} WITH PASSWORD '{new_password}'")
    conn.commit()
    
    client.update_item(password_id, {"password": new_password})
    print("Password successfully rotated and updated in Passwork")

Beneficios:

• La rotación completamente automatizada elimina acciones manuales y errores humanos
• La nueva contraseña está disponible inmediatamente para todo el equipo — sin retrasos ni brechas de comunicación

Seguridad: Zero knowledge y cifrado

Passwork implementa arquitectura Zero knowledge: el servidor nunca accede a los secretos en texto plano. Incluso los administradores con acceso completo a la infraestructura no pueden leer sus datos.

• Cifrado del lado del servidor — Todos los secretos se almacenan cifrados en el servidor. Adecuado para redes internas y requisitos de seguridad estándar.
• Cifrado del lado del cliente (CSE) — Los secretos se cifran en el cliente antes de la transmisión; solo el texto cifrado llega al servidor. La clave maestra se deriva de la contraseña maestra del usuario. Esencial para despliegues en la nube o requisitos de cumplimiento estrictos.

Elegir su modelo:

• Despliegue en la nube o cumplimiento estricto → Habilitar CSE
• Red interna con requisitos estándar → El cifrado del lado del servidor es suficiente

Autorización y tokens

La API de Passwork utiliza un par de tokens: accessToken y refreshToken.

• Token de acceso — Credencial de corta duración para solicitudes API
• Token de actualización — Permite la renovación automática del token de acceso sin reautorización

El conector Python maneja la actualización de tokens automáticamente, asegurando integraciones estables sin intervención manual.

Mejores prácticas de seguridad:

• Crear cuentas de servicio dedicadas — Asignar permisos mínimos, otorgar acceso solo a las bóvedas y carpetas requeridas
• Rotar tokens regularmente — Establecer políticas de expiración y actualizar credenciales según un horario
• Almacenamiento seguro de tokens — Usar variables de entorno o bóvedas de secretos dedicadas (nunca codificar directamente)
• Aplicar HTTPS — Siempre usar conexiones cifradas para la comunicación API

Conclusiones

Passwork ha evolucionado de un gestor de contraseñas a una plataforma integral de gestión de secretos. La API abierta, el conector Python, CLI e imagen Docker permiten una integración perfecta en cualquier flujo de trabajo mientras centralizan los secretos con control de acceso granular.

• Para administradores: Almacenamiento confiable con capacidades de automatización integradas.
• Para desarrolladores y DevOps: API y herramientas listas para producción para el manejo seguro de secretos.

Passwork consolida lo que típicamente requiere múltiples soluciones en un único sistema con gestión unificada. Esto reduce la sobrecarga operativa, simplifica los flujos de trabajo de rotación y proporciona a los equipos de TI y desarrollo controles de seguridad transparentes.

Como plataforma de gestión de secretos, Passwork ofrece una infraestructura protegida y escalable que se adapta a las necesidades de su organización.

Lecturas adicionales

Passwork 7.1: Tipos de bóvedas

Table of contents * What are vault types * Basic vault types * Advantages of vault types * Managing vault types * Migration from previous versions * Conclusion: Data control and efficiency Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a

Passwork BlogEirik Salmi

Seguridad de contraseñas GDPR: Guía para una formación eficaz del personal

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

Requisitos de HIPAA para la gestión de contraseñas

Table of contents * Introduction * How HIPAA works * Cybersecurity and clinical efficiency * HIPAA and password management * How to train staff to meet HIPAA standards * How Passwork supports HIPAA compliance * Sustainable HIPAA compliance Introduction In the complex ecosystem of modern healthcare, patient data is essential for secure management. In 2024, the U.

Passwork BlogAna Moore

Introduction

In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams.

Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As organizations adopt cloud infrastructure, microservices, and DevOps practices, the challenge intensifies — applications need seamless access to credentials while maintaining zero-trust security principles.

IT departments and DevOps teams face situations where there are too many secrets that become difficult to structure, control, and protect. In real-world projects, these secrets scatter across config files, environment variables, deployment scripts, and occasionally surface in public repositories.

What is secrets management

Secrets management is a cybersecurity best practice and set of tools for securely storing, managing, accessing, and rotating digital authentication credentials used by non-human identities such as applications, services, servers, and automated workloads.

Such secrets include passwords, passphrases, SSH, API and encryption keys, access tokens, digital certificates, and any other credentials that enable secure access to infrastructure.

Why secrets management matters

Protecting confidential information is a key priority for any business. Secrets require strict control at every stage of their lifecycle. That's just a few benefits of proper secrets management:

• Centralized storage. All passwords, keys, and tokens are stored in a single protected repository, preventing them from ending up in open docs, scripts, or source code, reducing the risk of leaks and unauthorized access.
• Flexible access management. The system allows individualized determination of who can access which secrets, whether individual employees, groups, or service accounts. This helps implement the principle of least privilege and reduces potential attack vectors.
• Complete control and operational transparency. Every request is logged: you can track who, when, and what actions were performed. Auditing facilitates regulatory compliance and makes security processes maximally transparent.
• Automated rotation. Passwords and keys are regularly updated automatically, on schedule or when threats are detected. This saves IT resources and reduces the likelihood of using outdated or compromised data.
• Integration with infrastructure and DevOps. Access to secrets is provided through API, CLI, SDK, and plugins, simplifying system integration with CI/CD pipelines, cloud platforms, containers, and databases.
• Rapid incident response. A centralized approach allows quick revocation or replacement of vulnerable secrets, minimizing incident consequences and preventing threat propagation within the company.

Without a unified solution, secrets often "wander" through configuration files and source code, complicating their updates and increasing compromise risks. Corporate password managers solve this task, but not all of them support the necessary automation for modern DevOps processes.

Passwork: More than a password manager

Passwork started as a corporate password manager — a simple and convenient tool for storing credentials. But modern IT teams need more: automation, integration, and programmatic access to secrets.

With Passwork 7, the platform evolved beyond traditional password storage into a full-fledged secrets management system.

API-first architecture

Passwork is built on API-first principles. This means that every function available in the UI is available through REST API.

The API provides programmatic access to all system functions: password management, vaults, folders, users, roles, tags, file attachments, and event logs. This enables you to automate access provisioning and revocation, update passwords programmatically, integrate Passwork into CI/CD pipelines, and export logs for analysis.

Two products in one

In other words, Passwork now combines two full-fledged products:

• Password manager — intuitive interface for secure credential storage and team collaboration.
• Secrets management system — programmatic access through REST API, Python connector, CLI, and Docker container for workflow automation.

Automation tools

Python connector

Passwork's official Python connector eliminates the complexity of working with low-level API calls and cryptography. Manage secrets through simple methods—no manual HTTP request handling or data transformations required.

Usage example:

from passwork_client import PassworkClient

client = PassworkClient(host="https://passwork.example.com")
client.set_tokens("ACCESS_TOKEN", "REFRESH_TOKEN")  # pass tokens
client.set_master_key("MASTER_KEY")  # master key for decryption

# create vault and password
vault_id = client.create_vault(vault_name="DevOps", type_id="vault_id_type")
password_data = {
    "Name": "Database PROD", 
    "vaultId": vault_id,
    "title": "DB prod",
    "login": "admin",
    "password": "secure-password",
    "url": "https://db.example.com"
}
password_id = client.create_item(password_data)

# retrieve and use password
secret = client.get_item(password_id)
print(secret['password'])

Key features:

• Simple methods like create_item(), get_item(), create_vault() handle all operations; no manual HTTP requests needed
• Client-side cryptography — master key never leaves your environment
• Connector automatically saves, restores, and refreshes tokens
• Universal call() method enables access to any API endpoint, even those without dedicated methods

The Python connector accelerates automation and integration without unnecessary complexity.

CLI utility

For shell script and CI/CD automation, Passwork CLI provides a universal tool with two operating modes:

• exec — extracts secrets, creates environment variables, and runs your process. Passwords are never saved and are only available during execution.
• api — calls any Passwork API method and returns JSON responses.

Key features:

• Passwords injected as environment variables
• Secrets automatically loaded in CI/CD pipelines
• Temporary variables enable service account operations
• Native integration with Ansible, Terraform, Jenkins, and similar tools

Usage examples

Retrieve a password and execute a command:

# Export environment variables
export PASSWORK_HOST="https://passwork.example.com"
export PASSWORK_TOKEN="your_token"
export PASSWORK_MASTER_KEY="your_master_key"

# Retrieve password by ID and run MySQL client
passwork-cli exec --password-id "db_password_id" mysql -u admin -h localhost -p $DB_PASSWORD database_name

Running script with multiple secrets:

passwork-cli exec \
  --password-id "db123,api456,storage789" \
  deploy.sh --db-pass=$DATABASE_PASSWORD --api-key=$API_KEY --storage-key=$STORAGE_KEY

Getting vault list through API:

passwork-cli api --method GET --endpoint "v1/vaults"

The CLI supports tag and folder filtering, custom fields, token refresh, and flexible configuration for diverse automation scenarios.

Docker container

For CI/CD integration, the official passwork/passwork-cli Docker image enables quick CLI launches in isolated environments.

Launch example:

docker run -it --rm \
  -e PASSWORK_HOST="https://passwork.example.com" \
  -e PASSWORK_TOKEN="your_access_token" \
  -e PASSWORK_MASTER_KEY="your_master_key" \
  passwork-cli exec --password-id "db_password_id" mysql -h db_host -u admin -p $DB_PASSWORD db_name

Key features:

• Ready for GitLab, Bitbucket Pipelines, and docker-compose workflows
• Secrets easily passed between containers

How we automate password rotation

Regular password changes are a fundamental security requirement, but manual rotation introduces risk and wastes time. Passwork enables complete automation through the Python connector.

Rotation workflow:

1. Retrieve current password from Passwork (get_item)
2. Generate new secure password
3. Change password in target system (e.g., ALTER USER for databases)
4. Update record in Passwork (update_item)
5. Notify team of completion

Example implementation:

from passwork_client import PassworkClient
import secrets
import psycopg2

def rotate_db_password(passwork_host, accessToken, refreshToken, master_key, password_id, db_params):
    client = PassworkClient(passwork_host)
    client.set_tokens(accessToken, refreshToken)
    client.set_master_key(master_key)
    
    secret = client.get_item(password_id)
    current_password = secret['password']
    new_password = secrets.token_urlsafe(32)
    
    conn = psycopg2.connect(
        dbname=db_params['db'], 
        user=db_params['user'],
        password=current_password, 
        host=db_params['host']
    )
    
    with conn.cursor() as cur:
        cur.execute(f"ALTER USER {db_params['user']} WITH PASSWORD '{new_password}'")
    conn.commit()
    
    client.update_item(password_id, {"password": new_password})
    print("Password successfully rotated and updated in Passwork")

Benefits:

• Fully automated rotation eliminates manual actions and human error
• New password immediately available to the entire team—no delays or communication gaps

Security: Zero knowledge and encryption

Passwork implements Zero knowledge architecture: the server never accesses secrets in plain text. Even administrators with full infrastructure access cannot read your data.

• Server-side encryption — All secrets stored encrypted on the server. Suitable for internal networks and standard security requirements.
• Client-side encryption (CSE) — Secrets encrypted on the client before transmission; only ciphertext reaches the server. Master key derived from user's master password. Essential for cloud deployments or strict compliance requirements.

Choosing your model:

• Cloud deployment or strict compliance → Enable CSE
• Internal network with standard requirements → Server-side encryption sufficient

Authorization and tokens

Passwork API uses a token pair: accessToken and refreshToken.

• Access token — Short-lived credential for API requests
• Refresh token — Enables automatic access token renewal without re-authorization

The Python connector handles token refresh automatically, ensuring stable integrations without manual intervention.

Security best practices:

• Create dedicated service accounts — Assign minimal permissions, grant access only to required vaults and folders
• Rotate tokens regularly — Set expiration policies and refresh credentials on schedule
• Secure token storage — Use environment variables or dedicated secret vaults (never hardcode)
• Enforce HTTPS — Always use encrypted connections for API communication

Conclusions

Passwork has evolved from a password manager into a comprehensive secrets management platform. The open API, Python connector, CLI, and Docker image enable seamless integration into any workflow while centralizing secrets with granular access control.

• For administrators: Reliable storage with built-in automation capabilities.
• For developers and DevOps: Production-ready API and tools for secure secrets handling.

Passwork consolidates what typically requires multiple solutions into a single system with unified management. This reduces operational overhead, simplifies rotation workflows, and provides IT and development teams with transparent security controls.

As a secrets management platform, Passwork delivers protected, scalable infrastructure that adapts to your organization's needs.

Further reading

Passwork 7.1: Vault types

Table of contents * What are vault types * Basic vault types * Advantages of vault types * Managing vault types * Migration from previous versions * Conclusion: Data control and efficiency Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a

Passwork BlogEirik Salmi

GDPR password security: Guide to effective staff training

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

HIPAA requirements for password management

Table of contents * Introduction * How HIPAA works * Cybersecurity and clinical efficiency * HIPAA and password management * How to train staff to meet HIPAA standards * How Passwork supports HIPAA compliance * Sustainable HIPAA compliance Introduction In the complex ecosystem of modern healthcare, patient data is essential for secure management. In 2024, the U.

Passwork BlogAna Moore