Findings incorrectly reactivated by Trivy and GitLab API Fuzzing scans despite being absent from the report

[Hamudah]

Description
When importing scans from the Trivy scanner and the GitLab API Fuzzing Report parser, previously mitigated findings are incorrectly reactivated (reopened), even though those findings are not present in the uploaded scan.

Expected behavior
Findings that do not appear in the current scan should remain (or be set to) mitigated, since deduplication/reimport should only reactivate findings that are actually present in the report.
Actual behavior

Findings that are absent from the scan get reactivated and reopened.
After a few days they close/mitigate themselves again on their own.
I verified the raw scan files directly and confirmed the affected findings are not contained in them, so they should be marked as mitigated rather than reopened.

Affected scanners

Trivy
GitLab API Fuzzing Report

Impact
False re-opening of already-mitigated findings creates noise and inaccurate finding status in the dashboard.

I have observed this in the OSS and the Pro Version we are running. After a few days it gets back to normal, but the teams are running down my door, asking what the issue here is. Are there any known issues regarding this scanners?

[tejas0077]

Hi @Hamudah, I'd like to take a look at this issue!
The behavior you described where findings mitigation status flips back and forth over a few days sounds like it could be related to a timestamp/timezone mismatch during the asynchronous reimport task processing, or an unstable unique ID/hash generation in those specific parsers.

To help me reproduce and debug this accurately, would you be able to provide sanitised/dummy versions of:

1. The initial scan report containing the findings.
2. The subsequent scan report where those findings were absent but got reactivated anyway.

Thanks!