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 powerful 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 explicitly cautions that EPSS is not a complete risk score and does not account for a specific environment, compensating controls, or impact. CISA KEV establishes observed exploitation somewhere, not exploitation of your asset. CVSS is technical severity, not ownership or business consequence.

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 reliable vendor evidence of exploitation. Use EPSS as a probability input when stronger active-exploitation evidence is absent. Record feed date and staleness.

4. Model consequence

Connect the asset to business service, sensitive data, privilege, lateral movement, safety, recovery dependency, and external obligations.

5. Choose an action and clock

Patch, mitigate, isolate, monitor, replace, or accept for a defined period. Assign an owner and target. A queue without ownership and verification is only a list.

Four common mistakes

1. Treating missing evidence as safety. A failed scan or unknown version is unresolved coverage, not proof that the condition is absent.
2. Overwriting operator state. A new scanner result should not silently reopen accepted risk, close a remediated issue, or erase the reason for a decision.
3. Ignoring feed time. KEV and EPSS change. Store the source version or observation time used in the decision.
4. Closing on ticket status. Closure needs a retest or other evidence that the condition or path changed.

How Argus structures the workflow

Argus Exposure imports findings and software inventories through strict adapters, deduplicates them around stable asset identity, and preserves original sources. Offline KEV and EPSS claims are stored with coverage and staleness metrics. Threat intelligence does not mutate the risk record automatically, and exploitability cannot be asserted without evidence.

Attack paths and toxic-combination rules add relationship context. Remediation records carry owners, service-level targets, exceptions, and acceptance. Rescan verification records the before-and-after delta. That makes priority reproducible even when the feed, scanner, or person changes.