Navigating Open-Source Supply Chain Threats: Protecting Your Software Ecosystem
In today’s business world, companies are determined to create software faster than ever before. Developers are under immense pressure to deliver products to customers quickly. To accelerate this process, developers often rely on pre-made “building blocks” – open-source components. This means that modern software is frequently assembled from existing parts rather than being built entirely from the ground up. Companies often blend various open-source components to create a single product, customizing it with their unique code as necessary, and that’s how they finish the job.
According to Forrester, the use of open source in software development has grown significantly, going from 36% in 2016 to 78% in 2021. And it keeps getting more popular. While using these ready-made solutions makes the process more efficient, it also comes with potential vulnerabilities. If adversaries successfully compromise these integrated libraries, they could potentially control the entire software delivery process, jeopardizing the whole project. This is called a supply chain threat.
Let’s talk about how big of a problem this is and how to make it safer.
Why Do Hackers Target Open Source?
Well, open-source projects are usually created by groups of people who really love what they’re doing – developers who work together on something they care about. Open-source software is often given away for free and can be used on different kinds of systems. Companies have the liberty to utilize it and tailor it to their products. Because these projects involve a lot of people working together, sometimes bad guys can use them for bad things.
Open-source project repositories frequently invite developers to add updates and new features, which means that any user, including malicious actors, can introduce their own code to the platform. Many communities relax controls on new members once trust is established. Consequently, an attacker can initially contribute in a constructive manner and later sneak in malicious code without being noticed.
Hackers often employ open-source supply chain threats because it is easier than going straight for particular targets, like bank servers, and trying to get around their security. To get into a bank’s computer system, an attacker can exploit a vulnerability in an open-source library that the bank uses. This lets them sneak in through a “back door” without too much trouble. If the bank identifies the attack promptly and takes action, it may still affect other companies using the same library, leading to a large-scale supply chain attack.
Software Supply Chain Threats
Attacks on software supply chain security are making waves in the open-source software ecosystem, gaining more attention, and causing greater disruptions. The researchers at the application security company Synopsys investigated and found at least one known open-source vulnerability in 84% of code bases. According to Sonatype’s 9th annual State of the Software Supply Chain report, there is a threefold increase in malicious open-source packages compared to their previous year’s report.
All of this shows that the software supply chain has become one of the fastest-growing vectors for threat actors to execute malicious code. Let’s quickly look at some tools that can help keep software safe while it’s being made.
Software Composition Analysis (SCA) Tools
SCA tools, using an application assembly file, automatically analyze the code base (including associated artifacts), generate a list of third-party libraries and components used in the software, and search for vulnerabilities. Also, such scanners can check open-source elements for compliance with licensing requirements.
Essentially, these tools check if there’s a newer version of a software part and if there are known problems with it that have been made public.
Software Bill of Materials (SBOM)
SBOM is a list of open-source and other third-party elements used in the software code base. It contains technical information about all components and their relationships with each other. SBOM may also include brief information about the component’s name, version, license, vulnerabilities, transitive dependencies, and so on.
SBOM programs help you identify and mitigate vulnerabilities by keeping track of code components, managing software licenses, and improving the software development life cycle (SDLC). The first stage of creating a program involves implementing SCA tools and other analyzers that can be seamlessly integrated into the CI/CD pipeline.
Supply-chain Levels for Software Artifacts (SLSA) Framework
This framework was launched by Google in collaboration with the Open Source Security Foundation (OpenSSF). SLSA contains a list of standards and guidelines to protect against unauthorized access and ensure the integrity of software artifacts in supply chains. SLSA clearly shows which parts of the supply chain are susceptible to vulnerabilities.
Source: https://slsa.dev/spec/v1.0/threats-overview
Before using any dependency, we must ensure that it comes from a trusted source. To be considered trusted, a source must confirm that its library meets all stated requirements and does not contain any payloads that could harm those who use it. Ideally, we should have a so-called provenance – additional information about the origin of an artifact, which can be used to trace from the very beginning who, where, when, and how something was created.
To follow this principle, SLSA introduces 4 levels of security: from the first level, which entails a complete absence of any guarantees, to the fourth level, which provides the highest degree of confidence and trust.
Level | Description |
0 | No guarantees |
1 | Documentation of the build process |
2 | Tamper resistance of the build service |
3 | Extra resistance to specific threats |
4 | Highest levels of confidence and trust |
Each level contains requirements for the code source (Source), the assembly process (Build), as well as additional information about the origin of artifacts (Provenance).
Trusted Repository of Vetted Open-Source Components
Having a trusted repository for open-source components, which are constantly updated, tested, and vetted against vulnerabilities, can significantly reduce the burden on developers. By ensuring that you always have the right library versions available, it can mitigate the risks associated with dependencies.
This is what TuxCare’s SecureChain for Java offers. The secure vetting process of SecureChain enables you to leverage the best and safest commonly used libraries for your applications. This reduces the time spent on manual updates and the risk of incorporating a library with potential vulnerabilities.
SecureChain gives you peace of mind knowing that your software supply chain is secure, allowing you to focus more on creating and improving your applications.
A Gateway for Attackers, but Not a Dead End
Open source can be a gateway for attackers to compromise many companies. Not all organizations can quickly spot open-source supply chain threats. Attackers hide their actions and use tricky techniques, like exploiting weaknesses in package management settings or hacking repositories. However, these threats shouldn’t make us avoid open source altogether. Instead, they push companies to choose open-source components more carefully and improve their security measures.