Open Source Is Just the Tip of the Iceberg in Software Supply Chain Security

Cyberattacks’ frequency and severity remain a growing concern for organizations large and small. Hardly a day goes by without news about a major breach or break-in. Yet it’s also clear that methods are evolving and becoming stealthier. One of the more disturbing trends is attackers embedding malware in legitimate products and supply chains.

The SolarWinds attack in 2020 demonstrated just how devastating supply chain attacks can be and how far they can reach. As customers of security firm FireEye downloaded and installed legitimate patches for its Orion IT-monitoring platform, malware hidden in open source software (OSS) code infiltrated their systems.

No Simple Task

Gaining control of the software supply chain is vital, yet it’s no simple task. OSS has emerged as an essential part of the business world and increasingly delivers critical building blocks used to produce proprietary and commercial software. A growing array of products rooted in the physical world — vehicles, airplanes, medical devices, consumer electronics, and industrial machinery, to name a few — rely on OSS to operate. Hacks and attacks on these systems represent a serious and even potentially fatal risk, ranging from ransomware to sabotage.

Yet the problem is broader. Most software developed today, including applications and code embedded in physical products, contains third-party code that falls into two separate categories:

• Pre-built components that perform a specific function and are available for purchase off-the-shelf, and
• Commissioned code that is developed on an outsourced basis for use in the purchasing company’s product.

Both of these types of third-party code can contain embedded and undocumented OSS, which may harbor security vulnerabilities.

Can You Trust Your Partners?

Avoiding software supply chain risks is increasingly difficult. Much of the software any organization uses derives from a trusted vendor or partner — or it’s a mash-up based on numerous sources. When patches and updates come from trusted sources and appear authentic, there’s typically no reason to inspect them. However, if attackers successfully plant malware in legitimate software and it goes undetected through final release production, it can become a mass malware-dissemination tool.

As the SolarWinds attack showed, an organization’s defenses are only as good as the supply chain’s weakest link. An enterprise can take numerous steps to ensure that the OSS it utilizes is secure, yet it’s next-to-impossible to guarantee that the third-party code a partner or vendor supplies is equally vetted. Unfortunately, everyone relies on different techniques, tests, and standards.

While open source code isn’t inherently more dangerous than proprietary code, the widespread adoption of OSS means that the same code components can wind up in numerous applications, products, and systems. In fact, roughly 70% to 90% of any software “stack” consists of third-party code. This includes industries and sectors as diverse as public transportation, consumer electronics, telecom, and major software applications used by universities, government agencies, and others.

Moreover, open source code risks are on the rise. Hackers and attackers use several highly effective methods to target resources such as Python repositories (i.e., Python Package Index, or PyPI) and JavaScript package manager npm. This can lead to malware that installs cryptomining software or steals credentials and authentication tokens. An attack can also embed malware in seemingly legitimate code, such as a recent case where 186 npm typosquatting packages appeared in open source code for Linux systems.

Cracking Down on Bad Code

Recently, a group of organizations joined together under the umbrella of the Linux Foundation to build a framework for verifying open source code.

This group — OpenSSF (Open Source Security Foundation) — includes heavyweights such as AWS, Google, IBM, and Microsoft, as well as specialized vendors such as Akamai, Indeed, and Socket Security. Its 10-point plan [PDF] aims to create more consistent open source code production methods, improve vulnerability discovery and remediation, and reduce patching response times for open source software.

OpenSSF hopes to achieve these results via expanded use of digital signatures on software releases; replacing non-memory-safe languages; standard third-party code reviews; improved education and training for developers and others; and improved tools and best practices for the software supply chain.

All of this leads to a best practice referred to as a software bill of materials (SBOM). It delivers a catalog of OSS as well as other software that’s present in third-party (building block) code. It also displays any security vulnerabilities that this software may contain.

An Eye on Observability

Getting to a more-advanced open source vetting framework also requires a closer look at the code itself. This is particularly important because organizations not only rely on OSS but also a hybrid approach that revolves around pre-built, off-the-shelf components and custom building blocks, developed internally or by outsourcing partners.

Nearly 60% of software products today contain third-party code, according to VDC Research, most of which uses open source components under the hood. Gaining the needed insight into this code is difficult because conventional software composition analysis (SCA) has inherent limitations. While SCA remains a useful tool for decomposition of software and spotting vulnerabilities, there’s also the need to examine and analyze binary files. This makes it possible to scan the code that runs, rather than inspecting only the pieces in the build environment.

Binary SCA finds vulnerabilities in third-party code and OSS without actual source software; it provides deep semantic matching; it’s equipped to conduct analysis on real-time code; and it delivers crucial elements such as audit logging, risk reporting, API analysis, and SBOM generation and output, including formats such as PDF, CSV, SPDX, JSON, and CycloneDX. It’s a best-practice framework that delivers a comprehensive view of OSS components and other code.

With these pieces in place, it’s possible to improve vulnerability detection across all sources of the software in an application or product, boost audit and compliance capabilities, and establish a coveted SBOM. There’s no way to stop crooks and cybergangs from attacking organizations through the software supply chain, but the combination of an industry framework and the right inspection technology minimizes the risks and maximizes the gains of open source software.