Detect and alert common vulnerabilities and exposures (CVE) in 3rd-party dependencies

2022-08-03 4 min read martin

Using 3rd-party libraries makes developer’s lives so much easier but can turn them into a nightmare when they are unmanaged and we don’t have a good understanding what is being used in a project or even a larger organization.

A few months ago we have seen quite a few popular frameworks widely used in many software products being hit by severe CVE (common vulnerabilities and exposures).

In the past developers have learned to practice test driven development to make sure every product increment delivers working software. They analyze their source code to detect common flaws, antipatterns, and security vulnerabilities, but often forget to include checking used libraries in the continuous integration cycle.

Complex software can include hundreds of external libraries (including those pulled in transitively) which are hard to track and check for various issues.

These issues may be that some library

is using a software license that is not acceptable
is affected by a severe CVE which imposes serious risks
is not well maintained or even abandoned by its developers
and many more …

So first we need awareness of the libraries that we use (including transitively included libraries). We need a bill of materials (widely referred to as BOM) that lists all libraries and their properties such as licensing model or known CVE.

The OWASP project has always been an excellent source of practices for avoiding and recognizing security issues and potential vulnerabilities. Also, it is a helpful source for tools for supporting developers.

We will be looking at the following OWASP projects:

Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain.

— https://owasp.org/www-project-dependency-track/

OWASP Dependency Track is an installable software offering a web API and web UI that is able to manage multiple projects, receive software bill of materials for a project and offers visualization of components (libraries) of a project. Also, it shows vulnerabilities, out-dated components, licenses and can alert on violation of these using configurable policies.

The software is very simple to set up. Follow along https://docs.dependencytrack.org/getting-started/distributions/ to run it in a container.

# Downloads the latest Docker Compose file
curl -LO https://dependencytrack.org/docker-compose.yml

# Starts the stack using Docker Compose
docker-compose up -d

Before we can start analyzing a project, it has to export its BOM which we can feed into to OWASP Dependency Track web API.

I’m a big fan of Gradle, so I will show how to set up a Java project that is built with Gradle and add the OWASP Cyclone DX Gradle Plugin. As done with earlier posts I’m using a project at GitHub that I created just for the sake of demoing various CI/CD and DevOps topics.

plugins {
  id "org.cyclonedx.bom" version "1.7.0"
}

After executing the plugin with ./gradlew cyclonedxBom the bill of material file build/reports/bom.json has been created. It contains the library metadata that we can feed into OWASP Dependency Track in the next step.

curl -vv -X "POST" "http://localhost:8081/api/v1/bom" \
    -H 'Content-Type: multipart/form-data' \
    -H "X-Api-Key: egmBk6wqlfi3yT7vh88RCbfgo89pveyT" \ (1)
    -F "autoCreate=true" \ (2)
    -F "projectName=continuousdelivery" \
    -F "projectVersion=0.1" \
    -F "bom=@build/reports/bom.json"

1	Get API key from dependencytrack’s web user interface (e.g. Team Administrators)
2	The API can create the project for us, so we don’t have to use the web UI.

With Dependency Track we can add policies for checking various properties of a library. I have chosen to check on an outdated version of a project library.

This triggers a policy violation since the project is using an outdated library version

This step included in a continuous integration pipeline and with an alert added to the notification system we can even get updates on policy violations on every single commit through various message sinks such as:

Slack
Email
MS Teams
Webhook
Console

When practicing DevOps and/or continuous-delivery it is essential that we automate all activities that make sure that we can deliver working software that has been scanned for known vulnerabilities. Members of a DevOps team must be notified about insecure or outdated libraries before the delivery phase in the DevOps cycle is hit.

With OWASP Dependency Track we get dependency scanning, alerting and a centralized bill of material service that produces transparency across projects within an organization.

I’m planning a follow-up post showing how to manage dependencies with Gradle so it is much easier to keep dependencies up to date and produce awareness of outdated and vulnerable dependencies.