Notifications
Clear all
Topic starter
21/08/2026 4:52 pm
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.
NHIMG editorial — based on content published by ARMO: When Your Friend’s House Burns Down Twice: The Trivy Supply Chain Attacks Explained
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Harden pull_request_target workflows Separate untrusted pull-request validation from any workflow that can read repository secrets, write releases, or invoke privileged tokens.
- 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.
- 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.
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
👉 Read ARMO's analysis of the Trivy supply chain attacks and credential theft chain →
Trivy supply chain compromise: what CI/CD teams need to rethink?
Explore further
21/08/2026 5:10 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Trivy’s twin supply chain attacks expose CI/CD credential fragility
