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.69k stars 578 forks source link

Dependency that has 1 vulnerability detected in one project and no vulnerability in another. #2863

Open khaledgithubwl opened 1 year ago

khaledgithubwl commented 1 year ago

Current Behavior

Hello, we are using Dependency Track 4.5.0, and we are facing an odd behavior. In one project, we find that the dependency lucenequeryparser 4.7.2 contains 1 vulnerability. and in another project, the same dependency ( with same version) / having the same purl .. doesn't show any vulnerability. We tried to reupload new boms, rescan the Boms.. but nothing has changed. Can you please tell what is happening on our side and how we can fix it ?

Thank you in advance.

Best Regards,

Steps to Reproduce

1.using lucenequeryparser 4.7.2 as a dependency

Expected Behavior

having the same number of vulnerabilities for the same exact component.

Dependency-Track Version

4.7.x

Dependency-Track Distribution

Executable WAR

Database Server

PostgreSQL

Database Server Version

No response

Browser

Google Chrome

Checklist

nscuro commented 1 year ago

What vulnerability is it specifically? Where both projects created around the same time, or is there some time in between?

It is possible that it was a false positive (e.g. in the database of OSS Index), that has since been resolved. Existing findings will not be removed, but such findings will not be raised for new projects anymore. That's just one possible scenario though.

khaledgithubwl commented 1 year ago

@nscuro Thank you for your quick response, this is the CVE : https://www.cvedetails.com/cve/CVE-2017-12629/ and as for the creation .. they were not created at the same time. Best Regards,

savek-cc commented 1 year ago

We see the same behaviour on DependencyTrack 4.8.0 - but even for complete projects (one has vulnerabilities in its components, the other project with identical BOM doesn't). A re-scan of the project does not fix the issue - downloading and re-uploading the BOM to the same project causes the vulnerabilities to be detected. One thing we observed is, that the project without listed vulnerabilities states "n/a" as last BOM upload date - which might be another issue altogether though.

msymons commented 1 year ago

WRT CVE-2017-12629 specifically

  1. I have 68 occurences in my projects
  2. Each project lists the CVE and the GHSA alias
  3. The identified analyzer is OSS Index
  4. GHSA lists the affected package as org.apache.solr:solr-core but the description mentions Lucene
  5. We do not use solr-core anywhere... the identified vulnerable component in DT is lucene-queryparser
  6. For what it's worth, 66 of the occurrences are as transitive dependencies of Elasticsearch, which is not affected by this vuln... so I now have 66 vulns to supress!

Anyway, @khaledgithubwl, if the analyzer that will report on the vulnerability is OSS Index, have you double-checked in your logs that OSS Index is working properly?

khaledgithubwl commented 1 year ago

hello @msymons what should I look for to see if OSS Index is working properly ? on my side, I don't see errors that is generated by OSS Index ..

Best Regards,