Open Source Security Landscape 2024

A look at Synopsys' 2024 Open Source Security and Risk Analysis Report and broader Open Source Security trends as we continue into 2024

Welcome to Resilient Cyber!

If you’re interested in FREE content around AppSec, DevSecOps, Software Supply Chain and more, be sure to hit the “Subscribe” button below.

Join 5,000+ other readers ensuring a more secure digital ecosystem.

If you’re interested in Vulnerability Management, you can check out my upcoming book “Effective Vulnerability Management: Managing Risk in the Vulnerable Digital Ecosystem” on Amazon. It is focused on infusing efficiency into risk mitigation practices by optimizing resource use with the latest best practices in vulnerability management.

---

As I’ve been spending the last several years deeply focused on software supply chain security, and open source software’s role in that discussion, one of my favorite reports is Synopys’ Open Source Security and Risk Analysis Report (OSSRA).

This report is widely cited when discussing the software supply chain and open source software (OSS) by many folks across both academia and industry. I’ve cited it in my own books Software Transparency and Effective Vulnerability Management.

For those unfamiliar with the report, I will start there, and dive into some of the specific findings as well as broader OSS trends we see underway.

OSSRA Background

OSSRA is conducted annually by SCA firm Synopsys, who own the Software Composition Analysis (SCA) product Black Duck. The report is in its 9th edition and provides insights into the current state of OSS security. This particular report uses findings from over 1,000 commercial codebases across 17 industries during 2023. The report mentions the team audits thousands of codebases every year for customers as part of identifying software risks during M&A activities.

This of course provides insight into target for acquisitions to the acquiring firms around licensing risks, vulnerabilities, component make up of products and so on.

These insights are very valuable, given we don’t have widespread visibility into the codebases of commercial products, which are generally proprietary and not open for visibility unlike open source projects and codebases.

Below is an overview of the codebases across various industries and the percentage of OSS within those codebases.

It provides insights into the OSS make up of commercial code bases and products and key metrics around the number of components, licensing concerns, vulnerabilities and more, which we will discuss below.

2024 OSSRA Findings

As discussed, this years OSSRA involved over 1,000 commercial codebases, so let’s take a look at some of the findings.

Rather than typing it all out, I will be leveraging visualizations from their reporting and then breaking it down below.

First up is the emphasis that nearly ALL of the codebases involved contained OSS. In fact, nearly 80% of the entire codebase was OSS.

Not only did 84% of the codebases have lagging indicators of risk, such as known vulnerabilities, 74% of them had high-risk vulnerabilities. Now there is some nuance that needs to be emphasized here.

The report doesn’t state how they determine risk levels, but if they are using industry standardized severity scores, such as the Common Vulnerability Scoring System (CVSS), we need to point out that those risk levels are based on CVSS Base Scores. This means it doesn’t take environment and organizational context into consideration. Cyentia Institute and folks from the EPSS Special Interest Group (SIG) have stated that remediating vulnerabilities based on CVSS High and Critical severity scores alone is about as effective as randomly picking CVE’s for remediation - meaning it is incredibly inefficient and doesn’t prioritize real risk, which is foolish, given we’re drowning in vulnerabilities and have scarce resources.

Furthermore, this doesn’t mean the vulnerabilities are known to be exploited, such as in sources like the CISA Known Exploited Vulnerabilities (KEV) catalog, or likely to be exploited soon, such as in the Exploit Prediction Scoring System (EPSS). For a deeper dive you can find my previous articles on CVSS, KEV, and EPSS, which cover the need for more context and analysis for effective vulnerability prioritization.

Additionally, this doesn’t mean the vulnerable code and components are called, or reachable, meaning actually exploitable, which is why you see modern SCA tooling providing reachability analysis.

There are some great articles discussing how reachability in SCA tooling can cut down significantly on the toil and noise security pushes onto developers and some organizations such as Endor Labs are looking to lead that charge.

All that said, it is clear that most codebases examined had vulnerabilities, and a majority of them had high-risk vulnerabilities that require analysis for prioritization. Just be sure to add some context because we start beating development peers over the head with massive spreadsheets and dumps of vulnerability findings with no actual context around the true risk they pose.

For a better understanding of the damage security does by burying Development teams in toil, see my article “Security Throwing Toil Over the Fence”.

Bloat

Another specific finding worth calling out is that the average number of OSS components in a given application they examined was 526. That is 500+ discrete individual components that are now compounded in the application and each of which has its own security and licensing considerations.

As the report mentions, this reality makes automated security testing like SCA a downright necessity, as there’s no feasible way to manually scale assessing several hundreds of components for a single application, let alone at-scale across an enterprise of hundreds or thousands of applications.

This also speaks to the risks associated with software bloat. The report found that there was a 54% increase in codebases with high-risk vulnerabilities compared to the previous year.

In an amazing IEEE article titled “Why Bloat if Still Software’s Biggest Vulnerability” the challenges with bloated software are highlighted. From security risks, provenance concerns, software supply chain attacks, functionality and quality concerns and more. The article was even cited by legendary security luminary Bruce Schneier, in an article of his “Schneier on Security”.

As I discussed in my recent article “You Can’t Teach Someone to Swim When They’re Drowning”, I took a look at a recent meta-review of security control effectiveness titled “Evidence-based cybersecurity policy? A meta-review of security control effectiveness”.

Do you know what the number #1 most effective security control was?

Attack surface management

How does that fair when we have applications with several hundreds to thousands of potentially vulnerable and insecure components each with their own unique security considerations?

How many of the components are vulnerable or risky?

How many are susceptible to social engineering attacks like xz utils?

How many of the components are truly needed for the application to be functional?

These are all valid questions and while we’re seeing some promising improvements from software supply chain leaders such as Chainguard, who’s container images boast up to 97.6% reduction in CVE’s, the is just one example of a major gap in the ecosystem.

Software bloast, as mentioned by IEEE is indeed one of our ecosystems biggest risks.

Licensing

Another finding, which may seem trivial on the surface, but isn’t is the findings around licensing. As the report points out, 53% of code bases contain license conflicts and 31% contain OSS with no license or a custom license. This has implications, such as legal, when it comes to M&A, acquiring a company/product/IP and could sour a deal for potential investors.

Failing to align with license requirements such as requirements to disclose source code and licenses that are often called “copy-left” can have implications for proprietary software and the need for it to be made public for example. Failing to align with license compliance can open firms to potential litigation around copyright infringement and breach of contract claims.

Code Hygiene and Maintenance

In addition to known vulnerabilities and licensing concerns another key consideration is the maintenance and sustainability of the OSS codebases and components.

Some of the findings highlighted here in the OSSRA include:

• 14% of codebases having vulnerabilities older than 10 years old

• 2.8 years being the mean age of vulnerabilities in the code base

• Nearly half of codebases having no development activity in 24 months

• 91% of codebases containing components that were either 10 versions or more behind the most recent version of the component

Let’s unpack these metrics a bit and their implications

The decade old vulnerabilities indicate several things.

First of which is that either the commercial companies are not patching/updating components to address vulnerabilities or there are no updates to apply, as indicated by the stale level of development also cited. This is a combination of a lack of maintenance and upkeep by both the consuming organization to keep versions of components updated but also by the OSS maintainers, not maintaining the components and projects being consumed.

As I have discussed, despite all the hype of the latest vulnerabilities, malicious actors love “vintage vulnerabilities”, and these are low hanging fruit to be exploited due to their total neglect. Studies show malicious actors, such as APT’s and others actively seek out and exploit these vintage vulnerabilities that have been totally overlooked.

Part of the challenge is the sheer number of vulnerabilities, which as I have discussed is now over 20,000 known vulnerabilities (e.g. CVE’s) per year, with organizations only showing a capacity to mitigate 1 out of 5 new vulnerabilities per month, as found by groups such as the Cyentia Institute.

(As an aside, the NIST National Vulnerability Database (NVD), the most widely used centralized vulnerability database that reports on CVE’s is having major challenges, which I explain in an article titled “Death Knell of the NVD?”)

This problem isn’t unique to OSS, as studies above refer to consumer organizations ability to patch commercial products and software in their environments due to sheer number of products and velocity of discovered vulnerabilities and associated patches. The key distinction here of course is that commercial companies using OSS in their products and not keeping the components updated, patched or secure aren’t just taking on the risks themselves, but are also externalizing that risk downstream to all customers and consumers of their products who are now also at risk.

For a great example of this, take a look at the Ivanti Pulse Connect VPN product, who’s zero day vulnerabilities discovered in January have went on to impact both Federal agencies and commercial industry. Just this past week, FFRDC non-profit MITRE disclosed that they had been impacted by the Invanti vulnerabilities prior to their disclosure.

Ironically, some took to LinkedIn to try and shame and point fingers at MITRE for the incident, while totally overlooking the fact that the product vendor involved in MITRE’s incident (Ivanti) had multiple zero day vulnerabilities that got exploited and impacted customers, including MITRE, prior to Ivanti, CISA and others issuing advisories, patches and other information to help customers mitigate the risk.

You can see this article titled “MITRE was breached through Ivanti zero-day vulnerabilities” for more details on the incident, as well as see a public announcement from their CTO that was posted to their website titled “Advanced Cyber Threats Impact Even the Most Prepared”, where they lay out details of the incident as well as mitigations and recommendations for others.

For a clear example of how unmaintained, out-dated and insecure components can be a risk, take a look at this image from Kevin Beaumont who digs into some of the components.

Without artifacts such as SBOM’s, software consumers largely lack transparency around the component makeup or risk of software products they consume. Product vendors like Ivanti are of course not incentivized to provide this transparency to customers, and given the age and staleness of the components in the product, it is clear that they either did not prioritize maintaining the third party components and/or were more focused on speed to market, revenue, market share and the usual suspects that get prioritized ahead of proper security hygiene and secure software and product development.

Compounding the challenge is the lack of maintenance by the maintainers themselves. This is for a variety of reasons, such as the high “bus factor” of most OSS projects, with studies finding that 25% of ALL OSS projects have a single maintainer, while 94% of ALL OSS projects have fewer than 10 maintainers actively contributing code.

We all know the famous xkcd image below now, demonstrating how much of the modern digital ecosystem, including not just consumer goods but critical infrastructure and national security systems rely on random obscure small groups or single individuals maintaining widely used OSS components.

On the surface, it may be tempting to say what the hell, why aren’t these folks maintaining these projects. It is worth emphasizing that first, most OSS contributors are mere hobbyists, doing these activities as passion/pet projects on their own free time, without a lack of compensation.

As I have discussed in my article “Supplier Misnomer”, OSS maintainers are not your suppliers. You generally have no service level agreement (SLA) with them, and they owe you nothing. They typically aren’t being compensated. As I discuss in that article, a vocal maintainer points out that most OSS software and libraries contain language, such as that shown below.

This means you use it, you own it.

You’re responsible for the security posture and risks associated with any OSS components you decide to integrate into your commercial products. If you don’t agree with this reality, tough luck, as it is starting to materialize in compliance procurement language, such as the U.S. Federal Government Secure Software Self-Attestation Form from CISA, which soon will be required to be signed by ALL software suppliers selling software to the U.S. Federal Government.

It isn’t just stagnant code or vulnerabilities and lack of maintenance that are risks to the stretched thing OSS ecosystem but also social engineering and other sorts of attacks against maintainers as well.

We saw this recently with the xz utils backdoor which got luckily discovered before it had too large of an impact, and then the OpenSSF and OpenJS Foundations just recently issued an alert for social engineering takeovers of OSS projects. In their alert they provide some comprehensive recommendations for maintainers to watch out for suspicious patterns in social engineering takeovers.

This demonstrated that the xz utils situation likely isn’t an isolated incident and malicious actors are preying on the under-maintained and under-resourced OSS projects, and likely already have been and simply may not have been discovered yet, or have begun their active exploitation. I had a chance to provide some commentary on the xz utils incident in publications such as The Record, in an article titled “Researchers stop ‘credible takeover attempt’ similar to XZ Utils backdoor incident”.

Malicious actors are preying on the under resourced OSS ecosystem and using both technical, social and psychological techniques to exploit projects and components our entire digital infrastructure rely on.

For a deeper dive on OSS security you can find my recent article on the OWASP OSS Security Top 10 List or my coverage of the CNCF Catalog of Software Supply Chain Compromises, which covers various types of attacks, including malicious maintainers. I would also recommend a good interview I recently caught with Sonatype’s CTO Brian Fox at OSS Seattle where he dives into xz as an example titled “Addressing Advanced Threats in Open Source”.

As an aside, Sonatype, produces an incredible Annual State of the Software Supply Chain report which is in its 9th edition, and has some incredible findings, many of which substantiate the data in the Synopsys report as well. See below for an example of findings from Sonatype’s report, for example take a look at the insane growth of malicious packages being discovered:

While there are efforts underway to try and compensate the most widely used projects, even those results are mixed, as indicated in a recent study conducted by The Atlantic Council, titled “O$$ Security: Does More Money for Open Source Mean Better Security? A Proof of Concept” which investigated the role of funding in improved security outcomes of OSS projects.

But what about AI?

No discussion in cybersecurity, including about OSS seems complete without touching on AI. Luckily, the OSSRA touches on this with a section titled “Protecting Against Security and IP Compliance Risk Introduced by AI Coding Tools”.

They point out that the use of AI-powered coding suggestion tools (e.g. Copilot) have the potential to introduce IP and litigation concerns, such as a class-action lawsuit which was filed against GitHub, Microsoft and OpenAI, claiming GitHub co-pilot violates copyright and software licensing requirements.

They recommend taking precautions when conducting AI-assisted software development to avoid risks and ensure code being generated and included doesn’t expose the organization to copyright and IP related legal risks.

This of course is interesting as it has implications for not only near term litigation but also M&A implications if someone develops a product, looks to be acquired and then runs into IP and licensing compliance blockers due to using AI-assisted development tools throughout the products SDLC.

While we all have a ton of hope for the promise of AI to help further accelerate software development velocity, it isn’t without its concerns of course, which don’t only include IP and licensing as discussed above but broader implications for the introduction of flaws and vulnerabilities, as indicated in a report from cloud-native security leader Snyk titled “AI code, security and trust in modern development” which found that 96% of development teams surveyed are already using AI coding tools but not automating security scanning and assessment of the code outputs, and are also bypassing AI code security policies at their organizations.

This isn’t surprising, given Developers are generally incentivized by code velocity, burning down the product backlog and appeasing product managers, which generally doesn’t include security tasks or focus, despite common lip service from leadership across the industry.

The future open source security landscape

So looking ahead, we know some key things. We know that OSS is everywhere.

It powers consumer goods, critical infrastructure and national security systems.

We know that it is deeply embedded into commercial codebases, across nearly all industry verticals.

We know that it is poorly maintained at the macro level, and even when it is, commercial organizations using it don’t do a great job of keeping those components embedded in their products up to date.

We know there are a lot of vulnerabilities, but we also know that low fidelity legacy security tools that lack context bury Development peers in findings, toil, frustration and noise.

We know that tools and resources are emerging to try and help make more risk-informed decisions around open source consumption easier and we know malicious actors are capitalizing on the overlooked and under-resourced open source ecosystem.

That said, we know most organizations will continue to exhaust this freely available resource in attempts to minimize expenses and maximize profit.

We know that consumers largely lack transparency around what components commercial product companies are integrating into their products and commercial companies generally externalize these risks onto downstream consumers who are often oblivious to these realities.

We know that AI holds some promise to potentially aid in risk reduction around OSS usage but also has the potential to accelerate insecure software development and also introduce IP and litigation risks.

But most of all, we know that attackers are showing NO signs of slowing down in targeting the OSS ecosystem and it will take widespread systemic changes in behavior and governance to mitigate these risks.

We’re in for interesting times for an ecosystem that the entirety of the modern digital world relies upon.

Buckle up.