DT Vulnerability figures massively jumped overnight - Why

[nigellh]

Hi.

I imported a BOM into DT a couple of weeks back and it showed 488 vulnerabilities on the 31 Jan. A colleague of mine in a different area said he ran it into his system and he found more and wanted to know why.

I checked my DT and it is now showing 672.

So between the 31 Jan and the 1 Feb, the vulnerability numbers have jumped by almost 200.

Would really appreciate an explanation as this will kick of a storm as we had reported 488.

There were no changes on my system such as DT being updated so I am guessing it is the NVD feed. Do they do batch updates or something at a month end?

[nigellh]

A little further information. You can see from the combined screen shots that DT was picking up minor variations from the 18th Jan, but on the 31st Jan there was a big update.

Looking at the Attributed on field, it appears that 184 were picked up by DT, but some of these additional ones are dated back to 2016 so it is not as if something was added overnight to the NVD.

Any advice, gratefully received.

[nscuro]

Can you provide more information on your setup?

• Is fuzzy matching enabled for the internal analyzer?
• Is OSV enabled?
• Is OSS Index enabled?
• Is this happening for all components across the board or do they have something in common (e.g. all NPM components)?
• Are the newly reported findings accurate, or are they all false positives?

[nigellh]

Hi @nscuro thanks for getting back to me.

This is a very basic DT set-up. Just the curl command, minor change to change localhost to IP address and the docker-compose up. Create a user add me to Admin and that is it.

I then create a Project, import a CycloneDX SBOM and leave it to its 'stuff'

I am unsure how to check for the first 3 you have asked for, but happy to look. If they have defaults they will just be them.

This is the only project on this instance of DT so I have nothing to compare it with.

Not sure how to check if they are false positives, but happy to check that if needed. I guess we trusted DT not to show us false positives! The results on the two separate DT instances from same SBOM are identical, just that the second we do not have the history on.

---

Our 'use case' is probably not that standard as it is used to create a snapshot in time report of vulnerabilities rather than to monitor. Just happened in this case the data was there for me to show the changes since the initial import.

We create a CycloneDX SBOM based on an audit that we are doing of a product. This is then imported into DT to give us an initial idea of the problems in the code and the likely development practices they team are using to address (if at all) vulnerability issues and it is turned into a report.

Just happens that two of us used the SBOM in two different 'vanilla' DT setups, I did an extract of the data in the 31st showing 488 vulnerabilities and he did one on the 1st Feb showing 672. We just had to figure it out why.

[nscuro]

Dependency-Track relies on the data quality of third parties for the accuracy of vulnerability matching.

If the components in your project have a CPE (you should see this in the BOM you've imported), then DT will be able to match those against the vulnerabilities in the NVD directly. Matching CPEs is error-prone, so I'll not rule out the possibility that DT is at fault if there are unexpected matches coming up. If the components do not have a CPE, then this is not a possibility.

If the components in your project have a PURL (again, also visible in the BOM), then DT will check those with Sonatype's OSS Index service for vulnerabilities. It is possible that OSS Index added loads of new vulnerabilities to their dataset. That is not something we can control from the DT side.

In any case, I'd only consider this to be a problem if the new findings indeed are (primarily) false positives. Maybe check some of them manually so you can get a feeling for the situation. You can check the PURLs against OSS Index manually to see whether it's the culprit.

[nigellh]

Thanks, really useful.

We are hot on proper naming conventions for packages and I think that is what you mean by CPEs. So for all the technologies we aim to have the industry standard name. Isn't perfect, but where automatically generated it will be. Just that in the manual part of the analysis, some might be wrong.

Where Purls are in the SBOM, it is a requirement that they are valid. Most of the automatically identified packages will have these.

I understand that basically garbage in garbage out, but this is where the Data in DT did not change and suddenly, there are 184 additional vulnerabilities overnight.

So our data did not change and so something in or between DT and the NVD must have.

I will check some of the new ones as false positives, but I would be surprised. A little (lot) troubling.

[nscuro]

CPE is short for Common Platform Enumeration, and is one of the identifiers that can be used to check packages against known vulnerabilities. Refer to https://cyclonedx.org/use-cases/#known-vulnerabilities

It's currently the only identifier officially supported by the NVD.

[nigellh]

Thanks, then yes I beileve that we have this correct as DT is picking up the 10,000 packages from the product!

Just the dang 184 new ones overnight!

[nigellh]

Hi, I got the logs from the system and found something interesting, some of which you will know, but summarising it for anyone reading it.

DT does a series of things on a daily basis. This includes getting an update from the NVD Database as follows:

[0m 2023-01-30 11:34:28,294 INFO [NistMirrorTask] Starting NIST mirroring task
[0m 2023-01-30 11:34:28,295 INFO [NistMirrorTask] Downloading files at Mon Jan 30 11:34:28 UTC 2023
[0m 2023-01-30 11:34:28,675 INFO [NistMirrorTask] Initiating download of https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.json.gz
[0m 2023-01-30 11:34:28,871 INFO [NistMirrorTask] Downloading...
[0m 2023-01-30 11:34:29,257 INFO [NistMirrorTask] Uncompressing nvdcve-1.1-modified.json.gz
[0m 2023-01-30 11:34:29,317 INFO [NvdParser] Parsing nvdcve-1.1-modified.json

So this is the one from the 30th of Jan and on unpacking it this is just a JSON file.

It also daily update on the projects. So for mine it is:

[0m 2023-01-30 17:33:29,768 INFO [VulnerabilityAnalysisTask] Analyzing 10968 components in project: fc10eb01-91b1-41ec-9291-c24237ee15a1

As you can see this is 6 hours after the NVD update and these repeat for each day.

What is interesting is on the 31st, the NVD update is as follows:

[0m 2023-01-31 11:34:28,287 INFO [NistMirrorTask] Starting NIST mirroring task
[0m 2023-01-31 11:34:28,293 INFO [NistMirrorTask] Downloading files at Tue Jan 31 11:34:28 UTC 2023
[0m 2023-01-31 11:34:28,671 INFO [NistMirrorTask] Initiating download of https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.json.gz
[0m 2023-01-31 11:34:28,868 INFO [NistMirrorTask] Downloading...
[0m 2023-01-31 11:34:29,339 INFO [NistMirrorTask] Uncompressing nvdcve-1.1-modified.json.gz
[0m 2023-01-31 11:34:29,422 INFO [NvdParser] Parsing nvdcve-1.1-modified.json
[0m 2023-01-31 11:34:48,662 WARN [NvdParser] CWE CWE-1390 now found in Dependency-Track database. This could signify an issue with the NVD or with Dependency-Track not having advanced knowledge of this specific CWE identifier.
[0m 2023-01-31 11:35:02,117 INFO [NistMirrorTask] Initiating download of https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.meta
[0m 2023-01-31 11:35:02,422 INFO [NistMirrorTask] Downloading...
[0m 2023-01-31 11:35:02,424 INFO [NistMirrorTask] Initiating download of https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2023.json.gz
[0m 2023-01-31 11:35:02,615 INFO [NistMirrorTask] Downloading...
[0m 2023-01-31 11:35:02,804 INFO [NistMirrorTask] Uncompressing nvdcve-1.1-2023.json.gz
[0m 2023-01-31 11:35:02,829 INFO [NvdParser] Parsing nvdcve-1.1-2023.json
[0m 2023-01-31 11:35:11,484 INFO [NistMirrorTask] Initiating download of https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2023.meta
[0m 2023-01-31 11:35:11,581 INFO [NistMirrorTask] Downloading...
[0m 2023-01-31 11:35:11,583 INFO [NistMirrorTask] Initiating download of https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2022.json.gz
[0m 2023-01-31 11:35:11,774 INFO [NistMirrorTask] Downloading...
[0m 2023-01-31 11:35:12,467 INFO [NistMirrorTask] Uncompressing nvdcve-1.1-2022.json.gz
[0m 2023-01-31 11:35:13,275 INFO [NvdParser] Parsing nvdcve-1.1-2022.json
[0m 2023-01-31 11:36:27,557 INFO [VulnerabilityMetricsUpdateTask] Completed metrics update on vulnerability database in 02:49:240

So it appears to be doing (guesswork) a download of the full NVD results for 2022 and 2023.

It then does the project update again.

[0m 2023-01-31 17:33:29,911 INFO [VulnerabilityAnalysisTask] Analyzing 10968 components in project: fc10eb01-91b1-41ec-9291-c24237ee15a1`

I did my extraction of the data before this project refresh at 17.33 and so these additional archives are probably the cause of the additional Vulnerabilities showing on the 1st of Feb, but this raises additional questions.

1. Why were they not picked up on previous NVD refreshes by DT? The system has been running continuously since at least the 18th. (I had to rebuild it as I could not gain access, but it was 18th at the latest)
2. Is this the NVD releasing something in the modified download on the 30th/31st that made DT go after the others?
3. Why are these updates adding in vulnerabilities that are older than 2022/2023 that are picked up as ‘new’ vulnerabilities? Shouldn’t they have already been in DT? The additional vulnerabilities are dated from 2016 on.

Still looking for answers as at the moment it is raising a question mark on the validity of DT. :-(

[nscuro]

There is a defect that prevented the 2023 feeds from being downloaded unless DT was restarted: #2349. But given your description, you restarted the instance this year so that will not be the reason for the bump in vulnerabilities you saw on Feb 1st.

Regarding questions 2 and 3: NVD feeds are never "final", even the feeds dating back to 2002 may still change. You can read more about how NVD feeds work here: https://nvd.nist.gov/vuln/data-feeds. Dependency-Track will re-download feeds that have changed since it last downloaded them.

Additionally, it's not uncommon that CVEs published now have been registered for multiple years. You can see this here for example: https://nvd.nist.gov/vuln/full-listing/2023/1

There are multiple CVEs listed for Jan 2023 for which their identifier dates back to even 2010.

[nigellh]

Hi @nscuro Thank you. I might have restarted it earlier than the 18th, but it would probably not have been by much.

I think I have an answer I can 'sell'. Looks like the updates on the 31st just added in a load of additional CVEs that were not their previously.

You have been a real help!!!!

[nigellh]

Just realised, I restarted it on the 30th Jan to change the localhost to the IP address to allow remote access. That might explain this!

[msymons]

@nigellh I have logged #2449, requesting that DT provide tracking of "Vulnerability Catalogue" metrics. If implemented, some questions become easier to answer.

For instance, if you are tracking (say) 100 vulnerabilities with Sonatype IDs (eg sonatype-2022-1518) then you know that OSS Index is enabled AND you know that it is configured with your own authentication token.

[nigellh]

@nigellh I have logged #2449, requesting that DT provide tracking of "Vulnerability Catalogue" metrics. If implemented, some questions become easier to answer.

For instance, if you are tracking (say) 100 vulnerabilities with Sonatype IDs (eg sonatype-2022-1518) then you know that OSS Index is enabled AND you know that it is configured with your own authentication token.

@msymons Hi Mark. That is a great idea thank you. The issue that we had was a real surprise and effectively came down to a bug in DT, a coincidental restart that fixed it and me extracting the data in the time before DT picked up the change and got the additional data and then reflected that in the product. Effectively, if I'd restarted it 24 hours earlier or extracted 3 hours later, we would never have seen this. Made for 'fun' 😭