FedRAMP's Vulnerability Detection & Response Requirements: A Runtime Security Guide

TL;DR

• FedRAMP's 2026 rules (BOD 26-04) demote CVSS from primary driver to a single signal, and require providers to evaluate vulnerabilities on operational risk: internet reachability, likely exploitability, KEV status, and more.
• Static scans and SBOMs can tell you what's in the box; they can't tell you which vulnerable functions are loaded, executed, or exposed in production, which is the kind of evidence FedRAMP now expects.
• Runtime observation closes that gap by continuously watching what applications actually do, and delivering definitive proof on whether application vulnerabilities are running and exploitable

Why FedRAMP's 2026 Changes Matter Beyond Compliance

When CISA released BOD 26-04 in June 2026, most of the attention went to the remediation timelines. But the timelines are really a side effect of something bigger: a change in how the federal government wants organizations to decide which vulnerabilities deserve attention in the first place.

FedRAMP compliance has long run on authenticated scans, monthly reporting, and remediation deadlines tied mostly to CVSS severity – logic that worked when applications were simpler and exploit times were measured in months. It strains today, because exploit times are now measured in hours, modern cloud applications are assembled from thousands of open source components and dynamically loaded libraries, and environments shift constantly.

Two applications can share the exact same CVE and carry completely different real-world risk. One might actively execute code and be exposed to the internet, while the other never loads that code path in production. CVSS can't tell those two cases apart, and neither can any type of scanner that isn’t observing code execution in real-time.

FedRAMP's Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules are built to close that gap, pushing vulnerability management toward observable, operational risk that is evaluated continuously, rather than focusing on theoretical risk assessed on a fixed schedule. For vulnerability management teams, this is arguably the biggest shift since CVSS became an industry staple.

What Actually Changed

FedRAMP's 2026 ruleset lays out six specific requirements that reshape how providers are expected to evaluate and act on vulnerabilities: 

• Continuous evaluation and flexible mitigation 
• Likely exploitability
• Internet reachability 
• A broader set of evaluation factors 
• Default assumption that exploits are automatable unless proven otherwise 
• Firm remediation timelines for Known Exploited Vulnerabilities (VDR-TFR-KEV).

As you can see, severity is still in the mix, but it's been demoted from primary driver to a single signal.

Why These Requirements Exist

In thinking about why these requirements exist, let’s run a hypothetical scenario that’s all too familiar to security teams. A scanner returns 5,000 vulnerabilities, engineering asks which ones actually matter, and security starts investigating manually.

The results find that some issues live in unused dependencies, some vulnerable functions are never called, some systems aren’t reachable from outside the network, and others sit behind compensating controls that may lessen the risk of a vulnerability. Out of 5,000 CVEs, maybe a fraction of those findings represent true operational risk.

The scanner wasn’t wrong – it was just never built to answer the question that matters most: does this vulnerability present real, exploitable risk in my environment, right now?

That's the question FedRAMP is now pushing organizations to answer with evidence, which is why vulnerability management is expanding from identification into actual evaluation.

Breaking Down the New Requirements

1. Internet Reachability

Providers need to be able to determine whether a vulnerability is reachable from the internet. Plenty sit behind authentication boundaries or live inside internal-only services that never touch an external request. Knowing which is which changes remediation priorities.

How Oligo helps: The platform pairs exposure analysis with runtime context, showing whether internet-facing applications are actually executing the vulnerable code paths in question. This closes the gap between exposure that's theoretical and exposure that's exploitable.

2. Evaluating Likely Exploitability

This one sounds incredibly simple until you try to answer it with the tools that teams use today. Most scanners can confirm a vulnerable package exists, but they cannot say whether it's loaded into memory, whether the vulnerable function executes, or whether the vulnerable code path ever fires. Answering that requires watching the application actually run.

How Oligo helps: Oligo determines exploitability by observing production behavior directly, and uses an enrichment pipeline built with NVIDIA Nemotron models for scale. That function-level visibility has surfaced 1,100% more vulnerable functions than commercial CVE advisories typically report, giving teams evidence of which vulnerabilities need attention now.

3. Weighing the Full Picture

FedRAMP doesn't want providers leaning on any single score, and instead expects evaluations to factor in criticality, reachability, exploitability, detectability, prevalence, privilege, and how a vulnerability relates to others already found. That's a lot to track through manual triage across thousands of findings.

How Oligo helps: Oligo brings several of those factors into one place automatically, showing what's reachable, what's actually running, and how a vulnerability relates to other findings in the same environment, so teams aren't reconstructing that picture manually for every CVE.

4. Assume Exploits Can Be Automated

FedRAMP flips the default here, requiring providers to assume an exploit can be automated unless they have evidence proving otherwise, representing a meaningfully higher bar than waiting to confirm automation exists.

How Oligo helps: Oligo gives teams the runtime evidence needed to responsibly rebut that default – proof a vulnerable function is never actually executed – instead of treating every finding as equally urgent.

5. Remediating Known Exploited Vulnerabilities (KEVs)

Providers must remediate KEVs on the timelines set by CISA's KEV catalog, regardless of whether a vulnerability has already been mitigated some other way, unless there's a valid technical reason not to.

How Oligo helps: Oligo enriches runtime analysis with CISA's KEV catalog and EPSS scores directly, so teams can immediately see which KEV-listed vulnerabilities are actually present and running in their environment. Moreover, instead of taking a closed ticket at face value, you get definitive proof that a vulnerability is no longer present because Oligo monitors code in real-time.

6. Continuous Vulnerability Response

Periodic authenticated scanning no longer cuts it on its own; vulnerabilities need continuous evaluation, since applications don't sit still. This one also gives providers flexibility: a vulnerability can be mitigated down to where it's no longer automatable or internet-reachable without requiring full remediation right away, as long as that mitigation is ongoing.

How Oligo helps: Oligo blocks exploit attempts and applies virtual patches at runtime, providing the continuous, active mitigation FedRAMP now accepts in place of immediate full remediation.

Why Runtime Security Fits Naturally Into the New FedRAMP Model

The common thread across every new VER requirement is context. FedRAMP wants providers to understand how vulnerabilities behave inside running production systems. The traditional ways of reporting, such as scanning static code in a repository and generating an SBOM, tells you what might be in the box, but it doesn’t tell you definitively what’s in the box or what it is doing right now. Runtime security fills that gap, observing code execution as it happens, which matters more every year as cloud-native applications grow more dynamic and dependent on third-party components.

Preparing for December 2026

Mandatory adoption of the new FedRAMP Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules take effect December 7, 2026 to align with CISA BOD 26-04. If you're pursuing or maintaining FedRAMP authorization, it's worth asking your team a few direct questions:

1. Can your tools distinguish vulnerable software that exists from vulnerable software that's actually executing?
2. Can they reassess exploitability continuously, or do they have to wait for a scan?
3. Can they combine runtime evidence with KEV data, EPSS, and additional risk factors? 
4. Can you produce defensible evidence for why one critical vulnerability needs remediation today while another can wait?

These questions increasingly define modern vulnerability management. FedRAMP just happens to be one of the first major frameworks to put that expectation into writing.

Finally, Oligo is on the pathway to FedRAMP High and DoD Impact Level 5 authorization. That means the platform is being built and operated to the same continuous monitoring, evidence, and control standards federal customers are now being asked to demonstrate under VDR and VER, so agencies and their contractors can adopt runtime evidence without inheriting a compliance gap in the tool that produces it.