How deduplication works
How Prodgator groups findings from different scanners into one finding, and how to split a wrong grouping.
When multiple scanners report the same problem in the same place, Prodgator shows it as one finding. The grouping rules differ by finding type.
The rule of thumb
Same problem in the same place, reported by any scanner: one finding.
Dependencies
Findings are grouped by:
- Repository
- Package name
- Vulnerability ID
Vulnerability IDs are matched through the OSV database alias list, so a CVE and its GHSA alias report as one finding. Versions are shown but not compared; GitHub reports a vulnerable range, not a fixed version.
If the OSV database cannot be reached, Prodgator uses the IDs in the report and regroups findings later when OSV becomes available.
SARIF has no standard package field. For each dependency result, Prodgator reads the package name, version and ecosystem from where the scanner puts them: a purl or package property, the result message (Grype, Trivy, OSV-Scanner), the rule ID (Checkov) or the lockfile path. A SARIF result from Grype, Trivy or OSV-Scanner for lodash CVE-2021-23337 therefore joins the Dependabot alert for the same package and CVE. A dependency result whose package cannot be read groups with other such results by repository and vulnerability ID only. See how SARIF results are categorized.
Code
Findings are grouped by file location. Within the same file, Prodgator first matches SARIF fingerprints (if both findings have them). If not, it looks for a shared CWE, or the same scanner and rule when neither has a CWE. Findings within 3 lines of each other also match.
Secrets
Findings are grouped by secret type, file and line number. GitHub secret alerts get their location from GitHub.
Several scanners
Results from several scanners that describe the same problem end up in one finding. For SARIF:
- Dependencies: grouped by repository, package and vulnerability ID, the same as Dependabot alerts and CycloneDX reports. Grype writes rule IDs like and Trivy writes ; Prodgator reads the CVE and the package from both. The same lodash CVE from Grype, Trivy, OSV-Scanner and Dependabot in one repository becomes one finding. CVE and GHSA aliases are matched through OSV, so an npm audit result that only names the GHSA joins the CVE finding.
- Dependencies without a package: when a scanner's SARIF gives a vulnerability ID but no package Prodgator can read, the finding groups with other such findings by repository and vulnerability ID, but not with Dependabot alerts. A CycloneDX report with vulnerabilities always carries the package.
- Code: findings in the same file group when they share a SARIF fingerprint, share a CWE and are within 3 lines, or (with no CWE) come from the same scanner and rule within 3 lines.
- Fingerprints: SARIF (for example , which CodeQL and Grype write) make matching more precise and keep a finding's identity when code moves. Prefer scanner output that keeps them.
- Secrets: grouped by secret type, file and line.
Finding state
- Open: the finding is open if any of its scan results is open.
- Dismissed: the finding is dismissed only when every scan result that is not fixed is dismissed (and at least one is dismissed).
- Fixed: otherwise, the finding is fixed.
Why grouped
Every scan result shows the reason it was grouped into its finding, for example "GHSA-... is an alias of CVE-... (OSV)" or "Same file, same CWE".
Nothing is thrown away
Deduplication changes how findings are shown, not what is stored. Every scan result stays, with its own source, state and link:
- The Scan results view shows every scan result, always.
- The export has one row per scan result, not per finding.
- The API endpoint returns scan results.
- Compliance checks count findings and scan results together, for example "2 open critical findings (5 scan results from 3 sources)".
Counts always come in pairs: unique findings and scan results.
Splitting and rejoining
If a finding grouped scan results incorrectly, an or can click Split and move one or more scan results to a new finding. The split is recorded in the audit log.
Click Rejoin to undo a split and move scan results back to the original finding. The rejoin is also recorded.
Determinism
The same set of scan results always produces the same findings. Uploading the same report again (for example, the same SARIF file to the same run) does not change anything.