From c987b590a0fd259653f70d14a6c747bdc193137d Mon Sep 17 00:00:00 2001 From: Valentijn Scholten Date: Sat, 4 Jul 2026 10:54:54 +0200 Subject: [PATCH 1/2] docs(dedupe): document set-based hash code fields (vulnerability IDs + CWE matchers) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the Pro Tuner set-match hash-code fields: vulnerability_ids (exact), vulnerability_ids_partial/_subset, and cwes_partial/_subset — what each matches, how _partial/_subset are compared per pair rather than hashed, the empty-set behavior (abstain when another hashed field gates the pair; no match when the matcher is the sole field), and the config rules (a vulnerability IDs field may stand alone; CWE fields may not be the only criteria). --- .../PRO__deduplication_tuning.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md b/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md index e2eb9ec45bd..649d66ef609 100644 --- a/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md +++ b/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md @@ -50,6 +50,30 @@ Attempts to use the tool's unique ID first, then falls back to the hash code if #### Global Component Matches findings by component name and version across **all Products** in the instance, rather than within a single Product or Engagement. Intended for SCA tools where the same vulnerable dependency appears in many Products. This algorithm is off by default and must be enabled by DefectDojo Support. See [Global Component Deduplication](/triage_findings/finding_deduplication/pro__global_component_deduplication/) for details. +### Set-based Hash Code Fields (Vulnerability IDs and CWEs) + +Two finding attributes hold a *set* of values rather than a single value: vulnerability IDs (CVE, GHSA, …) and CWEs. When using the **Hash Code** algorithm (Same Tool or Cross Tool), you can add the following fields to **Hash Code Fields** to control how those sets are compared: + +| Field | Findings are duplicates when… | +|-------|-------------------------------| +| `vulnerability_ids` | they have the **exact same set** of vulnerability IDs | +| `vulnerability_ids_partial` | they share **at least one** vulnerability ID | +| `vulnerability_ids_subset` | one finding's vulnerability IDs are a **subset** of the other's | +| `cwes_partial` | they share **at least one** CWE | +| `cwes_subset` | one finding's CWEs are a **subset** of the other's | + +The `_partial` and `_subset` fields are compared per finding pair rather than folded into the hash: the remaining Hash Code Fields group the candidate findings, and the set comparison then narrows that group. (Exact matching, `vulnerability_ids`, is folded into the hash directly.) + +**Empty values.** If a finding has no vulnerability IDs (or no CWEs) for the configured matcher: + +- If Hash Code Fields also include an ordinary field (for example `title`), that field carries the identity — the set matcher is skipped for the pair and the findings can still match on the rest of the hash. +- If a set matcher is the **only** field, a finding with no values does not match anything: with nothing else to identify it, an empty set is not treated as matching every other finding. + +**Configuration rules** (enforced when you save settings): + +- A vulnerability IDs field (`vulnerability_ids`, `vulnerability_ids_partial`, or `vulnerability_ids_subset`) may be used on its own — a CVE or GHSA identifies a specific vulnerability instance. +- CWE fields (`cwes_partial`, `cwes_subset`) may **not** be the only criteria. A CWE is a weakness *class*, not a specific instance, so matching on CWE alone would merge unrelated findings. Pair a CWE matcher with an identifying field such as `title` or `file_path`. + ## Cross Tool Deduplication Cross Tool Deduplication is disabled by default, as deduplication between different security tools requires careful configuration due to variations in how tools report the same vulnerabilities. From 93546090fbe7966cf5f8ea1d16cd89b228e7f326 Mon Sep 17 00:00:00 2001 From: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Date: Mon, 13 Jul 2026 19:37:48 -0600 Subject: [PATCH 2/2] docs(dedupe): document the bare `cwes` (exact-set) hash token (F40) The token table listed cwes_partial/cwes_subset but omitted the bare `cwes` token (exact CWE set, folded into the hash like `vulnerability_ids`). Add the row, note it in the exact-matching sentence, and include `cwes` in the "CWE fields may not be the only criteria" rule. Co-Authored-By: Claude Fable 5 --- .../finding_deduplication/PRO__deduplication_tuning.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md b/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md index 649d66ef609..46a6ad9b67f 100644 --- a/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md +++ b/docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md @@ -59,10 +59,11 @@ Two finding attributes hold a *set* of values rather than a single value: vulner | `vulnerability_ids` | they have the **exact same set** of vulnerability IDs | | `vulnerability_ids_partial` | they share **at least one** vulnerability ID | | `vulnerability_ids_subset` | one finding's vulnerability IDs are a **subset** of the other's | +| `cwes` | they have the **exact same set** of CWEs | | `cwes_partial` | they share **at least one** CWE | | `cwes_subset` | one finding's CWEs are a **subset** of the other's | -The `_partial` and `_subset` fields are compared per finding pair rather than folded into the hash: the remaining Hash Code Fields group the candidate findings, and the set comparison then narrows that group. (Exact matching, `vulnerability_ids`, is folded into the hash directly.) +The `_partial` and `_subset` fields are compared per finding pair rather than folded into the hash: the remaining Hash Code Fields group the candidate findings, and the set comparison then narrows that group. (Exact matching — `vulnerability_ids` and `cwes` — is folded into the hash directly.) **Empty values.** If a finding has no vulnerability IDs (or no CWEs) for the configured matcher: @@ -72,7 +73,7 @@ The `_partial` and `_subset` fields are compared per finding pair rather than fo **Configuration rules** (enforced when you save settings): - A vulnerability IDs field (`vulnerability_ids`, `vulnerability_ids_partial`, or `vulnerability_ids_subset`) may be used on its own — a CVE or GHSA identifies a specific vulnerability instance. -- CWE fields (`cwes_partial`, `cwes_subset`) may **not** be the only criteria. A CWE is a weakness *class*, not a specific instance, so matching on CWE alone would merge unrelated findings. Pair a CWE matcher with an identifying field such as `title` or `file_path`. +- CWE fields (`cwes`, `cwes_partial`, `cwes_subset`) may **not** be the only criteria. A CWE is a weakness *class*, not a specific instance, so matching on CWE alone would merge unrelated findings. Pair a CWE matcher with an identifying field such as `title` or `file_path`. ## Cross Tool Deduplication