Hidden Software Dependencies: The Risk Your Business Doesn't Track

Every application your company uses is built on top of other software. Your accounting platform, your CRM, your project management tool, even the internal utilities your team relies on daily, all pull in dozens or hundreds of open-source libraries and third-party components that the original developers chose, often years ago.

Your IT team didn’t select these components. Your vendor might not even know they’re there anymore. But when one of them has a critical vulnerability, your business is exposed.

This isn’t a theoretical concern. The pattern has repeated itself at scale multiple times in the last five years, and each incident has hit SMBs harder than enterprises because smaller organizations typically lack visibility into what’s actually running under the hood.

The Pattern: Vulnerabilities in Code Nobody Chose

In December 2021, a critical remote code execution vulnerability in Log4j, a Java logging library used in hundreds of thousands of applications worldwide, gave attackers a way into any system running affected software. Log4j wasn’t something anyone deliberately installed. It came bundled inside other software, which came bundled inside other software. Many organizations spent weeks just figuring out whether they were affected.

The same vulnerability class surfaced again the following year in Fastjson, a JSON parsing library for Java. CVE-2022-25845, disclosed in 2022, was an unsafe deserialization flaw that scored CVSS 9.8, enabled remote code execution, and had public exploit code circulating while many downstream consumers were still running unpatched versions. Businesses running Spring Boot applications that pulled in Fastjson as a transitive dependency, meaning it was included automatically by another library they did choose, were exposed without any action on their part.

The pattern showed up again in March 2024 with xz Utils, a compression library embedded so deeply in Linux systems that a backdoor planted by a trusted maintainer nearly compromised SSH authentication across the entire internet. The attack was caught by accident. A Microsoft engineer noticed unusual CPU usage during routine testing. If that engineer had been less curious, the backdoor would have shipped in major Linux distributions and propagated silently into cloud infrastructure, containers, and servers that SMBs depend on without ever touching directly.

The common thread is that the vulnerability wasn’t in software your team picked or even knows about. It was buried two or three layers deep in the dependency tree, doing its job invisibly until it became a liability.

Why SMBs Are Disproportionately Exposed

Enterprise organizations with dedicated security teams can run software composition analysis (SCA) tools, maintain internal registries, and enforce dependency policies across development teams. A 50 to 200-person business running commercial off-the-shelf software and a handful of custom internal tools has none of this infrastructure.

The typical SMB exposure looks like this:

• Line-of-business applications with embedded components the vendor hasn’t updated in years
• Custom integrations built by a contractor who chose libraries based on convenience, not long-term supportability
• Self-hosted tools running on servers where nobody has checked the installed package versions since deployment
• WordPress sites, internal dashboards, and automation scripts pulling in plugins and packages with their own dependency trees

When a vulnerability like Log4j or Fastjson drops, an enterprise security team runs an automated scan across their environment and produces a list of affected systems within hours. An SMB relying on break-fix IT support has to wait for their vendor to acknowledge the problem, issue a patch, and communicate the risk. That process can take days to weeks, and for transitive dependencies, the vendor may not even realize their product is affected.

What a Software Bill of Materials (SBOM) Actually Is

A Software Bill of Materials is exactly what it sounds like: a list of every component that makes up a piece of software. Think of it as the ingredient label on packaged food. You might buy a jar of tomato sauce, but the SBOM tells you it also contains citric acid, calcium chloride, and soybean oil. If calcium chloride turns out to be harmful, you need that label to know which products on your shelf are affected.

For software, an SBOM lists every library, framework, and module included in an application, along with version numbers and licensing information. When CISA or a vendor announces a vulnerability in a specific component at a specific version, an SBOM lets you answer the question “are we affected?” in minutes instead of days.

Executive Order 14028 (May 2021) required SBOM delivery for software sold to federal agencies. That requirement has been filtering down into the private sector through cyber insurance questionnaires, vendor risk assessments, and compliance frameworks. The CISA SBOM resources page provides the technical standards (SPDX and CycloneDX) and guidance for both producers and consumers of software.

For most SMBs, the practical application is simpler than the technical standards suggest:

• Ask your vendors for SBOMs. If a vendor can’t produce one, they don’t have visibility into their own supply chain. That’s a risk factor worth noting in your vendor security vetting process.
• Keep an inventory of what’s installed. You can’t protect what you can’t see. A current IT asset inventory that includes software versions is the minimum starting point.
• Track CISA KEV alerts. The Known Exploited Vulnerabilities catalog lists confirmed in-the-wild exploitation. If a component in your environment appears on this list, the patching clock has already started.

What Managed Patching Covers That Break-Fix Doesn’t

The difference between a managed IT engagement and break-fix support is most visible when a dependency vulnerability hits. Break-fix means someone calls for help after the problem is discovered, usually after a vendor advisory, a news article, or worse, an incident. The response is reactive, and the first step is always the same question: “What are we running, and is it affected?” If nobody has maintained an inventory, that question takes days to answer.

A managed patching program operates on continuous inventory and automated scanning. When a new CVE drops, the managed provider can cross-reference the vulnerability against a current list of every application, component, and version running across client environments. We covered how this works in practice during a multi-vulnerability week in our triage walkthrough. The difference in response time between “we need to figure out what we’re running” and “we already know, here’s the remediation plan” can be the difference between patching within CISA’s three-day standard and scrambling for weeks.

Managed patching also covers the long tail that break-fix ignores entirely. The routine monthly patches for operating systems and major applications are the visible part of the job. The invisible part is tracking updates and end-of-life dates for the dozens of smaller components, plugins, drivers, and runtime environments that make up the full software stack. A Java runtime that’s two major versions behind, a .NET framework that’s past end of support, or a database driver that hasn’t been updated since installation are all dependency risks that break-fix support will never proactively address because nobody is looking.

Four Steps to Start Tracking Your Dependency Risk

You don’t need to implement a full software composition analysis program tomorrow. These four steps will give you meaningful visibility into your exposure.

1. Build a software inventory that goes one level deeper than application names. Don’t just list “QuickBooks” and “Salesforce.” Document the platform versions, the runtime environments they depend on (Java, .NET, Python), and any plugins, connectors, or extensions installed alongside them.

2. Identify self-hosted and custom applications. SaaS products are patched by the vendor. Self-hosted tools, custom integrations, and internal applications are your responsibility. These are the most likely places where outdated dependencies hide because they don’t receive automatic updates.

3. Ask your vendors about their dependency management. When a critical CVE drops in a component like Log4j or Fastjson, how does your vendor determine whether their product is affected, and how quickly do they communicate that to customers? A vendor with a mature software development lifecycle can answer this question specifically. One without it will give you a vague response about “following best practices.”

4. Ensure your IT provider maintains continuous inventory and has a vulnerability response process. Whether that’s an internal team or an MSP, someone needs to be watching the CVE feeds, cross-referencing against your environment, and acting on critical findings within hours, not days.

The Fastjson, Log4j, and xz Utils incidents all followed the same trajectory. A component that nobody specifically chose turned out to be everywhere, and the organizations that knew what they were running responded quickly while the rest scrambled.

Dependency risk isn’t going away. The software your business relies on will keep pulling in components you’ve never heard of. The question is whether you’ll know about it when one of those components fails.