Calls for a critical look at how open-source software (OSS) is secured and used have been increasing after a number of recent scares exposed vulnerabilities and risks, in particular the XZ Utils incident that revealed a backdoor inserted into a widely used OSS for compression and decompression of XZ files.
XZ Utils could have been one of the highest-impact software supply chain breaches to date, had it not been detected in time. Although it didn’t end up having the widespread exploitation potential of Log4j, it served as another wake-up call that the modern digital ecosystem is incredibly fragile and needs to mature how it consumes and secures OSS.
In response to these and other incidents, additional resources and guidance for cybersecurity practitioners are evolving to help mature the way OSS is governed and used securely, including the Top 10 Risks for Open Source Software (OSS), from the Open Web Application Security Project (OWASP).
The OWASP Top 10 was originally created by Endor Labs, a software supply chain and application security company focused on the secure consumption of OSS, CI/CD pipelines and vulnerability management. The project also included support from industry leaders such as Palo Alto, HashiCorp, and Citibank.
While traditionally vulnerability management has looked at known vulnerabilities, often in the form of Common Vulnerability and Exposures (CVE) lists, there is a growing realization that known vulnerabilities are lagging indicators of risk.
To mature the way we approach the use of open source, a paradigm shift is needed to look at leading indicators of risk, which are metrics that may signal that there is risk associated with particular OSS libraries, components and projects which when considered holistically, can help inform more secure consumption of OSS and mitigate potential risks that manifest into exploits and vulnerabilities.
The top 10 open source risks
OWASP
1: Known vulnerabilities
This section covers OSS components with known vulnerabilities such as software flaws, often inadvertently introduced by software developers and maintainers and then subsequently disclosed publicly, often by security researchers in the community.
These vulnerabilities may be exploitable depending on the context in which they are used within an organization and application. While this point may seem trivial, it isn’t — failing to provide developers with this context leads to significant toil, wasted time, frustration and often resentment towards Security.
There are efforts to address this challenge, such as the CISA Known Exploited Vulnerability (KEV) catalog and Exploit Prediction Scoring System (EPSS).
Organizations can take actions to mitigate the risk of OSS components with known vulnerabilities such as scanning for vulnerabilities in all OSS components they use, prioritizing findings based on methods such as known exploitation, exploitation probability, reachability analysis (which can reduce up to 80% of noisy findings), and more.
2: Compromise of a legitimate package
Next up on the list of Top 10 OSS Risks is the compromise of a legitimate package. Malicious actors realize the value of compromising a legitimate package to impact downstream consumers, both organizationally and individually.
There are a variety of methods they can use to pursue this attack vector, such as hijacking the accounts of the project maintainers or vulnerabilities in the package repositories.
They can also volunteer to become maintainers only to pursue their nefarious intentions down the road. This is precisely what happened in the recent XZ Utils incident, as someone posed as a legitimate contributor over a long timeline before embedding a backdoor in the code.
Recommendations to mitigate this risk include using emerging resources and guidance such as Microsoft’s (now donated to OpenSSF) Secure Supply Chain Consumption Framework (S2C2F), but there are now several other similar frameworks in the industry.
3: Name confusion attacks
In name-confusion attacks, attackers create malicious components whose names resemble legitimate OSS packages or components with the hope they will be inadvertently downloaded and consumed by potential victims. Such attacks, which are also represented in the CNCF Software Supply Chain Attack catalog, include typosquatting and brand-jacking. When these compromised packages are brought into the IT environments of an organization, they can then impact the confidentiality, integrity, and availability (CIA) of systems and data.
4: Unmaintained Software
One of the harsh realities about OSS, unlike proprietary software, is that there is no “supplier”. OSS maintainers provide the software “as is”. This means there are no assurances that the software will be maintained, updated, or sustained.
Reports such as Synopsys’ OSS report suggest that 85% of codebases evaluated have OSS components that were more than four years out of date and that haven’t had any new development in two years.
Considering that software ages rapidly and new vulnerabilities are emerging at a record-setting pace, based on annual NVD metrics, this doesn’t bode well for the security and hygiene of modern applications using OSS components that aren’t actively updated.
OSS is largely supported by unpaid volunteers. Software components may not actively be developed or maintained and fixes for flaws may not occur, or if they do, may not be on the timeline desired by the software consumer using the component(s) nor aligned with the proprietary vendor’s SLA around vulnerability remediation with downstream customers. When it comes to OSS components, if you use it, you own it.
Another key factor contributing to unmaintained OSS is the reality that almost 25% of OSS projects have only one developer contributing code and 94% of projects are maintained by 10 or fewer developers, as cited by researcher Chinmayi Sharma in her publication “A Tragedy of the Digital Commons”, which is a recommended read for those wanting a comprehensive understanding of the challenges.
This is also often referred to as the “Bus Factor”, which is essentially asking “What would be the impact if so-and-so got hit by a bus?” If a project has a single maintainer, the risk is obvious. Considering that 60-80% of modern code bases are composed of OSS, one can start to get an appreciation for the reality that a significant portion of our digital ecosystem, even our most critical systems operate on software which is minimally supported and maintained — which represents significant systemic risk ripe for exploitation.
Recommendations for dealing with this risk as cited in the report include checking the project’s liveliness and health, such as the number of maintainers and contributors, the release frequency and the meantime-to-remediate (MTTR) vulnerabilities.
5: Outdated software
In this case, a project is using an outdated version of a component despite the fact that a newer version and update may exist. As cited in the Synopsys report, this situation is actually the norm, occurring in an overwhelming majority of code bases and repositories.
This of course is complicated by the intricate and dizzying array of dependencies that many modern software applications and projects have. This problem is emphasized in reports from groups such as Sonatype and Endor Labs, the latter of which published “The State of Dependency Management” which showed that 95% of vulnerabilities are tied to transitive dependencies.
6: Untracked dependencies
This is a situation where developers/organizations aren’t aware of their use of a specific dependency or component whatsoever. This can occur due to the organization not making use of tools such as software composition analysis (SCA) to understand their OSS consumption or not adopting emerging tools such as software bills of materials (SBOM), which provide visibility of components in the software organizations consume or distribute.
This is actually part of the broader push for SBOMs and Software Supply Chain Security, as the industry realized through incidents such as SolarWinds and Log4j, that most organizations lack a comprehensive software asset inventory down to the component/library level despite software asset inventory being a SANS/CIS critical control for many years. SBOMs look to counter this problem by letting organizations start to get a handle on their component inventory as an enterprise.
7: License and regulatory risk
This risk is a situation where components or projects may lack licensing or may have licensing that impedes the intended use of downstream consumers.
OWASP states that organizations need to ensure their use of OSS components complies with the applicable license terms of those components. Failing to do so can lead to licensing or copyright infringement and even legal action.
This may impact organizational business goals, M&A activities and more, as organizations make broader use of OSS components in their proprietary products, services, and offerings.
Organizations can take measures to mitigate these risks by identifying the applicable licensing for components they’re using in their software and their intended use of the components. The report also recommends organizations avoid the use of components that lack licensing entirely in addition to identifying when components have multiple or conflicting licenses applied.
8: Immature software
Not all software is created equally and of course exists on a spectrum in terms of maturity, partially due to the varying level of maintainer involvement.
Some OSS projects may not be applying secure software development practices (such as those cited in the NIST Secure Software Development Framework (SSDF)). Specific examples may include no documentation, a lack of regression testing, no review guidelines and many other best practices.
There is also the uncomfortable reality that many developers have no interest in security. This is supported by studies such as those done by the Linux Foundation and the Laboratory for Innovation Science at Harvard University (LISH) discovered that free and open-source software developers spend only 2.3% of their time improving the security of their code.
There are industry efforts and tools available as well such as OpenSSF’s Scorecard, which provides a robust set of checks for OSS projects in Github, such as the presence of branch protection, number of contributors/organizations, CI tests, fuzzing, maintenance, licensing and more. Another similar effort involves CISA and OpenSSF dubbed “Principles for Package Repository Security”.
9: Unapproved change (mutable)
OWASP defines these as situations in which components may change without the developer noticing, reviewing, or approving a change. This can occur in situations where download links change or point to un-versioned resources or even insecure data transfers that were tampered with, emphasizing the role of secure transit.
Recommended actions and mitigations include using resource identifiers for assurance and pointing to the same immutable artifact. You also can verify signatures and digests for components prior to actually installing and using them. Also, to mitigate the risk of components being compromised in transit, organizations should make use of secure protocols for the transfer and communication of network traffic.
10: Under/over-sized dependency
Lastly are situations in which components may provide very little or a lot of functionality, of which only a portion is actually used. This is often called “software bloat”.
In the undersized dependency example, due to the limited lines of code, the component becomes dependent on upstream projects for security. On the flipside, where you have code bloat or an exponential number of lines of code, you end up bringing in an increased attack surface and potentially exploitable code/dependencies despite not actually being needed or used for your intended purposes.
The report recommends in these cases going as far as redeveloping the functionality needed internally to mitigate the risk of relying on under or oversized dependencies. We’re also seeing pushes in cloud-native containerized environments to capitalize on “secure base images” as being evangelized by leaders such as Chainguard, which are minimal hardened base images with limited to no vulnerabilities.