Standing credentials increase risk because a single workflow execution can become a trusted bridge from a low-friction entry point to package publishing, registry pushes, and secret access. If a pipeline can mint release artifacts and use long-lived tokens, an attacker only needs one injection path to turn code execution into broad distribution of trojaned assets.
Why This Matters for Security Teams
Standing credentials in CI and release pipelines turn automation into a durable trust bridge. Once a token, key, or certificate is embedded in a job, script, or runner environment, it can outlive the original change, be copied into logs or artifacts, and be reused outside its intended scope. That makes one compromised build path enough to reach package registries, signing services, cloud resources, and secret stores. The OWASP Non-Human Identity Top 10 is useful here because pipeline credentials are NHI assets, not just “deployment details.”
The real risk is not only theft, but persistence. A long-lived credential can silently preserve access after the original vuln is patched, the runner is rebuilt, or the developer account is reset. That widens the blast radius of a single injection path into a supply chain event affecting downstream customers. In practice, many security teams encounter this only after a routine release process has already been used as the delivery mechanism for trojaned artifacts, rather than through intentional compromise detection.
How It Works in Practice
In a typical CI and release flow, credentials are used to authenticate package uploads, sign releases, pull dependencies, call cloud APIs, or read protected secrets needed for deployment. When those credentials are standing, any code that reaches the pipeline can often inherit the same authority for the full lifetime of the token. That means attacker-controlled build steps, poisoned dependencies, or malicious pull request logic can abuse legitimate automation without having to defeat separate perimeter controls.
Supply chain risk increases because the pipeline is often trusted to produce and distribute software at speed. If a long-lived secret is exposed in environment variables, cached files, container layers, logs, or artifact metadata, it may be reusable well beyond the job that was supposed to consume it. This is exactly the kind of non-human identity exposure that the NIST SP 800-63 Digital Identity Guidelines help contextualize at a broader identity assurance level: credentials should be bound, scoped, and lifecycle-managed, not treated as static utility values.
- Use short-lived credentials wherever possible, with just-in-time issuance for the specific workflow.
- Bind pipeline identities to workload, repo, environment, and action scope instead of global reuse.
- Separate build, sign, publish, and deploy permissions so one step cannot freely assume the others.
- Protect secrets at rest and in transit, and prevent them from appearing in logs, caches, or artifacts.
- Require strong provenance checks before release promotion or artifact publication.
Current guidance suggests that least privilege is most effective when credentials are ephemeral and tied to an auditable identity path, rather than when they are simply rotated on a schedule. NIST control thinking reinforces this through access enforcement and system integrity requirements, including the broader control set in NIST SP 800-53 Rev 5 Security and Privacy Controls and the governance lens in the NIST Cybersecurity Framework 2.0. These controls tend to break down when self-hosted runners share credentials across projects because isolation is too weak to contain reuse.
Common Variations and Edge Cases
Tighter credential controls often increase operational overhead, requiring organisations to balance deployment speed against the friction of stronger authentication, secret issuance, and approval logic. That tradeoff is real, especially where release engineering teams want reproducible builds and minimal pipeline latency.
Some environments legitimately need temporary standing access for migration windows, cross-account publishing, or vendor-operated release tooling, but current best practice is evolving toward time-bounded, narrowly scoped exceptions with explicit monitoring. There is no universal standard for how long a release credential may remain valid, but the shorter the lifetime, the lower the replay value. This becomes even more important when agentic automation is involved, because autonomous tooling can chain actions faster than a human can notice abnormal behaviour. The recent Anthropic report on an AI-orchestrated cyber espionage campaign shows why identity control around autonomous execution matters: if a pipeline identity can be reused, an attacker may not need to stay interactive for long.
Exceptions also arise in air-gapped or heavily regulated release systems where token issuance is constrained. In those cases, compensating controls should include explicit approval gates, dedicated signing identities, strong artifact provenance, and alerts on unusual publish behaviour. The practical question is not whether automation should have identity, but whether that identity is disposable, traceable, and isolated to the narrowest feasible function.
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-2 | Pipeline tokens and keys are non-human identities with lifecycle risk. |
| NIST CSF 2.0 | PR.AC | Least-privilege access and identity control reduce release pipeline blast radius. |
| NIST SP 800-63 | AAL2 | Credential assurance and lifecycle discipline matter when pipelines can publish software. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management applies to long-lived secrets used by build and release systems. |
| MITRE ATT&CK | T1078 | Valid accounts are often reused after credential theft in supply chain intrusions. |
Treat release credentials as authenticated identities with binding, expiry, and reauthentication rules.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
