Because automated updates are usually granted broad access to fetch, build, and test without the human checks that would slow an attacker down. When those updates are poisoned, the attacker inherits the same permissions and can target runner credentials, secret stores, and downstream repositories in one flow.
Why trusted CI updates become such high-value credential targets
Trusted CI updates are dangerous because they already sit inside a privileged delivery path. Once attackers can influence that path, they do not need to break into each downstream system separately. They can pivot from the update pipeline into build runners, signing workflows, secret stores, and repositories that trust the update as legitimate.
That trust changes the economics of attack. A poisoned update often inherits the same access, automation, and replication privileges that make CI efficient in the first place, so a single compromise can fan out across many environments before anyone notices.
When a CI pipeline is trusted to fetch dependencies, build artifacts, and test code automatically, the update mechanism itself becomes part of the attack surface. Top 10 NHI Issues is useful here because it frames the access, rotation, and privilege problems that show up when automation is allowed to handle credentials at scale.
How one compromised update leads to credential theft
The sharp increase in risk comes from privilege concentration. CI systems commonly have tokens for package registries, cloud services, source control, signing, artifact promotion, and test infrastructure. If an attacker injects malicious content into an update or build step, that same execution context can read environment variables, mount secrets, call internal APIs, and reach downstream repositories without tripping the human friction that normally slows abuse.
That is why supply chain compromise and credential theft so often appear together. The malicious payload does not need to be sophisticated if the pipeline already exposes reusable secrets. Fake Dependabot commits 2023 shows how stolen GitHub tokens and malicious workflow changes can turn a trusted update path into a secrets-harvesting path.
Trusted CI updates also compress the attacker’s timeline. A compromised runner may expose short-lived session tokens, long-lived API keys, signing certificates, or cloud credentials in one execution window. If those secrets are reused across environments, the attacker can move laterally from a single poisoned update into multiple systems before rotation or revocation catches up. Slack GitHub breach 2022 is a good example of how one stolen token can expose private repositories at scale.
Why the blast radius grows so fast in CI/CD
CI/CD pipelines are designed to automate trust. They often grant broad permissions so builds do not stall, tests can reach dependencies, and deployments can proceed without manual approval at every step. That works operationally, but it means a poisoned update can inherit authority that would be too risky in a human-operated workflow. The result is not just one leaked secret, but a pathway to the secret stores, runners, and repositories that hold many more.
This is especially dangerous when the update system can reach production-adjacent assets, artifact signing keys, or cloud control planes. In that situation, a compromise becomes a credential collection event first and an intrusion second. Miasma and Hades Supply Chain Worms illustrates how supply chain malware can use compromised credentials and package trust to spread through multiple ecosystems.
The other amplifier is reuse. CI credentials are often shared across jobs, environments, or repositories because the pipeline needs them in many places. That convenience means one successful theft can unlock not just the build system, but the adjacent services that depend on the same token, key, or account. Ultimate Guide to NHIs, Why NHI Security Matters Now reinforces why broad access and weak rotation make automated environments attractive to attackers.
Risk and Threat Considerations
Trusted CI updates are high-risk because they combine privileged automation, wide fan-out, and limited human scrutiny. That makes them ideal for attackers who want to harvest reusable credentials quickly and then reuse those secrets before defenders can revoke them.
Failure mechanism: A poisoned update executes inside a trusted pipeline, reads secrets or tokens available to the runner, and uses those credentials to access artifact stores, repositories, or cloud services that trust the pipeline output.
Impact: The compromise can spread beyond the initial build job into source control, secret stores, deployment systems, and downstream environments, turning one update into a multi-system credential exposure event.
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, MITRE ATT&CK and OWASP API Security Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Trusted CI updates can expose runner and pipeline secrets. |
| NHI-05 — Overprivileged NHI | CI runners and automation often hold broader access than needed. | |
| NHI-07 — Long-Lived Secrets | CI credential reuse makes poisoned updates far more damaging. | |
| Recommendation — Minimise secret exposure in update jobs and rotate any credential a pipeline can read. Scope CI identities to the minimum permissions needed for each pipeline stage. Replace durable CI secrets with short-lived credentials wherever possible. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Poisoned updates often target exposed credentials inside build environments. |
| Recommendation — Hunt for exposed credentials in CI logs, variables, artifacts and config files. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen CI tokens and keys frequently become the first valid access path. |
| Recommendation — Require strong authentication controls for machine-to-machine access used by CI. | ||
Practitioner Guidance
What to verify: Treat CI trust boundaries as credential boundaries. Verify which jobs can see which secrets, whether runners are isolated per trust level, and whether update-related workflows can reach production credentials or signing material.
What to prioritise: Reduce the number of secrets available to update and build jobs, then separate fetch, build, test, and publish permissions so a compromise in one stage does not automatically expose everything else.
Common mistake: Assuming signed or “trusted” updates are safe by default. If a pipeline can execute code and the code can access secrets, trust in the update channel is also trust in its credential access path.
Practitioner takeaway: The key judgement is not whether updates are automated, but whether the automation is bounded tightly enough that a poisoned update cannot become a credential extraction point.
OWASP Non-Human Identity Top 10
Related resources from NHI Mgmt Group
- Why do misconfigured CI/CD workflows increase credential theft risk?
- Why do trusted integrations create a larger breach risk than direct credential theft?
- Why do personal devices increase the risk of browser-based credential theft?
- Why do adversary-in-the-middle phishing kits increase identity risk beyond ordinary credential theft?