Top 10 OSS Risks

We’ve written and spoken extensively at this point about the prevalence of Open Source Software (OSS), which makes up between 60-80% of modern applications/codebases.

Organizations and enterprises in nearly every industry continue to take advantage of the power of OSS, including some of the most critical infrastructure sectors and National Security Systems (NSS)’s. As cited by studies we discuss below, OSS is now pervasive across not just the tech sector and startups but more than half of critical infrastructure codebases as well.

This includes systems such as those in the electrical grid, communications, water treatment facilities, national security systems and the list goes on. Some even argue that OSS itself should be treated as a critical infrastructure sector or sub-sector due to its importance in our digitally-driven society.

That said, as we saw with incidents such as Log4j, OSS adoption isn’t without its own risks and considerations. While organizations have and continue to realize the value of OSS, so do malicious actors who have realized the pervasive nature of OSS make it a very compelling target due to a single compromised project or component being able to impact thousands of organizations and millions of users and the reality that most organizations have a poor inventory and understand of the extent of their OSS consumption. This is why we have seen software supply chain attacks rise 742% over the last 3 years.

Recently, software supply chain leader Endor Labs released their Top 10 OSS Risks report, which in addition to the Endor Labs team, also included reviewers and contributors from technology and leadership roles across some of the most successful and mature organizations in the industry such as Palo Alto, Discord, HashiCorp, Citi Bank and many others.

While the report raises various concerns, risks and considerations related to OSS security, it also emphasizes that OSS can often be more secure than proprietary software, especially when you’re referring to some of the most mature and widely supported OSS projects that benefit from broad involvement and many “eyeballs”, per Linus’ Law, which in short, is that “given enough eyeballs, all bugs are shallows”.

That said, as you will see when we discuss some of the risks and studies below, a large portion of OSS projects in the ecosystem lack enough eyeballs and for even well-maintained projects, OSS consumers do a poor job of keeping their OSS consumption and components updated sufficiently, a problem that plagues the proprietary software landscape as well.

So let’s take a look at some of the top 10 risks the report raises.

Top 10 OSS Risks

1 - Known Vulnerabilities

First up in the list are OSS components with known vulnerabilities. These of course are software flaws, often inadvertently introduced by software developers and maintainers and then subsequently disclosed publicly, often by security researchers in the community.

The vulnerabilities generally get published through outlets such as NIST’s National Vulnerability Database (NVD) and may be assigned a Common Vulnerability and Exposure (CVE) ID, but they may also appear in other vulnerability databases such as OSV, GSD, the Sonatype OSS Index and others. We covered the state of the vulnerability scoring ecosystem and associated databases in an article here.

These vulnerabilities of course may be exploitable, but they may not be as well, depending on the context they are used within the applicable organization and application. While this point may seem trivial, it isn’t, and failing to provide Developers with this context leads to significant toil, wasted time, frustration and often resentment towards Security.

Legacy security tooling generally didn’t provide this context and we’re seeing more modernized tooling that can delineate between exploitable/reachable vulnerabilities and attack paths in code, as well as the continued evolution of resources such as the Exploit Prediction Scoring System (EPSS), which helps to sift through the noise and help organizations prioritize vulnerabilities that are more likely to be exploitable.

We know that going based strictly on Common Vulnerability Scoring System (CVSS) scores alone is a fools errand that wastes limited time and resources for organizations (however, that doesn’t stop many in the industry from taking this approach, including the U.S. Federal Government and Department of Defense, as pointed out Walter Haydock in this article). The image below is from the EPSS website, which is maintained by FIRST, the same organization that governs CVSS.

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 I mentioned above and more broadly, having an accurate inventory of their OSS consumption.

OWASP cites Vulnerable and Outdated Components among their OWASP Top 10 2021 list. This of course isn’t limited to OSS components, as recent reports from groups such as Tenable show that several year old vulnerabilities remain unpatched and continue to be exploited by attackers among proprietary software as well. As an industry, we aren’t exactly doing ourselves any favor and increasing the difficulty for malicious actors with this poor level of patch management and upkeep.

Other reports such as Synopsys’ OSS report show 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 software ages like milk and new vulnerabilities emerge constantly, 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. See the image below from the Synopsys report I mentioned previously.

2 - Compromise of a Legitimate Package

Next up on the list of Top 10 OSS Risks is the compromise of a legitimate package. As mentioned in the introduction of this article, 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 a maintainer only to pursue their nefarious intentions down the road. Considering compromised credentials are involved in a large portion of data breaches and security incidents per sources such as Verizon’s Data Breach Investigation Report (DBIR), it isn’t exactly an uncommon occurrence. Luckily, we are seeing major platforms/providers such as GitHub roll out two-factor authentication to millions of users. We cover some of these attack types in our article discussing the CNCF Catalog of Software Supply Chain Attack Types.

This compromised software ultimately makes its way onto organizationally owned systems, servers and enterprise environments and can wreak havoc and compromise sensitive data, having both security and regulatory ramifications depending on the data types involved.

Examples the Endor Labs report includes for this risk include the compromise of the component known as “event-stream” and the all too well known SolarWinds incident, which passed on compromised software updates to unsuspecting downstream software consumers and customers, over 18,000 of them, including many Government agencies and organizations, although this example applies to a proprietary software vendor, not an OSS project.

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) (which we covered in detail in this article).

There are of course a myriad of other guidance and resources such as NIST’s Software Supply Chain Security guidance, NSA’s Software Supply Chain Series, CIS Software Supply Chain Guidance, the Supply Chain Levels for Software Artifacts (SLSA) framework, CNCF’s publication and the list goes on.

As I often have said, as an industry we’re best practices rich but implementation poor.

To close that gap, organizations must actually do the work and make the investments of time and resources to do implementation.

3 - Name Confusion Attacks

Another risk cited in the report are name confusion attacks, of course which also are represented in the CNCF Software Supply Chain Attack catalog we mentioned above.

This is a situation where attackers create malicious components who’s name resemble legitimate OSS packages or components with the hopes of them inadvertently being downloaded and consumed by potential victims. Examples include typo-squatting and brand-jacking.

Much like Risk #2, when these compromised packages are brought into organizations IT environments they can then impact the Confidentiality, Integrity and Availability (CIA) of systems and data.

Recommendations here include verifying both the code and project characteristics for leading indicators of risk and potential nefarious activity and intent. Consumers can also verify the signatures of the components, if they exist, which is being championed by groups such as OpenSSF in their Open Source Security Mobilization Plan, and through emerging options such as Sigstore, which we cover in an article here.

That said, we still have a ways to go in terms of adoption and ubiquitous use of signatures across the entire OSS ecosystem and of course will never cover every project and component.

Endor Labs provided examples such as “Colourama” which was a typosquatting attack focused on Bitcoin and attacker-controlled wallets.

4 - Unmaintained Software

One of the harsh realities about OSS unlike proprietary software is that there is no “supplier”. As I discussed in an article titled “Supplier Misnomer” using an article from OSS Maintainer Thomas Depierre, who published an article titled “I am not a supplier”, OSS maintainers provide the software “as-is”. This means there are no assurances that the software will actually be maintained, updated or sustained. Thomas also recently appeared on an episode of the Open Source Security podcast that you can find here.

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 vendors SLA’s around vulnerability remediation with downstream customers. When it comes to OSS components, 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 being maintained by 10 or fewer developers, as cited by researcher Chinmayi Sharma in her publication “A Tragedy of the Digital Commons”, which I strongly recommend reading.

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 we have a single maintainer, well, you can see how that would be risky.

When looking at these numbers, contrasted with the reality 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 across our society. By now we have all seen the image from xkcd, which does a great job of visually depicted this fragile dependence on a sole or small group of developers.

This also creates situation where downstream consumers/developers with less-inherent knowledge of the software may need to create patches for vulnerabilities for unmaintained upstream software. I discuss this in an article dedicated to the topic of “Virtual Patching” titled “What do you mean there isn’t a patch”?

Recommendations for dealing with this risk as cited in the report include checking the projects liveliness and health, such as the number of maintainers and contributors, the release frequency and the meantime-to-remediate (MTTR) vulnerabilities.

These are often referred to as “leading indicators of risk”, where CVE’s are of course lagging indicators of risk, and if you’re wrestling with CVE’s, you are dealing with vulnerabilities and risks that are already known and exist, vice may occur in the future.

This risk is cited in sources such as the Common Weakness and Enumerations (CWE), specifically 1104: Use of Unmaintained Third Party Components.

5 - Outdated Software

This particular risk draws a lot of parallels to the #1 mentioned risk, which was using components with known vulnerabilities. Unlike the previous risk of unmaintained software, this is a case where the project is using an outdated version of a component despite the fact that a newer version and update may exist.

As I cited from the Synopsys report, this situation is actually the norm, occurring in an overwhelming majority of code bases and repositories. This of course is complicated due to 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.

The Endor Labs report states that falling too far behind the latest release of a dependency can cause challenges with timely updates in emergency situations, such as the disclosure of a vulnerability and also poses challenges for developers when trying to update and migrate versions in their applications.

Recommendations here involve dependency hygiene, or keeping dependencies up-to-date and is often facilitated through the use of tools such as the popular OSS tool “renovate", which can help automate dependency updates, enable scheduling to avoid disruptions and boasts support for widely used platforms such as GitHub, GitLab and others.

However, dependency management is far from trivial and is often referred to as “dependency hell”, as documented by Sourcegraph in this article titled “The Nine Circles of Dependency Hell”.

6 - Untracked Dependencies

Coming in at #6 on the Top 10 OSS Risks list is 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 Bill of Materials (SBOM)’s which provide visibility of components in the software organizations consume or distribute.

This is actually part of the broader push for SBOM’s 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. SBOM’s look to help aid this problem by letting organizations start to get a handle on their component inventory as an enterprise.

The Endor Labs expands on this risk by stating components that fly under the radar, aren’t tracked, or aren’t something organizations are aware of pose risks, especially if these components are pervasive in their enterprise and have exploitable vulnerabilities.

The report recommends taking actions such as evaluating and comparing SCA tools to ensure you’re using tools that support producing accurate BOM’s both with and without the help of package management tools (such as Maven or npm).

If organizations have incomplete SBOM’s (or no SBOM’s), insufficient SCA tooling in place, poor visibility of 3rd party code and so on, they are at risk of having untracked dependencies, and this is common for many organizations and as the report points out, presents unmitigated risks.

This is of course a best practice supported through various sources of guidance, including OWASP’s Software Component Verification Standard (SCVS) in V1 - Inventory and V2 - SBOM’s.

For those looking to learn more about SBOM’s, organizations such as NTIA and CISA have provided plenty of documentation.

7 - License and Regulatory Risk

#7 may not jump out as the most appealing or exciting risk, but it is a real risk, often overlooked by organizations when making use of OSS.

This risk is a situation where components or projects may lack licensing, or may have a licensing that impedes the intended use of downstream consumers.

The report 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 infringements 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.

The Endor Labs report cites a specific example where the Free Software Foundation entered litigation with Cisco Systems in an attempt to recover damages from copyright infringement.

The report points to resources such as “Reuse Software” which can help identify what license files are under and who owns the copyright.

The same Synopsys report I have cited throughout this article found that 53% of audited codebases contained license conflicts and 20% contained OSS components with no licenses or a custom license.

8 - Immature Software

Not all software is created equally and of course exists on a spectrum in terms of maturity, as we have discussed, 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 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 FOSS 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 FOSS developers only spend 2.3% of their time on improving the security of their code. In fact, some of the surveyed OSS developers described security and secure coding as a “soul-withering chore”, which doesn’t exactly give a warm feeling of confidence in the prioritization of security among the OSS community.

The risks associated with immature components or projects include various operational risks. This includes software not working as intended, being complex, inefficient and potentially insecure.

Mitigations recommended by the report include checking whether projects follow secure development and more generally, development best practices. This includes the presence and quality of up-to-date project documentation, test coverage, CI/CD pipelines for regression testing and also the number of downstream dependents, which can provide some speculative insight into the maturity and adoption of a project or component.

There of course 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.

9 - Unapproved Change (mutable)

Second from last on the list of OSS risks in the report of unapproved changes. The report defines these as situations where components may change without the developer noticing, reviewing or approving of 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.

The report cites a specific example of the CodeCov Bash Uploader where piping downloaded scripts directly to bash without verifying the integrity can introduce risks and vulnerabilities into environments.

Actions and mitigations recommended including 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 transfer and communication of network traffic.

10 - Under/over-sized Dependency

Last up on the Top 10 OSS Risks report from Endor Labs is Under/Over-sized Dependencies. This is a situation where components may provide very little or a lot of functionality, of which only a portion is actually used.

In the under-sized dependency example, due to the limited lines of code (LoC), the component becomes dependent on upstream projects for security. On the flip side, where you have code bloat, or an exponential number of LoC, 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. Specific examples cited by the report include Apache Log4J (large dependency) and left-pad (small dependency). For further reading on the topic, the report points to the report “A comprehensive study of bloated dependencies in the Maven ecosystem”, which discusses the risk associated with bloated dependencies, including increased maintenance, attack surface and potentially vulnerabilities.

Wrapping It Up

Bringing the article to a close, the Top 10 OSS Risks report from Endor Labs represents a comprehensive resource that lays out some of the most prevalent risks associated with OSS consumption and leans on the expertise of a robust set of reviewers and contributed with diverse security expertise and experience.

As organizations continue to make use of OSS and its myriad of benefits, consumers (and producers) should be familiar with the most prevalent OSS risks and how to mitigate them and ensure the risk is within the organizations risk tolerance.

Given the prevalence of some of these risks, as cited throughout the article, we have a large portion of our digital infrastructure with significant levels of risk that could impact nearly every aspect of society.