Open Source Security Risk: What Mid-Market Teams Miss

Open source security risk is the exposure a company inherits from free, community-built software components buried inside the products it buys. You don't write the code, you don't patch it, and you rarely know it's there.

That last part is what makes it hard to manage. Nobody approved it. Open source never went through a procurement review, and it arrived attached to something you did approve, so it sits a layer or two below anything your team can see. It's a real slice of your software supply chain risk, and it behaves differently from the rest of that category.

February 2024 is a good place to start. A volunteer had spent roughly two years contributing to xz-utils, a small compression library that ships inside almost every Linux system, building enough goodwill to be handed maintainer access. Then they used it to plant a backdoor in SSH, the tool administrators use to log into servers remotely. CISA scored it 10.0 out of 10, the top of the scale. A Microsoft engineer caught it because a login was taking longer than it should have. Half a second. That was the whole tell.

Nothing in that story is a vulnerability in the usual sense. No developer made a mistake. No bug, either. No scanner would have flagged version 5.6.0 on the day it shipped, because on that day it was the current release. The risk was in who held the keys, and how few people were watching. Questionnaires and vulnerability reports don't measure either one.

What Is Open Source Security Risk?

Open source security risk is the chance that a free, publicly maintained software component inside something you own gets exploited, abandoned, or tampered with. The component is usually invisible to you, and you can't patch it directly.

Plain version first. Source code published openly, free for anyone to use. Commercial vendors build on it heavily, because rewriting a PDF renderer or a logging library from scratch would be a waste of everyone's money. Black Duck's 2026 analysis found open source in 98% of the codebases it audited, across 947 codebases in 17 industries.

Depth is what catches people out. Your accounting platform pulls in a reporting engine, the reporting engine pulls in a charting library, and the charting library pulls in something small that parses dates. Developers call the buried ones transitive dependencies, meaning components that arrive attached to other components rather than being chosen on purpose. In the 2025 edition of that same report, 64% of everything found was transitive. Two-thirds of the open source in your software was never picked by anybody. It came with the box.

And it ages in place. 90% of the codebases audited in that 2025 report held components more than four years out of date. Software doesn't corrode the way a bearing does, but the comparison holds better than you'd like, because a four-year-old library has four years of published attacks aimed at it by now. And often nobody left who cares.

Why Does This Apply If Nobody at Your Company Writes Software?

You don't have to write code to run it. Not one line. Open source reaches a company through the products it buys, the SaaS it subscribes to, the internal apps a contractor built, and the tools its IT provider uses to manage the network.

Each of those doors has a different owner, and the owner is the useful distinction. Where the owner is a vendor, your work is asking. Where the owner is a contractor who left in 2021, your work is finding out what they left behind. Same risk, completely different job.

Nobody thinks about the bottom two rows. A managed IT provider installs software agents on every machine you own, which is precisely why their toolchain deserves the same scrutiny as your ERP vendor's. The automation row barely existed in 2023. Now it's everywhere.

I know a 240-person food processor whose entire quoting workflow runs on a small web app a contractor wrote in 2019. Node, a MySQL database, and roughly 40 packages pinned to whatever was current that spring. Nobody has touched the dependencies since. It works fine. That's the problem, because working software doesn't generate tickets, and nothing that fails to generate tickets ever gets reviewed.

What Does a CVE Count Miss?

Most of it. A CVE is a publicly logged flaw in a specific version, so a scanner can match it. Abandonment, a hijacked maintainer account, a typo-squatted package name, and a library that quietly changed hands produce no CVE at all.

OWASP, the nonprofit behind the widely used web application risk lists, published a Top 10 for open source risk in 2024. Worth reading once. Even if you never think about it again after that. Only the first category covers known open source vulnerabilities. The other nine describe conditions a vulnerability scanner has no way to see.

Half that list comes back to one fact. Not a code-quality fact. Very widely used software is often maintained by very few people. The Linux Foundation and Harvard's innovation lab published Census III in December 2024, built from more than 12 million observations of open source libraries running in production at over 10,000 companies, and one of its plainer findings is that many of the most deployed libraries are held up by a small handful of contributors.

Sometimes one. xz-utils was one, which is exactly what made a two-year grooming campaign worth the effort. Two years of patience.

None of this makes open source a bad choice. It usually isn't. Commercial software has single points of failure too. They're just called employees, and a contract covers them. That's the whole difference. A contract gives you somebody to call at 2 a.m., while a volunteer maintainer in another timezone never agreed to be on call for your business and was never paid to be.

Vulnerable Packages and Malicious Packages Are Not the Same Problem

A vulnerable package is an accident, sometimes a zero-day vulnerability nobody knew about until it was used. A malicious package is somebody's plan. Accidents you patch. Plans you have to notice first.

Sonatype's 2026 report counted 454,600 new malicious packages published during 2025, pushing its cumulative blocked total past 1.2 million, and more than 99% of it landed on npm, the package registry for JavaScript. A single campaign called IndonesianFoods published 169,538 packages in a matter of days.

The one worth understanding is Shai-Hulud. In September 2025 a compromised npm package began scanning the machines that installed it for stored credentials, using a legitimate security tool called TruffleHog, then used any publishing tokens it found to infect further packages without human help. Self-replicating. CISA issued an alert on September 23, 2025 once more than 500 packages had been hit, and a second wave in November spawned more than 25,000 malicious repositories.

Read CISA's actual advice and notice who it's addressed to. Rotate developer credentials. Require phishing-resistant multifactor authentication on GitHub and npm accounts. Pin dependencies to releases published before September 16, 2025. Block outbound traffic to webhook.site.

All four are developer-machine and build-pipeline controls. If you have two developers or one contractor, those four items are close to your entire exposure to this class of attack. None of them cost money. If you have no developers at all, it reaches you through your vendors instead, on their schedule, and the only lever you hold is knowing which of your vendors ship software written in JavaScript.

What Changed in 2026 When AI Started Writing the Code?

Volume went up. Review didn't. Assistants also invent package names that don't exist, which hands attackers a ready list of names to register and fill with malware.

Researchers from UT San Antonio, the University of Oklahoma, and Virginia Tech presented the measurements at USENIX Security in 2025. They generated 2.23 million package references across 16 code-generating models. 440,445 of them, 19.7%, pointed at packages that don't exist. Nearly one in five. The inventions repeat, too. 43% of them came back on all 10 tries with the same prompt, and repeatable is what makes a fake name worth registering.

Slopsquatting is the name that stuck. A 2026 follow-up on newer frontier models found the spread had tightened to somewhere between 4.62% and 6.10%, so the models did improve. Better isn't zero. One in 20 is still a lot of attempts when the person generating the code is a finance analyst automating a monthly report rather than a developer who'd notice a package name that looks slightly wrong.

Black Duck's 2026 figures show the squeeze from the other direction. Mean vulnerabilities per codebase climbed 107%, while component counts grew 30% and files per codebase grew 74%, all of it inside twelve months. 76% of organizations said they check AI-generated code for security problems. 24% said they run a full evaluation covering security, licensing, and quality together. That 52-point gap is where this risk now sits.

What Should You Actually Ask a Software Vendor?

Five questions. A perfect answer isn't the goal. You're finding out whether the vendor has a process at all, because a vendor who can't answer inside two weeks doesn't have one.

SecurityScorecard framed the gap well. A questionnaire asks whether a vendor patches their software, and rarely asks which open source projects underpin it, which version, or how recently the maintainers shipped a security fix. Standard vendor assessments skip straight past the layer where this risk actually sits.

• Can you provide a software bill of materials for the version we're running? An SBOM is a machine-readable parts list for software. How fast it arrives tells you more than the file does.
• Which components in it do you treat as critical, and when did each last receive a security update?
• How do you find out when one of your dependencies has a new vulnerability? A named tool is a fine answer. Silence isn't.
• What's your commitment for shipping a fix once something critical is disclosed? Get the number into the renewal paperwork.
• If a component you depend on gets abandoned, then what? Hardly anyone has a real answer here. The ones who do are worth keeping.

If you'd rather borrow vocabulary than invent your own, NIST publishes SP 800-218, the Secure Software Development Framework. Part of why it exists is so buyers and software producers can describe the same practices in the same words, and federal agencies already collect vendor attestations against it, which means the wording has already been argued over by buyers with far more leverage than you have. Borrow it. It slots into an existing third-party risk management program, and the parts-list half of the conversation is covered in more depth in our piece on what an SBOM actually contains.

The Internal App Nobody Owns

Every mid-market company I've looked at has at least one. A shipping label tool, a commission calculator, a customer portal built during a growth spurt by somebody who has since moved on. It runs, so it's invisible.

Dependencies in an app like that are frozen at the moment it was built, while the libraries underneath kept moving. Four or five years on you're running a stack carrying hundreds of published vulnerabilities with no practical way to update it, because the only machine ever set up to rebuild the thing was the contractor's laptop.

This is where an ordinary patch management routine stops helping. There's no update to apply. It turns into a vulnerability management decision instead, which means ranking what you can't fix and containing it. Find out what it's built on, write it down, then choose deliberately between funding an update, walling it off from the rest of the network, and replacing it. Pick one. Any of the three beats not knowing.

A Reasonable First 60 Days

Sixty days is enough to build the inventory and ask the questions. It isn't enough to fix anything, and attempting both at once is why this work usually stalls out somewhere in month three, with a half-finished spreadsheet and nobody willing to own the next step.

• Weeks 1 and 2. List every piece of software touching your network, including the camera system, the badge readers, and whatever runs the production line. Not the tidy version. The real one.
• Weeks 3 and 4. Rank it by what would actually hurt. A vulnerable library inside your MRP system matters more than one inside the conference room display, and the ranking is a business judgment rather than a technical one.
• Send the five questions to your top 10 vendors by risk, not your top 10 by spend. Those two lists overlap less than people expect.
• Weeks 5 and 6 belong to the internal apps. Find the ones nobody owns, and write down what they're built on.
• Ask your IT provider for their side of it. Which agents they run on your machines, how they patch their own tooling, what their process is when one of their vendors gets compromised.
• Weeks 7 and 8. Write down what you found, and write down what you decided not to do about it. That second list is the one auditors and insurance underwriters ask to see.

Under 20 users, with everything running on Microsoft 365 and a couple of SaaS platforms, this is a 90-minute conversation. Not a project. And if you already run software composition analysis inside a build pipeline, you're well ahead of this entire article. Skip to the vendor questions.

Consilien is a security-first managed IT and managed cybersecurity services firm working with companies between 20 and 1000 users nationwide, mostly manufacturers, distributors, and professional services firms. The problem we get called about here is the same one nearly every time. Nobody can produce a list of what the company actually runs, so nobody can answer a question about it when one arrives. We start with the inventory. Every other decision depends on it. Compliance work sits alongside that as its own engagement rather than folded into managed IT.

Dependency risk doesn't announce itself. No alert, no ticket, no outage. It sits in a version number inside a product you bought in 2022 from a vendor that has since been acquired, and it stays quiet until somebody publishes an exploit and your provider spends a weekend working out whether you're affected.

Knowing what you run turns that weekend into an afternoon. If you want help building the inventory and putting real questions in front of your vendors, speak to a security expert about where your open source exposure actually sits, or start with a broader cybersecurity risk assessment.