SARIF reimport with `unique_id_from_tool_or_hash_code` closes valid findings even though `unique_id_from_tool` matches

[cpriyakant]

Description of the bug

When reimporting CodeQL SARIF into the same test with DD_DEDUPLICATION_ALGORITHM_PER_PARSER='{"SARIF":"unique_id_from_tool_or_hash_code"}', findings are closed even though the new SARIF contains the same vulnerability with an identical unique_id_from_tool. Only hash_code changes between scans, which is expected for a line/location change.

Given the metadata below, I expect DefectDojo to keep the existing finding open and reuse it (same vuln, new location), but instead some findings are being marked closed and no new findings are created.

Environment

• DefectDojo edition: Community

• DefectDojo version: (2.53.5)

• Deployment: docker-compose

• Relevant env var:

  DD_DEDUPLICATION_ALGORITHM_PER_PARSER: '{"SARIF": "unique_id_from_tool_or_hash_code"}'

• Test type: SARIF

• Endpoint used: /api/v2/reimport-scan/

• close_old_findings on reimport: true

• Same Product → same Engagement → same Test for both scans

What I’m doing

1. Initial CodeQL SARIF upload to a SARIF test via reimport-scan (first time behaves like import).
2. Later CodeQL SARIF reimport into the same test using /api/v2/reimport-scan/ with close_old_findings=true.
3. Code has changed so the line/location changed, but the logical vuln is the same.

Observed behavior

• Some findings are being closed (mitigated/inactive) after reimport.
• No new findings are created for those vulns.
• In SARIF Explorer and in DefectDojo API, I can see that the vuln is still present in the new SARIF and the unique_id_from_tool value is identical between fresh and reimport scans.
• Only hash_code changes between scans.

Expected behavior

With DD_DEDUPLICATION_ALGORITHM_PER_PARSER='{"SARIF":"unique_id_from_tool_or_hash_code"}' I expect:

• On reimport into the same test:
  • New SARIF result with same unique_id_from_tool should be matched to the existing finding and keep it open.
  • No new finding should be created (since it’s the same vuln).
  • close_old_findings=true should only close findings that have no matching unique_id_from_tool or hash_code in the new SARIF.

In other words: same test + same unique_id_from_tool + different location/hash_code should result in one open finding, not a closed finding and no new one.

Example metadata

Below are 3 findings, with metadata from the initial (fresh) scan and the reimported scan.

Fresh scan metadata:

• unique_id_from_tool:
  primaryLocationLineHash:2abebf2b9f7e8f07:1|primaryLocationStartColumnFingerprint:14
• hash_code:
  fd88a20b1bd5ce0674cfa22284f08e7cdb3d3369e58d7969afdd03b01b041fa5

• unique_id_from_tool:
  primaryLocationLineHash:7c1ccbae89e35318:1|primaryLocationStartColumnFingerprint:13
• hash_code:
  60caa862d2020e301b64b4f52ae88cfbbce991196ffddd417e50af9274d05980

• unique_id_from_tool:
  primaryLocationLineHash:db9e4b3bba297e41:1|primaryLocationStartColumnFingerprint:12
• hash_code:
  f1c6f6c4cccb48980e93b8758e42e48ae2cf7188f75b402fbfc7ce97b146e18c

Reimport scan metadata (same test, same vulns with changed location):

• unique_id_from_tool:
  primaryLocationLineHash:2abebf2b9f7e8f07:1|primaryLocationStartColumnFingerprint:14
• hash_code:
  1a49e4cdb4a19cc434a3da0a8a92ac8546487b3043a11f70205167cde9f3a908

• unique_id_from_tool:
  primaryLocationLineHash:7c1ccbae89e35318:1|primaryLocationStartColumnFingerprint:13
• hash_code:
  fa51a69946d6090670522afa22b81e56c6b189cdbaf48dda6f1f95caab230a85

• unique_id_from_tool:
  primaryLocationLineHash:db9e4b3bba297e41:1|primaryLocationStartColumnFingerprint:12
• hash_code:
  e5c242ce20f8cdf6878235c46e01dc4011853a9979c2cde4af7ecc223b04acbf

For all 3:

• unique_id_from_tool is identical between fresh and reimport.
• hash_code is different between fresh and reimport (expected for location change).

Despite this, some of these findings are being closed after reimport and no new finding is created.

Why this seems wrong

According to the deduplication docs and UNIQUE_ID_FROM_TOOL_OR_HASH_CODE semantics, if an incoming finding has the same unique_id_from_tool as an existing one, they should be considered the same logical finding. docs.defectdojo
In a reimport-scan for the same test, that should keep the existing finding open and mark it as “seen”; close_old_findings=true should only close findings that had no matching unique_id_from_tool or hash_code in the new scan. docs.defectdojo

Here, reimport behaves as if the finding was not seen, even though there is a matching unique_id_from_tool in the new SARIF. This looks similar to other reports where valid findings get mitigated on reimport. github

Request

• Can you please confirm the intended behavior of reimport-scan with UNIQUE_ID_FROM_TOOL_OR_HASH_CODE for SARIF?
• If my understanding is correct, can this be treated as a bug in the close_old_findings logic for SARIF reimport?

[valentijnscholten]

Can you provide a sample report to reproduce this?

[cpriyakant]

As of now I don't have the sample report but I will try to create one during weekends.

If it helps this is the same issue I am talking about 13681 , This is for different scan type, currently I am using SARIF files from codeql-CLI.

On the same thread this comment #13681 (comment) mentioned that its common issues for all SAST tools where only line number changes cause the findings to not found in report and gets closed in reimport.

also because of hash mismatch if the finding is closed then as per the new hash it create new findings but this is very horrible for dashboard statistics.

[cpriyakant]

I’ve done the following debugging, but the reimport scan API still closes findings as Inactive, Mitigated even when only the line number changes.

Environment configuration

I configured deduplication to rely solely on the tool’s unique ID for SARIF:

DD_DEDUPLICATION_ALGORITHM_PER_PARSER: '{"SARIF": "unique_id_from_tool"}'
DD_HASHCODE_FIELDS_PER_SCANNER: '{"SARIF": ["unique_id_from_tool"]}'

Hash / ID verification (separate engagements)

To verify that hashes and IDs are stable across scans, I imported the initial (fresh) SARIF and the modified (line‑shifted) SARIF into two separate engagements/tests. This was only for debugging purposes, to compare metadata without any reimport logic involved.

For a given finding, both tests show identical values:

unique_id_from_tool: primaryLocationLineHash:2abebf2b9f7e8f07:1|primaryLocationStartColumnFingerprint:14
hash_code:          6c8d780ee53e5b5f0612c5c57348b68790a381feaf2a5ae99840c03a3fbcea31

unique_id_from_tool: primaryLocationLineHash:2abebf2b9f7e8f07:1|primaryLocationStartColumnFingerprint:14
hash_code:          6c8d780ee53e5b5f0612c5c57348b68790a381feaf2a5ae99840c03a3fbcea31

So for the same logical CodeQL issue, the unique_id_from_tool and hash_code are identical in both the fresh and rescan uploads, even though the line number in the SARIF location changed.

Reimport behavior in a single engagement/test

Next, I returned to the main scenario:

1. Use a single engagement and a single test.
2. Import the fresh SARIF scan.
3. Reimport the modified SARIF scan (same findings, only line number changes, same unique_id_from_tool / hash).
4. Reimport is done via the API (reimport endpoint), with these env settings in place.

Expected behavior with this configuration:

• Since unique_id_from_tool and hash_code are identical between fresh and rescan, the reimport logic should recognize them as the same findings and keep them Active.

Actual behavior:

• Those findings are still being marked as Inactive, Mitigated during reimport, despite:
  • Matching unique_id_from_tool,
  • Matching hash_code,
  • And dedup configuration explicitly set to use unique_id_from_tool for SARIF.

This suggests that the reimport logic is performing additional checks or applying closing rules that are not aligned with the configured deduplication algorithm and hash fields, causing valid findings with unchanged tool IDs to be closed when only their line number changes.

[valentijnscholten]

Can you provide a sample report that reproduces this or the debug logs? Could be that the dedupe settings are not picked up.

[cpriyakant]

Sample report may take time cause I might not find the same scenario.

Currently I can import and reimport the scan into fresh engagement and same test so How do I generate logs or where I can view them?

[manuel-sommer]

Could this also be a performance related issue? I am also very interested in this topic.

[cpriyakant]

I did some more analysis and I think there are actually two interacting problems here: how CodeQL generates IDs and how DefectDojo’s dedupe/reimport logic uses them.

1. CodeQL CLI unique ID behavior

   CodeQL’s SARIF uses a line‑based fingerprint (primaryLocationLineHash + primaryLocationStartColumnFingerprint) as the basis for unique_id_from_tool. For JavaScript, this means that different queries like js/tainted-format-string and js/log-injection can generate the same unique_id_from_tool when they flag the same file and line. In other words, the tool ID is not “per query per occurrence”, it is “per line/location”.

   Because of that, on a fresh import with global dedupe enabled, DefectDojo will treat “category B” findings as duplicates of “category A” findings if they share the same unique_id_from_tool, even though they are different queries/categories. This duplicate behavior happens already on the first import if deduplication is enabled in System Settings.

2. Interaction with global vs engagement dedupe and reimport

   In my setup I initially disabled global deduplication in System Settings, but enabled “Deduplication within this engagement only” when creating the engagement. My understanding at the time was that engagement‑level dedupe would still work even if global dedupe was off (which may not be true).

   As a result:

   • On the fresh import, there was effectively no dedupe at all (so all findings were stored separately, even if unique_id_from_tool collided).
   • On reimport, once I turned on DD_DEDUPLICATION_ALGORITHM_PER_PARSER='{"SARIF": "unique_id_from_tool_or_hash_code"}', the reimport logic started to trust the tool’s unique_id_from_tool. For findings with a colliding CodeQL tool ID, reimport then:
     • Looked only at unique_id_from_tool,
     • Ignored the “normal” hash_code differences,
     • And incorrectly closed valid findings as if they were “old/unseen” when close_old_findings=true.

   In other words, switching to the UNIQUE_ID_FROM_TOOL_OR_HASH_CODE algorithm on SARIF made reimport rely on a tool ID that is not unique per query, which caused both wrong duplicate behavior and wrong closure on reimport.

3. Current workaround I’m using

   To avoid the non‑unique tool IDs, I’m currently working with:

   DD_DEDUPLICATION_ALGORITHM_PER_PARSER: '{"SARIF": "hash_code"}'

   and leaving HASHCODE_FIELDS_PER_SCANNER at its default for SARIF (which includes line number by default).

   With this setup:

   • Dedup uses only hash_code, not unique_id_from_tool.
   • On reimport, if a line number changes, the hash changes, so DefectDojo:
     • Closes the “old” finding,
     • Creates a “new” finding for the same logical vuln at the new line.
   • This is strict and somewhat noisy (line moves → close+recreate), but at least it avoids the incorrect behavior caused by non‑unique unique_id_from_tool.

   All of this started because CodeQL CLI produces the same unique_id_from_tool for different categories/queries on the same file+line, and the UNIQUE_ID_FROM_TOOL_OR_HASH_CODE algorithm assumes unique_id_from_tool is a stable, per‑finding key.

4. Question / expected solution

   Given this, I’m trying to understand what the intended solution is for tools like CodeQL where:

   • unique_id_from_tool is not guaranteed unique per query+occurrence (only per location), and
   • primaryLocationLineHash is query‑agnostic.

   Specifically:

   • Should the recommended approach for SARIF in this situation be to stop using unique_id_from_tool entirely and rely only on hash_code for dedupe and reimport (with clear guidance on safe default hash fields)?
   • Or is the expectation that users pre‑process SARIF to construct a better unique_id_from_tool (for example, ruleId + "|" + primaryLocationLineHash + "|" + primaryLocationStartColumnFingerprint), so that UNIQUE_ID_FROM_TOOL_OR_HASH_CODE can be used safely?
   • If pre‑processing is the intended path, would it make sense to document this explicitly for CodeQL/SARIF users, since using UNIQUE_ID_FROM_TOOL_OR_HASH_CODE with the raw CodeQL IDs leads to the incorrect closure behavior described in this issue?

Right now the only way I can avoid both “wrong duplicates between different categories” and “valid findings closed on reimport” is to ignore unique_id_from_tool and use a hash_code‑only strategy, which loses some of the benefits of tool‑provided IDs. It would be very helpful to know what DefectDojo considers the “best practice” here for SARIF/CodeQL.

[valentijnscholten]

If unique_id_from_tool is not unique, you can't use UNIQUE_ID_FROM_TOOL_OR_HASH_CODE or UNIQUE_ID_FROM_TOOL algorithms. SARIF is almost impossible for us to predict if it will work with any scanner as it's such a generic format which can be used and abused in many ways. In this case it looks like the CodeQL scanner is putting non-unique or non-constant values in the fingerprint field. I haven't studied all of the SARIF spec but it seems like the fingerprint fields are meant to help recognize identical findings in subsequent scans: https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/sarif-v2.1.0-errata01-os-complete.html#_Toc141791182
But to be honest I have hard time following all the information above. It would be much simpler to have a sample report to reproduce the problem.