DependencyTrack only find vulnerability issue from OSS index analyzer not from NV

[clin4]

Current Behavior

I setup a dependency track server with (k8s) use helm in middle of 2022 (following the instruction from your git hub page) which installed the 4.5.0 version ( evryfs-oss/dependency-track, chart 1.4.1). I used to upload a sbom json file, which had 2000+ components and got 200+ vulnerability issues.

But recently the number of vulnerabilitites issues significiately reduced to 5. I tried other projects which get similar trend. I found all issues reported by "Sonatype OSS index" Analyzer. I cannot find any of issue from internal (NVD) any more. I had make sure internal anaylzer and the NVD mirror is on, I saw the log the DT was able to download the NVD CVE DB.

I also tried the 4.63(1.5.5, the latest chart), I got same behavior. I tried dependencytrack/bundled:lastest locally. Still same.

Do I miss anything. Because I am preparing a demo for my boss. I really need some help. Any advices are highly appriciated.

Steps to Reproduce

1. create a project in DT
2. upload the sbom json (from the zip) in components page
3. wait for the analyze done
4. check the vuln issue number and which analyzer found it populated.zip

Expected Behavior

expect to see more vuln issues (expected 200+) found by DT, and "OSS index analyzer" should not be the only finder.

Dependency-Track Version

4.6.x

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

No response

Browser

Google Chrome

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this defect was already reported

[zhenik]

@clin4 It might be coupled with migration of NVD to api version 2 and deprecating version 1

Here are references:

• https://nvd.nist.gov/general/news/change-timeline
• https://nvd.nist.gov/general/news/api-20-announcements

[clin4]

@clin4 It might be coupled with migration of NVD to api version 2 and deprecating version 1

Here are references:

• https://nvd.nist.gov/general/news/change-timeline
• https://nvd.nist.gov/general/news/api-20-announcements

It is possible but I guess unlikely. since from the log, I can see the DT spend almost half hours and downloaded all CVEs from NVD for 2023 to 2022. Also from the announced timeline, it should still work before March 2023 at least.

I paste a log I got from the latest release 4.7.1. After the NVDCVEs downloaded I saw the following errors: (I attached the full log, 1.log) ERROR [IndexManager] The index component seems to be corrupted org.apache.lucene.store.LockObtainFailedException: Lock held by this virtual machine: /data/index/component/write.lock at org.apache.lucene.store.NativeFSLockFactory.obtainFSLock(NativeFSLockFactory.java:139) at org.apache.lucene.store.FSLockFactory.obtainLock(FSLockFactory.java:41) at org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45) at org.apache.lucene.index.CheckIndex.(CheckIndex.java:425) at org.dependencytrack.search.IndexManager.isIndexHealthy(IndexManager.java:444) at org.dependencytrack.search.IndexManager.lambda$checkIndexesConsistency$1(IndexManager.java:482) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Unknown Source) at java.base/java.util.stream.ReferencePipeline$Head.forEach(Unknown Source) at org.depen

dencytrack.search.IndexManager.checkIndexesConsistency(IndexManager.java:479) at org.dependencytrack.tasks.IndexTask.inform(IndexTask.java:51) at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:101) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

[syalioune]

Hello @clin4

Which tool did you use to generate the attached SBOM ? There are indeed 1279 unique CPE (see attached file 2461-cpe.txt) but none of them match the official CPE dictionary which you can find here. It looks more like purls translated to cpe

The stacktrace that you shared would not prevent vulnerability detection (see #2379)

[straimtheone]

Greetings @syalioune and thank you for helping us with this issue. The SBOM CycloneDX was generated mainly with Syft and enriched with several tools, the simplest way to reproduce it is to clone the react-native repo (https://github.com/facebook/react-native), download the latest Syft binary (https://github.com/anchore/syft/releases/tag/v0.73.0), and run "./syft react-native/ -o cyclone-dx > results/syft.json".

Is it possible that the CPE that comes from Syft is all wrong?

[syalioune]

I generated a SBOM with syft as instructed (see attached file syft-sbom-react-native.txt) and it contains 1301 CPE among which only those below are legit CPE from the official NVD dictionary. There are no vuln associated to them in NVD.

cpe:2.3:a:ajv:ajv:6.12.6:*:*:*:*:*:*:*
cpe:2.3:a:boost:boost:1.76.0:*:*:*:*:*:*:*
cpe:2.3:a:fmt:fmt:6.2.1:*:*:*:*:*:*:*
cpe:2.3:a:lodash:lodash:4.17.21:*:*:*:*:*:*:*
cpe:2.3:a:ruby-lang:rexml:3.2.5:*:*:*:*:*:*:*

Regarding syft, you can look at my comments from a previous analysis here https://github.com/DependencyTrack/dependency-track/issues/1871 Essentially the CPE are generated on a best guess basis. Can't blame them, CPE are a mess to begin with

[mauk1us]

Some details on my issue that I think is related to this. On v4.7.1 it seems download fails for NVD dbs from 2020 to 2011 but downloads the rest until 2002, so alot of vulnerabilities are not mirrored cause of this. On the same environment on a v4.7.0 install, the same NVD dbs are getting downloaded with no problems. I had the same issue as the initial post, a project with around 60 vulnerabilities on v4.7.0 has now only 5 on v4.7.1 and they are all OSS .

[lme-nca]

This is still the case on the latest 4.9.0 release, I uploaded dependencytracks own SBOM (https://github.com/DependencyTrack/dependency-track/releases/download/4.9.0/bom.json) with and without the sonar scanner active:

Without the sonar scanner active not a single vulnerability is detected....

[nscuro]

@lme-nca You'll notice that DT's SBOM does not contain CPEs, which are required for vulnerability analysis against the NVD. The NVD does not support package URL, and converting between PURL and CPE is unreliable at best, hence why DT doesn't do it. Enabling GitHub Advisories or OSV can be done if depending on OSS Index is not desireable.

[lme-nca]

@nscuro thanks for the quick reply, i guess that might actually explain this whole issue then.

I noticed this issue after analyzing some other issues on our PROD dependencytrack (for mostly Java project) I then replicated this on the new 4.9.0 test instance, with the above dependencytrack sbom and indeed I do not have the "Enable fuzzy CPE matching" activated so i guess this is just expected behaviour.