Generate a Dependency Vulnerability Analysis Report

You can configure a job to generate a Dependency Vulnerability Analysis (DVA) report for a Maven, Node.js/Javascript, or Gradle application. This report can help you analyze any publicly known vulnerabilities in the application's dependencies.

When a build runs, VB Studio scans the job's POM file (Maven), package.json file (Node.js/Javascript), or build.gradle file (Gradle) and checks the direct and transitive dependencies against the National Vulnerability Database (NVD). See https://nvd.nist.gov/ to find more about NVD.

Dependencies in Node.js and Javascript projects are also checked for vulnerabilities against the following sources:

• NPM: Data may be retrieved from the NPM Public Advisories, https://www.npmjs.com/advisories.
• RetireJS: Data may be retrieved from the RetireJS community, https://retire.js/github.io/retire.js/.
• Sonatype OSS Index: Data may be retrieved from the Sonatype OSS Index. https://sonatype.ossindex.org.

For any vulnerabilities found, you can configure the job to mark the build as failed or file an issue. If email notifications have been enabled or if a Slack webhook has been configured, you can be notified about these actions through email or Slack.

To configure a job to scan for security vulnerabilities:

1. Open the job’s configuration page.
2. Click the Before Build tab.
3. From Add Before Build Action, select Dependency Vulnerability Analyzer.

   After adding the Dependency Vulnerability Analyzer build action, make sure it's enabled. You can disable the DVA report generation by disabling the build action.

4. In Threshold at or above, select the score threshold.

   The scores capture the principal characteristics of a vulnerability and reflect its severity.

   Note:

   The threshold and confidence settings have different mappings and values, depending on the type of project (Node.js/Javascript, Maven, or Gradle). The Common Vulnerability Scoring System (CVSS) score is for vulnerabilities from the NVD database only. Vulnerabilities in Node.js and Javascript projects can come from sources (NPM, RetireJS, Sonatype OSS Index) in addition to those that come from NVD.

   For more information about how CVSS scores are calculated, see https://nvd.nist.gov/vuln-metrics/cvss.

   This table explains how the levels (Low, Medium, High) are defined for each vulnerability source. The Analyzer reports vulnerabilities when the value for the level you choose is met or exceeded.

   Source	Project	Low	Medium	High
   NVD	Maven, NodeJS, Gradle	Score range 0.0-3.9	Score range 4.0-6.9	Score range 7.0-10.0
   NPM	NodeJS	Low	Moderate	High or Critical
   RetireJS	NodeJS	Low	Medium	High or Critical
   Sonatype OSS Index	NodeJS	Score range 0.0-3.9	Score range 4.0-6.9	Score range 7.0-10.0

   For example, if you select Medium, any vulnerability with a CVSS score of 4.0 or above (and a Moderate NPM level, a Medium RetireJS level, or a Sonatype OSS Index score greater than 4.0 for a Node.js project) is detected and reported.

5. In CPE Confidence, select the confidence rating the DVA has for the identified Common Platform Enumeration (CPE).

   CPE is a structured naming scheme for describing and identifying classes of applications, operating systems, and hardware devices present among an enterprise's computing assets. To find more about CPE, see https://csrc.nist.gov/projects/security-content-automation-protocol/specifications/cpe/.

   The CPE Confidence rating helps you filter the Common Vulnerabilities and Exposure (CVE) identifiers based on the confidence level. CVE is a list of common identifiers for publicly known cybersecurity vulnerabilities. To find more about CVE, see https://cve.mitre.org/.

   For example, select Medium to filter out the low confidence CVE identifiers from the report.

   Note:

   CPE confidence levels are not supported for NPM, RetireJS, and Sonatype OSS Index sources. For these sources, the Analyzer reports all vulnerabilities, regardless of the level you choose.
6. To fail the build if a vulnerability is detected, select the Fail Build check box.
7. To automatically file an issue for every build file where a vulnerability is detected, select the Create issue for every affected build file check box.
   In Product and Component, select the issue's product and component.
8. Click the Steps tab.
9. Add a Unix Shell step (or appropriate step, such as a Maven step to build the POM file).
   For example, if you add a UNIX Shell step, enter the following command to build the pom.xml file in the app_dir directory in the job's Git repository:

   mvn -install -fae -f app_dir/pom.xml -X

10. Click Save.
11. Run a build of the job.
    To trigger the build manually, in the Job Details page, click Build Now.
12. After the build is complete and a vulnerability is detected, click Vulnerabilities to view the vulnerabilities report. If no vulnerabilities were detected, Vulnerabilities will be disabled.
13. On the Dependency Analyzer Summary page, review the affected files, dependencies, and detected vulnerabilities.
    Expand the Report section to view the files of your application where vulnerabilities are found (in the POM file, in this example):

    

After the DVA report is generated, expand each file in the Report section to view these details:

• Issue ID, if the Create issue for every affected file check box was selected. Click the issue link to open it.

  You can also open the Project Home page and check the recent activities feed about the issue's create notification. You should see a message that an issue was created, such as System created Defect 2: Vulnerabilities in -MavenJavaApp. If an issue was previously created for the vulnerability, a comment will be added to the issue and a message like System commented Defect 2: Vulnerabilities in - MavenJavaApp will be added to the activities feed.

• Merge request ID, if the Resolve button was clicked to resolve the vulnerabilities. Click the merge request link to open it.
• Number of vulnerabilities
• Name of each dependency where a vulnerability is found
• Each dependency's type (direct or transitive)

  A transitive dependency displays a Transitive label next to the name. A direct dependency displays no label.

• Number of alerts and alert categories of vulnerabilities (High, Medium, or Low)
• Expand each dependency to view its vulnerabilities

  To mute a vulnerability's alerts, expand the vulnerability in the Report section, and click Mute in Alerts. In the Mute Vulnerability dialog box, review the details, and click Mute. The muted vulnerability won't be reported during the next run and it will not cause the build to fail. It will simply be included in the report as a muted vulnerability that should be used only for reference or to be unmuted and dealt with at some future time.

  Muted vulnerabilities will only show up in a report for the latest build, not in reports for any previous builds.

To fix a reported vulnerability, use Resolve and the dropdown menu in the analysis tool to change the dependency's version to one that doesn't have the vulnerability.