Add Support for Identification of Aliases

[msymons]

Is your feature request related to a problem? Please describe.

With the introduction of suppport for vulnerability aliasing is Dependency Track, the plugin is now reporting a different metrics total than DT itself.

This has led to user confusion.

Describe the solution you'd like

The metrics in the plugin should match the metrics in DT. Ideally, the report in Jenkins should handle aliases so that things match up.

Additional context

I have not tested whether the plugin "risk gateway" is impacted by aliases. ie, if one could set threshold at (say) 2 x high severity vulns and fail the build when there is only one (but it has one or more an aliases). I will test... and then update this issue.

[msymons]

I have performed testing of the "risk gateway" and it seems to no longer be fit for purpose when connecting to a Dependency-Track server that has been configured with additional vulnerability sources that lead to vulnerability aliasing. In my case, the "extra" is GHSA... but adding Snyk as an analyser in DT would cause the same problem... and having both GHSA and Snyk would make things even worse. ie, there would be triplicates and not just duplicates.

Using the example from the description, a project with 18 actual high severity vulnerabilities, setting the threshold in the plugin to 19 "High Finding" will result in a build fail... having not accounted for aliases.

I think that the problem might be addressable using the /metrics endpoint. For the same project...

/api/v1/metrics/project/UUID/current

I get response body:

{
  "critical": 1,
  "high": 18,
  "medium": 22,
  "low": 6,
  "unassigned": 0,
  "vulnerabilities": 47,
  "vulnerableComponents": 19,
  "components": 358,
  "suppressed": 2,
  "findingsTotal": 47,
  "findingsAudited": 0,
  "findingsUnaudited": 47,
  "inheritedRiskScore": 172,
  "policyViolationsFail": 0,
  "policyViolationsWarn": 0,
  "policyViolationsInfo": 1,
  "policyViolationsTotal": 1,
  "policyViolationsAudited": 0,
  "policyViolationsUnaudited": 1,
  "policyViolationsSecurityTotal": 1,
  "policyViolationsSecurityAudited": 0,
  "policyViolationsSecurityUnaudited": 1,
  "policyViolationsLicenseTotal": 0,
  "policyViolationsLicenseAudited": 0,
  "policyViolationsLicenseUnaudited": 0,
  "policyViolationsOperationalTotal": 0,
  "policyViolationsOperationalAudited": 0,
  "policyViolationsOperationalUnaudited": 0,
  "firstOccurrence": 1681898444080,
  "lastOccurrence": 1683727278217
}

Ah ha! high = 18. Just what we want.

[msymons]

@sephiroth-j , thanks for adding this issue to a milestone. Have you yet got any idea of when plugin v5.0.0 might be released? Having a date (even if it is approximate) will allow my devs to decide whether to make use of the DT API or to wait for the v5.0.0 plugin release.

[sephiroth-j]

Hi @msymons , the release will probably not happen until the end of the year.

[sephiroth-j]

The next version will "support" aliases in such a way that they will simply be ignored. If there are two vulnerabilities v1 and v2 and v2 is an alias of v2, only v1 will be kept and v2 will be discarded. no duplicates -> correct numbers

[msymons]

The drawback in that approach is that I often see vulnerabilities with GHSA or Snyk IDs having a lot more information in the description when compared with the CVE that they alias.

eg compare GHSA-3gh6-v5v9-6v9j with CVE-2023-36479 in NVD

[sephiroth-j]

🤔
But keeping them would lead to the current higher an incorrect numbers on the results summary page. The bar at the top of the table shows the numbers of the findings from the table - if filtered by severity, the counter for the other severities is zero.

[msymons]

Is there nothing that can be used from metrics endpoint? At least as a fix for the "risk gateway" problem described in my comment of May 10th '23?

I have also discussed things with @nscuro since posting my previous comment today. We do need to do more on our side:

DT needs to support aliases better, it shouldn’t be the Jenkins plugin having to deal with this.

We do have open issues and welcome all feedback.

[sephiroth-j]

Of course, I could use the metrics API for the severity count. But then I get inconsistent numbers between the different charts and the previously mentioned table. Then I could also filter aliases there when I count the numbers for the bar at the top of the table, but when the table contains two vulnerabilities where one is an alias of the other, I want to display the correct result 2. So I prefer to have consistent numbers across all pages and charts, even if that means not showing alias-vulnerabilities.