Software Supply Chain Security

The vulnerabilities of supply chains have come into focus following the pandemic, including software supply chains. With business activity increasingly moving online, it’s essential to ensure that software supply chains are safe from bad actors looking to exploit vulnerabilities in the form of breaches or hacks, resulting in compromised personal data, monetary losses, government penalties, and possibly irreparable brand damage.

This article explains everything you need to know about software supply chain security, why it’s important to organizations, and how you can secure your supply chains with Snyk.

Today, most of the software we use relies on open source code and third-party components created by developers or organizations outside the corporate name you might see on the invoice or website banner. While using outside code or components instead of building from scratch speeds up the development cycle, it also introduces a host of security risks. That’s why software supply chain security is so important.

The scope also involves evaluating the security of third-party software components and open-source libraries used in the development process and ensuring all of it is free from vulnerabilities, malware, and other cyber hazards. Think of software supply chain security as a comprehensive approach to protecting the integrity and confidentiality of software throughout its entire lifecycle.

Why is software supply chain security important?

Threats to the software supply chain are very real. In fact, according to a 2022 report, software supply chain attacks soared 742% in the last three years. A few recent incidents include:

• SolarWinds Attack: In December 2020, a Russian state-sponsored hacking group infiltrated the network of SolarWinds — a provider of IT management software to large organizations. The hackers inserted malware into a software update, which was distributed to thousands of SolarWinds customers (government agencies and private companies), giving the hackers access to their networks.

• Operation ShadowHammer: In 2019, hackers used compromised software updates to distribute malware called ShadowHammer across ASUS computers. As many as one million users were affected by the attack. 

• Huawei: United States officials warned that software provided by Chinese telecommunications company Huawei and used by organizations within their systems could be exploited by the Chinese state for espionage or other malicious purposes.

Read our guide to supply chain attacks for more examples.

Software supply chain security can thwart a cyber attack, mitigate the effects of one, or even prevent the inclusion of the vulnerability in your application to begin with. Robust security can protect the software development and deployment process against the introduction of malicious or compromised components such as malware, vulnerabilities, and other security threats. Securing the supply chain also ensures compliance with regulations and industry standards while promoting trust and confidence in the software being developed and deployed.

The issue of supply chain security is so essential to national security that in September 2022, US President Joe Biden issued Executive Order M-21-30 emphasizing the NIST guidelines for securing any software being sold to the US Government. As per the EO, the attestation form should include the following:

• Software producer’s name

• Software name

• Statement from the vendor or agency highlighting that they followed secure development practices

What is a software supply chain attack?

A software supply chain attack occurs when an attacker targets a vulnerability in the software development supply chain to insert malicious code or malware into the software. Such an attack can occur anytime during software development, from initial coding and testing to the distribution and installation stages. Once integrated into the software, bad actors can activate the malware to steal computing resources or sensitive information, disrupt operations, or take control of compromised systems. 

Attackers can use numerous vectors (methods and tactics) to target software supply chain vulnerabilities. These include (but are not limited to):

• Third-party components: Malicious actors will target third-party components (e.g., libraries or frameworks) and search for opportunities to insert malware into the software.

• Compromised development tools: Malicious actors will target compilers, build systems, or other development tools for opportunities to introduce malware.

• Compromised developer accounts: Malicious actors will seek to exploit vulnerabilities within developer accounts, like those on GitHub or other code-sharing platforms.

• Compromised software update infrastructure: Malicious actors frequently target software update infrastructure to deliver malware, as they did with Operation ShadowHammer.

• Social engineering: Malicious actors will contact employees or developers to trick them into providing access to sensitive information or systems.

4 best practices to mitigate software supply chain attacks

Securing a software supply chain is essential to any organization developing or deploying software, whether it's for internal or external use. To help you out, we’ve put together a list of four best practices you can (and should) implement immediately to help reduce the risk of a software supply chain attack. These include: 

1. Mitigate dependency confusion attacks

2. Disable arbitrary install commands by open-source packages

3. Enable multi-factor authentication across your software supply chain

4. Avoid exposure of sensitive information

1. Mitigating dependency confusion attacks

It’s easy for bad actors to launch dependency confusion attacks to exploit weaknesses in the software supply chain of companies. Here’s how to protect your organization:

• Use a scoped namespace: Scoped packages lock the package's namespace and map it to a specific user/organization. This mitigates the dependency confusion attack because there is no substitution of an underlying package from the user's original intent, and an alternate upstream repository. 

• Use repo-specific configuration for explicit upstream registry definition: Package managers, such as pip and npm, do their best to resolve package information look-ups in the absence of explicit guidance. They usually look up the public registries (e.g., npmjs, PyPI) to find newer versions of a package, and will accidentally insert a malicious package. So when using an internal package repository or proxy, such as Artifactory, or Verdaccio, ensure that you aren’t proxying requests for private packages to public registries.

Isaac Schlueter, Co-Founder of npmjs, put together some elaborate examples and configuration references for the above-mentioned counter-measures to dependency confusion. You can also check out this white paper from Microsoft with guidelines on mitigating this kind of concern of software supply chain attacks.

2. Disable arbitrary install commands by open-source packages

Some package managers, such as npm, allow any package being installed or uninstalled to execute arbitrary commands. Numerous malicious packages have weaponized this default setting. Or the attack can be executed by employing a typosquatting attack, where either through a dependency tree or by mistakenly typing a wrong package name in the command line, a victim might install a malicious package. 

It’s easy to confuse dependency names. For example, which one of the following is malicious, and which is the real package?

coffeescript

cofeescript

It’s understandable how dependency confusion attack vectors can trip someone up. The key is to not install packages thoughtlessly or by blindly copying & pasting, but rather to research and vet packages first. We recommend using the Snyk Advisor to assess the package’s health.

What is dependency confusion?

One of the most common and easiest attack vectors is dependency confusion. With this technique, malicious actors seek to exploit vulnerabilities in how organizations manage software dependencies. Attackers will upload malicious versions of open-source packages to public package management systems (npm or PyPI) using names similar to legitimate packages, also known as typosquatting or brandjacking. Developers can accidentally update or install malicious versions of packages, compromising their systems.

3. Enable multi-factor authentication across your software supply chain

As good citizens of the open-source community, we’re more dependent on each other than ever. Authentication is becoming increasingly important to ensure others can trust us and the software we maintain. So you might assume developers would be the first to enable 2FA as they’d understand the risks of not having it. Unfortunately, we found this isn’t the case. 

In January 2020, it was publicly reported that less than 10% of developers on npmjs enabled 2FA, despite this feature having existed since the end of 2017. 

We strongly recommend that you and anyone else working in a software environment take better security measures in your accounts across registries and ecosystems, such as npmjs, RubyGems, Docker, and GitHub, by enabling multi-factor authentication.

4. Avoid exposure of sensitive information

With the popularity of open source software, developers and contributors are collaborating in the open. This is great for innovation but bad for confidential information, which they may inadvertently leak. Take caution to avoid exposure of sensitive information, as it's incredibly difficult to hide sensitive information once it's been shared. Here’s how: 

• Don’t store sensitive information in a repository, in config, or in code. We have detailed 10 GitHub security best practices for you to drill down to each security practice.

• Avoid publishing packages or container images with potentially sensitive information that can end up in public registries. You can follow the 10 npm security best practices guidelines on configuring npm packages with proper .npmignore configurations.

To delve deeper, check out this video presentation on How to Mitigate Risk in Software Supply Chain Security

How does supply chain security relate to AppSec and DevSecOps?

Supply chain security, AppSec (application security), and DevSecOps (development, security, and operations) all involve safeguarding components and systems to develop, distribute, and maintain software. 

• Supply chain security: Ensures the software and components used in the development and distribution of a product come from trusted sources, and are devoid of vulnerabilities.

• AppSec: Secures the software itself and the systems it runs on while also protecting the data it processes. 

• DevSecOps: Integrates security into the software development process by bringing security teams and their processes early into the development, testing, and deployment phases. The aim is to address possible security concerns sooner rather than later.

Think about supply chain security, AppSec, and DevSecOps as working together to ensure the overall security of a product or system.

Automating supply chain security

Automating the processes and tasks involved in safeguarding the software and components used in developing and distributing a product can help maintain a strong cybersecurity posture. Not only does automation efficiently and effectively identify and mitigate security threats, it better ensures security controls are consistently applied across systems and components, decreasing the risks associated with human error.

Some automated supply chain security technology includes:

• Automated vulnerability scanning: Tools that automatically scan third-party software and components for known vulnerabilities and security threats. Scanning tools can use policies set by security teams to manage, alert and block critical vulnerabilities from entering an application.

• Automated dependency management: Tools that automatically track and manage the dependencies of a product (e.g., libraries, frameworks), then alert developers when a dependency contains known or newly discovered vulnerabilities.

• Automated supply chain analysis: Tools that automatically analyze software supply products for potential security risks (e.g., untrusted third-party components).

• Automated configuration management: Tools that automatically manage and enforce security configurations on systems (e.g., software, servers, cloud resources).

Mitigating software supply chain attacks with Snyk

Snyk can help secure your software supply chain by helping to identify, fix and prevent the use of vulnerable and malicious packages from finding their way into your codebase, including the open source packages and containers used to build applications. 

Open source security

Snyk actively researches, responsibly discloses, and helps organizations to detect and fix malicious packages in the open source dependencies pulled into your codebase. In 2020 alone, we detected over 700 malicious packages in open source registries. 

We have a proven track record of discovering, detecting, and helping customers fix these malicious packages. Examples include the electron-native-notify dependency attack on npmjs, and remote code execution in strong_password’s Ruby gem. Our Security Research team also published their findings of the SourMint ad fraud and data-leak that impacted thousands of mobile applications through a malicious SDK.

Snyk scans your package manifest files and builds a complete deeply-nested dependency tree that lists all the packages you are pulling into your application, including those introduced via transitive dependencies. These dependencies are then correlated with our Snyk Intel Vulnerability Database, and if Snyk identifies a reference to a known malicious package, the relevant package is flagged as a vulnerability, along with applicable fix advice. 

Depending on how you deploy Snyk in your SDLC, our technology can also help automate the prevention of using malicious packages or container base images – either by stopping a build or CI process from passing, sending you a notification, opening a Jira ticket, and whatever suits your workflows.

Software bill of materials (SBOM)

A software bill of materials (SBOM) is a formal record of the components used to develop software and its software supply chain relationships. SBOMs offer an opportunity for vulnerability discovery early in the software production lifecycle, neutralizing opportunities for threats before they occur.

Snyk can automate building an SBOM so organizations can easily track open source components and dependencies they use. Our supply chain security solution can scan these components to find potential vulnerabilities and offer actionable recommendations to remediate them. Check out our post on how to build an SBOM.

Container security

Snyk detects packages inside containers – whether inherited from base images or installed by user instructions via Linux package managers. Snyk Container can detect if any vulnerabilities are detected in the base image or the packages (or dependencies) added to the container, and provide actionable advice to remediate the problems. For base images, Snyk Container provides one-click fixes to allow you to quickly convert to a more secure version of your base image, while for user instructions, it helps you select more secure package versions. Snyk Container can also monitor your container images for newly discovered vulnerabilities, alerting you when they are discovered in your already built images, providing the same fix advice for the normal build workflow.

Snyk also detects other binaries installed outside the various Linux package managers. For example, suppose a particularly onerous package finds its way into popular container base images but was not installed via package managers. In that case, we could use our detection capability to find these packages. However, this is not a substitute for malware detection. 

What’s next for software supply chain security?

Mitigating the risk of software supply chain attacks requires organizations to take intentional steps to internalize the risk. This involves understanding the changing nature of software development and the new attack vectors that this introduces. It also means educating everyone on the development team on the risks and their precautions. 

At Snyk, we are constantly researching and uncovering malicious packages across ecosystems and can say with complete confidence that cyber threats are only becoming more prevalent with time. The more software we use, the more software threats will increase. Understanding these risks is the first step in preventing and reducing them.

For further reading on how to enhance your cybersecurity posture, check out Preventing Supply Chain Attacks with NPM.