Skip to main content

Open Source Supply Chain Security

In this article we are going to look at the growing issue of software supply chain attacks via some examples and then look at the emerging field of open source supply chain security: what it is, current best practices, the institutional landscape and emerging legislation.

Since there are more authoritative sources on the Internet, this article aims to provide the key concepts. This is an executive summary of this topic with lots of references to further reading.

Supply Chain Attacks

A software supply chain attack occurs when an attacker compromises the software development or distribution process to introduce malicious code into legitimate software or updates that are then delivered to end users.

"A supply chain attack is a cyber-attack that seeks to damage an organization by targeting less secure elements in the supply chain.[1] A supply chain attack can occur in any industry, from the financial sector, oil industry, to a government sector. A supply chain attack can happen in software or hardware. Cybercriminals typically tamper with the manufacturing or distribution of a product by installing malware or hardware-based spying components." - Supply Chain Attack, Wikipedia

Example: Solar Winds

The SolarWinds attack, uncovered in late 2020, stands as one of the most significant and sophisticated cyber espionage campaigns ever. Attackers compromised SolarWinds' Orion software, a network management tool used by numerous government agencies and large corporations worldwide.

By doing so, the perpetrators were able to embed malicious code within legitimate software updates, enabling them to gain unauthorized access to the networks of organizations that installed these tainted updates. Once inside, they could move laterally, steal data, and potentially disrupt operations. The scale of the attack was massive, with thousands of entities affected, including key U.S. government agencies.

Further Reading:

Open Source Supply Chain Security

Digital Supply Chain Security refers to the strategies and measures implemented to protect digital assets and processes (such as software) as they move through various stages of development, distribution, and deployment - essentially trying to prevent attacks like the one above.

When focusing on open source, supply chain security becomes particularly challenging because of the communal and transparent nature of the development environment.

Open source software often involves numerous contributors, some anonymous, and can be integrated into a wide variety of applications and platforms. As such, it's imperative to ensure that malicious actors don't introduce vulnerabilities, either inadvertently or deliberately, into these shared code bases.

Open source supply chain security, therefore, emphasizes:

  • rigorous vetting of contributions
  • continuous monitoring of dependencies
  • prompt patching of known vulnerabilities
  • community collaboration to maintain the trustworthiness of shared software resources.

Examples

  • event-stream (2018): A malicious actor took over maintenance of a popular (>2m downloads per week) npm package, introducing a targeted payload that stole Bitcoin funds from several users.

  • us-parser-js (2021): Threat actors offered access to the developer account of this package on the dark web. An installation script was introduced into the package so that the victim's computer would be used to mine crypto currency and report back user credentials.

  • left-pad (2016): While SolarWinds is a high-profile, deliberate attack, the supply chain is at risk from vandalism too. left-pad was a popular but small JavaScript library that was removed from the npm repository by its author in protest over a decision made by NPM's administrators, unexpectedly breaking numerous dependent projects and highlighting vulnerabilities in modern software dependencies.

  • Heartbleed / OpenSSL: The OpenSSL library is the default encryption implementation used by the majority of the Internet. The critical Heartbleed vulnerability of 2012 not only affected vast nubmers of servers and applications, but demonstrated a weakness in the open source supply chain present in many packages - that of too few maintainers. This is commonly refered to as the "One Guy in Nebraska Problem" after this XKCD cartoon.

A Growing Problem

As the volume of open source software grows, the number of open source developers increases, the cost of compute reduces and the cost of initiating a supply chain attack reduces, the importance of securing the open source supply chain grows more important:

"Supply chain attacks are increasing exponentially. In 2021 the world witnessed a 650% increase in software supply chain attacks, aimed at exploiting weaknesses in upstream open source ecosystems. For perspective, the same statistic was 430% in the 2020 version of the report." - State of the software Supply Chain, SonaType

Transitive Dependencies

It is worth drawing attention to the issue of transitive dependencies. A developer may make use of up to fifteen (say) dependencies directly in a moderately-sized software application. However, each of these dependencies may have dependencies of their own and so on.

It is estimated that the average JavaScript dependency tree contains 86 packages, while for PyPI (Python libraries) it is 7.3. See: How much do we really know about how packages behave on the npm registry?

Further Reading:

Components of the Open Source Supply Chain

Open Source Supply Chain, adapted from the LF Open Source Software Supply Chain Security article.

Attacks can occur at any point in the open source supply chain, so let's look at the different parts of this system. The above diagram (adapted from "Open Source Software Supply Chain Security" by the Linux Foundation shows the four main components, arranged in a cycle:

  • Users: Individuals or systems that utilize software for various tasks and applications.
  • Package Managers: Tools or software that automate the process of installing, upgrading, configuring, and removing software packages in a consistent manner.
  • Repositories: Centralized storage locations or databases where software packages are archived, distributed, and made available for download.
  • Developers: Individuals or teams responsible for creating, updating, and maintaining software codebases and packages.

Each of these is an opportunity for an attack.

Exploits. Vulnerabilities & Attacks

  • Exploits (or "hacks") are methods that leverage a vulnerability to bypass security and gain unauthorized access, privileges, or capabilities within a system.

    "An exploit (from the English verb to exploit, meaning "to use something to one’s own advantage") is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerized)." - Exploit, Wikipedia

  • Vulnerabilities can be accidentally introduced by maintainers, and they may range from low impact or not possible for an attacker to exploit, to high impact and easily exploitable.

    "Vulnerabilities are flaws in a computer system that weaken the overall security of the device/system. Vulnerabilities can be weaknesses in either the hardware itself, or the software that runs on the hardware. Vulnerabilities can be exploited by a threat actor, such as an attacker, to cross privilege boundaries (i.e. perform unauthorized actions) within a computer system." - Vulnerability, Wikipedia

    Even if you have vulnerabilities in production, you have some time to address them; they may not be discovered or exploited before you update to a fixed version.

    See:

  • Supply Chain Attacks (or exploit) involve malware that is intentionally introduced into a package by an attacker.

    "A supply chain attack can happen in software or hardware. Cybercriminals typically tamper with the manufacturing or distribution of a product by installing malware or hardware-based spying components." - Supply Chain Attack, Wikipedia

    You don't have a few days or weeks to mitigate the issue. You need to catch it before you install it on your own laptop or on a production server.

    See:

    • The MITRE ATT&CK aims to be a knowledge base of all the tactics, techniques, and procedures (TTPs) used by attackers in cyberattacks.

Examples of Common Supply Chain Attacks

Attack NameDescriptionExample
Dependency/Manifest ConfusionAn attacker publishes a package with the same name as a private package used by a specific company but in a public repository. If the company's build system is not properly configured, it may pull the malicious public package instead of the intended private one.Alex Birsan
Package Stealing/HijackingAttackers can sometimes take over abandoned or poorly maintained packages and introduce malicious changes. They then publish the updated malicious version, and dependent systems automatically pull in these updates.us-parser-js above.
Malicious Forks/MasqueradingAn attacker might create a fork of a popular open-source project, introduce malicious changes, and then attempt to promote or advertise this fork to unsuspecting users.Stephen Lacy
RepoJackingAn attack where a malicious actor registers a username and creates a repository used by an organization in the past but which has since changed its name. Doing so results in any project or code that relies on the dependencies of the attacked project to fetch dependencies and code from the attacker-controlled repository, which could contain malware.CTX
Piggybacking on Legitimate Packages/Pull Request SneakingSome attackers contribute malicious code to popular and legitimate projects, usually through pull requests. If not thoroughly reviewed, the malicious code might get merged into the main project.Teleport
Download Count Inflation/Star JackingTo make a malicious package look popular and trustworthy, attackers artificially inflate the download count.Pampyio
Trojan PackageIn the trojan package infection method, the attacker publishes a fully functional library but hides malicious code in it.lemaaa
Joke PackagesNot strictly an attack, but publishing packages as jokes. Can harm the supply chain and cause dependency bloat.true
Cache PoisoningExploiting weaknesses in parameter handling by package managers.Rack
TypoSquattingTyposquatting is the practice of obtaining (or squatting) a famous name with a slight typographical error."Amzon.com"

Once a package, even a legitimate one, becomes dependent on a malicious package, it might unknowingly propagate the malicious behavior when others use it.

Note: this table is just a list of notable examples. See The MITRE ATT&CK for a complete, authoritative list.

Best Practices

As mentioned at the start of the article, this is a fast-evolving area. In this section, we'll outline a few important concepts that you should be aware of.

See:

Software Composition Analysis (SCA)

According to https://en.wikipedia.org/wiki/Software_Composition_Analysis:

Software Composition Analysis (SCA) is a practice in the fields of Information technology and software engineering for analyzing custom-built software applications to detect embedded open-source software and detect if they are up-to-date, contain security flaws, or have licensing requirements.

See Also:

Static Application Security Testing (SAST)

SAST, or Static Application Security Testing, is a type of software security testing that analyzes the source code of an application for potential security vulnerabilities without executing the code.

"SAST is a vulnerability scanning technique that focuses on source code, bytecode, or assembly code. The scanner can run early in your CI pipeline or even as an IDE plugin while coding. SAST tools monitor your code, ensuring protection from security issues such as saving a password in clear text or sending data over an unencrypted connection." - Static Application Security Testing, Snyk

Some leading SAST tools are Checkmarx, Veracode, SonarQube, Fortify and Coverity.]

See Also:

Dynamic Application Security Testing / Penetration Testing

  • Dynamic Application Security Testing (DAST): DAST involves executing the code of an application and examining its behavior for potential security vulnerabilities. This type of testing can help identify potential security risks that may not be apparent from examining the code alone.

  • Penetration Testing: Penetration testing involves attempting to actively exploit vulnerabilities in a software system or application to determine its security weaknesses. This type of testing is usually conducted by security experts who use manual and automated techniques to simulate real-world attacks.

Tools for these include Metasploit, Zed Attack Proxy (ZAP), Fortify WebInspect and Burp Suite.

See:

Infrastructure Security Testing

Infrastructure security testing involves evaluating the security of the underlying infrastructure that supports a software system or application, such as networks, servers, and databases.

Some leading tools include Nessus, Nmap and Qualys

Attestation / Signing

Via the use of secure hashes and digital signatures, it's possible to prove that code was either authored by someone ("provenance attestation") or built by something ("build attestation").

This is useful when producing or consuming open source software.

Developer Best Practces

Linux Security suggests:

  • Using multifactor authentication on developer accounts.
  • Having a formal change-tracking process.
  • Giving each release a unique identifier.
  • Testing for bugs and unexpected behavior throughout the development cycle.
  • Documenting and managing a project’s dependencies.
  • Cryptographically signing a project’s integrity (attestation, above).
  • Checking digital signatures of dependencies.
  • Checking for signature revocation (just checking attestation is not enough).
  • Tracking and addressing vulnerabilities in open-source tools used in development.

... many of which are contained in the OpenSSF best practices (see below).

Endpoint Detection and Response (EDR)

Endpoint Detection and Response (EDR) is a cybersecurity solution that continuously monitors and analyzes endpoint data to detect, investigate, and mitigate advanced threats across a network.

https://en.wikipedia.org/wiki/Endpoint_detection_and_response

Web / Mobile Application Security Testing.

  • Web Application Security Testing: Web application security testing focuses on identifying security vulnerabilities in web applications, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
  • Mobile Application Security Testing: Mobile application security testing focuses on identifying security vulnerabilities in mobile applications, such as those running on iOS or Android platforms.

See:

Initiatives / Industry Bodies

  • Vulnerabilities

  • OpenSSF: A foundation (part of LF) devoted to the securing the open source ecosystem. Most of its projects are hosted on GitHub. Projects of note include:

  • The MITRE ATT&CK aims to be a knowledge base of all the tactics used in such supply chain attacks.

  • SLSA: "Supply chain Levels for Software Artifacts". This is a framework designed for creating repeatable builds with provenance of their components.

  • OpenChain: an ISO standard for open source license compliance, developed and hosted by the Linux Foundation. It provides a set of requirements to create effective open source management systems, helping companies to minimize legal risks related to open source software use and improve efficiency and trust in the software supply chain.

  • Renovate Bot: Renovate Bot is an open-source tool that helps to automate the process of updating dependencies in software projects. It scans your project for dependencies, automatically opens pull requests to update outdated ones, and provides change logs and compatibility information to assist in validation and troubleshooting.

  • Secure Supply Chain Consumption Framework (S23C2F): The S2C2F SIG is a group working within the OpenSSF's Supply Chain Integrity Working Group formed to further develop and continuously improve the S2C2F guide which outlines and defines how to securely consume Open Source Software (OSS) dependencies into the developer’s workflow.

  • Financial Services Information Sharing and Analysis Center (FS-ISAC): a non-profit organization dedicated to reducing cyber-risk in the global financial system. It enables members to share threat and vulnerability information, collaborate on incident response and mitigation, conduct synchronized response, and provides tools for better protection against physical and cyber threats.

Legislation

US

Following SolarWinds the US government became concerned with the issue of software supply chain security. See the linked articles below for more information. However, a very brief summary is as follows:

  • Removing barriers to sharing threat information between different government departments and the private sector.
  • Adopting a zero-trust architecture, deployment of MFA, encryption etc.
  • Accelerate movement to secure cloud services
  • Enhance Software Supply Chain Security, adopting the standards and best practices, SBOMs etc.
  • Establish a standard "Playbook" for responding to cyber incidentts.
  • Improving detection of cybersecurity vulnerabilities and incidents e.g. by deploying EDR

See:

EU

UK

Further Reading

Maturity Checklist