How do projects manage security with so many dependencies in open source projects?

Question

Some node.js libraries (just as an example) can pull in literally hundreds of dependencies. Some of these dependencies are small packages that only have one contributor. Often times the contributor doesn't even have any personal information listed other than their username.

How is it possible to trust that nobody in those hundreds of libraries will never act maliciously, get their account hacked, have a change of heart, purposefully introduce a vulnerability, etc?

It seems that all it would take is one point in the chain to get compromised, or have never had good intentions from the beginning, and that could lead to huge security problems or data breaches. A compromised plugin in a build system could steal source code.

It just seems like the wild west and a disaster waiting to happen. Do companies really review the source code of every single package they use, and the changes on every single update? That just sounds unmaintainable.

I could understand trusting a paid library published by a business, but I don't understand projects using these deeply nested dependencies published by internet strangers.

I guess what my question is that I am having trust issues and don't know how to properly include a library without worrying that I could accidentally compromise a customer's business.

Answer 1

This is a reason why there are a number of tools to audit open source libraries in your dependencies. In fact if you search for "open source auditing tools" you will find a list of several companies with a product to help you do that. Many of them (like Sonatype Nexus Auditor) work with your build pipeline.

These tools do a good job alerting you if you are using open source software (OSS) with reported vulnerabilities or incompatible licenses. That doesn't help discover vulnerabilities if they are never reported.

When it comes to using any library (OSS or commercial), there are two types of risk you need to worry about:

• Legal Risk, i.e. violating licenses or using libraries that can't legally be used together
• Security vulnerabilities, i.e. problems in the library code that can be exploited by malicious users. Not all vulnerabilities are intentional.

There are a few ways to address the problem:

• If the license permits, fork the library and audit the code--puts the responsibility on you to audit future changes and to stay current. However, you will be most assured of the library's safety.
• Set up your own private package repository. Products like Sonatype Nexus, Artifactory JFrog, etc. let you host your own respositories for 3rd party libraries
  • Allows your group to control when new versions are available
  • Allows your group to skip known bad versions--or to remove known bad versions from the repository
  • Allows your group to monitor and restrict dependencies so you are working with mostly known and trusted code
• Set up an OSS Auditing solution. This will alert you to subtle problems like license incompatibilities, as well as known reported vulnerabilities.
• Add automated penetration testing with tools like Arachni scanner to actually test your site for known vulnerabilities.

The concept of DevSecOps which builds, deploys, and runs automated security and application tests with each check-in also helps provide confidence in your code. The bottom line is that every decision you make carries risk. The more you can do to prove the solution meets your security requirements in an automated fashion the better.