Set finding mitigation from Dependency Track affected version ranges - #15366
Open
webdevred wants to merge 4 commits into
Open
Set finding mitigation from Dependency Track affected version ranges#15366webdevred wants to merge 4 commits into
webdevred wants to merge 4 commits into
Conversation
Read the affectedVersions ranges the Dependency Track FPF now exports and set the finding mitigation to the first patched version (versionEndExcluding), matched to the finding's component by purl. This surfaces the upgrade target without opening the advisory. Handles a single affected range for now.
…ation When a vulnerability lists several affected ranges for the same component, compare the installed version against each range's bounds and use the fix from the range it falls in, so a component on the 2.x line is not pointed at a 3.x fix. Fall back to the single range when only one matches, and to no mitigation when the version cannot be parsed.
…is known When the affected range the component falls in has no versionEndExcluding there is no exact first fixed version to name. Use versionEndIncluding instead and word the mitigation as an upgrade to a version after the last affected version.
Treat an affected-version entry with no range bounds (an exact-version entry) as not containing any version, so it no longer matches every component or masks a real range in the process. Apply the containment check to a single matched range as well, and fall back to a lone range only when the component version cannot be compared.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
When Dependency Track pushes findings via the Finding Packaging Format, each vulnerability now carries the affected version ranges per component. DefectDojo dropped them, so a finding told an auditor a component was vulnerable but not which release to move to, leaving the upgrade target to be looked up by hand in the advisory.
This reads those ranges and sets the finding mitigation. For the range the installed component version falls in, it uses versionEndExcluding (the first patched version) to say "Upgrade to X or later", and falls back to "Upgrade to a version after X" from versionEndIncluding when no exact fix version is known. Ranges are matched to the component by purl and compared with packaging, so when a vulnerability spans several release lines the range the installed version actually sits in is the one used. Exact-version entries and component versions that do not parse are left without a mitigation rather than guessing, and findings whose vulnerability has no affected version ranges are unchanged.
This needs the Dependency Track side that emits the ranges (FPF 1.6). It implements #15239 and is the companion to the Dependency Track change that adds the affected version ranges to the FPF export (DependencyTrack/dependency-track#5907).
Test results
Added unit tests and FPF fixtures under
unittests/covering the exact-fix case, the versionEndIncluding wording, multi-range selection (the installed version picks its own range), the exact-version-entry guard, and the unparseable-version fallback. The fullTestDependencyTrackParsersuite passes and the code is Ruff compliant. Also verified end to end by importing a sample FPF export into a running DefectDojo and confirming the mitigation was set on the resulting findings (for example log4j-core 2.14.1 gets "Upgrade to 2.15.0 or later").Documentation
No documentation change needed. This enriches the output of the existing Dependency Track parser (it now sets the mitigation field) and does not add a new parser, setting, or model.
Checklist
dev.dev.bugfixbranch.