Trivy’s twin supply chain attacks expose CI/CD credential fragility

At a glance

What this is: Trivy was compromised twice in under a month, first through a GitHub Actions workflow weakness and then through surviving credentials that enabled poisoned releases and tags.

Why it matters: This matters to IAM practitioners because CI/CD tokens, service accounts, and release automation behave like non-human identities, and a single weak lifecycle control can turn trusted pipelines into propagation channels.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read ARMO's analysis of the Trivy supply chain attacks and credential theft chain

Context

Trivy’s double compromise is a supply chain and identity governance problem, not just a source-code incident. The first attack exploited a GitHub Actions workflow pattern that handed attacker-controlled code access to privileged credentials, and the second showed what happens when token rotation and release controls are not truly atomic.

In CI/CD environments, service accounts, Personal Access Tokens, GitHub Actions tokens, and registry credentials function as non-human identities with high blast radius. Once those credentials are stolen or left active during remediation, attackers can pivot from pipeline access into release poisoning, package tampering, and downstream compromise.

The article’s starting position is atypical only in scale, not in structure: the same trust assumptions that exist in many build systems made this attack possible, but Trivy’s reach turned a familiar control failure into a major ecosystem event.

Key questions

Q: What breaks when CI/CD workflow actions or build credentials are tampered with?

A: A poisoned workflow action can turn trusted automation into a credential-exfiltration path, especially when runners hold deployment tokens, cloud keys, or signing material. The break point is not just the build itself. It is the assumption that a pinned dependency or reusable action is stable. Teams should treat build systems as high-trust NHI environments and verify provenance continuously.

Q: Why do standing CI/CD tokens create so much risk in supply chain attacks?

A: Standing tokens remain usable long after the moment they were created, so a compromise can persist through normal operations and even through partial remediation. In supply chain environments, that means one stolen token can be reused to push artefacts, alter tags, or seed downstream packages. Short-lived access and verifiable revocation are the controls that reduce that exposure.

Q: How do security teams know if credential rotation actually worked?

A: They need proof that every consumer rejected the old credential, every dependent workflow has moved to the replacement, and no residual access path still functions. A rotation is not complete until validation shows the old secret is dead everywhere it mattered. Without that verification, response teams are guessing.

Q: Who is accountable when a compromised pipeline publishes malicious packages?

A: Accountability usually sits with the organisation that issued the publishing credential, maintained the pipeline trust boundary, and failed to constrain release authority. In practice, this is an IAM, DevSecOps, and platform governance issue together, not a developer-only mistake.

Technical breakdown

How pull_request_target workflows expose privileged credentials

GitHub Actions workflows triggered by pull_request_target run in the context of the base repository, which means they can access secrets and permissions intended for trusted automation. If that workflow also checks out or executes attacker-influenced code, the attacker can convert a routine validation step into a secret-harvesting path. In this case, the malicious payload ran inside the workflow and dumped process memory to extract a high-privilege token. The technical issue is not GitHub Actions itself, but the combination of privileged execution, untrusted input, and insufficient separation between review and runtime.

Practical implication: isolate untrusted pull-request logic from any workflow that can reach repo-level secrets or privileged tokens.

Why incomplete credential rotation leaves a standing access window

Rotation only works if old credentials are invalidated everywhere before the attacker can reuse them. If the old token, mirror, cached secret, or delegated grant survives even briefly, the attacker can continue operating while defenders believe containment is complete. That creates a race between response teams and the adversary, especially in release pipelines where a single surviving token can re-tag versions, republish binaries, or modify metadata. Atomic revocation matters because non-human identities are often embedded in automation, mirrors, and build jobs that do not fail closed when one credential is replaced.

Practical implication: treat credential rotation as a coordinated revocation event, not a piecemeal update.

How tag poisoning turns trusted releases into malware delivery

Mutable tags create a dangerous trust shortcut because downstream users often pin names, not immutable commits. When an attacker force-pushes a tag, the visible version string stays familiar while the underlying code changes completely. In this incident, the malicious commit preserved enough metadata to look authentic at a glance, then shipped a payload that executed first and scanned second. That is a classic software supply chain deception pattern: preserve the surface signal of legitimacy while swapping the underlying artifact. Monitoring systems that only watch create or delete events can miss the change entirely.

Practical implication: prefer immutable commit references and alert on tag movement, not just release publication.

Threat narrative

Attacker objective: The attacker objective was to harvest high-value credentials and convert a trusted open-source release pipeline into a scalable malware and access-distribution channel.

1. Entry occurred through a misconfigured GitHub Actions pull_request_target workflow that let attacker-controlled input reach privileged automation.
2. Credential access followed when the malicious payload dumped process memory and extracted a repository-scoped Personal Access Token.
3. Escalation and impact came when the stolen token was used to delete releases, poison tags, publish backdoored binaries, and seed downstream credential theft across packages.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD tokens are non-human identities, and they fail like identities, not like code. The Trivy incident shows that build credentials, release tokens, and service account secrets need the same lifecycle discipline as any other privileged identity. When rotation is incomplete or execution is overly trusted, the pipeline itself becomes the breach path. The practitioner conclusion is simple: govern pipeline credentials as standing access with explicit revocation boundaries.

Atomic revocation is the governance gap this breach exposed. The article makes clear that the first response did not fully close the access window, which allowed the second attack to reuse surviving credentials. That is not just an operational miss, it is a lifecycle failure in how organisations validate that old access is gone before new access is assumed safe. The conclusion for practitioners is to test revocation completeness, not just rotation completion.

Named concept: pipeline trust inheritance. This is the pattern where a trusted CI step inherits privilege from the repository, the runner, and the release process all at once. The more layers that inherit trust automatically, the easier it is for a single misconfiguration to become a supply chain compromise. Practitioners should map where inherited trust crosses from validation into release authority.

Immutable provenance has to become a release control, not a documentation control. The attack succeeded partly because tag movement and release metadata could be made to look normal. That means the control problem is provenance enforcement across publishing, signing, and downstream consumption, not merely artifact storage. Practitioners should assume any mutable release reference is a candidate for abuse unless proven otherwise.

Open-source maintainers now sit inside the same governance problem as enterprise buyers. The attackers used community trust to amplify impact, but the real weakness was the lack of strong guardrails around secret exposure and release mutation. That widens the responsibility model for both maintainers and consumers. The conclusion is that ecosystem trust must be backed by verifiable lifecycle controls, not reputation alone.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Forward look: Explore 52 NHI Breaches Analysis for the recurring lifecycle failures that let exposed credentials become breach paths.

What this signals

Pipeline identity governance will now sit closer to release engineering. The Trivy attack shows that build credentials are not a niche DevOps concern, they are a governance boundary for access, provenance, and revocation. Teams that already manage secrets and non-human identities should expect more pressure to prove that build-time access can be isolated, rotated, and audited with the same discipline as production privilege.

Pipeline trust inheritance: this is the pattern in which a workflow inherits authority from the repository, the runner, and the release process at the same time. Once that inheritance is visible, the next step is to break it into smaller trust domains and add explicit controls at each boundary. The relevant external reference point is the OWASP Non-Human Identity Top 10, which aligns well with token lifecycle and overprivilege risk.

The operational signal is not just whether a secret leaked, but whether the organisation can prove that the old credential was eliminated everywhere the pipeline could reach. That is where secrets management, release governance, and identity lifecycle control start to converge. For teams building policy around non-human identities, this is a reminder that rotation without verification is only half a control.

For practitioners

• Harden pull_request_target workflows Separate untrusted pull-request validation from any workflow that can read repository secrets, write releases, or invoke privileged tokens. Review every job that combines forked code with base-repository permissions, and remove secret-bearing steps from that path. Focus on the workflow files that can reach release authority.
• Make credential revocation atomic Rotate and revoke the old token, not just issue a replacement, then verify that caches, mirrors, runners, and delegated grants no longer accept the prior credential. Validate the entire path with a negative test before declaring containment complete.
• Pin consumers to immutable references Replace tag-based dependency trust with commit SHAs or equivalent immutable references for critical build inputs, and monitor for tag movement as a security event. In CI, treat mutable release tags as untrusted metadata rather than a source of assurance.
• Monitor for secret-harvesting behaviour in pipelines Look for process memory access, unexpected environment variable reads, and outbound calls from build jobs that do not match the expected scanner or release profile. Add detections for pipeline behaviour that resembles credential theft, especially when the job still appears to complete normally.

Key takeaways

• The Trivy compromise shows how a single workflow misconfiguration and incomplete token rotation can turn trusted CI/CD automation into a supply chain breach.
• The scale matters because the attackers moved from one repository token to poisoned releases, forced tag rewrites, and downstream package propagation.
• The control that would have limited the damage is atomic revocation paired with immutable release references and workflow separation.

Key terms

• Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
• Atomic Credential Rotation: A credential replacement process that invalidates the old secret everywhere before the new one is treated as trusted. In security operations, atomic rotation matters because partial updates leave surviving access paths that attackers can continue to use.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Platform Trust Inheritance: The tendency to carry forward trust assumptions from an older platform into newer identity and access environments. It often appears harmless because the original model felt controlled, but it becomes risky when cloud services, delegated access, and machine identities scale beyond the original design.

What's in the full article

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

• The exact malicious workflow path in apidiff.yaml and how the pull_request_target pattern enabled token theft
• The full tag-poisoning method used to rewrite 75 of 76 release tags without changing the visible workflow file
• The forensic indicators that distinguished the malicious commits from legitimate maintainers' releases
• The downstream canister-based C2 and npm worm propagation details for teams investigating exposure

👉 ARMO's full post covers the attack timeline, tag poisoning mechanics, and containment lessons in detail.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives practitioners a practical framework for governing privileged automation across build, release, and runtime environments.