Open source code is everywhere. Most software companies on planet earth use open source libraries and projects in their product, to help speed up development and save developers precious time. As you might expect, while using open source code truly speeds up your development cycle, it also makes you vulnerable to risks you inherit from those libraries, and their dependencies.

You can think of software supply chain vulnerabilities like infections in humans (pardon the COVID vibe): When you share food, cutlery or cups with other people, you are exposing yourself to infections these people may have gotten from other people they share food, cutlery or cups with. This makes you more likely to get sick. Similarly, when you’re using open source code, you are exposing your application to the vulnerabilities that may exist in these libraries, in their dependencies, and in their dependencies dependencies. This makes your application more likely to be at risk.

With the widespread use of open source code, the popularity of software supply chain attacks has grown. Huge attacks like Log4Shell (the Log4j exploit) and Sunburst (the SolarWinds exploit) struck hundreds of organizations around the globe, some even Fortune 500 ones.

The good news is, there are a few best practices you can implement to make sure your application is more resilient to supply chain risks.

 

What exactly is in your software supply chain

Your software supply chain is anything that is in your code or affects your code throughout your software development lifecycle, and in production. This includes:

  • Your own code
  • Your open source dependencies, and their dependencies
  • Elements that come with base images for your containers, AMIs or other machine images. These are elements we often don’t think about as part of our supply chain, but they are very much a part of what we deploy and run, and so anything bad in them is going to be bad for our application.
  • Finally (and often overlooked), all the third-party tools and technologies that you’re using during the deployment process. These tools don’t actually run in production, but are a part of your CI/CD process, which means they can influence the outputs of your deployment processes. For example, a malicious third-party component that is part of your build process can influence the output product, which then goes into your production environment.

 

More than just supply chain attacks

There are a number of risks to consider when it comes to your software supply chain. The first (and perhaps most obvious) risk to your application is supply chain attacks. Someone could insert something into your supply chain to attack your application. Supply chain attacks can compromise your data, your availability, and could even be a culprit for further attacks.

But it’s not only about huge, news-worthy supply chain attacks. Other and less talked about risks to using open source code include bugs, vandalism or even acts of protest in third-party libraries that can severely impact your application.

One example for an act of protest is an incident that happened earlier this year, where an open source coder intentionally sabotaged his repository in protest against failed attempts to monetize faker.js and color.js – two of the most popular NPM packages that are used by a large number of projects and packages.

Acts of protest, vandalism and bugs are all very real, and more common supply chain risks that could impact your application’s performance and security.

 

3 Things you can do today to protect your supply chain

Protecting your software supply chain requires you to consistently act on several fronts – from code scanning to runtime protection. There are, however, a few best practices you can implement immediately to improve your resilience to risks.

Visibility is everything

As always – visibility is king. It is really important to know and understand where your dependencies are in all the categories mentioned above. This will help you to make informed decisions on whether you are exposed to risks, and how you should act in order to mitigate them.

Prevent the known

The good news is that most supply chain attacks are known attacks. What this means is that all you need to do to lower your risks of getting hit by one is be aware of known vulnerabilities, and apply a tool to figure out whether your application is exposed to them or not.

The best way to do that is to use a tool that allows you to automatically detect vulnerabilities in your applications. The tool you use needs to actively look for vulnerabilities in applications both as they are deployed and in production. This will help you mitigate them before they become a problem.

Reconsider your supply chain and don’t automatically update

Yes, we all like to reuse code and not write something that someone else already wrote, which has definitely improved our products and sped up our development.

However, in light of the mentioned risks, it is worth considering if you are able to reduce your supply chain in areas where it is unnecessarily large. For example, you might be using open source libraries that are really just two lines of code, and are worth writing yourself.

If you are not up for shrinking your supply chain, consider locking down versions instead of automatically updating to the most recent version. Automatically updating to the latest version can make you more susceptible to acts of protest and vandalism.

To recap

Your software supply chain is everything and anything that affects your product, throughout its development and in production. To protect your application from inherited vulnerabilities, you need to have full visibility into your code and your dependencies, apply a tool that can detect known vulnerabilities in your development environment and in deployed applications, and lastly – try to revisit your supply chain to determine whether you can remove some of the open source libraries and write them yourself.