Software Supply Chain Security: The Basics and Four Critical Best Practices
What is software supply chain security?
Modern enterprise software is typically composed of some custom code and an increasing amount of third-party components, both closed and open source. These third-party components themselves very often get some of their functionality from other third-party components. The totality of all of the vendors and repositories from which these components (and their dependencies) come make up a large part of the software supply chain. But it’s not just code, the supply chain for a software product also includes all of the people, services, and infrastructure that make it run. Adding it all up: the software supply chain is an often large and complex web of various sources of code, hardware, and humans that come together to make, support, and deliver a larger software product.
Using third-party and open source software saves your organization time and money and frees up your developers to create novel software instead of reinventing the wheel, but it comes with a cost. These components are created and maintained by individuals who are not employed by your organization, and these individuals may not have the same security policies, practices, and quality standards as you. This poses an inherent security risk, because differences and inconsistencies between policies can create overlooked areas of vulnerability that attackers may seek to exploit.
Attackers can compromise the security of the software supply chain in a number of 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
Software supply chain security seeks to detect, prevent, and mitigate these threats and any others that stem from an organization’s third-party components. In this blog post, we look at software supply chain attacks, and how best to thwart them.
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 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.” Stated another way: a hacker breaches your trusted vendor and injects malicious code into their product, which then ends up on your systems and may allow the hacker to gain access to your sensitive data or compromise your code to gain access to your customers, set you up for a ransomware attack, or other malicious purposes. The compromised vendor software may have been unknowingly altered from the outset or the compromise may have occurred later, deployed through an update such as a patch or hotfix. These attacks are a big deal. They can be costly and they can affect all users of the compromised software which may include government, critical infrastructure, and private sector software users.
Typically, attackers find a weak link in the supply chain and use it to move up or across the supply chain to their real targets. They take advantage of trusted relationships to breach organizations that use the initial victim’s components, products, or services, allowing attackers to infiltrate a large number of well-secured organizations with just one successful exploit.
Software supply chain attacks are unique because they shift the focus from your organization’s internal defenses onto those of your vendors. A well-defended organization may not be worth the time and effort to attack directly. But if that organization uses a vendor with weak security practices, an attacker can target the vendor and compromise the vendor’s network or development process. Once that has occurred, the attacker can use this foothold to then penetrate the otherwise well-defended organization’s systems.
MSP attacks
Managed service providers (MSPs) are a frequent target of supply chain attacks. Organizations use MSPs to outsource technical roles, including those pertaining to highly sensitive work like 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 are used to orchestrate ransomware attacks, point-of-sale intrusions, and business email compromise scams. These types of attacks have skyrocketed in recent years and a multinational group of government cybersecurity organizations believe that trend will continue. A 2021 report estimated that a cyberattack on a single MSP or managed security service provider (MSSP) could cost up to $80 billion in economic losses across hundreds of organizations.
How is malware used in a supply chain attack?
Where an MSP attack leverages privileged access, other supply chain attacks compromise a software vendor’s systems and plant malware. This malware is then transmitted to the vendor’s customers. This was the method used in the catastrophic SolarWinds attack. In this well known breach, 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. The attack was so far-reaching that it’s difficult to calculate how much organizations have spent to clean up the mess, but one estimate puts it as high as $100 billion.
Not exactly new but exploding in prevalence, another source of malware that can be used in supply chain attacks is malicious packages in package registries like npm and rubygems. Attackers rely on brandjacking, typosquatting, dependency hijacking, and dependency confusion to trick tired or inattentive devs into downloading malware posing as trusted open source software. Once downloaded, the malware from malicious packages can allow attackers to steal private information including the usernames and passwords necessary to move laterally across an organization’s infrastructure and outward to that organization’s customers and partners.
Follow-on attacks
Usually the initial supply chain attack is just the first step in the attacker’s plan. After the first breach, attackers will often attempt lateral movement and privilege escalation to deepen their hold on the network and gain 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 can take several months to succeed and frequently go undetected for prolonged periods. Like Advanced Persistent Threat (APT) attacks, supply chain attacks are often both targeted and highly sophisticated.
Even with excellent traditional cybersecurity defenses, organizations can be vulnerable to supply chain attacks. In fact, supply chain attacks may be on the rise because so many organizations have beefed up their traditional security, leaving attackers with less low-hanging fruit to go after. While some security solutions, such as software composition analysis (SCA), assess the risk of third-party software, most traditional cybersecurity approaches implicitly trust elements already included in a product or service. An organization may use state-of-the-art firewalls and endpoint security technology, but these technologies, or any other part of the organization’s infrastructure, can still 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. Given the rise of malicious packages in open source package registries, open source software is another area of particular risk. Organizations should focus on ensuring that all third-party software is free of tampering before using it.
Another important finding from ENISA is that in more than half of supply chain attacks analyzed, vendors either did not know or did not disclose how the attacks had actually occurred. 89 percent of customer organizations surveyed, however, did know how the attacks on their infrastructure happened. 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.
- Respond quickly to vulnerabilities
Fast identification and remediation of vulnerabilities in third-party components should be your primary strategy for preventing supply chain attacks. 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) to inventory their third-party software, identify components with known vulnerabilities, and apply the relevant updates and patches as quickly as possible.
- Maintain deep supply chain visibility
It’s no good knowing you have something if you can’t find it. Organizations need to be aware of where components are used across their software portfolio and how those components are connected with systems and source code. When a vulnerability is discovered, developers need to know exactly where the vulnerable component is being used across multiple software projects in order to effectively remediate or remove it.
- Flag potentially vulnerable components
As they hurry to complete projects and meet deadlines, developers continuously source new software components that may contain vulnerabilities. Organizations are advised to shift supply chain security left to ensure that developers have the knowledge, support, and tools needed to avoid selecting vulnerable or insecure components early in the software development lifecycle.
Once a potentially vulnerable component is discovered, it should be flagged to ensure all development teams are aware of it. With the right tools, it’s possible to set up flagged components or those failing vulnerability scans to “break the build”, automatically preventing these components from being deployed to production, a must for continuous integration/continuous delivery pipelines.
- Continuously monitor components
A component that is identified safe today may not remain safe in the future. New vulnerabilities are discovered every day, and components may also reach end of life or their open source contributors can abandon them, leaving them with no support. In any 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.
. . . And an important additional consideration. Don’t forget to vet your vendors
When it comes to third-party software you don’t always get a chance to speak to the manager but if you’re making a large purchase for your company you should absolutely ask your vendor about their security practices. What are they doing to keep their products secure and free from tampering? What tools are they using? How are they maintaining visibility into their own supply chain?
Software supply chain security with Mend.io
Two of the best products to protect your software supply chain are made by Mend.io: Mend SCA and Mend Supply Chain Defender.
Mend SCA is an advanced software composition analysis product that analysts at Gartner have recognized as “visionary.” Mend SCA is utilized by organizations around the world to find and fix vulnerable open source dependencies, comply with license policies, and prevent malicious open source software from entering their code base, and it is currently used by six of the ten largest software companies including Microsoft.
The capabilities that distinguish Mend SCA from other products are:
- Comprehensive support: With over 200 languages supported, Mend SCA can detect vulnerabilities and licensing issues for a wide range of applications
- Speed via automation: Mend SCA not only identifies vulnerable open source components, but automatically generates pull requests with suggested fixes, thereby reducing mean time to repair (MTTR) by 80%
- Accuracy: Mend’s patented algorithms separate the real problems from the noise, enabling you to become 70 percent to 85 percent more efficient
- Automatic prioritization: Eliminate false positives with reachability path analysis that detects which vulnerabilities could make an impact, and which can be ignored
- Seamless integration: Mend SCA fits right into your existing repositories, registries, IDEs, package managers, build tools, and CI/CD pipelines, working alongside you while you code, build, deploy, and improve your applications
- Ease of use: Mend gives developers real-time information about open source vulnerabilities right inside of their normal development environment, meaning no need to switch between applications or wait for results
- Scalability and adoption: 100% adoption for open source security across every developer and application
As an additional bonus for security and compliance, Mend SCA allows you to easily create an SBOM for every software project. Each SBOM created by Mend SCA identifies open source libraries, including direct and transitive dependencies, and provides a path to remediation that ensures updates won’t break the build.
Mend Supply Chain Defender is a dedicated supply chain security solution that prevents malicious open source software from entering your code base. It integrates with package managers (currently JavaScript and Ruby) to block the download and installation of malicious packages before they can mount an attack. Mend Supply Chain Defender enables you to define policies to allow or block package downloads based on your organization’s specific needs and processes, thereby controlling the entire process of using open source dependencies.
Supply Chain Defender protects you against a wide array of attacks including typosquatting attacks, malicious takeovers, account takeover 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 2020, Mend Supply Chain Defender has scanned more than 17 million packages and detected over 800,000 malicious packages.