Software Supply Chain Attack vs. Supply Chain Vulnerability: What's The Difference?

Cyberattackers are using the software supply chain as an initial intrusion vector at a rapidly increasing rate: The 2022 Verizon Data Breach Investigation Report found that 62% of system intrusions they looked at were the result of supply chain compromises, and the 2022 M-trendsreport showed supply chain compromise overtaking phishing as an initial intrusion vector. Within the past year, examples such as SolarWinds SUNBURST, Kaseya VSA/REvil, and Log4Shell impacted anywhere from thousands to millions of organizations, and made headlines worldwide.

But not all software supply chain security issues are the same, and understanding the differences is vital for security teams hoping to rapidly triage and remediate the next one that hits.

Supply Chain Attacks vs Supply Chain Vulnerabilities

A software supply chain attack is an event in which an attacker compromises a software provider and uses that software provider's privileged access to compromise their customers or users. The software provider could be an enterprise software company such as SolarWinds, an open-source project, or a managed services provider

A software supply chain vulnerability is an accidental security flaw in a piece of software that is incorporated into other applications, leaving them vulnerable—potentially without the knowledge of the application administrator. For example, the Log4Shell vulnerability was not an intentional attack, but it caused thousands of organizations and millions of devices to be vulnerable to attack.

Beyond exploiting accidental vulnerabilities, attackers have many ways of intentionally introducing malicious code into trusted open-source packages. Dependency confusion, typosquatting, and simply adding malicious code and issuing a pull request are all methods by which attackers can abuse the open source software supply chain to introduce malware into a targeted environment. A 2021 Sonatype report indicated a 650% year-over-year increase in attacks against open source software providers.

While there's a difference in how we define supply chain attacks and supply chain vulnerabilities, these loose categories are not mutually exclusive! For example, in the SUNBURST attack, the attackers intentionally introduced their own malicious code into the SolarWinds Orion product, which was then distributed through SolarWinds' own update delivery channels. In the case of the Kaseya VSA attack, the REvil ransomware group exploited an accidental vulnerability in the VSA software, which is commonly used by managed service providers (MSPs) to administer IT assets for their customers. This created an opening for attackers to compromise the MSPs' customers and distribute ransomware through the VSA software, effectively making the attack vector a supply chain dependency. These examples show how, whether the attackers introduce the vulnerability themselves, or simply find and exploit it, these layers of obfuscation in an attack create a compounding challenge for detecting and responding to the threat.

Why Does It Matter for Software Supply Chain Security? It Is All About How You Respond

The difference between software supply chain attacks and software supply chain vulnerabilities matters because it affects the timeline and response actions required from SecOps and incident response teams. There are no universal truths about how these attacks play out, but by looking at recent examples of attacks and vulnerabilities, we can identify some common traits that affect the timeline and prioritization of any response action.

Supply Chain Attack (SolarWinds SUNBURST)\: Actual supply chain attacks tend to be active for some period of time before they are discovered. That means affected organizations may already have experienced data theft or a ransomware event, and must focus on incident response and damage control. This often means that SecOps and incident response teams need to look into archived logs of past forensic data to try to identify where the attacker got in first, and where they went from there.

Understanding the scope of an attack enables IR teams to remediate compromised devices without going overboard and shutting down uncompromised parts of the network out of an abundance of caution. Teams that lack the necessary data to be able to look back in time and identify the point of initial compromise will struggle to eradicate the threat.

Supply Chain Vulnerability (Log4Shell)\: Vulnerabilities such as Log4Shell are often discovered and disclosed before ever being used by attackers in the wild. After a vulnerability is disclosed by a security researcher, it is common for a period of hours or days to pass before attackers develop code to actually exploit the vulnerability. In this case, defenders have a brief window of time during which they can patch their vulnerabilities and close the door to attackers. Teams that lack a current, complete inventory of their hardware and software assets, and lack the ability to identify vulnerable assets, will struggle to react quickly enough to prevent an attack.

How to Take Back The Advantage from Supply Chain Attackers

Accelerate Patching of Vulnerable Software

Historically, incident response and software patching have been quite different activities in terms of the timeline and sense of urgency. The increasing speed, sophistication, and impact of cyberattacks has started to blur this line. Because of this, accelerated software patching in response to disclosure of a widespread vulnerability is becoming necessary. The U.S. federal government has even issued a binding directive that federal agencies must patch new vulnerabilities that reach a certain risk threshold within two weeks of their disclosure

By contrast, the IBM Cost of a Data Breach report 2021 indicated that organizations take an average of 286 days to discover and remediate breaches caused by vulnerabilities in third party software. This mismatch in timelines offers a huge opportunity for attackers, and a yet unsolved challenge for defenders.

Maintain a Complete IT Asset Inventory

Asset inventory is a basic security hygiene measure. It is the first item in the CIS Top 18 critical security controls and is specifically recommended in CISA's guidance on Defending Against Software Supply Chain Attacks. And the strategic value of a complete asset inventory is going up.

When Log4Shell was disclosed, tens of thousands of organizations worldwide went into incident response mode. The first thing they needed to do was identify which applications and devices in their environment had vulnerable versions of Log4j installed. Those that could locate and patch these vulnerable versions quickly enough might avoid attacks entirely. This is a case study in why IT asset inventory is so important for security.

Use AI/ML Driven Behavioral Detection and Response

Once you have preventive measures in place, you need to consider your detection and response capabilities against attackers that still get in.

All the victims of the SUNBURST, REvil, and Log4j attacks doubtless had some kind of preventive measure in place, and the attacker still got in by exploiting the privileged access enjoyed by some software and service providers.

CISA recommends that organizations understand the baseline behavior of software and users in their environment, and "use machine learning or artificial intelligence to identify anomalies and deny abnormal information flows."

Because software supply chain attacks get in through trusted channels, and compromise application servers that are likely already allowed to communicate outside the network to receive updates, they have a perfect smokescreen to hide behind. Only high-fidelity behavioral detection capabilities will detect malicious changes in the behavior of these entities.

To Stop Active Supply Chain Attackers, Look Inside Your Network

Once a supply chain attacker gets inside your environment, they are likely to try to expand their access by scanning to enumerate more targets, and moving laterally to access more devices. No matter how they got in, these behaviors are visible on the network if you know where to look.