Your Real Vendor List Has 50,000 Names — and April 2026 Proved It

A 42-Minute Window Nobody Was Watching#

At roughly 11:30 AM Eastern on April 30, 2026, two new versions of a popular AI library called PyTorch Lightning appear on the Python Package Index. The version numbers are 2.6.2 and 2.6.3. To anyone running a training pipeline that morning — a research team at a university, a data scientist at a Fortune 500, a solo machine-learning consultant on their laptop — they look exactly like a routine maintenance release.

They are not. Hidden inside both packages is a small folder called `_runtime`, and a modified line in the package's `__init__.py` file means that the moment a developer types `import pytorch_lightning`, a background process starts up silently — no install message, no progress bar, no warning — and begins looking for cloud credentials, GitHub tokens, and npm publish tokens to ship out to a server the attacker controls.

The malicious versions stay live on PyPI for forty-two minutes. A scanner from a security company called Socket flags them in eighteen. The PyTorch Lightning team takes them down twenty-four minutes later. By the standards of open-source supply-chain response, that is heroic.

It was also long enough.

The day before, four official packages from SAP's open-source development toolkit had been compromised the same way. A month earlier, a JavaScript HTTP library that pulls in more than a hundred million weekly downloads had carried a remote-access trojan into production builds at companies that didn't know they were using it.

If your vendor risk register doesn't list any of those three names — what exactly do you think it's protecting you from?

What Actually Happened in April#

Three named, dated incidents are worth walking through. They are not isolated. They share an attacker, a method, and a structural problem most companies have never modeled.

Axios — late March / early April 2026. Axios is a JavaScript library that lets web applications talk to other web applications. Think of it as the standard polite way for one program to call another over the internet. It receives more than a hundred million weekly downloads. There is almost no modern Node.js application that does not depend on it, somewhere. In late March, an attacker pushed a poisoned version of Axios to npm — the public registry where JavaScript libraries live — and the malicious version delivered a cross-platform remote-access trojan capable of running on Windows, macOS, and Linux. Microsoft's security team published mitigation guidance on April 1; Trend Micro and Snyk followed the same week. The malicious version was pulled, but for some unknown number of hours, every automated build that pulled "the latest Axios" pulled the trojan along with it.

SAP's CAP-JS packages — April 29, 2026. SAP, the German enterprise software company, publishes a set of free, open-source developer tools through npm. On April 29, four of those packages — `@cap-js/sqlite` 2.2.2, `@cap-js/postgres` 2.2.2, `@cap-js/db-service` 2.10.1, and a build tool called `mbt` 1.2.48 — were published in malicious versions. For somewhere between two and four hours, anyone who ran the standard `npm install` command on a project that depended on those packages pulled a worm. The worm ran a hidden script that runs before the install finishes, harvesting credentials sitting on the developer's machine: AWS keys, GitHub tokens, Google Cloud configurations, npm publish tokens. Then it did something most credential-theft malware doesn't do. If the worm captured a working npm token — the kind a developer uses to publish their own packages to npm — it tested the token to see what packages the victim had publish rights for, and then automatically published poisoned versions of those packages using the victim's own credentials. Every successful infection turned the victim into a new launching pad. The campaign is being called "Mini Shai-Hulud," after a worm-themed family of attacks the same threat group has run before. Researchers at Wiz, Socket, Endor Labs, and Kodem have linked the campaign to a cybercrime crew several firms call TeamPCP, the same group connected to earlier compromises of Checkmarx, Bitwarden, Telnyx, LiteLLM, and Aqua Security packages.

PyTorch Lightning — April 30, 2026. Already described above. Forty-two minutes live, eighteen-minute detection, twenty-four-minute remediation. Versions 2.6.2 and 2.6.3 only. Recommended remediation per the official GitHub Security Advisory: downgrade to 2.6.1 and rotate any credentials that were sitting on a machine that imported the bad versions during the window.

The pattern tying them together. Three different ecosystems. Three different packages. Same threat actor for at least two of them, and a near-identical payload pattern across all three: silently steal developer credentials at install time, then either use them or sell them. None of these are flaws in the underlying open-source code. The code is fine. What's compromised is the publishing layer — the moment when a maintainer's account, or in some cases a CI build pipeline, pushes a new version of a package to a public registry. Steal a maintainer's credentials once, and you can publish anything you want under their name. The next person who types `npm install` or `pip install --upgrade` does the rest of your work for you.

The Vendor Risk Register That Doesn't Know#

Here is the part that makes my stomach turn when I sit with this data.

If you are an executive at any company larger than about twenty people, you almost certainly have a vendor risk register. It is a list of the third parties you've signed contracts with — the SaaS platforms, the cloud providers, the payment processors, the HR systems. A typical mid-size company has somewhere between twenty and sixty names on it. A large enterprise might have several hundred. Your procurement team owns it. Your security team reviews it. Your auditor checks that you've reviewed it.

That list does not include `axios`. It does not include `@cap-js/sqlite`. It does not include `pytorch-lightning`. It does not include the dozen single-maintainer JavaScript packages that quietly run inside every web application you use, including your CRM, your payroll system, and your customer-support tool. The most-downloaded package on npm — a small text-coloring utility called `chalk` — receives more than four hundred million weekly downloads and is maintained by one person whose npm publishing credentials are the single point of failure for hundreds of millions of weekly downloads. Glob, three hundred forty million weekly downloads, single maintainer for thirteen years. Cross-spawn, one hundred ninety million, single maintainer.

The vendor your purchasing team negotiated with isn't the vendor that's running inside your application. The real vendor list — the one that decides whether you stay online — is fifty thousand names long and changes every Tuesday.

The Cigna CISO, the Walmart CISO, the corner-store accountant, and the solo Shopify merchant all share this. Different scale, same structural exposure: when one of those single-maintainer packages gets poisoned at the publishing layer, your contractual vendor list gives you no warning, no notification clause, and no one to call. The compromise lives on a developer's laptop or in a CI runner — your own equipment, in your own building — and your incident-response playbook tells you to call the vendor.

What This Means for Your Company — and It Depends on Your Size#

The same week of incidents lands very differently on a Fortune 500 platform team, a fifty-person growth-stage company, and a five-person consultancy. Each segment has its own version of the problem, and pretending otherwise is part of why this category of risk hasn't moved.

Large Enterprises (1,000+ employees)

You have the tools. You probably have a Software Composition Analysis platform — something like Snyk, GitHub Advanced Security, or Sonatype — and an Application Security team that reads its alerts. You may already produce Software Bills of Materials, the machine-readable inventories of every library a piece of software depends on, in the SPDX or CycloneDX formats CISA published guidance on last year. Your CISO can answer "are we vulnerable to the Axios compromise?" in twenty minutes if the AppSec team is awake.

The problem is that all of that lives in your engineering org and almost none of it has been wired into your governance, risk, and compliance program. Your vendor risk register and your dependency inventory are two different systems, owned by two different teams, with two different scoring frameworks and almost no shared vocabulary. Your auditors check the contractual side. Your engineers check the dependency side. Nobody is asking the question that actually matters when an event like the April 30 Lightning compromise hits, which is: for the forty-two minutes that bad code was live, which of our build systems pulled it, what credentials were on those machines, and what do we have to rotate?

The honest version of "what large enterprises should do" is not "buy more tools." It is: get the AppSec team and the GRC team in a room, agree on a shared definition of "supply chain," and run one tabletop exercise per quarter against an OSS-compromise scenario, not just a vendor-breach scenario. The tools you already have will then be used by people who know the question.

Mid-Size Organizations (100–999 employees)

You probably do not have a dedicated AppSec headcount. You have a head of engineering who took the course, an IT director who reads Krebs on Security, and a compliance lead who has heard the words "Software Bill of Materials" but not been asked to act on them. Your CFO recently approved a "supply chain" line item, and most of it went to vendor questionnaires.

Free tools — `npm audit`, `pip-audit`, GitHub's Dependabot — do real work for you, but they produce a flood of low-quality alerts that nobody on your team has time to triage. Commercial Software Composition Analysis tools start in the low thousands of dollars per month and are priced for engineering organizations of fifty-plus, which puts them out of reach for most companies in this segment until they grow into them. The result is a kind of motivated blindness: you know the risk exists, you cannot easily measure it, and so you treat the problem as theoretical until an incident in the news forces a one-time fire drill that nobody has time to operationalize.

Mid-size is the segment where a few hundred dollars of tooling and a half-day of process work would move the needle most, and where neither the tooling nor the process work tends to happen.

Small & Growing Organizations (Under 100 employees)

You probably do not write much code yourselves. Your exposure runs through your vendors. Your CRM is built on hundreds of npm packages. So is your accounting software, your scheduling tool, your e-commerce store. When Axios was compromised in early April, none of you got an email about it, because none of those vendors were contractually obligated to tell you.

Your practical answer is two things, and only two things. The first is contractual: when you sign or renew a software vendor contract, ask for a clause that requires the vendor to notify you within a fixed window — seventy-two hours is reasonable — of any upstream open-source compromise that has touched their build pipeline. They may not agree. The conversation itself will tell you which vendors take this seriously and which don't, and that signal is itself useful. The second is operational: if you have a website that takes payments, ask your vendor whether they participate in any of the public bug bounty or vulnerability-disclosure programs and whether they can share the date of their last dependency audit. You are not going to inventory their codebase. You are checking whether they have a process at all.

That is what realistic risk management looks like at this scale: not reading every commit, but making sure the people whose code runs your business are reading theirs.

What to Do Monday Morning#

Six things you can walk into a Monday meeting with. None of them require a new vendor contract. The first three are free; the last three are a few hundred dollars of tooling at most for a mid-size org, and free or near-free for a small one.

1. Pull a Software Bill of Materials for one production application. Pick the application that your business most needs to be online. If it's a Node.js application, run `npm sbom --sbom-format cyclonedx --omit dev > sbom.json` from the project root. If it's a Python application, `pip-audit --format cyclonedx-json` does the equivalent. The file you get is the actual list of vendors running inside that one application — usually somewhere between four hundred and four thousand names. The exercise of looking at the file once will reframe what "vendor risk" means for your team for the rest of the year. This is free.
2. Identify the single-maintainer load-bearing packages in your top twenty dependencies. Once you have an SBOM, sort by download count and look at the top twenty packages. For each one, spend ninety seconds checking how many maintainers it has. Tools like Socket and Sonatype give you this for free in a browser. The packages with one maintainer and no two-factor enforcement on the publish path are the ones a compromise like the April 30 PyTorch Lightning incident is most likely to come through. You are not trying to remove these packages. You are building intuition for where the actual blast radius lives. This is free.
3. Run a credential-rotation drill on developer workstations. Pick a Wednesday afternoon. Send a memo: "We are rotating GitHub personal access tokens, npm publish tokens, AWS access keys, and Google Cloud service account keys on every developer workstation by close-of-business Friday." Time how long it takes the team to complete it. The first time you run this drill, it will take longer than you expect. The second time you run it, it will take half as long. The point is not the drill itself; it's that an actual supply-chain compromise will require this exact action on a deadline you didn't set, and you want to know how fast you can do it. Free, but uncomfortable.
4. Turn on npm "trusted publishers" and PyPI provenance for any packages you publish. If your company publishes its own packages to npm or PyPI — even one — switching the publish path to OIDC-based "trusted publishers" (npm) or PyPI's "Trusted Publishing" workflow removes the long-lived credential that an attacker would otherwise steal. It is a one-day engineering task and meaningfully reduces the chance that your publish credentials become the next vector. Setup time is the only cost.
5. Add an upstream-OSS notification clause to your vendor contract template. When you sign or renew a software vendor contract, add a clause requiring the vendor to notify you within seventy-two hours of any upstream open-source compromise that touched their build pipeline. Most vendors will accept the clause. The ones that push back are giving you a useful signal about how they think about the problem. Your legal team can write the clause in two paragraphs; this is procurement work, not engineering.
6. Hold one thirty-minute meeting between your AppSec or engineering lead and your GRC or compliance lead. Walk through the April 30 PyTorch Lightning incident together. Ask one question: if this had happened to a package we depend on at 11:30 AM today, who would notice, who would respond, and how would those two people find each other? If the answer is "I don't know," you have just identified the most important thing on your supply-chain roadmap for the rest of the year. The meeting is the action.

The first three are operational. The fourth is technical. The last two are organizational. The real progress in this category, in my experience, comes from the organizational ones — the tooling will follow once the right people are talking to each other about the right problem.

If You Want a Place to Start#

A few of the questions in the list above — do we maintain an inventory of suppliers, including software components? Do we assess them? Do we have a communication mechanism in place when a compromise happens upstream? — are exactly the questions NIST CSF 2.0 added in February 2024 when the framework introduced its Cybersecurity Supply Chain Risk Management category, GV.SC. If you've never sat with the framework, a structured readiness toolkit is a reasonable starting point — something that walks an internal team through the Identify and Govern functions without needing a consultant in the room. The DLegendDigital NIST CSF 2.0 Readiness Toolkit covers exactly that ground; the SOC 2 Toolkit's vendor-management workpapers can be extended to cover OSS dependencies, though SOC 2 itself doesn't require it. And if you are the engineer who needs a second set of eyes on a dependency-inventory exercise before you walk into a board meeting with the answer, that is the kind of half-day engagement our PBF advisory work is built for. None of that changes the actions above — the actions stand on their own — but it can shorten the time from "we should look into this" to "we have an answer."

The Uncomfortable Truth#

If your vendor risk register doesn't list `axios`, `@cap-js/sqlite`, or `pytorch-lightning`, it is not protecting you from the kind of attack we just lived through three times in thirty days. It is protecting you from the kind of attack that was common in 2018. The actual risk has moved. The register has not.

Over the next twelve months, I expect this category to get worse before it gets better. The npm and PyPI registries are improving — trusted publishers, mandatory two-factor on top packages, automated provenance — and the attackers are improving at the same rate. We will see at least one supply-chain compromise that lands inside an AI model weight or training-data pipeline rather than a Python package, and the AppSec community is not yet equipped to detect that class of attack quickly. We will also see, sometime this year, a compromise that gets caught in eighty-four minutes instead of forty-two, and the damage will be visibly larger; the only difference between the April 30 Lightning incident and a much worse one is the speed of the volunteer response.

The good news, and I do mean it, is that the actions above are inside your reach. You do not need a perfect inventory of fifty thousand names. You need a defensible inventory of the ones running inside the application you most need online, and a thirty-minute conversation between the two people on your team who would have to respond. That is what changed for me after this April. I hope it's what changes for you, too.

— Charles Redding, Founder, DLegendDigital