Why do the results from running Dependency Check look different than the report I received?

Question

I’ve run OWASP Dependency Check on my application and the results look different from the PDF report I received from the Software Assurance Team. How do I map findings between the two? Why are my results different from the findings in the PDF report?

Answer

The PDF reports provided by the Software Assurance Team are the definitive artifact for the Software Composition Analysis A&A activity. The PDF reports are based on the results of the Dependency Check scan, but are post-processed to organize the results in a manner similar to the Software Assurance Team’s Fortify code review validation reports.

The default Dependency Check report format is HTML. It contains a superset of the information contained in the PDF report. By default, the report only shows the dependencies with known vulnerabilities, however all dependencies detected by Dependency Check may be shown by selecting, “Showing Vulnerable Dependencies (click to show all)” in the “Summary” section.

In the default Dependency Check HTML report, click on the dependency name in the leftmost column in the “Summary” section and it will bring you to a detailed view of the dependency. Some information available in this section includes:

  • Information on where the dependency was found (see “File Path”), either the library itself or artifact that indicates the dependency is used
  • “Evidence” on how Dependency Check identified the dependency and its version
  • A list of CVEs or other known vulnerabilities associated with this dependency. Each vulnerability listed has a link to the associated CVE, severity information, and a summary of the issue.

The PDF reports contain a subset of this information, however it is organized by vulnerability instead of by dependency and the vulnerabilities are grouped by severity. So if a dependency has 5 known vulnerabilities reported against it, the dependency will only be listed once in the HTML report, but the PDF report from the Software Assurance Team will have 5 entries, one for each vulnerability.

Additional Information

Even with an understanding of how to read the Dependency Check output file, you may find your results are different from the report from the Software Assurance Team. The report from the Software Assurance Team contains the scan results that must be addressed for your ATO and the developer must resolve the issues reported there, as opposed to issues reported in scans developers may perform themselves.

There are many possible reasons for differences in the reports. Some examples include:

  • Unlike Fortify where rulepacks are updated quarterly, the known vulnerability databases used by Dependency Check are updated continuously. Each report generated by Dependency Check represents a snapshot in time.
  • The Software Assurance Team runs Dependency Check on the source code and dependencies delivered. If the developer has updated the dependencies or they are otherwise modified from the set delivered for review, the results will be different. You can select “Showing Vulnerable Dependencies (click to show all)” in the HTML report to show all dependencies to see if the dependency version has changed.
  • Dependency Check version differences. The Software Assurance Team strives to use the current release of Dependency Check. If you are not using the current version, results may differ.
  • Dependency Check command differences. The Software Assurance Team uses the Dependency Check as described in this technical note. The only exceptions are for applications that use the Yarn package manager or for applications that use Ruby. Additional command-line arguments are required for these cases as described in the Dependency-Check Documentation.
  • If Dependency Check reported any errors or warnings with the scan, those issues may result in a different set of findings. These issues must be addressed to get an accurate scan.

As stated above, to emphasize, the report from the Software Assurance Team is the definitive artifact for the Software Composition Analysis A&A activity that contains the specific findings that must be addressed for your ATO. Even if your scan results are different, the results from the Software Assurance Team must be addressed.

References