Navigating Open-Source Dependency Security Issues

It was Saturday afternoon here in New Zealand, the weather was brilliant and my family and I were at the beach when Maria called me “CK, we got a problem, you need to check the server right now, there’s an outage”. So much for a chill Saturday…

As much as I like the team, I much prefer not hearing from them over the weekend. And that my friend, was the big lesson that I want to share with you today.

We all know how important it is to be on the lookout for random bugs, malicious attacks and other security vulnerabilities in our code.

But something that’s just as essential, but sometimes overlooked, is staying alert to these dangers in other’s code that we depend on (e.g., external libraries).

It can be problematic as we usually don’t have direct control of the code in our dependencies. Also, they can also be open-source – which brings with them their own realm of potential threats (like their own security vulnerabilities, bugs, public visibility, etc.). But, according to GitHub, “99% of the world’s software has at least some open-source code in its DNA”.

What’s more, is that a 2021 open-source security report in Help Net Security, uncovered that there’s been a whopping 650% increase of supply chain attacks targeting public repositories.

We as companies and global citizens depend on software to function. But as GitHub’s report revealed, our software depends on open source.

Take this as a friendly reminder of actions you can take to proactively protect your project that integrates open source.

Without knowing how to navigate open source dependency threats and issues, your project runs the risk of being greatly harmed by preventable problems.

Read on to find out about some recent open-source incidents and ways to prevent being badly harmed by these kinds of events!

Three Open Source Cybersecurity Events

1. Malicious attack in npm — “faker.js” and “colors.js

In January 2022, npm, a GitHub and software registry was targeted by an attacker that caused the code to fall into an infinite loop. With the libraries having such a widespread reach, it temporarily affected a huge amount of projects.

2. Vulnerability called Log4Shell

Ah.. the damned Log4Shell vulnerability… you’re probably sick of hearing about this one by now. But just in case you’re new to cybersecurity…

Apache Log4j 2 is a commonly-used Java Library for logging error messages. In November 2021, a security vulnerability called Log4Shell was detected – one that enables a malicious attacker to take control of a computer. The exploitation opportunities being discovered are rising exponentially. The consequence of the attack could be catastrophic for an application, as the attacker could remotely control any service that’s internet-connected and use particular versions of the Log4j library somewhere in the software.

This Log4Shell vulnerability is a big deal in cybersecurity due to Apache Log4j 2 usage throughout vast amounts of applications. For example, Twitter and big cloud services like Google, Microsoft, Apple, & CloudFlare.

Another concern is that the vulnerability cannot be fully ameliorated. The dangers will decrease through evolving technology and increasing protection – but due to the nature of the vulnerability it will somewhat remain and cybersecurity experts will be continually working to reduce the vulnerability.

3. Symfony Vulnerability

In 2021 it was discovered that Symfony, an open-source PHP framework commonly used in web applications, had a grave security vulnerability. This was specific to web cache poisoning attacks – which attack the storage points between web servers and client devices. They, therefore, carry the power to expose sensitive information (like a users’ IP address).

Symfony has been downloaded over 200 million times, and despite this, the mishandling of HTTP headers slipped through – meaning that the websites build on top of the symphony were vulnerable to these attacks.

What should you do to protect your project?

1. Do your research – prior!

Before you incorporate your dependencies into your project, make sure to research their weaknesses and history.

There’s nothing worse than integrating a bunch of dependencies into your project to find out later that they aren’t so great. Often the deeper you get into your project, the more heavily you rely on your dependencies and the harder it is to return and get alternatives.

You should also know their weak spots so you can stay alert to them.

Questions you could ask yourself:

  • Have they been related to any problems in the past?
  • What aspects don’t work so well and where are they vulnerable?
  • How widely established and used are they? Are they widespread enough that you can find out about incidents quickly and easily?

2. Stay Informed

Make the effort to check in with cyber security news and be up-to-date with news related to your dependencies.

Some of my favourite that are quick to inform you about incidents and upcoming threats:

3. Incorporate tools into your project to automatically monitor dependencies

It’s not enough to exclusively rely on outside news outlets for protection. Instead, use your intuition and build protection directly (and early) into your projects.

Example strategies and tools you can use for defence:

4. Be quick to react

It’s inevitable that bugs and security incidents will arise from your dependencies, especially if you are using open-source.

Make sure to react immediately (or as soon as you can). The longer you wait the higher the chance a serious incident occurs and it gets worse.

But, when this does happen, do not panic. It’s not your fault and to be expected. It’s simply a part of software collaboration and the wonderful world of open-source.

To sum up:

The recent events show us that even when open-source dependencies are ubiquitous and have a clean history, their safety cannot be ensured.

We cannot merely rely on our dependencies to be vigilant about security protection. Although some libraries appear very trustworthy, due to their past and popularity, the security cannot be fully guaranteed – especially for open source.

Instead, we must take our own precautions by researching, keeping up-to-date, making use of the myriad of tools and responding swiftly to incidents.

It’s now (and always will be) the time to ask yourself: What are you doing to protect your projects?