The Open Source Security Gap

Blog

The Open Source Security Gap

Dana Crane

August 1, 2024

Software security is top of mind these days, driven by a number of emerging market factors, including:

Ransomware – payouts have not only hit an all time high of $1.1B, but they’ve also had a devastating impact on certain industries like healthcare.
Supply Chain Attacks – software supply chain incidents are up 633% YoY resulting in $46B in damages in 2023.
Litigation – it’s one thing for public corporations to be subject to new cybersecurity SEC rules, but it’s quite another for the US government to personally sue CxOs.

The fallout of these trends has been an escalating focus on cybersecurity, as exemplified by exorbitant valuations of security companies, as well as a growing focus by governments worried about cyberwarfare who have been encouraging software vendors since 2021 to prioritize security even at the expense of market share.

As the software industry has incorporated more and more open source software in the codebase of their applications, the security problem has only grown due to:

Trust – organizations rely on open source dependencies created and maintained by thousands of authors with whom they typically have no relationship, requiring them to implicitly trust a diverse set of actors, at least some of whom may have malicious intentions.
Exploitability – open source ecosystems must rely on the kindness of strangers to contribute code, since open source software creation is rarely compensated. Barriers to contribution, such as security controls around what can or cannot be published in a public repository, are necessarily minimized in order to foster growth.

Recent software supply chain attacks highlight the fact that for consumers of open source software the message is clear: “user beware.” For example:

Polyfill Attack Impacts >300K Websites – organizations that weren’t tracking the ownership of a popular Javascript project (Polyfill JS) were blindsided when the new author injected malware into the library.
Trojanized jQuery Packages Found – an unusually persistent, cross-repository threat was found in variously named instances of the popular jQuery package on npm, GitHub, and jsDelivr code repositories.
PyPI Redirect – a clever typosquat of the official Python Package Index (PyPI) domain “files.pythonhosted.org” was instantiated as “files.pypihosted.org”. Visitors were served trojanized versions of popular Python packages.

I’ve written elsewhere of the need to separate Dependency Security (DepSec) into its own discipline distinct from Application Security (AppSec) for a number of reasons, and the public repository problem is yet another good reason that needs further elaboration.

Traditional AppSec Versus Mr Fox

If you’ve seen Wes Anderson’s animated movie, The Fantastic Mr Fox you may be familiar with the story of a fox that breaks a long-standing promise and raids the farms of his neighbors, endangering his world and subsequently being forced into hiding underground.

While most viewers might see the movie as a cautionary tale for children, it also paints a compelling picture for AppSec, re: after years of taking open source software for granted, software supply chain attacks are growing 633% YoY, resulting in $46B in damages in 2023. While the US government is spearheading the underground search for bad actors, organizations are left to deal with the problem on their own.

I’ve discussed elsewhere why every ISV is in the software supply chain business, whether they know it or not, despite the fact that they rarely have the tools in place to manage their open source supply chain at scale. Time and resources are generally already maxed out addressing the traditional, known security issues across the Software Development LifeCycle (SDLC) leaving new threats unaddressed. In fact, according to the Application Security Posture Management (ASPM) 2024 report, “77% [of organizations] recognize that software supply chain security is a blind spot for AppSec teams.”

For example, in any typical SDLC:

>80% of a modern application’s codebase comes from open source ecosystems like npm (JavaScript), PyPI (Python), maven (Java), etc.
The point of ingress into the organization is typically a binary repository, since most open source components are imported as prebuilt binaries.
On top of the open source is layered proprietary code developed in-house, compiled, and added into the binary repository.
All of the stakeholders from dev to test to production (i.e., the CI/CD pipeline) can then pull from the binary repository to populate their environments and processes.

AppSec has the tools to address the traditional threats along the way:

For source code, AppSec employs Static Analysis Software Tools (SAST) to ensure code security and integrity.
Software Composition Analysis (SCA) tools are used in the CI/CD pipeline to assess the binary components flowing through and flag any exceptions.
Dynamic Analysis Software Tools (DAST) are used to assess the built application in order to identify any exploitable paths through the software, as well as typical web app vulnerabilities.

But the point of ingestion from the public ecosystems currently doesn’t have standard tooling to identify whether the imported open source code is fit for use. In fact, most organizations rely on their binary repository to warn them whether what they’ve already imported poses a risk. In other words, we first let the fox into the henhouse and then try to figure out how to get him out. Hardly an ideal situation.

Conclusions – Eliminating the Threat of Public Repos

The threats associated with importing open source packages from public repositories are well known, including typsoquatting, malware, dependency confusion, vulnerabilities, etc, but are typically not addressed before they’re imported into the organization.

While the open source ecosystems’ public repositories are quite good at addressing these threats when they’re found, often deleting them within hours of their upload, those compromised packages will still have been downloaded hundreds or even thousands of times, infecting dozens of downstream organizations.

To address these open source threats prior to import requires the implementation of multiple tools and controls. Alternatively, the ActiveState Platform provides a single solution that can ensure you populate your binary repository with secure packages since it builds all open source securely from vetted source code.

Next Steps

Contact us to learn how you can safely populate your binary repository with open source dependencies whose security and integrity has been pre-verified.

Frequently Asked Questions

What is the open source security gap?

The open source security gap is the difference between an organization's perception of its open source security posture and its actual exposure. Most organizations believe their scanner gives them visibility into their open source vulnerabilities. In practice, scanners miss transitive dependencies, generate false positives that crowd out real findings, operate with incomplete CVE enrichment data since NIST acknowledged it cannot process all submissions, and generate findings against packages that have already entered the environment and need remediation — not admission control. The gap is what falls between those limitations.

Why do transitive dependencies represent the largest component of the security gap?

Most organizations have dozens to hundreds of direct open source dependencies. Each of those dependencies has its own dependency tree, often several layers deep, adding up to thousands of transitive components that the team never chose, often cannot fully see, and typically has no governance over. The majority of supply chain attacks — including the March 2026 axios compromise — exploited a transitive dependency rather than a direct one. Most SCA tools provide weaker coverage of transitive dependencies than they do of direct dependencies.

What closes the open source security gap most effectively?

The combination of governed admission — ensuring components come from a vetted source — and full dependency tree coverage closes the gap that scanners leave open. A curated catalog that governs every component in the dependency tree, including transitives, before it reaches the developer is the structural answer. Scanners remain useful for validating the posture of what was admitted, but they cannot close a gap that exists in what enters the environment in the first place.