Shift Left on Vulnerability Detection

by | Jul 24, 2020 | Community news | 0 comments

This article is written by one of our DevSecOps Academy community members Yahav Itzhak

Using open source packages is becoming more and more popular. Open source libraries are developed by the community for the community and many have already discovered the benefits of using them, including:

  1. Easy to use – Some of these libraries save you time writing code you’re not familiar with. For example, as an open source developer, I sometimes have to encrypt passwords with AES256 encryption. Obviously this is not something I would want to implement alone.
  2. Less bugs – In popular libraries, most of the lines of code are reviewed by many skilled programmers. This code may also be used by many other software developers that encounter and report flows.
  3. Security – Open source libraries can be more secure. In addition to the above, these libraries are scanned by many vulnerability databases such as NVD, VulnDB, WhiteSource and more.

Vulnerability Databases

According to Wikipedia, “A vulnerability database is a platform aimed at collecting, maintaining, and disseminating information about discovered computer security vulnerabilities.” 

Let’s take, for example, the US National vulnerability database (NVD). The NVD is getting updated on a daily basis. In fact, according to their statistics page, over 50 vulnerable components are scanned and processed every day. There are currently over 26,000 of high severity software components and more than 9,000 of critical components.

The Risk of Using Vulnerable Components

Hackers constantly find creative ways to exploit vulnerabilities. For example, let’s take a look at the high severity component CVE-2019-10742. This vulnerability affects the popular NodeJS Axios HTTP client in versions prior to the 0.18.0 version. Using it to download data may cause high CPU usage finalized by denial of service.

Vulnerability Scanning During CI Build

Using vulnerability scanning during the build process is a great approach to catch the vulnerabilities before the code is delivered. This ensures safer software with a minimum amount of functional and security issues.

For example, let’s take a look at a usual CI/CD pipeline:

The CI server:

  1. Builds and tests the software.
  2. Uploads the software binaries to a binary repository manager, such as JFrog Artifactory.
  3. Security binary analysis tools such as JFrog Xray, scans the binaries in the build. If a vulnerability is found in one of the vulnerability databases, it fails the build.

Builds and Vulnerability Scanning

Imagine the following scenario: John the developer writes code and commits it to GitHub.

In the best case scenario, a CI build is triggered for scanning and testing the build. The binary analysis tool (JFrog Xray) analyzes the code and reports that a vulnerable component is found. John gets the reports and needs to determine whether he can upgrade the component’s version or use another component. Precious development time spent.

Let’s examine the worst case scenario. Steve develops code for ATMs. Steve uses component A that uses component B that uses component C. (A->B->C). C is a vulnerable component. Due to lack of ability to build and download dependencies of project A, the binary analysis tool doesn’t know that C is contained in A. The ATM will contain a vulnerable component C, waiting for a hacker to steal all of the money inside.

IDEs and Vulnerability Scanning

Now, let’s examine a different approach. In addition to scanning their builds as part of their CI, which is to the right of the CI/CD pipeline, John and Steve are using a dependencies scanner extension inside their IDE, which is all the way left in the CI/CD pipeline.

Since all of the direct and transitive dependencies are already contained in the developers’ machine, the dependencies scanner plugin can build a dependencies tree with the information from the security binary analysis tool (JFrog Xray) about each component. The extension can show the transitive dependencies tree and mark direct dependencies as vulnerable if one of the transitive dependencies is vulnerable. This way the builds will never fail on vulnerabilities and the final version will be safe.

 

Extensions & Plugins in the Market

VS-Code Dependencies Scanner Extensions

JFrog Visual Studio Code Extension

  • Supports npm, Go, python and Maven.
  • Provides syntax highlighting in the json, go.mod, requirements.txt and pom.xml.
  • Displays the components licenses.

Snyk Visual Studio Code Extension

  • Supports npm and Ruby 

 VS-Code Dependencies Scanner Extensions

JFrog Idea plugin

  • Supports npm, Go, Maven and Gradle. Shows syntax highlighting in the package.json, go.mod, pom.xml and build.gradle.
  • Displays the components licenses.

Whitesource Advise 

  • Supports Maven

Visual Studio Dependencies Scanner Extensions

JFrog Visual Studio Extension

  • Supports Nuget.

Eclipse Dependencies Scanner Plugins

Components licenses screenshots:

About the Author

Yahav Itzhak is a developer at JFrog, part of the Ecosystem team developing free open source IDE and CI integrations. Linkedin profile: https://www.linkedin.com/in/yahavi