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
Learn how you can safely populate your binary repository with open source dependencies whose security and integrity has been pre-verified.
