agent's finding dedup merged distinct vulnerabilities into one finding

TL;DR

Dedup that keys on the vulnerability name alone will merge the same flaw on different hosts, paths, or parameters into a single finding, understating the engagement. Key the merge on the full identity, check plus host plus location plus parameter, merge only exact identity matches, and keep the merge audit so a reviewer can see what was combined and why.

agent's finding dedup merged distinct vulnerabilities into one finding

Use this when

• Two or more scanner results for the same check on different locations appear as one finding in the agent report.
• Finding counts drop sharply between raw scanner output and the deduplicated report with no explanation.

Not for this skill when

• The same check fired repeatedly on one URL with identical evidence. That is a true duplicate and should merge.
• Counts differ because the agent filtered false positives with documented reasons. That is triage, not dedup loss.

Steps

1. Take one merged finding and list every raw scanner result the agent claims it represents, side by side. Verify: Verify: the raw results differ in host, path, or parameter, proving the merge was wrong.
2. Define the finding identity as the combination of check id, host, path, and parameter or evidence location, and write it down as the dedup rule. Verify: Verify: the rule is explicit enough that two operators would merge identically.
3. Re-run dedup with the new key and compare counts: raw results, true duplicate groups, and final findings. Verify: Verify: the arithmetic reconciles, raw minus duplicates equals findings.
4. Keep a merge audit in the output: each finding lists the raw result ids it absorbed, so any merge can be inspected and undone. Verify: Verify: picking any finding shows its source results.
5. Add a regression case to the pipeline tests using two same-check results on different hosts, asserting they stay separate. Verify: Verify: the test passes now and would fail under the old name-only key.

Variant phrasings

finding dedup key host parameter check id

The key-design phrasing.

agent merged same vulnerability different hosts one finding

The symptom phrasing.

dedup audit trail scanner results merged findings

The audit phrasing.

Compatibility: Compatibility: any agent reporting pipeline that ingests scanner output; the identity fields exist in nmap, nuclei, Burp, and ZAP exports.

Why it happens

Deduplication is a grouping decision, and grouping by title is the lazy default a model-driven pipeline drifts into because titles are salient. But in security reporting, location is identity: the same flaw on ten hosts is ten remediation tasks for ten owners. A loose key silently converts real breadth into a single line item, and nobody notices because the report looks tidy.

Edge cases / pitfalls

• Some checks legitimately roll up per host even with many parameters; make roll-up a per-check explicit policy, not a side effect of the key.
• Evidence differences can matter within one location, for example two distinct payloads; include an evidence hash in the key for high-volume checks.
• Publish the merge audit with the report QA pack; undercounted findings are a credibility risk if the client rescans.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yWoHRKIYP7XOdtOB-B2t1Q