Patch order is not decided by severity alone: separate exploitation evidence, exposure, and mitigations

EDITORIAL PRACTICE

Severity scores do not tell you what is being exploited

Scores such as CVSS evaluate the nature of a vulnerability — how easy it is to exploit and how large the impact could be. But as CISA's Binding Operational Directive 22-01 explains, the CVSS base score does not account for whether a vulnerability is actually being used to attack systems. Some high scores have only ever been demonstrated in labs, while some medium scores power widespread attacks.

The numbers support the distinction. The same directive's background notes that less than 4% of the total number of CVEs have been publicly exploited. A severity-only queue therefore spends equal effort on the 96% that are not being used. With limited maintenance time, misordering is directly a longer exposure window.

And exploited vulnerabilities move fast: of those known exploited CVEs, 42% are being used on day 0 of disclosure, 50% within 2 days, and 75% within 28 days. Attackers' first move is faster than a monthly patch cycle. That speed gap is why exploitation evidence belongs at the front of the ordering rule.

Severity still has a role: as a secondary key inside the exploited set, and as an initial signal before exploitation evidence exists. The error is letting the score alone decide the order. In this design, exploitation evidence is the first key, and exposure plus severity are the second.

Operationally, the change starts as a re-sort: join scan results with KEV membership and bring KEV matches to the top. No new tooling is required; matching existing scan output against a public catalog is the first step.

A common floor-level misunderstanding is that everything the scanner marks critical is equally dangerous. Scanner severity exists for coverage, not for ordering. Writing down the division of labor — the scanner finds, the KEV match and exposure review order — moves meetings forward on its own.

Vendor-side scoring also keeps evolving, including revisions and companion exploitability indicators. For your own operation, the durable design is to hold external evaluation and actual exploitation fact separately, with the fact at the head of the queue; improvements in external indicators simply sharpen the secondary key.

Sources: [1][2]

EDITORIAL PRACTICE

Wire the KEV catalog in as a prioritization input

The KEV catalog lists vulnerabilities CISA judges to have been exploited in the wild. Per CISA's explanation, inclusion requires an assigned CVE ID, reliable evidence of active exploitation, and a clear remediation action such as a vendor update. A listing therefore certifies two things at once: it is being used, and a fix exists.

The catalog is available in CSV and JSON, so it can be matched mechanically against asset inventories and scan results. Operationally, fetch the catalog diff weekly and pick up new entries matching products you run. An arrangement that depends on a human reading the catalog will not survive; automate the diff and the match.

BOD 22-01 binds federal agencies, but its deadline design transfers to private small organizations. Catalog entries carry remediation timelines, by default within 6 months for CVEs assigned prior to 2021 and within two weeks for all other vulnerabilities. The transferable idea is the unit: exploited items get week-scale deadlines.

CISA itself frames the catalog as an input to an organization's vulnerability management prioritization framework — material to combine with your own asset and exposure picture, not a ready-made work order. Catalog order is not your work order; the join with your environment is what produces one.

Keep the join result as a table: per asset, KEV match yes/no, the CVE, listing date, and your internal deadline. That table becomes the core ledger of patch operations; information that lives only inside a scanner UI serves neither deadline management nor management reporting.

When automating the match, mind the catalog's update shapes: not only new listings but deadline changes and corrected entries appear as diffs. In weeks where a change touches your products, revisit the ledger deadlines in step. The catalog is a living input, not a static list.

Tie the match to the product inventory as well: unless products and versions are recorded accurately, KEV hit detection itself leaks. Product-inventory precision decides the entry precision of exploitation-based ordering.

Sources: [1][2]

EDITORIAL PRACTICE

Exposure reorders even identical KEV entries

The same KEV vulnerability carries different urgency on different assets. An internet-facing server or VPN appliance and a test terminal deep inside the network differ completely in attacker reachability. The second ordering key is this exposure.

Evaluate exposure from asset-ledger attributes: internet exposure, the population that can reach it, the sensitivity of the data it handles, and the business impact if it stops. If the ledger lacks these attributes, ledger repair precedes KEV matching; ordering precision is capped by ledger precision.

Prioritize boundary devices: VPN, remote access, mail, and public web servers. They are the attacker's first landing point and the repeat target of exploited vulnerabilities. Decide in advance that a KEV match on a boundary device pre-empts other scheduled work.

Conversely, low-exposure, low-impact assets can legitimately wait for the normal maintenance cycle. If every KEV match is treated as an emergency, the word emergency wears out and real emergencies stop moving people. Ordering means deciding what is urgent — and being able to say, out loud, what is not.

Exposure is not static. New publications, configuration changes, and expanded remote work all change it. Fold ledger review into the change procedure and refresh the joined table monthly; a static table drifts from reality within months.

For ledger attributes, even just two — an internet-exposure flag and a boundary-device flag — are worth aligning first. Too many attributes and maintenance dies. Keep only attributes the ordering actually uses and drop the rest; a ledger that keeps being updated beats a detailed one that does not.

Sources: [1][2]

EDITORIAL PRACTICE

Set deadlines by class and catch overruns by monitoring

Set deadlines per class: KEV with external exposure gets the shortest window (two weeks as a ceiling, shorter for boundary devices), KEV without exposure the next class, and non-KEV items the normal cycle. BOD 22-01's defaults — six months for older CVEs, two weeks for the rest — show that class-based deadlines are an established public pattern.

A deadline does nothing without a mechanism that counts down and surfaces overruns and near-overruns weekly. Treat overruns not as individual lateness but as an ordering or resourcing signal: review overrun counts and reason categories in a standing meeting, and let accumulated reasons test whether the classes and deadlines themselves are realistic.

Include the work steps in the deadline math. Patching involves validation, scheduling with business owners, a restart window, and a rollback plan. Count backwards from validation start, not from the apply date; if validation finds a problem at the deadline, no time remains to design a mitigation. Slack is created by starting earlier, not by stretching the date.

Expand what automatic updates cover first. OS and major middleware auto-updates, and vendor-side SaaS updates, leave the human ordering queue entirely. What remains after automation is the set that genuinely needs judgment — exactly where a small team's attention should go.

One principle stays fixed ahead of the exceptions discussion: an exception is not 'an extension request' but 'a plan to reduce exposure within the window via mitigation', and it only stands when presented as that pair.

In the weekly check, use the list sorted by days remaining as the agenda itself. Skipping the slide-making step raises the meeting's survival rate. Each item resolves to exactly one of three decisions — schedule the patch, switch to mitigation, or revisit the class — and everything else is deferred. That simplicity is what lets a small team keep the loop turning.

Align deadline classes with the answers you give in audits and customer security questionnaires. When classes and deadlines exist as documents, questionnaire answers are written straight from the ledger; an operation that lives only in someone's head gets reinvented for every questionnaire. Deadline design is also an external-communication asset.

Sources: [1][2]

EDITORIAL PRACTICE

When you cannot patch, reduce exposure instead of waiting

Reality includes cases where the deadline cannot be met: no vendor fix yet, no restart window, a validation failure. The correct action then is not waiting but reducing exposure. BOD 22-01's background presents isolation among the mitigations for assets that cannot be updated in time, describing isolation as a form of removal from the network.

Order mitigation candidates by blast radius: disable the affected feature, restrict source networks, segment the asset, strengthen monitoring, or suspend the asset temporarily. None is permanent, but each lowers reachability or impact. Record, in one line per mitigation, which risk it reduces and by what mechanism.

Every mitigation carries an expiry, entered in the ledger together with the rescheduled patch date, and resurfaced automatically when due. Assets left indefinitely 'under mitigation' wear the face of 'handled' forever; add a quarterly sweep that lists everything still living on mitigation alone.

Document mitigations as an agreement with the business side: the residual exposure period, the business impact, and the name of the person who accepted it. If an incident occurs later, that record is what separates 'neglect' from 'managed risk acceptance'. Design it as shared risk, not a security team's unilateral call.

Where the blocker is the vendor, record the vendor check itself: fix ETA, workaround availability, official recommendations. With facts on record, internal deadline decisions and audit explanations become concrete; 'waiting on the vendor' as a bare phrase is where operational quality goes to die.

Record cost alongside effect for mitigations so later decisions get faster. Source restriction is cheap and cuts reachability sharply, while segmentation is stronger but slow to design and verify. With past mitigation results in the ledger, a new vulnerability immediately gets the answer to 'does the previous play work here too?'.

When choosing mitigations, escalate gradually: start with the option of least business impact, confirm its effect, then move to stronger measures. Jumping straight to full isolation often fails to win business agreement and paradoxically extends the period in which nothing is done.

Sources: [1][2]

EDITORIAL PRACTICE

Exceptions and records: a ledger that survives audits and handovers

For each vulnerability, the ledger keeps the affected assets, class, deadline, patch date or mitigation, exception reason and approver, and verification result. With that, operations survive staff changes, and audits or customer questionnaires can be answered from the ledger itself. Records are not a by-product of operations; they are what makes ordering decisions reproducible.

Fix the exception approval bar in advance: who approves extensions, whether an extension without mitigation is allowed at all, and the maximum length. Where one class accumulates exceptions, treat the accumulation itself as the problem and revisit the class design or resourcing. Exception statistics are the operation's self-inspection.

Report upward as trends, not lists: remaining KEV count, overrun count with reasons, boundary-asset status, and the number of assets held on mitigation. Translate into 'how many publicly reachable holes with confirmed exploitation remain' and the report becomes usable for decisions.

Mind the blind spot: assets the scanner cannot see receive no ordering at all. Reconcile the asset ledger against scan coverage, track agent-less endpoints, and inventory shadow IT. The ordering system only means something together with management of what is visible in the first place.

Finally, prepare the emergency lane: for a vulnerability under mass exploitation, define an out-of-cycle procedure that runs the match and sets deadlines without waiting for the weekly rhythm. With the standing system in place, an emergency is just that system run faster.

Reporting culture matters as well: do not punish overruns in the report. If overruns become blame material, the floor quietly loosens deadlines themselves. Treat overruns as adjustment material for ordering and resourcing, and revise classes or deadlines to fit reality where needed. Honest numbers set the speed of improvement.

Decide where the ledger lives and who can read it. Residual-vulnerability information is itself valuable to an attacker, so share the ledger only on a need-to-know basis and aggregate it before anything goes outside. Keeping the defensive record from becoming a new exposure is part of the design.

Sources: [1][2]

EDITORIAL PRACTICE

Start small: build the operation from this week's match

None of this requires a large rollout. The first step is fetching the KEV catalog in JSON, matching it against your main products, and writing the hits into a ledger. Scoped to boundary devices and public servers, the first match takes hours, not weeks. Do not wait for a perfect ledger; start the loop on a narrow scope.

Next, set provisional classes and deadlines and put the weekly check into a standing meeting. The numbers do not need to be right on day one; tune them toward reality as overrun reasons accumulate. Deadlines treated as instruments for adjusting order and resources, rather than as sticks, earn the floor's cooperation.

Monthly, maintain the ledger and review mitigations; quarterly, review the class and deadline design itself. Once these three rhythms turn — weekly match and deadline check, monthly ledger maintenance, quarterly design review — patching stops being 'process whatever arrived' and becomes an operation whose order can be explained.

Decide how effect is measured: average days-to-remediate for KEV items, overrun rate, remaining KEV count on boundary assets. Watching those numbers fall is the evidence the operation works; a class whose numbers never move is a signal that either the design or the resourcing is wrong.

Vulnerabilities will keep growing — CISA's own background expects the KEV count to expand as new CVEs increase. In a world of growth, admitting that not everything can be chased, and concentrating resources on the most reliable signal — confirmed exploitation — is the design that defends best.

Rehearse the emergency lane once. Under a simulated 'mass exploitation reported' scenario, run the match, deadline setting, and business notification end to end. The stalls in rehearsal are usually the unglamorous parts — where the ledger lives, who calls whom — and removing those stalls before a real event is the entire point.

Sources: [1][2]