Stolen tokens turn software supply chains into distribution paths

At a glance

What this is: This analysis shows how stolen publishing and CI/CD tokens can turn trusted release channels into malware delivery paths and downstream credential exposure vectors.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat software delivery credentials as high-value identities whose scope, lifetime, and revocation status directly shape supply chain risk.

👉 Read Truffle Security's analysis of stolen tokens in software supply chains

Context

Software supply chain security fails when trusted release mechanisms are also trusted authentication mechanisms. If a publishing token or CI/CD credential can change what gets distributed, the attacker does not need to bypass the product itself, only the authority behind the release path. That creates a direct identity security problem inside the build and delivery pipeline, not just an application security problem.

The Trivy incident is a clear example of why machine identities in delivery systems need the same lifecycle governance as human admin access. When rotation is incomplete, privilege remains usable even after the initial exposure has been detected, and that gap is often enough to sustain attacker access.

Key questions

Q: What breaks when package publish credentials are stolen in a software supply chain?

A: A stolen publish credential turns trusted release infrastructure into an attacker-controlled distribution path. The malicious actor can publish a package that appears legitimate, reach many downstream environments quickly, and bypass user suspicion because the attack comes through normal update channels. The control failure is usually weak secret scoping, poor rotation, and missing release approval boundaries.

Q: Why do incomplete credential rotations keep supply chain incidents alive?

A: Incomplete rotation keeps incidents alive because one surviving token, bot account, or secret can preserve attacker access after the first response. In supply-chain environments, that residual identity can reach release automation, repositories, and signing paths. The real containment test is whether any credentialed path remains valid after rotation.

Q: What are the warning signs that CI/CD credentials are over-scoped?

A: Warning signs include one token reaching repositories, registries, cloud services, and multiple workflows, or a single credential being able to publish and deploy. If one machine identity can fan out across the whole delivery stack, the blast radius is too large and the permission model needs tightening.

Q: How should teams balance artifact signing with credential governance in supply chains?

A: Artifact signing reduces tampering risk, but it does not solve compromised release authority. Teams need both signed artefacts and tightly governed machine identities that create them. If the publishing credential is weak, the attacker can still sign or distribute malicious content through a trusted process.

Technical breakdown

How compromised publishing tokens become a release vector

Publishing tokens, CI/CD secrets, and release credentials are not just authentication artefacts. They are authority-bearing machine identities that can approve package publication, tag releases, trigger workflows, and push content into trusted distribution channels. Once an attacker holds one of these credentials, the software supply chain can be used as a delivery mechanism for malicious code. The danger is amplified when the token sits inside automation that already has broad repository or registry reach. In that model, one identity can influence multiple downstream systems without needing interactive access or a human login. See the CI/CD Pipeline Identity Security Guide.

Practical implication: Treat release credentials as privileged identities and constrain what each token can publish, modify, or trigger.

Why incomplete revocation leaves attacker access intact

Credential rotation only works when the old secret is actually invalidated everywhere it can authenticate. In the Trivy case, the article describes earlier credential theft that had not been fully contained, which meant rotation did not fully end the attacker’s access. That is a classic lifecycle failure: the organisation believes the secret has been replaced, but some authentication path still accepts the old value or an equivalent grant survives. For supply chain incidents, this is especially dangerous because release systems often connect source control, package registries, artifacts, and cloud services through one credential plane. See the Leaked Credential and Secret Incident Response Playbook.

Practical implication: Verify that revoked credentials no longer authenticate anywhere before assuming containment is complete.

Why build pipelines magnify the blast radius

Build pipelines concentrate trust. They commonly link repositories, registries, artifact stores, and cloud services, so a single credential may reach far more than the release job it was meant to perform. That makes over-scoped automation accounts and long-lived publishing secrets particularly dangerous. If a compromised token can reach additional repositories or cloud accounts, the attacker can move from one release event into broader infrastructure exposure. This is why software supply chain defence must account for identity scope, not only artifact integrity. A secure pipeline is one where each credential is narrowly bound to a specific workflow and cannot be reused elsewhere.

Practical implication: Map every publishing and CI/CD credential to the systems it can actually reach, then remove unnecessary cross-system permissions.

Threat narrative

Attacker objective: The objective is to use legitimate software delivery authority to distribute malware and reach additional credentials, repositories, and downstream environments.

1. Entry occurred when attackers obtained a publishing or CI/CD credential that authorized changes to trusted release infrastructure.
2. Credential access persisted because earlier theft had not been fully contained and the rotation process did not fully eliminate attacker-authenticated access.
3. Escalation happened as the attackers used the trusted release path to publish malicious releases and manipulate GitHub Actions tags.
4. Impact followed when the malicious components could steal additional credentials and potentially expose repositories, cloud accounts, and CI/CD systems.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Release credentials are now supply chain identities, not operational convenience tokens. When a publishing token can alter releases, trigger workflows, and reach multiple downstream systems, it becomes a privileged identity with direct security impact. That should change how teams inventory, scope, and monitor automation access. The practical conclusion is to govern release credentials as high-risk machine identities, not as disposable build secrets.

Incomplete revocation is a containment failure, not a hygiene issue. The article describes a prior credential theft that was not fully contained, which allowed attacker access to survive rotation. That means the control gap is not merely secret exposure, but the assumption that rotation alone ends compromise. Teams need to prove that old grants no longer authenticate before they close an incident.

Stolen tokens expose a verification trust gap in software delivery. Developers and automated pipelines trust the release channel, so attackers only need the authority behind that channel to exploit the system. CI/CD pipeline identity security becomes central here because the pipeline itself is part of the identity perimeter. Practitioners should assume the delivery path is a target, not just the artifact.

Long-lived publishing secrets create avoidable blast-radius expansion. A single broadly scoped token can reach repositories, cloud services, and automated workflows, which means one compromise can fan out across the delivery stack. The discipline is moving toward narrower, workload-bound credentials with explicit revocation proof. The practitioner conclusion is to reduce standing authority wherever software changes are authorised.

Protecting software supply chains now requires identity governance at the release layer. Artifact signing and dependency checks still matter, but they are no longer sufficient if the credentials used to publish those artifacts remain exposed or over-permissioned. This is a governance problem as much as a technical one: the trust boundary is the credential, not only the package. The conclusion is to align release governance with machine identity lifecycle controls.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Software Supply Chain Security Guide

What this signals

Software delivery is becoming an identity perimeter. The practical shift is that release credentials, not just code dependencies, now define where supply chain compromise can begin and how far it can spread. Teams that still treat publishing access as a low-friction operational detail will keep underestimating blast radius.

Identity lifecycle control is the new supply chain control point. The important question is no longer whether a secret was rotated, but whether the old grant is truly unusable across every system it touched. That makes revocation proof and permission scope the decisive operational measures for release environments.

Trusted publishing reduces exposure only when it replaces long-lived authority, not when it sits beside it. Short-lived, workload-bound release identity is the direction of travel, because it limits how long an attacker can use stolen credentials to impersonate the build pipeline.

For practitioners

• Inventory every release credential and automation token Map publishing tokens, CI/CD secrets, GitHub Actions credentials, and registry grants to the systems they can reach, then classify which ones can modify releases or trigger trusted workflows.
• Reduce standing authority in publishing workflows Replace long-lived publishing credentials with short-lived, workload-bound identity where supported, and limit each token to the smallest release scope possible.
• Prove revocation before closing containment After rotating a compromised secret, test that the old credential no longer authenticates and confirm that no equivalent grant survives in adjacent systems.
• Expand secret discovery beyond source code Search CI logs, configuration files, container images, build outputs, and release artifacts for exposed credentials that could still authorise distribution or downstream access.
• Separate release authority from general build access Use distinct credentials for build, publish, and deployment steps so that a compromise in one stage cannot automatically reach the next stage.

Key takeaways

• The article’s core warning is that software supply chains fail when release credentials are treated as routine secrets instead of privileged identities.
• The Trivy incident and related attacks show that a compromised token can extend from one publish path into repositories, cloud accounts, and CI/CD systems.
• Preventing this pattern requires narrower release permissions, short-lived credentials, and proof that revoked access can no longer authenticate.

Related NHI Mgmt Group resources: CI/CD Pipeline Identity Security Guide · Leaked Credential and Secret Incident Response Playbook · Software Supply Chain Security Guide · GitHub and GitHub Actions Security Guide

Key terms

• Package Publishing Token: A package publishing token is a secret that authorises a person or automation to upload or modify software packages in a registry. If it is stolen or over-scoped, an attacker can inject code, overwrite releases, or propagate malicious updates at scale.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Release Infrastructure: Release infrastructure is the set of repositories, registries, workflows, and automation steps that move software from build to distribution. It becomes a security boundary when the credentials that operate it can also alter what users and pipelines receive.
• Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.

What's in the full article

Truffle Security's full blog post covers the operational detail this post intentionally leaves for the source:

• A closer walkthrough of the Trivy compromise chain, including how trusted release channels were abused
• Practical detail on token exposure paths across GitHub Actions, releases, and container images
• Specific examples of how incomplete rotation can leave attacker access intact
• Context on why secret discovery must extend beyond source code into build and release artefacts

👉 The full Truffle Security post covers the Trivy compromise, release-path abuse, and credential containment details.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect machine identity controls to real operational governance.