Triaging Auto-Filed Vulnerability Tickets

Vulnerability scanners are designed for coverage, not for prioritisation. A single dependency update in a base image can generate hundreds of findings across services. A new scan of the same unchanged systems refiles what was already known. Container images pull in operating system packages that your application never calls.

Three structural problems follow.

Severity is not exposure. Scanners report a base score without knowing whether the component is reachable, authenticated, or even loaded at runtime.

Ownership is missing. A finding lands on on-call because the scanner has no model of which team owns the affected service.

Repetition is constant. The same unpatched package reappears on every scan, so triage effort is spent re-reading decisions that were already made.

The result is an on-call engineer reading hundreds of tickets that describe the same handful of underlying facts, while the one that matters sits in the middle of them.

Why this is an incident management problem

Scanners are not wrong, just unaware

1. Enrich automatically before a human sees it. Attach the affected asset, its owner, whether it is internet facing, what data it handles, the runtime version actually deployed, and whether the vulnerable code path is reachable where you can determine that.

2. Attach exploitation status. Check the finding against known exploited vulnerability catalogues and exploit prediction data. This is the single most useful enrichment step.

3. Auto-close the noise. Components not deployed, packages present in an image but not used at runtime where you can prove it, and findings already tracked under an existing ticket.

4. Route by ownership. Send remaining findings to the team that owns the service, into their backlog, with a due date derived from severity and exposure.

5. Page only on a narrow rule. For example: internet facing, unauthenticated, remote code execution or authentication bypass, and either publicly exploited or with a public proof of concept. Everything else waits for business hours.

6. Suppress with an expiry. Accepted risks and false positives get a suppression with an owner, a reason, and a review date, so they cannot become permanent invisible debt.

7. Feed patterns back. Group findings by weakness class and by base image or shared library. Most flood problems are fixed once at the base image, not repeatedly per service.

Agree the paging rule with security and engineering together. Written down, with examples of what does and does not page. An unwritten rule becomes an argument during an incident.

Set service level targets by tier, not by score alone. For example, internet-facing critical findings within days, internal criticals within a sprint, everything else within a release cycle. Then measure against them.

Measure the right things. Time to triage, time to remediate by tier, the number of findings auto-closed, the number of pages generated, and how many of those pages led to same-night action. If almost none did, the rule is too broad.

Review suppressions on a schedule. The list of accepted risks is where quiet failure accumulates.

Keep one ticket per underlying problem. If forty services share a vulnerable base image, the work is one image fix and forty follow-ups, not forty investigations.

Record decisions with a root cause code. Over a quarter, the codes show whether the queue is dominated by base images, unpatched dependencies, or scanner false positives, and each of those has a different fix.

Re-run the rule against past incidents. Take the last few genuinely urgent vulnerabilities and check whether your rule would have paged for them. That is the only real test of the threshold.