The part no one wants to say out loud: you can’t audit them all.
Last week, a security research firm named Novee published a finding that should make every CIO in the country uncomfortable. A class of vulnerabilities they’re calling Cordyceps — embedded in GitHub Actions workflows — exposed more than 300 public repositories (including those of Microsoft, Google, and Apache) to full supply-chain takeover. An attacker with the right foothold could push poisoned code into the open source packages that millions of applications depend on. The exposure was wide. The blast radius is the entire internet.
If you’re running a 50-person SaaS company or a regional healthcare network, you probably read that story and thought the same thing I did: I don’t control any of this.
That’s the point. Welcome to the supply chain problem.
The Software Stack Has Outgrown Your Perimeter
Five years ago, “supply chain attack” mostly meant a compromised vendor slipping malware into a software update. The SolarWinds incident of late 2020 fit that model almost perfectly. One point of compromise. Investigate, contain, move on.
The 2026 version is messier, broader, and harder to point at. Three stories from the last ten days alone:
- Miasma, a self-propagating worm targeting npm packages and GitHub Actions, has surfaced again in a new cluster of compromised packages. It spreads by stealing credentials and hopping to other repos — the same playbook that made the original Shai-Hulud worm famous in 2024.
- Amazon Q Developer, the AI coding assistant baked into AWS tooling, had a flaw that let a malicious repository run commands and steal cloud credentials from any developer who opened it. Wiz disclosed the bug on June 26. Amazon patched it the same day. The vulnerability was never seen in the wild, but it could have been.
- Microsoft Edge Add-ons booted 119 extensions that hid malware payloads inside ordinary image and font files. The extensions sat dormant on victims’ browsers for days before waking up to steal credentials and run ad fraud. Microsoft says the operator behind it has been active since at least 2021.
Three different vendors. Three different attack surfaces. One common reality for anyone running a small IT team: the things you depend on to ship software, take payments, or run your website are being attacked in ways you cannot see.
Why SMBs Are the Real Victims
The press coverage tends to focus on the household names. Microsoft, Google, Apache, AWS — these are mature companies with serious security teams. If they miss a bug in their CI/CD pipeline or their extension store, it’s news for a week and then they patch.
The same software is sitting in your stack. A 30-person e-commerce business might run its entire operation on a handful of npm packages, a payment processor, an inventory SaaS, and a small fleet of AWS services. Any one of those is a possible entry point. The smaller company can’t audit the source of every dependency, can’t review the security of every SaaS vendor, and almost certainly doesn’t have a Software Bill of Materials to begin with.
A few uncomfortable numbers, courtesy of Verizon’s 2025 Data Breach Investigations Report: 30% of breaches now involve a third-party component, and that share has been climbing every year since 2021. For small businesses specifically, the figure is higher — somewhere around 40%, depending on which report you read.
You don’t have to be the actual target. You just have to be downstream of one.
What You Can Actually Do About It
The honest answer: you cannot eliminate the risk. Anyone who tells you they can is selling you something. But you can reduce the blast radius and catch problems faster. Here’s what I’d actually do this week if I were running IT for a 50-to-500-person company.
1. Inventory your dependencies. Then inventory them again.
You probably have an official list of approved SaaS vendors and on-prem software. That list is incomplete. The real inventory lives in your developers’ package.json files, your DevOps team’s GitHub Actions, your marketing team’s browser extensions, and your sales team’s Chrome plug-ins. Get a Software Bill of Materials (SBOM) tool — CycloneDX or SPDX-format generators are free and plug into most CI systems. You can’t protect what you can’t name.
2. Lock down browser extensions.
The StegoAd case is a reminder that the attack surface you can see is not the only one. Browser extensions run with the same privileges as the user who installed them. Set a corporate policy. Audit which extensions are installed across the team. Don’t allow employees to install extensions on company-managed browsers without a review. This sounds pedantic. It is not.
3. Watch the maintainers, not just the packages.
A growing share of supply chain attacks in 2026 target the humans behind the software. Compromised maintainer accounts. Social engineering of project owners. Hijacked email addresses used for password resets. Miasma works exactly this way. If your business depends on a small open source library maintained by one person in another time zone, that is a single point of failure. Know who they are. Have a contingency plan for what happens if their account gets hijacked.
4. Treat vendor security like vendor pricing.
If you evaluate SaaS vendors on price, uptime, and feature set, add security to that list and make it count. Ask vendors for SOC 2 reports. Ask how they handle dependency updates. Ask whether they have their own SBOM. The answers vary wildly, and the questions alone will weed out vendors who shouldn’t be in your stack.
5. Have an “off switch.”
When the next big npm or Python package gets compromised — and there will be a next one — how fast can you pin your dependencies to known-good versions, roll back your last build, or block traffic to the affected vendor? That is your incident response plan for supply chain failures. Most companies don’t have one. Spend an afternoon writing it.
The Bigger Picture
The uncomfortable trend is that the perimeter is dissolving. The work of securing your business used to mean securing your network, your laptops, and your office. It now means securing every package, every service, every extension, and every developer tool that touches your stack. The number of those things grows every quarter. The number of people you have to secure them with doesn’t.
For a 200-person company, the practical move isn’t to out-tech the attackers. It’s to be a less attractive target than the next 200-person company. That means knowing your dependencies, limiting the third-party surface, and having a plan for the day one of them fails. None of this is glamorous. All of it is the actual job in 2026.
