If you’ve been paying attention to the vulnerability management landscape over the last several years, it has undergone a painful but long-needed evolution. Organizations continue to drown in vulnerability backlogs in the hundreds of thousands to millions of findings, with practitioners unsure where to begin, mainly due to legacy vulnerability management practices.

Slowly, we’ve seen the industry move towards context-rich vulnerability management methods, which account for known exploitation, exploitability, reachability, mitigations, and organizational context, such as business criticality and data sensitivity.

While several of these factors always should have been part of vulnerability management methodologies, and may have been for some outliers, most organizations have used mainly legacy practices, such as prioritizing vulnerabilities for remediations based on flawed approaches such as base CVSS scores. The problem with this, of course, is that it accounts for nothing I mentioned above, and doesn’t account for realities such as < 5% of CVEs in a given year are ever exploited, meaning the traditional base scoring approach to remediation is incredibly inefficient and ineffective, and diverts resources from real risks.

Most large compliance frameworks have yet to evolve with this reality, which is why it is so refreshing to see FedRAMP release RFC-0012 Continuous Vulnerability Management Standard, which we will examine in this article.

We also discussed this shift in detail during a recent livestream. If you’d prefer to hear the conversation between myself and Ron (VP Marketing, Endor Labs), you can watch it here:

For anyone who’s followed me for some time, you know that FedRAMP and Vulnerability Management are near and dear topics to me. In a previous life, I served as a Federal employee at the General Services Administration (GSA), the agency that leads the FedRAMP program. I’ve also helped many agencies and CSPs navigate FedRAMP requirements, including vulnerability management.

Additionally, I’m the coauthor of “Effective Vulnerability Management: Managing Risk in the Vulnerable Digital Ecosystem”.

For those looking to learn more about FedRAMP, I’ve written about it, including its challenges, extensively in other articles, such as:

• Dissecting the FedRAMP Authorization Act
• Modernizing FedRAMP

For those unfamiliar, the Federal Risk Authorization Management Program (aka FedRAMP) is a program the Federal government uses to securely adopt cloud services and offerings. It is oriented around NIST 800-53 and associated security control baselines (Low, Moderate, and High).

This means all cloud service offerings used by U.S. Federal agencies must adhere to FedRAMP and have FedRAMP authorizations. These requirements trickle into requirements for the U.S. Defense Industrial Base (DIB), software vendors, and commercial firms supporting U.S. Federal agencies, and state-level requirements (e.g., StateRAMP). To put it briefly, FedRAMP is far-reaching and is often viewed as one of the leading frameworks for cloud security and compliance.

With that out of the way, let’s examine this latest RFC and why the changes are both needed and valuable.

FedRAMP Continuous Vulnerability Management Standard

It’s worth noting that the new continuous vulnerability management standard isn’t finalized, but it is a strong indicator of where the program is headed. The FedRAMP PMO is currently accepting public comments and feedback.

FedRAMP provides a summary and motivation of the RFC as laid out below:

This standard’s intent is to ensure providers promptly detect and respond to critical vulnerabilities by considering the entire context over Common Vulnerability Scoring System (CVSS) risk scores alone, prioritizing realistically exploitable weaknesses, and encouraging automated vulnerability management. It also aims to facilitate the use of existing commercial tools for cloud service providers and reduce custom government-only reporting requirements.

The RFC provides many helpful additional information, such as definitions and terminology. Still, I won’t be diving into that here, as it is primarily helpful for folks unfamiliar with some of the terms used.

The RFC also lays out various requirements for ALL CSPs authorized under FedRAMP, such as:

• Establishing and maintaining programs to meet the requirements of the standard, including detecting, evaluating, reporting, mitigating, and remediating vulnerabilities
• Creating and maintaining vulnerability reports that provide sufficient metadata (e.g., CVE IDs, unique identifiers, exploitability assessment, potential impacts, etc.)
• Many other requirements, tied to KEV’s, vulnerability discovery, reporting, mitigations, and more.

I don’t want to belabor all of the new/proposed requirements, but instead focus on the new context FedRAMP is adding, which is long overdue, both for how FedRAMP approaches vulnerability management and how the industry approaches the practice. I’ll highlight some of them below.

First is the aspect of “Exploitability Assessment” in FRR-CV-02.

This is a loaded term because a lot can go into whether something is credibly exploitable. Still, some common aspects include if it’s known to be exploited, such as via CISA’s Known Exploited Vulnerability (KEV) catalog. Also, the rise in popularity of the Exploit Prediction Scoring System (EPSS) provides a score between 0 and 1 regarding how likely a vulnerability will be exploited in the next 30 days. Other factors include whether it is reachable (more to come on this later).

This may include whether it is Internet-accessible, whether a library is loaded, whether a function is called, or whether compensating controls in your architecture would make something unreachable and, therefore, unable to be exploited. 

Second is FRR-CVM-04

Here you see FedRAMP stressing that providers MUST adjust the risk and severity of vulnerabilities using not just CVSS but also context such as reachability and exploitability. Again, this is a long overdue change because less than 5% of CVEs annually ever see exploitation activity. When you adjust for factors such as reachability, that number drops even further. Accounting for these factors helps development and engineering focus on real risks to the organization, rather than just blindly trying to remediate “all the highs and criticals” when referring to CVSS base scores. 

This is an industry-wide change that is desperately needed and something the Endor Labs team has already been championing for years. Endor boasts robust reachability in our Software Composition Analysis (SCA) platform, looking into factors related to vulnerabilities such as:

• Is it in the production code?
• Is there a fix available
• Is the affected function reachable?
• Is there a high probability of an exploit (e.g., high EPSS score)

This is depicted well in what we dub the “Vulnerability Prioritization Funnel”, as seen below:

Vulnerability Response Times

FedRAMP’s new continuous vulnerability management guidance then lays out tentative vulnerability response timeframes. Many may view these as aggressive, especially given the massive vulnerability backlog, competing priorities for developers, limited bandwidth, concerns about disrupting production, and more. 

Some may say “just patch the findings” but any practitioner knows it isn’t that simple and the research demonstrates that reality. 

For example, Cyentia Institute found that 25% of vulnerabilities are remediated within the first 4 weeks, while half are remediated within the first 100 days, and nearly 25% of all vulnerabilities remain open after a year. 

To meet these sorts of SLA’s from FedRAMP, organizations need to lean into innovative approaches. For example, we’ve seen widespread adoption of Chainguard Images, which are minimal, zero-CVE images with industry-leading SLA’s, to try and minimize the cost of CVE’s, something I discussed in depth in a recent article titled “CVE Cost Conundrums”. 

Endor Labs also offers an offering dubbed “Endor Patches” aimed at helping organizations meet strict regulatory vulnerability remediation SLAs. It allows organizations to take the security fix from the latest version of an open source project and apply it to older versions they’re already using. This is incredibly helpful given organizations are often running open source dependencies that are multiple versions behind the version with the security fix, and upgrading may impact functionality and lead to breaking changes, leading to business disruption, or in other words, affecting the “A” in the CIA triad. 

As I discussed in my article “The 2025 Open Source Security Landscape”, 90% of codebases contain components that are more than 10 versions behind the most current version, so this problem is pervasive. It is due to factors such as organizations lacking the remediation capacity, or being reluctant due to the breaking changes I mentioned above. Endor Patches helps tackle this challenge directly. 

Leaning into offerings such as Endor Patches allows organizations to meet strict remediation timelines from their compliance requirements, such as FedRAMP, while minimizing operational impact on development and engineering and reducing organizational risks and disruptions.

Closing Thoughts

The FedRAMP Continuous Vulnerability Management RFC represents a systemic shift in how one of the industry’s leading compliance frameworks approaches AppSec and vulnerability management. It’s a pivot from legacy approaches and instead focuses on rich context of insights tied to exploitation, reachability and more.

However, to make this shift and meet the desired SLA’s, organizations will need to have comprehensive AppSec tooling capable of providing this context, which will also be a welcomed change for developers and engineering teams, who can instead focus on the ~8% of vulnerabilities that pose real organizational risks.