TL;DR
- Trivy, one of the most popular open-source security scanners, had its GitHub Action compromised in March 2026, exposing secrets from CI/CD pipelines that used it [1]
- This attack follows the same pattern as the tj-actions/changed-files compromise — attackers target widely-used GitHub Actions to harvest secrets at scale [2]
- Supply chain attacks on CI/CD tooling are accelerating because a single compromised action can expose thousands of repositories simultaneously
- SMBs running GitHub Actions need to pin action versions to commit SHAs, audit their workflows, and rotate any secrets that may have been exposed
What Happened to Trivy's GitHub Action?
In March 2026, Aqua Security's Trivy — one of the most widely-used open-source vulnerability scanners — had its GitHub Action (aquasecurity/trivy-action) compromised [1]. The irony is sharp: a security scanning tool became the attack vector.
Get Our Weekly Cybersecurity Digest
Every Thursday: the threats that matter, what they mean for your business, and exactly what to do. Trusted by SMB owners across Australia.
No spam. No tracking. Unsubscribe anytime. Privacy
The attackers modified the ac
Free Resource
Weekly Threat Briefing — Free
Curated threat intelligence for Australian SMBs. Active campaigns, new CVEs, and practical mitigations — every week, straight to your inbox.
Subscribe Free →This wasn't a vulnerability in Trivy itself. The scanner's core codebase remained intact. Instead, attackers targeted the GitHub Action wrapper — the automation layer that integrates Trivy into CI/CD workflows. This distinction matters: even if your tools are secure, the supply chain around those tools can be compromised.
Related: AI Security Deployment Crisis — SMB Guide 2026
Why CI/CD Supply Chain Attacks Keep Happening
The Trivy breach didn't happen in isolation. It followed the high-profile compromise of the tj-actions/changed-files GitHub Action earlier in March 2026, which similarly leaked CI/CD secrets from repositories that referenced it [2]. That attack affected an estimated 23,000 repositories.
CI/CD pipelines are prime targets for supply chain attacks because of how GitHub Actions work. When you reference an action in your workflow file (e.g., uses: aquasecurity/[email protected]), you're running third-party code inside your build environment. That code has access to your repository secrets, environment variables, and often cloud deployment credentials.
Here's why attackers love this attack surface:
Scale. A single compromised action can harvest secrets from every repository that uses it. Unlike traditional attacks that target one organization, supply chain attacks deliver thousands of targets from a single intrusion.
Trust. Developers trust popular open-source actions implicitly. If a tool has thousands of GitHub stars and is maintained by a reputable company, most teams never audit the action's code — they just add it to their workflow.
Stealth. The malicious modification can be subtle. Exfiltrating secrets requires only a few lines of code — an HTTP request to an attacker-controlled endpoint embedded within a legitimate build step. Unless you're reviewing every action update line-by-line, you won't see it.
The CISA (Cybersecurity and Infrastructure Security Agency) has warned repeatedly about the growing threat of software supply chain attacks, noting that they exploit the trust relationships inherent in modern software development [3].
How the Attack Worked — A Technical Breakdown
Based on reporting from The Hacker News and Aqua Security's own disclosure [1], the Trivy GitHub Action compromise followed a pattern consistent with recent GitHub Actions supply chain attacks:
Step 1 — Compromise the action. Attackers gained the ability to modify the action's code. In the tj-actions case, this was done by compromising a maintainer's Personal Access Token (PAT) [2]. The exact mechanism for the Trivy action compromise is still under investigation, but the result was the same: malicious code was injected into the action.
Step 2 — Modify the action to exfiltrate secrets. The injected code dumped CI/CD secrets — typically by reading environment variables and the GitHub Actions runner's memory — and sent them to an external endpoint.
Step 3 — Harvest at scale. Every repository that ran the compromised action during the attack window had its secrets exposed. This includes API keys, cloud provider credentials, Docker registry tokens, and any other secrets stored as GitHub repository secrets.
Step 4 — Exploit harvested credentials. With valid credentials in hand, attackers can access cloud infrastructure, push malicious code, exfiltrate data, or pivot deeper into an organization's systems.
ISO 27001 SMB Starter Pack — $97
Threat intelligence is one thing — having the policies and controls to respond is another. Get the complete ISO 27001 starter kit for SMBs.
Get the Starter Pack →What This Means for SMBs Using GitHub Actions
If your business uses GitHub Actions for CI/CD — and many SMBs do, because it's free for public repos and affordable for private ones — you need to take this seriously.
Here's the reality: most SMBs don't have a dedicated DevSecOps team reviewing every GitHub Action they use. Developers add actions to workflows because they solve problems, and nobody audits the supply chain behind them.
The immediate risk: If you used aquasecurity/trivy-action or tj-actions/changed-files during the compromise window, your CI/CD secrets may have been exposed. That means your cloud credentials, API keys, and deployment tokens could be in an attacker's hands right now.
The ongoing risk: This pattern will repeat. GitHub Actions is an ecosystem of tens of thousands of community-maintained actions. Any of them could be compromised in the same way. Your CI/CD pipeline is only as secure as the least-trusted action in your workflow.
Related: Patch Management Speed — Why 20 Hours Changes Everything
How to Protect Your CI/CD Pipeline — Practical Steps for SMBs
You don't need a massive security team to protect your CI/CD pipeline. Here are concrete steps any business can take:
1. Pin GitHub Actions to Commit SHAs, Not Tags
Instead of referencing an action by its version tag (which can be modified by an attacker):
# RISKY — tag can be moved to malicious code
uses: aquasecurity/[email protected]Pin to a specific commit SHA:
# SAFER — immutable reference to a specific version
uses: aquasecurity/trivy-action@a1b2c3d4e5f6...Commit SHAs are immutable. Even if an attacker compromises the repository, they can't change what a specific SHA points to. This is the single most effective mitigation for GitHub Actions supply chain attacks.
2. Audit Your Current Workflows
Review every .github/workflows/*.yml file in your repositories. List every third-party action you use. For each one, ask:
- Is this action maintained by a reputable organization?
- When was it last updated?
- Am I referencing it by tag or by SHA?
- Does it need access to my secrets?
3. Use GitHub's Built-in Security Features
GitHub provides several features that help:
- Dependabot can alert you when actions you use have known vulnerabilities
- Required workflows let organization admins enforce security checks
- OIDC tokens can replace long-lived secrets for cloud deployments, reducing the impact of secret exfiltration
4. Apply the Principle of Least Privilege to Secrets
Don't give every workflow access to every secret. GitHub Actions allows you to scope secrets to specific environments and require approval for deployments. Use environment-level secrets instead of repository-level secrets where possible.
5. Rotate Exposed Secrets Immediately
If you used any compromised action during the attack window, rotate all secrets that were accessible to that workflow. This includes:
- Cloud provider credentials (AWS, Azure, GCP)
- Docker registry tokens
- API keys for any service
- NPM, PyPI, or other package registry tokens
- Database connection strings
Don't wait. Rotate now. Even if you're "probably fine," the cost of rotation is low and the cost of compromised credentials is high.
6. Monitor for Unauthorized Access
After rotating secrets, review your cloud provider's audit logs for any unauthorized access during and after the compromise window. Look for:
- Unusual API calls from unknown IP addresses
- New resources created that you didn't provision
- Data access patterns that don't match normal operations
The Bigger Picture: Security Tools Are Part of the Supply Chain
The Trivy compromise highlights a fundamental tension in modern software development. We use security tools to find vulnerabilities — but those tools are themselves software with their own supply chains, dependencies, and attack surfaces.
NIST's Secure Software Development Framework (SSDF) emphasizes that organizations must "protect all forms of code from unauthorized access and tampering" — and that explicitly includes the tools used to build, test, and secure code [4].
When a security scanner becomes the attack vector, it's a reminder that trust in the software supply chain must be verified, not assumed. Every tool in your pipeline — including the security tools — is a potential entry point.
FAQ
No. The vulnerability was in the GitHub Action wrapper (aquasecurity/trivy-action), not in Trivy's core scanning engine. If you run Trivy locally via the CLI rather than through GitHub Actions, you were not affected by this specific attack. However, the incident underscores the importance of verifying the integrity of all tools in your CI/CD pipeline, not just the core binaries.
Review your GitHub Actions workflow run logs for the period during which the action was compromised. Check if your workflows referenced aquasecurity/trivy-action by a mutable tag (like @v0.20.0 or @latest) rather than a pinned commit SHA. If they did, assume your CI/CD secrets were exposed and rotate them immediately.
A version tag (like v1.0.0) is a pointer that can be moved. If an attacker gains control of a repository, they can point v1.0.0 at malicious code. A commit SHA (like a1b2c3d4e5f6) is a cryptographic hash of a specific code state — it cannot be changed without altering the hash. Pinning to a SHA ensures you always run exactly the code you reviewed.
No. GitHub Actions remains a powerful and cost-effective CI/CD platform, especially for SMBs. The key is to use it securely: pin actions to SHAs, minimize the secrets accessible to workflows, use OIDC for cloud authentication when possible, and regularly audit your workflows. The risk isn't in GitHub Actions itself — it's in trusting third-party code without verification.
The most effective protections are: (1) pin all GitHub Actions to commit SHAs instead of tags, (2) scope secrets to specific environments using GitHub's environment protection rules, (3) use OIDC tokens instead of long-lived credentials for cloud access, (4) regularly audit which third-party actions your workflows use, and (5) monitor your cloud audit logs for signs of unauthorized access. No single measure is enough — defense in depth is the strategy.
References
[1] R. Lakshmanan, "Trivy Security Scanner GitHub Actions Compromise Exposes CI/CD Secrets," The Hacker News, Mar. 2026. [Online]. Available: https://thehackernews.com/2026/03/trivy-security-scanner-github-actions.html
[2] R. Lakshmanan, "tj-actions/changed-files GitHub Action Compromised, Exposing Secrets in 23,000 Repos," The Hacker News, Mar. 2025. [Online]. Available: https://thehackernews.com/2025/03/supply-chain-attack-github-action.html
[3] CISA, "Defending Against Software Supply Chain Attacks," Cybersecurity and Infrastructure Security Agency, Apr. 2021. [Online]. Available: https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf
[4] NIST, "Secure Software Development Framework (SSDF) Version 1.1," NIST Special Publication 800-218, Feb. 2022. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-218/final
[5] GitHub, "Security hardening for GitHub Actions," GitHub Docs, 2024. [Online]. Available: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
[6] Aqua Security, "Trivy — Comprehensive Security Scanner," Aqua Security, 2024. [Online]. Available: https://github.com/aquasecurity/trivy
[7] OpenSSF, "Scorecard — Security Health Metrics for Open Source," Open Source Security Foundation, 2024. [Online]. Available: https://securityscorecards.dev/
[8] NIST, "Cybersecurity Supply Chain Risk Management Practices," NIST SP 800-161 Rev. 1, May 2022. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final
Your CI/CD pipeline is business infrastructure. If it's compromised, your deployments, credentials, and customer data are all at risk. lilMONSTER helps SMBs audit their CI/CD security, implement supply chain protections, and respond to incidents like the Trivy breach. Book a supply chain security assessment →
Work With Us
Ready to strengthen your security posture?
lilMONSTER assesses your risks, builds the tools, and stays with you after the engagement ends. No clipboard-and-leave consulting.
Book a Free Consultation →TL;DR
- A popular security tool called Trivy was tricked into stealing passwords from the software factories that used it
- It's like hiring a security guard for your building, but someone secretly replaced the guard with a spy
- This kind of attack is called a "supply chain attack" — instead of breaking in, the bad guys sneak in through something you already trust
- Businesses can protect themselves by checking exactly which version of their tools they're using
What Happened?
Imagine your school has a security guard who checks everyone's backpack at the door. You trust this guard — they've been doing their job for years. But one day, someone secretly replaces the real guard with a lookalike who not only checks backpacks but also copies down all the locker combinations they can find, and secretly sends them to a thief.
That's basically what happened with Trivy. Trivy is a security tool that developers use to check their software for problems. Thousands of companies use it every day as part of their software-building process. Someone managed to tamper with Trivy's setup so that instead of just checking for problems, it also quietly collected secret passwords and keys from the companies using it.
What Is a "Supply Chain Attack"?
A supply chain is everything that goes into making something. When you buy a sandwich, the supply chain includes the farmer who grew the wheat, the baker who made the bread, and the shop that sold it to you.
Software has a supply chain too. When a company builds software, they don't write everything from scratch — they use tools and pieces of code made by other people. A supply chain attack happens when a bad guy sneaks something harmful into one of those trusted tools or pieces of code.
It's sneaky because you're not breaking in through a locked door. You're hiding inside something that's already invited in.
Why Should My Business Care?
If your business builds or uses custom software — even a simple website — there's a good chance your developers use tools like Trivy. Those tools have access to important secrets like passwords, keys to your cloud services, and codes that let you publish updates.
If one of those tools gets tampered with, all those secrets could be stolen. It's like someone copying your house key while you're at the locksmith.
What Can You Do?
Here are three things any business can do:
Lock in the exact version of every tool you use. Instead of saying "use the latest version," say "use this exact version, confirmed by its unique fingerprint." This way, even if someone tampers with the tool, your systems will keep using the safe version you originally chose.
Keep a list of all the tools your software uses. You can't protect what you don't know about. Make sure someone in your team knows every tool and piece of code that goes into building your products.
If something was compromised, change your passwords immediately. If you found out the locksmith's apprentice was copying keys, you'd change your locks right away. Same idea — rotate all the secret keys and passwords that the compromised tool could have accessed.
The good news: protecting yourself from supply chain attacks doesn't require expensive security software. It requires attention, good habits, and making sure you know exactly what's running in your software factory.
Want help making sure your software tools are safe? lilMONSTER helps small businesses check their software supply chain and build better security habits. Talk to us →
