search

DependencyTrack / dependency-track

Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain.
https://dependencytrack.org/
Apache License 2.0
2.72k stars 580 forks source link

False positives for CVE-2018-8088 using OSS Index #302

Open msymons opened 5 years ago

msymons commented 5 years ago

Issue Type:

Current Behavior:

I am supplying CycloneDX BOM (cyclonedx-maven-plugin v1.3.1) to Dependency-Track Server v3.4.0. The server has Dependency-Check disabled and OSS Index enabled.

Noticing that I was getting hits against CVE-2018-8088 for purl such as the following (and these are just 2 of many):

pkg:maven/org.slf4j/slf4j-api@1.7.26?type=jar
pkg:maven/org.slf4j/log4j-over-slf4j@1.7.26?type=jar

...I double checked using the search function on the OSS Index website and then emailed them to report a false positive. They responded to confirm the presence of the false positive and implemented the necessary fixes, fixes that became visible by 20th March 2019. The purl listed above are now "vulnerability free" on OSS Index and their vulnerability listing for the CVE:

https://ossindex.sonatype.org/vuln/d33d3123-eac8-43d1-a5b1-4ebb82c88b77

...now links only to slf4j-ext modules

However, Dependency-Track is still listing the "problem purls" as being vulnerable, when they are not.

Is it possible that Dependency-Track is not cleaning up when false positives are fixed in OSS Index? ie, a previously known vunerability is removed from a component?

Steps to Reproduce (if defect):

See above.

What I have not tested is what Dependency-Track would report for a completely fresh install done after 20th March... If the problem is only with removing false positives then I would imagine that a fresh install would report no vulnerabilities for:

pkg:maven/org.slf4j/slf4j-api@1.7.26?type=jar
pkg:maven/org.slf4j/log4j-over-slf4j@1.7.26?type=jar

Expected Behavior:

When OSS Index fix a false positive then the change should be reflected in Dependency-Track.

Environment:

stevespringett commented 5 years ago

Dependency-Track will not account for false positives being removed from a vulnerability source (ODC, OSS Index, NPM, etc). If a vulnerability is assigned to a component in Dependency-Track there is not a mechanism in place to remove it. This is expected behavior. In this case, the component audit feature should be used to flag the vulnerability as a false positive, then suppress it. All projects that use that component will no longer see the vulnerability.

msymons commented 5 years ago

Could/Should there be a mechanism to clean-up vulnerability assignments when a false positive is removed from a vulnerability source?

In order to be efficient (workable), would it perhaps require REST API extensions on the source (eg OSS Index) so that it would be easier to query to establish what needs to be updated and then just update those components, rather than have to double-check everything?

Alternatively, for something lightweight, how about having a button on the component screen that would perform an on-demand check for that single purl?

update-vulnerability-report

(And perhaps the button would only be available when appropriate, eg using OSS Index).

This functionality might also help with false negatives as well as false positives.

Note the component in the screenshot.

pkg:maven/org.slf4j/slf4j-ext@1.7.25?type=jar

This component should be displaying CVE-2018-8088 as a threat (whereas slf4j-api andlog4j-over-slf4, from my original post, are displaying the threat and should not.

I had been using suppress via "Project Auditing" and, following your pointer above, tried "Component Auditing". This definitely does help. But it can be rather confusing. For instance, when browsing to a project, vulnerabilities that are suppressed at component level are not displayed here. What if the suppression had been incorrect? It might be only when looking at the usage of a component in a project that one realizes that something is incorrect.

eg, from "Best Practice":

Findings with an analysis state of NOT_AFFECTED or FALSE_POSITIVE should be suppressed

"NOT_AFFECTED" might be totally valid for 99 projects... and invalid for the 100th. Thus, one might want to tweak the component suppression at the project (individual dependency) level.

stevespringett commented 5 years ago

Could/Should there be a mechanism to clean-up vulnerability assignments when a false positive is removed from a vulnerability source?

No as there are audit decisions (project and global) to take into consideration as well as unknown actions taken as a result of a webhook response, ThreadFix, Kenna, or Fortify SSC analysis and defect tracker tickets created.

Alternatively, for something lightweight, how about having a button on the component screen that would perform an on-demand check for that single purl?

I like that idea. Go ahead and create an enhancement for it.