Patch queues should start with evidence of use

Vulnerability programs often inherit a queue sorted by the largest technical severity number. That is easy to automate and hard to defend. It can place an isolated critical condition ahead of a reachable high-severity issue that attackers are already using.

CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities exploited in the wild and recommends using it as an input to prioritization. FIRST defines EPSS as an estimate of the probability that exploitation activity for a published CVE will be observed in the next 30 days. These are useful inputs because they answer different questions.

Keep the questions separate

• CVSS: How technically severe could exploitation be under the scoring assumptions?
• CISA KEV: Is there evidence this CVE has been exploited in the wild?
• EPSS: What is the estimated probability of exploitation activity in the next 30 days?
• Local exposure: Is an affected instance present, reachable, and on an attack path?
• Business context: What service, data, safety function, or revenue depends on the asset?
• Control state: Do segmentation, authentication, filtering, detection, or isolation materially change likelihood or impact?

FIRST describes EPSS as one input because it lacks your environment and compensating controls. KEV shows that a CVE was exploited somewhere; local evidence establishes whether your instance was affected. CVSS scores the flaw, while asset records show what depends on it.

A defensible five-layer priority model

1. Confirm applicability

Resolve product, version, configuration, and component evidence. Scanner fingerprints are useful leads, but ambiguous identity should be resolved before an emergency change.

2. Establish local exposure

Determine internet reachability, required authentication, network paths, tenant boundaries, and whether the vulnerable function is enabled. Preserve the observation time and source.

3. Add threat evidence

Promote KEV items and credible vendor reports of exploitation. Use EPSS as a probability input when nothing stronger is available. Record the feed date, and how stale it was when you decided.

4. Model consequence

Connect the asset to the business service it supports, the data it holds, and what an attacker could reach from it. Add safety and contractual obligations where they apply.

5. Choose an action and clock

Choose a patch, mitigation, isolation step, or time-limited acceptance. Assign an owner and date so the list becomes a work queue.

Four common mistakes

1. Missing evidence leaves coverage unresolved. A failed scan or unknown version cannot prove that the condition is absent.
2. Protect operator state. A new scanner result must preserve accepted-risk decisions and remediation evidence, including the recorded reason.
3. Feed timestamps matter. KEV and EPSS change, so store the source version or observation time used in the decision.
4. A ticket status cannot close a finding by itself. Closure needs a retest or other evidence that the condition or path changed.

How KernelHawk structures the workflow

KernelHawk helps teams combine vulnerability evidence, asset ownership, business impact, and fix verification into one prioritized record.

Attack paths and toxic-combination rules add the relationship context. Every remediation record carries an owner, a target date, and any exception that was granted. When you rescan, the system records what actually changed — so the priority holds up even after the feed, the scanner, or the analyst has moved on.