Display Fixed version if available as a separate field on its own

[prabhushan]

Current Behavior

vulnerabilities are shown, but the fixed versions are usually hidden in the description of the fixes. Calling out could help the team or automate the remediation in the future

Proposed Behavior

Is there a way to display Fixed versions for vulnerabilities atleast for the ones for which fixes are available..

Checklist

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

[wadimj]

It would be great to have this, since the Trivy analyzer already provides the “Fixed Version” information, but it is currently being silently dropped in Dependency-Track.
In my other workflows, I rely on that field to produce compact reports for developers, including a list of affected packages and the minimum required version to address all findings.

[webdevred]

Hello @nscuro

I'd like to implement this. Here is what I found on main and what I would change, split by component.

What already works. The GHSA mirror (vuln-data-source/github module, ModelConverter) parses the advisory's affected version range, and the apiserver exposes it on GET /v1/vulnerability/source/{source}/vuln/{vulnId} as affectedComponents, each with its version bounds. So the affected range is already in the API response.

The gap. The frontend never renders it. In the frontend repo, src/views/portfolio/vulnerabilities/Vulnerability.vue fetches affectedComponents but does not display it. The "Affected Projects" tab only lists the user's own impacted projects, not the advisory's version ranges. So on a vulnerability page you cannot see which versions are affected or fixed.

I would like to make two separate changes:

1. Display the affected ranges (frontend repo, Vulnerability.vue).
Render affectedComponents on the vulnerability page: the affected version range per package, with the versionEndExcluding bound shown as the fixed version. This alone resolves the original request and needs no backend change.

2. Capture GHSA firstPatchedVersion (dependency-track repo).
Today ModelConverter in the vuln-data-source/github module never reads the advisory's firstPatchedVersion, so Vulnerability.patchedVersions stays empty for GHSA advisories (Trivy already sets it). I would read it there, carry it through the CycloneDX Bill of Vulnerabilities (BOV) that the module emits, and map it in the apiserver so patchedVersions is populated for GHSA. That gives a concrete fixed version instead of one only implied by the range bound.

Change 2 is motivated by downstream use: we export findings to DefectDojo via the Finding Packaging Format, and we want the fixed version to travel with the exported finding, which means it has to exist as a real field rather than be inferred from the range.

Questions before I start:

1. Are you open to both changes, or only the frontend display?
2. For change 2, how should the fixed version be represented in the BOV: as an unaffected version range, or another way you would prefer?
3. For the frontend, where should the affected and fixed versions live on the vulnerability page: a new section, or a table near the existing content?

Best regards,
webdevred

[nscuro]

In general this would be good to address. Bit of feedback:

Today ModelConverter in the vuln-data-source/github module never reads the advisory's firstPatchedVersion, so Vulnerability.patchedVersions stays empty for GHSA advisories (Trivy already sets it).

There is a semantic difference here that's worth unwrapping. GitHub provides version ranges, which means firstPatchedVersion should always be inferrable from those ranges (as you noted yourself). It should thus not be necessary to drag firstPatchedVersion along.

Trivy only gives us a "vulnerable" / "not vulnerable" verdict for components we send to it. It doesn't report ranges. Here it somewhat makes sense to populate patchedVersions because the information can't be inferred.

The frontend never renders it. In the frontend repo, src/views/portfolio/vulnerabilities/Vulnerability.vue fetches affectedComponents but does not display it. The "Affected Projects" tab only lists the user's own impacted projects, not the advisory's version ranges.

The data is rendered in the modal that opens when you click View Details, in the Affected Components tab.

Render affectedComponents on the vulnerability page: the affected version range per package, with the versionEndExcluding bound shown as the fixed version.

Note that multiple sources can report version ranges for the same vuln, and a single vulnerability can affect multiple release trains of a component (e.g. >= 2.1.0 | < 2.3.0, >= 3.1.0 | < 3.3.0), so it's possible there are multiple fixed versions.

Also there can be ranges for multiple components, but the Vulnerability page doesn't have "context" about whether you're only interested in one of the components. So you'd need to render the fixed versions for all affected components, which can be many in some cases.

[webdevred]

Thanks @nscuro, that is helpful, and you are right on both counts.

I missed the View Details > Affected Components tab. VulnerabilityDetailsModal.vue does render the ranges (the affectedComponentLabel helper builds the >= / < string per component), so the data is already visible in the UI. My "the frontend never renders it" was wrong, apologies for the noise.

Agreed on firstPatchedVersion as well. For GHSA the fix is inferrable from the range, so there is no reason to carry a separate field. Trivy is the case where patchedVersions earns its place, since there is no range to infer from. I will drop that idea.

Your point about multiplicity is fair too: multiple release trains and multiple affected components mean there is no single "fixed version" to show, so a dedicated field on the vulnerability page would be misleading without component context. My wish was that I could easily get closest safe version to upgrade to but it is true that version is not the only version with the fix.

Given all that, the piece I actually care about is downstream rather than the UI. The affected ranges are in the API (affectedComponents) and in the modal, but they are not included in the Finding Packaging Format export that integrations consume. So a tool that ingests FPF (in our case DefectDojo) has no way to tell which version fixes a finding, even though Dependency-Track knows. Would you be open to including the affected version ranges per component in the FPF Finding export? Consumers could then derive the fixed version themselves, which also sidesteps the multiplicity problem, since they would get the full ranges rather than one guessed value.

If that is better tracked as its own issue instead of here on #5907, I am happy to open one.

Best regards,
webdevred