Upgrading to DefectDojo Version 2.59.1

Dependency Check parser: related dependencies folded into the main finding#

The Dependency Check parser previously created one finding per <relatedDependency> in the report, in addition to the finding for the main vulnerable dependency. Because OWASP Dependency-Check attaches the vulnerability only to the main dependency in the XML and the related entries are metadata pointing to other files in the same logical component, this produced N findings sharing the same title, CVE, component name and component version — only the file path differed. For projects with Spring Boot, ActiveMQ, or other libraries whose CPE matches many sibling artifacts this produced significant noise.

Starting in 2.59.1, the parser emits exactly one finding per vulnerability per main dependency. The file paths of any related dependencies are surfaced in the finding description under a **Related Filepaths:** block.

Background: what <relatedDependencies> actually contains#

OWASP Dependency-Check’s DependencyBundlingAnalyzer merges co-grouped artifacts into a single main dependency and lists the others under <relatedDependencies>. It does this under five scenarios:

1. Identical content (hashesMatch) — the same jar (matching sha1) found at multiple paths, e.g. the same library packaged into multiple ear/war archives.
2. Shaded jar (isShadedJar) — a .jar and a pom.xml extracted from inside it share the same CPE; the pom.xml is recorded as related.
3. WebJar (isWebJar) — a .js file extracted from a WebJar matches the jar’s CPE (mapped via pkg:maven/org.webjars/<name>@<version>); the js file is recorded as related to the jar.
4. Same CPE + base path + vulnerabilities + filename match — sibling artifacts in the same project that share a CPE. Example: spring-boot, spring-boot-actuator, spring-boot-starter-jdbc, etc. all map to the spring_boot CPE and are grouped under the main spring-boot jar.
5. NPM same name + version — the same npm package discovered via different resolution paths (for example package-lock.json plus node_modules).

Only scenario 1 represents the same vulnerable artifact at multiple deploy locations. Scenarios 2-5 are different files representing one logical component. Both cases were previously inflated into separate findings; both now collapse to one finding with the related paths listed in the description.

Required actions#

• Users filtering or grouping by the related tag: that tag is no longer applied because related findings are no longer created. Update any saved filters, dashboards, or rules that depend on it. Equivalent information is now available in the finding description (look for **Related Filepaths:**).
• Reimport behavior: on the next reimport of an existing Dependency Check report, the previously-created related findings will be closed as no longer present in the report. This is expected and matches the new parsing behavior.

For more information, check the Release Notes.