2021 State of Open-source Security Report Examines Real-world Software Supply Chains
Prompted by the devastating SolarWinds attack, the White House is reportedly preparing an executive order on software security to be released in the next several weeks. President Biden already issued an order on February 24 that directs all federal agencies to conduct a review of supply chain security risk.
The executive order will reportedly set standards for business-critical software and may include a rating system for software similar to the voluntary Energy Star ratings for appliances—or mandatory scores like those that must be posted at every New York City restaurant. Among the advocates for this approach is the Cyberspace Solarium Commission (CSC), which was formed in 2019 to develop a consensus on a strategic approach to defending the United States against cyberattacks.
Federal agencies impacted by the SolarWinds breach have either completed remediations and verifications required by the White House or are on track to complete them by March 31. The administration is particularly concerned that critical infrastructure like electrical and water systems are not impacted by the attack, and is seeking information from the owners of those systems about their exposure and any remediation efforts that they may need.
RISKS TO THE SOFTWARE SUPPLY CHAIN
This attention to software supply chains is welcome at a time when application security risk is higher than ever. For the 18,000-plus networks impacted by the breach, the Orion platform was simply a piece of off-the-shelf software they had purchased. They had no control over the integrity of software updates. Worse yet, some of the attack’s victims were not even SolarWinds customers. Suddenly, the repercussions of a successful attack on the software supply chain increase exponentially.
The recent discovery of dependency confusion vulnerabilities in commonly used Software-as-a-Service (SaaS) applications also underscores the issue of software supply chain risk. Dependency confusion attacks can enable bad actors to compromise software applications used by millions of people.
No one knew about these vulnerabilities until a security researcher discovered them at 35 major technology companies in February. Other researchers, including our own Matt Austin, discovered them in additional popular software packages—potentially exposing hundreds of millions of users of vulnerable software. At the same time, bad actors began to exploit dependency confusion with real attacks. Make no mistake, software supply chain risk is real.
THIRD-PARTY RISK TO THE SOFTWARE FACTORY
Of course, the off-the-shelf applications an organization buys are not the only element of the software supply chain. Companies involved in the creation of applications must also ensure protection for (1) custom code developed in-house, (2) developer tools utilized in the software “manufacturing” process, and (3) code from open-source libraries used in the software.
To provide insight into the latter element of the software supply chain, Contrast Labs has just published its 2021 State of Open-source Security Report, a comprehensive look at trends in usage of third-party libraries and the risks they pose for organizations.
Open-source libraries have long been a focus for application security and development teams, partly because vulnerabilities are easy to identify. The Common Vulnerabilities and Exposures (CVE) database identifies exactly which versions of which library each vulnerability exists in.
But there are two problems that many organizations have not taken into account. First, traditional software composition analysis (SCA) tools treat all CVEs the same, even though many CVEs in an application pose no risk to an organization. Among other things, this report provides analysis of just what share of CVEs fall in that category. Second, vulnerabilities listed in the CVE database are just one slice of the total vulnerabilities that exist in open-source software. Identifying CVEs falls to a very small bevy of volunteer security researchers, who are greatly outnumbered by cyber criminals looking for software vulnerabilities to exploit.
A PROLIFERATION OF LIBRARIES IN APPLICATIONS
The report is based on aggregate telemetry from thousands of real-life software supply chains represented by applications assessed and protected by Contrast OSS and Contrast Assess.
The Contrast Labs team analyzed applications written in Java, .NET, and Node, and analyzed how libraries are used in each language and in aggregate.
The sheer number of libraries in applications is astounding but is more of an indicator of complexity than of risk. The average application contains 118 libraries, and 24% of applications have more than 150 libraries. A few applications have library counts into the high three digits, and even into the thousands.
A look at programming languages shows that Java, .NET, and Node are quite different in this regard, and similar stark differences are noted throughout the report. .NET has a much more streamlined architecture than other languages due to the controls Microsoft employs over it. In fact, 43% of .NET applications contain just one library, and two-thirds have fewer than five. In contrast, Node tends to have a separate library for every functionality, and 45% of Node applications contain more than 350 libraries. Java libraries are in between, with 50% of applications containing more than 100 libraries and the rest having fewer.
Despite the large number of libraries in Java and Node applications, some libraries are in a big share of applications. For example, the most popular Java library is in 79% of applications, and all of the top 25 Node libraries are present in 92% or more of applications. Even with .NET, one library is present in 45% of applications, though the presence descends quickly from there. If any of these popular libraries is contaminated due to an attack, many thousands of applications could be impacted. This is a really big deal, as attackers know that certain libraries are used in most applications and direct significant firepower to target those libraries.
FIVE LAYERS OF OPEN-SOURCE RISK
After presenting data on library counts, the report identifies five layers of risk brought to organizations by open-source software:
- Layer 1: Active and inactive libraries. Our data shows that 62% of libraries found in applications are inactive—not used by the software in any way. This happens when a selected library brings in multiple additional libraries that have nothing to do with the functionality needed in the software. Vulnerabilities in inactive libraries pose no risk, but runtime observability into routes taken by the software is required to identify which libraries are in use.
- Layer 2: Active and inactive library classes. Even in active libraries, only 31% of classes are invoked, leaving 69% unused. Again, observability is required to see which classes are inactive and pose no risk. The outtake in the report is that only 9.4% of code in applications is active open-source library and class code.
- Layer 3: Library age. It is astounding that the average library version used in applications is 2.6 years old. Unfortunately, the data indicates that the odds of a Critical or Major vulnerability increases from 3% for libraries one year old to 13% for those that are five years old. Keeping libraries updated regularly also avoids the big headaches that occur when a several-years-old library must be updated.
- Layer 4: Open-source vulnerabilities. The average application contains 34 CVEs from third-party libraries, but an average 23% of these CVEs—and 18% of those categorized as Critical and Major—are found in inactive libraries and classes. The report calls this the “false-positive rate” of legacy software composition analysis (SCA) tools, as such solutions list CVEs in inactive libraries and classes alongside all other CVEs. As a result, organizations mark those riskless vulnerabilities for remediation—wasting time and delaying action on truly risky issues.
- Layer 5: License risk. The license risk faced by organizations was recently underscored when it was revealed that a Ruby library called “mimemagic” was shipped under a risky license, GPLv2, when it was listed as using a low-risk MIT license. Copyleft licenses like GPL can require that an entire application be made open source—even if the library covered by the license provides little or no functionality for the application. And as the mimemagic case illustrates, licenses can change at any time. Contrast Labs’ data shows that 69% of Java applications have at least one high-risk license, and 95% contain a license of variable or unknown risk. Unfortunately, most organizations take very few steps to manage license risk.
WHAT CAN ORGANIZATIONS DO?
The report concludes that the best ways for organizations to reduce software supply chain risk are as follows:
- Setting comprehensive policies for libraries, frameworks, and licensing, based on the organization’s risk tolerance
- Establishing continuous observability into active and inactive libraries and classes, library age, vulnerabilities, and licenses, to enable prioritization of remediation
- Embedding controls in continuous integration/continuous deployment (CI/CD) processes, eliminating human error and preventing risky code or licenses from being imported
At the heart of these recommendations is observability. Considering that less than 10% of code in applications is active third-party library code, observability should be a requisite part of application security strategy. Indeed, according to Anne Neuberger, the deputy national security adviser for cyber and emerging technology in the Biden administration, observability is a key requirement for supply chain security. “[T]he level of visibility has to match the consequences of the failure of those systems,” she said at the SANS Institute’s ICS Security Summit.
This is what Contrast OSS and the Contrast Application Security Platform bring for customers: full observability of every open-source dependency and what role—if any—it plays in the functionality of the software. This enables organizations to make smart application security decisions, eliminating the riskiest vulnerabilities first and passing over those that pose no risk.
REPORT: 2021 State of Open-source Security Report
PODCAST: Breaking Down Findings & Insight From the 2021 State of Open-source Security Report
WEBINAR: How To Determine What Your Open-source Risks Look Like
PRESS RELEASE: Contrast Security Study Exposes Significant Time and Resource Drain in Software Supply Chain Security
