Read a fixed/patched version from the Dependency-Track FPF and set it as Finding mitigation

[webdevred]

Is your feature request related to a problem? Please describe

The Dependency-Track parser (dojo/tools/dependency_track/parser.py) reads the component and vulnerability fields from the Finding Packaging Format (FPF), but it never reads a fixed or patched version. When an advisory has a known fix, that value does not reach the imported finding: the mitigation says nothing about which version resolves the vulnerability, so a user has to open the advisory and look it up by hand.

Describe the solution you'd like

I have been using DefectDojo together with DependencyTrack for some months now and I wished that the fixed version to appeared in the finding's mitigation, so I can see which release resolves the vulnerability without leaving DefectDojo.

Related to: DependencyTrack/dependency-track#5907 and DependencyTrack/dependency-track#1410

Concretely, in dojo/tools/dependency_track/parser.py: inside the loop that builds each finding, after the existing component and vulnerability extraction, read the fixed version from the FPF and set it on Finding.mitigation (for example "Fixed in 1.2.3") before the Finding is constructed. This reuses the existing mitigation field and adds no new model or Finding field, so it stays within the contributing scope.

There is a dependency worth stating up front: the FPF does not carry a fixed version today. Emitting it is a separate change on the Dependency-Track side. Nothing is committed there yet, so this issue is here to agree on direction first, in line with the guidance to open an issue before a PR.

Describe alternatives you've considered

• Do nothing and rely on the Dependency-Track UI to show the fixed version. That keeps it out of DefectDojo, which is where our triage actually happens.
• Put the full affected version range in mitigation instead of the single fixed version. Less actionable, since the useful part is the concrete "upgrade to" target.
• Add a dedicated structured field on the Finding for the fixed version. Ruled out on purpose, since the contributing guide says a new model or Finding field will not be approved.

Additional context

Two things I would like to settle here so the two projects line up:

1. Is a fixed version in the Dependency-Track parser something you would accept, mapped to Finding.mitigation as described above?
2. What should the field be named in the FPF payload? I will match that name on the Dependency-Track side, and Dependency-Track would bump FPF_VERSION when it adds the field.

If there is interest, I will open the PR here once the field name is agreed and Dependency-Track is emitting it.

[webdevred]

Update on direction, this issue is partly outdated now.

After maintainer feedback on DependencyTrack/dependency-track#5907, the Dependency-Track side is no longer going to emit a single scalar "fixed version" field. The reasoning: a vulnerability can affect several release trains of the same component (for example >= 2.1.0, < 2.3.0 and >= 3.1.0, < 3.3.0) and can cover multiple components, so there is no one fixed version to put in the FPF without it being misleading. GitHub advisories already provide ranges (the fix is inferrable from the upper bound), and Trivy only gives a vulnerable / not vulnerable verdict.

New plan on the Dependency-Track side: the FPF will carry the full affected version ranges per component, under a new affectedVersions array on each finding's vulnerability. Each entry has the component identity (purl or cpe) and the version bounds (versionStartIncluding / versionStartExcluding / versionEndIncluding / versionEndExcluding), the same shape already exposed as affectedComponents on the vulnerability API. FPF_VERSION bumps when that lands.

What that changes for this issue:

• The two questions I asked at the bottom (single vs range, and what to name the field) are settled. It is a range array named affectedVersions, not a scalar with a negotiated name.
• The parser (dojo/tools/dependency_track/parser.py) now has to derive the upgrade target from the ranges rather than read a value straight off. For the finding's component, take the applicable range and use its upper bound (versionEndExcluding, i.e. the first patched version) as the "Fixed in X" value.
• Multiplicity has to be handled: more than one range means more than one candidate fixed version. Simplest is to surface the lowest fixed version above the component's current version, and fall back to listing the candidates when that is ambiguous.

The rest of the original proposal still holds: this maps to Finding.mitigation, no new model or Finding field.