You Can't Out-Scan an AI: Why Vulnerability Management Needs an OODA Loop, Not a Patch Cycle

Air Force Colonel John Boyd spent years on a puzzle from the Korean War: why did American F-86 pilots keep beating MiG-15s that could out-climb and out-turn them? The answer wasn't a better airframe. It was fast transients, the F-86's ability to shift from one maneuver to the next more quickly, thanks to better cockpit visibility and lighter, high-authority controls. Whoever could change state faster controlled the fight. Through the 1970s and 80s Boyd generalized that into one of the most quietly influential ideas in modern strategy, the OODA loop (observe, orient, decide, act), and it explains something about vulnerability management that "attackers are getting faster" doesn't quite capture on its own.

Boyd's real insight wasn't that speed wins. It was that an OODA loop has two sides you can work at once: compress your own time, and stretch out your opponent's. Against a peer, you stretch his by generating mismatch, presenting a situation that changes faster than he can form an accurate picture of it, so that his observations stop matching reality. Boyd called the result operating "inside" the adversary's loop: the opponent is reacting to a world that has already moved. He doesn't just lose the current exchange; he loses the ability to act on accurate information at all.

Vulnerability management inherits a constraint that reshapes how this works. It is almost pure defense, and the systems you're defending have mission focus. They are on the network because they have to be reachable and running. You can't manufacture ambiguity by maneuver the way a fighter pilot can; you can't strike the attacker's decision cycle, and you can't move the data center into the woods under a camo net every few days. What you can do is constrain the terrain he has to cross. Orient and act to close the available attack paths (gauntlets within gauntlets) before he has time to exploit them: overlapping controls, segmentation, and containment that channel every approach into narrower, better-watched ground. Denied, delayed, contained. Run that at loop speed and the ambiguity and the stretched attacker clock come as a consequence, not as the goal. His reconnaissance goes stale, and his exploit is built for a path you've already closed. That is Boyd's freedom of action, diminishing the adversary's while improving your own, in a domain where you only hold the shield.

Most vulnerability management programs are structured as if this idea doesn't apply to them. They're built as a pipeline: scan, prioritize, patch, repeat next month. A pipeline has no adversary in it. It assumes the only clock that matters is your own. Boyd's framework insists on a second clock, the attacker's, and asks whether yours is faster or slower than theirs. It also asks a question a pipeline never poses: what are you doing to slow theirs? Right now, for most programs, it's slower, and not by a small margin.

Traditional vulnerability management, as most programs run it, means scanning for vulnerabilities, ranking them by CVSS, and patching down the list until the next scan. Boyd's framework doesn't ask for a faster version of that. It asks whether observation, orientation, decision, and action even function as a loop, or whether they're four disconnected steps that happen to run in sequence.

Observe: Asset Visibility Is the Foundation of Vulnerability Management

Boyd's loop starts with observation, and this is where most programs are already compromised before anything else goes wrong. An observation is only as good as the inventory it's drawn from, and most organizations have a partial one. Business IT tends to be reasonably mapped. Industrial control systems, shadow SaaS integrations, and anything provisioned outside a formal process tend not to be, and that unmapped territory is exactly where risk concentrates, precisely because nobody is looking at it.

This is where progressive discovery matters: inventory has to be a byproduct of the ongoing security work, not a prerequisite that has to be finished before the work starts. Waiting for a complete asset inventory before doing anything else is how programs stay permanently stuck at the first node of the loop.

What that looks like in practice varies by substrate, and treating it as one uniform problem is itself part of why observation stays broken.

Active scanning works well against a corporate IT fleet, but it can take an OT network offline if pushed into it, so the primary method there has to be passive: span traffic, protocol-aware sensors that speak Modbus or DNP3 rather than generic network traffic. Some industrial environments only get one real downtime window a year, sometimes just a single holiday shutdown day, so waiting for an active scan to confirm what's out there isn't a scheduling inconvenience. It simply isn't going to happen on any timeline a patch cycle assumes.

SaaS sits outside all of it entirely, visible only through API-based posture checks and OAuth scope inventory rather than anything resembling a traditional scan.

None of these methods is a lesser substitute for active scanning; each is the primary tool for its own zone. A program that only knows how to point one instrument at every substrate will always have zones it can't actually see, not because no one built a scanner for them, but because the substrate was never going to answer to that kind of scanner in the first place.

Orient: Why CVSS Alone Isn't Enough

Of the four nodes, orientation is the one Boyd spent the most time on, and it's also the one most vulnerability management programs skip almost entirely. Boyd didn't treat orientation as a simple filter that observations pass through. He treated it as the phase where raw data gets taken apart and recombined (cross-referenced against experience, culture, and everything already known) into a picture you can actually act on. Boyd built orientation out of heritage, cultural traditions, previous experience, new information, and, at its core, the interplay of analysis and synthesis. It's the richest and most decisive node in the loop, not a formality between seeing and deciding.

Reduce that synthesis down to a single number, and you've thrown away almost everything Boyd meant by orientation. That's precisely what happens when a CVSS score is treated as the whole picture. A CVSS score describes a vulnerability in isolation. It says nothing about whether an attacker can actually reach the asset, whether the business would notice if it went down, or whether that vulnerability class is the kind currently being targeted by automated discovery.

Real orientation has to synthesize all of that, which is why effective programs blend CVSS with EPSS, CISA's Known Exploited Vulnerabilities list, network reachability, and business context into a single disposition tier rather than a severity score.

There's a second, subtler failure at this stage: most security stacks orient on contradictory data by picking a winner and discarding the rest. A firewall reports an asset running Linux traffic. The EDR on the same asset reports Windows. Most platforms force a resolution, and whichever one loses, half the real picture disappears with it. In this case, both are right, it's a Windows host running a Linux subsystem the firewall correctly picked up. The fix Boyd's framework points toward is to stop reconciling and start preserving: every observation stays intact as its own timestamped claim, and the current best understanding of an asset gets computed from that full evidence base at query time rather than collapsed into one brittle record ahead of time. Disagreement becomes a signal instead of noise, and the picture gets sharper every time the loop runs again.

Decide: Vulnerability Prioritization Requires More Than Patching

Boyd viewed decisions as provisional hypotheses, not permanent conclusions. They exist to be tested by action and revised by the next pass through the loop, not settled once and left alone. Most vulnerability management programs treat "decide" as choosing whether to open a ticket, with a single 30-day SLA covering everything above a severity threshold. That's not a decision process; it's a filter with one setting.

A decision process that actually reflects the orientation feeding into it needs more than one lever. Patch is the obvious one, but it's rarely the only right answer:

• Virtual patching buys time when a vendor fix doesn't exist yet.
• Compensating controls reduce risk when neither patch nor virtual patch is viable.
• Segmentation isolates what can't be hardened in place.
• Retirement removes assets that shouldn't be running at all.
• Documented risk acceptance handles what's genuinely below threshold, provided it's revisited rather than left to quietly become tech debt.

The SLA has to attach to that disposition and its tier, not to the raw severity score, because a tier-one patch and a tier-one compensating control don't share a verification path and shouldn't share a clock.

Act: Closing the Loop Faster Than the Attacker

The version of Boyd's diagram most people know is a simple four-box cycle. Boyd's own fully drawn version (the one in his final work, The Essence of Winning and Losing) adds feed-forward paths and "implicit guidance and control": orientation doesn't only feed decisions, it can drive observation and action directly once a pattern is understood well enough to pre-authorize a response. That's the mechanism behind machine-speed defense: not skipping orientation, but making it mature enough that some responses don't need to wait for a fresh decision cycle each time.

Just as important is the feedback running backward through the whole loop. Every action generates new observations. A deployed control, a verified patch, a segmented asset: each one updates what gets observed next time, which sharpens orientation, which improves the next decision. A pipeline doesn't have this property. It ends when the ticket closes. A loop doesn't end; it compounds, and that compounding is the actual source of the tempo advantage Boyd was describing, not raw speed on any single pass.

Getting Inside Your Own Loop First

The uncomfortable implication of Boyd's framework is that most organizations aren't losing to a faster adversary so much as they're not running a loop at all. A scan-and-patch pipeline has no orientation phase worth the name, no disposition beyond patch-or-don't, and no feedback path connecting action back to observation. There's nothing for tempo to compound against.

Most programs sit somewhere between knowing they have gaps and actually routing findings to the right disposition, with partial inventory, a CVSS-driven queue, and patch treated as the default answer for everything. That's not a failure of effort. It's what a pipeline looks like when it's running as well as a pipeline can, which was never going to be well enough.

The fix isn't a faster pipeline. It's closing an actual loop, one where inventory builds itself through the work, where orientation synthesizes rather than scores, where decisions route to the right disposition instead of a single SLA, and where every action makes the next cycle sharper than the last.

There's a military idiom for the alternative to standing still and studying the problem: get off the X, the kill zone, and move.

Slow is smooth. Smooth is fast.

Building an actual loop takes deliberate work, not a rush job, but deliberate isn't the same as slow. It's the difference between moving with a plan and not moving at all. The full version of that plan, how it plays out on a Windows fleet, a PLC, or a CI/CD pipeline, is more than one post can cover; that's what Arctiq's on-demand webinar on this framework walks through in detail.

If you'd rather start with where your own loop is actually breaking, Arctiq's next step is a 60-minute working session to map your substrate mix and find the highest-leverage place to start, no six-month scoping process required. Get in touch to set one up.