Securing Open Source Libraries

Chapter 2. Finding Vulnerable Packages

Now that you understand what a known vulnerability is, let’s start going through the four steps needed to address them: find, fix, prevent, and respond.

The first step in solving any problem is acknowledging you have one! And so, with vulnerable packages, your first act should be to look for vulnerable packages your application is consuming. This chapter discusses how to test your application, when and how you should run such a test, and the nuances in running the test and interpreting the results.

Taxonomy

Before you start testing, let’s first discuss what you should anticipate seeing in the results.

Known Vulnerability Versus Vulnerable Path

Consider an app that uses two packages, A and B, wherein A uses B (with the same version) as well, resulting in the following dependency tree:

App
 ├─┬ A@1.0.0
 │ └── B@1.0.0
 └── B@1.0.0

Now, let’s assume B@1.0.0 has a known denial-of-service (DoS) vulnerability. When testing the app, how many vulnerabilities should we report? On one hand, the app only has one known vulnerability: DoS in B@1.0.0. On the other hand, there are two instances of this vulnerability. What should we report: one or two?

The answer, unfortunately, is both, as each number is right in its own way. Different tools may count the two differently, but for the purpose of this book I’ll use the terms known vulnerability and vulnerable path to separate the two.

A known vulnerability represents a unique ID of a vulnerability in your tree ...