Understanding Software Supply Chain Risks and How to Mitigate Them

As demand for new applications continues to rise, developers are adapting new tools and techniques to accelerate their release cycles and lower costs. As a result, modern software has evolved to include four different elements:

1. Software you write. Custom code of all types—including web and desktop applications, application programming interfaces (APIs), serverless, batch jobs, customizations to existing software, and configuration files.

2. Software you import. Code drawn from open-source libraries, frameworks, and modules.

3. Software you run. Off-the-shelf applications acquired from third parties that are used for critical purposes. Generally, the buyer has little insight into the security of these applications.

4. Software you build with. Developer tools used to build, package, test, and deploy code.

Any given application today can be built from as much as 90% open-source code, including hundreds of discrete libraries in a single application. As use of third-party open-source software (OSS) increases, so do the associated risks of security vulnerabilities, licensing complications, and malicious packages that ultimately impact the integrity of the software supply chain. The number of recent, highly publicized breach events related to the software supply chain was one of the drivers behind President Biden’s 2021 Cybersecurity Executive Order calling for urgent improvements to cybersecurity across all federal agencies.

As we detailed in a recent white paper (“Understanding the Risks of the Software Supply Chain”), there is a pressing need to improve open-source security; however, significant challenges remain. The main problem here is that most organizations today are using legacy application security testing (AST) solutions. Because these traditional tools were not designed for modern applications or the rigors of today’s DevOps and Agile development environments, their results tend to be riddled with false-positive results. Moreover, organizations are fixated on testing third-party code at the repo level. While this can be great for early developer testing, it doesn’t take into account additional libraries that are added during the build process.

Sponsorships Available

Sponsorships Available

Sponsorships Available

It also leads to hours spent validating findings in libraries that are ultimately not used when the application runs. The process of manual triage and analysis also slows down development cycles and increases the organization’s total security debt. Perhaps worst of all, these inefficiencies greatly increase the odds of a critical application vulnerability being released and then deployed in any number of production applications.

Dissecting the Risks to the Software Supply Chain

The number of software supply chain attacks in 2021 are predicted to quadruple versus the previous year’s total. Recent high-profile breaches like SolarWinds, Codecov, Kaseya, and Microsoft Exchange Server highlight both the reach and the gravity of these attacks. While the number of high-impact software supply chain attacks in recent months may seem unprecedented, this has been a worldwide problem for years.

Unmanaged use of OSS components introduces two areas of potential risk: security vulnerabilities embedded into popular libraries, and licensing issues that present legal or intellectual property (IP) risks.

Security vulnerabilities

To be clear, OSS is no more or less secure than custom code. But as with any software, it can include errors that result in security vulnerabilities. These issues can be used by hackers as backdoors in OSS/third-party libraries. Vulnerabilities can lead to supply chain attacks such as:

• Embedded malicious code packages, like the aforementioned Kaseya ransomware attack.
• Remote code execution, like the “dependency confusion” vulnerability discovered in February.
• Exfiltration of sensitive data, as seen in the well-documented Target retail breach.

Security researchers manually review public OSS code to seek out vulnerabilities such as these. Each year, thousands of new vulnerabilities are discovered and disclosed publicly, often with exploits used to prove the vulnerability exists. Unfortunately, the average library uses a version that is 2.5 years old. This increases the risk of unaddressed vulnerabilities while expanding the amount of work required when an update is finally done. According to OWASP, using old versions of open-source components with known Common Vulnerabilities and Exposures (CVE) is one of the most critical web application security risks today.

Licensing risks

Despite being free to users, use of open-source software may carry different licensing conditions. Licenses range from extremely permissive versions such as MIT and Apache (which allow users to copy, modify, license, and sub-license the code freely), to restrictive licenses like that of GPL (which requires any changes to the open source or derivative works to be licensed as open source). Undeclared or restrictive licenses can put an organization’s intellectual property at risk if developers use it in a way that allows proprietary code to be defined as “derivative work.” Licensing complexity may also impact other aspects of software commercialization (e.g., patent rights,) which may require legal expertise to navigate.

High-risk licenses are present in 69% of Java applications and 33% of Node applications. These expose organizations to significant risk by legally obligating the license holder to make any resulting software open source. And nearly all (99%) organizations today report having at least one high-risk Java license.

Challenges Managing Third-party Software Risk

While open-source/third-party libraries make up a large percentage of code, only a tiny fraction of that is relevant at runtime—38% of libraries actually get used. Plus, only 31% of library classes within active libraries ever get invoked by a given application. Unfortunately, traditional software composition analysis (SCA) tools cannot differentiate between vulnerabilities found in active libraries/classes (where there’s an actual risk of compromise) and those found in inactive ones (where there is no risk). Subsequently, these tools return false positives at a rate of 23% for Java applications, 13% for .NET applications, and 69% for Node applications. They create high volumes of alert results without sufficient context around how or why the issue was flagged.

Most SCA vendors approach third-party library analysis via siloed results without adding any context about how custom and third-party code interact. While testing source code by pointing at the repo has value, it simultaneously can create a false sense of security and add new problems for developers to address. They can cause friction between security and development teams, as well as lost time spent validating security findings in libraries that ultimately don’t matter. Nearly three-fourths (74%) of application code is third-party content that is never invoked. Any vulnerabilities in that code pose no risk to an organization and should therefore be deprioritized.

The only way to provide a concrete understanding of the vulnerabilities that need to be prioritized for remediation is by testing how custom and third-party code interact at runtime.

Process and policy risks

When a new library vulnerability is discovered and disclosed post-deployment, teams need to predefine their response practices for patching vulnerable components in a timely manner. The Kaseya ransomware attack is a great example of why this matters. The vendor was notified about the specific CVE in question back in April 2021. Unfortunately, they were still working on patches in July when the attacks happened.

Organizations also need policy-level requirements to help prevent developers from using risky libraries in the first place. An active threat landscape combined with the dire consequences of a successful attack means that policy enforcement should be a strict requirement. This sort of thing can be difficult to implement if the organization does not already have security ingrained into its development culture.

The Software Supply Chain Needs Modern Open-source Security

Hackers in 2021 have provided multiple examples of how a single open-source vulnerability can create major ripples across the broader software supply chain. While the urgency of the current situation is clear, much work remains to be done in terms of addressing the OSS risks and defining effective industry standards.

Traditional AST tools are really the root of the problem. To actualize the many benefits of open-source and third-party libraries, organizations need open-source security designed to evaluate all parts of a modern application during runtime.

White Paper: Understanding the Risks of the Software Supply Chain