When the Trivy compromise hit in March, a cross-company group of supply chain researchers had it flagged, triaged, and documented before any of the major vendors published anything. Paul McCarty was one of them. He got the word out publicly on OpenSourceMalware while CrowdStrike, Wiz, and Socket were still catching up. The credit for catching Trivy belongs to the whole group. Paul was kind enough to sit down with me and walk through how this kind of work actually gets done.
I wrote about the Trivy attack a few weeks ago and kept circling back to one question. How does an informal network of researchers keep beating a billion dollar vendor stack to the punch? Paul’s answer is worth sitting with, because it isn’t about genius or luck. It’s about a threat model the vendor industry was never built for, and a people shortage nobody wants to fund.
I sent him six questions. He came back with something closer to a masterclass on why EDR platforms keep missing software supply chain attacks, why git was never built for security, and where the post-SolarWinds billions actually went.
—
1. You caught the Trivy compromise before CrowdStrike, Wiz, and Socket. Walk us through what that actually looked like. What were you doing when you noticed it, and what was the first thing that looked wrong?
Paul: I didn’t discover the trivy compromise. I’m part of an intel sharing group and I found out about it from that group. I jumped on it immediately and added a threat report and advisory on OpenSourceMalware. It’s super important that once you know that something is malicious you get the word out as quickly as possible so you can try and limit the blast radius that happens when a popular tool like Trivy is compromised. The reality is that Trivy is a great tool, and lots of orgs use it in production, which is why it was such a perfect target. I had Trivy installed across all my environments
Most of these big attacks are actually worked in parallel by researchers at multiple companies, which is funny at the end because everyone claims “discovering” it.
2. You’ve said EDR vendors flat out can’t detect malicious interpreted malware like Python or JavaScript. For people who haven’t thought about this, why? What makes a malicious pip install invisible to something like Falcon?
Paul: EDR platforms like CrowdStrike, SentinelOne and Windows Defender are all built to detect classic binary based malware or ransomware. So, in practice this means they over index on two things: first, they detect file hashes of known bad files. If they’ve seen a binary or dll before, they’ll have the hash and if that hash shows up anywhere else, they already know its bad and they block it. Okay, then the second thing that EDR does: they identify malicious behaviour related to things like ransomware. So for example, EDR will detect if a number of files is encrypted in a short period of time. If one or two files are encrypted, the EDR doesn’t do anything because that’s normal behaviour: people compress files, etc. But if you see 50 files get compressed then the EDR can step in and say “this is anomalous, lemme block that”.
Open-source malware, which is 99% interpreted JavaScript or Python, doesn’t do any of those things. First, there’s no point in using filehashes for interpreted files like .py or .js. If you block a filehash, the bad guy will just add a single zero to the file, and publish a new version, and your security control has been bypassed.
You can see this on VirusTotal, and the sandboxes like Joe’s and Any.run: they don’t detect interpreted payloads. I have dropped thousands of JavaScript and Python payloads into VT, and the EDR vendors never detect them. The only company that actively detects JavaScript malware in that space is Kaspersky and their detection is very rudimentary.
Similarly, the behaviour of infostealers and cryptostealers is harder for EDR to detect. They do things once, and then move on. So for example, infostealers will look for files to exfil in browser directories, or they’ll look for certain browser extensions. Then they POST that data in a JSON blob to a webservice. This all happens via HTTP and blends into all the other web traffic. These are all actions that your browser, and other associated apps and processes do all day long. The behaviour just looks normal. And even if an EDR vendor finds some way to detect malicious Javascript for example, the threat actor will just push a new version of it because its just code after all. It’s not like a binary that needs to be compiled and distributed, which means that pushing a new version of a malicious binary payload takes time. That time works against the bad guy. With the case of highly iterative javascript payloads, the bad guy can produce 20 different versions in a day, which I have seen happen.
3. Git tags are mutable. Almost nobody pins GitHub Actions by commit SHA. Why hasn’t the industry fixed this after repeated tag based attacks?
Paul: Omg, you could ask the same type of question about why the industry doesn’t sign their commits, or use pre-commit git hooks to run security scans. The reality is that the engineering industry lags behind security best practices because the engineering leaders are really only incentivizing how fast the engineering teams (and individuals) can push new features and code.
About GitHub actions specifically: these actions aren’t widely understood, and so a lot of the behaviours we see is simply because the users of GitHub actions don’t really understand how it works.
4. You’ve been doing supply chain red teaming training at BSides for a couple years. When you’re teaching people to think like an attacker in this space, what’s the first thing you have to get them to unlearn?
Paul: Haha! great question! The first thing I start on is git. I show them very deliberately how git wasn’t built with security in mind. It accepts the user identity implicitly, which is why in 2026 I can still push a commit to GitHub as Linus Torvalds. It’s crazy.
Then I dive into how git commit history can be faked. GitHub and other SCM providers have spent a lot of time making us think that git commit history is an important function and validation. I mean, it’s attached to every single github user’s profile, right?
Well that thing is, that git commits and the git index itself all lives on your local machine, and you can make it say or do anything you want. You can then push it to GitHub and it trusts it all implicitly. So, yeah, that’s where I start. 🙂
5. If you had to bet, five years from now, are we better or worse at catching these?
Paul: Oh man. That’s tough. We are definitely gonna be better at catching certain attacks or malicious behaviours. Ai will definitely help us there.
But, circling back to your question about immutable tags in GitHub Actions, the reality is that we are moving really fast and using new tools all the time and that just means there’s a lot of room for a gap in security understanding. That gap is between us using a thing (like Claude) and us understanding the security implications of that thing.
Ai skills is a great example. My skills in Claude are awesome and automate a bunch of the hard parts of my job. But, by using Skills I open myself up to a new attack. Just this week I noticed that one of my sandboxes had a malicious AI skill in the .claude/skills directory. And skills, unlike python or javascript, don’t have well understood functions, classes and operating principles. You can basically put anything you want in an AI skill and then run it five times, and you will get five different bad outcomes.
6. After SolarWinds, enterprises poured billions into supply chain security. Automated scanning, dependency tracking, vendor risk platforms. And when Trivy got compromised, a cross-company research group caught it first. Where is that money actually going?
Paul: Oh the money spent on tools was appropriate. Before Solarwinds most orgs had zero fucking dollars for AppSec budgets. If Solarwinds did anything it unlocked budgets in this space. However, to your point, tools ain’t the only thing we need. We also need people with the right skill set and subject expertise guiding those tools and the industry has failed to build or encourage those subject matter experts. I guess they thought, if I buy the tools, they’ll magically fix all the things and we’ll all live happily ever after.
There aren’t many AppSec teams in Australia, but most of them that do exist are a team of one person. That one person ends up doing vuln management and triage for the tools that were bought after Solarwinds. They sit in between engineering teams and the AppSec tools and basically just help the former navigate the latter. It’s a shit show.
Organizations have systematically underfunded AppSec teams and it shows.
—
Laterstack take
Two things in Paul’s answers keep circling back for me, and I think they’re actually the same thing.
The obvious one is the people gap. After SolarWinds, every enterprise finally got an AppSec budget. All of it went to tools built for binary malware, which is the wrong threat model for 99% of what’s actually shipping. The people who understand the real threat, the ones who catch these things first, are sitting in one-person teams without the budget to breathe. Paul said it plain, and it should be printed on the wall of every CISO’s office.
The less obvious one is buried in his answer about AI. He mentioned finding a malicious AI skill in one of his sandboxes last week. Read that sentence again. The supply chain attack surface is already moving from npm and PyPI into .claude/skills directories, and there is zero mature tooling for it. No hash detection, no behavior signatures, no sandbox model anyone trusts. The same gap Paul is describing at the previous layer, moved one floor up, and nobody is ready for it.
What this means
For everyday users. You don’t run Trivy and you don’t install AI skills. But every app you trust with your data is built by developers who do. When a compromised dev tool siphons credentials or injects bad code into a build pipeline, the blast radius doesn’t stay inside engineering. It hits your bank, your health portal, your employer’s HR system, the app you use to talk to your kids’ teachers. Almost every “we’re writing to inform you of a data breach” email you’ve received in the last five years traces back to something that started on a developer’s machine and rolled downhill.
For technical people. If you’re a developer or running AppSec, Paul basically handed you a working checklist. Pin your GitHub Actions by commit SHA, not tag. Sign your commits. Run pre-commit hooks that actually scan. Don’t assume your EDR caught anything malicious in your last pip install or npm install, because Paul just told you it didn’t. And that AI skill you dropped into .claude/skills last week, treat it like a random package from an account you’ve never heard of, because that’s what it is until proven otherwise. The detection layer you’re counting on was built for a previous decade of threat, which means the burden is back on engineering judgment. The teams that survive this era will be the ones where developers and AppSec treat each other as peers, not as a tax on each other’s velocity.
For enterprises. If your AppSec team is one person and you’ve already bought the post-SolarWinds tool stack, Paul is telling you plainly that you don’t have a security program. You have a risk transfer document with scanners bolted to it. The companies that actually get this right over the next five years will have fewer tools and more subject matter experts, and they’ll be the ones not showing up in headlines.
For legislators and policymakers. The current regulatory frameworks on software supply chain (SBOM mandates in the US, the Cyber Resilience Act in the EU) assume the problem is transparency. Know what’s in your software. That’s useful, but it’s already one regulation behind the actual threat. The scanners you’re mandating visibility into were built for a threat model that isn’t the threat model anymore. You can mandate inventory all day on a detection layer that cannot see interpreted malware and has no framework at all for malicious AI skills, and you still end up with the same gap Paul is describing. Policy is already playing catchup, and AI skills means it’s about to be playing catch up on two fronts.
Paul McCarty runs OpenSourceMalware and teaches supply chain red teaming at BSides. The research on the Trivy compromise was a collaborative effort across a cross-company intelligence sharing group.