Upgrading to DefectDojo Version 3.3.x
Deduplication identity changes
Three scan types gain HASHCODE_FIELDS_PER_SCANNER registrations in this release. A
registration changes how hash_code is computed, so findings imported by these parsers
before the upgrade carry a hash that no longer matches what an import computes after it.
Left alone, the next re-import of an unchanged report would treat every affected finding
as new, close the stored one as absent, and recreate it, detaching false positive
history and risk acceptances along the way.
| Scan type | New hash fields | Why |
|---|---|---|
Xeol Parser | title, component_name, component_version | Its severity is derived from the current date against the component’s EOL date, and the legacy hash meant finding identity moved on its own as time passed. Severity still escalates as an EOL date recedes; it just no longer decides what the finding is. |
Checkmarx One Scan | unique_id_from_tool | The parser already deduplicates on the vendor id. The stored hash previously fell through to the legacy field set, whose title and description are the same volatile text for every result family, so the stored identity moved whenever Checkmarx reworded a finding even though matching did not. |
Checkmarx Scan detailed | vuln_id_from_tool, file_path, line | The same three fields as its sibling Checkmarx CxFlow SAST, which the parser populates on every detailed-mode finding. None of them carries scan text. |
DefectDojo Pro
Pro 3.2.300 and later record identity signatures by default
(identity_signature_dual_write), and the nightly drift watch will notice these
definition changes and notify. The notification is a report, not a repair: recompute the
stored hashes with the same three commands below, or accept the definition change in the
Tuner, which runs the equivalent scoped rehash.
Two Pro-specific notes:
- If your instance has a signature ledger worth keeping (it has been recording for a
while, or you ran a backfill), run
python manage.py identity_signatures_backfillin a maintenance window before this upgrade. The backfill records the identities findings currently have, and a rehash replaces them; done in this order, the previous identities stay in the ledger and remain matchable during the transition on instances where signature matching is enabled. identity_signature_matchingremains opt-in per instance. Where it is enabled, imports still carrying the old identity bridge through the ledger during the transition.
Open source, and Pro instances that skip the rehash
Rehash the affected scan types after upgrading so stored hashes match what imports now compute:
docker compose exec uwsgi /bin/bash -c "python manage.py dedupe --parser 'Xeol Parser' --hash_code_only"
docker compose exec uwsgi /bin/bash -c "python manage.py dedupe --parser 'Checkmarx One Scan' --hash_code_only"
docker compose exec uwsgi /bin/bash -c "python manage.py dedupe --parser 'Checkmarx Scan detailed' --hash_code_only"Installs that never imported these scan types are unaffected.
SARIF-family parsers stop trusting repeated fingerprints
The SARIF parser (and the parsers built on it: CodeQL, Flawfinder, Cppcheck, DevSkim,
Mayhem, and the other SARIF subclasses) previously copied a result’s fingerprint into
unique_id_from_tool verbatim. SARIF fingerprints are frequently not unique: partial
fingerprints hash line content, so identical lines in different files collide, and some
scanners emit a constant placeholder for every result. Because these scan types
deduplicate on unique_id_from_tool first, a repeated fingerprint silently merged
findings that were visibly different.
From 3.3.0, a fingerprint value carried by more than one finding in the same report is dropped at parse time. Findings whose fingerprint is dropped deduplicate by hash code, exactly like findings the scanner gave no fingerprint. Fingerprints that are genuinely unique within their report are kept and behave as before.
No rehash is needed: stored hash codes are unchanged, and reimport continuity holds because a unique-id comparison against a now-absent id falls through to the same hash match it previously ended at. The visible effect is that new imports stop merging unrelated findings that happen to share a fingerprint; findings previously merged that way stay as they are and can be unmarked from each finding’s duplicates list if wanted.
Check the Release Notes for the full contents of the release.