Taking Down the Botnet Doesn’t Answer the Harder Question

CrowdStrike and Google’s Glassworm takedown is a genuine win. Two years of coordinated supply chain attacks, 300+ poisoned GitHub repositories, four command-and-control channels knocked offline. Real work, real results, and the teams involved deserve the credit.

Here’s what the story also reveals, though.

The Glassworm attackers didn’t break encryption or exploit a zero-day. They hijacked developer accounts that already had trusted status in the ecosystem. They published malicious extensions to marketplaces developers use daily. They paid for search results that looked like legitimate tooling. Once they had a foothold in a trusted repo, the software supply chain carried the rest. Downstream organizations pulled those dependencies the same way they pull any other dependency: because they had every reason to trust them.

That’s the part worth sitting with.

The pattern showing up everywhere right now

Glassworm ran for two years. Last week, the Mini Shai-Hulud campaign compromised dozens of popular open-source packages and caught at least one OpenAI developer in the process. In March, a suspected North Korean actor hijacked Axios, the HTTP client that millions of developers depend on. Three separate campaigns, same basic approach: find something trusted, compromise it upstream, let the supply chain handle distribution.

The approach keeps working because enterprise security is very good at telling you where code came from. It’s much less equipped to tell you what that code is going to do before it runs.

Signing confirms a publisher. It doesn’t confirm behavior. An SBOM tells you what’s inside a package. It doesn’t tell you what the package will do in your environment. An EDR catches suspicious execution, but it catches it after the artifact has already started running. Sandboxes can detonate a file, but they’re slow, they get bypassed by evasive samples, and the output is raw log data that takes an analyst to interpret.

None of those controls answer the question that supply chain attacks keep exploiting: should this artifact be allowed to run in the first place?

What Zero Trust for Code actually means

Zero Trust started as a network principle: don’t assume that traffic inside your perimeter is safe. Verify before you grant access, regardless of origin. That thinking eventually extended to identity and to devices.

It hasn’t been applied to software execution.

The default today is still: if the code came from a trusted source with a valid signature, it runs. That’s the assumption Glassworm was built around. And it works, repeatedly, because the trust model for software execution hasn’t caught up to how attackers actually operate.

Zero Trust for Code means no artifact gets a free pass based on where it came from. Every artifact gets evaluated for what it will actually do, against policy, before it executes. The output is a decision: allow, block, restrict, quarantine, or require review. With behavioral evidence behind it, documented, auditable, ready for the analyst or the regulator.

This isn’t a pitch for a product category. It’s a description of a control that the industry hasn’t built yet but increasingly needs.

What security teams should be asking today

The botnet is down. The technique it used is still viable.

The organizations best positioned against the next campaign won’t be the ones waiting for another takedown. They’ll be the ones that have an answer, at every point where code enters and executes in their environment, to the question: do we actually know what this is going to do?

Endpoint, CI/CD pipeline, email gateway, artifact repository: each of those is a place where untrusted code can arrive looking completely legitimate. Each of them needs a control that evaluates behavioral intent before execution, not after.

That’s the work. CrowdStrike did their part. Now it’s time for the rest of the industry to close the loop.