Treat shared secrets as a governance defect, not just an operational convenience. Assign ownership, reduce reuse, and move toward per-workflow credentials with automatic expiry. Shared secrets increase blast radius because one leak can affect multiple systems at once. A good control model limits where a secret can be used, how long it lives, and who can reissue it.
Why This Matters for Security Teams
Shared secrets are rarely a simple convenience issue. They are usually a sign that authentication has been optimised for delivery speed while ownership, scope, and revocation were left vague. Once the same token is embedded in multiple applications or pipelines, any one compromise can become a cross-system incident. Current guidance from the OWASP Non-Human Identity Top 10 treats that pattern as an identity-risk problem, not just a vaulting problem.
The exposure is not theoretical. GitGuardian’s Guide to the Secret Sprawl Challenge reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is a strong reminder that detection without revocation leaves the blast radius intact. Shared credentials also blur accountability: if multiple apps, jobs, and human teams can use the same secret, no one can confidently answer who needs it, who used it, or who should retire it.
In practice, many security teams discover the problem only after a leaked pipeline token has already been reused in a second system, rather than through intentional secret lifecycle management.
How It Works in Practice
The operational fix is to replace broad reusability with scoped, short-lived credentials tied to a specific workload, workflow, or deployment stage. That usually means issuing separate credentials per application, per pipeline, or even per environment, then enforcing automatic expiry and revocation on completion. For cloud-native systems, workload identity is often a better primitive than storing reusable static secrets, because it proves what the workload is and lets policy decide what it may do at request time.
This is where Zero Trust thinking becomes useful: identity and access should be evaluated continuously, not assumed because a token once existed. The OWASP Non-Human Identity Top 10 aligns with that approach by emphasising identity scoping, rotation, and misuse resistance for machine access. In practice, teams should pair that with pipeline controls that prevent secrets from being copied across jobs or inherited by downstream steps. NHIMG’s CI/CD pipeline exploitation case study shows how quickly a single exposed credential can become a supply chain pivot when build runners are over-trusted.
- Assign one owner per secret and retire anything that lacks a named owner.
- Replace shared static credentials with per-workflow or per-service identities.
- Use JIT issuance so access exists only for the task window.
- Enforce automatic rotation and revocation on deployment, failure, or job completion.
- Log every issuance and use event so reuse can be detected as an exception, not a norm.
For teams modernising their posture, NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference point, and the implementation pattern should be validated against the OWASP Non-Human Identity Top 10 before rollout. These controls tend to break down when legacy applications hardcode credentials into configuration files or when shared runners cannot support distinct identities per job.
Common Variations and Edge Cases
Tighter secret scoping often increases operational overhead, so organisations need to balance stronger blast-radius reduction against build complexity and release friction. That tradeoff is real, especially in older environments where one integration token still supports many jobs, or where third-party systems cannot accept short-lived federation flows yet.
Best practice is evolving for these edge cases. Where full per-workflow identity is not yet possible, teams should at least compartmentalise by environment, separate human and machine access, and introduce revocation triggers for pipeline completion or exception handling. The goal is to shrink reuse even if it cannot be eliminated immediately.
Shared secrets also show up outside code repositories, including chat tools, ticketing systems, and documentation. NHIMG’s Guide to the Secret Sprawl Challenge notes that 28% of secrets incidents now originate outside code repositories and are more likely to be critical, which makes governance across collaboration tools just as important as repository scanning. For teams dealing with large-scale pipeline exposure, the Reviewdog GitHub Action supply chain attack is a reminder that secret hygiene has to extend to actions, runners, and transitive build dependencies.
Where the environment includes autonomous tooling or AI-assisted release steps, organisations should be especially cautious about extending shared credentials into those workflows, because tool-chaining can turn a narrow secret into broad unauthorized access very quickly.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses over-scoped, long-lived machine credentials and their rotation. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access control for machine identities and secrets. |
| NIST Zero Trust (SP 800-207) | Supports continuous verification instead of trusting a reusable shared credential. |
Replace shared secrets with scoped, rotated NHI credentials and enforce short-lived issuance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
