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.71k stars 579 forks source link

Component: Re-Check Vulnerabilities Button #305

Open msymons opened 5 years ago

msymons commented 5 years ago

Issue Type:

Current Behavior:

When Dependency-Track has ingested a vulnerability then it will associate the vulnerability against components.

On occasion that the vulnerability has a CPE change. This is illustrated by the change history section of 2018-8088 a change which has now been reflected in OSS Index.

Dependency-Track does not reflect these changes and cannot perform automated rechecking (for reasons explained in #302), meaning that some components are left with false positives and others with false negatives.

Expected Behavior:

Per linked issue, Dependency-Track should be enhanced by the addition of a button on the component screen that would perform an on-demand check for that single purl.

update-vulnerability-report

..and then update the component accordingly.

In the screenshot above, the false negative and positive respectively relate to:

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

As DT is based on REST API, the functionality should also be executable via the API (ie, not relying on UI).

I would also expect results to be part of the audit trail. DT currently has an audit trail for vulnerabilities... should there be one for components themselves?

Environment:

msymons commented 5 years ago

@stevespringett, since logging this enhancement I have spotted multiple false negatives in DT that all led back to OSS Index. I reported them to OSS Index and all have been fixed and, more importantly, have appeared in Dependency-Track. eg CVE-2018-1000180 for Bouncy Castle.

I went so crazy reporting issues via email that Sonatype created this repo to aid the reporting process: OSSIndex/vulns

I believe that the delay in such items showing up in DT might be more to do with #342 than anything else... and that issue is resolved in the upcoming v3.5.0 release (and looks great when tested in snapshots).

Therefore, I think that this enhancement should be dropped from p2 to p3.

stevespringett commented 5 years ago

Thank you for letting me know OSS Index has a new way of reporting data issues. I wasn't aware of it, but glad they came up with something, because email....

msymons commented 3 years ago

@stevespringett I would like to request that this enhancement be boosted in priority again!

Per the description, the original motivation for logging this request was #302, which focused on false positives. I find that false positives are still an utter bugbear of my life when it comes to Dependency-Track.

CVE-2021-22147 is an example of an Elasticsearch CVE that has correct version range info in GitHub advisories and in OSS Index data... but the latter was only corrected in mid-October to [7.11.0,7.14.0) to exclude older versions of Elasticsearch. Any NEW project in Dependency-Track now has no problem at all... but I was left with scores of false positives in projects (ie, "Attributed On" dates in September and early October).

It took over an hour of effort to suppress all the false positives. And that is just for a single vulnerability. Thus, the need for a mechanism to force Dependency-Track to update specific vulnerabilities (the button of the title).

302 explains that...

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.

On the one hand, there will be many DT deployments that have no integration with Threadfix or other systems. Thus, the choice on whether or not to clean up false positives should the users to take (the user with permissions, that is!). On the other, I would hope that a good integration would allow for error correction. Defect tracker tickets would be a perfect example.

melba-lopez commented 1 year ago

@msymons i believe this is already in place. I've seen the regular checking of the vuln sources and also there's a "reanalyze" button at the project level. should this be closed?

samholton commented 3 weeks ago

I have an example of Python idna==3.7 being flagged for PYSEC-2024-60 back on July 12, 2024. However, that impacts 3.6 and was fixed in 3.7. If I create a new BOM with 3.7 and upload it, it is not flagged. However, I cannot get it to clear from the current project that was Attributed on 7/12/2024. After clicking Reanalyze, it still remains.

Image