Why is vulnerability management no longer a supporting function in security operations?

Every other security team now depends on vulnerability management's data and coordination — patching needs its prioritization, forensics needs coordination before evidence is lost, and IT needs actionable reports to avoid outages. What used to be a scan-and-report function now sits directly in the critical path of every remediation decision.

Why does memory capture have to come before patching a compromised system?

Rebooting to apply a patch destroys volatile evidence that cannot be recovered afterward. On any externally facing or possibly compromised system, the order of operations is set by how evidence decays — patching has to wait until forensics confirms the asset is safe to touch, or evidence has already been collected.

How should organizations prioritize vulnerabilities by blast radius?

Treat it as a pyramid: critical services (DNS, Active Directory, core infrastructure) and business applications sit at the top and need the most caution, analysis, and time before acting. Executive workstations and general endpoints sit in the middle. Kiosks and low-sensitivity terminals sit at the base, where patching or isolating fast is safe — that's where automation and process compression should happen first.

What does CISA's Binding Operational Directive require for known exploited vulnerabilities?

CISA's BOD puts known exploited vulnerabilities on a three-day remediation clock and requires documented forensic justification when an externally facing asset can't be patched in that window. Combined with remote and field work expanding what counts as externally facing, that clock now applies to far more of the environment than it used to.

Why does Little's Law mean vulnerability teams need more capacity, not just faster tools?

Little's Law says the work sitting in a queue equals the arrival rate times the time each item spends in the system (L = λW). Vulnerability discovery is climbing while each vulnerability's time-in-system has a floor set by the forensic gate and human judgment — so if capacity holds still, the backlog only grows. Both sharper prioritization and more people and tooling near the top of the pyramid are required, not either one alone.

← Resources

BlogJuly 16, 2026

80,000 Machines, Every Three Days

Monzy Merza

Founder & CEO, Crogl

A navy stepped pyramid of blocks rising from a fast-churning, streaked base to a single sharp, motionless amber-lit block at the apex, encircled by a faint cycle arc — representing blast-radius prioritization under a compressed vulnerability remediation clock

Early results from Mythos use have elevated vulnerability management to the center of enterprise security operations. Patching, forensics, compliance, and incident response will have to flow through vulnerability management. More vulns will be found in less time, and enterprises are rethinking how to manage this new cycle.

Vulnerability management is the nexus

I worked on the vulnerability management team at a National Lab. We were a supporting function. We ran scans, validated results, produced reports, and handed them off. But now, these teams are central. Every other team flows through them. The patching side of IT depends on its data to know what to touch. The detection side wants prioritization of what to look for. The IT team is getting deluged, so they want actionable reports with instructions so they don't cause outages. The investigation team wants guidance on assessing blast radius; the forensics team wants coordination in case they find new vulns; the remediation team wants guidance so they don't lose evidence. And all these teams want to know which data to collect, how to organize it, and how to share it.

Every day starts to look like Patch Tuesday

The regulatory pressure is on its way. US Gov orgs are already feeling it. CISA's Binding Operational Directive (BOD) puts known-exploited vulnerabilities on a three-day remediation clock, and requires documented forensic justification when an externally facing asset can't be patched in time. This may sound like, oh, it's only for externally facing assets. But with remote work and field work, those are big numbers.

Combine three-day mandates with Glasswing-scale discovery, and the monthly patch cadence has collapsed. Collection, analysis, prioritization, communication, remediation, and validation have to run as one compressed cycle, over and over, across the whole environment. I was speaking with a US Gov colleague last week: his team is responsible for two Class B networks, on the order of 80,000 machines. Running that cycle every three days at that scale is an IT service management problem and a security problem in the same motion, on the same clock.

The broader shift in how vulnerability management now operates as a security function is covered in depth here: When Every Day Is Patch Tuesday.

Physics and Forensics

On any externally facing or possibly compromised system, memory capture comes before the patch. Rebooting to apply a patch destroys volatile evidence, and that evidence does not come back. The order of operations is set by how evidence decays. This is a new requirement — a hard constraint for sophisticated teams.

So the IR workflow has to be rewired. The patch team has to ask the vuln team, "Is this patchable right now?" before touching the box. If forensics is needed, patching is blocked until the evidence is collected. A supporting function that used to hand off reports now sits directly in the critical path of every remediation.

Prioritize by blast radius

Not every machine deserves the same care, and the difference is blast radius. A workable prioritization looks like a pyramid:

Critical services — DNS servers, Active Directory, core infrastructure.
Business applications — ERP, CRM, the systems of record the business runs on.
Executive workstations.
General endpoints.
Kiosks and low-sensitivity terminals.

Hard action is safe to take fast at the base. You can patch or isolate a kiosk and move on. Near the top, a wrong action breaks a service thousands of people depend on, or destroys evidence you were required to preserve.

There is an intrinsic rubric here: the higher up the stack, the more effort, more communication, more detailed analysis, more people, and more time it takes. The lower items are an immediate opportunity for automation and process compression. You can use those to get comfortable as you accelerate toward mission-critical systems.

The math says you need more capacity

Little's Law describes any queue: the work sitting in the system equals the arrival rate times the time each item spends in it (L = λW). The arrival rate of must-fix vulnerabilities is climbing, and Glasswing is a preview of the supply. The time each one spends in the system has a floor, and that floor has two parts: the forensic gate and human judgment. Hold capacity fixed, and the backlog grows. There is no way around the arithmetic.

You lower time-in-system with sharper prioritization and faster blast-radius reasoning. You raise capacity with people and tooling. Both are required. So the conclusion has to be that enterprises running this cycle will need more skilled people near the top of the stack, where the critical services live.

Fully autonomous remediation at the top of that pyramid is a ridiculous proposition today. There is no example in the natural world of a control system that acts correctly with no feedback and no constraints. Mistakes will be made. And running vulnerability management as a quarterly, supporting-role function is untenable once discovery runs at Glasswing scale. The work is to compress the cycle where compression is safe, and to put trained human judgment — armed with a tool that computes blast radius in seconds — where the radius is largest.

So now what?

We built Crogl because we want to serve the community. Useful and governed AI should be accessible to you when you want it. And you should be able to use it whenever, wherever, and however you want it. Download Crogl for free and test it for blast radius on any vulnerability you care about. Point it at a KEV and see what it tells you: exploitation status, what may already be exposed, and where that vulnerability lives across your machines. That is the analysis the three-day clock demands, and it is the analysis that lets you spend your people where they matter.

Then read Anthropic's Project Glasswing updates and CISA's Known Exploited Vulnerabilities directive, and size the clock you are now running against.

References

Project Glasswing — Anthropic
Project Glasswing, initial update (10,000+ vulnerabilities) — Anthropic
Assessing Claude Mythos Preview's cybersecurity capabilities — Anthropic
CISA Binding Operational Directive & Known Exploited Vulnerabilities Catalog
Little's Law (queueing theory) — first-principles reference for the compressed cycle.