Anyone who has followed a satellite through its pass knows the feeling of a crowded sky: dozens of objects, each with a position, a speed and a question about whether it matters. Security teams live with a similar picture every day. Their sky is a list of known software flaws, it grows faster than it shrinks, and the list is only useful if someone decides what to look at first. That habit of running flaw handling as a continuous flow, rather than a quarterly clean-up, is what the industry has started calling VulnerabilityOps. This article treats it the way a mission controller would treat a worsening tracking problem: symptoms first, then causes, then a fix you can verify.
Symptom one: the catalogue only ever grows
The first sign that something is wrong is a backlog that rises month after month while the team insists it is working hard. Think of a ground station that logs more conjunction warnings each week than its operators can review. Nobody is lazy; the arithmetic simply does not close. The published numbers explain why. The public CVE Program listed 18,375 entries in 2020 and 48,244 in 2025, and the first half of 2026 alone added 35,872. An older benchmark study of roughly 300 organisations found that a typical one fixed about one in ten of its open flaws in a month, with the strongest performers managing around two and a half times that.
Put those two facts side by side and the diagnosis is immediate. If arrivals outrun closures, the pile grows no matter how heroic the effort. The remedy is not a bigger weekend sprint. It is to measure the ratio of arrivals to verified closures for each priority tier, and to treat anything above one as a standing alarm. A ratio below one means the tier is draining; above one means it is filling, whatever the dashboard colour says.
Symptom two: everything is labelled urgent
The second symptom is a triage rule that sends one huge group of findings to the top. Many teams still sort purely by the severity score attached to each flaw. The scoring body itself says a base score should not be used alone to judge risk, because it describes how bad a flaw could be, not whether anyone is actually using it. In orbital terms, it is like ranking every object by size and ignoring whether its path comes anywhere near your spacecraft.
A sturdier ordering uses three signals with a clear hierarchy. Evidence of real-world exploitation, as recorded in the government catalogue of known exploited flaws, comes first. A probability estimate, the exploit prediction score, comes second. Raw severity comes third. One warning attached to this hierarchy deserves emphasis: do not multiply the probability by the severity to get a single magic number. The scoring body has a name for that shortcut, “score laundering”, because it blends two different kinds of information into a figure that looks precise and means little.
Symptom three: tickets close, risk does not
The third symptom is the most dangerous because it looks like success. Closure rates are high, yet the same flaws turn up again at the next scan. Usually the cause is that “closed” means someone changed a ticket status. A mission team would never accept “burn executed” as proof of the new orbit; they would wait for fresh tracking data. The equivalent here is an authenticated rescan, a configuration test, a new image digest, or an upheld dispute. Only evidence like that should end a finding.
A well-known edge-device incident from 2023 shows why the definition of “fixed” matters. Applying the vendor update was not enough, because attackers who had already hijacked sessions stayed in place; the advice included terminating every active and persistent session as part of the fix. If your closure criteria do not mention such steps, your numbers will overstate your safety.
Where the Atlas places VulnerabilityOps
For a compact statement of the whole discipline, the Ops Atlas entry on VulnerabilityOps describes it as an emerging label rather than a formal standard, and frames it as tier, owner queue, verified closure and flow metrics in one loop. It is a useful map precisely because it does not pretend to be a product.
Cause analysis: why the sky looks crowded
Before prescribing anything, separate three root causes that often hide behind the same symptom.
- Inflow exceeds capacity. The rising public numbers above are real, and no team has an unlimited crew.
- Triage is blunt. A single score drives everything, so the truly time-critical items share a queue with thousands of near-irrelevant ones.
- Visibility is shaky. If scanners lose their credentials, they report fewer findings and the dashboard improves for the wrong reason. In one worked example from the Atlas material, 80 hosts silently dropped out of authenticated scanning after a key rotation, while the headline coverage still looked healthy at nearly 96 percent.
Each cause needs its own treatment. Capacity problems need flow metrics, triage problems need a policy, and visibility problems need an alert that fires when credentialed coverage slips.
The fix, step by step
1. Tag your assets by exposure first
A satellite operator knows which spacecraft are in crowded orbits and which are parked in quiet ones. Do the same with systems: mark what faces the public internet, what is internal, and what is operational equipment that cannot tolerate heavy probing. An untagged asset should be treated as public until proven otherwise, which makes the safe default also the lazy one.
2. Turn severity bands into clocks
In mid-2026 a US federal directive replaced severity bands with remediation clocks computed from four facts: whether the system is publicly exposed, whether the flaw is on the exploited list, whether exploitation can be automated, and how severe the technical impact would be. The shortest clock was three days, for a publicly exposed, listed, automatable, total-impact flaw, and it came with forensic triage. A publicly exposed flaw that is not listed and has only partial impact might get somewhere between 14 and 60 days. The directive binds only federal civilian agencies, but the pattern is portable, and unknown inputs get conservative defaults: unknown automation is treated as “no”, unknown impact as “total”.
3. Give every finding a dated owner
A warning without a named recipient is just noise. One famous breach investigation found that an alert had reached a stale distribution list. Keep the routing table as carefully as you keep the catalogue itself.
4. Close on evidence
Make verified closure the only way a finding leaves the queue. Remember that duplicates should be keyed on asset, flaw and component together, so that a rescan does not reset a clock and quietly erase the age of a stubborn issue.
5. Report flow, not just the pile
Pair every age statistic with the arrival-to-closure ratio. The Atlas material flags a trap: the 90th percentile of backlog age can fall from 30 weeks to 12 while the backlog itself grows by 25 items a week, because fresh arrivals dilute the old ones. Reporting age alone would have called that a win.
Related reading on this site
If you want grounding in how orbital regimes differ, the plain-spoken piece on geostationary orbit shows why a fixed position over one region changes everything about monitoring. For the busier end of the spectrum, a beginner’s tour of low Earth orbit explains why fast, crowded paths demand constant, automated attention, which is the same temperament a healthy flaw pipeline needs.
A thirty-day starting plan
Starting costs no budget line and no software purchase. In the first month, fill the gaps in your asset inventory, add exposure tags, match your inventory against the exploited-flaw catalogue every day, and record a baseline of arrivals, closures and credentialed coverage. In the second month, publish a first version of the clock policy, define what a hand-off record looks like and begin closing findings by rescan. By the third month, automate one high-volume class of fix and hold your first monthly flow review.
The sky will not get emptier. But a team that knows its arrival rate, orders its queue by evidence, assigns owners and demands proof of closure can keep pace with it, and can explain to anyone why a given item sits where it does.