Skip to main content
Back to Blog
Security
March 23, 2026
11 min read
Pantoja Digital

The Tool That Finds Vulnerabilities Was Compromised. Who's Scanning the Scanners?

Trivy's GitHub Action was compromised in a supply-chain attack. Here's what it means for your business security.

Share

Imagine hiring a security guard to protect your business. They show up on time, check every door, and hand you a clean report every morning.

Then you find out someone's been stealing from your safe for months — through the security guard.

That's essentially what happened to companies using Trivy, an open-source vulnerability scanner. The tool that's supposed to find security holes became one.

What Is Trivy, and Why Should You Care?

If you're not a developer, you've probably never heard of Trivy. But there's a very good chance your development team — or the agency that built your website — is using it right now.

Built by Aqua Security, Trivy is used to scan code, containers, and infrastructure for security issues. It's free, it's fast, and it integrates directly into the automated pipelines (called CI/CD) that companies use to build and deploy software.

Think of it like a spell-checker, but for security. It can run in a build pipeline and flag detected risks.

When Trivy says "all clear," companies move forward with confidence. When Trivy gets compromised, that confidence becomes a liability.

What Happened: The Attack, Explained Simply

In March 2026, security researchers discovered that Trivy's GitHub Actions — the automated workflows companies use to run Trivy in their build pipelines — had been compromised through a supply chain attack.

Here's how it worked, in plain English:

Step 1: Poisoning the Pipeline

GitHub Actions are reusable automation scripts that developers reference by "tags" — version labels like v1 or latest. When you set up Trivy in your pipeline, you tell it to use a specific tag of the official Trivy Action.

The attackers found a way to modify the code behind those tags without changing the tag itself. It's like someone replacing the pills in a medicine bottle without breaking the seal. The label says "Trivy v1," but the code inside is now something else entirely.

Step 2: Exfiltrating Secrets

When companies ran their normal build pipelines — which they do dozens or hundreds of times per day — the compromised Trivy Action executed the attacker's code alongside the legitimate scan. That code was designed to do one thing: steal secrets.

API keys. Authentication tokens. Cloud credentials. Database passwords. Anything stored as a "secret" in the CI/CD environment was silently exfiltrated to attacker-controlled servers.

Step 3: Silent Extraction at Scale

The beauty of supply chain attacks — from the attacker's perspective — is scale. The attackers didn't need to break into each company individually. They compromised one tool, and every company using that tool in their automated pipelines became a victim simultaneously.

Why This Matters for YOUR Business

You might be thinking: "We're a small business. We don't use Trivy. This doesn't affect us."

Think again. Here's why this matters for every business, regardless of size:

Your Developers Might Be Using It Without You Knowing

Most business owners don't know the specific tools their developers or agencies use. If you hired a firm to build your website, set up your chatbot, or manage your cloud infrastructure, there's a reasonable chance Trivy — or a similar open-source tool — is part of their pipeline.

You trust your vendor. Your vendor trusts Trivy. Trivy got compromised. That's a trust chain, and the weakest link just broke.

Supply Chain Attacks Are the Fastest-Growing Threat

Attackers have figured out something important: why attack thousands of companies individually when you can attack one tool they all share?

The SolarWinds attack in 2020 and the Log4j vulnerability disclosed in 2021 both showed how widely shared technology can create broad downstream risk. The Trivy incident is another reminder to scrutinize the tools inside a software supply chain.

Attackers don't break into your front door anymore. They compromise the tools you trust — the security scanner, the logging library, the CI/CD plugin — and walk right through the door you opened for them.

The Security Guard Analogy

You shouldn't place unconditional trust in any security scanner.

The incident reveals a deeper problem: our entire approach to security has a single-point-of-failure problem.

The Deeper Problem: Blind Trust in Security Tools

Here's the uncomfortable truth that most businesses don't want to hear:

Running a vulnerability scanner doesn't mean you're secure. It means you've checked a box.

Scanners Follow Checklists. Attackers Don't.

Automated scanners like Trivy can check for known vulnerabilities, misconfigurations, exposed secrets, and other detectable risks.

That's valuable. It catches a lot of real problems. But it has fundamental limitations:

  • They can't find everything. Zero-day vulnerabilities, novel attack techniques, and creative exploitation chains may require other methods.
  • They don't think like attackers. A scanner checks if your front door is locked. An attacker checks the windows, the garage, the dog door, and whether your smart doorbell has a known firmware exploit.
  • They don't understand context. A scanner might flag a medium-severity vulnerability that's actually critical in your specific deployment, or miss a combination of low-severity issues that together create a devastating attack path.

The Green Checkmark Problem

There's a dangerous psychology at play. When a scan comes back clean — green checkmarks across the board — businesses feel safe. They move on. They deploy.

But that green checkmark only means: "We didn't find any of the specific things we were looking for."

It doesn't mean there are no vulnerabilities. It doesn't mean an attacker can't get in. It especially doesn't mean your chatbot isn't leaking customer data through prompt injection — because most scanners don't even test for that.

A company can run Trivy, get a clean report, deploy their agent, and have a hacker extract their entire system prompt, customer database access credentials, and internal business logic through a carefully crafted conversation. The scanner would never know. The green checkmark would still be green.

Automation Has Changed the Game — Scanners Haven't Caught Up

The rise of agents, chatbots, and LLM-powered tools has introduced entirely new categories of vulnerabilities that traditional scanners were never designed to detect:

  • Prompt injection — tricking an agent into executing attacker instructions
  • Jailbreaking — bypassing safety guardrails to make an agent do things it shouldn't
  • System prompt extraction — stealing the confidential instructions that define how an agent behaves
  • Data exfiltration through conversation — using natural language to make an agent reveal sensitive information
  • Indirect prompt injection — hiding attack instructions in documents or web pages the agent processes

These risks require testing beyond dependency and configuration scanning.

What Real Security Testing Looks Like

If scanners aren't enough, what is? The answer isn't to stop using scanners — it's to stop using only scanners.

Defense in Depth: Layers, Not Silver Bullets

Real security has always been about layers. A castle doesn't rely on just a moat. It has walls, gates, guards, towers, and a keep. Each layer exists because the ones before it might fail.

Your security posture should work the same way:

  1. Automated scanners (like Trivy) catch known vulnerabilities — they're your first filter
  2. Adversarial testing probes your systems the way real attackers do — finding what scanners miss
  3. Continuous monitoring detects new vulnerabilities as they emerge over time
  4. Incident response planning ensures you're prepared when something does get through

Most businesses have layer one. Almost none have layers two through four. That's the gap where breaches happen.

Thinking Like an Attacker

Adversarial testing — sometimes called penetration testing or red teaming — means deliberately trying to break your systems using the same techniques attackers use. It's not about checking boxes on a list. It's about creative, adaptive probing that follows the path of least resistance, just like a real attacker would.

NullShield was built for this kind of adversarial testing. We test over 500 attack patterns across agents, websites, and APIs, including agent-specific attack vectors. We don't just check if your front door is locked. We try other plausible entry points.

When we test a chatbot, we don't scan its code for known CVEs. We talk to it. We try to extract its system prompt. We attempt prompt injection attacks. We probe for data leakage. We test whether its guardrails actually hold up under pressure. We do what hackers do — because that's the only way to know if your defenses actually work.

The Difference Is Methodology

A scanner asks: "Does this match a known vulnerability pattern?"

NullShield asks: "Can I break this? How? What can I access if I do?"

That difference in approach is the difference between compliance theater and actual security.

The "Scanning the Scanners" Approach

The Trivy incident teaches us something important: even security tools need to be tested. Trust, but verify. Then verify the verification.

What This Looks Like in Practice

Regular testing, not one-and-done. A security scan from six months ago is ancient history. New vulnerabilities are discovered daily. Your systems change. Your threat landscape changes. Monthly or quarterly testing catches what a single annual assessment misses.

Multiple perspectives, not one tool. No single tool — no matter how good — catches everything. Layer automated scanning with adversarial testing. Use different tools. Get outside perspectives. If your only security measure is running one scanner, you have one layer. One layer is not defense in depth.

Human-guided automation testing. This is where NullShield stands out. We combine automated testing with human expertise to test your systems adaptively. Our testing engine doesn't just follow a script — it learns, adapts, and explores based on what it finds. When it hits a potential vulnerability, it digs deeper. When a guardrail blocks one approach, it tries another.

Continuous monitoring for emerging threats. The security landscape changes constantly. A system that was secure last month might be vulnerable today because of a newly discovered attack technique or a dependency update that introduced a flaw. Monthly monitoring catches these emerging threats before attackers do.

What You Should Do Right Now

The Trivy supply chain attack is a wake-up call, but it's also an opportunity. Most of your competitors will read the headline, think "that's a developer problem," and move on. You can do better.

1. Audit Your Security Tools

Find out what security tools your development team or agency is using. Ask specifically:

  • What scanners are in our CI/CD pipeline?
  • Are we using GitHub Actions from third parties?
  • How do we verify the integrity of our tooling?
  • When was the last time we rotated our secrets and credentials?

If your developers use Trivy through GitHub Actions, ensure they've updated to verified, pinned versions (using commit SHA hashes, not mutable tags) and have rotated all secrets that may have been exposed.

2. Stop Relying Solely on Automated Scanners

Automated scanners are valuable. Keep using them. But recognize them for what they are: one layer of a multi-layer strategy. They catch the known, the obvious, the cataloged. They miss the novel, the creative, the agent-specific.

If your entire security strategy is "we run a scanner," your entire security strategy has a single point of failure — as Trivy's users just learned the hard way.

3. Get an Independent Security Assessment

You need someone who thinks like an attacker — not like a checklist. An independent assessment that probes your agents, websites, and APIs using real-world attack techniques will show you what your scanners can't.

This isn't about finding fault. It's about finding vulnerabilities before someone with bad intentions does. Every finding is a problem you get to fix before it becomes a breach, a lawsuit, or a headline.

4. Implement Continuous Security Monitoring

Security isn't a project. It's a process. One assessment, no matter how thorough, becomes outdated the moment your system changes. Monthly monitoring ensures you stay ahead of emerging threats and catch new vulnerabilities as they appear.

The Bottom Line

The Trivy supply chain attack is a clear signal: the tools we trust to keep us safe are themselves targets. Relying on any single tool, any single scanner, any single layer of defense is a bet you will eventually lose.

Real security means testing your systems the way attackers actually attack them. It means layers, not silver bullets. It means regular testing, not annual checkboxes. And it means having someone on your side who thinks like a hacker — not like an auditor.

Your scanner can be hacked. Your agent can be jailbroken. Your trust can be exploited.

The question isn't whether your systems have vulnerabilities. They do. The question is whether you'll find them first — or whether someone else will.


Ready to find out what your scanners are missing? NullShield tests agents, websites, and APIs using 500+ attack patterns — including the agent-specific threats that automated scanners don't even know to look for.

<a href="/buy?service=nullshield-full" className="inline-flex items-center gap-2 rounded-lg bg-red-500 px-6 py-3 font-semibold text-white hover:bg-red-600 transition-colors">Book a NullShield Scan — We Test What the Scanners Miss →</a>

Share

Newsletter

Get agent security and systems notes in your inbox

Join our newsletter for agent security, automation ideas, website strategy, and practical updates from the studio.

Ready to get started?

Book a free discovery call and let's build your digital systems strategy together.

Book a Discovery Call