Lessons on How to Harden Software Supply Chains from Recent Attacks

Lessons on How to Harden Software Supply Chains from Recent Attacks

As part of Solutions Review’s Premium Content Series—a collection of contributed columns written by industry experts in maturing software categories—Mackenzie Jackson, the Developer Advocate at GitGuardian, shares some insights into security issues facing software supply chains and how to respond to them.

Supply chain attacks have been increasing dramatically, and the simple truth is that no one is immune from them. The distributed architecture we use to build applications gives attackers the perfect opportunity to be able to target hundreds, even thousands of organizations at the same time. While it is impossible to be without the risk of being a victim in a supply chain attack, we can implement some best practices to reduce the risk of both being a victim and potential damage caused during an attack.

The scary part about supply chain attacks is that often, the victims are powerless because vulnerability can be out of their control. This article will focus on understanding supply chain attacks and identify how we can harden our supply chain to limit damage from such an attack.

Examples of Attacks on Software Supply Chains


Recently, we have seen a consistent and drastic increase in Softlet’s Supply Chain Attacks, particularly over the past three years. This is a type of attack where advisories target a trusted piece of software or hardware that an application relies on. Large-scale supply chain attacks, such as what we are currently experiencing with Log4Shell or SolarWinds before that, can send the entire internet into a spin.

Software Supply chain attacks can happen in several different ways. We will examine three types of attacks and use recent examples to explain them.

Attack Through a Trusted System with Privileged Access

First, let’s look at an attack through a trusted system with privileged access. For this, we will use the SolarWinds breach.

This attack targeted a piece of software called SolarWinds Orion, which is used to monitor networks and had privileged access to these Networks. A component of the Orion software, its FTP update server, was vulnerable to attackers. They could exploit this component and infect the Orion software by injecting code through the FTP update server; this became known as the Sunburst attack. The malicious application gave attackers access to private networks of many high-profile customers, including Homeland Security, State Commerce and Treasury, and Microsoft, to name a few.

Attack Through Software Deployment and Testing Tools

Second, we can look at an attack through software deployment and testing tools. For example, we will look at the Codecov breach. Codecov, a device with tens of thousands of users, is used to determine how mature the testing procedures of an application are. This software had access to sensitive information, namely secrets (or credentials) needed to compile and test the application.

In this case, attackers could inject malicious code into Codecov because of a leaked credential found in a docker image. This malicious segment of code took all the secrets being used by CodeCovs users during the testing process and sent them to the attacker. Most importantly, this included access keys to users’ private git repositories, which are high-value targets.

Attack Through Software Dependencies

Lastly, we can look at an attack through software dependencies. For this, we will look at the recent Log4Shell event.

All software uses some open-source components. A study by Synopsys shows that 91% of modern applications are open-source components. Log4Shell, a zero-day disclosed no longer than a few days ago at the time of writing, is a striking example of how even the most well-established OS dependency can end up opening a wide breach into millions of devices. Log4Shell is an open-source logging component that is used by games, enterprise software, and data centers, to name a few. Log4Shell is so widely used that even if an application doesn’t directly rely on this, tools and other components that it uses often will, meaning there is a high chance you will still have some exposure to the attack.

Lessons From These Examples

By looking at these attacks and others, we can take away lessons about securing our Software Supply Chains.

Only use trusted dependencies within your application

When choosing what dependencies and modules to use within your application, you must make sure you are using software that:

  • Are well maintained with a continued track record of updates; this ensures that any vulnerabilities discovered will be researched and patches updated.
  • Are not misspelled! A type of attack called type-squatting is where malicious actors misspell a prevalent open-source dependency.

Scan open-source software for known vulnerabilities

Open-Source Scanning or OSS software is fundamental in hardening Software Supply Chains. This software will search through the dependencies your package uses and compare them to extensive databases of vulnerable packages and versions to see if your application has any known vulnerabilities.

Patching intelligently (regularly, not instantly)

Even when using very well monitored open-source components trusted by millions, you can’t be sure things won’t go wrong at some point. Most security professionals will tell you to Patch regularly. While this is true, always using the latest version is not always desirable, and we must be cautious about this approach. This may sound counterintuitive. But if we look at all the examples we have in this article, the one similarity they have is that had the users not updated immediately, they wouldn’t have been affected. This does not mean we shouldn’t patch regularly; it means we shouldn’t patch immediately unless there is a reason to do so.

Implement advanced authentication and principles of least privilege

There is a concept in security called Zero Trust. It means that just because someone has authentication credentials, we still don’t trust them. Examples include using multifactor authentication and limiting the IP addresses that can access systems. It is also essential to ensure we use the principle of least access—this means users and services only have minimum access to additional data and services.

Make sure your repositories are free from secrets.

It has become a classic playbook by attackers to target private code repositories. These are known to contain credentials attackers can use to authenticate themselves and move deeper into an organization. This is precisely the type of target an attacker will try and access with a supply chain attack. Implementing automated secret detection with products such as GitGuardian is critical to preventing lateral movement from an attacker and reducing potential damage. Also, no matter your size, start deploying a secrets management solution to avoid static tokens and implement secrets rotation.


Mackenzie Jackson
Latest posts by Mackenzie Jackson (see all)