Your vendor risk questionnaire asks about your 35 direct suppliers. Your real attack surface is closer to 50,000 transitive dependencies — the little pieces of free code your vendors' code quietly pulls in, which their vendors' code pulls in, which nobody on your team has ever seen the name of. April 2026 gave us three reminders in thirty days.
The story#
Here is what actually happened. In late March, an attacker poisoned a JavaScript helper called Axios — a library that lets web apps talk to other web apps, downloaded more than a hundred million times a week. For an unknown number of hours, every automated build that pulled "the latest Axios" pulled a remote-access trojan with it. Microsoft and Trend Micro published mitigation guidance on April 1. Almost nobody outside engineering noticed.
On April 29, four official packages from SAP's open-source developer toolkit went out in poisoned versions. The malicious script ran before the install finished, harvested the developer's AWS keys, GitHub tokens, and npm publishing credentials, and then — and this is the new part — used those stolen credentials to automatically publish poisoned versions of whatever else the victim had publish rights to. Every infection turned the victim into a new launching pad. The researchers are calling it Mini Shai-Hulud, after a worm-themed family of attacks the same crew has run before. Window: two to four hours.
The next day — April 30, at roughly 11:30 AM Eastern — two new versions of a popular AI training library called PyTorch Lightning appeared on PyPI (the Python Package Index — the place Python developers download free libraries from). They looked like a routine update. They were not. The moment any developer typed `import pytorch_lightning`, a background process started silently shipping credentials out to a server the attacker controlled. The bad versions stayed live for 42 minutes. A scanner from a security company called Socket flagged them in 18. The maintainers pulled them 24 minutes after that. By the standards of volunteer-run open-source security response, that is heroic. It was also long enough for an unknown number of laptops and build servers around the world to lose their secrets.
The pattern across all three: nobody attacked the code itself. They attacked the publishing layer — the moment a maintainer pushes a new version of a free library to a public registry. Steal a maintainer's password once, and you can publish anything you want under their name. The next person who runs an install command does the rest of your work for you.
Here is the part that should sit with vendor risk teams this week. None of these names — `axios`, `@cap-js/sqlite`, `pytorch-lightning` — are on your vendor risk register. They are not vendors you signed a contract with. But they are running inside the SaaS tools you did sign contracts with: your CRM, your payroll system, your customer-support platform. When those packages get poisoned, your contractual vendor list gives you no warning, no notification clause, and nobody to call. The compromise lives on a developer's laptop or in a build server — your equipment, your building — and your incident-response playbook tells you to call the vendor.
Hot take#
SBOMs — Software Bills of Materials, basically a labeled ingredient list of every free library your code pulls in — have been on the table since the 2021 White House executive order. Three-plus years. Every cybersecurity vendor on the trade-show floor has been selling SBOM tooling since 2023. CISA published the formats. NIST CSF 2.0 added a whole new category for supply-chain risk in February 2024.
April changed the conversation from "we should look into this" to "we don't have an answer." After three named incidents in thirty days hitting packages that everyone uses, "we don't have SBOM tooling" is no longer an acceptable answer in a vendor security review — yours or the one your customers are running on you. The next vendor security questionnaire your auditor reviews will ask for one. The next enterprise procurement RFP your sales team chases will ask whether you produce them for your own product. Plan for the question now, because it is coming inside this fiscal year, and the honest answer of "we know the top 20 packages we depend on and what we'd rotate if one got hit" is a defensible one. "We don't track it" is not.
Curated links#
- Mini Shai-Hulud: SAP CAP-JS packages compromised (Wiz Research) — The clearest single write-up of the April 29 SAP incident, including the self-replicating worm mechanic and the threat actor researchers are tracking (TeamPCP). Read this if you read only one.
- PyTorch Lightning malicious release advisory (GitHub Security Advisory) — The official advisory with the 42-minute window, the affected versions, and the recommended downgrade-and-rotate steps. Forward to anyone running AI training pipelines.
- Axios npm compromise — mitigation guidance (Microsoft Security) — Microsoft's April 1 write-up on the Axios trojan and what to look for in your build logs. Useful for IT directors who need a vendor-recognized source to escalate internally.
- SBOM guidance for procurement (CISA) — CISA's plain-English landing page on what an SBOM is, what to ask vendors for, and the SPDX and CycloneDX formats that are now standard. The reference your procurement team should be working from when they update questionnaires.
- The state of open-source supply-chain security 2026 (Sonatype) — Annual industry report with the numbers behind the trend. Useful to drop into a board deck when "supply chain risk" needs a chart, not just a story.
What's next#
Issue #5 lands in two weeks — and we are writing about the Windows 11 patching deadline that is about to land on every IT manager's desk, plus why "we'll just pay for extended support" costs more than most teams expect.