When secrets management sits only with developers, governance gaps usually appear. Security teams lose visibility into how secrets are created, stored, shared, and rotated across platforms. That leads to inconsistent controls, weak auditability, and higher exposure risk. Effective programmes need shared ownership, policy enforcement, and continuous discovery across the software lifecycle.
Why This Matters for Security Teams
When secrets management is treated as a developer-only task, the control plane becomes fragmented. Developers may know where a token is used in code, but security teams still need visibility into creation, storage, rotation, revocation, and exception handling across CI/CD, cloud services, and third-party integrations. The result is weaker auditability, uneven policy enforcement, and slower response when exposure happens.
This is not a theoretical governance issue. NHIMG research on The State of Secrets in AppSec shows the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities. That gap reflects a familiar failure mode: ownership is assumed to exist, but it is not operationalised. The same pattern appears in Guide to the Secret Sprawl Challenge, where sprawl outpaces central governance and manual review cannot keep up.
Teams usually notice the problem only after a credential leak, pipeline compromise, or audit finding exposes how many secrets were never brought under a shared process.
How It Works in Practice
Effective secrets management needs shared accountability across development, platform engineering, security, and operations. Developers should not be the only people deciding how secrets are created or rotated, because the same secret often moves through source control, build systems, runtime environments, and SaaS integrations. The right model treats secrets as operational assets with lifecycle controls, not as local implementation details.
Practically, that means security teams define policy, guardrails, and monitoring, while engineering teams implement those controls in workflows. Current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 supports this kind of shared responsibility: inventory secrets, classify them by risk, enforce least privilege, and make rotation and revocation measurable. In mature programmes, secrets are discovered continuously across repositories and CI/CD systems, then mapped to owners and expiry rules. Short-lived credentials are preferred where possible, because long-lived static secrets increase blast radius and make revocation slower.
A useful operating model is:
- central policy for approved secret stores and rotation intervals
- automated discovery across code, pipelines, and cloud environments
- role clarity for creation, approval, use, and revocation
- audit logging that ties each secret to an owner and system of record
NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant because secrets are part of the broader non-human identity lifecycle, not a separate side problem. These controls tend to break down when organisations run many disconnected platforms, because inconsistent tagging and manual handoffs prevent reliable discovery and rotation.
Common Variations and Edge Cases
Tighter central control often increases workflow friction, so organisations have to balance developer velocity against risk reduction. That tradeoff becomes sharper in legacy estates, multi-cloud environments, and teams using many ephemeral build agents, where secrets appear and disappear too quickly for manual review.
There is no universal standard for exactly where every approval should sit, but current guidance suggests the security function should own policy and assurance while engineering owns implementation. In practice, the biggest edge case is “shadow ownership,” where a developer team creates a secret for one service, then that credential is reused in another system with no new review. Another common exception is machine-to-machine traffic in automation-heavy environments, where teams keep using static secrets because refactoring to workload identity has not been completed.
That is why incidents like the CI/CD pipeline exploitation case study matter: once a pipeline is trusted to create or pass secrets, compromise can cascade into multiple downstream systems. The practical test is simple: if a team cannot answer who owns a secret, where it is stored, when it expires, and how it is revoked, then the responsibility model has already failed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shared ownership is needed to prevent unmanaged NHI secret sprawl. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on controlled secret issuance and review. |
| NIST SP 800-53 Rev 5 | IA-5 | Authentication management covers secret lifecycle, rotation, and revocation. |
| CSA MAESTRO | Agentic workflows need governance for secrets used by autonomous workloads. | |
| NIST AI RMF | AI systems need accountability around access to sensitive credentials and data. |
Treat secrets for automated workloads as governed assets with policy, telemetry, and revocation.
Related resources from NHI Mgmt Group
- What breaks when teams manually copy secrets between Kubernetes and external vaults?
- How should security teams implement auto-rotating secrets at scale in developer and cloud environments?
- What breaks when organisations treat secrets storage as lifecycle management?
- What breaks when teams treat system prompts as a secure place for secrets?
