Add support for CDX vulnerability references

[stevespringett]

Current Behavior:

Currently, each vulnerability is unique by its source and identifier. However, different sources have different identifiers for the same vulnerability. This leads to duplicate vulnerabilities, increased risk scores, and extra effort in auditing.

Proposed Behavior:

CycloneDX supports vulnerability references, which are aliases that describe the same vulnerability across multiple sources of vulnerability intelligence. Dependency-Track should adopt this model and be able to:

• present the vulnerability data in its de-duped form (with aliases that cross-reference).
• take aliases into consideration with performing risk scores
• provide aliases on all REST endpoints that provide vulnerability data (including Findings API)

[msymons]

I lot of users will be very pleased to see this enhancement implemented. I know that my main "customer" (in management) thinks that it is just what he needs to see done in order for him to authorise me to enable GHSA analyser on our production server.

A few questions/observations...

• How will alerts be handled? I am assuming that (say) NEW_VULNERABILITY will be linked to the CDX Vulnerability Reference, thus helping addressing one aspect of the current alert spam?
• Will "Attributed On" timestamps still be tracked for the individual sources of vulnerability intelligence? Once the aliasing is in place I think that this might allow the potential for the enterprising API user to pull data that could show (say) what percentage of the time different analysers were the first to identify a specific vulnerability.
• Taking aliases into consideration when performing risk scores will be fantastic. I have two Dependency-Track deployments with identical projects. One server has GHSA enabled and one does not. The GHSA one has a portfolio risk score that is 10,000 higher than the other. This enhancement will drop that delta by a large amount... and then the remaining difference should reflect the vulns that only GHSA intelligence is currently successfully identifying.
• But what will happen when different analysers give different severity scores? As of today, CVE-2022-25647 has a score of 7.7 on GHSA and the originating CNA (Snyk), but a score of 7.5 on NVD.
• Will internal vulnerabilities (introduced in v4.4.0) be "aliasable"? ie manually identify "CVE-XXX" and DT then creates alias to matching CDX vulnerability ID.
• How will auditing be handled in general?
• How will upgrade to DT implementing this enhancement handle existing audit decisions? Some existing vulns might be suppressed simply as a way to handle the duplication that this enhancement is intended to address. In such a situation, one would not want to have the new aliases accidentally suppressed.

[stevespringett]

Support for aliasing for GHSA is working upon mirroring of the data. The next step is to de-dupe and update scoring logic. Aliases are already provided in the REST API.

@msymons very good questions, many of which would be individual enhancements. This ticket does not mention alerts, attribution, differences in scoring, or auditing. Any of these would be individual enhancements after the aliasing system is in place and basic functionality is working.

As of now, OSS Index is out of scope due to multiple issues with their data. I have tried three different packages:

• pkg:maven/commons-io/[email protected]
• pkg:maven/com.orientechnologies/[email protected]
• pkg:npm/[email protected]

All three packages result in vulnerabilities where the data is untrustworthy. In some cases, the CVE is in the vulnerability description field, but not in the cve field. In other cases, the cve field is populated with a sonatype identifier. So the first three packages I've tried have CVEs, but none of them have the cve field populated correctly.

We will be excluding OSS Index support of aliases until such time their data issues are sorted.

[msymons]

There's one more wrinkle. As with some of the items above it might need to be catered for by later logging of a separate issue (enhancement) but I am mentioning it here so that at least there is an initial record...

Vulnerability Description often seems to be orders of magnitude better in one analyser than another. Compare CVE-2022-2191 (GHSA) with same in OSSI

Nearly 300 words in former. Just 34 in later (taken from NVD).

When support for CDX vulnerability references is implemented then we want to ensure that "good desciptions" do not get buried. In this example, the work-around provided via GHSA might be the exact piece of information that is critical to some users.

[nscuro]

Closing this issue as basic functionality has been shipped with 4.6.

I raised some issues for further improvements and introduced the vuln-aliases label to track them. I'll also throw some of @msymons' suggestions into more issues as well.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.