📢 New post: From "What's the Score?" to "Assume It's Automatable": BOD 26-04 and FedRAMP's Answer · 📝 Also fresh: Three Bugs That Want to Be One: The UniFi OS KEV Chain and the Gear Nobody Scoped · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAVulnerability Management

From "What's the Score?" to "Assume It's Automatable": BOD 26-04 and FedRAMP's Answer

We've spent a run of posts watching the KEV clock start on a specific CVE — Langflow, LiteLLM, a PAN-OS box on the edge of a boundary. Each time the mechanics were the same: a vulnerability lands on CISA's catalog, it inherits a federal due date, and that date overrides the comfortable 30/90/180-day continuous-monitoring windows.

This month the windows themselves changed. CISA issued BOD 26-04, "Prioritizing Security Updates Based on Risk," and FedRAMP answered it on June 16 with NTC-0014. Together they rework the question continuous monitoring is supposed to answer — and the FedRAMP half adds one rule we've been turning over since we read it.

The old reflex, and why it stopped scaling

For years the operating motion looked like this: scan the environment, export a long list of CVEs, sort by CVSS, and start at the top. A 9.8 went before a 7.5. It was legible and auditable, and that was most of its appeal.

The trouble is that a CVSS score describes a vulnerability in a vacuum. It can't see that the 9.8 sits on an isolated internal host nobody can route to, while the 7.5 is on an internet-facing appliance that an off-the-shelf script can pop in one request. Sorted purely by score, you'd patch the theoretical problem first and leave the practical one for next sprint. We've all done it; the list told us to.

BOD 26-04 reframes the first question from "what is the score?" to something closer to "can this be used against us — from where, how fast, and to what effect?" It builds on the KEV model from BOD 22-01 and the asset-visibility requirements of BOD 23-01 rather than replacing them; KEV status becomes one strong signal among several, not the whole story.

Four questions, then a clock

The directive asks four things about each vulnerability:

  • Is the affected asset publicly exposed?
  • Can exploitation be fully automated?
  • Would successful exploitation grant complete control of the system?
  • Is there evidence it's being actively exploited?

The answers sort a finding into urgency bands rather than a numeric rank. The shape of them:

  • Three days, plus forensic triage — the worst case: publicly exposed, automatable, full system control, and actively exploited. All four lights red.
  • Three days — public exposure plus a KEV listing plus automatable, with partial control.
  • Fourteen days — various combinations that involve public exposure, KEV status, or automatable exploitation, short of the top tier.
  • Sixty days — lower-risk findings without public exposure or KEV listing.
  • Fix on the next system upgrade — the lowest band: not public, not on the KEV catalog, not automatable.

What we like about this is that it spends your remediation budget where the danger actually is. The same CVSS-7 can be a three-day fire drill on an exposed, automatable, KEV-listed front door and a fix-on-upgrade footnote on a segmented internal box. The score never moved; the context did all the work. That matches how incidents actually unfold, which is a nice thing to be able to say about a compliance requirement.

FedRAMP's answer — and the line that stuck with us

FedRAMP doesn't just point at the directive and call it done. NTC-0014 maps BOD 26-04 onto its Vulnerability Detection and Response framework and, in a few places, sets the bar higher. The new rules, in plain terms:

  • VER-EVA-EIR — Evaluate Internet-Reachability. Determine whether a vulnerability is actually reachable from the internet, which is a sharper test than the directive's general "publicly exposed."
  • VER-EVA-ELX — Evaluate Exploitability. Assess whether a finding is genuinely exploitable, accounting for KEV status and exploit automation.
  • VER-EVA-EFA — Evaluation Factors. Weigh supplementary factors beyond the directive's core criteria — criticality, prevalence, privilege gained, detectability.
  • VER-EVA-AIA — Assume It's Automatable. Assume an exploit is automatable by default, unless you have evidence it isn't.
  • VDR-TFR-KEV — Remediate KEVs on the BOD timelines, absent a valid technical reason.
  • VDR-CSO-RES — Vulnerability Response. Keep mitigating and remediating on an ongoing basis, with room for alternative approaches.

That fourth one — Assume It's Automatable — is the one we keep coming back to. BOD 26-04 asks whether exploitation can be automated. FedRAMP flips the burden of proof: presume it can, and make the provider produce evidence to argue otherwise. It's a small wording change with a large posture change behind it. The default is no longer "innocent until a working exploit shows up." The default is "treat it as weaponizable, and earn the right to relax."

We find that honest. By the time a public PoC has been packaged into something a botnet runs at scale, the gap between "theoretically exploitable" and "automated and everywhere" is days, sometimes hours. Assuming automation by default isn't pessimism; it's just refusing to bet against a trend that has been remarkably consistent.

There's a calendar attached, too. NTC-0014 was published June 16, with the rules effective December 7, 2026 — the date by which agencies and FedRAMP cloud providers are expected to be evaluating and remediating under this model. Providers who haven't adopted by then face certification revocation after a March 7, 2027 grace period. So this is a "start the migration now" item, not a "read it later" one.

What it asks of how you actually run things

The interesting part isn't the rule text; it's what the rules quietly assume about your operation. Risk-based prioritization only works if you can answer the four questions per asset, on demand — and most environments can't, not quickly. FedRAMP's VDR framing is explicit that this means persistent discovery and continuous monitoring, evaluated in the context of the cloud service offering — exploitability, internet-reachability, adverse impact, criticality, prevalence, privilege gained, detectability — rather than a quarterly scan you reconcile by hand.

Sit with what that requires the morning a vulnerability lands:

  • Is it in our inventory, and where does it sit? "Publicly exposed?" is unanswerable if the asset isn't on a list, or if the list is a spreadsheet from last quarter. This is the BOD 23-01 visibility dependency made concrete — you can't prioritize what you can't see.
  • Is it reachable from outside, right now? Not "was it designed to be internal," but what ingress and routing actually allow today. That's a live question about configuration, not an architecture diagram.
  • Can we show it isn't automatable? Under VER-EVA-AIA the absence of evidence isn't a defense. If you want the longer timeline, you need the artifact that justifies it.
  • Where's the trail? As ever, the thing that survives the next assessment is the evidence — the reachability determination, the automation rationale, the remediation ticket, the timeline you actually hit.

None of that is exotic. It's the same unglamorous capability we keep landing on: an inventory that answers in seconds, context attached to each asset, evidence that collects itself as a normal byproduct of operating. BOD 26-04 didn't invent the need for it — it just made the lack of it more expensive, because now the prioritization depends on data most teams gather reactively.

Where we've landed

We read BOD 26-04 as a good change, and an overdue one. Sorting a vulnerability list by a context-free number was never how attackers picked their targets, so it was never a great way to pick our defenses either. Asking "exposed, automatable, controlling, exploited?" is closer to the real conversation. And FedRAMP's "assume it's automatable" default is the kind of small, honest line that quietly raises the floor for everyone who has to comply with it.

It's also squarely the shape of work we've been building the Novaprospect audit engine toward — infrastructure-native discovery that knows which assets are actually reachable, context carried alongside each finding so the four questions answer themselves, and the evidence for why something got a 3-day clock or a 60-day one captured as it happens rather than reconstructed before an assessment. When the prioritization itself depends on knowing your environment in real time, the inventory stops being paperwork and starts being the control.

Reference