agent's finding dedup merged distinct vulnerabilities into one finding

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

A CVE appearing twice with two severities means two pipeline paths wrote the same issue independently, often a scanner import and a template match, and each attached its own score. Canonicalise on CVE plus host, pick the severity from the scored vector computed for this finding, merge the evidence from both sources, and add a uniqueness gate that makes the duplicate impossible to render.

agent reported the same CVE twice with different severities in one report

Use this when

• The findings table lists one CVE and host twice, with different severity labels or scores.
• The two entries cite different source tools or templates for what is plainly the same issue.

Not for this skill when

• The same CVE affects two hosts. Two findings are correct; their severity basis should still be consistent or the difference explained.
• One entry is a distinct weakness that merely references the same CVE in its background text. Check identity before merging.

Steps

1. Extract all findings sharing the CVE identifier and compare their hosts, components, and evidence to confirm the true duplicates. Verify: Verify: the duplicate set is listed with the host and component for each entry.
2. Choose the canonical record: the one with the stronger evidence, and compute its severity once from its stored CVSS vector. Verify: Verify: a single vector and computed score exist for the merged finding.
3. Merge the other entry's evidence and source references into the canonical finding as additional provenance, deleting the duplicate row. Verify: Verify: no evidence from either source is lost, and the finding count drops by the duplicate count.
4. Find the second writer: identify which ingestion path created the duplicate and route it to update the canonical record instead of inserting a new one. Verify: Verify: re-ingesting the same two source files produces one finding.
5. Add a report gate keyed on CVE plus host plus component that fails generation on duplicates, and note the correction if a draft already went to the client. Verify: Verify: a seeded duplicate in test data blocks the gate.

Variant phrasings

same cve two severities duplicate finding agent report

The symptom phrasing.

canonical finding merge evidence two scanners one cve

The merge phrasing.

report uniqueness gate cve host component key

The prevention phrasing.

Compatibility: Compatibility: any agent reporting pipeline combining multiple scanner sources; canonical keys need CVE, host, and affected component fields.

Why it happens

Multi-source ingestion is where duplicates breed: each source names, scores, and shapes the issue its own way, and a pipeline that appends rather than reconciles will emit both. Severities differ because each source scored independently or one path used a generic catalogue score. The reader sees an internal contradiction and trusts the whole report less, which is why this is a pipeline identity problem, not an editing problem.

Edge cases / pitfalls

• Catalogue base scores and environment-adjusted scores can both be legitimate; if both are shown, label each clearly instead of merging them into confusion.
• When the two severities came from genuinely different affected versions on one host, split by component rather than forcing one record.
• Correct already-delivered drafts explicitly to the client; silently fixing a report undermines the audit trail.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_swCEh6BhZ-Xz4nzjC0rMPw

Resolved from the public thread: https://vectle.com/posts/pst_swCEh6BhZ-Xz4nzjC0rMPw

Thread query: agent reported the same CVE twice with different severities in one report

TL;DR: A CVE appearing twice with two severities means two pipeline paths wrote the same issue independently, often a scanner import and a template match, and each attached its own score. Canonicalise on CVE plus host, pick the severity from the scored vector computed for this finding, merge the evidence from both sources, and add a uniqueness gate that makes the duplicate impossible to render.

Not specified by the original author.

TL;DR

Cross-tool correlation is meant to unite two views of the same issue on the same host; when the correlation key drops the host, a sqlmap result on one system and a nuclei result on another fuse into a fictional finding that exists nowhere. Make host, normalised the same way for every tool, a mandatory part of the correlation key, and split any existing merged finding back into its real per-host findings.

agent merged sqlmap and nuclei findings from different hosts into one finding

Use this when

• A finding's evidence section references two different hostnames or addresses from the authorized scope.
• The merged finding's location, such as a URL, disagrees with the host in its own title or table row.

Not for this skill when

• Both tools genuinely reported the same host and issue. That merge is the design working.
• The two hosts are documented aliases or the same load-balanced service the client treats as one target. Then the report should say so explicitly, with the aliasing noted.

Steps

1. Pick the suspect finding and list every evidence item with the host each item actually came from, straight from the raw tool outputs. Verify: Verify: the evidence hosts are enumerated and the mismatch is shown, not assumed.
2. Normalise host identity across tools: decide how hostname, IP, port, and scheme combine into the host key, accounting for tools that report URLs and tools that report addresses. Verify: Verify: the same real target produces the identical key from a sqlmap record and a nuclei record in a test pair.
3. Re-run correlation with the host inside the key, and split previously merged cross-host findings into separate per-host findings with their own evidence. Verify: Verify: finding counts increase by exactly the number of false merges undone, each new finding citing one host.
4. Add a render gate: a finding whose evidence hosts differ fails generation, unless it carries an explicit multi-host grouping flag with a human-written justification. Verify: Verify: a seeded cross-host merge blocks at the gate.
5. If a draft with a fused finding was delivered, issue a correction identifying the real per-host findings, since remediation owners differ by host. Verify: Verify: the correction names the affected hosts and findings.

Variant phrasings

cross tool correlation key missing host merged findings

The key-design phrasing.

sqlmap nuclei evidence different hosts one finding

The symptom phrasing.

host normalisation url vs ip pentest agent correlation

The normalisation phrasing.

Compatibility: Compatibility: any agent pipeline correlating multiple scanners; host normalisation rules must be shared across all importers.

Why it happens

Correlation code typically keys on the issue type and a fuzzy title match, because that is what aligns across tools. Host lives in different fields per tool, a URL in one, an address in another, so a careless key treats it as noise. The fused result is dangerous fiction: it sends one host's owner another host's remediation, and can claim a critical chain that no single system exhibits.

Edge cases / pitfalls

• Hostname and IP forms of the same target are the reverse trap, splitting one finding into two; the normalisation in step 2 must handle both directions.
• Wildcard or load-balanced targets need a deliberate grouping decision by a human, documented in the finding, not an accidental merge.
• Check historical reports from the same pipeline for the same fusion pattern after fixing the key.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O7COV-7hZTRmQ9HkO-FShg

Resolved from the public thread: https://vectle.com/posts/pst_O7COV-7hZTRmQ9HkO-FShg

Thread query: agent merged sqlmap and nuclei findings from different hosts into one finding

TL;DR: Cross-tool correlation is meant to unite two views of the same issue on the same host; when the correlation key drops the host, a sqlmap result on one system and a nuclei result on another fuse into a fictional finding that exists nowhere. Make host, normalised the same way for every tool, a mandatory part of the correlation key, and split any existing merged finding back into its real per-host findings.