Author: Chase Snyder, Sr. PMM, Xage Security

When Solarwinds was hacked in 2020, the attackers did not just deploy ransomware on Solarwinds assets or DDOS their systems. The adversary inserted malware called “SUNBURST” that was propagated via Solarwinds software update pathways, so that thousands of Solarwinds customers were compromised as well.This event brought the risks of software supply chain attacks to the forefront of awareness for enterprises, and caused a rush of software supply chain risk management efforts to be undertaken. 

Nonetheless, years later, new software supply chain attacks continue to create major issues for enterprises worldwide. The first half of 2024 brought to light that a widely used Linux utility called XZUtils had been the subject of a long term effort to insert a backdoor that would affect millions of devices running Linux. The 2024 Verizon Data Breach Investigation Report (DBIR) noted a 68% year-over-year growth in breaches influenced by software supply chain interconnections. Clearly, the issue of software supply chain risk and software supply chain attacks is far from solved. 

This post will explore several key elements in a software supply chain risk management strategy. We will identify which aspects are most mature, and which areas still require further investment by enterprises wanting to secure themselves against software supply chain attacks.

Today, approaches to mitigating software supply chain risks can be separated into the broad category of preventing vulnerabilities, mitigating risks, and responding to incidents.

Preventing Potential Risks in the Software Supply Chain

Prevention techniques tend to fall under a few broad categories, including:

• Vulnerability Management and Patch Management: Checking for known vulnerabilities in software that is already deployed inside the enterprise, and patching those vulnerabilities according to priorities driven by their risk level, likelihood of exploitation and other factors.
• Third-Party Risk Assessments: Vetting third-party organizations that provide software to your enterprise to assure that they use secure-by-design practices and are not likely to introduce vulnerabilities into your environment.
• Software Composition Analysis (SCA) – A process for identifying the software components that are present in a given platform, for the purpose of avoiding potential risk introduced by open-source software packages or other low level components (such as the backdoored XZutils Linux component discussed earlier.)
• Secure Software Development Lifecycles (SDLC) – Software development practices intended to avoid writing insecure code or incorporating insecure open source components into either in-house developed software or solutions purchased from third parties.
• Software Bills of Materials (SBOM) – In addition to analyzing the components of any software you use, you can request an SBOM from your vendors. A 2021 White House Executive Order on Improving the Nation’s Cybersecurity laid out numerous requirements for the U.S. Federal Information Systems to publish, obtain, and use SBOMs in software they purchase or develop. The EO stated that “Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.” 

These techniques all focus on what can be done to limit the amount of risk you bring into your environment in the first place, and keeping an eye on potential sources of future risk within your technology stack.

Mitigating Risks from Third Party Connectivity

Approaches to mitigating risk tend to focus more on third-party connectivity. 

As noted in the CISA guide to Defending Against Software Supply Chain Attacks:

“Many third-party software products require privileged access; and second, many third-party software products require frequent communication between a vendor’s network and the vendor’s software product located on customer networks.”

The potent mixture of privileged access and frequent communication to an outside network makes third party software vendors an appealing target for attackers. For example, the Kaseya VSA attacks by the REvil Ransomware group in 2021 leveraged a vulnerability in a remote monitoring and management software, used by many managed service providers (MSPs), to compromise many organizations that used the software. 

It may not be possible, or desirable, to deny software vendors the privileged remote access they desire. In those cases, mitigating risks associated with this access will require internal controls to assure that the software can only access data and resources it needs to perform its function. This is where the notion of a zero trust architecture enters the picture. The notion of “least privilege access” is most often applied to humans accessing assets and accounts, but it is just as important to keep tight control of the access and privileges that third party software and machines have to other software and machines inside your environment. 

Both CISA and various executive orders from the U.S. Federal Government have emphasized the importance of a zero trust architecture as part of an overall risk management strategy. Next, we’ll discuss how zero trust policies specifically apply to mitigating risk from software supply chain attacks.

Zero Trust Architecture is the Missing Piece for Supply Chain Security

An under-emphasized aspect of supply chain risk management is the need to reduce the blast radius and minimize the damage when a supply chain attack actually affects your systems. No prevention measures are foolproof, and it has long been recognized that perimeter-only security is insufficient to prevent modern cyberattacks. Many enterprises have embraced the idea of a defense-in-depth strategy, but have not yet applied these controls to third-party software and vendor remote access pathways that exist in their environments. 

Whether a piece of software that you use is intentionally compromised by an attacker (as in Kaseya, XZUtils, or Solarwinds), or there’s simply an accidental vulnerability that starts being exploited in the wild, your assets are exposed. An attacker exploiting a flaw in the software in your environment can just as easily cause harm in either case. 

This is often not framed as an issue that falls within the software supply chain risk management category. Controlling access and limiting movement within your own network are typically the bailiwick of network segmentation, internal firewalls and network access control tools, and other solutions not typically considered part of the supply chain attack prevention equation. A mindset shift needs to occur among both software vendors and cybersecurity teams to acknowledge that any software you bring into your environment brings new risks with it that must be mitigated not at the perimeter, but from the inside.

CISA’s guidance for reducing harm once a supply chain attack has already occurred inside your network is to implement segmentation at the most granular level that can be achieved. They recommend several technical control that fall under the umbrella of zero trust:

• Identity- and object-based approaches to baselining normal behavior
• Machine learning or AI to identify anomalies and deny abnormal actions
• Network segmentation and zero-trust microsegmentation to limit an attacker’s ability to enumerate further targets and move laterally from one device or network segment to another.

Xage Delivers Zero Trust to Mitigate Software Supply Chain Risk

Whether a software supply chain attack starts with malicious code in a compromised open source software package, a managed service provider, or an enterprise remote access solution, they all end up in the same place: inside your enterprise, putting your critical assets at risk.

Xage Security provides many of the capabilities recommended by White House Executive Orders and CISA’s guide on the topic: Defending Against Software Supply Chain Attacks. 

To learn more, get our guide to the Five Must-Haves for Securing Remote Access.