According to a Gartner report, up to 45% of organizations worldwide would have experienced an attack on their software supply chain by 2025. This type of attack is becoming frequent and difficult to deal with due to changes in how software products are being built these days.
Today, software engineers don’t have to build applications from scratch. As much as 90% of an app can be built with 3rd party codes, discrete libraries, and Open Source software. While this approach to software development helps to simplify the process of building apps and saves a significant amount of time, it also increases threats and security vulnerabilities since malicious packages can be delivered through third-party codes and software.
Ultimately, it is becoming increasingly difficult to maintain the integrity of software supply chains. The recent increase in software supply chain risks and the high-profile breaches caused by them goes to show how serious the problem of vulnerabilities in the supply chain is.
In line with this trend, it has become imperative for organizations to take action to ensure the integrity and security of their software. In this post, we will explore the common software supply chain risks and the various ways organizations can mitigate these vulnerabilities and protect their software from attacks.
The known vulnerabilities in software supply chains
Third-party software can pose several threats to the software supply chain. Attackers may make use of various ways to exploit vulnerabilities in systems that depend on this third-party software. Some of these methods of attack include introducing malicious code into software, dependency confusion, typosquatting, and so on.
However, due to the complexity of software development and the speed at which new apps need to be delivered in today’s highly competitive digital marketplace, software engineers have no choice but to rely on third-party tools and external libraries to create applications as quickly as possible.
Vulnerabilities can be introduced into applications as a result of:
- The code you write: poor security practices in the custom code that you wrote yourself
- What you build with: the software development tools used for building apps can be compromised, exposing your software to security vulnerabilities
- What you buy: some off-the-shelf Software-as-a-Service (SaaS) applications used for app development may contain vulnerabilities
- What you use: many applications depend on third-party open-source libraries that may serve as the weak link in your supply chain.
Considering the numerous potential weak links in every software supply chain, organizations must be proactive about preventing and remediating software supply chain vulnerabilities. To do this, software engineers must understand these potential risks or threats that their software projects can potentially face. Some of these threats include:
Embedded malicious code package
One of the things attackers do in a software supply chain attack is to infect the affected endpoints with malicious software. This malware could be a virus, ransomware, trojan horse, or spyware that can wreak havoc on the affected software and computer systems.
Attackers often pick targets whose systems have high-level authorization on user devices. A notable example of an attack like this is the 2021 cyber attack suffered by Kaseya, an IT solutions developer whose clients included Managed Service Providers and enterprise clients.
One of the key IT solutions offered by Kaseya is VSA, a unified remote monitoring, and management tool. The VSA server was highly trusted on customer devices and by infiltrating it, the attackers were able to circumvent authentication controls on connected clients. This way, they could upload malicious payloads without hindrance. The Kaseya attack is similar to the SolarWinds security fiasco, where attackers were able to push malicious updates to thousands of customers which left them exposed to additional security vulnerabilities.
Exfiltration of sensitive data
Every attack with a data theft objective can be classified as a data exfiltration attack. Data exfiltration is said to occur when a malicious actor carries out an unauthorized transfer of sensitive data from a target system to a different location. A notable example of a data exfiltration attack that occurred as a result of a supply chain attack was the November 2013 attack on Target, one of the largest retail companies in the United States.
The attackers got into Target’s systems using credentials they had stolen from a third-party vendor. This attack gave them unauthorized access to Target’s customer service database, allowing them to capture the names, phone numbers, email addresses, payment card information, and other sensitive data of customers. The payment card information of 41 million target customers was exfiltrated to the attacker’s servers while more than 60 million customers had their contact information exposed.
Remote code execution
Remote Code Execution (also called Arbitrary Code Execution) is a type of cyberattack where an attacker gains access to command the operation of a device or computer remotely. Typically the attacker injects malicious code into a file, string, or an entire package that a victim intends to run on their systems. This allows the attacker to launch a full-scale attack that can compromise an entire web app or web server. Two common ways remote code execution attacks can occur in software supply chain attacks are via Typosquatting and Dependency Confusion:
Typosquatting
To execute this type of attack, the malicious actors typically create a compromised package that is identical to the dependencies that you intend to install. Usually, the malicious package has a slightly different spelling. The intention is to take advantage of a possible mistyping of an installation command. The malicious package functions normally just like the dependency that the engineer intended to install, but it also executes a malicious code that has been embedded in it at the same time.
Dependency Confusion
Dependency confusion is another approach that attackers use to launch a remote code execution in a software supply chain attack. With this type of attack, the malicious actors create a package on an external library with the same name as an internal dependency package. Since both dependencies have the same name, the package manager may install the malicious code instead. This allows the attacker to penetrate the continuous integration/continuous deployment (CI/CD) environment of the software application being developed.
How to mitigate the risks in the software supply chain?
Over the past few years, Software supply chain attacks have become one of the biggest cyber threats faced by organizations all over the world. Mitigating the risks of attacks like this has become an important part of cyber security and risk management across every organization, especially those that depend on one third-party software or another. Rather than trusting third-party platforms and public repositories blindly, it’s better to take precautions and carry out necessary checks on what is getting imported into your system. When building your software supply chain risk management plan, you can use the following ways to mitigate the risks of software supply chain attacks:
Audit your software
What makes supply chain attacks so difficult to combat is that the risk goes beyond your own systems. To mitigate the risk of these attacks, you have to do more than just protect your own perimeter. Instead, your strategy has to be more focused on ensuring that the external software systems connected to yours are just as secure.
However, this is often difficult to achieve especially when you do not even have sufficient information about the external systems you’re connected to or the code dependencies used within your application. The first step in mitigating the risk of a supply chain attack is to do a comprehensive audit of your software supply chain.
Just recently, following the 2020 SolarWinds attack which affected several US government agencies, the United States federal government made software audits a legal requirement for every company selling software to a US government agency. You should do the same too for all your systems as well. Keeping a clear record of all your software dependencies is the only way to know if your system is exposed to the risk of supply chain attacks.
Asides from auditing your software dependencies right away, you also need to audit your system again with every new release of your software. You may also need to go beyond manual auditing by doing more thorough auditing that can identify all types of dependencies, including transient ones.
Automated auditing
Asides from manually auditing your systems, you might also need to set your auditing on autopilot. Automation plays a key role in picking out vulnerabilities in any part of your software. Automated scans help discover vulnerabilities in your software code quickly so that they can be addressed before the code is pushed to production. The use of third-party code in software development will continue to grow and malicious actors will continually target these systems as a weak link to launch attacks on software on the value chain. The only way to stop them is to continually stay on top of the safety of your system by continually auditing it.
Prepare a Software Bill of Material
The software bill of Materials (SBOM) has become one of the key ways to ensure the security of your software and mitigate supply chain risks. This document is a formal, machine-readable meta-data that is designed to identify all the content of a software package. It also details other vital information such as the license data and copyrights of all the components used in building a software product.
The concept of preparing a bill of materials is not an entirely new one. Historically, it takes its origin from the world of manufacturing. Here, every manufactured product gets a bill of material which serves as an inventory of all the items included in the manufacturing process of that product.
The same principle can be applied to software supply chain risk management. The SBOM details the part of your application that you built from scratch, while also listing all the parts you got from third-party suppliers. This way, when a vulnerability is discovered, you can easily trace its source.
SBOMs are meant to be shared across various organizations that make use of a software component. This provides transparency on all the components that everyone across a software supply chain is using. As an organization concerned about the security of your software, you need to make SBOMs a priority. Before adding a component to your software product, it would help to get a Bill of materials from the vendor. This will make it easier to respond to challenges and security vulnerabilities.
Develop A Risk Management Framework
In mitigating the risks of software supply chain attacks, it is always better to take a proactive approach than waiting till an attack occurs. By outlining the possible attack scenarios beforehand, you can access your readiness to combat them in the future.
As part of your software supply chain risk management efforts, you need to develop a way to assess the likelihood of an attacker compromising your system. This way, you can determine the preventive strategies you need to adopt to limit these risks as well as the contingency plan that you have to put in place to address the risk.
Training everyone in your organization on how to respond to supply chain attacks is another essential part of your risk management framework. This will empower everyone to be vigilant in anticipating such attacks and responding appropriately if they do occur.
Conclusion
Software supply chain attacks will continue to expose organizations to various forms of risks. Thus, engineers can no longer assume that the third-party packages they use for building, deploying, and maintaining their software applications are safe and properly maintained. In fact, the major reason why software supply chain attacks have become more commonplace than before is partly because of the increased dependence on third-party codes in building software apps. To mitigate these risks, you need to take inventory of your software supply chain and put measures in place to minimize the impact of these threats on your system in order to prevent major breaches and the accompanying consequences.