/may 23, 2016

Fixing Vulnerabilities with Safe Versions

By Asankhaya Sharma

Last week Vanessa gave a presentation about the security risks associated with using open source libraries at the Null Singapore Meetup.

There was a great discussion afterward talking through different approaches people had for mitigating these risks. Unfortunately, it's a bit more complicated than just updating your project dependencies.

Safe Versions

When a vulnerability is disclosed, maintainers often recommend users upgrade to a "fix" version of a library.

This approach is often incomplete because:

  • The "fix" version of the library may have other vulnerabilities.
  • A "fix" version of the library may not be available soon enough.
  • The vulnerable library may be a transitive dependency, making it more difficult to update.
  • The "fix version includes changes that are incompatible with your project.

To help make upgrading dependencies easier, The SourceClear Registry uses the notion of "Safe Versions", which are not affected by any known vulnerabilities and are computed automatically by our platform.

As an example, here's a library with 30 released versions:

All versions of the library

This library has 4 different vulnerabilities associated with it:

  1. Vulnerability A affects version range v2-v4 and v7-v10
  2. Vulnerability B affects version range v23-v26
  3. Vulnerability C affects version range v13-v19
  4. Vulnerability D affects version range v30

Since multiple vulnerabilities associated with a library can have different overlapping ranges we need to take into account all the vulnerabilities associated with a library in order to compute the Safe Versions.

Safe Versions of a library

First we mark the vulnerable versions of the library.

All vulnerable versions of library are marked

We don't want to downgrade a library, so we ignore the versions before the earliest vulnerable version and mark all other versions as Safe.

Safe versions of library

With this computed table we can determine the Safe Versions for each vulnerability of the library:

  1. Vulnerability A safe versions are v11-v12, v20-v22 and v27-v29
  2. Vulnerability B safe versions are v27-v29
  3. Vulnerability C safe versions are v20-v22, v27-v29
  4. Vulnerability D has no safe versions

Since vulnerability D effects all versions of the library including v30, there are no Safe Versions of this library. If a fix is released in v31 and it passes the SourceClear scan, it will be marked as the Safe Version in our Registry.

Safe Version information is displayed on the library page for every vulnerability in our Registry. For example: CVE 2015-1427:

Save versions for CVE 2015-1427

Safe Versions for projects

Upgrading a single dependency can be hard enough, but determining which Safe Version to use in a project is made more complicated with transitive dependencies. When SourceClear scans your project, we build the full transitive dependency graph and have accurate information about how a particular library is being used and whether it was included directly, transitively, or both. We use this precise dependency information to pick the best Safe Version of the library for your project:

Safe versions for a project

We think Safe Versions provide the best way to communicate vulnerability remediation information. Check out the Safe Versions of a particular library or vulnerability by searching the SourceClear Registry. You can scan your projects for free with SourceClear Open and get accurate vulnerability information based on Safe Versions.

Related Posts

By Asankhaya Sharma

Dr. Asankhaya Sharma is the Director of Software Engineering at Veracode. Asankhaya is a cyber security expert and technology leader with over a decade of experience in creating security products for industry, academia and open-source community. He is passionate about building high performing teams and taking innovative products to market. He is also an Adjunct Professor at the Singapore Institute of Technology.