Standing trust creates risk because a compromised user, script, or integration can reuse its access to modify code, inject malicious components, or bypass review. In software supply chains, the safer model is to assume that threats may already exist inside the environment and require verification before each critical step.
Why standing trust turns a pipeline into a reusable attack path
Build pipelines are meant to automate repeatable steps, but standing trust gives those steps durable authority. If a user, script, token, or integration can keep acting without fresh verification, any compromise of that trust path can be reused to change source, alter artifacts, or move malicious content downstream. The risk is not just a bad build, it is a trusted path that can be abused repeatedly.
The supply chain problem is amplified because pipeline credentials often connect multiple systems: source control, package registries, artifact stores, deployment targets, and CI runners. Once that access is persistent, the attacker does not need to win each checkpoint separately. They only need one foothold in the trusted path to influence many builds.
Standing trust also weakens review assumptions. A pipeline step that has permanent permission to pull, push, sign, or deploy can bypass the human decision points that were supposed to separate safe code from unsafe code. That is why verification before execution matters more than trusting the identity of the thing executing the step.
NHIMG’s Reviewdog GitHub Action supply chain attack shows how a trusted action path can be turned into a secrets exposure event, and the broader pattern is the same in many CI/CD compromises.
For a wider look at how mismanaged pipeline access turns into compromise, CI/CD pipeline exploitation case study is a useful companion example.
Where the trust boundary breaks in practice
Standing trust becomes dangerous when it is treated as a one-time setup instead of a continuously validated control. Long-lived tokens, privileged automation accounts, reusable workflow permissions, and third-party actions all expand the blast radius if they are not rechecked at each critical stage. In practice, the failure is often not a single missing control, but a chain of small permissions that together enable code tampering or artifact substitution.
This is especially important in systems that consume external packages, reusable build components, or marketplace plugins. Those dependencies can be modified upstream, hijacked, or impersonated, and a pipeline that accepts them on trust alone may ingest malicious content with no new decision point. The safer model is to bind trust to the specific run, artifact, or approval state instead of to the actor forever.
The most important design question is whether the pipeline can distinguish between a legitimate repeat operation and an unauthorized reuse of earlier access. If it cannot, then the pipeline is not just automated, it is persistently exposed.
Supply-chain integrity guidance from SLSA is directly relevant here because provenance and build integrity are meant to reduce exactly this kind of reusable trust.
NIST SSDF (SP 800-218) also reinforces the need for secure build practices, change control, and integrity checks across the software development lifecycle.
Open source supply chain hardening guidance from OpenSSF is useful when the risk comes from externally sourced components that enter the pipeline through trusted automation.
One relevant data point from NHIMG’s Ultimate Guide to Non-Human Identities is that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is a strong indicator of how often standing trust is coupled with exposed credentials.
Risk and Threat Considerations
Standing trust increases both exposure and abuse potential because compromise does not have to happen at the boundary, it can happen inside the process that everyone already trusts. Once that trust is durable, an attacker can persist through normal automation, modify outputs without immediate detection, or weaponise an integration that was never meant to be a privileged control point.
Failure mechanism: Persistent credentials, overly broad workflow permissions, and unchecked third-party automation let a compromised principal reuse access across builds, which turns a single foothold into repeated source or artifact manipulation.
Impact: Attackers can inject malicious code, alter dependencies, steal secrets, poison releases, or cause downstream deployments to distribute compromised software at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Standing trust is an access control problem that determines who or what can alter builds. |
| PR.DS — Data Security | Build integrity depends on protecting source, artifacts, and secrets from unauthorized modification or exfiltration. | |
| DE.CM — Continuous Monitoring | Standing trust is risky because abuse may persist unless pipeline activity is monitored for anomalies. | |
| Recommendation — Limit build-system access to the minimum required privileges and revalidate access before release-critical actions. Protect source, build outputs, and secrets with integrity checks and controlled handling across the pipeline. Monitor pipeline actions for unusual privilege use, unexpected artifact changes, and suspicious workflow executions. | ||
| CIS Controls v8 | 5 — Account Management | Build pipelines rely on managed accounts, tokens, and service access that must be controlled and reviewed. |
| 6 — Access Control Management | The risk comes from persistent permissions that let compromised automation modify code or artifacts. | |
| 16 — Application Software Security | Build pipelines are part of software delivery and need integrity controls around trusted components and dependencies. | |
| Recommendation — Inventory pipeline accounts and revoke or rotate any standing credentials that are no longer required. Enforce least privilege for CI/CD roles and remove broad write or deploy rights from default workflow paths. Verify build inputs, dependencies, and release artifacts before promotion into later stages. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The scenario describes attacker abuse of trusted build paths to insert malicious content into software delivery. |
| T1552 — Unsecured Credentials | Standing trust often persists through exposed tokens, keys, or secrets used by build automation. | |
| Recommendation — Map pipeline trust assumptions to supply-chain compromise paths and hunt for tampering in build dependencies and outputs. Track and remove exposed pipeline credentials before they can be reused to alter code or releases. | ||
Practitioner Guidance
What to prioritise: Treat build trust as per-run authority, not permanent entitlement. If a pipeline component can read source, publish artifacts, or deploy to production without fresh validation, it deserves immediate review for privilege scope, secret handling, and approval boundaries.
What to verify: Confirm that critical pipeline steps are bound to short-lived credentials, signed inputs, and explicit provenance checks. If a step can still succeed after the originating user or integration should no longer be trusted, the control is too permissive.
Common mistake: Teams often protect the code review process but leave the automation path fully trusted. That creates a gap where the review was sound, yet the build and release path can still be used to bypass it.
Practitioner takeaway: The security goal is not to eliminate automation, but to ensure that every automation step with release influence is continuously re-authorised, narrowly scoped, and attributable.
