TL;DR: Trivy was hit by two supply chain attacks in March 2026, with the first stealing a privileged GitHub token through a dangerous pull_request_target workflow and the second reusing incomplete rotation to poison releases, tags, and downstream packages, according to ARMO. The pattern shows that CI/CD trust, not just code integrity, is now the governing control point for open-source consumers.
At a glance
What this is: ARMO shows that the Trivy compromise was not a single event but a two-stage supply chain attack that turned CI/CD trust and incomplete token rotation into a wider secret-theft campaign.
Why it matters: It matters because CI/CD runners, release automation, and service tokens now sit on the identity boundary of software supply chains, so weak workflow design can turn one compromise into many.
Context
The core problem is not just poisoned code. It is the way CI/CD platforms grant privileged access to workflow jobs, release pipelines, and tokens that outlive a single run or are rotated too late to matter.
In this case, a misconfigured GitHub Actions workflow, mutable tags, and non-atomic token rotation combined to create a trust gap that attackers could reuse. That is a common failure pattern in software supply chains, especially where build identity and release identity are not tightly separated.
The identity angle is direct: runners, service accounts, GitHub tokens, npm tokens, cloud keys, and registry credentials all behaved like non-human identities with weak lifecycle control.
Key questions
Q: What breaks when pull_request_target workflows process untrusted input?
A: The workflow can turn attacker-controlled text or branch names into executable shell syntax while still running with the base repository's permissions. That creates a path from harmless-looking metadata to secret exposure, release tampering, or package publication. The failure is not the trigger alone. It is the combination of privileged context, unsafe interpolation, and insufficient separation between review and execution.
Q: Why do compromised CI/CD credentials make supply chain attacks much worse?
A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments. If those credentials are not scoped, rotated, and monitored like privileged identities, attackers can use them to publish malicious packages, access secrets, and spread laterally across trusted automation.
Q: How do teams know whether release integrity controls are actually working?
A: They should look for consistent automated coverage across signing, security checks, SBOM generation, and image signing, not just policy documents. If evidence is produced automatically at every release path, the control is working as designed. If teams still rely on exceptions or tribal knowledge, integrity remains uneven.
Q: What should organisations do after a CI/CD token or PAT is exposed?
A: Revoke the exposed token, invalidate any related sessions or cached secrets, and assume adjacent credentials may also be compromised. Then inspect release jobs, runners, package publishing paths, and downstream repositories for misuse. The goal is to collapse attacker access across the whole workflow chain before further tag, release, or package poisoning can occur.
Technical breakdown
How pull_request_target turns workflows into a secret exposure path
GitHub Actions pull_request_target runs in the context of the base repository, which means the workflow can access repository secrets and elevated permissions even when the triggering code comes from a fork. That makes it useful for certain review scenarios, but dangerous when the workflow also checks out or executes untrusted content. In the Trivy case, the workflow became an execution bridge between attacker-controlled input and privileged CI context. The critical mistake is assuming the workflow boundary is the same as the code boundary. It is not. Practical implication: restrict pull_request_target to the smallest possible set of read-only checks and avoid executing fork-supplied code in privileged jobs.
Practical implication: restrict pull_request_target to the smallest possible set of read-only checks and avoid executing fork-supplied code in privileged jobs.
Why mutable tags and release automation expand blast radius
Git tags are references, not immutable artefacts, unless the release process treats them as protected and verified. When an attacker can force-push tags or influence automated release jobs, consumers that pin to a tag inherit whatever code now sits behind that name. In a CI/CD supply chain, the release pipeline itself becomes the propagation mechanism. That is why tag integrity, release signing, and provenance checks matter as much as source review. The Trivy attack showed how a trusted project can become a distribution channel when release identity is weaker than repository identity. Practical implication: protect release tags, require signed provenance, and verify what a tag resolves to before consuming it.
Practical implication: protect release tags, require signed provenance, and verify what a tag resolves to before consuming it.
Why incomplete credential rotation leaves attacker access alive
Rotation only works when old credentials are invalidated everywhere, immediately, and atomically. If one token is refreshed while another survives, or if caches, runners, and release jobs still trust the old state, the attacker can return through the gap. The Trivy report makes clear that rotation during incident response is not just a hygiene task. It is a containment control. This is especially true for CI/CD non-human identities, where one PAT or service token often authorises broad repository and release operations. Practical implication: treat token revocation as a coordinated lifecycle event, not a series of ad hoc changes.
Practical implication: treat token revocation as a coordinated lifecycle event, not a series of ad hoc changes.
Threat narrative
Attacker objective: The attacker’s objective was to harvest high-value CI/CD and cloud credentials and then use trusted release and package channels to expand access at scale.
- Entry occurred through a misconfigured pull_request_target workflow that let an attacker execute payloads in a privileged GitHub Actions context.
- Credential access followed when the payload dumped process memory and extracted a high-value Personal Access Token tied to the repository organisation.
- Escalation and propagation happened when surviving credentials were reused to poison tags, publish backdoored releases, and push malicious commits into the action supply chain.
- Impact was broad secret theft across CI/CD environments, downstream package compromise, and a self-propagating worm seeded through stolen tokens.
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).
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
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
CI/CD workflows now behave like non-human identities with their own lifecycle risk. The Trivy compromise shows that build jobs, release pipelines, and automated tokens are not just delivery plumbing. They are governed access paths with scope, revocation, and trust boundaries. Once those boundaries blur, the pipeline itself becomes the attacker’s identity layer, and practitioners should treat CI/CD credentials as first-class NHI assets.
Non-atomic rotation is a governance failure, not a response detail. The second Trivy attack succeeded because old trust state survived long enough to be reused. That exposes a familiar assumption gap: teams often believe a rotated token is safe once a replacement exists, but shared runners, caches, and release automation can preserve the old authority. The failure mode is credential continuity after supposed revocation, and that should be named explicitly in incident reviews.
Mutable release references create a verification trust gap. Tag-based consumption is convenient, but it weakens provenance unless consumers verify what the tag points to at the time of use. In software supply chains, this is where identity and integrity meet: the project identity may be trusted, yet the artefact identity can still be swapped. Practitioners should view provenance, signed releases, and protected tags as compensating controls for that trust gap.
Supply chain security is moving from code review toward runtime and identity assurance. The Trivy case is a reminder that static checks alone do not stop poisoned pipelines, stolen tokens, or downstream secret harvesting. The field is converging on lifecycle controls for machine identities, build provenance, and release integrity. Teams that still separate these functions will keep discovering that their control model breaks at the point of handoff.
Secret theft in CI/CD is now a cascading risk pattern, not a point event. The important question is no longer whether a single token was exposed. It is whether the compromised identity can reach release systems, cloud providers, package registries, and developer endpoints before containment closes. That makes blast-radius containment the decisive governance objective for supply chain teams.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
CI/CD pipelines need to be governed as identity systems, not just build systems. Once runners, release jobs, and tokens can publish artefacts or reach cloud services, they carry the same lifecycle risk as any privileged non-human identity. That means inventory, ownership, revocation, and separation of duties must apply to build identities as tightly as they do to human admins.
Release provenance is becoming the practical line between trust and compromise. The Trivy pattern shows why teams need to care about signed artefacts, protected tags, and immutable references before they care about packaging convenience. If the release reference can be moved after approval, the approval model is already too weak.
CI/CD secret exposure is a blast-radius problem, not a single-control problem. The Trivy incident demonstrates how a workflow misconfiguration can cascade into repository hijack, release poisoning, and downstream package abuse in one chain. That is why teams should measure whether one compromised build identity can reach multiple environments, not whether one control is enabled.
For practitioners
- Harden privileged GitHub Actions workflows Reserve pull_request_target for the smallest possible read-only checks and forbid execution of fork-supplied code in jobs that can access secrets or write permissions.
- Protect release tags and provenance Lock down mutable tags, require signed release provenance, and verify that consumed artefacts still match the approved commit and author chain.
- Treat CI/CD tokens as coordinated NHI assets Inventory PATs, service accounts, registry credentials, and cloud keys used by build and release automation, then revoke old values atomically during incident response.
- Separate build trust from consumer trust Require downstream teams to pin versions to immutable references and validate release integrity before promoting packages or images into production.
- Monitor for abnormal secret-harvesting behaviour Look for process-memory reads, broad environment-variable access, unexpected outbound connections, and repository events that indicate a workflow is acting as a credential stealer.
Key takeaways
- The Trivy compromise revealed that CI/CD workflows, release tags, and pipeline tokens can act as privileged identities with their own lifecycle risk.
- ARMO describes two attacks in March 2026 that together led to release poisoning, tag hijacking, and theft of CI/CD secrets across thousands of workflows.
- The limiting control is not a single scanner or workflow rule, but atomic revocation, protected release integrity, and strict separation between untrusted input and privileged jobs.
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 CIS Controls v8, NIST CSF 2.0 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-02 — Secret Leakage | The article centers on CI/CD secrets stolen from privileged workflows and reused downstream. |
| NHI-05 — Overprivileged NHI | The compromised workflow and tokens had more access than the release task required. | |
| NHI-07 — Long-Lived Secrets | The attack chain depended on credentials that survived incomplete rotation. | |
| Recommendation — Scan build and release systems for secret leakage paths and revoke exposed CI/CD credentials immediately. Reduce CI/CD token scope so build identities cannot publish or mutate resources beyond their job. Shorten the lifetime of pipeline secrets and make rotation atomic across all dependent jobs. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incident moved from secret theft into broader supply chain compromise and downstream spread. |
| Recommendation — Map CI/CD compromise paths to credential access and lateral movement to prioritise detection and containment. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI/CD tokens, service accounts, and release identities all require lifecycle governance. |
| Recommendation — Apply account management controls to every build and release identity, including ownership and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about excessive and poorly contained access in CI/CD identities. |
| Recommendation — Review entitlements for CI/CD identities and remove any access not required for the release task. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The attack relied on weak authenticator rotation and lingering token validity. |
| Recommendation — Enforce authenticator lifecycle controls so exposed CI/CD credentials are revoked and replaced atomically. | ||
Key terms
- CI/CD Identity: CI/CD identity is the set of credentials and permissions used by build, test, and deployment systems to act in software delivery pipelines. It includes service accounts, tokens, keys, and certificates that let automation access code, artifacts, cloud resources, and deployment targets. Strong governance limits exposure, scope, and lifetime.
- Pull Request Target Risk: A workflow risk pattern where untrusted pull request content is processed in a privileged context. Because the job may run with write access or access to secrets, the boundary between review and execution collapses. The control failure is not the pull request itself, but the permissions attached to the trigger.
- Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.
- Atomic Rotation: Atomic rotation is the coordinated replacement of a credential so the old value is invalid everywhere at the same time. In incident response and routine lifecycle control, it prevents attackers from keeping access through stale tokens, cached trust, or partially updated systems.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity lifecycle control to the operational risks that modern CI/CD pipelines create.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org