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:
Supply chain security seeks to prevent, detect, and mitigate these threats and any others that stem from an organization’s third-party components.
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.
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.
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.
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.
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.
The following best practices can help prepare your organization for the next supply chain attack.
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.
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.
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.
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.
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:
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.
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.