How should security teams govern cloud secrets across DevOps and runtime systems?

Treat secrets as lifecycle-managed NHI credentials, not static configuration values. Assign ownership, scope every credential to a purpose, rotate it on exposure or expiry, and remove standing access wherever possible. The governance goal is to shrink the time and scope of usable access, especially in pipelines and cloud workloads.

Why This Matters for Security Teams

Cloud secrets are not just configuration artefacts. They are credentials that can unlock pipelines, workloads, storage, and third-party services, which means weak governance becomes an identity problem very quickly. Security teams often inherit secrets scattered across source code, CI jobs, chat tools, and runtime environments, then try to fix the issue with periodic scans alone. That is too late for many incidents. NHIMG research shows 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026, which is a reminder that exposure is still accelerating across modern delivery systems.

Good governance starts with treating each secret as a scoped NHI credential with ownership, expiry, and revocation rules. That approach aligns with the practical lessons seen in the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack, where exposed credentials became operational access rather than just data leakage. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward least privilege, inventory, and continuous protection, but teams still struggle to apply those ideas consistently across DevOps and runtime systems. In practice, many security teams encounter secret abuse only after a build runner or cloud workload has already been used for lateral movement.

How It Works in Practice

Security teams should govern secrets as a lifecycle, not a vault-only problem. Start by inventorying all secrets, then classify them by owner, system, purpose, and blast radius. Every secret should have a named business or platform owner, a rotation policy, a revocation trigger, and a clear link to the workload or pipeline that consumes it. Where possible, replace static secrets with short-lived credentials issued at runtime through workload identity, federated access, or brokered token exchange. That is especially important for CI/CD runners, ephemeral containers, and deployment bots, because those systems often execute with broad permissions but limited human oversight.

Practical controls usually include:

• Use dedicated secrets managers for issuance, storage, and audit trails rather than embedding values in code or environment files.
• Prefer ephemeral credentials with tight TTLs for build jobs, deployment steps, and runtime service calls.
• Enforce just-in-time access for humans and automation that only needs privileged access briefly.
• Revoke on exposure, not just on schedule, and verify revocation with alerting and pipeline checks.
• Bind each secret to one purpose so a compromised token cannot be reused across systems.

This is not abstract advice. The Guide to the Secret Sprawl Challenge and 52 NHI Breaches Analysis show that the damage from secrets often comes from over-scoped access and slow containment, not from the initial leak alone. The operational standard should be fast detection, automatic rotation, and immediate invalidation, backed by policy that evaluates access at request time. These controls tend to break down in highly distributed build systems with unmanaged runners and ad hoc scripts because ownership and revocation paths are unclear.

Common Variations and Edge Cases

Tighter secrets governance often increases deployment friction, requiring organisations to balance speed against control. That tradeoff is real in platform engineering, where developers want frictionless automation and security teams need auditability and constrained access. Best practice is evolving, but current guidance suggests that static long-lived secrets should be the exception, not the default, especially in systems that scale quickly or change frequently.

Some environments need special handling. Legacy applications may still require static credentials for compatibility, but those should be isolated, rotated aggressively, and surrounded by compensating controls such as network restriction, vault access policies, and monitoring for abnormal use. Multi-cloud and hybrid systems can also complicate ownership because the same workload may consume secrets from different control planes. In those cases, security teams should unify policy and reporting even if the underlying stores remain separate. Runtime systems that autoscale or spin up short-lived jobs are usually the strongest candidates for ephemeral secret issuance, while batch processes and machine-to-machine integrations may need different TTLs and revocation workflows.

The main failure mode is assuming that a secret is safe once it is hidden. As the 230M AWS environment compromise illustrates, exposed credentials can become control-plane access if governance is weak. That is why Emerald Whale breach style lessons matter: detection, rotation, and revocation must be operationalised together, not treated as separate tasks. There is no universal standard for every environment yet, but the direction is clear: minimise standing access, shorten credential lifetime, and make every secret traceable to a single owner and purpose.

Related resources from NHI Mgmt Group

• How should security teams govern API secrets across cloud and DevOps environments?
• How should security teams handle cloud secrets that are shared across applications and pipelines?
• How should security teams govern non-human identities in cloud environments?
• How should security teams govern delegated admin access from cloud providers?