# Triage And Deduplication > Use when turning raw scanner output into an actionable backlog — deduplicating, filtering false positives, and grouping findings so teams fix root causes, not thousands of tickets. - Skill: `jihedbfr-art/triage-and-deduplication` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/triage-and-deduplication` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/triage-and-deduplication/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/triage-and-deduplication --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose Raw scanner output is unusable as a work list: the same vulnerability appears across hundreds of hosts, false positives are mixed in, and one root cause (an outdated base image, a missing patch) shows up as thousands of separate findings. Triage turns that flood into an actionable, deduplicated backlog. Done well, it's the difference between a team fixing root causes and a team drowning in tickets. This skill covers making scanner data actionable. ### When to use it Between scanning and remediation, every cycle. It's the processing step that makes the numbers manageable — a programme that dumps raw scan results on engineers gets ignored; one that hands them a deduplicated, prioritised, verified backlog gets action. ### Procedure 1. **Deduplicate across scans and sources.** The same CVE reported by two scanners, or the same finding on repeated scans, is one issue — collapse it. Correlate findings across your network scanner, web scanner, and cloud/container tools so a vuln isn't counted (and worked) multiple times. 2. **Group by root cause, not by instance — the key move.** One missing patch across 500 hosts, or one vulnerable base image behind 50 containers, is *one* remediation action, not 500 tickets. Group findings so the team fixes the cause once and closes many findings. This collapses the numbers dramatically and matches how remediation actually happens. 3. **Filter false positives.** Scanners (especially unauthenticated) produce them; a finding that isn't real wastes remediation effort and erodes trust. Validate uncertain findings, and suppress confirmed false positives with a reason so they don't reappear each cycle. 4. **Confirm exploitability/applicability in context.** A flagged vuln in a component your system never invokes, or already mitigated by a compensating control, is lower (or non-) priority. Reachability and context adjust the real risk (ties into cvss-in-context). 5. **Prioritise the deduplicated set** using severity, environmental exposure, and exploitation likelihood (cvss-in-context, EPSS, KEV) so the backlog is ordered by real risk. 6. **Assign to owners** (from the asset inventory) and route into the remediation workflow with clear, grouped actions. 7. **Track state** — new, in-progress, remediated, risk-accepted, false-positive — so the backlog reflects reality and closed items don't reopen as noise. ### Cheatsheet ``` raw scan -> ACTIONABLE backlog 1. dedup same CVE across scanners/scans/hosts = ONE issue (correlate) 2. group by root cause (the big win) 1 missing patch on 500 hosts = 1 action, not 500 tickets 1 vulnerable base image, 50 containers = 1 fix 3. filter FPs validate uncertain; suppress-with-reason (don't reappear) 4. context unreachable component / compensating control -> lower/no priority 5. prioritise severity x exposure x likelihood (cvss-in-context + EPSS + KEV) 6. assign owner from inventory -> remediation workflow (grouped actions) 7. track state new / in-progress / remediated / risk-accepted / false-positive goal: teams fix ROOT CAUSES, not drown in per-instance tickets. ``` ### Reading the backlog - **Thousands of findings that collapse to dozens of root causes** = the normal, healthy result of good triage; grouping by cause is what makes the workload real. If your backlog is still per-instance, you're overwhelming the fixers. - **The same finding reappearing every scan** = deduplication/suppression isn't working, or a false positive isn't recorded; it retrains people to ignore the backlog. - **Findings on unreachable components or already-mitigated issues rated high** = context isn't applied; they inflate the queue with non-issues. - **A root cause (base image, patch) spread across many tickets** = a grouping failure — one fix would close them all; surface the cause. - **Ownerless items** = they won't move; assign from the inventory. - **A deduplicated, root-cause-grouped, prioritised, owned backlog** = the actionable output remediation needs. ### The fix / best practice - **Deduplicate and correlate** across scanners, scans, and hosts so each issue is counted and worked once. - **Group by root cause** — the highest-leverage step; it turns thousands of findings into a manageable set of actions and matches how fixes actually deploy. - **Validate and suppress false positives** with recorded reasons so they don't recur and erode trust. - **Apply context** (reachability, compensating controls) to filter non-issues before they consume effort. - **Prioritise the clean set** by real risk and **assign to owners** with grouped, clear remediation actions. - **Track finding state** so the backlog reflects reality and closed items stay closed. ### Pitfalls - **Dumping raw scan output as the work list.** Thousands of duplicated, per-instance, false-positive-laced findings overwhelm and get ignored. Triage is what makes it usable. - **Not grouping by root cause.** Working 500 tickets for one missing patch wastes effort and demoralises; group the cause. - **Ignoring false positives.** They waste remediation time and teach teams the backlog is noise. Validate and suppress-with-reason. - **Skipping context.** Rating unreachable or already-mitigated issues as high inflates the queue with non-problems. - **No state tracking.** Without it, remediated findings reappear as noise and risk-accepted items look like neglect. ### References - NIST SP 800-40 (vulnerability management workflow) - The vulnerability-scanning, cvss-in-context, epss-and-exploit-likelihood, and asset-inventory skills - SANS / industry guidance on vulnerability triage and deduplication ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.