Why Open Source Risks are Larger than SCA Tools

Open Source Software is critical. However it often comes with inherited risks that are larger than what can be tackled by conventional Software Composition Analysis (SCA) tools. This post aims to compare the current and emerging risks in open source software supply chain with the capabilities of conventional and next-generation SCA tools.

Why use Open Source Code?

To build and ship software to your customers. Fast. Imagine having to build frameworks like Springboot, Ruby on Rails, Django, Express from scratch before your developers can write business logic. Lets say a new requirement needs the ability to integrate with a SAML based identity provider, would you invest engineering bandwidth in learning SAML from RFC and building a client library from scratch or use the one available from open sources?

Am I using Open Source?

Almost certainly yes. If we just focus on organizations shipping software products to their customers, then there is, most likely, a heavy dependency on OSS in the form of libraries, container images and other platform software. Even if your organization has a policy of not using open source components (very rare!), you are still inheriting and thus using open source components from your commercial software vendors who in turn depend on OSS.

Even if you are building a custom software development framework over an HTTP router or Servlet, you are still leveraging open source in forms of protocol & service adapters, cryptography and other libraries.

Can I move away from Open Source?

Many companies build their businesses on open source software, code that would cost firms $8.8 trillion to create from scratch if it weren’t freely available. - Frank Nagle and colleagues @ HBR

This is really the value of OSS to the software development industry. If you are building software for your business, typically it will cost you 3.5 times more to do so without OSS. This is substantiated by Linux Foundation Open Source Census II that estimates 70-90% of modern software constitute OSS.

Is OSS Risky?

No. Open Source ecosystem is not the problem. In fact it is a critical resource for global economy today. The greatest strength that led to the success of OSS is its decentralized, volunteer and community working model. The key idea behind OSS is building something to solve one’s own needs and having it evolve with the community extending it to solve their own needs.

Trust and security for OSS is however a Tragedy of Commons situation. The incentive model of the OSS ecosystem and the economic platform supporting it does not always align when it comes to enterprise security requirements. After all, a volunteer offering a software to the community is not obliged to follow the security requirements of a large enterprise. This is really the vulnerability that has been exploited in Open Source Software Supply Chain Attacks.

What are the Risks?

There are three key problems that arise due to the uncontrolled nature of the code inherited from the open source ecosystems in different forms. These problems impact the consumer of OSS i.e. software development teams leveraging OSS to ship software to their customers.

Vulnerabilities
Malware
Legal & Compliance

For this post, we will ignore legal risks which have been tackled fairly well through technical and non-technical means. Vulnerabilities inherited from OSS code makes your own product vulnerable, leading to potential breach. A real life example is Zoho Manage Engine Authentication Bypass and Remote Code Execute due to dependency on Apache Santurio vulnerable to CVE-2022-47966.

Malicious Open Source

Why bother finding and exploiting complex vulnerabilities in enterprise software when you can just deliver malicious code to them? Nation state sponsored attackers realized this with early evidence in Solarwinds Hack and Sunburst Backdoor. Open Source is the largest software supplier to any enterprise today, directly or indirectly. Directly is when they build their own software leveraging OSS libraries and indirectly is when their commercial software supplier depends on OSS libraries. This makes OSS a high value target to compromise large enterprises.

The xz backdoor, Ledger connect-kit crypto Hack, CodeCov Backdoor Stealing CI Credentials are just some of the incidents caused by malicious OSS. In fact, Sonatype finds 700% increase in malicious OSS components.

Attack Vectors for Supplying Malicious OSS

Attack vectors observed in real life OSS supply chain attacks are documented in SLSA Threat Model, CNCF Supply Chain Compromises among others. Notable attack patterns involve

Attack Vector	Description	Notable Incident
Source Compromise	Attacker compromises OSS project source repository	PHP git server compromise
Malicious Code Submission	Attacker submits intentionally vulnerable or malicious code to an OSS project	SushiSwap
Malicious Maintainers	A privileged maintainer of an OSS project turning malicious	xz Attack
Build Environment Compromise	Attacker compromises CI/CD environment and injects backdoor in package artifacts	Solarwinds Orion IT Hack
Package Registry Compromise	Attacker compromises a package registry and publishes malicious package	Docker Hub credentials exposure
Typosquatting	Attacker publishes malicious components in public registries (e.g. PyPI) that resembles popular package	Python `requests`
Dependency Confusion	Attacker exploits package manager’s registry precedence to hijack internal packages	See reference section
Lockfile Poisoning	Attacker tampers auto-generated `lockfiles` and exploits cognitive load of code reviewers to sneak in malware in OSS project	See reference section
Revival Hijack	Attacker re-registering an OSS project in a package registry (e.g. PyPI) that has been deleted by original maintainer	See reference section

Vulnerable vs. Malicious OSS

Vulnerabilities are unintentional side-effects of software bugs that are inevitable. Vulnerabilities in OSS components may or may not affect a downstream consumer. Their exploitation may not be trivial. On the other hand, a malicious OSS component has the intention to cause harm and almost always leads to a compromise for consumers. To safeguard against OSS supply chain risks, ability to detect and prevent untrustworthy and malicious OSS components is the most important aspect of an enterprise OSS governance program.

Malicious OSS is a larger threat than vulnerabilities because of the direct impact. This is evident by analyzing CNCF Supply Chain Compromises. Outdated dependencies only account for 1.2% of the compromises while publishing infrastructure compromise and malicious maintainers contribute to 30% of compromises among tracked incidents.

What is Software Composition Analysis (SCA)?

SCA tools identify the composition of a software artifact, particularly it’s 3rd party dependencies and their vulnerabilities. Typically they rely on a vulnerability databases such as NVD or OSV. The process involves matching discovered components by coordinates aka. package versions with a vulnerability database to identify vulnerable components. These classes of tools have evolved over the years with code analysis capabilities to reduce noise and eliminate false positives.

Next-Gen: Reachability

An OSS library is not vulnerable in its entirety, some code block within a function can be vulnerable. An application using a vulnerable version of an OSS library is impacted only if there is a reachable path from the host application to the vulnerable function in the library. This is easier said than done due to complexities involved in whole program call graph generation and lack of precise vulnerable function symbols in security advisories. Next-gen SCA tools performs reachability analysis to identify evidence of exploitability to help prioritize fixing and eliminate noise.

Does SCA Solve OSS Risks?

Partially. SCA has been attempting to solve the problem of vulnerable OSS components for more than a decade now. High noise and precision gaps in early SCA tools did not solve the problem effectively. Next-gen SCA tools aim to solve that through code analysis. However, SCA tools do not protect against malicious OSS and software supply chain attacks that arise due to complexity and vulnerability in any of the systems involved in software delivery within and outside an enterprise.

Risk	SCA	Gap
Known vulnerabilities	Yes	Nuances in vulnerability database and code context
Unknown vulnerabilities	No	No visibility on vulnerabilities unless available in a database
Malicious OSS	Limited	Only when publicly known and included in a database to match with
Typosquatting Attacks	Limited	Using attributes such as popularity, origin trust etc. but without a remediation path
Dependency Confusion Attack	No	No visibility on origin and provenance of a source package

Managing Open Source Risks

OSS is vast and its dependency for enterprise software is equally significant. Uncontrolled nature of OSS introduces multiple security risks. To mitigate these risks, appropriate controls must be implemented at consumer end. Secure Supply Chain Consumption Framework is an OpenSSF project working on maturity models for software consumers to mitigate these threats. The general guidelines for managing Open Source risks involves building the technical capability to

Identify all third party / OSS components across all product portfolios
Define, implement and enforce policy driven security guardrails to prevent risky OSS from getting into your products
Define practices to quickly upgrade / replace / re-build OSS components when impacted by critical risks

Register for SafeDep Cloud

Leverage the power of SafeDep cloud to build an organization wide SBOM, export as CycloneDX and execute flexible queries to discover actionable risks.