Why Software Supply Chain Security Isn’t Optional

Worms are great for fishing.

Worms are not great for the npm ecosystem.

Look no further than November 2025, when security researchers began tracking something unusual spreading through the npm ecosystem. A worm wasn’t just infecting packages, it was making more of itself. This malware, once installed, harvested credentials from developer machines and cloud environments. Those stolen credentials were used to log into victims’ own npm accounts and republish their packages, appending itself to software that thousands of other companies were already using.

Within days, nearly 800 packages representing more than 20 million weekly downloads were compromised. Researchers named it Shai-Hulud 2.0, and it was the second worm of its kind following a similar attack in September 2025.

The worm rides in on something a team already trusts, and by the time you notice, that trust was used against them. This is the reality of supply chain security.

Software supply chain security is about protecting every step between code being written and code running in production. This includes third-party tools, and other pipelines a team may use to build or deploy code.

We aren’t naive enough to think Basis Theory is somehow immune to this type of supply chain security attack. It’s becoming a part of how we think about protecting our platform.

Why are we talking about software supply chain security? 

Openly talking about supply chain security carries risk. We aren’t inviting anyone to test us, and we are not making any special claims about our infrastructure.

But when a company is hit by a supply chain attack, a compromised dependency can be painful, but contained.

Basis Theory doesn’t think about it that way.

We sit in the path of payment data for the companies that use us. That means a compromised dependency isn’t just a problem for our developers or CI pipeline, it’s a problem for every customer routing data through the infrastructure we’re responsible for. The blast radius isn’t just our engineering organization, it’s everyone downstream of us

Which is why we’re talking about, and dealing with, the threat of software supply chain security instead of acting like the risk doesn’t exist.

Return to Top

What does supply chain security actually cover? 

Every modern application is built out of far more code than any one team writes themselves. A typical project might have a few dozen direct dependencies, and each of those depends on more, and those depend on more. The software you ship is a tree with thousands of nodes.

That covers a few distinct things that often get lumped together:

• Dependency integrity. Is the package you're pulling in actually the package you think it is, and hasn't it been tampered with since a legitimate maintainer published it? This is the layer Shai-Hulud 2.0 attacked directly, by using stolen credentials to republish trusted packages with malicious code quietly added.
• Build and CI/CD pipeline integrity. Even if every dependency is clean, the systems that assemble, test, and deploy your code are their own attack surface. A compromised build tool, a poisoned CI/CD action, or an overly permissive automation credential can insert malicious code after the fact, even into software that started out safe.
• Provenance and trust verification. Can you actually prove that the code running in production is the code that was reviewed and approved, and that nothing was substituted along the way? This is less about catching a known-bad package and more about being able to answer "how do we know?" with confidence rather than assumption.
• Vendor and tooling risk. Every third-party tool, library, or service you depend on inherits its own supply chain risk into yours. Trusting a dependency means trusting everyone that dependency trusts, whether or not you've ever heard of them.

None of these are solved by a single tool or a single decision. They're different problems that happen to share a name, and a serious approach to supply chain security means treating them as a layered set of defenses rather than a single checkbox.

Return to Top

How should we be thinking about supply chain security? 

There's no single fix for supply chain risk, so we don't treat it like one. The way we think about it is as a set of layers, each catching something the others might miss.

It starts before code ever reaches a build: a cooling-off period on newly published package versions, so a compromised package published an hour ago doesn't get pulled into production before anyone's had a chance to notice something's wrong. From there, protections extend to developer workstations, flagging or blocking suspicious installs before they land on a laptop in the first place. Our CI/CD pipelines get the same scrutiny.

We have also deployed a supply chain firewall, an application that sits in front of every package manager we use and monitors for malicious activity. This catches malicious packages before they reach any of our systems at all, workstation or pipeline.

None of these layers is perfect on its own. That's the point. A worm like Shai-Hulud 2.0 doesn't succeed because one control failed; it succeeds because it only needs one gap to get through. Layering defenses is how you shrink that gap, not how you close it forever.

That's really the invitation here. If you're evaluating any piece of infrastructure that touches sensitive data, payments or otherwise, supply chain security is worth asking about directly.

We'd rather be the kind of company with an answer ready. If you want to talk through how we approach this, or what it means for how we handle your data, we're glad to have that conversation.

Return to Top