The arithmetic of alert fatigue
Consider one real pattern: a vulnerable transitive dependency. It appears as:
- an SCA finding on the dependency manifest,
- a container-image finding on the built artifact,
- a runtime finding on the deployed workload,
- and often a DAST finding on the endpoint that exercises the library.
Four tickets, one root cause, one fix. If your platform reports four, your engineers learn within a month that the queue is not a to-do list — it is background noise. Once that belief sets in, the real critical finding gets triaged with the same shrug.
What deduplication actually has to do
Naive deduplication matches on CVE identifier or on file-and-line. Both fail. CVE matching misses the case where the same vulnerable function is reached through two different packages. File-and-line matching misses the case where the same defect is reported at the sink by SAST and at the source by a different rule.
Root-cause deduplication requires a correlation key built from the defect's reachability path, not its label. In TrustArmor™ the key is composed of:
- Entry point — the route, handler, or job that first touches untrusted input.
- Data-flow signature — the normalized sequence of transformations the value passes through.
- Sink identity — the dangerous operation (query execution, deserialization, file write, template render).
- Artifact lineage — the commit, build, and image digest that produced the running code.
Two findings that share all four are the same defect. Two findings that share only the CVE are not.
Worked example
An unvalidated redirect in a Node service. SAST reports it at res.redirect(req.query.next). DAST reports it as an open-redirect on GET /login?next=. SCA reports nothing. A naive platform shows two medium findings and an engineer fixes one of them.
With a correlation key, both collapse to a single entry whose evidence bundle contains the SAST data-flow trace, the DAST proof-of-concept request, and the commit that introduced the handler. The remediation is one pull request, and the closure evidence is attached to both original tool reports automatically.
The metrics that prove it is working
Do not measure “findings closed.” That number goes up when you close noise. Measure these instead:
| Metric | Definition | Healthy target |
|---|---|---|
| Deduplication ratio | Raw findings ÷ distinct root causes | 6:1 to 12:1 |
| True-positive rate on the deduplicated queue | Confirmed defects ÷ distinct root causes triaged | > 70% |
| Median time-to-remediate (critical) | First detection to merged fix | < 72 hours |
| Reopen rate | Root causes reappearing within 90 days | < 5% |
| Coverage of ASVS v5 L2 controls | Controls with at least one automated or manual test | > 90% |
The deduplication ratio is the leading indicator. If it is near 1:1, your platform is a log aggregator, not an ASPM system. If it is above roughly 15:1, you are probably over-merging and hiding distinct defects behind one ticket.
Where teams get this wrong
- Deduplicating before triage. Merge first, then triage the merged set. Triaging raw findings and merging afterwards wastes the triage effort.
- Losing the original tool reference. Auditors and tool owners need the source finding. Keep the raw records as evidence children of the root cause, never delete them.
- Treating suppression as remediation. A suppressed finding with no compensating control is an open finding with a nicer status.
- Ignoring artifact lineage. Without the image digest, you cannot tell whether a finding is in production or only in a stale branch build.
How this connects to compliance
ASVS v5 and SOC 2 both ask for evidence that identified vulnerabilities were remediated within a defined window. A raw finding count cannot answer that question — it has no notion of “the same defect.” A root-cause record with a first-seen timestamp, a merged fix commit, and a verified closure does.
Managed AppSec Services runs this correlation continuously across SAST, DAST, SCA and cloud posture, and delivers the deduplicated queue with remediation patches rather than a raw export.
Bottom line
Alert volume is not a security signal. The number of distinct, reachable, exploitable defects is. Root-cause deduplication is the mechanism that turns a 10,000-row export into a work queue a team can actually finish — and into evidence an auditor will accept.