The NIS2 Directive (EU 2022/2555) is no longer a future concern. As of October 2024, organizations across 18 European sectors must demonstrate compliance with mandatory cybersecurity controls. Penalties reach €10 million or 2% of global annual turnover, and board members face personal liability for non-compliance.

At the core of NIS2 is Article 21, which mandates 10 specific security measures. Of these, access management (credential governance, role-based access control, multi-factor authentication, and audit logging) is the most auditable and the most directly linked to breach outcomes.

This guide maps those requirements to practical implementation steps and shows how to generate compliance evidence that regulators expect.

Key takeaways

• Stolen credentials appear in 39% of all breaches — not just at initial access, but as the primary mechanism for lateral movement, privilege escalation, and persistence.
• Third-party involvement has reached 48% in 2026, a 60% year-over-year increase that directly implicates supply chain access governance under NIS2 Article 21(2)(d).
• NIS2 Article 21 mandates 10 specific security measures, all mandatory for every covered entity. The most auditable and breach-critical measures are access control, MFA, and immutable audit logging — these produce exportable compliance evidence regulators expect.
• Access control is where NIS2 compliance becomes measurable. Unlike policy documents, credential governance produces verifiable evidence: audit logs, permission matrices, MFA enforcement reports. Regulators can confirm that controls are actively enforced.
• Article 23 introduces a 24-hour incident reporting obligation. Organizations without centralized credential management, immutable audit trails, and automated rotation capabilities cannot meet this deadline. Bulk password rotation must be executable within hours, not days.
• ENISA specifies three MFA tiers. Tier 1 (phishing-resistant FIDO2/WebAuthn) is mandatory for all privileged accounts. Tier 2 (TOTP) is acceptable for standard users. SMS and email OTPs are explicitly flagged for phase-out and do not meet the minimum threshold.
• Personal liability for board members is unprecedented. Article 20 holds C-suite executives personally accountable for cybersecurity failures, including temporary bans from management roles. This provision has no precedent in NIS1.
• Penalties reach €10 million or 2% of global annual turnover for Essential Entities, with enforcement active as of 2026. National competent authorities across the EU have begun proactive audits. Non-compliance is no longer a future concern.
• On-premise deployment eliminates third-party data custody. Credentials remain inside your network with no external transmission. Audit logs are stored locally and piped directly to your SIEM with no vendor intermediary, guaranteeing audit independence.
• The 5-phase implementation roadmap takes 30–60 days from assessment to audit-ready compliance: pre-deployment assessment, access audit, credential system deployment, NIS2 configuration, and ongoing monitoring. Most organizations can move from fragmented access management to enforcement within this timeline.

Why NIS2 focuses on access management

Access control is where NIS2 compliance becomes measurable. Unlike policy documents or risk assessments, credential governance produces exportable evidence: audit logs, permission matrices, MFA enforcement reports. Regulators can verify that controls are actively enforced.

The threat landscape makes this urgency clear. According to Verizon's 2026 Data Breach Investigations Report, vulnerability exploitation has become the leading initial access vector at 31% of breaches, up from 20% in 2025. However, this headline comparison obscures a more critical finding: stolen credentials appear in 39% of all breaches across the entire attack lifecycle — not just at initial access, but as the primary mechanism for lateral movement, privilege escalation, and persistence.

Once attackers gain entry, credentials become their dominant tool for moving through the infrastructure. Third-party involvement has reached 48% in 2026, up from 30% in 2025 — a 60% increase that directly implicates supply chain access governance under NIS2 Article 21(2)(d). ,

Stolen credentials drive breach expansion — reused, shared, or never revoked when employees leave. NIS2 Article 21 was designed to eliminate this through strict access control, mandatory MFA, and immutable audit logging.

Understanding NIS2 Article 21: The 10 mandatory security measures

NIS2 Article 21 requires "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. All 10 measures are mandatory for every covered entity. Here's what each one demands:

• Measure 1: Risk analysis and information system security policies. Organizations must continuously identify and document cybersecurity risks. This translates to credential discovery: mapping all privileged accounts, identifying shared credentials, and documenting which systems hold the highest-risk access.
• Measure 2: Incident handling — prevention, detection, and response. Organizations must have documented procedures for responding to security incidents. For credential-based breaches, this means the ability to rotate compromised passwords in bulk within hours, not days.
• Measure 3: Business continuity, backup management, and disaster recovery. Credentials must remain accessible even when primary systems fail. This requires failover clustering, replication, and tested backup procedures.
• Measure 4: Supply chain security. Organizations must assess and manage the cybersecurity risks posed by direct suppliers and service providers. For credentials, this means isolating third-party access, time-bounding it, and revoking it automatically when contracts end.
• Measure 5: Security in network and information systems acquisition, development, and maintenance. Systems must be built and maintained with security in mind. For credential systems, this means secure development practices and regular penetration testing.
• Measure 6: Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Organizations must verify that controls actually work. This requires audit trails: proof that access controls are enforced and that every credential action is logged.
• Measure 7: Basic cyber hygiene practices and cybersecurity training. Weak passwords are the most common credential failure. Organizations must enforce password complexity, rotation schedules, and user security awareness.
• Measure 8: Policies and procedures regarding the use of cryptography and encryption. Credentials must be encrypted at rest and in transit. This means AES-256 encryption, TLS for all communications, and zero-knowledge architecture where the server never holds decryption keys.
• Measure 9: Human resources security, access control policies, and asset management. This is the core of NIS2 access governance: every user must have documented access rights, every access change must be logged, and every credential must be revoked when access is no longer needed.
• Measure 10: Use of MFA or continuous authentication solutions. Multi-factor authentication is no longer optional. ENISA's technical guidance specifies three tiers of MFA strength, with phishing-resistant authentication (FIDO2/WebAuthn) mandatory for all privileged accounts.

Quick reference table

Passwork delivers direct compliance evidence across 9 of the 10 NIS2 measures. Access logs and immutable audit trails satisfy measures 1, 2, and 6. Encrypted storage covers measure 8. RBAC, MFA enforcement, and asset-level access control close out measures 9 and 10 — where regulators demand technical proof. Get a free demo and see it in action

The 24-hour incident reporting obligation

NIS2 Article 23 introduces a three-stage reporting timeline that fundamentally changes how organizations respond to credential breaches.

• Early Warning (24 hours). Within 24 hours of discovering a significant incident, organizations must notify the national CSIRT. No full assessment required — just confirmation that an incident occurred and whether criminal activity is suspected.
• Incident Notification (72 hours). Provide an initial assessment: severity, impact, indicators of compromise (IoCs), and affected systems. This is where credential breach scope becomes critical. If admin credentials were compromised, the scope is potentially enterprise-wide.
• Final Report (1 month). Full root cause analysis, remediation steps taken, cross-border impact assessment, and lessons learned. This is the document regulators will scrutinize. For credential breaches, it must include proof that all compromised passwords were rotated and that access was revoked for any accounts that should no longer have had access.

Organizations without centralized credential management, immutable audit trails, and automated rotation capabilities cannot meet the 24-hour deadline.

ENISA Technical Guidance: MFA, PAM, and audit logging

The European Union Agency for Cybersecurity (ENISA) published detailed technical implementation guidance for NIS2. For access management, three areas dominate: MFA strength, privileged access management (PAM), and audit logging.

MFA: Three tiers of strength

ENISA classifies MFA into three tiers based on phishing resistance:

1. Strong (Phishing-Resistant). FIDO2, WebAuthn, and hardware security keys. These cannot be intercepted by phishing attacks because they use cryptographic challenge-response protocols. ENISA mandates Tier 1 for all privileged and administrative accounts. No exceptions.
2. Medium. TOTP authenticator apps and push notifications. Acceptable for standard user accounts. Vulnerable to real-time phishing but significantly better than passwords alone.
3. Last Resort (Phase Out). SMS and email one-time passwords. Vulnerable to SIM-swap attacks and interception. ENISA explicitly recommends phasing these out for all regulated environments.

Organizations must document which MFA tier is enforced for each user group. Auditors will verify that all privileged accounts use Tier 1 and that SMS/email OTPs are no longer in use.

Privileged Access Management (PAM)

ENISA specifies four PAM requirements:

1. Separation of duties. Admin accounts must never be used for general tasks like email or browsing. Separate, dedicated accounts required for all privileged operations.
2. Full audit logging. Every privileged action must be logged with user identity, timestamp, source IP, and action taken. Logs must be immutable and tamper-evident.
3. Just-In-Time (JIT) access. Privileges granted on a per-event basis and automatically revoked after use. No standing admin access.
4. Third-party access governance. Vendor access must be scoped, time-limited, and automatically revoked upon contract end or project completion.

Audit logging (ENISA §11.4)

Logs must be:

• Centralized. All credential actions logged to a single, protected system.
• Immutable. No user, including administrators, can modify or delete log entries.
• Exportable. Structured formats (JSON, CSV, Syslog) for SIEM integration and regulatory submission.
• Retained. Minimum retention period defined by the entity's risk assessment (typically 1–3 years).

Incomplete or tamper-able logs will not satisfy ENISA §11.4. Regulators will reject them.

Mapping NIS2 requirements to technical controls

Here's how specific technical controls satisfy Article 21 obligations:

Every control in the table above is built into Passwork's core architecture. You get password security dashboards, immutable audit trails, RBAC, MFA enforcement, and AES-256 encryption out of the box. The result: compliance evidence that regulators expect, not policy documents they have to interpret.

The 5-phase implementation roadmap: From assessment to audit-ready compliance

Moving from fragmented access management to audit-ready NIS2 compliance doesn't require a complete infrastructure rebuild. A structured 5-phase approach takes most organizations from assessment to enforcement within 30–60 days.

Phase 1: Pre-deployment assessment (week 1)

1. Define NIS2 scope boundaries. Which business units, systems, and user groups fall under the directive? Classify your organization as Essential or Important entity and confirm applicable obligations.
2. Assign accountability. Designate a compliance owner with Article 20 accountability — typically the CISO or IT Director. Align IT, security, HR, and legal teams on roles, responsibilities, and escalation paths.
3. Confirm infrastructure readiness. Verify server specifications and network topology for on-premise deployment. Confirm Active Directory or LDAP readiness for automated user provisioning.

Phase 2: Access audit — where you stand today (week 2)

1. Map all privileged accounts. Identify every account with admin access across all systems and infrastructure. Include service accounts and shared credentials — these are your highest-risk credentials.
2. Identify third-party access. Review all active third-party and vendor access. Document scope, duration, and current MFA status. This is where most organizations discover uncontrolled access.
3. Assess current logging. What is being logged today, where, and for how long? Document the gap between current state and ENISA's technical requirements.

Phase 3: Deploying Passwork in your environment (week 3)

1. Install on-premise. Deploy via Docker Compose or bare-metal server (Linux/Windows). Passwork runs entirely within your infrastructure with no external credential transmission.
2. Integrate with identity systems. Connect to Active Directory or LDAP for automated user provisioning. Configure SSO via SAML 2.0 for seamless, auditable authentication.
3. Import and organize credentials. Migrate existing credentials into structured vaults by team, system, and criticality. Define initial vault structure and ownership hierarchy.

Phase 4: Configuring for NIS2 compliance (week 4)

1. Define and enforce RBAC. Apply the least-privilege principle throughout. Every user accesses only the credentials their role requires.
2. Mandate MFA. Enforce Tier 1 (FIDO2) for all privileged accounts. Enforce Tier 2 (TOTP) for all standard users. Document enforcement as audit evidence.
3. Isolate third-party access. Create dedicated, time-bound vaults for vendors and contractors with automatic expiry at contract end.
4. Configure password policies. Enforce complexity rules, rotation schedules, and automatic expiry. Enable full audit trail logging and configure SIEM integration via Syslog.

Phase 5: Ongoing monitoring and reporting (ongoing)

1. Schedule quarterly access reviews. Validate that RBAC assignments remain accurate. Ensure no orphaned access remains after employee departures.
2. Generate automated compliance reports. Demonstrate MFA enforcement, access governance, and control effectiveness. Have exportable evidence packages ready for regulatory submission on demand.
3. Monitor audit logs. Integrate alerts with SIEM for anomalous access patterns. Conduct annual NIS2 readiness assessments against updated ENISA guidance.

The NIS2 compliance checklist

Use this checklist to track your compliance posture across the three critical areas: access management, supply chain security, and incident readiness.

Access control (Article 21(2)(i))

• Map all privileged accounts across all systems and infrastructure
• Implement strict RBAC — every user accesses only credentials their role requires
• Eliminate all shared accounts — replace with individualized access
• Automate identity lifecycle via AD/LDAP — immediate access revocation upon employee exit
• Export permission matrices as auditor-ready evidence

Supply chain (Article 21(2)(d))

• Isolate all third-party access in dedicated, time-bound vaults
• Audit all active vendor credentials — revoke any access no longer operationally justified
• Document vendor access scope, duration, and MFA status for every active third-party credential
• Configure automatic expiry at contract end

MFA (Article 21(2)(j))

• Enforce Tier 1 MFA (FIDO2/WebAuthn) for all administrative accounts
• Enforce Tier 2 MFA (TOTP) for all standard users
• Phase out SMS and email OTPs — both fail ENISA's minimum threshold
• Generate compliance report confirming MFA across all active accounts

Incident readiness (Article 23)

• Verify audit logs provide sufficient detail for 24-hour early warning
• Establish and test bulk credential rotation workflow for post-incident response
• Designate named individual responsible for Article 23 notification
• Prepare exportable evidence packages ready for regulatory submission on demand

Audit logging (ENISA §11.4)

• Centralize and protect audit logs — configure immutable, exportable logging
• Integrate with SIEM via Syslog — ensure no user can modify or delete log entries
• Confirm every entry captures identity, timestamp, action, and source IP
• Generate automated reports covering MFA enforcement, RBAC compliance, and access reviews

Penalties: What non-compliance actually costs

The financial and personal consequences of NIS2 non-compliance are severe:

• For Essential Entities: Up to €10 million or 2% of global annual turnover, whichever is higher. Regulators may also impose temporary operational restrictions.
• For Important Entities: Up to €7 million or 1.4% of global annual turnover, whichever is higher. Reactive supervision does not mean lower risk.
• Personal liability for management (Article 20). Board members and C-suite executives can be held personally liable for cybersecurity failures. Competent authorities may impose temporary bans from management roles. This provision has no precedent in NIS1, and it fundamentally changes how leadership must approach compliance.

As of 2026, national competent authorities across the EU have begun proactive audits of Essential Entities. The enforcement phase is active.

Building your NIS2 evidence package

Regulators want proof. Your compliance evidence package must include:

1. RBAC configuration export. Permission matrices showing which users/roles have access to which credentials.
2. MFA enforcement report. System configuration confirming MFA is globally enforced, with MFA method per user.
3. Audit log samples. Representative logs showing identity, timestamp, action, and source IP for credential access and modifications.
4. Third-party access inventory. Documented scope, duration, and MFA status for every active vendor credential.
5. Password policy documentation. Enforced complexity rules, rotation schedules, and automatic expiry settings.
6. Incident response capability. Proof that bulk credential rotation can be executed within hours.
7. Backup and failover records. Evidence that credentials remain accessible during system failures.

The On-Premise advantage for NIS2 compliance

Organizations often ask: why does NIS2 emphasize on-premise deployment? The answer is data sovereignty and audit independence.

1. Data stays where you govern it. All credentials remain inside your network with no external transmission, no third-party custody, and no jurisdictional ambiguity.
2. Audit logs you own and control. Logs are stored locally, pipe directly to your SIEM via Syslog with no vendor intermediary, no restrictions, and no data leaving your perimeter.
3. No third-party data dependency. Because the credential system runs within your infrastructure, it holds no custody over your credentials, eliminating the third-party data dependency that triggers supply chain assessment requirements under Article 21(2)(d).
4. Compliance evidence on your terms. Every report, log, and configuration export is generated from your own infrastructure and available on demand for auditors, without dependency on a vendor's support team or data retention policy.
5. Isolated environments supported. Air-gapped deployment for OT/ICS infrastructures with zero network exposure. Credentials remain accessible even where internet connectivity is prohibited by design.

Conclusion: From compliance to competitive advantage

NIS2 is a mandate to secure the infrastructure that European society depends on. Credential-based attack vectors dominate the 2026 threat landscape — and they are precisely what Article 21 was designed to address.

Organizations that centralize credential governance, enforce phishing-resistant MFA, and maintain immutable audit trails do more than pass the audit. They eliminate their most significant attack surface. The 5-phase implementation roadmap in this guide takes you from fragmented access management to audit-ready compliance within 30–60 days.

The technical foundation for that outcome requires three elements: on-premise deployment that guarantees data sovereignty, RBAC that enforces least privilege at scale, and audit logs that give regulators exactly the evidence they need.

Passwork delivers all 9 technical controls in this table: password security dashboards, bulk rotation, failover clustering, on-premise deployment, immutable audit trails, policy enforcement, AES-256 encryption, RBAC, and MFA. Get a free demo and see it in action.

Ready to move from compliance planning to implementation? Download the full NIS2 compliance guide for detailed technical mapping, sector-specific guidance, and a customizable compliance checklist.

Frequently asked questions

What does NIS2 Article 21 actually require from my organization?

Article 21 mandates 10 specific security measures: risk analysis, incident handling, business continuity, supply chain security, secure development, control effectiveness verification, cyber hygiene, encryption, access control, and MFA. All 10 are mandatory for every covered entity. The most auditable and breach-critical measures are access control (Article 21(2)(i)), MFA (Article 21(2)(j)), and audit logging (Article 21(2)(f)).

Who is required to comply with NIS2?

Organizations in 18 European sectors classified as Essential Entities must comply immediately. These include energy, transport, water, health, digital infrastructure, and public administration. Important Entities (financial services, food supply, manufacturing, chemicals, space) have until October 2025 for full compliance. Non-EU organizations operating in these sectors within EU jurisdiction are also in scope.

What are the penalties for non-compliance?

Essential Entities face fines up to €10 million or 2% of global annual turnover, whichever is higher. Important Entities face up to €7 million or 1.4% of global annual turnover. Board members and C-suite executives face personal liability under Article 20, including temporary bans from management roles. Enforcement is active as of 2026.

How long does it take to implement NIS2 compliance for access management?

Most organizations move from assessment to audit-ready compliance within 30–60 days using a structured 5-phase approach: pre-deployment assessment (week 1), access audit (week 2), credential system deployment (week 3), NIS2 configuration (week 4), and ongoing monitoring. The timeline depends on infrastructure complexity and the volume of existing credentials to migrate.

What is the difference between Essential and Important Entities under NIS2?

Essential Entities operate critical infrastructure (energy, transport, water, health, digital infrastructure, public administration). Important Entities provide essential services (financial services, food supply, manufacturing, chemicals, space). Essential Entities face higher penalties (€10 million vs. €7 million) and stricter enforcement timelines. Both must implement all 10 Article 21 measures.

Why does NIS2 emphasize on-premise credential management?

On-premise deployment guarantees data sovereignty: credentials remain inside your network with no external transmission or third-party custody. Audit logs are stored locally and piped directly to your SIEM with no vendor intermediary. This eliminates the third-party data dependency that triggers supply chain assessment requirements under Article 21(2)(d) and gives you complete audit independence.

What MFA tier does NIS2 require?

ENISA specifies three tiers: Tier 1 (phishing-resistant) — FIDO2, WebAuthn, hardware security keys — is mandatory for all privileged and administrative accounts. Tier 2 (TOTP authenticator apps, push notifications) is acceptable for standard users. SMS and email OTPs are explicitly flagged for phase-out and do not meet ENISA's minimum threshold.

How do I prove NIS2 compliance to regulators?

Your evidence package must include: RBAC configuration exports showing permission matrices, MFA enforcement reports confirming global enforcement, representative audit logs with identity/timestamp/action/source IP, third-party access inventory with scope and duration, password policy documentation, proof of bulk credential rotation capability, and backup/failover records. All evidence must be exportable and auditor-ready on demand.

What is the Article 23 reporting timeline?

Article 23 introduces three stages: Early Warning (24 hours) — notify the national CSIRT that an incident occurred. Incident Notification (72 hours) — provide initial assessment including severity, impact, and affected systems. Final Report (1 month) — full root cause analysis, remediation steps, and lessons learned. Organizations without centralized credential management and automated rotation cannot meet the 24-hour deadline.

Password and access management for SMBs: Is KeePass enough?

Using KeePass for your team? Discover the hidden risks of KeePass for SMBs in 2026 — sync failures, compliance gaps, and when to switch to a corporate password manager.

Passwork BlogAlex Muntyan

Is NIS2 passwordless authentication required for compliance?

NIS2 Article 21(2)(j) mandates MFA “where appropriate” — not passwordless by default. Learn what ENISA guidance actually requires, how auditors evaluate your implementation, and how to build a defensible hybrid compliance posture for 2026.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

Jeder IT-Admin, der KeePass für ein Team betreibt, erzählt dieselbe Geschichte. Es beginnt mit einer gemeinsamen .kdbx-Datei auf einem Netzlaufwerk. Dann kann jemand sie nicht öffnen, weil ein Kollege sie gesperrt hat. Dann überschreibt ein Junior-Sysadmin eine Änderung, die jemand anderes eine Stunde zuvor gemacht hat. Dann verlässt ein Mitarbeiter das Unternehmen, und niemand weiß genau, auf welche Passwörter er Zugriff hatte.

KeePass ist ein wirklich hervorragendes Werkzeug — für eine Person. Sobald es von einem Team genutzt wird, verwaltet man keine Passwörter mehr. Man verwaltet eine einzelne Datei.

Wichtige Erkenntnisse

KeePass ist hervorragend für Einzelpersonen, aber strukturell ungeeignet für Teams. Sobald ein zweiter Benutzer hinzukommt, gehen Echtzeit-Synchronisation, granulare Zugriffssteuerung und Audit-Trails verloren — die drei Dinge, die Credential-Breaches und Compliance-Verstöße verhindern.

• Multi-User-Synchronisation ist manuell und fehleranfällig. Gleichzeitige Bearbeitungen an einer gemeinsamen .kdbx-Datei führen zu Datenverlust. Das „Last-Writer-Wins"-Problem skaliert linear mit der Teamgröße. Es gibt keinen Merge, keine Konflikterkennung und keine Warnung.
• Die Zugriffssteuerung ist binär. Jeder, der das Masterpasswort benötigt, erhält vollen Zugriff auf alle Zugangsdaten. Es gibt kein Konzept für „dieser Benutzer kann Cloud-Zugangsdaten lesen, aber keine Datenbankpasswörter". Beim Offboarding müssen alle Zugangsdaten rotiert werden, die die Person möglicherweise gesehen hat.
• KeePass erzeugt keine Audit-Logs. Es lässt sich nicht nachweisen, wer wann und von wo auf bestimmte Zugangsdaten zugegriffen hat. Dies verstößt gegen SOC 2 CC6.1, GDPR Artikel 32, NIS2, ISO 27001 und PCI DSS 4.0 — jedes moderne Compliance-Framework.
• Die operativen Kosten summieren sich schnell. Sync-Konflikte, manuelles Offboarding, Credential-Rotation und Audit-Lücken erzeugen einen administrativen Overhead, der mit der Teamgröße wächst.
• Die Lösung ist ein zweckgebauter Tresor mit RBAC, AD-Integration und automatisierten Audit-Trails. Keine größere Tabelle, kein besseres Filesharing-Tool — ein Credential-Manager, der für Teams unter Compliance-Anforderungen entwickelt wurde.

Die Attraktivität von KeePass für kleine Unternehmen

KeePass ist aus drei völlig rationalen Gründen für KMU attraktiv: Es kostet nichts, speichert Daten lokal und wurde von der Open-Source-Community seit über zwei Jahrzehnten auditiert. Für ein Fünf-Personen-Unternehmen ohne Compliance-Verpflichtungen und mit einem einzelnen IT-Generalisten sind das echte Vorteile.

Die Verschlüsselung ist solide. KeePass 2.x verwendet standardmäßig AES-256, mit optionaler ChaCha20-Unterstützung — letztere ist schneller auf mobiler Hardware, wo keine AES-Hardwarebeschleunigung verfügbar ist. Das .kdbx-Format ist gut dokumentiert, portabel und wird nicht verschwinden.

KeePass bleibt ein bedeutender Teil der Consumer-Adoption-Kurve, besonders unter technisch versierten Nutzern, die Cloud-Diensten misstrauen. Das Enterprise-Segment (wo Compliance-Audits, Multi-Team-Zugriff und Audit-Logging obligatorisch sind) ist jedoch fast vollständig auf zweckgebaute Lösungen umgestiegen.

Die „KeePass-Skalierungsfalle": Wenn kostenlos teuer wird

KeePass wurde als Single-User-Anwendung konzipiert. Die Multi-User-Dokumentation räumt dies direkt ein — die offizielle KeePass-Hilfeseite für mehrere Benutzer beschreibt Workarounds, keine nativen Funktionen. Wenn Sie eine .kdbx-Datei auf ein Netzlaufwerk legen und fünf Personen Zugriff geben, haben Sie ein System gebaut, das irgendwann versagen wird. Hier ist genau, wie.

Das Last-Writer-Wins-Problem

KeePass hat keine Echtzeit-Sync-Engine. Wenn zwei Benutzer dieselbe Datenbankdatei gleichzeitig öffnen, hält jeder eine lokale Kopie im Speicher. Wenn Benutzer A speichert, wird die Datei aktualisiert. Wenn Benutzer B dreißig Sekunden später speichert, überschreibt seine Version die Änderungen von Benutzer A vollständig. Es gibt keinen Merge, keine Konflikterkennung und keine Warnung.

KeePass bietet zwar eine manuelle „Synchronisieren"-Funktion, die zwei .kdbx-Dateien zusammenführen kann — aber sie erfordert eine bewusste Aktion des Benutzers und funktioniert nur, wenn beide Versionen verfügbar sind. Auf einem Netzlaufwerk, wo die Datei beim Speichern überschrieben wird, ist diese zweite Version bereits verschwunden.

Alles-oder-Nichts-Zugriff

KeePass hat ein Masterpasswort (oder eine Schlüsseldatei) pro Datenbank. Jeder, der Zugriff benötigt, erhält denselben Schlüssel. Es gibt kein Konzept für „dieser Benutzer kann die Cloud-Server-Zugangsdaten lesen, aber nicht die Datenbankpasswörter". Sie können separate .kdbx-Dateien für verschiedene Zugriffsebenen erstellen, aber dann verwalten Sie mehrere Dateien und mehrere Sync-Prozesse — und Sie haben immer noch keinen Audit-Trail.

RBAC (rollenbasierte Zugriffssteuerung) — die Möglichkeit zu definieren, was jeder Benutzer oder jede Gruppe sehen und tun kann — existiert in der Architektur von KeePass schlicht nicht. Es ist eine Designentscheidung für ein Single-User-Tool.

Das Offboarding

Wenn ein Mitarbeiter mit Zugriff auf die gemeinsame KeePass-Datenbank Ihre Organisation verlässt, ist die korrekte Sicherheitsreaktion, alle Zugangsdaten zu rotieren, die er möglicherweise gesehen hat. Alle. Da Sie kein Log darüber haben, worauf er zugegriffen hat, können Sie die Rotation nicht eingrenzen — Sie müssen vom Worst-Case ausgehen.

Bei einer Datenbank mit 200 Einträgen ist das ein voller Arbeitstag. Bei einer Datenbank mit 800 Einträgen über Produktionssysteme, SaaS-Tools und Kundenumgebungen hinweg ist es ein mehrtägiger Incident. Und das passiert jedes Mal, wenn jemand geht.

Die rollenbasierten Tresore von Passwork ermöglichen es, den Zugriff für einen ausscheidenden Mitarbeiter mit einer einzigen Aktion zu widerrufen. Erfahren Sie, wie es funktioniert

Sicherheit vs. Compliance: Die regulatorische Landschaft 2026

Die Verschlüsselung von KeePass ist wirklich stark. AES-256 mit einem gut gewählten Masterpasswort ist nicht der Schwachpunkt. Der Schwachpunkt ist, dass KeePass keine Nachweise darüber produziert, was innerhalb der Datenbank passiert ist — und 2026 sind diese Nachweise das, wonach Auditoren fragen.

Was GDPR Artikel 32 verlangt

GDPR Artikel 32 schreibt „geeignete technische und organisatorische Maßnahmen" vor, um ein dem Risiko angemessenes Sicherheitsniveau zu gewährleisten. Für das Credential-Management umfasst die Arbeitsinterpretation von Artikel 32 Verschlüsselung im Ruhezustand, Zugriffskontrollen und — entscheidend — die Fähigkeit nachzuweisen, dass die Zugriffskontrollen funktionieren. Dieser letzte Teil erfordert Logs.

Eine KeePass-Datenbank kann nicht sagen, wer sie geöffnet hat, wann, von welchem Rechner oder was angesehen wurde. Wenn ein Regulator Sie auffordert nachzuweisen, dass der Zugriff auf personenbezogene Zugangsdaten angemessen eingeschränkt war, ist eine .kdbx-Datei keine Antwort.

NIS2-Richtlinie: Zugriffssteuerung und Incident Response

Die NIS2-Richtlinie (seit Oktober 2024 für EU-Organisationen gültig) schreibt vor, dass Betreiber wesentlicher Dienste und wichtige Einrichtungen „erweiterte Zugriffssteuerung" implementieren und detaillierte Logs über den Zugriff auf kritische Assets führen müssen. Für das Credential-Management bedeutet das:

• Rollenbasierte Zugriffssteuerung (RBAC) mit Authentifizierung pro Benutzer
• Unveränderliche Audit-Logs aller Credential-Zugriffe
• Die Fähigkeit, den Zugriff beim Ausscheiden eines Mitarbeiters sofort zu widerrufen

Eine gemeinsam genutzte KeePass-Datei mit einem einzigen Masterpasswort verletzt alle drei Anforderungen. Das Neuschlüsseln der gesamten Datenbank, wenn jemand geht, ist kein „sofortiger Widerruf" — es ist ein Workaround, der administrativen Overhead erzeugt und das Risiko menschlicher Fehler erhöht.

ISO 27001:2022 und Anforderungen an die Zugriffssteuerung

ISO 27001 Anhang A.8.2 (Zugriffssteuerung) und A.8.15 (Protokollierung) verlangen von Organisationen, Kontrollen zu implementieren, die den Zugang zu Informationen auf autorisierte Benutzer beschränken und Aufzeichnungen über den Zugriff führen. Für Credential-Repositories bedeutet das:

• Granulare Zugriffsberechtigungen, die an Jobrollen gebunden sind
• Audit-Trails, die zeigen, wer wann und von wo auf was zugegriffen hat
• Automatisierte Durchsetzung des Prinzips der geringsten Berechtigung

KeePass bietet nichts davon. Eine Datenbank, die von Teammitgliedern mit einem einzigen Passwort geteilt wird, ist das Gegenteil von geringster Berechtigung — es ist maximale Berechtigung für alle.

PCI DSS 4.0: Schutz von Zahlungskartendaten

Wenn Ihre Organisation Zahlungskartendaten verarbeitet, schreibt PCI DSS 4.0 Anforderung 7.1 vor, dass der Zugriff auf Karteninhaberdaten auf Personal mit legitimem geschäftlichem Bedarf beschränkt werden muss. Anforderung 10.2.1 erfordert die Protokollierung aller Zugriffe auf Systeme, die Karteninhaberdaten enthalten, einschließlich Benutzer-ID, Datum, Uhrzeit und Art des Zugriffs.

Eine KeePass-Datenbank, die Payment-Gateway-API-Schlüssel oder Datenbankzugangsdaten speichert, kann diese Anforderungen nicht erfüllen. Es gibt keine Authentifizierung pro Benutzer, keinen Audit-Trail und keine Möglichkeit, einem PCI-Auditor nachzuweisen, dass der Zugriff auf autorisiertes Personal beschränkt war.

SOC 2 Type II und CC6.1

SOC 2 Trust Services Criteria CC6.1 verlangt, dass der logische Zugang zu Systemen, die sensible Daten speichern, auf autorisierte Benutzer beschränkt und der Zugriff protokolliert wird. Eine gemeinsam genutzte KeePass-Datenbank mit einem einzigen Masterpasswort erfüllt beide Bedingungen nicht. Es gibt keine Authentifizierung pro Benutzer und kein Log.

Dies ist kein theoretisches Risiko. Auditoren fragen bei SOC 2 Type II-Bewertungen nach Zugriffs-Logs. „Wir verwenden KeePass" beendet dieses Gespräch ungünstig.

NIST SP 800-63B (Revision 4)

NIST SP 800-63B, finalisiert im August 2025, empfiehlt eine Mindestpasswortlänge von 15 Zeichen für gemerkte Geheimnisse und rät ausdrücklich von obligatorischer periodischer Rotation ab, zugunsten einer durch Breaches ausgelösten Rotation. KeePass kann konforme Passwörter speichern — aber es kann die Richtlinie nicht durchsetzen, keine Compliance-Berichte erstellen und einem Auditor nicht nachweisen, dass die Richtlinie befolgt wurde.

Das Ausmaß der Bedrohung

Die Zahlen machen das Compliance-Argument konkret. Laut dem IBM 2025 Cost of a Data Breach Report erreichten die durchschnittlichen Breach-Kosten für Unternehmen mit weniger als 500 Mitarbeitern 3,31 Millionen Dollar. Credential-Kompromittierung gehört konstant zu den häufigsten initialen Angriffsvektoren. Ein Compliance-Verstoß zusätzlich zu einem Breach verstärkt den finanziellen Schaden durch regulatorische Bußgelder und Sanierungskosten.

Die Reifekurve der Passwortsicherheit für KMU

Die meisten KMU durchlaufen drei erkennbare Stufen. Diese Progression zu benennen hilft Teams zu identifizieren, wo sie stehen und wie der nächste Schritt tatsächlich aussieht.

• Stufe 1 — Excel/gemeinsames Dokument. Zugangsdaten in einer Tabelle, oft auf einem gemeinsamen Laufwerk oder in E-Mail-Threads. Keine Verschlüsselung. Keine Zugriffssteuerung. Vollständig auditierbar auf die denkbar schlechteste Art: Jeder mit der Datei kann alles sehen.
• Stufe 2 — KeePass. Verschlüsselte Datei, starke Kryptographie, keine Kosten. Eine echte Verbesserung gegenüber Stufe 1. Geeignet für Einzelpersonen und sehr kleine Teams ohne Compliance-Anforderungen. Bricht bei mehr als fünf Benutzern zusammen, bei Audits oder wenn jemand geht.
• Stufe 3 — Unternehmens-Tresor. Zweckgebautes Multi-User-Credential-Management mit RBAC, AD/LDAP-Integration, Audit-Logs pro Benutzer, MFA-Durchsetzung und automatisiertem Offboarding. Hier müssen Teams mit Compliance-Verpflichtungen, mehr als zehn Benutzern oder jeglichen kundenorientierten Sicherheitsanforderungen sein.

Die Falle ist, bei Stufe 2 zu bleiben, nachdem sie nicht mehr passt. Die Kosten dieser Verzögerung sind der administrative Overhead, das Incident-Risiko und die Audit-Findings.

Der 5-Punkte-KeePass-Stresstest für Ihr Unternehmen

Gehen Sie diese fünf Fragen mit Ihrem aktuellen Setup durch. Jedes „Ja" ist ein Signal, dass KeePass Risiken erzeugt, die Ihr Team möglicherweise nicht eingepreist hat.

1. Haben Sie mehr als 5 Benutzer, die auf die gemeinsame Datenbank zugreifen?
   Über fünf gleichzeitige Benutzer werden Sync-Konflikte zu einem fast täglichen Ereignis. Das „Last-Writer-Wins"-Problem skaliert linear mit der Teamgröße.
2. Können Sie nachweisen, wer wann auf bestimmte Zugangsdaten zugegriffen hat?
   Wenn ein Kunde fragt, welcher Ihrer Mitarbeiter letzten Dienstag auf seine Systemzugangsdaten zugegriffen hat, können Sie antworten? KeePass kann diese Aufzeichnung nicht erstellen. Ein Unternehmens-Tresor mit Audit-Logging kann es.
3. Wird die Datenbank auf einem gemeinsamen Laufwerk, Dropbox oder ähnlichem gespeichert?
   Cloud-Sync-Tools wie Dropbox fügen ihre eigene Konfliktlösung zusätzlich zu der von KeePass hinzu — was bedeutet, dass Sie mit mehreren .kdbx-Versionen enden können, ohne zuverlässig zu wissen, welche aktuell ist. Netzlaufwerke haben das oben beschriebene Dateisperrproblem.
4. Wie lange dauert es, den Zugriff für einen ehemaligen Mitarbeiter vollständig zu widerrufen?
   Wenn die Antwort lautet „wir ändern das Masterpasswort und rotieren dann alles, was er möglicherweise gesehen hat", beschreiben Sie einen mehrstündigen Incident, der jedes Mal passiert, wenn jemand geht. Mit Zugriffssteuerung pro Benutzer ist der Widerruf eine einzige Aktion.
5. Schützt MFA den Tresor selbst?
   KeePass unterstützt Schlüsseldateien als zweiten Faktor, aber die Verteilung und Verwaltung dieser Schlüsseldateien über ein Team hinweg ist ein eigenes operatives Problem. Native MFA-Integration — TOTP, Hardware-Keys, SSO — erfordert ein zweckgebautes Tool.

Wenn Sie die Fragen 2 und 5 mit „Nein" beantwortet haben oder die Fragen 1, 3 und 4 mit „Ja", ist Ihr Team über KeePass hinausgewachsen.

Wie verwalten Sie den Credential-Zugriff, wenn Ihr Team über fünf Personen hinaus skaliert? Passwork übernimmt das Multi-Team-Credential-Management mit RBAC, Audit-Logging und Echtzeit-Sync — ohne den operativen Overhead. Passwork kostenlos testen

Über KeePass hinaus: Auswahl einer Unternehmens-Zugriffsverwaltungslösung

Die Kriterien für einen teamtauglichen Credential-Manager sind nicht kompliziert, aber sie sind nicht verhandelbar, sobald Sie in irgendeinem Umfang oder unter irgendeinem Compliance-Framework operieren.

Gemeinsam genutzte Tresore mit granularen Berechtigungen

Jedes Team oder Projekt sollte seinen eigenen Tresor haben. Einzelne Benutzer erhalten Zugriff auf die Tresore, die sie benötigen, auf der Berechtigungsebene, die sie benötigen (Lesen, Schreiben, Admin). Wenn sich die Rolle einer Person ändert, aktualisieren Sie ihre Tresor-Mitgliedschaft — nicht das Masterpasswort. Das ist rollenbasierte Zugriffssteuerung (RBAC), und sie ist die Grundlage der Compliance. KeePass hat kein Äquivalent.

Passwork weist Gruppen Berechtigungen zu, sodass ein Entwickler, der dem DevOps-Team beitritt, automatisch den Tresor-Zugriff des Teams erbt. Wenn er geht, widerrufen Sie ihn einmal.

RBAC mit Ihrem Verzeichnis verknüpft

AD/LDAP-Integration bedeutet, dass Benutzer-Provisioning und -Deprovisioning automatisch erfolgen. Wenn der Admin ein Konto in Active Directory terminiert, geht der Tresor-Zugriff damit. Kein manueller Schritt, keine Lücke. Passwork integriert nativ mit Active Directory und LDAP, sodass Ihr Credential-Zugriff Ihrer Organisationsstruktur folgt — nicht umgekehrt.

Audit-Logs pro Benutzer

Jede Credential-Ansicht, -Kopie, -Bearbeitung und -Freigabe sollte mit Zeitstempel und Benutzeridentität protokolliert werden. Dies ist die Aufzeichnung, die SOC 2 CC6.1 erfüllt und die GDPR Artikel 32-Rechenschaftspflicht unterstützt. KeePass produziert keine Logs.

Passwork führt einen vollständigen Audit-Trail jeder Aktion, exportierbar für Compliance-Überprüfungen und Incident-Untersuchungen.

MFA-Durchsetzung auf Tresor-Ebene

Nicht optional, keine Benutzer-Präferenz — durch Richtlinie durchgesetzt, mit Unterstützung für TOTP, Hardware-Token und SAML SSO. KeePass unterstützt Schlüsseldateien, was keine MFA ist. Passwork erzwingt MFA auf Tresor-Ebene, mit Unterstützung für mehrere Authentifizierungsmethoden, die an Ihren Identity-Provider gebunden sind.

Autofill und Browser-Integration

Ein moderner Credential-Manager integriert sich mit Browsern und CLI-Tools, um Passwörter automatisch auszufüllen und Secrets in Deployment-Pipelines einzuspeisen. KeePass hat Browser-Plugins, aber sie werden von der Community gepflegt und haben nicht das Sicherheitsmodell eines zentralisierten Tresors. Passwork bietet native Browser-Erweiterungen und CLI-Tools, die Zugangsdaten on-demand aus Ihrem Tresor abrufen, mit vollständigem Audit-Logging jeder Autofill-Aktion.

Zero-Knowledge-Architektur

Ihre Credential-Daten sollten clientseitig verschlüsselt werden, bevor sie jemals den Server erreichen. Das bedeutet, der Server (ob selbstgehostet oder Cloud) kann Ihre Zugangsdaten nicht entschlüsseln. Es ist eine Garantie, kein Versprechen. KeePass verschlüsselt lokal, bietet aber keine Team-Zusammenarbeit ohne manuelles Filesharing. Passwork verwendet clientseitige AES-256-Verschlüsselung mit Zero-Knowledge-Architektur: Zugangsdaten werden vor der Übertragung verschlüsselt, verschlüsselt auf dem Server gespeichert und nur auf autorisierten Clients entschlüsselt.

Selbstgehostet oder Cloud, Ihre Wahl

Einige KMU haben regulatorische oder vertragliche Gründe, Credential-Daten on-premises zu halten. Ein Tool, das echtes Self-Hosting bietet, gibt Ihnen die Kontrolle, die KeePass bietet, ohne die operativen Einschränkungen. Passwork ist als Cloud-Passwort- und Secrets-Manager und als selbstgehostete Deployment auf Ihrer eigenen Infrastruktur verfügbar, mit vollständiger AES-256-Verschlüsselung und Zero-Knowledge-Architektur. Ihre Daten verlassen nie Ihre Kontrolle.

KeePass vs. Passwork: Funktionsvergleich

Der Unterschied ist architektonisch. Wenn Ihr Team über fünf Personen hinauswächst, wird die operative Reibung von KeePass real. Credential-Rotation erfordert das Neuschlüsseln der gesamten Datenbank. Offboarding bedeutet, dass alle ihr Masterpasswort ändern. Die Zugriffssteuerung ist binär — entweder hat jemand das Masterpasswort oder nicht. Passwork eliminiert diese Reibung: granulare Berechtigungen, automatisiertes Offboarding, Audit-Trails pro Benutzer und Echtzeit-Sync ohne Konflikte.

Wenn Ihre Organisation unter Compliance-Anforderungen operiert (GDPR, SOC 2, NIS2, ISO 27001, PCI DSS), wird die Lücke noch größer. Eine gemeinsam genutzte KeePass-Datenbank besteht kein Audit. Passwork mit RBAC, Audit-Logging, AD-Integration und Zero-Knowledge-Verschlüsselung erfüllt Compliance-Anforderungen ohne administrativen Overhead.

Fazit

KeePass ist ein Ausgangspunkt. Für einen Solo-Admin oder ein Zwei-Personen-Team ohne externe Audit-Anforderungen erfüllt es seinen Zweck. Für jedes Team, das über diese Schwelle hinaus operiert, erzeugt es mehr Risiko, als es eliminiert.

Die administrative Schuld akkumuliert sich leise: Sync-Konflikte, die hier eine Stunde kosten, eine Offboarding-Rotation, die dort einen Tag kostet, ein Audit-Finding, das ein Quartal kostet. Nichts davon erscheint auf der KeePass-Rechnung, weil es keine gibt. Aber die Kosten sind real.

Der nächste Schritt ist unkompliziert: Kartieren Sie Ihr aktuelles Credential-Inventar, identifizieren Sie, welche Teams Zugriff auf welche Systeme teilen, und bewerten Sie, ob Ihr aktuelles Tool Ihnen sagen kann, wer auf was Zugriff hat. Wenn es das nicht kann, haben Sie Ihre Antwort.

Wenn Ihr Team über KeePass hinausgewachsen ist, wurde Passwork genau für diesen Moment entwickelt. Sie erhalten granulare Berechtigungen, Echtzeit-Sync, Audit-Logs pro Benutzer, AD-Integration, MFA-Durchsetzung und Zero-Knowledge-Verschlüsselung. Alles ohne die operative Schuld der Verwaltung gemeinsamer Masterpasswörter und manueller Credential-Rotation. Passwork kostenlos testen

Häufig gestellte Fragen

Ist KeePass sicher für die Unternehmensnutzung?

KeePass verwendet AES-256-Verschlüsselung und ist Open-Source mit einer langen Sicherheitsbilanz, was es kryptographisch solide macht. Für die Unternehmensnutzung liegt das Sicherheitsrisiko im Fehlen von Audit-Logs, granularen Zugriffssteuerungen und MFA-Durchsetzung. Diese Lücken erzeugen Compliance-Risiko unter GDPR Artikel 32 und SOC 2 CC6.1.

Können mehrere Benutzer eine KeePass-Datenbank teilen?

Ja, aber mit erheblichen Einschränkungen. KeePass hat keine Echtzeit-Sync-Engine. Wenn zwei Benutzer dieselbe .kdbx-Datei gleichzeitig auf einem Netzlaufwerk bearbeiten, überschreibt das letzte Speichern das vorherige ohne Merge oder Warnung. Die eigene Dokumentation von KeePass beschreibt dies als bekannte Einschränkung, die manuelle Workarounds erfordert.

Was ist der Hauptunterschied zwischen KeePass und einem Unternehmens-Passwortmanager?

Der Kernunterschied liegt in der Zugriffsarchitektur. KeePass verwendet ein einziges Masterpasswort, das von allen Benutzern geteilt wird — es gibt keine individuellen Konten, keine Berechtigungen pro Benutzer und keine Aktivitätslogs. Ein Unternehmens-Passwortmanager weist jedem Benutzer seine eigene authentifizierte Sitzung zu, erzwingt rollenbasierten Zugriff auf bestimmte Tresore und protokolliert jede Credential-Interaktion.

Unterstützt KeePass Active Directory oder LDAP?

Nein. KeePass hat keine native AD- oder LDAP-Integration. Benutzer-Provisioning und -Deprovisioning sind vollständig manuell. Im Gegensatz dazu integrieren sich Enterprise-Grade-Credential-Manager mit AD/LDAP, sodass Zugriffsrechte automatisch der Verzeichnisgruppen-Mitgliedschaft folgen.

Warum besteht KeePass Compliance-Audits nicht?

KeePass kann keine Nachweise darüber erbringen, wer wann auf welche Zugangsdaten zugegriffen hat. SOC 2 Type II-Auditoren verlangen Zugriffs-Logs unter CC6.1. GDPR Artikel 32 verlangt nachweisbare Zugriffssteuerungen. Eine .kdbx-Datei mit einem gemeinsamen Masterpasswort erfüllt keine der beiden Anforderungen, unabhängig davon, wie stark die Verschlüsselung ist.

Wann sollte ein KMU von KeePass zu einem Unternehmens-Passwortmanager wechseln?

Die praktische Schwelle liegt bei fünf oder mehr Benutzern, jeglicher Compliance-Verpflichtung (SOC 2, GDPR, HIPAA, ISO 27001) oder jeder Situation, in der der Zugriffsverlauf nachgewiesen werden muss. Wenn beim Ausscheiden eines Mitarbeiters Zugangsdaten rotiert werden müssen, anstatt ein Benutzerkonto zu widerrufen, ist das ein klares Signal, dass das aktuelle Tool nicht zweckgeeignet ist.

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und rangiert unter den besten 10 % von über 100.000 Lösungen. Das Badge basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einem perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

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

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lifecycle behandelt wird. Dieser Leitfaden behandelt alle sieben Stufen — von Erstellung und Ownership bis hin zu sicherer Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Todos los administradores de TI que utilizan KeePass para un equipo cuentan la misma historia. Comienza con un único archivo .kdbx compartido en una unidad de red. Luego alguien no puede abrirlo porque un compañero lo tiene bloqueado. Después, un administrador de sistemas junior sobrescribe un cambio que otra persona hizo una hora antes. Finalmente, un empleado se va y nadie sabe con certeza a qué contraseñas tenía acceso.

KeePass es una herramienta genuinamente excelente — para una sola persona. En el momento en que lo pone frente a un equipo, ya no está gestionando contraseñas. Está gestionando un único archivo.

Conclusiones clave

KeePass es excelente para individuos, pero estructuralmente inadecuado para equipos. En el momento en que añade un segundo usuario, pierde la sincronización en tiempo real, el control de acceso granular y los registros de auditoría — las tres cosas que previenen las filtraciones de credenciales y las violaciones de cumplimiento normativo.

• La sincronización multiusuario es manual y propensa a errores. Las ediciones simultáneas en un archivo .kdbx compartido causan pérdida de datos. El problema del «último escritor gana» escala linealmente con el tamaño del equipo. No hay fusión, no hay detección de conflictos y no hay advertencia.
• El control de acceso es binario. Todos los que necesitan la contraseña maestra obtienen acceso completo a todas las credenciales. No existe el concepto de «este usuario puede leer las credenciales de la nube pero no las contraseñas de la base de datos». La baja de personal requiere rotar todas las credenciales que pudieron haber visto.
• KeePass no produce registros de auditoría. No puede demostrar quién accedió a una credencial específica, cuándo o desde dónde. Esto incumple SOC 2 CC6.1, GDPR Artículo 32, NIS2, ISO 27001 y PCI DSS 4.0 — todos los marcos de cumplimiento modernos.
• El coste operativo se acumula rápidamente. Los conflictos de sincronización, las bajas manuales, la rotación de credenciales y las brechas de auditoría crean una sobrecarga administrativa que crece con el tamaño del equipo.
• La solución es una bóveda diseñada específicamente con RBAC, integración con AD y registros de auditoría automatizados. No una hoja de cálculo más grande, no una mejor herramienta para compartir archivos — un gestor de credenciales diseñado para equipos que operan bajo marcos de cumplimiento.

El atractivo de KeePass para pequeñas empresas

KeePass atrae a las pymes por tres razones completamente racionales: no cuesta nada, almacena los datos localmente y ha sido auditado por la comunidad de código abierto durante más de dos décadas. Para una empresa de cinco personas sin obligaciones de cumplimiento y un único generalista de TI, esas son ventajas reales.

El cifrado es sólido. KeePass 2.x utiliza AES-256 por defecto, con soporte opcional para ChaCha20 — este último es más rápido en hardware móvil donde la aceleración por hardware de AES no está disponible. El formato .kdbx está bien documentado, es portátil y no va a desaparecer.

KeePass sigue siendo una parte significativa de la curva de adopción del consumidor, particularmente entre usuarios técnicamente capacitados que desconfían de los servicios en la nube. Sin embargo, el segmento empresarial (donde las auditorías de cumplimiento, el acceso multiequipo y el registro de auditoría son obligatorios) se ha movido casi por completo hacia soluciones diseñadas específicamente.

La «trampa de escala de KeePass»: cuando lo gratuito se vuelve caro

KeePass fue diseñado como una aplicación para un solo usuario. Su documentación multiusuario reconoce esto directamente — la página de ayuda oficial de KeePass sobre múltiples usuarios describe soluciones alternativas, no funciones nativas. Cuando coloca un archivo .kdbx en una unidad de red compartida y da acceso a cinco personas, ha construido un sistema que eventualmente fallará. Así es exactamente cómo.

El problema del «último escritor gana»

KeePass no tiene motor de sincronización en tiempo real. Cuando dos usuarios abren el mismo archivo de base de datos simultáneamente, cada uno mantiene una copia local en memoria. Cuando el Usuario A guarda, el archivo se actualiza. Cuando el Usuario B guarda treinta segundos después, su versión sobrescribe completamente los cambios del Usuario A. No hay fusión, no hay detección de conflictos y no hay advertencia.

KeePass ofrece una función manual de «Sincronizar» que puede fusionar dos archivos .kdbx — pero requiere una acción deliberada del usuario, y solo funciona si ambas versiones están disponibles. En una unidad de red compartida donde el archivo se sobrescribe al guardar, esa segunda versión ya se ha perdido.

Acceso de todo o nada

KeePass tiene una contraseña maestra (o archivo de clave) por base de datos. Todos los que necesitan acceso obtienen la misma clave. No existe el concepto de «este usuario puede leer las credenciales del servidor en la nube pero no las contraseñas de la base de datos». Puede crear archivos .kdbx separados para diferentes niveles de acceso, pero ahora está gestionando múltiples archivos y múltiples procesos de sincronización — y todavía no tiene registro de auditoría.

RBAC (control de acceso basado en roles) — la capacidad de definir qué puede ver y hacer cada usuario o grupo — simplemente no existe en la arquitectura de KeePass. Es una decisión de diseño para una herramienta de usuario único.

La baja de personal

Cuando un empleado con acceso a la base de datos compartida de KeePass abandona su organización, la respuesta de seguridad correcta es rotar todas las credenciales que pudo haber visto. Todas ellas. Debido a que no tiene registro de a qué accedió, no puede limitar el alcance de la rotación — tiene que asumir el peor escenario.

Para una base de datos con 200 entradas, eso es un día completo de trabajo. Para una base de datos con 800 entradas distribuidas entre sistemas de producción, herramientas SaaS y entornos de clientes, es un incidente de varios días. Y sucede cada vez que alguien se va.

Las bóvedas basadas en roles de Passwork permiten revocar el acceso de un empleado saliente con una sola acción. Vea cómo funciona

Seguridad vs. cumplimiento: El panorama regulatorio de 2026

El cifrado de KeePass es genuinamente fuerte. AES-256 con una contraseña maestra bien elegida no es el punto débil. El punto débil es que KeePass no produce evidencia de lo que ocurrió dentro de la base de datos — y en 2026, esa evidencia es lo que piden los auditores.

Lo que requiere el Artículo 32 del GDPR

El Artículo 32 del GDPR exige «medidas técnicas y organizativas apropiadas» para garantizar un nivel de seguridad adecuado al riesgo. Para la gestión de credenciales, la interpretación práctica del Artículo 32 incluye cifrado en reposo, controles de acceso y — de manera crítica — la capacidad de demostrar que los controles de acceso funcionan. Esa última parte requiere registros.

Una base de datos de KeePass no puede indicarle quién la abrió, cuándo, desde qué máquina o qué consultó. Si un regulador le pide que demuestre que el acceso a las credenciales de datos personales estaba apropiadamente restringido, un archivo .kdbx no es una respuesta.

Directiva NIS2: Control de acceso y respuesta a incidentes

La Directiva NIS2 (efectiva desde octubre de 2024 para organizaciones de la UE) exige que los operadores de servicios esenciales y entidades importantes implementen «control de acceso avanzado» y mantengan registros detallados del acceso a activos críticos. Para la gestión de credenciales, esto significa:

• Control de acceso basado en roles (RBAC) con autenticación por usuario
• Registros de auditoría inmutables de todo el acceso a credenciales
• La capacidad de revocar el acceso inmediatamente cuando un empleado se va

Un archivo KeePass compartido con una única contraseña maestra viola los tres requisitos. Regenerar las claves de toda la base de datos cuando alguien se va no es «revocación inmediata» — es una solución alternativa que crea sobrecarga administrativa y aumenta el riesgo de error humano.

ISO 27001:2022 y requisitos de control de acceso

ISO 27001 Anexo A.8.2 (Control de Acceso) y A.8.15 (Registro) requieren que las organizaciones implementen controles que restrinjan el acceso a la información a usuarios autorizados y mantengan registros de acceso. Para repositorios de credenciales, esto se traduce en:

• Permisos de acceso granulares vinculados a roles laborales
• Registros de auditoría que muestren quién accedió a qué, cuándo y desde dónde
• Aplicación automatizada del principio de mínimo privilegio

KeePass no ofrece ninguno de estos. Una base de datos compartida entre miembros del equipo con una única contraseña es lo opuesto al mínimo privilegio — es el máximo privilegio para todos.

PCI DSS 4.0: Protección de datos de tarjetas de pago

Si su organización maneja datos de tarjetas de pago, el Requisito 7.1 de PCI DSS 4.0 exige que el acceso a los datos del titular de la tarjeta esté restringido al personal con una necesidad comercial legítima. El Requisito 10.2.1 requiere el registro de todo el acceso a sistemas que contienen datos del titular de la tarjeta, incluyendo el ID de usuario, la fecha, la hora y la naturaleza del acceso.

Una base de datos de KeePass que almacena claves de API de pasarelas de pago o credenciales de bases de datos no puede satisfacer estos requisitos. No hay autenticación por usuario, no hay registro de auditoría y no hay forma de demostrar a un auditor de PCI que el acceso estaba restringido al personal autorizado.

SOC 2 Tipo II y CC6.1

Los Criterios de Servicios de Confianza SOC 2 CC6.1 requieren que el acceso lógico a sistemas que almacenan datos sensibles esté restringido a usuarios autorizados y que el acceso sea registrado. Una base de datos de KeePass compartida con una única contraseña maestra incumple ambas condiciones. No hay autenticación por usuario y no hay registro.

Este no es un riesgo teórico. Los auditores solicitan registros de acceso durante las evaluaciones SOC 2 Tipo II. «Usamos KeePass» termina mal esa conversación.

NIST SP 800-63B (Revisión 4)

NIST SP 800-63B, finalizado en agosto de 2025, recomienda una longitud mínima de contraseña de 15 caracteres para secretos memorizados y desaconseja explícitamente la rotación periódica obligatoria en favor de la rotación desencadenada por brechas. KeePass puede almacenar contraseñas conformes — pero no puede aplicar la política, informar sobre el cumplimiento ni demostrar a un auditor que se siguió la política.

La magnitud de la amenaza

Las cifras hacen concreto el argumento del cumplimiento. Según el Informe del Coste de una Filtración de Datos 2025 de IBM, el coste promedio de una filtración para empresas con menos de 500 empleados alcanzó los 3,31 millones de dólares. El compromiso de credenciales está consistentemente entre los principales vectores de acceso inicial. Una violación de cumplimiento además de una filtración multiplica el daño financiero a través de multas regulatorias y costes de remediación.

La curva de madurez de seguridad de contraseñas para pymes

La mayoría de las pymes atraviesan tres etapas reconocibles. Nombrar esta progresión ayuda a los equipos a identificar dónde están y cuál es realmente el siguiente paso.

• Etapa 1 — Excel/documento compartido. Credenciales en una hoja de cálculo, a menudo en una unidad compartida o hilo de correo electrónico. Sin cifrado. Sin control de acceso. Completamente auditable de la peor manera posible: cualquiera con el archivo puede ver todo.
• Etapa 2 — KeePass. Archivo cifrado, criptografía fuerte, coste cero. Una mejora genuina respecto a la Etapa 1. Apropiado para individuos y equipos muy pequeños sin requisitos de cumplimiento. Falla por encima de cinco usuarios, bajo auditoría o cuando alguien se va.
• Etapa 3 — Bóveda corporativa. Gestión de credenciales multiusuario diseñada específicamente con RBAC, integración AD/LDAP, registros de auditoría por usuario, aplicación de MFA y baja automatizada. Aquí es donde deben estar los equipos con obligaciones de cumplimiento, más de diez usuarios o cualquier requisito de seguridad de cara al cliente.

La trampa es quedarse en la Etapa 2 más allá del punto donde encaja. El coste de ese retraso es la sobrecarga administrativa, la exposición a incidentes y los hallazgos de auditoría.

La prueba de estrés de 5 puntos de KeePass para su empresa

Revise estas cinco preguntas con su configuración actual. Cada «sí» es una señal de que KeePass está creando un riesgo que su equipo puede no haber valorado.

1. ¿Tiene más de 5 usuarios accediendo a la base de datos compartida?
   Por encima de cinco usuarios concurrentes, los conflictos de sincronización se convierten en un evento casi diario. El problema del «último escritor gana» escala linealmente con el tamaño del equipo.
2. ¿Puede demostrar quién accedió a una credencial específica y cuándo?
   Si un cliente pregunta cuál de sus empleados accedió a sus credenciales de sistema el martes pasado, ¿puede responder? KeePass no puede producir ese registro. Una bóveda corporativa con registro de auditoría sí puede.
3. ¿Está la base de datos almacenada en una unidad compartida, Dropbox o similar?
   Las herramientas de sincronización en la nube como Dropbox añaden su propia resolución de conflictos encima de la de KeePass — lo que significa que puede terminar con múltiples versiones de .kdbx y ninguna forma fiable de saber cuál es la actual. Las unidades de red compartidas tienen el problema de bloqueo de archivos descrito anteriormente.
4. ¿Cuánto tiempo tarda en revocar completamente el acceso de un exempleado?
   Si la respuesta es «cambiamos la contraseña maestra y luego rotamos todo lo que pudieron haber visto», está describiendo un incidente de varias horas que ocurre cada vez que alguien se va. Con controles de acceso por usuario, la revocación es una única acción.
5. ¿Está MFA protegiendo la propia bóveda?
   KeePass soporta archivos de clave como segundo factor, pero distribuir y gestionar esos archivos de clave en un equipo es su propio problema operativo. La integración nativa de MFA — TOTP, llaves de hardware, SSO — requiere una herramienta diseñada específicamente.

Si respondió «no» a las preguntas 2 y 5, o «sí» a las preguntas 1, 3 y 4, su equipo ha superado a KeePass.

¿Cómo gestiona el acceso a credenciales cuando su equipo crece más allá de cinco personas? Passwork maneja la gestión de credenciales multiequipo con RBAC, registro de auditoría y sincronización en tiempo real — sin la sobrecarga operativa. Pruebe Passwork gratis

Más allá de KeePass: Elegir una solución de gestión de accesos corporativa

Los criterios para un gestor de credenciales de nivel empresarial no son complicados, pero son innegociables una vez que opera a cualquier escala o bajo cualquier marco de cumplimiento.

Bóvedas compartidas con permisos granulares

Cada equipo o proyecto debe tener su propia bóveda. Los usuarios individuales obtienen acceso a las bóvedas que necesitan, con el nivel de permiso que necesitan (lectura, escritura, administrador). Cuando el rol de alguien cambia, actualiza su membresía de bóveda — no la contraseña maestra. Esto es control de acceso basado en roles (RBAC), y es la base del cumplimiento. KeePass no tiene equivalente.

Passwork asigna permisos a grupos, por lo que cuando un desarrollador se une al equipo de DevOps, hereda automáticamente el acceso a la bóveda del equipo. Cuando se va, lo revoca una sola vez.

RBAC vinculado a su directorio

La integración con AD/LDAP significa que el aprovisionamiento y desaprovisionamiento de usuarios ocurren automáticamente. Cuando el administrador termina una cuenta en Active Directory, el acceso a la bóveda se va con ella. Sin paso manual, sin brecha. Passwork se integra de forma nativa con Active Directory y LDAP, por lo que su acceso a credenciales sigue su estructura organizacional — no al revés.

Registros de auditoría por usuario

Cada visualización, copia, edición y compartición de credencial debe registrarse con una marca de tiempo e identidad de usuario. Este es el registro que satisface SOC 2 CC6.1 y respalda la responsabilidad del Artículo 32 del GDPR. KeePass no produce registros.

Passwork mantiene un registro de auditoría completo de cada acción, exportable para revisiones de cumplimiento e investigaciones de incidentes.

Aplicación de MFA a nivel de bóveda

No opcional, no preferencia por usuario — aplicado por política, con soporte para TOTP, tokens de hardware y SAML SSO. KeePass soporta archivos de clave, lo cual no es MFA. Passwork aplica MFA a nivel de bóveda, con soporte para múltiples métodos de autenticación vinculados a su proveedor de identidad.

Autocompletado e integración con navegador

Un gestor de credenciales moderno se integra con navegadores y herramientas CLI para autocompletar contraseñas e inyectar secretos en pipelines de despliegue. KeePass tiene plugins de navegador, pero son mantenidos por la comunidad y carecen del modelo de seguridad de una bóveda centralizada. Passwork proporciona extensiones de navegador nativas y herramientas CLI que obtienen credenciales bajo demanda de su bóveda, con registro de auditoría completo de cada acción de autocompletado.

Arquitectura de conocimiento cero

Sus datos de credenciales deben cifrarse del lado del cliente antes de llegar al servidor. Esto significa que el servidor (ya sea autoalojado o en la nube) no puede descifrar sus credenciales. Es una garantía, no una promesa. KeePass cifra localmente, pero no ofrece colaboración en equipo sin compartición manual de archivos. Passwork utiliza cifrado AES-256 del lado del cliente con arquitectura de conocimiento cero: las credenciales se cifran antes de la transmisión, se almacenan cifradas en el servidor y se descifran solo en clientes autorizados.

Autoalojado o en la nube, su elección

Algunas pymes tienen razones regulatorias o contractuales para mantener los datos de credenciales en sus propias instalaciones. Una herramienta que ofrece autoalojamiento genuino le da el control que ofrece KeePass sin las limitaciones operativas. Passwork está disponible como gestor de contraseñas y secretos en la nube y como despliegue autoalojado en su propia infraestructura, con cifrado AES-256 completo y arquitectura de conocimiento cero. Sus datos nunca salen de su control.

KeePass vs. Passwork: comparativa de funciones

La diferencia es arquitectónica. Cuando su equipo crece más allá de cinco personas, la fricción operativa de KeePass se vuelve real. La rotación de credenciales requiere regenerar las claves de toda la base de datos. La baja significa que todos cambian su contraseña maestra. El control de acceso es binario — o alguien tiene la contraseña maestra o no la tiene. Passwork elimina esa fricción: permisos granulares, bajas automatizadas, registros de auditoría por usuario y sincronización en tiempo real sin conflictos.

Si su organización opera bajo requisitos de cumplimiento (GDPR, SOC 2, NIS2, ISO 27001, PCI DSS), la brecha se amplía aún más. Una base de datos de KeePass compartida no pasa ninguna auditoría. Passwork con RBAC, registro de auditoría, integración con AD y cifrado de conocimiento cero satisface los requisitos de cumplimiento sin crear sobrecarga administrativa.

Conclusión

KeePass es un punto de partida. Para un administrador en solitario o un equipo de dos personas sin requisitos de auditoría externa, cumple su función. Para cualquier equipo que opere por encima de ese umbral, crea más riesgo del que elimina.

La deuda administrativa se acumula silenciosamente: conflictos de sincronización que cuestan una hora aquí, una rotación de baja que cuesta un día allá, un hallazgo de auditoría que cuesta un trimestre. Nada de esto aparece en la factura de KeePass porque no hay ninguna. Pero el coste es real.

El siguiente paso es sencillo: mapee su inventario de credenciales actual, identifique qué equipos comparten acceso a qué sistemas y evalúe si su herramienta actual puede indicarle quién tiene acceso a qué. Si no puede, tiene su respuesta.

Si su equipo ha superado a KeePass, Passwork está diseñado exactamente para este momento. Obtiene permisos granulares, sincronización en tiempo real, registros de auditoría por usuario, integración con AD, aplicación de MFA y cifrado de conocimiento cero. Todo sin la deuda operativa de gestionar contraseñas maestras compartidas y rotación manual de credenciales. Pruebe Passwork gratis

Preguntas frecuentes

¿Es seguro KeePass para uso empresarial?

KeePass utiliza cifrado AES-256 y es de código abierto con un largo historial de seguridad, lo que lo hace criptográficamente sólido. Para uso empresarial, el riesgo de seguridad es la ausencia de registros de auditoría, controles de acceso granulares y aplicación de MFA. Estas brechas crean exposición de cumplimiento bajo el Artículo 32 del GDPR y SOC 2 CC6.1.

¿Pueden múltiples usuarios compartir una base de datos de KeePass?

Sí, pero con limitaciones significativas. KeePass no tiene motor de sincronización en tiempo real. Cuando dos usuarios editan el mismo archivo .kdbx simultáneamente en una unidad de red compartida, el último guardado sobrescribe el anterior sin fusión ni advertencia. La propia documentación de KeePass describe esto como una limitación conocida que requiere soluciones alternativas manuales.

¿Cuál es la principal diferencia entre KeePass y un gestor de contraseñas corporativo?

La diferencia central es la arquitectura de acceso. KeePass utiliza una única contraseña maestra compartida por todos los usuarios — no hay cuentas individuales, no hay permisos por usuario y no hay registros de actividad. Un gestor de contraseñas corporativo asigna a cada usuario su propia sesión autenticada, aplica acceso basado en roles a bóvedas específicas y registra cada interacción con credenciales.

¿Soporta KeePass Active Directory o LDAP?

No. KeePass no tiene integración nativa con AD o LDAP. El aprovisionamiento y desaprovisionamiento de usuarios es completamente manual. En contraste, los gestores de credenciales de nivel empresarial se integran con AD/LDAP para que los derechos de acceso sigan automáticamente la pertenencia a grupos del directorio.

¿Por qué KeePass no pasa las auditorías de cumplimiento?

KeePass no puede producir evidencia de quién accedió a qué credenciales y cuándo. Los auditores de SOC 2 Tipo II requieren registros de acceso bajo CC6.1. El Artículo 32 del GDPR requiere controles de acceso demostrables. Un archivo .kdbx con una contraseña maestra compartida no satisface ninguno de los requisitos, independientemente de lo fuerte que sea el cifrado.

¿Cuándo debería una pyme pasar de KeePass a un gestor de contraseñas corporativo?

El umbral práctico es cinco o más usuarios, cualquier obligación de cumplimiento (SOC 2, GDPR, HIPAA, ISO 27001), o cualquier situación donde necesite demostrar el historial de acceso. Si la salida de un empleado requiere rotar credenciales en lugar de revocar una cuenta de usuario, esa es una señal clara de que la herramienta actual no es adecuada para el propósito.

Passwork gana Top Performer Primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge, posicionándose en el 10% superior de más de 100.000 soluciones. La insignia se basa completamente en reseñas verificadas — 4,8 estrellas en general, con un 5,0 perfecto en soporte.

Passwork BlogAlex Muntyan

Ciclo de vida de rotación de secretos: Desde la creación hasta 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

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 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

Every IT admin who runs KeePass for a team tells the same story. It starts with one shared .kdbx file on a network drive. Then someone can't open it because a colleague has it locked. Then a junior sysadmin saves over a change someone else made an hour ago. Then an employee leaves, and nobody's quite sure which passwords they had access to.

KeePass is a genuinely excellent tool — for one person. The moment you put it in front of a team, you're not managing passwords anymore. You're managing a single file.

Key takeaways

KeePass is excellent for individuals but structurally unsuitable for teams. The moment you add a second user, you lose real-time sync, granular access control, and audit trails — the three things that prevent credential breaches and compliance violations.

• Multi-user sync is manual and error-prone. Concurrent edits on a shared .kdbx file cause data loss. The "last-writer-wins" problem scales linearly with team size. There is no merge, no conflict detection, and no warning.
• Access control is binary. Everyone who needs the master password gets full access to every credential. There is no concept of "this user can read cloud credentials but not database passwords." Offboarding requires rotating every credential they could have seen.
• KeePass produces no audit logs. You cannot prove who accessed a specific credential, when, or from where. This fails SOC 2 CC6.1, GDPR Article 32, NIS2, ISO 27001, and PCI DSS 4.0 — every modern compliance framework.
• The operational cost compounds quickly. Sync conflicts, manual offboarding, credential rotation, and audit gaps create administrative overhead that grows with team size.
• The fix is a purpose-built vault with RBAC, AD integration, and automated audit trails. Not a bigger spreadsheet, not a better file-sharing tool — a credential manager built for teams operating under compliance frameworks.

The allure of KeePass for small businesses

KeePass appeals to SMBs for three reasons that are completely rational: it costs nothing, stores data locally, and has been audited by the open-source community for over two decades. For a five-person shop with no compliance obligations and a single IT generalist, those are real advantages.

The encryption is solid. KeePass 2.x uses AES-256 by default, with optional ChaCha20 support — the latter being faster on mobile hardware where AES hardware acceleration isn't available. The .kdbx format is well-documented, portable, and not going anywhere.

KeePass remains a meaningful part of the consumer adoption curve, particularly among technically literate users who distrust cloud services. However, the enterprise segment (where compliance audits, multi-team access, and audit logging are mandatory) has almost entirely moved to purpose-built solutions.

The "KeePass scale trap": When free becomes expensive

KeePass was designed as a single-user application. Its multi-user documentation acknowledges this directly — the official KeePass help page on multiple users describes workarounds, not native features. When you put a .kdbx file on a network share and give five people access, you've built a system that will eventually fail. Here's exactly how.

The last-writer-wins problem

KeePass has no real-time sync engine. When two users open the same database file simultaneously, each holds a local copy in memory. When User A saves, the file updates. When User B saves thirty seconds later, their version overwrites User A's changes entirely. There is no merge, no conflict detection, and no warning.

KeePass does offer a manual "Synchronize" function that can merge two .kdbx files — but it requires a deliberate action from the user, and it only works if both versions are available. On a network share where the file gets overwritten on save, that second version is already gone.

All-or-nothing access

KeePass has one master password (or key file) per database. Everyone who needs access gets the same key. There is no concept of "this user can read the cloud server credentials but not the database passwords." You can create separate .kdbx files for different access levels, but now you're managing multiple files and multiple sync processes — and you still have no audit trail.

RBAC (role-based access control) — the ability to define what each user or group can see and do — simply doesn't exist in KeePass's architecture. It's a design choice for a single-user tool.

The offboarding

When an employee with access to the shared KeePass database leaves your organization, the correct security response is to rotate every credential they could have seen. All of them. Because you have no log of what they accessed, you can't scope the rotation — you have to assume worst-case.

For a database with 200 entries, that's a full day of work. For a database with 800 entries across production systems, SaaS tools, and client environments, it's a multi-day incident. And it happens every time someone leaves.

Passwork's role-based vaults let you revoke access for a departing employee in a single action. See how it works

Security vs. compliance: The 2026 regulatory landscape

KeePass's encryption is genuinely strong. AES-256 with a well-chosen master password is not the weak point. The weak point is that KeePass produces no evidence of what happened inside the database — and in 2026, that evidence is what auditors ask for.

What GDPR Article 32 requires

GDPR Article 32 mandates "appropriate technical and organisational measures" to ensure security appropriate to the risk. For credential management, the Article 32 working interpretation includes encryption at rest, access controls, and — critically — the ability to demonstrate that access controls are working. That last part requires logs.

A KeePass database can't tell you who opened it, when, from which machine, or what they looked at. If a regulator asks you to demonstrate that access to personal data credentials was appropriately restricted, a .kdbx file is not an answer.

NIS2 Directive: Access control and incident response

The NIS2 Directive (effective October 2024 for EU organizations) mandates that operators of essential services and important entities implement "advanced access control" and maintain detailed logs of access to critical assets. For credential management, this means:

• Role-based access control (RBAC) with per-user authentication
• Immutable audit logs of all credential access
• The ability to revoke access immediately upon employee departure

A shared KeePass file with a single master password violates all three requirements. Rekeying the entire database when someone leaves is not "immediate revocation" — it's a workaround that creates administrative overhead and increases the risk of human error.

ISO 27001:2022 and access control requirements

ISO 27001 Annex A.8.2 (Access Control) and A.8.15 (Logging) require organizations to implement controls that restrict access to information to authorized users and maintain records of access. For credential repositories, this translates to:

• Granular access permissions tied to job roles
• Audit trails showing who accessed what, when, and from where
• Automated enforcement of the principle of least privilege

KeePass offers none of these. A database shared among team members with a single password is the opposite of least privilege — it's maximum privilege for everyone.

PCI DSS 4.0: Payment card data protection

If your organization handles payment card data, PCI DSS 4.0 Requirement 7.1 mandates that access to cardholder data be restricted to personnel with a legitimate business need. Requirement 10.2.1 requires logging of all access to systems containing cardholder data, including the user ID, date, time, and nature of the access.

A KeePass database storing payment gateway API keys or database credentials cannot satisfy these requirements. There is no per-user authentication, no audit trail, and no way to prove to a PCI auditor that access was restricted to authorized personnel.

SOC 2 Type II and CC6.1

SOC 2 Trust Services Criteria CC6.1 requires that logical access to systems storing sensitive data be restricted to authorized users and that access be logged. A shared KeePass database with a single master password fails both conditions. There's no per-user authentication, and there's no log.

This isn't a theoretical risk. Auditors ask for access logs during SOC 2 Type II assessments. "We use KeePass" ends that conversation badly.

NIST SP 800-63B (Revision 4)

NIST SP 800-63B, finalized August 2025, recommends a minimum password length of 15 characters for memorized secrets and explicitly discourages mandatory periodic rotation in favor of breach-triggered rotation. KeePass can store compliant passwords — but it can't enforce the policy, report on compliance, or prove to an auditor that the policy was followed.

The scale of the threat

The numbers make the compliance argument concrete. According to IBM's 2025 Cost of a Data Breach Report, the average breach cost for businesses with fewer than 500 employees reached $3.31 million. Credential compromise is consistently among the top initial access vectors. A compliance violation on top of a breach compounds the financial damage through regulatory fines and remediation costs.

The SMB password security maturity curve

Most SMBs move through three recognizable stages. Naming this progression helps teams identify where they are and what the next step actually looks like.

• Stage 1 — Excel/shared doc. Credentials in a spreadsheet, often on a shared drive or email thread. No encryption. No access control. Fully auditable in the worst possible way: anyone with the file can see everything.
• Stage 2 — KeePass. Encrypted file, strong cryptography, zero cost. A genuine improvement over Stage 1. Appropriate for individuals and very small teams with no compliance requirements. Breaks down above five users, under audit, or when someone leaves.
• Stage 3 — Corporate vault. Purpose-built multi-user credential management with RBAC, AD/LDAP integration, per-user audit logs, MFA enforcement, and automated offboarding. This is where teams with compliance obligations, more than ten users, or any client-facing security requirements need to be.

The trap is staying at Stage 2 past the point where it fits. The cost of that delay is the administrative overhead, the incident exposure, and the audit findings.

The 5-point KeePass stress test for your business

Run through these five questions against your current setup. Each "yes" is a signal that KeePass is creating risk your team may not have priced in.

1. Do you have more than 5 users accessing the shared database?
   Above five concurrent users, sync conflicts become a near-daily event. The "last-writer-wins" problem scales linearly with team size.
2. Can you prove who accessed a specific credential and when?
   If a client asks which of your staff accessed their system credentials last Tuesday, can you answer? KeePass cannot produce that record. A corporate vault with audit logging can.
3. Is the database stored on a shared drive, Dropbox, or similar?
   Cloud sync tools like Dropbox add their own conflict resolution on top of KeePass's — which means you can end up with multiple .kdbx versions and no reliable way to know which is current. Network shares have the file-locking problem described above.
4. How long does it take to fully revoke access for a former employee?
   If the answer is "we change the master password and then rotate everything they might have seen," you're describing a multi-hour incident that happens every time someone leaves. With per-user access controls, revocation is a single action.
5. Is MFA protecting the vault itself?
   KeePass supports key files as a second factor, but distributing and managing those key files across a team is its own operational problem. Native MFA integration — TOTP, hardware keys, SSO — requires a purpose-built tool.

If you answered "no" to questions 2 and 5, or "yes" to questions 1, 3, and 4, your team has outgrown KeePass.

How do you manage credential access when your team scales beyond five people? Passwork handles multi-team credential management with RBAC, audit logging, and real-time sync — without the operational overhead. Try Passwork free

Beyond KeePass: Choosing a corporate access management solution

The criteria for a team-grade credential manager are not complicated, but they're non-negotiable once you're operating at any scale or under any compliance framework.

Shared vaults with granular permissions

Each team or project should have its own vault. Individual users get access to the vaults they need, at the permission level they need (read, write, admin). When someone's role changes, you update their vault membership — not the master password. This is role-based access control (RBAC), and it's the foundation of compliance. KeePass has no equivalent.

Passwork assigns permissions to groups, so when a developer joins the DevOps team, they inherit the team's vault access automatically. When they leave, you revoke it once.

RBAC tied to your directory

AD/LDAP integration means user provisioning and deprovisioning happen automatically. When admin terminates an account in Active Directory, vault access goes with it. No manual step, no gap. Passwork integrates natively with Active Directory and LDAP, so your credential access follows your organizational structure — not the other way around.

Per-user audit logs

Every credential view, copy, edit, and share should be logged with a timestamp and user identity. This is the record that satisfies SOC 2 CC6.1 and supports GDPR Article 32 accountability. KeePass produces no logs.

Passwork maintains a complete audit trail of every action, exportable for compliance reviews and incident investigations.

MFA enforcement at the vault level

Not optional, not per-user preference — enforced by policy, with support for TOTP, hardware tokens, and SAML SSO. KeePass supports key files, which is not MFA. Passwork enforces MFA at the vault level, with support for multiple authentication methods tied to your identity provider.

Autofill and browser integration

A modern credential manager integrates with browsers and CLI tools to autofill passwords and inject secrets into deployment pipelines. KeePass has browser plugins, but they're community-maintained and lack the security model of a centralized vault. Passwork provides native browser extensions and CLI tools that pull credentials on-demand from your vault, with full audit logging of every autofill action.

Zero-knowledge architecture

Your credential data should be encrypted client-side before it ever reaches the server. This means the server (whether self-hosted or cloud) cannot decrypt your credentials. It's a guarantee, not a promise. KeePass encrypts locally, but offers no team collaboration without manual file sharing. Passwork uses AES-256 client-side encryption with zero-knowledge architecture: credentials are encrypted before transmission, stored encrypted on the server, and decrypted only on authorized clients.

Self-hosted or cloud, your choice

Some SMBs have regulatory or contractual reasons to keep credential data on-premises. A tool that offers genuine self-hosting gives you the control KeePass offers without the operational limitations. Passwork is available as a cloud password and secrets manager and a self-hosted deployment on your own infrastructure, with full AES-256 encryption and zero-knowledge architecture. Your data never leaves your control.

KeePass vs. Passwork: feature comparison

The difference is architectural. When your team grows beyond five people, the operational friction of KeePass becomes real. Credential rotation requires rekeying the entire database. Offboarding means everyone changes their master password. Access control is binary — either someone has the master password or they don't. Passwork eliminates that friction: granular permissions, automated offboarding, per-user audit trails, and real-time sync without conflicts.

If your organization operates under compliance requirements (GDPR, SOC 2, NIS2, ISO 27001, PCI DSS), the gap widens further. A shared KeePass database fails every audit. Passwork with RBAC, audit logging, AD integration, and zero-knowledge encryption satisfies compliance requirements without creating administrative overhead.

Conclusion

KeePass is a starting point. For a solo admin or a two-person team with no external audit requirements, it does the job. For any team operating above that threshold it creates more risk than it eliminates.

The administrative debt accumulates quietly: sync conflicts that cost an hour here, an offboarding rotation that costs a day there, an audit finding that costs a quarter. None of it shows up on the KeePass invoice because there isn't one. But the cost is real.

The next step is straightforward: map your current credential inventory, identify which teams share access to which systems, and evaluate whether your current tool can tell you who has access to what. If it can't, you have your answer.

If your team has outgrown KeePass, Passwork is built for exactly this moment. You get granular permissions, real-time sync, per-user audit logs, AD integration, MFA enforcement, and zero-knowledge encryption. All without the operational debt of managing shared master passwords and manual credential rotation. Try Passwork free

Frequently asked questions

Is KeePass safe for business use?

KeePass uses AES-256 encryption and is open-source with a long security track record, making it cryptographically sound. For business use, the security risk is the absence of audit logs, granular access controls, and MFA enforcement. These gaps create compliance exposure under GDPR Article 32 and SOC 2 CC6.1.

Can multiple users share a KeePass database?

Yes, but with significant limitations. KeePass has no real-time sync engine. When two users edit the same .kdbx file simultaneously on a network share, the last save overwrites the previous one with no merge or warning. KeePass's own documentation describes this as a known limitation requiring manual workarounds.

What is the main difference between KeePass and a corporate password manager?

The core difference is access architecture. KeePass uses a single master password shared by all users — there are no individual accounts, no per-user permissions, and no activity logs. A corporate password manager assigns each user their own authenticated session, enforces role-based access to specific vaults, and logs every credential interaction.

Does KeePass support Active Directory or LDAP?

No. KeePass has no native AD or LDAP integration. User provisioning and deprovisioning are entirely manual. In contrast, enterprise-grade credential managers integrate with AD/LDAP so that access rights follow directory group membership automatically.

Why does KeePass fail compliance audits?

KeePass cannot produce evidence of who accessed which credentials and when. SOC 2 Type II auditors require access logs under CC6.1. GDPR Article 32 requires demonstrable access controls. A .kdbx file with a shared master password satisfies neither requirement, regardless of how strong the encryption is.

When should an SMB move from KeePass to a corporate password manager?

The practical threshold is five or more users, any compliance obligation (SOC 2, GDPR, HIPAA, ISO 27001), or any situation where you need to prove access history. If an employee departure requires rotating credentials rather than revoking a user account, that's a clear signal the current tool isn't fit for purpose.

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

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

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

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet — einer B2B-Softwarevergleichsplattform, auf der IT-Teams Tools recherchieren, bevor sie Kaufentscheidungen treffen. Die Auszeichnung basiert ausschließlich auf verifizierten Bewertungen von Personen, die Passwork täglich einsetzen und nutzen.

Dies folgt auf eine weitere Anerkennung Anfang 2026: Passwork erhielt die Auszeichnung Best Customer Support von Software Advice, einer zu Gartner gehörenden Plattform für Unternehmenssoftware-Recherche. Auch diese Auszeichnung wird durch verifizierte Nutzerbewertungen bestimmt, wobei die Supportqualität das primäre Kriterium ist.

Was Nutzer über Passwork sagen

Laut verifizierten Bewertungen auf SourceForge bewerten Nutzer Passwork als zuverlässigen Passwort-Manager und loben das strukturierte Anmeldedaten-Management mit Zugriffskontrolle auf Ordnerebene, den reibungslosen Bereitstellungsprozess und einen Support, der tatsächlich antwortet.

„Wir verwenden Passwork als unseren geschäftlichen Passwort-Manager und haben bisher sehr positive Erfahrungen gemacht. Die Oberfläche ist übersichtlich und einfach zu bedienen, das Onboarding des Teams war unkompliziert, und das sichere Teilen von Anmeldedaten zwischen Abteilungen funktioniert wirklich gut." — IT-Leiter

Administratoren heben die granulare Zugriffskontrolle als herausragendes Merkmal hervor — die Möglichkeit, Anmeldedaten logisch zu strukturieren und die Sichtbarkeit auf Ordnerebene einzuschränken.

„Was mir an Passwork am besten gefällt, ist, dass man Anmeldedaten/Passwörter in Ordnern und Unterordnern für eine übersichtliche logische Struktur organisieren kann und Zugriff nur auf bestimmte Ordner gewähren kann." — Infrastruktur-Architekt

Für Sicherheits- und Compliance-Teams wird Passwork zur Grundlage für die Erfüllung formaler Zertifizierungsanforderungen.

„Die Integration mit verschiedenen Browsern und die Smartphone-App sind unschlagbare Vorteile. Die Weboberfläche ist einfach und intuitiv. Es war die Lösung, die uns ermöglichte, die Anforderungen des ISO-27001-Standards zu erfüllen." — ICT-Manager

Über die Auszeichnung

SourceForge ist das weltweit größte B2B-Softwarebewertungs- und -vergleichsverzeichnis mit fast 20 Millionen monatlichen Nutzern, die Unternehmenssoftware evaluieren. SourceForge vergibt das Top-Performer-Abzeichen viermal jährlich — im Frühjahr, Sommer, Herbst und Winter. Es geht an Produkte, die zu den besten 10 % von mehr als 100.000 auf der Plattform gelisteten Lösungen gehören.

„Diese Auszeichnung bestätigt, dass unser Fokus auf flexibles, strukturiertes Anmeldedaten-Management, Transparenz und echten Support der richtige Weg war. Es bedeutet noch mehr zu wissen, dass sie direkt von den Menschen kommt, die Passwork täglich nutzen." — Alex Muntyan, CEO von Passwork

Die Auswahl wird durch verifizierte Nutzerbewertungen bestimmt, ohne redaktionelle Beurteilung. Je aktueller, zahlreicher und besser bewertet sie sind, desto höher rangiert das Produkt. Passwork hat eine Gesamtbewertung von 4,8 von 5 Sternen, mit Einzelwertungen von 4,7 für Benutzerfreundlichkeit, 4,8 für Design und 5,0 für Support.

Erfahren Sie, wie Passwork Anmeldedaten sicher in Ihrer eigenen Infrastruktur aufbewahrt. Starten Sie eine kostenlose Testversion mit vollem Zugriff

Passwork gewinnt Best Customer Support 2026 von Software Advice

Wir freuen uns mitzuteilen, dass der Kundensupport von Passwork als der beste in der Kategorie Passwort-Manager von Software Advice ausgezeichnet wurde.

Passwork BlogAlex Muntyan

Was sind hartcodierte Secrets? Risiken und Prävention

Hartcodierte Secrets sind Anmeldedaten, die direkt in den Code geschrieben werden, anstatt zur Laufzeit eingefügt zu werden. Sie überdauern in der Git-Historie, CI/CD-Logs und Forks lange nach dem „Fix"-Commit. Dieser Leitfaden behandelt, wie sie sich verbreiten, wie man sie erkennt und wie man sie eliminiert.

Passwork BlogAlex Muntyan

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

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von der Erstellung und Eigentümerschaft bis zur sicheren Rotation, Notfall-Widerruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge — una plataforma de comparación de software B2B donde los equipos de TI investigan herramientas antes de tomar decisiones de compra. El premio se basa exclusivamente en reseñas verificadas de las personas que implementan y utilizan Passwork a diario.

Este reconocimiento sigue a otro recibido a principios de 2026: Passwork recibió el premio Mejor Soporte al Cliente de Software Advice, una plataforma propiedad de Gartner para la investigación de software empresarial. Ese premio también se determina mediante reseñas verificadas de usuarios, con la calidad del soporte como criterio principal.

Qué dicen los usuarios sobre Passwork

Según las reseñas verificadas en SourceForge, los usuarios califican a Passwork como un gestor de contraseñas fiable, destacando la gestión estructurada de credenciales con control de acceso a nivel de carpeta, un proceso de implementación sencillo y un soporte que realmente responde.

«Hemos estado utilizando Passwork como nuestro gestor de contraseñas empresarial y hasta ahora hemos tenido una experiencia muy positiva. La interfaz es limpia y fácil de usar, la incorporación del equipo fue sencilla, y compartir credenciales de forma segura entre departamentos funciona muy bien.» — Director de TI

Los administradores destacan el control de acceso granular como una característica sobresaliente — la capacidad de estructurar las credenciales de forma lógica y restringir la visibilidad a nivel de carpeta.

«Lo que más me gusta de Passwork es que puedes organizar credenciales/contraseñas en carpetas y subcarpetas para una estructura lógica ordenada y puedes dar acceso solo a carpetas específicas.» — Arquitecto de Infraestructura

Para los equipos de seguridad y cumplimiento, Passwork se convierte en la base para cumplir con los requisitos de certificación formal.

«La integración con varios navegadores y la aplicación para smartphone son ventajas inmejorables. La interfaz web es simple e intuitiva. Fue la solución que nos permitió cumplir con los requisitos de la norma ISO 27001.» — Director de TIC

Sobre el premio

SourceForge es el directorio de reseñas y comparación de software B2B más grande del mundo, con casi 20 millones de usuarios mensuales evaluando software empresarial. SourceForge otorga la insignia Top Performer cuatro veces al año — en primavera, verano, otoño e invierno. Se concede a productos que se sitúan en el 10% superior de más de 100.000 soluciones listadas en la plataforma.

«Este premio confirma que nuestro enfoque en la gestión de credenciales flexible y estructurada, la transparencia y el soporte real fue el camino correcto. Significa aún más sabiendo que proviene directamente de las personas que utilizan Passwork todos los días.» — Alex Muntyan, CEO de Passwork

La selección se determina mediante reseñas verificadas de usuarios, sin juicio editorial. Cuanto más recientes, numerosas y mejor valoradas sean, más alto se posiciona el producto. Passwork mantiene una calificación general de 4,8 sobre 5 estrellas, con puntuaciones individuales de 4,7 en facilidad de uso, 4,8 en diseño y 5,0 en soporte.

Descubra cómo Passwork mantiene las credenciales seguras dentro de su propia infraestructura. Inicie una prueba gratuita con acceso completo

Passwork gana Mejor Soporte al Cliente 2026 de Software Advice

Nos complace compartir que el soporte al cliente de Passwork ha sido reconocido como el mejor en la categoría de Gestores de Contraseñas por Software Advice.

Passwork BlogAlex Muntyan

¿Qué son los secretos hardcodeados? Riesgos y prevención

Los secretos hardcodeados son credenciales escritas directamente en el código en lugar de inyectarse en tiempo de ejecución. Persisten en el historial de Git, los logs de CI/CD y los forks mucho después del commit de «corrección». Esta guía cubre cómo se propagan, cómo detectarlos y cómo eliminarlos.

Passwork BlogAlex Muntyan

Ciclo de vida de la rotación de secretos: Desde la creación hasta 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 la propiedad hasta la rotación segura, la revocación de emergencia y la evidencia de auditoría.

Passwork BlogAlex Muntyan

Passwork has been named a Top Performer Spring 2026 by SourceForge — a B2B software comparison platform where IT teams research tools before making purchasing decisions. The award is based entirely on verified reviews from the people who deploy and use Passwork every day.

This follows another recognition earlier in 2026: Passwork received the Best Customer Support award from Software Advice, a Gartner-owned platform for business software research. That award is also determined by verified user reviews, with support quality as the primary criterion.

What users say about Passwork

According to verified reviews on SourceForge, users rate Passwork as a reliable password manager, praising structured credential management with folder-level access control, clean deployment process, and support that actually responds.

"We've been using Passwork as our business password manager and have had a very positive experience so far. The interface is clean and easy to use, onboarding the team was straightforward, and sharing credentials securely across departments works really well." — Head of IT

Administrators point to granular access control as a standout feature — the ability to structure credentials logically and restrict visibility at the folder level.

"What I like the most about Passwork is that you can organize credentials/passwords into folders and subfolders for a neat logical structure and you can give access just to particular folders." — Infrastructure Architect

For security and compliance teams, Passwork becomes the foundation for meeting formal certification requirements.

"Integration with various browsers and the smartphone app are unbeatable advantages. The web interface is simple and intuitive. It was the solution that enabled us to comply with the requirements of the ISO 27001 standard." — ICT Manager

About the award

SourceForge is the largest B2B software review and comparison directory in the world, with nearly 20 million monthly users evaluating business software. SourceForge issues the Top Performer badge four times a year — in spring, summer, fall, and winter. It goes to products that rank in the top 10% out of more than 100,000 solutions listed on the platform.

"This award confirms that our focus on flexible, structured credential management, transparency, and real support was the right path. It means even more knowing it comes directly from the people who use Passwork every day." — Alex Muntyan, CEO of Passwork

The selection is determined by verified user reviews, without editorial judgment. The more recent, numerous, and highly rated they are, the higher the product ranks. Passwork holds a 4.8 out of 5 stars overall rating, with individual scores of 4.7 for ease of use, 4.8 for design, and 5.0 for support.

See how Passwork keeps credentials secure within your own infrastructure. Start a free trial with full access.

Passwork wins Best Customer Support 2026 by Software Advice

We’re excited to share that Passwork’s customer support has been recognized as the best in the Password Managers category by Software Advice.

Passwork BlogAlex Muntyan

What are hardcoded secrets? Risks and prevention

Hardcoded secrets are credentials written directly into code instead of injected at runtime. They survive in Git history, CI/CD logs, and forks long after the “fix” commit. This guide covers how they spread, how to detect them, and how to eliminate them.

Passwork BlogAlex Muntyan

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

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

Tres cosas ocurrieron en abril de 2026 que no parecen estar conectadas — hasta que se ve el patrón.

APT28 secuestró 18.000 routers en 120 países y redirigió el tráfico de autenticación a través de un proxy adversario intermediario. Sin malware. Solo una advertencia de certificado TLS que la mayoría de los usuarios ignoraron. Credenciales de Microsoft 365 y tokens OAuth recopilados en el punto intermedio, MFA completamente eludido.

Un desarrollador en una startup de productividad con IA fue infectado por un infostealer común. El malware costó aproximadamente 200 dólares en un foro de la darknet. Extrajo un token OAuth almacenado en el navegador, lo entregó a los atacantes, y en cuestión de horas estaban dentro del entorno de producción de Vercel — enumerando claves API, credenciales de bases de datos y claves de firma.

ShinyHunters extrajo tokens de autenticación de un proveedor de análisis externo llamado Anodot y pasó el día monetizando el acceso a docenas de plataformas downstream. Vimeo. Zara. Clientes de Snowflake. Ninguna de las plataformas principales fue comprometida directamente. El ataque se ejecutó completamente a través de la capa de integración.

El hilo común: la brecha nunca comenzó donde terminó el daño. Cada atacante entró a través de un periférico — un proveedor, una integración, un dispositivo olvidado — y pivotó hacia el objetivo real desde allí.

Este resumen cubre los incidentes de credenciales y autenticación que definieron abril de 2026, las estadísticas que les dan contexto, y lo que colectivamente significan para cómo las organizaciones gestionan el acceso.

Conclusiones clave

• APT28 secuestró 18.000 routers en 120 países para robar tokens OAuth de Microsoft 365. La campaña FrostArmada no requirió malware y casi no dejó rastro visible — la configuración DNS fue sobrescrita silenciosamente para redirigir el tráfico de autenticación a través de un proxy adversario intermediario. MFA fue completamente eludido. El FBI desmanteló la infraestructura en abril de 2026.
• Storm-2372 eludió MFA a escala sin robar una sola contraseña. La campaña abusó del flujo OAuth Device Code, usando señuelos específicos por rol generados por IA para engañar a las víctimas y que autorizaran sesiones controladas por atacantes. El toolkit (EvilTokens) automatizó toda la operación de principio a fin.
• La brecha de Anodot expuso tokens almacenados de docenas de plataformas downstream. ShinyHunters extrajo tokens de autenticación de un proveedor de análisis externo y los usó para acceder a datos de clientes en Vimeo (119.000 usuarios) e Inditex/Zara (197.000 registros). Snowflake no fue comprometido — el ataque se ejecutó completamente a través de la capa de integración.
• Un infostealer común en el dispositivo de un desarrollador fue suficiente para vulnerar el entorno de producción de Vercel. Lumma Stealer comprometió Context.ai, un proveedor de IA periférico. El acceso OAuth heredado dio a los atacantes entrada directa a los sistemas de Vercel — sin zero-day, sin phishing al personal de Vercel requerido.
• Un paquete malicioso de Bitwarden CLI circuló vía npm durante 94 minutos. Los atacantes secuestraron una GitHub Action en el pipeline CI/CD e inyectaron un payload dirigido a secretos de desarrolladores, credenciales en la nube y configuraciones de herramientas de codificación con IA — con auto-propagación integrada a través de repositorios accesibles.
• El desarrollo asistido por IA llevó las filtraciones de secretos a un récord de 28,6 millones en 2025 — un aumento del 34% interanual. Las filtraciones de credenciales de servicios de IA crecieron un 81%. Los commits coautorados por herramientas de IA filtran secretos aproximadamente al doble de la tasa base. El 64% de los secretos expuestos en 2022 permanecían activos y explotables en 2026.
• Cada incidente importante de este mes siguió el mismo patrón. El objetivo principal nunca fue la víctima final — los atacantes se movieron a través de un proveedor periférico, un token almacenado o una dependencia comprometida para alcanzar el objetivo real. MFA no detuvo ninguna de las campañas de robo de credenciales. La superficie de ataque es la capa de integración, el pipeline CI/CD y la concesión OAuth.

APT28: campaña de secuestro DNS FrostArmada desarticulada por autoridades internacionales

Una operación policial internacional que involucró al FBI, el Departamento de Justicia de EE. UU. y el gobierno polaco, con soporte técnico de Microsoft y Black Lotus Labs, desmanteló FrostArmada: una campaña de APT28 que secuestró configuraciones DNS de routers para robar credenciales de Microsoft 365 y tokens OAuth. Activa desde mayo de 2025, la campaña infectó 18.000 dispositivos en 120 países en su pico en diciembre de 2025.

Qué ocurrió

APT28 (también rastreado como Fancy Bear, Forest Blizzard, Strontium y Storm-2754) — atribuido por el NCSC y el DoJ de EE. UU. a la unidad militar 26165 del GRU ruso — comprometió routers SOHO expuestos a internet explotando vulnerabilidades públicas conocidas. El objetivo principal fue el TP-Link WR841N vía CVE-2023-50224, que permitía a atacantes no autenticados extraer credenciales del router mediante una solicitud HTTP GET manipulada, y luego sobrescribir la configuración DHCP/DNS con una segunda solicitud.

La cadena de ataque funcionó de la siguiente manera:

1. El router es comprometido vía una vulnerabilidad conocida; la configuración DNS es sobrescrita para apuntar a nodos VPS controlados por el atacante
2. La nueva configuración DNS es automáticamente distribuida a todos los dispositivos internos vía DHCP — portátiles, teléfonos, todo en la red
3. Cuando un usuario consulta un dominio relacionado con autenticación, el servidor DNS malicioso devuelve la IP del atacante en lugar de la real
4. El usuario es redirigido a un proxy adversario intermediario (AitM)
5. El proxy pasa las solicitudes al servicio legítimo — mientras recopila silenciosamente contraseñas y tokens OAuth en el punto intermedio
6. La única advertencia visible para la víctima: un error de certificado TLS, fácilmente ignorado

El enfoque requirió mínima interacción del usuario final y casi no dejó rastro visible. Black Lotus Labs lo describió como «todo thriller, sin relleno de malware».

Cómo evolucionó la campaña

La actividad más temprana fue limitada y comenzó en mayo de 2025. El punto de inflexión llegó el 5 de agosto de 2025, cuando el NCSC publicó su informe Authentic Antics describiendo un conjunto de herramientas de Forest Blizzard para robar credenciales de Microsoft Office. Lumen detectó explotación generalizada de routers y redirección DNS comenzando el día siguiente (6 de agosto), confirmando una rápida adaptación de técnicas después de la exposición pública.

Este patrón es consistente con la historia más amplia de Forest Blizzard. El grupo ha evolucionado continuamente sus métodos de robo de credenciales desde al menos 2021: desde fuerza bruta con password spraying contra servicios de Microsoft, a recolección de hashes NTLM vía routers comprometidos, hasta infraestructura AitM completa. El grupo también es conocido por desplegar la herramienta basada en LLM «LAMEHUG» junto con técnicas más tradicionales.

Cómo se organizó la infraestructura

Black Lotus Labs identificó dos clústeres operacionales distintos:

• Equipo de expansión — enfocado en comprometer nuevos routers SOHO y hacer crecer la botnet a escala, apuntando a un gran conjunto de equipos de red vía interfaces web expuestas
• Clúster AitM — manejó la recopilación de credenciales y tokens; también realizó operaciones interactivas contra routers MikroTik específicos

El secuestro DNS fue oportunista por diseño: lanzar una red amplia, luego filtrar el tráfico interceptado para clasificar víctimas de probable valor de inteligencia en cada etapa de la cadena.

Objetivos y alcance

La campaña apuntó principalmente a agencias gubernamentales, ministerios de asuntos exteriores, cuerpos policiales, proveedores de TI y hosting, y organizaciones que ejecutan servidores de correo on-premise. Microsoft confirmó ataques AitM contra subdominios de Microsoft 365, incluyendo Outlook en la web. Black Lotus Labs y el NCSC también observaron ataques dirigidos a organizaciones gubernamentales en el norte de África, América Central y el sudeste asiático, incluyendo «una plataforma de identidad nacional en un país europeo».

El desmantelamiento

El FBI llevó a cabo una operación técnica autorizada por tribunal, restableciendo remotamente las configuraciones DNS en routers comprometidos para apuntar de nuevo a resolvers legítimos. La operación fue probada extensivamente en firmware TP-Link afectado para asegurar que no impactara la funcionalidad normal del router ni recopilara datos de usuarios.

Lumen bloqueó el tráfico hacia la infraestructura afectada y añadió indicadores de compromiso en Lumen Defender. Los routers pueden limpiarse completamente restaurando la configuración de fábrica. TP-Link confirmó el alcance en una declaración oficial:

«TP-Link ha realizado una revisión interna e identificado que múltiples productos legacy de TP-Link pueden estar afectados por esta vulnerabilidad. Excepto TL-WR940N v6 (EOS desde 2024), todos los productos afectados han alcanzado el estado de fin de vida (EOL) y ya no están dentro del ciclo de mantenimiento estándar de TP-Link.»

En la práctica, esto significa que no vendrán parches — el reemplazo es la única vía de remediación para el hardware afectado.

Qué hacer

Acciones prioritarias para equipos de red y seguridad:

• Reemplace cualquier router que ya no reciba actualizaciones de firmware — el hardware en fin de vida fue el punto de entrada principal
• Verifique la configuración del resolver DNS en su router y compárela con valores conocidos buenos de su ISP
• Implemente certificate pinning en dispositivos corporativos gestionados vía MDM — esto genera un error cuando un proxy AitM intenta inspeccionar el tráfico
• Revise las reglas del firewall para prevenir la exposición no deseada de interfaces de gestión remota
• Monitoree los logs de inicio de sesión de Microsoft Entra para patrones anómalos de uso de tokens OAuth

Phishing con IA de Storm-2372: evasión masiva de MFA vía Device Code

Microsoft documentó una campaña de phishing a gran escala por Storm-2372 que eludió MFA sin robar una sola contraseña. El ataque abusó del flujo de autenticación OAuth Device Code — un mecanismo legítimo diseñado para dispositivos que no pueden soportar inicios de sesión interactivos — para engañar a los usuarios y que autorizaran sesiones controladas por atacantes. La campaña fue impulsada por EvilTokens, un toolkit de phishing como servicio que automatizó toda la operación de principio a fin.

Cómo funcionó

El ataque se desarrolló en tres fases:

• Reconocimiento: 10–15 días antes del phishing, el grupo verificó la validez de las cuentas objetivo vía el endpoint GetCredentialType de Microsoft.
• Entrega: la IA generativa produjo correos señuelo hiperpersonalizados adaptados al rol de cada objetivo — RFPs para personal de compras, facturas para equipos de finanzas, notificaciones de flujo de trabajo de fabricación para operaciones. Las cadenas de redirección pasaron por Vercel, Cloudflare Workers y AWS Lambda para mezclarse con el tráfico empresarial legítimo.
• Captura de tokens: cuando una víctima hacía clic en el enlace, un script en segundo plano generaba un Device Code en vivo en tiempo real — evitando la ventana de expiración estándar de 15 minutos. La víctima completaba MFA en la página de inicio de sesión real de Microsoft, autorizando sin saberlo la sesión del atacante.

La actividad post-compromiso se centró en objetivos de alto valor: exfiltración de correo electrónico, reglas de bandeja de entrada maliciosas para persistencia, y reconocimiento de Microsoft Graph para mapear la estructura organizacional y los permisos.

Objetivos y alcance

La campaña apuntó a organizaciones en los sectores gubernamental, financiero, manufacturero y de TI. La actividad post-compromiso no fue indiscriminada: los actores de amenazas usaron enriquecimiento automatizado — cruzando referencias de perfiles públicos y directorios corporativos — para clasificar cuentas comprometidas y priorizar individuos en roles financieros o ejecutivos para una explotación más profunda.

Actividad post-compromiso

Una vez obtenidos los tokens, los atacantes se enfocaron en mantener el acceso y extraer datos. Esto incluyó exfiltración de correo electrónico, creación de reglas de bandeja de entrada maliciosas para redirigir u ocultar comunicaciones, y reconocimiento de Microsoft Graph para mapear la estructura organizacional y los permisos — permitiendo movimiento lateral mientras los tokens robados permanecieran válidos.

Qué hacer

• Deshabilite el flujo Device Code para usuarios y aplicaciones que no lo requieran vía políticas de Acceso Condicional
• Monitoree consultas anómalas al endpoint GetCredentialType y patrones inusuales de emisión de tokens
• Implemente políticas de vida útil de tokens y evaluación de acceso continuo para limitar las ventanas de validez de tokens robados
• Trate los señuelos personalizados por IA específicos por rol como un vector de amenaza documentado — la capacitación de concienciación genérica es insuficiente

Filtración de tokens de Anodot: Vimeo, Zara y docenas más afectados en la campaña de ShinyHunters

Más de una docena de empresas sufrieron robo de datos después de que tokens de autenticación fueran robados de Anodot, un proveedor de análisis basado en IA adquirido por Glassbox en noviembre de 2025. La mayoría de los ataques apuntaron a entornos de clientes de Snowflake. Entre las víctimas confirmadas: Vimeo (119.000 usuarios afectados) y la empresa matriz de Zara, Inditex (197.000 registros expuestos). La plataforma Snowflake en sí no fue vulnerada — el ataque se ejecutó completamente a través de la capa de integración de terceros.

Qué ocurrió

Anodot proporciona detección de anomalías en tiempo real para datos comerciales y operacionales, integrándose directamente con Snowflake, S3, Amazon Kinesis y otras plataformas. Para funcionar, almacena tokens de autenticación en nombre de sus clientes. Cuando el entorno de Anodot fue vulnerado, esos tokens almacenados dieron a los atacantes acceso directo a los datos de clientes downstream — no se requirió ninguna vulnerabilidad en Snowflake en sí.

El grupo de extorsión ShinyHunters se atribuyó la responsabilidad, diciendo a BleepingComputer que robaron datos de docenas de empresas en un solo viernes usando tokens recolectados de Anodot. El grupo también insinuó que podrían haber tenido acceso a Anodot durante algún tiempo antes de actuar. ShinyHunters posteriormente intentó usar los mismos tokens robados contra cuentas de clientes de Salesforce — pero fue detectado y bloqueado por detección basada en IA antes de tener éxito.

Snowflake respondió bloqueando cuentas de clientes potencialmente impactadas y notificando a las organizaciones afectadas. La página de estado de Anodot mostró todos los conectores caídos en todas las regiones geográficas desde el fin de semana del incidente. Ni Anodot ni su empresa matriz Glassbox respondieron a las consultas de prensa al momento de la publicación.

Víctimas confirmadas

Vimeo confirmó que la brecha de Anodot expuso datos de usuarios y clientes — principalmente datos técnicos, títulos de videos, metadatos, y en algunos casos direcciones de correo electrónico. En su divulgación oficial, Vimeo declaró:

«Los datos accedidos no incluyen contenido de video de Vimeo, credenciales de inicio de sesión de usuario válidas, ni información de tarjetas de pago. Las credenciales de inicio de sesión de usuarios y clientes de Vimeo están seguras. Al enterarnos del incidente, deshabilitamos rápidamente todas las credenciales de Anodot, eliminamos la integración de Anodot con los sistemas de Vimeo, y contratamos expertos en seguridad externos para asistir con la investigación.»

Según Have I Been Pwned, 119.200 direcciones de correo electrónico únicas fueron expuestas, a veces acompañadas de nombres. ShinyHunters publicó cientos de gigabytes de datos de Vimeo después de listar a la empresa en su portal de extorsión «paga o filtramos».

Zara (Inditex) también fue listada por ShinyHunters como parte de la misma campaña. El grupo publicó lo que afirmó ser un terabyte de datos, supuestamente incluyendo 95 millones de registros de tickets de soporte. Have I Been Pwned registró 197.400 direcciones de correo electrónico únicas en la brecha, junto con SKUs de productos, IDs de pedidos y datos de mercado geográfico. Inditex confirmó el incidente pero declaró que no afectó contraseñas ni información de pago.

Por qué importa

Este incidente es un riesgo estructural, no un evento aislado. Las integraciones SaaS-a-SaaS rutinariamente involucran delegación de credenciales: un servicio se autentica en nombre de otro, almacenando tokens de larga duración con amplios permisos. Esa autorización se otorga una vez y raramente se revisa. Cuando el servicio delegado es comprometido, cada conexión downstream que mantiene se convierte en un vector de ataque — y la plataforma principal no tiene visibilidad ni control sobre la brecha.

El playbook de ShinyHunters es consistente: identificar un servicio de integración periférico, comprometerlo, extraer tokens almacenados y monetizar el acceso a través de extorsión antes de que las víctimas puedan responder.

Qué hacer

• Mantenga un inventario actualizado de todas las integraciones SaaS de terceros y las credenciales que mantienen en su nombre
• Aplique alcance de mínimo privilegio a todas las concesiones OAuth y tokens API emitidos a servicios externos
• Establezca políticas de expiración de tokens — evite tokens de larga duración indefinida para integraciones de terceros
• Realice revisiones periódicas de acceso y revoque autorizaciones para servicios que ya no estén en uso activo
• Trate la postura de seguridad del proveedor de integración como parte de su proceso de evaluación de riesgo de proveedores

Las integraciones de terceros no revisadas y los tokens de larga duración son un riesgo estructural, no un caso extremo. Passwork proporciona a los equipos de seguridad un inventario centralizado de credenciales con acceso basado en roles y un registro de auditoría completo — para que nada persista sin ser notado. Vea cómo funciona

Vercel: ataque a la cadena de suministro vía OAuth y Lumma Stealer

Un empleado de Vercel usó Context.ai — una herramienta de productividad con IA de terceros — conectada a su cuenta corporativa de Google Workspace vía OAuth. Cuando Context.ai fue comprometido, los atacantes heredaron ese acceso OAuth, tomaron control de la cuenta de Vercel del empleado y pivotaron hacia los sistemas de producción.

Variables de entorno no sensibles — claves API, tokens, credenciales de bases de datos, claves de firma — fueron enumeradas y descifradas. Vercel contrató a Google Mandiant para la investigación forense y describió a los atacantes como «altamente sofisticados basándose en su velocidad operacional y profundo entendimiento de la superficie API del producto de Vercel».

Qué ocurrió

Trend Micro identificó a Lumma Stealer como el infostealer usado en el compromiso inicial de Context.ai. Lumma es una herramienta de malware como servicio común que extrae credenciales almacenadas en navegadores, cookies de sesión y tokens de autenticación de máquinas infectadas. Un dispositivo de desarrollador infectado en un pequeño proveedor de IA se convirtió en el punto de entrada para una brecha de datos de 2 millones de dólares en una importante plataforma en la nube.

Vercel confirmó que las variables de entorno secretas — aquellas explícitamente marcadas como sensibles — estaban almacenadas cifradas y no fueron comprometidas. Las variables no secretas fueron expuestas. La empresa describió a los atacantes como «altamente organizados» y contrató a Mandiant para la investigación forense.

«Hemos identificado un incidente de seguridad que involucró acceso no autorizado a ciertos sistemas internos de Vercel. Estamos investigando activamente y hemos contratado expertos en respuesta a incidentes para ayudar a investigar y remediar.» — Declaración oficial de Vercel

Por qué importa

Las concesiones OAuth son fáciles de crear y raramente se revisan. Cuando un empleado conecta una herramienta de terceros a una cuenta corporativa, típicamente otorga amplios permisos con un solo clic — y esa autorización persiste indefinidamente a menos que se revoque explícitamente. Cada aplicación conectada es un punto de pivote potencial si esa aplicación es alguna vez comprometida.

La cadena de ataque aquí no requirió ningún zero-day, ningún phishing directo a un empleado de Vercel, y ninguna vulnerabilidad en el código propio de Vercel. Un infostealer común en la máquina de un desarrollador en un proveedor periférico fue suficiente.

Qué hacer

• Audite todas las aplicaciones OAuth conectadas a cuentas corporativas de Google Workspace y Microsoft 365
• Aplique políticas que restrinjan qué aplicaciones de terceros pueden autorizar los empleados
• Marque todas las variables de entorno sensibles explícitamente — y trate las variables no marcadas como potencialmente expuestas
• Despliegue detección de endpoints capaz de identificar actividad de infostealers antes de que ocurra la exfiltración de credenciales
• Rote todas las variables de entorno no sensibles como precaución si la aplicación OAuth de Context.ai estaba presente en su entorno

Bitwarden CLI comprometido en el ataque a la cadena de suministro de Checkmarx

22 de abril de 2026. El paquete Bitwarden CLI @bitwarden/cli@2026.4.0 fue distribuido con código malicioso durante 94 minutos — entre las 5:57 PM y las 7:30 PM ET — vía una GitHub Action secuestrada en el pipeline CI/CD de Bitwarden. El compromiso es parte de la campaña más amplia de cadena de suministro de Checkmarx, atribuida al actor de amenazas TeamPCP. Bitwarden confirmó el incidente y declaró que no se accedió a datos de bóvedas de usuarios finales.

Qué hizo el código malicioso

El código inyectado se ejecutó vía un hook de preinstalación y apuntó a credenciales en múltiples superficies: archivos de entorno locales e historial de shell, secretos de GitHub Actions, credenciales de pipelines CI/CD, archivos de configuración para herramientas de codificación con IA (Claude, Cursor, Codex CLI, Aider, Kiro) y tokens npm. Los datos robados fueron cifrados con AES-256-GCM y exfiltrados a audit.checkmarx[.]cx — un dominio que suplantaba a Checkmarx — con un repositorio de GitHub como respaldo.

Si se encontraban tokens de GitHub, el malware inyectaba flujos de trabajo de Actions maliciosos en cada repositorio accesible y usaba credenciales npm recolectadas para publicar más versiones de paquetes maliciosos downstream. Endor Labs lo describió como uno de los «payloads de cadena de suministro npm más capaces» publicados hasta la fecha.

Qué hacer

• Fije todas las dependencias CI/CD — GitHub Actions, paquetes npm, imágenes Docker — a hashes de commit específicos verificados
• Implemente verificación de integridad de dependencias (checksums, firmas Sigstore) antes de la instalación
• Restrinja los permisos del pipeline CI/CD al alcance mínimo requerido
• Si el paquete fue instalado durante la ventana afectada, rote todos los secretos accesibles desde ese entorno inmediatamente

GitGuardian: los agentes de IA llevaron a la filtración de 29 millones de secretos

El informe State of Secrets Sprawl 2026 de GitGuardian encontró 28.649.024 nuevos secretos expuestos en repositorios públicos de GitHub en 2025 — un aumento del 34% interanual y el mayor salto anual en la historia del informe. El principal impulsor: el desarrollo asistido por IA.

Por qué la IA empeora esto

Los asistentes de IA aceleran el desarrollo hasta el punto en que el código parece listo para producción — y se hace commit — antes de que nadie haya decidido dónde deben vivir las credenciales. Los commits coautorados por Claude Code filtran secretos aproximadamente al doble de la tasa base en GitHub público. Una superficie de riesgo separada emergió con los archivos de configuración MCP: GitGuardian encontró 24.008 secretos únicos expuestos en configuraciones de Model Context Protocol en 2025.

Cifras clave

Una vez que un secreto es cometido a un repositorio público, es efectivamente público — independientemente de si luego se elimina. Los escáneres automatizados recolectan secretos recién cometidos en minutos después de la publicación.

Qué hacer

• Implemente hooks pre-commit y escaneo de secretos CI/CD para capturar credenciales antes de que lleguen a los repositorios
• Aplique herramientas dedicadas de gestión de secretos (HashiCorp Vault, AWS Secrets Manager) como el único mecanismo de almacenamiento de credenciales permitido
• Rote cualquier credencial que alguna vez haya aparecido en un repositorio público, independientemente de cuán brevemente
• Establezca políticas de gobernanza de credenciales específicamente para integraciones de agentes de IA — trate las identidades de agentes como objetos de gestión de acceso de primera clase

Qué tienen en común los incidentes de abril

Tres patrones se repiten en cada incidente de este mes:

• El objetivo principal raramente fue la víctima final — los atacantes se movieron a través de un proveedor periférico, una aplicación OAuth de terceros o una dependencia CI/CD comprometida para alcanzar el objetivo real.
• MFA proporcionó menos protección de lo asumido — tanto la campaña Device Code como las cadenas de robo de tokens OAuth lo eludieron completamente sin tocar una contraseña.
• La IA aceleró la velocidad del atacante en ambos lados — la IA generativa personalizó el phishing a escala mientras el desarrollo asistido por IA creó un volumen récord de credenciales expuestas.

Abril de 2026 en números: el mes en ciberseguridad

Abril de 2026 continuó la trayectoria establecida a principios de año — más incidentes, mayor impacto, y cadenas de ataque que cada vez más evaden los controles tradicionales. El ransomware, el robo de credenciales y el compromiso de la cadena de suministro dominaron el panorama de amenazas en todos los sectores.

Volumen de brechas y ataques

Exposición de credenciales y secretos

Técnicas de ataque en foco

Conclusión

Abril de 2026 confirmó un cambio que se ha estado gestando durante años: la capa de autenticación es la superficie de ataque principal, y los tokens de sesión son el objetivo principal.

APT28 secuestró 18.000 routers para interceptar tokens OAuth sin tocar jamás una contraseña. Storm-2372 eludió MFA a escala usando un flujo de autenticación legítimo. ShinyHunters extrajo tokens almacenados de un proveedor de análisis externo y monetizó el acceso a través de docenas de plataformas downstream — ninguna de las cuales fue comprometida directamente. Un infostealer común en la máquina de un solo desarrollador en un proveedor periférico fue suficiente para alcanzar el entorno de producción de Vercel.

Los 28,6 millones de secretos expuestos en GitHub, las campañas de robo de tokens ejecutadas por APT28 y Storm-2372, y la brecha de Anodot que afectó a docenas de plataformas downstream apuntan a la misma brecha estructural: la gestión de acceso construida para un entorno más simple no está siguiendo el ritmo de cómo las organizaciones realmente operan hoy.

Proteger credenciales ahora significa gobernar todo el ciclo de vida — emisión, rotación, delegación y revocación — a través de usuarios humanos, cuentas de servicio, claves API e identidades de agentes de IA. El shadow IT, las concesiones OAuth no revisadas y los secretos codificados en pipelines CI/CD son la superficie de ataque. El perímetro no lo es.

Los incidentes en este resumen comparten una brecha estructural: credenciales y tokens que existían fuera de la gobernanza — no revisados, no rotados, no revocados. Passwork proporciona una bóveda autoalojada con control de acceso basado en roles, permisos estructurados y un registro de auditoría completo. Pruebe Passwork en su infraestructura

Preguntas frecuentes

¿Cuál fue la amenaza de ciberseguridad más significativa en abril de 2026?

La campaña FrostArmada de APT28 fue el incidente operacionalmente más significativo del mes. Al secuestrar la configuración DNS en más de 18.000 routers SOHO sin parchar en 120 países, el grupo vinculado al GRU ruso interceptó silenciosamente credenciales de Microsoft 365 y tokens OAuth de agencias gubernamentales, cuerpos policiales y proveedores de TI — eludiendo MFA sin desplegar malware ni hacer phishing directo a usuarios individuales.

¿Cómo elude el robo de tokens OAuth a MFA?

Los tokens OAuth se emiten después de que un usuario ya ha completado la autenticación — incluyendo cualquier paso de MFA. Robar el token significa heredar una sesión completamente autenticada. MFA protege el proceso de inicio de sesión; no protege el token que resulta de él. Los atacantes que interceptan o roban tokens se saltan el proceso de inicio de sesión por completo, haciendo que MFA sea irrelevante en esa etapa.

¿Qué es la técnica de phishing Device Code usada por Storm-2372?

El phishing Device Code abusa de un flujo OAuth legítimo diseñado para dispositivos con entrada limitada. Los atacantes inician el flujo, luego entregan el código resultante a las víctimas vía correos de phishing personalizados con IA. Cuando la víctima ingresa el código en la página de autenticación real de Microsoft, sin saberlo autoriza la sesión del atacante — emitiendo un token de acceso válido sin exponer su contraseña ni activar ningún desafío MFA. El token es legítimo porque el usuario completó la autenticación él mismo.

¿Por qué fue significativo el ataque a la cadena de suministro de Bitwarden CLI?

Demostró que las herramientas de seguridad llevan el mismo riesgo de cadena de suministro que cualquier otra dependencia de software. Una versión maliciosa de Bitwarden CLI fue distribuida vía npm durante 94 minutos después de que los atacantes secuestraran una GitHub Action en el pipeline CI/CD. El código inyectado apuntó a secretos de desarrolladores, credenciales en la nube y tokens de pipelines — y fue construido para auto-propagarse a cada repositorio que el token de GitHub de la víctima pudiera alcanzar.

¿Qué es la dispersión de credenciales y por qué se está acelerando?

La dispersión de credenciales se refiere a la proliferación descontrolada de secretos — claves API, tokens, contraseñas, certificados — a través de repositorios, archivos de configuración, herramientas de colaboración y pipelines CI/CD. El informe State of Secrets Sprawl 2026 de GitGuardian encontró 28,6 millones de nuevos secretos expuestos en repositorios públicos de GitHub en 2025, un aumento del 34% interanual impulsado en gran parte por el desarrollo asistido por IA. El código llega a producción más rápido de lo que las políticas de gobernanza de credenciales pueden seguir el ritmo — y el 64% de los secretos expuestos en 2022 permanecían activos y explotables en 2026.

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 deslizarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 prueban 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,8M 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

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

Una contraseña olvidada cuesta 70 dólares. Una brecha cuesta 4,44 millones de dólares. 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

Im April 2026 geschahen drei Dinge, die zunächst unzusammenhängend erscheinen — bis man das Muster erkennt.

APT28 kaperte 18.000 Router in 120 Ländern und leitete Authentifizierungsverkehr über einen Adversary-in-the-Middle-Proxy um. Keine Malware. Nur eine TLS-Zertifikatswarnung, die die meisten Benutzer ignorierten. Microsoft 365-Zugangsdaten und OAuth-Tokens wurden am Mittelpunkt abgegriffen, MFA wurde vollständig umgangen.

Ein Entwickler bei einem KI-Produktivitäts-Startup wurde von einem handelsüblichen Infostealer infiziert. Die Malware kostete etwa 200 $ in einem Darknet-Forum. Sie extrahierte ein im Browser gespeichertes OAuth-Token, übergab es den Angreifern, und innerhalb weniger Stunden befanden sie sich in Vercels Produktionsumgebung — wo sie API-Keys, Datenbank-Zugangsdaten und Signaturschlüssel auflisteten.

ShinyHunters erbeutete Authentifizierungstokens von einem Drittanbieter für Analysen namens Anodot und verbrachte den Tag damit, den Zugang zu Dutzenden von nachgelagerten Plattformen zu monetarisieren. Vimeo. Zara. Snowflake-Kunden. Keine der primären Plattformen wurde direkt kompromittiert. Der Angriff lief vollständig über die Integrationsschicht.

Der gemeinsame Nenner: Der Angriff begann nie dort, wo der Schaden entstand. Jeder Angreifer drang über eine Peripherie ein — einen Anbieter, eine Integration, ein vergessenes Gerät — und bewegte sich von dort zum eigentlichen Ziel.

Dieser Digest behandelt die Zugangsdaten- und Authentifizierungsvorfälle, die den April 2026 prägten, die Statistiken, die ihnen Kontext geben, und was sie gemeinsam für das Zugriffsmanagement in Organisationen bedeuten.

Wichtigste Erkenntnisse

• APT28 kaperte 18.000 Router in 120 Ländern, um Microsoft 365 OAuth-Tokens zu stehlen. Die FrostArmada-Kampagne erforderte keine Malware und hinterließ kaum sichtbare Spuren — DNS-Einstellungen wurden stillschweigend überschrieben, um Authentifizierungsverkehr über einen Adversary-in-the-Middle-Proxy umzuleiten. MFA wurde vollständig umgangen. Das FBI zerschlug die Infrastruktur im April 2026.
• Storm-2372 umging MFA im großen Stil, ohne ein einziges Passwort zu stehlen. Die Kampagne missbrauchte den OAuth Device Code-Flow und nutzte KI-generierte rollenspezifische Köder, um Opfer dazu zu bringen, von Angreifern kontrollierte Sitzungen zu autorisieren. Das Toolkit (EvilTokens) automatisierte den gesamten Vorgang von Anfang bis Ende.
• Der Anodot-Vorfall legte gespeicherte Tokens für Dutzende nachgelagerter Plattformen offen. ShinyHunters extrahierte Authentifizierungstokens von einem Drittanbieter für Analysen und nutzte sie, um auf Kundendaten bei Vimeo (119.000 Benutzer) und Zara/Inditex (197.000 Datensätze) zuzugreifen. Snowflake wurde nicht kompromittiert — der Angriff lief vollständig über die Integrationsschicht.
• Ein handelsüblicher Infostealer auf dem Gerät eines einzigen Entwicklers reichte aus, um in Vercels Produktionsumgebung einzudringen. Lumma Stealer kompromittierte Context.ai, einen peripheren KI-Anbieter. Geerbter OAuth-Zugriff verschaffte Angreifern direkten Zugang zu Vercel-Systemen — kein Zero-Day, kein Phishing von Vercel-Mitarbeitern erforderlich.
• Ein bösartiges Bitwarden CLI-Paket zirkulierte 94 Minuten lang über npm. Angreifer kaperten eine GitHub Action in der CI/CD-Pipeline und injizierten eine Payload, die auf Entwickler-Secrets, Cloud-Zugangsdaten und KI-Coding-Tool-Konfigurationen abzielte — mit eingebauter Selbstverbreitung über erreichbare Repositories.
• KI-unterstützte Entwicklung führte zu einem Rekord von 28,6 Millionen geleakten Secrets im Jahr 2025 — ein Anstieg von 34 % im Jahresvergleich. Leaks von KI-Service-Zugangsdaten wuchsen um 81 %. Commits, die mit KI-Tools erstellt wurden, leaken Secrets mit etwa der doppelten Basisrate. 64 % der 2022 exponierten Secrets waren 2026 noch aktiv und ausnutzbar.
• Jeder größere Vorfall in diesem Monat folgte demselben Muster. Das primäre Ziel war nie das endgültige Opfer — Angreifer bewegten sich über einen peripheren Anbieter, ein gespeichertes Token oder eine kompromittierte Abhängigkeit zum eigentlichen Ziel. MFA stoppte keine der Zugangsdatendiebstahl-Kampagnen. Die Angriffsfläche ist die Integrationsschicht, die CI/CD-Pipeline und der OAuth-Grant.

APT28: DNS-Hijacking-Kampagne FrostArmada von internationalen Behörden zerschlagen

Eine internationale Strafverfolgungsoperation unter Beteiligung des FBI, des US-Justizministeriums und der polnischen Regierung, mit technischer Unterstützung von Microsoft und Black Lotus Labs, zerschlug FrostArmada: eine APT28-Kampagne, die Router-DNS-Einstellungen kaperte, um Microsoft 365-Zugangsdaten und OAuth-Tokens zu stehlen. Aktiv seit Mai 2025, infizierte die Kampagne auf ihrem Höhepunkt im Dezember 2025 18.000 Geräte in 120 Ländern.

Was geschah

APT28 (auch bekannt als Fancy Bear, Forest Blizzard, Strontium und Storm-2754) — vom NCSC und dem US-Justizministerium der russischen GRU-Militäreinheit 26165 zugeschrieben — kompromittierte internetexponierte SOHO-Router durch Ausnutzung bekannter öffentlicher Schwachstellen. Das primäre Ziel war der TP-Link WR841N über CVE-2023-50224, das es nicht authentifizierten Angreifern ermöglichte, Router-Zugangsdaten über eine manipulierte HTTP-GET-Anfrage zu extrahieren und dann DHCP/DNS-Einstellungen mit einer zweiten Anfrage zu überschreiben.

Die Angriffskette funktionierte wie folgt:

1. Router wird über eine bekannte Schwachstelle kompromittiert; DNS-Einstellungen werden überschrieben, um auf von Angreifern kontrollierte VPS-Knoten zu verweisen
2. Neue DNS-Konfiguration wird automatisch über DHCP an alle internen Geräte verteilt — Laptops, Telefone, alles im Netzwerk
3. Wenn ein Benutzer eine authentifizierungsbezogene Domain abfragt, gibt der bösartige DNS-Server die IP des Angreifers statt der echten zurück
4. Benutzer wird zu einem Adversary-in-the-Middle (AitM)-Proxy umgeleitet
5. Der Proxy leitet Anfragen an den legitimen Dienst weiter — während er stillschweigend Passwörter und OAuth-Tokens am Mittelpunkt sammelt
6. Die einzige sichtbare Warnung für das Opfer: ein TLS-Zertifikatsfehler, der leicht ignoriert werden kann

Der Ansatz erforderte minimale Endbenutzer-Interaktion und hinterließ fast keine sichtbare Spur. Black Lotus Labs beschrieb es als „all thriller, no malware filler".

Wie sich die Kampagne entwickelte

Die früheste Aktivität war begrenzt und begann im Mai 2025. Der Wendepunkt kam am 5. August 2025, als das NCSC seinen Authentic Antics-Bericht veröffentlichte, der ein Forest Blizzard-Toolset zum Stehlen von Microsoft Office-Zugangsdaten beschrieb. Lumen erkannte ab dem nächsten Tag (6. August) weit verbreitete Router-Ausnutzung und DNS-Umleitung, was eine schnelle Anpassung der Taktiken nach der öffentlichen Enthüllung bestätigte.

Dieses Muster ist konsistent mit der breiteren Geschichte von Forest Blizzard. Die Gruppe hat ihre Methoden zum Diebstahl von Zugangsdaten seit mindestens 2021 kontinuierlich weiterentwickelt: von Brute-Force-Passwort-Spraying gegen Microsoft-Dienste über NTLM-Hash-Harvesting über kompromittierte Router bis hin zu vollständiger AitM-Infrastruktur. Die Gruppe ist auch dafür bekannt, das LLM-basierte Tool „LAMEHUG" neben traditionelleren Techniken einzusetzen.

Wie die Infrastruktur organisiert war

Black Lotus Labs identifizierte zwei unterschiedliche operative Cluster:

• Expansionsteam — konzentrierte sich auf die Kompromittierung neuer SOHO-Router und das Wachstum des Botnets im großen Maßstab, wobei ein großer Pool von Netzwerkgeräten über exponierte Weboberflächen anvisiert wurde
• AitM-Cluster — übernahm die Sammlung von Zugangsdaten und Tokens; führte auch interaktive Operationen gegen bestimmte MikroTik-Router durch

Das DNS-Hijacking war von vornherein opportunistisch angelegt: ein weites Netz auswerfen und dann den abgefangenen Verkehr filtern, um Opfer von wahrscheinlichem Geheimdienstwert in jeder Phase der Kette zu priorisieren.

Ziele und Umfang

Die Kampagne zielte hauptsächlich auf Regierungsbehörden, Außenministerien, Strafverfolgungsbehörden, IT- und Hosting-Anbieter sowie Organisationen mit On-Premise-E-Mail-Servern. Microsoft bestätigte AitM-Angriffe gegen Microsoft 365-Subdomains, einschließlich Outlook im Web. Black Lotus Labs und das NCSC beobachteten auch Angriffe auf Regierungsorganisationen in Nordafrika, Zentralamerika und Südostasien, darunter „eine nationale Identitätsplattform in einem europäischen Land".

Die Zerschlagung

Das FBI führte eine gerichtlich genehmigte technische Operation durch und setzte die DNS-Konfigurationen auf kompromittierten Routern aus der Ferne zurück, um wieder auf legitime Resolver zu verweisen. Die Operation wurde ausgiebig auf betroffener TP-Link-Firmware getestet, um sicherzustellen, dass sie die normale Router-Funktionalität nicht beeinträchtigt oder Benutzerdaten sammelt.

Lumen blockierte den Verkehr zur betroffenen Infrastruktur und fügte Kompromittierungsindikatoren in Lumen Defender hinzu. Router können durch Wiederherstellen der Werkseinstellungen vollständig bereinigt werden. TP-Link bestätigte den Umfang in einer offiziellen Erklärung:

„TP-Link hat eine interne Überprüfung durchgeführt und festgestellt, dass mehrere ältere TP-Link-Produkte von dieser Schwachstelle betroffen sein können. Mit Ausnahme des TL-WR940N v6 (EOS seit 2024) haben alle betroffenen Produkte den End-of-Life (EOL)-Status erreicht und befinden sich nicht mehr im Standard-Wartungslebenszyklus von TP-Link."

In der Praxis bedeutet dies, dass keine Patches kommen werden — der Austausch ist der einzige Behebungsweg für betroffene Hardware.

Was zu tun ist

Prioritätsmaßnahmen für Netzwerk- und Sicherheitsteams:

• Ersetzen Sie alle Router, die keine Firmware-Updates mehr erhalten — End-of-Life-Hardware war der primäre Einstiegspunkt
• Überprüfen Sie die DNS-Resolver-Einstellungen in Ihrer Router-Konfiguration und gleichen Sie diese mit bekannten guten Werten Ihres ISP ab
• Implementieren Sie Certificate Pinning auf Unternehmensgeräten, die über MDM verwaltet werden — dies erzeugt einen Fehler, wenn ein AitM-Proxy versucht, den Verkehr zu inspizieren
• Überprüfen Sie Firewall-Regeln, um eine ungewollte Exposition von Remote-Management-Schnittstellen zu verhindern
• Überwachen Sie Microsoft Entra-Anmeldeprotokolle auf anomale OAuth-Token-Nutzungsmuster

Storm-2372 KI-Phishing: Massiver MFA-Bypass über Device Code

Microsoft dokumentierte eine groß angelegte Phishing-Kampagne von Storm-2372, die MFA umging, ohne ein einziges Passwort zu stehlen. Der Angriff missbrauchte den OAuth Device Code-Authentifizierungsflow — einen legitimen Mechanismus, der für Geräte entwickelt wurde, die keine interaktiven Logins unterstützen können — um Benutzer dazu zu verleiten, von Angreifern kontrollierte Sitzungen zu autorisieren. Die Kampagne wurde von EvilTokens angetrieben, einem Phishing-as-a-Service-Toolkit, das den gesamten Vorgang von Anfang bis Ende automatisierte.

Wie es funktionierte

Der Angriff entfaltete sich in drei Phasen:

• Aufklärung: 10–15 Tage vor dem Phishing überprüfte die Gruppe die Gültigkeit der Zielkonten über Microsofts GetCredentialType-Endpunkt.
• Zustellung: Generative KI produzierte hyperpersonalisierte Köder-E-Mails, die auf die Rolle jedes Ziels zugeschnitten waren — Ausschreibungen für Beschaffungsmitarbeiter, Rechnungen für Finanzteams, Fertigungs-Workflow-Benachrichtigungen für den Betrieb. Umleitungsketten liefen über Vercel, Cloudflare Workers und AWS Lambda, um sich mit legitimem Unternehmensverkehr zu vermischen.
• Token-Erfassung: Wenn ein Opfer auf den Link klickte, generierte ein Hintergrundskript in Echtzeit einen Live-Device-Code — unter Umgehung des standardmäßigen 15-Minuten-Ablaufzeitfensters. Das Opfer schloss MFA auf Microsofts echter Login-Seite ab und autorisierte dabei unwissentlich die Sitzung des Angreifers.

Post-Kompromittierungs-Aktivitäten konzentrierten sich auf hochwertige Ziele: E-Mail-Exfiltration, bösartige Posteingangsregeln zur Persistenz und Microsoft Graph-Aufklärung zur Kartierung der Organisationsstruktur und Berechtigungen.

Ziele und Umfang

Die Kampagne zielte auf Organisationen in den Bereichen Regierung, Finanzen, Fertigung und IT. Post-Kompromittierungs-Aktivitäten waren nicht wahllos: Bedrohungsakteure nutzten automatisierte Anreicherung — Querverweise mit öffentlichen Profilen und Unternehmensverzeichnissen — um kompromittierte Konten zu triagieren und Personen in Finanz- oder Führungspositionen für tiefere Ausnutzung zu priorisieren.

Post-Kompromittierungs-Aktivität

Sobald Tokens erlangt wurden, konzentrierten sich Angreifer auf die Aufrechterhaltung des Zugangs und die Datenextraktion. Dies umfasste E-Mail-Exfiltration, die Erstellung bösartiger Posteingangsregeln zur Umleitung oder Verschleierung von Kommunikation und Microsoft Graph-Aufklärung zur Kartierung der Organisationsstruktur und Berechtigungen — was laterale Bewegung ermöglichte, solange die gestohlenen Tokens gültig blieben.

Was zu tun ist

• Deaktivieren Sie den Device Code-Flow für Benutzer und Anwendungen, die ihn nicht benötigen, über Conditional Access-Richtlinien
• Überwachen Sie anomale GetCredentialType-Endpunktabfragen und ungewöhnliche Token-Ausstellungsmuster
• Implementieren Sie Token-Lebensdauerrichtlinien und kontinuierliche Zugriffsbewertung, um die Gültigkeitszeitfenster gestohlener Tokens zu begrenzen
• Behandeln Sie rollenspezifische KI-personalisierte Köder als dokumentierten Bedrohungsvektor — allgemeine Awareness-Schulungen reichen nicht aus

Anodot-Token-Leak: Vimeo, Zara und Dutzende weitere von ShinyHunters-Kampagne betroffen

Über ein Dutzend Unternehmen erlitten Datendiebstahl, nachdem Authentifizierungstokens von Anodot gestohlen wurden, einem KI-basierten Analyseanbieter, der im November 2025 von Glassbox übernommen wurde. Die Mehrheit der Angriffe zielte auf Snowflake-Kundenumgebungen. Unter den bestätigten Opfern: Vimeo (119.000 betroffene Benutzer) und Zaras Mutterkonzern Inditex (197.000 exponierte Datensätze). Die Snowflake-Plattform selbst wurde nicht kompromittiert — der Angriff lief vollständig über die Drittanbieter-Integrationsschicht.

Was geschah

Anodot bietet Echtzeit-Anomalieerkennung für Geschäfts- und Betriebsdaten und integriert sich direkt mit Snowflake, S3, Amazon Kinesis und anderen Plattformen. Um zu funktionieren, speichert es Authentifizierungstokens im Namen seiner Kunden. Als Anodots Umgebung kompromittiert wurde, verschafften diese gespeicherten Tokens Angreifern direkten Zugang zu nachgelagerten Kundendaten — keine Schwachstelle in Snowflake selbst war erforderlich.

Die ShinyHunters-Erpressergruppe bekannte sich zur Verantwortung und erklärte BleepingComputer, dass sie an einem einzigen Freitag Daten von Dutzenden von Unternehmen gestohlen haben, indem sie von Anodot erbeutete Tokens verwendeten. Die Gruppe deutete auch an, dass sie möglicherweise eine Zeit lang Zugang zu Anodot gehabt hatten, bevor sie handelten. ShinyHunters versuchte anschließend, dieselben gestohlenen Tokens gegen Salesforce-Kundenkonten zu verwenden — wurde jedoch durch KI-basierte Erkennung erkannt und blockiert, bevor sie Erfolg hatten.

Snowflake reagierte, indem es potenziell betroffene Kundenkonten sperrte und betroffene Organisationen benachrichtigte. Anodots Statusseite zeigte alle Konnektoren in allen geografischen Regionen ab dem Wochenende des Vorfalls als ausgefallen an. Weder Anodot noch seine Muttergesellschaft Glassbox reagierten zum Zeitpunkt der Veröffentlichung auf Presseanfragen.

Bestätigte Opfer

Vimeo bestätigte, dass der Anodot-Vorfall Benutzer- und Kundendaten exponierte — hauptsächlich technische Daten, Videotitel, Metadaten und in einigen Fällen E-Mail-Adressen. In seiner offiziellen Offenlegung erklärte Vimeo:

„Die abgerufenen Daten enthalten keine Vimeo-Videoinhalte, gültige Benutzeranmeldedaten oder Zahlungskarteninformationen. Vimeo-Benutzer- und Kundenanmeldedaten sind sicher. Nach Bekanntwerden des Vorfalls haben wir umgehend alle Anodot-Anmeldedaten deaktiviert, die Anodot-Integration mit Vimeo-Systemen entfernt und externe Sicherheitsexperten zur Unterstützung bei der Untersuchung beauftragt."

Laut Have I Been Pwned wurden 119.200 einzigartige E-Mail-Adressen exponiert, manchmal begleitet von Namen. ShinyHunters veröffentlichte Hunderte von Gigabytes an Vimeo-Daten, nachdem sie das Unternehmen auf ihrem „Zahlen-oder-Leak"-Erpressungsportal gelistet hatten.

Zara (Inditex) wurde ebenfalls von ShinyHunters als Teil derselben Kampagne gelistet. Die Gruppe veröffentlichte, was sie als ein Terabyte an Daten bezeichnete, angeblich einschließlich 95 Millionen Support-Ticket-Datensätzen. Have I Been Pwned verzeichnete 197.400 einzigartige E-Mail-Adressen im Datenleck, zusammen mit Produkt-SKUs, Bestell-IDs und geografischen Marktdaten. Inditex bestätigte den Vorfall, erklärte jedoch, dass er keine Passwörter oder Zahlungsinformationen betraf.

Warum das wichtig ist

Dieser Vorfall ist ein strukturelles Risiko, kein einmaliges Ereignis. SaaS-zu-SaaS-Integrationen beinhalten routinemäßig Credential-Delegation: Ein Dienst authentifiziert sich im Namen eines anderen und speichert langlebige Tokens mit umfangreichen Berechtigungen. Diese Autorisierung wird einmal erteilt und selten überprüft. Wenn der delegierte Dienst kompromittiert wird, wird jede nachgelagerte Verbindung, die er hält, zu einem Angriffsvektor — und die primäre Plattform hat keine Sichtbarkeit oder Kontrolle über den Vorfall.

Das ShinyHunters-Playbook ist konsistent: einen peripheren Integrationsdienst identifizieren, ihn kompromittieren, gespeicherte Tokens extrahieren und den Zugang durch Erpressung monetarisieren, bevor Opfer reagieren können.

Was zu tun ist

• Führen Sie ein aktuelles Inventar aller Drittanbieter-SaaS-Integrationen und der Zugangsdaten, die sie in Ihrem Namen halten
• Wenden Sie Least-Privilege-Scoping auf alle OAuth-Grants und API-Tokens an, die an externe Dienste ausgegeben werden
• Legen Sie Token-Ablaufrichtlinien fest — vermeiden Sie unbefristete langlebige Tokens für Drittanbieter-Integrationen
• Führen Sie regelmäßige Zugriffsüberprüfungen durch und widerrufen Sie Autorisierungen für Dienste, die nicht mehr aktiv genutzt werden
• Behandeln Sie die Sicherheitslage von Integrationsanbietern als Teil Ihres Vendor-Risk-Assessment-Prozesses

Ungeprüfte Drittanbieter-Integrationen und langlebige Tokens sind ein strukturelles Risiko, kein Randfall. Passwork bietet Sicherheitsteams ein zentralisiertes Inventar von Zugangsdaten mit rollenbasierter Zugriffskontrolle und einem vollständigen Audit-Trail — damit nichts unbemerkt bestehen bleibt. Erfahren Sie, wie es funktioniert

Vercel: Supply-Chain-Angriff über OAuth und Lumma Stealer

Ein Vercel-Mitarbeiter nutzte Context.ai — ein KI-Produktivitätstool eines Drittanbieters — das über OAuth mit seinem geschäftlichen Google Workspace-Konto verbunden war. Als Context.ai kompromittiert wurde, erbten Angreifer diesen OAuth-Zugriff, übernahmen das Vercel-Konto des Mitarbeiters und drangen in Produktionssysteme ein.

Nicht-sensible Umgebungsvariablen — API-Keys, Tokens, Datenbank-Zugangsdaten, Signaturschlüssel — wurden aufgelistet und entschlüsselt. Vercel beauftragte Google Mandiant für die forensische Untersuchung und beschrieb die Angreifer als „hochentwickelt basierend auf ihrer operativen Geschwindigkeit und ihrem tiefgreifenden Verständnis von Vercels Produkt-API-Oberfläche".

Was geschah

Trend Micro identifizierte Lumma Stealer als den Infostealer, der bei der initialen Kompromittierung von Context.ai verwendet wurde. Lumma ist ein handelsübliches Malware-as-a-Service-Tool, das im Browser gespeicherte Zugangsdaten, Session-Cookies und Authentifizierungstokens von infizierten Maschinen extrahiert. Ein infiziertes Entwicklergerät bei einem kleinen KI-Anbieter wurde zum Einstiegspunkt für einen 2-Millionen-Dollar-Datenvorfall bei einer großen Cloud-Plattform.