Open Source Security: How Safe are Your Dependencies?

Is the next Log4J or OpenSSL disaster lurking in one of your open source dependencies?

If you happened to miss out on those particular catastrophes, here’s a quick recap:

Log4J is a popular logging library used in many enterprise applications to populate server logs. The Log4Shell vulnerability that was recently discovered in the Log4J library “allows third-party servers to submit software code that can perform all kinds of actions on the targeted computer. This opens the door for nefarious activities such as stealing sensitive information, taking control of the targeted system, and slipping malicious content to other users communicating with the affected server.” Patches were quickly released to fix it, but not before malicious hackers conducted thousands of attempts to exploit it.

OpenSSL is a library commonly used to enable secure end-to-end TLS and SSL connections across the internet. The Heartbleed bug was another recent vulnerability that “allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software.” This compromises the secret keys used in the identification and encryption process so that hackers who exploit this bug can obtain access to sensitive information that would typically be protected by the SSL/TLS encryption.

Unfortunately, those are probably not going to be isolated incidences. We’ve spoken with a few open-source maintainers and, combined with the Census II of Free and Open Source Software – Applications Libraries report by the Linux Foundation’s Open Source Security Foundation (OpenSSF) and Harvard Business School, the picture is clear: Your dependencies may not be as safe as you might assume.

Let’s take a look at why that is, what’s been done in the past to mitigate these problems systemically, and what you should be doing to protect your projects.

The benefits and risks of FOSS

While we all know the most significant advantage of Free and Open Source Software (FOSS) is its distributed development approach, it also happens to be one of its most significant disadvantages. It’s great to have an army of volunteers and enthusiasts producing great libraries, but no centralized authority is responsible for ensuring that bugs are found and fixed.

Because of this lack of centralization, it can be challenging to figure out what projects need the most help and where the problems even lie. After all, because individual contributors maintain most FOSS projects, it may not be apparent if a given project is actively updated.

In the words of the Census II report, “Therefore, to ensure the future health and security of the FOSS ecosystem, it is critical to understand what FOSS is being used, and how well it is supported and maintained.”

Similarly, CoderPad Developer Advocate Corbin Crutchley – who himself is an active developer for FOSS projects like PlopJS – says:

“It can be a mess to see if a project is well maintained or not. I know of some major projects with millions of installs a month that only have one or two people actively contributing to them. It’s increasingly common for the few people working on major open-source (OSS) projects not to be paid, either, so there’s little incentive for them to spend their spare time working on a project.

This is known in the OSS community as ‘the bus factor problem’, – a ‘measurement of the risk resulting from information and capabilities not being shared among team members,’ i.e., what would happen to a project if the team got hit by a bus. It reminds me of the popular XKCD comic joking about a single person maintaining a dependency that a slew of larger projects relies on.”

This idea of a “bus factor” is a massive problem. If a FOSS maintainer decides to hand off (or even sell) their work to a bad actor, that’s game over for any project that relies on it. This is especially troubling since an estimated 98% of codebases include FOSS. The more people working with FOSS, the more likely bugs and other vulnerabilities will be found.

Clearly, the goal here is to increase dev participation in FOSS – but even if there’s increased participation, how do we know what security problems there are present in a codebase to begin with?

Current FOSS security solutions

This is not to say that the dev community has wholly ignored the FOSS security issue. There are currently some great tools and platforms that are working to close the vulnerability gaps:

1. Common Vulnerabilities and Exposures (CVE) is a system that the MITRE Corporation runs with funding from the US Government. It’s a list of “publicly disclosed computer security flaws” that helps inform security researchers of new security issues so that they can document them and inform the proper channels to get patched in OSS. Anyone can add to the list by submitting the issue here.
2. In 2019 Github introduced a feature called Dependabot, which monitors Github projects for dependencies that might have critical security flaws. 
3. Node Package Manager (NPM) also has the ‘npm audit’ command that “performs a moment-in-time security review of your project’s dependency tree” that identifies security vulnerabilities that may be present in your dependencies. 

While they’re a step in the right direction, these tools are not flawless. For example, the npm audit command has drawn its fair share of criticisms over the years.To quote Dan Abramov, one of the core members of the ReactJS team:

“The way npm audit works is broken. Its rollout as a default after every npm install was rushed, inconsiderate, and inadequate for the front-end tooling.”

He goes on to compare it to “The boy who cried wolf”in the sense that npm audit is prone to generating a significant amount of false positives, making it challenging to focus on the actual security issues.

Where developers should focus their efforts to improve open source security

This is where the Census II report comes in handy – by suggesting where our focus should be by ranking the most popular FOSS packages. The more popular a package, the more attention it should get to prevent catastrophic vulnerabilities from being exploited. 

The rankings are broken out in three ways:

1. Versioned vs. Version-Agnostic – i.e., “versioned” considers whether a particular version of a package is used more.
2. Direct dependencies vs. Direct AND Indirect Dependencies – Direct means the package was downloaded straight from the package manager; indirect is any dependencies that are included with a direct download.
3. NPM vs. Non-NPM packages – Node package manager (NPM) has become such a popular tool that the results were broken out between it and other popular package managers like maven and nuget.

You can find the top 5 results below:

What can you do?

Contribute and review FOSS! Obviously, you’re not going to dedicate your free time to fixing every FOSS out there, but you can focus on one of the top ones on the list or – better yet – find one on the list that you often use and find ways to improve it.

Moreover, you can help fund projects you depend on. With the advent of tools like GitHub Sponsors and Open Collective it’s easier than ever to find projects that require funding and financially support them.

The Census II report’s authors also cite the following focus areas:

• the need for a standardized naming schema for software components, 
• the complexities associated with package versions, 
• much of the most widely used FOSS is developed by only a handful of contributors, 
• the increasing importance of individual developer account security, and 
• the persistence of legacy software in the open source space”

There’s a lot of work ahead of the FOSS developer community. The report mentions how some governments have incentivized FOSS focus by creating “bug bounty programs, hackathons, and conferences.” They conclude their study with this:

“Given the distributed nature of FOSS, only through data sharing, coordination, and investment will the value of this critical component of the digital economy be preserved for generations to come.”

We can be grateful that groups like OpenSSF are helping to bring light to this global issue, but in the end we have to realize this is a team effort, and we must all do our part to ensure the FOSS we use is safe for ourselves, our companies, and our customers. 

For full rankings and methodology, check out the report here.

Happy coding!