Vulnerability Management Framework

Vulnerability management as a control loop

September 15, 2026·8 min read·Chris Boker
A closed control loop diagram: a green sensor block with five white scan bars sits at upper left, a mint comparator block holds a summing junction circle with a plus and a minus crossbar under a small setpoint tag at upper right, a gold actuator block with a piston and three ink levers sits at lower right, and a surface feedback block filled with three green validation checkmarks sits at lower left; four heavy ink arrows connect them clockwise while a green feedback arrow returns from validation up into the sensor, with a small gold delta diamond on the top link and a wider surface strip in the middle carrying a loop-latency trend line dotted by four green points falling as time passes

On June 10, 2026 the U.S. federal civilian branch started operating under a directive that quietly redefined what a mature vulnerability program has to look like. BOD 26-04 asks agencies to answer four questions per finding per asset: is the vulnerability in the KEV catalog, is exploitation automatable, does the technique give an attacker total control of the device, is the asset publicly exposed. Three of those four answers move on their own. A KEV entry lands when CISA publishes. An exploit module ships when a researcher releases it. A load balancer edit rewrites public exposure at 3 a.m. on a Tuesday. Agencies must be meeting 26-04 timelines by December 7, 2026, and the ones that built scan-then-ticket pipelines are about to discover the deeper fact the directive quietly assumes. A pipeline processes a finding once and forgets it. A directive that requires continuous answers to inputs that will not sit still cannot be satisfied by a pipeline even in principle.

The directive has no engineering vocabulary for the shape it demands. Engineers do. What it demands is a control loop.

Prior art that already frames the shape

Control theory is engineering baseline. A sensor reads state, a comparator subtracts state from setpoint, an actuator changes state, and a feedback path re-reads state and closes the loop. John Boyd's OODA loop (observe, orient, decide, act) is the doctrinal application to adversarial contexts. Google SRE built error budgets on the same pattern, with the burn rate acting as a comparator that gates deployments; the SRE book chapter on embracing risk is the closest published analogue of a comparator with teeth. Gartner's CTEM five stages already imply a cycle, and our own CTEM reference architecture named the closed-loop principle in July. None of that is being restated here.

What is not published anywhere is the loop mechanics for a vulnerability program. What the sensor, comparator, actuator, and feedback path actually are in remediation terms. Where real programs break the loop. How to instrument loop latency as a reported metric of program health. That is the argument the rest of this piece makes.

Four parts of a working loop, mapped to remediation

The sensor is the discovery and enrichment layer. Scanners, cloud posture readers, SBOM tools, external attack-surface probes, and KEV enrichment all feed one stream, and that stream is the current state of the environment. A sensor that reports once a week and forgets is worse than a sensor that reports continuously and disagrees with itself. The disagreement is what the loop learns from.

The comparator is the exposure model. It reads the current sensor stream and subtracts a definition of desired state. If desired state is "no KEV finding on an internet-facing asset older than 72 hours", the comparator produces a delta the actuator can act on. Most programs do not have a comparator; they have a severity histogram, which is a very different object.

The actuator is remediation capacity. Patch cycles, config changes, control tuning, and compensating rules are how the loop shrinks the delta. An actuator has a service rate that is finite and almost always ignored during intake planning.

The feedback path is validation evidence. A rescan, a control test, a BAS run, or a re-enrichment of the same finding tells the loop whether the actuator's action actually moved state. A closed ticket with no validation is not a state change; it is a guess about a state change, and the loop cannot learn from a guess.

Where the metaphor breaks

A physical plant has a stable setpoint. A thermostat wants sixty-eight. A vulnerability program does not, because an adversary chooses new payloads, so the setpoint moves. That does not kill the metaphor, it moves the interesting variable from the setpoint to the rate at which the loop can re-plan its comparator against a moving target. Programs that never revisit their definition of desired state are running open-loop against an adversary that iterates weekly. This is also where OODA earns its keep against the physical-plant model; Boyd's frame is explicit that both sides have loops, and the faster loop tends to win.

Three ways programs snap the loop

No feedback. Verizon's 2026 DBIR looked at more than 13,000 organizations and reported only 26 percent of KEV entries fully remediated, with median time to full remediation at 43 days. Some fraction of the other 74 percent is genuinely unfixed and some is ticket-closed but state-unchanged. Without a feedback path, the program cannot tell the two apart, and the dashboard reports both as "closed". Requiring rescan-attached evidence to close a ticket is the smallest, cheapest correction available, and it is where most programs should start.

No comparator. When desired state is "zero findings", every finding is at target and nothing is over target, so the comparator has no useful signal to compute. Better desired states are quantitative and layered: no KEV on internet-facing assets over 72 hours, no CVSS 9 or higher on identity systems over 14 days, recurring root causes trending flat quarter over quarter. Without a comparator, prioritization collapses back to sorting by severity, and severity is a histogram, not a work queue.

Saturated actuator. Edgescan's 2026 stats put 45.4 percent of findings unresolved at 12 months, with high and critical MTTR at 54.81 days for application and API and 39 days for network. When intake exceeds service rate for long enough, the queue is not a prioritization problem, it is a saturated actuator, and no amount of re-ranking will drain it. The arithmetic of the saturated actuator is its own conversation about queue economics; the loop view names the shape, and the economics view sizes the fix.

Loop latency is the program's speedometer

Loop latency is the time from an exposure appearing in the environment to a validated state change against it. Compute it from data every team already owns. The sensor timestamp of first observation is one endpoint. The ticket timestamp of a validated close, with rescan attached, is the other. The difference is per-finding latency, and the median of that difference (with the 95th percentile as a discipline check) is the program's real speed.

VulnCheck's 1H 2026 report puts median time from CVE publication to first evidence of exploitation at 80 days, down from 120 in 2025. That is the adversary's loop, measurably closing. If our loop latency is longer than theirs on our own exposures, the program is losing ground even when the tickets look busy on the dashboard. Loop latency is the metric that ties the whole loop together, and almost no program instruments it today, because dashboards ship with counts and SLA percentages, not with the elapsed time between a state change and its validation.

The metric is worth reporting quarterly to whichever forum owns exposure risk, alongside two decompositions that make it actionable. Latency by owner tells you who is holding the loop open. Latency by finding class tells you which classes take longest, and why.

Small loops beat big loops

A weekly per-service loop with three or five findings, a named owner, and a rescan on Friday closes faster than a quarterly program review that touches everything. The reason is control-theoretic. Small loops have small delays; small delays have small phase lag; and phase lag is where feedback control loses stability. Quarterly reviews report on decisions made months ago against state that has already moved twice, which is why they feel simultaneously exhausting and useless. Weekly loops correct.

The practical version is unglamorous. Pick five services that carry meaningful business risk. Assign each an owner. Hold a 30-minute weekly checkpoint whose only agenda is what the sensor saw this week, what got acted on, and what the feedback path is saying. Track loop latency per service. Do that for eight weeks and the program will have more real data on its own operating shape than any quarterly review has produced in years.

Where CVEasy fits

CVEasy AI is the local-first CTEM platform that runs exactly this loop against your own environment, with the sensor, comparator, actuator, and feedback path in the same working queue on hardware you own. TRIS is the score the comparator reads to produce a delta the actuator can act on today.