Secrets managers reduce handling friction, but they do not remove the secret from the environment where code runs. If a malicious package or runner compromise can access memory or environment variables, the credential is still reachable. That is why pipeline design matters as much as vault design.
Why This Matters for Security Teams
Secrets managers are valuable, but they are not a complete defence when CI/CD runners, build steps, and third-party actions can still access live credentials at runtime. The real problem is exposure surface, not storage location. A secret that is fetched just in time can still be dumped from memory, echoed in logs, inherited by child processes, or exfiltrated by a compromised package. That is why NHI governance has to cover the pipeline itself, not just the vault. GitGuardian’s The State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which is a useful reminder that the attack target is often the automation layer.
Current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 points toward least privilege, monitoring, and lifecycle control, but those controls only help if the execution environment is trustworthy. In practice, many security teams discover credential theft only after a runner has already executed untrusted code or a malicious dependency has already read the injected secret.
How It Works in Practice
In a well-designed pipeline, the secrets manager should be only one layer in a broader control set. The credential should be issued to a specific workload identity, scoped to a single job, and revoked automatically after that job ends. For CI/CD, that means preferring short-lived tokens, workload identity federation, and policy checks at request time instead of long-lived static secrets copied into environment variables. The distinction matters because the build agent, not the vault, is where most abuse happens.
Practitioners should treat secrets access as a runtime authorisation decision. That includes:
- binding secrets to a runner identity rather than to a repository or user token;
- issuing credentials only when a pipeline step actually needs them;
- preventing secrets from being written to logs, artifacts, or caches;
- isolating high-trust jobs from untrusted pull requests and third-party actions;
- rotating or revoking credentials immediately after use.
NHIMG’s CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack both illustrate the same pattern: once an attacker controls code execution inside the pipeline, vault design alone does not stop theft. That is why NHI controls and NIST SP 800-63 Digital Identity Guidelines should be read together with pipeline hardening, not as separate disciplines. These controls tend to break down when runners are long-lived, shared across projects, or allowed to execute arbitrary third-party code without isolation.
Common Variations and Edge Cases
Tighter secrets handling often increases pipeline overhead, so organisations have to balance developer speed against blast-radius reduction. That tradeoff is especially visible in fast-moving release systems, monorepos, and self-hosted runners where convenience features such as cached credentials or shared workspaces are tempting.
Best practice is evolving, but current guidance suggests treating some environments as high-risk by default. Public pull requests, forks, and ephemeral test jobs should not receive production-grade secrets unless there is a strong compensating control. In newer supply chain scenarios, such as malicious npm dependencies or compromised GitHub Actions, the primary issue is not whether the secret came from a manager, but whether the job had the authority to reach it at all. NHIMG’s Shai Hulud npm malware campaign is a reminder that dependency execution can be a direct path to credential exposure.
There is no universal standard for this yet, but the direction is clear: pair Guide to the Secret Sprawl Challenge thinking with stronger workload identity, runtime policy, and rapid revocation. Secrets managers reduce leakage, but they do not eliminate the possibility that a compromised build step can use the credential before the manager ever has a chance to help.
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 address the attack and risk surface, while NIST CSF 2.0 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-02 | Addresses secret exposure across non-human workloads and pipelines. |
| NIST CSF 2.0 | PR.AC-4 | Covers access control and least privilege for automated build environments. |
| NIST AI RMF | Useful when automation is goal-driven and can expand access dynamically. |
Apply governance, measurement, and monitoring to automated execution paths that can reach secrets.
