Include analysis.detail in DefectDojo finding payload

[webdevred]

Description

When DefectDojo is used as the primary triage surface and Dependency-Track as the SBOM ingestion engine, the per-finding audit text stored in analysis.detail never made it into the payload sent to DefectDojo. Auditors working in DefectDojo had no way to see that context without switching back to DT for every finding.

This adds ANALYSIS."DETAILS" to the SQL queries that back the Finding model, which makes the field flow into the Finding Packaging Format document that the DefectDojo integration uploads. The field appears as analysis.detail alongside the existing analysis.state and analysis.isSuppressed fields.

One option considered was prepending the audit detail directly to vulnerability.description in the FPF, which would have made it visible in DefectDojo without any changes on that side. That was rejected because vulnerability.description is CVE data and mixing analyst notes into it would affect any other consumer of the FPF. Adding it as a separate field keeps the concerns separated and lets each consumer decide how to present it. A companion PR to DefectDojo appends it to the finding description there.

One pre-existing bug is also fixed here: after the new column was inserted at position 36, the QUERY_ALL_FINDINGS call site in FindingsSearchQueryManager was reading the project UUID from the wrong index. This would have caused a runtime failure in the global findings view for any project with a finding that has audit detail set.

Related to DefectDojo/django-DefectDojo#14931

Addressed issue

Closes #6169

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[owasp-dt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[nscuro]

Hi @webdevred, please re-target your PR at either 4.14.x (for v4) or main (for v5) as per https://github.com/DependencyTrack/dependency-track/blob/main/V5_MIGRATION.md#contributors-and-pr-authors.

[nscuro]

Please bump the FPF version accordingly:

dependency-track/apiserver/src/main/java/org/dependencytrack/integrations/FindingPackagingFormat.java

Lines 46 to 49 in 03f1364

	/**
	* FPF is versioned. If the format changes, the version needs to be bumped.
	*/
	private static final String FPF_VERSION = "1.3";

And add an entry for the change here:

dependency-track/docs/_docs/integrations/file-formats.md

Lines 29 to 40 in fadd195

	> Finding Packaging Format v1.1 was introduced in Dependency-Track v4.5 and supports an array of CWEs per vulnerability.
	> Previous versions of Dependency-Track supported only a single CWE (`cweId` and `cweName` fields respectively) per
	> vulnerability.
	> The `cweId` and `cweName` fields are deprecated and will be removed in a later version. Please use `cwes` instead.
	> Finding Packaging Format v1.2 was introduced in Dependency-Track v4.8.0.
	> It removes the allBySource and the technical 'id' values, which were exposed unintentionally, in the aliases array of a vulnerability.
	> The example below shows how aliases are currently exported.
	> Finding Packaging Format v1.3 was introduced in Dependency-Track v4.14.0.
	> It adds optional `cvssV2Vector`, `cvssV3Vector`, `cvssV4Vector`, and `owaspRRVector` fields to `vulnerability` objects,
	> which are included when the corresponding scores or ratings are available and may be omitted otherwise.

[webdevred]

Hi,
Thanks for the feedback!
What do you think of this entry?

Finding Packaging Format v1.4 is not yet available in a stable release of Dependency-Track
It adds an optional detail field to analysis objects, which contains any analyst notes recorded against the finding.

Best regards,
webdevred