They become cloud breaches quickly because the initial compromise is often only the opening move. Once hostile code reaches environment variables, tokens, or kubeconfigs, it can reuse existing non-human identities to publish images, change workflows, or access infrastructure. The breach scales with the number of standing credentials still available at runtime.
Why This Matters for Security Teams
Supply-chain incidents become cloud breaches when the attacker’s real target is not the package or build step, but the standing non-human identities behind it. A poisoned dependency, compromised GitHub Action, or malicious CI artifact can inherit access to tokens, kubeconfigs, cloud roles, and signing keys that were never meant to survive the pipeline. Once those secrets are exposed, the blast radius is usually governed by runtime privilege, not by the original entry point.
This is why NHI governance and supply-chain defense are inseparable. NHIMG’s The 52 NHI Breaches Report shows how often credential sprawl turns a single compromise into a broader trust failure, while OWASP’s OWASP Non-Human Identity Top 10 frames the same issue as an identity problem, not just a code integrity problem. In practice, many security teams encounter cloud takeover only after a build system, deployment workflow, or container registry has already been used to pivot into infrastructure.
When static secrets remain available during execution, the attacker does not need to “break out” of the supply chain at all; they simply reuse the privileges already embedded in it.
How It Works in Practice
The pattern is usually straightforward: a supply-chain entry point lands in a trusted automation path, and that path has access to live credentials. Those credentials may be injected as environment variables, mounted into runners, stored in kubeconfigs, or attached to service accounts that can push images, mutate clusters, or read cloud state. If the attacker can read the runtime context, they can often impersonate the workload long before defenders detect the compromise.
Current guidance suggests treating these paths as identity-bearing workloads, not just software delivery tooling. That means binding access to short-lived, task-specific identities and limiting what each pipeline step can do at request time. The operational goal is to reduce standing privilege and replace reusable secrets with ephemeral credentials that expire automatically after the job completes. This lines up with NHIMG guidance in the Top 10 NHI Issues and the incident patterns documented in the Reviewdog GitHub Action supply chain attack.
- Use workload identity for CI, build agents, and deployment controllers so the runner proves what it is, not just what secret it holds.
- Issue just-in-time tokens per task, with tight TTLs and automatic revocation on completion.
- Evaluate authorisation at runtime with context such as repo, branch, artifact hash, target account, and requested action.
- Separate build, sign, and deploy permissions so one compromised step cannot become full cloud control.
The practical standard is moving toward identity-aware pipelines, but there is no universal standard for this yet. Frameworks such as the Anthropic report on AI-orchestrated cyber espionage and CISA’s cyber threat advisories reinforce the same lesson: once an automation trust path is captured, abuse tends to spread faster than manual response can contain it. These controls tend to break down in legacy CI/CD systems where long-lived service account keys are shared across many jobs and cannot be revoked without interrupting production release flows.
Common Variations and Edge Cases
Tighter credential controls often increase operational friction, requiring organisations to balance release speed against the security value of short-lived access. That tradeoff becomes sharper in high-volume build environments, where teams rely on cached secrets, broad runner permissions, or cross-account roles to keep pipelines moving.
Best practice is evolving, but a few edge cases are already clear. Self-hosted runners are especially risky because they often sit closer to cloud control planes and have broader filesystem access than managed services. Multi-account cloud setups can also hide privilege chaining, where a benign build token in one account can assume a stronger role in another. In Kubernetes, over-permissioned service accounts and wide cluster-admin bindings can make a package compromise look like a routine deployment until the attacker starts creating pods, reading secrets, or altering admission controls.
NHIMG’s LiteLLM PyPI package breach and Shai Hulud npm malware campaign both show how quickly exposed secrets can convert a software trust failure into cloud access. The same risk is amplified when organisations use static credentials for automation instead of workload-bound identities and runtime policy checks. That is why the best answer is not “trust the pipeline less,” but “make the pipeline prove itself continuously.”
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, OWASP Agentic AI Top 10 and CSA MAESTRO define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses exposed and overused non-human identities in pipelines and cloud automation. |
| OWASP Agentic AI Top 10 | A-04 | Dynamic runtime authorisation is needed when automated systems can chain actions unpredictably. |
| CSA MAESTRO | MAE-02 | Maps to governance of autonomous and semi-autonomous workload identities in cloud environments. |
Inventory and classify every pipeline identity, then replace shared secrets with scoped, short-lived workload identities.
