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:
WHAT CAN ORGANIZATIONS DO?
The report concludes that the best ways for organizations to reduce software supply chain risk are as follows:
- 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.
PRESS RELEASE: Contrast Security Study Exposes Significant Time and Resource Drain in Software Supply Chain Security