Enable OSV vulnerability source per default

[nscuro]

Current Behavior

We previously enabled the OSS Index analyzer per default, since it allowed for unauthenticated usage.

The other vulnerability source that is enabled per default is the NVD. It however does not provide PURL matching data and is thus not of great help during vulnerability analysis.

We need another, PURL-based alternative that can be enabled per default.

Proposed Behavior

Enable the OSV integration per default.

It provides PURL matching data, does not require authentication, and has broad ecosystem coverage.

Consider limiting the default to a small selection of popular ecosystems.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[wkoot]

Enabling by default seems like a terrible idea while the implementation is still in beta. It would however be convenient to configure the source via application.properties and environment variables for container-based deployments

[nscuro]

I have been pondering whether we should add an OSV analyzer instead, which uses the OSV API rather than mirroring the data, to bridge this gap.

For the following reasons:

• It would be usable immediately since it doesn't require any configuration or data downloads.
• The component version matching logic is offloaded to the OSV service.
• There is no need (or even possibility) to configure ecosystems. If OSV supports the PURL being sent, it will return vulnerabilities.

[wkoot]

That sounds like a better option, as starting a fresh instance of Dependency-Track can take days to fetch all OSV data.
In any case it would be nice to be able to configure this outside of the GUI, especially since changes POSTed don't seem to take effect (or, at least not within a short timespan)

[cachescrubber]

Please consider #5785 (Discussion) as it seems related to this issue. I enabled OSV on top of NVD (Datasource) + Internal (analyzer) + Sonatype Oss Index (analyzer) and get duplicate findings.

[lukas-braune]

I have been pondering whether we should add an OSV analyzer instead, which uses the OSV API rather than mirroring the data, to bridge this gap.

@nscuro It would be helpful to keep the existing mirroring option for DT instances that aren’t allowed to call external APIs with component information.

[nscuro]

@lukas-braune Yeah I agree. I have also since learned that some organizations curate their own OSV feeds and use the mirroring feature to get them into DT.

[xavier-calland]

I'm testing the use of OSV and I've noticed some limitations in its default usage.

https://github.com/DependencyTrack/dependency-track/blob/4.14.0/src/main/java/org/dependencytrack/tasks/scanners/InternalAnalysisTask.java#L104-L112

Currently, Dependency-Track prioritizes CPEs for range matching, which means the filter on the distributions provided with OSV is not applied.
This results in a large number of false positives, particularly for native Ubuntu packages whose affected.ranges information only includes an introduced = 0 (with no fixed or last_affected fields).

Did I miss something?
Will the behavior of range matching change?

[nscuro]

@xavier-calland While the code you linked looks suspicious, it only extracts the version to use for range comparison, which if you have both CPE and PURL in a component, should be identical between the two.

The relevant parts are here and here.

If both CPE and PURL are available, we analyze against both of them. CPE analysis works with NVD data. As noted in the changelog for v4.14.0:

[...] the NVD does not contextualize version ranges by OS release.

Here is a related comment in another thread: #1374 (comment)

The tl;dr is that components with CPEs are much more likely to get false positives.

We are very keen to get this gap resolved, but we need to achieve this without introducing a bunch of false negatives at the same time. i.e., just ignoring CPE or NVD data will likely not cut it.

[xavier-calland]

@nscuro Thanks for your reply. I should have included more code snippets in my previous message.

If both CPE and PURL are available, we analyze against both of them

Are you sure?

As I understand the code, analyzeVersionRange is called with both parsedCpe and parsedPurl here.
But only one of parsedCpe and parsedPurl is not null here.
When a component has a CPE, parsedPurl is null and analyzePurlVersionRange is not called in analyzeVersionRange here.

Am I right? Or have I misunderstood something?

We are very keen to get this gap resolved, but we need to achieve this without introducing a bunch of false negatives at the same time. i.e., just ignoring CPE or NVD data will likely not cut it.

I completely agree.
Let me know if I can be of any help.

[nscuro]

When a component has a CPE, parsedPurl is null and analyzePurlVersionRange is not called in analyzeVersionRange here.

Aha! No you're totally correct, that is a defect for sure. Parsing the PURL should not happen in an else if block. Preparing a fix.