• Home
  • Resources
  • Blog
  • Software Supply Chain Security: The Basics and Four Critical Best Practices

Software Supply Chain Security: The Basics and Four Critical Best Practices

Software Supply Chain Security: The Basics and Four Critical Best Practices
Software Supply Chain Security: The Basics and Four Critical Best Practices

What Is Software Supply Chain Security?

Enterprise software projects increasingly depend on third-party and open source components. These components are created and maintained by individuals who are not employed by the organization developing the primary software, and who do not necessarily use the same security policies as the organization. This poses a security risk, because differences or inconsistencies between these policies can create overlooked areas of vulnerability that attackers seek to exploit. 

Third-party software components are either sourced directly from vendors or from centralized registries and repositories. These vendors and repositories form the modern software supply chain. Attackers can compromise the security of the software supply chain in numerous ways, including: 

  • Exploiting bugs or vulnerabilities in third-party components
  • Compromising the development environment of a third party and injecting malware
  • Creating fake components that are malicious

Supply chain security seeks to prevent, detect, and mitigate these threats and any others that stem from an organization’s third-party components.

Reducing Enterprise Application Security Risks:

More Work Needs to Be Done

What Is a Software Supply Chain Attack?

According to the U.S. National Institute of Standards and Technology (NIST), a software supply chain attack occurs “when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer’s data or system. Newly acquired software may be compromised from the outset, or a compromise may occur through other means like a patch or hotfix. In these cases, the compromise still occurs prior to the patch or hotfix entering the customer’s network. These types of attacks affect all users of the compromised software and can have widespread consequences for government, critical infrastructure, and private sector software customers.”

Typically, attackers find a weak link in the supply chain and use it to move up the supply chain. They take advantage of trusted relationships to breach organizations that use the victim’s components, products, or services. This can allow attackers to breach a large number of well-secured organizations with one successful exploit.

Software supply chain attacks shift the focus from an organization’s internal defenses to those of its vendors. If a well-defended organization uses a vendor that has weak security practices, attackers will target the vendor. Once they compromise the vendor’s network or development process, they can use this foothold to penetrate the customer’s systems. 

MSP attacks

One particular type of supply chain attack targets managed service providers (MSPs). Organizations use MSPs to outsource technical roles, including highly sensitive roles such as network and system administration. By compromising an MSP, the attacker immediately gains access to the corporate networks of all its customers. These types of attacks have skyrocketed in recent years and are used to orchestrate ransomware attacks, point-of-sale intrusions, and business email compromise scams. A 2021 report estimated that a cyberattack on a single MSP or managed security service provider (MSSP) could wreak up to $80 billion in economic losses across hundreds of businesses.

How is malware used in a supply chain attack?

While an MSP attack leverages privileged access, other supply chain attacks compromise a vendor’s systems and plant malware, which is then transmitted to the vendor’s customers. This was the method used in the catastrophic SolarWinds attack. The attackers planted malware in a seemingly innocent software update, which was signed by SolarWinds and distributed to its customers. Major global corporations were hit, including Cisco, SAP, Intel, Deloitte, Nvidia, Fujitsu, and Rakuten. 

Follow-on attacks

Usually, a supply chain attack is just the first step in an attacker’s plan. After the initial supply chain attack, attackers will often attempt lateral movement and privilege escalation, deepening their hold on the network and gaining access to more sensitive systems. Afterward, or in parallel, attackers might steal sensitive data, sabotage operational systems, or extort the organization, as in a ransomware attack.

Why Are Traditional Cybersecurity Measures Not Enough for Software Supply Chain Security?

Supply chain attacks target one or multiple suppliers and can take several months to succeed. In many cases, these attacks go undetected for prolonged periods. Like Advanced Persistent Threat (APT) attacks, supply chain attacks are often targeted and highly sophisticated.

Organizations can be vulnerable to supply chain attacks, even with excellent traditional cybersecurity defenses. While some solutions, such as software composition analysis (SCA) software, assess the risk of third-party software, many do not. Rather, most traditional cybersecurity approaches implicitly trust elements already included in a product or service. Organizations might have state-of-the-art firewalls and endpoint security technology, but those technologies themselves, or any other part of an organization’s infrastructure, could be compromised by a supply chain attack.

A report by the European Union Agency for Cybersecurity (ENISA) showed that in approximately 66 percent of reported supply chain attacks, the attacker used vendor code to compromise the vendor’s customers. This suggests that organizations should focus on ensuring that third-party software and code is free of tampering before using it.

Another important finding is that in more than half of supply chain attacks analyzed, vendors were either unaware or did not report how the attacks occured. However, 89 percent of customer organizations exposed to supply chain attacks eventually became aware. This suggests a maturity gap in security incident reporting between vendors and their enterprise customers.

Four Best Practices for Securing the Software Supply Chain

The following best practices can help prepare your organization for the next supply chain attack.

  1. Respond Quickly to Vulnerabilities

While some supply chain attacks exploit unknown (zero-day) vulnerabilities, many of them leverage known vulnerabilities. Organizations should generate a software bill of materials (SBOM), identify components with known vulnerabilities, and apply the relevant updates or patches. Fast identification and remediation of vulnerabilities in third-party components is a primary strategy for preventing supply chain attacks.

  1. Maintain Deep Supply Chain Visibility

Organizations need to be aware of components used across their software portfolio and understand the connection between components, systems, and source code. When a vulnerability is discovered, developers need to know where the vulnerable component is used across multiple software projects to be able to remediate or remove it. Multiple tools are available that can automatically detect and help manage vulnerabilities. 

  1. Flag Problematic Components

Developers continuously source new software components that may contain vulnerabilities. So, organizations are advised to shift supply chain security left, to ensure that developers have the knowledge, tooling, and support to avoid selecting vulnerable or insecure components early in the software development lifecycle.

Once a problematic component is discovered, it should be flagged to ensure all development teams are aware of it. Flagged components or those failing vulnerability scans could “break the build,” and continuous integration/continuous delivery pipelines should automatically prevent them from being deployed to production.

  1. Continuously Monitor Components

Even if a component is identified as safe, it doesn’t mean it will remain safe. New vulnerabilities are discovered all the time, and components may also reach end of life, or their open source contributors can abandon and stop supporting them. In all of these situations, you must be able to detect the change in the component’s risk status, prioritize the severity of the risk, and if necessary, switch out the component.

Software Supply Chain Security with Mend

Two of the best products to protect your software supply chain are made by Mend. They are Mend SCA and Mend Diffend.

Mend SCA is an advanced SCA product that, since 2019, has been one of the market leaders according to analysts at Forrester Research. Mend SCA is used by organizations around the world, including six of the ten largest software organizations, among them, Microsoft

Mend SCA tells you what third-party software components are contained inside your applications and whether any of those components contain vulnerabilities that could be attacked. The things that particularly distinguish Mend SCA from other products are:

  • Accuracy. Mend’s patented algorithms are able to separate the real problems from the noise, enabling you to become 70 percent to 85 percent more efficient.
  • Ease of use. Mend provides developers with real-time information about open source vulnerabilities in their normal development environment, so developers don’t need to switch between applications or wait for results.
  • Automated remediation. Mend not only identifies vulnerable open source components, but it also automatically generates pull requests with a suggested fix. 

Additionally, Mend SCA allows you to easily create an SBOM for every software project Each SBOM identifies open source libraries, including direct and transitive dependencies, and provides a path to remediation that ensures updates won’t break the build.

Mend Diffend is a dedicated supply chain security solution that integrates with package managers (currently JavaScript and Ruby) to block the installation of malicious packages before they can attack your codebase. Diffend protects you against typosquatting attacks, malicious takeovers, ATO attacks, makefile pollution, bitcoin mining, accidental injections, botnet code injections, environment and credential stealing, viruses, package tampering, package CVEs, JavaScript CVEs, Ruby CVEs, brandjacking, and dependency confusion.

Since its public launch in early 2020, Mend Diffend has detected more than 350 known malicious packages on the Rubygems registry, and more than 1,400 malicious packages on NPM since late 2021.

Meet The Author

Adam Murray

Adam Murray is a content writer at Mend. He began his career in corporate communications and PR, in London and New York, before moving to Tel Aviv. He’s spent the last ten years working with tech companies like Amdocs, Gilat Satellite Systems, Allot Communications, and Sisense. He holds a Ph.D. in English Literature. When he’s not spending time with his wife and son, he’s preoccupied with his beloved football team, Tottenham Hotspur.

Subscribe to Our Blog