RFC-0012 FedRAMP Continuous Vulnerability Management Standard

[pete-gov]

RFC-0012 Continuous Vulnerability Management Standard

Note: FedRAMP requirements documents use RFC 2119 key words to indicate requirement levels.

RFC Front Matter

Due to the nature of this RFC, FedRAMP will be hosting two public events and public informal discussions in the FedRAMP Community about this RFC. General questions are encouraged in these public discussions to sharpen and focus public comment but the public must submit formal public comments for official consideration during the comment period.

• Status: Closed
• Created By: FedRAMP
• Start Date: 2025-07-15
• Closing Date: 2025-08-21
• Short Name: rfc-0012-vulnerability-management

In addition to this markdown, this RFC is available in the following formats:

• PDF file: 0012-vulnerability-management.pdf
• Word file: 0012-vulnerability-management.docx

Where to Comment

Members of the public may submit multiple different comments on different issues during the public comment period. The public is asked to please refrain from including documents or spreadsheets (especially those with in-line comments or suggested changes) in public comment as this creates a significant additional review burden.

Formal public comment for official consideration by FedRAMP can be made via the following mechanisms in order of preference:

1. GitHub Post: RFC-0012 FedRAMP Continuous Vulnerability Management Standard #59
2. Public Comment Form: https://forms.gle/adWgLmR9a4d7vMBW6
3. Email: pete@fedramp.gov with the subject "RFC-0012 Feedback"

Note: FedRAMP will review and publicly post all public comments received via email, but will not otherwise respond. Email submissions from federal agencies will not be made public unless requested.

Summary & Motivation

This proposed Continuous Vulnerability Management Standard indicates an intended direction from FedRAMP and is not expected to be finalized in its exact current form. Once the RFC phase is completed, a modified version informed by public comment will be tested and evaluated with volunteer cloud service providers during a 20x Pilot and Rev5 Beta Tests then routinely refined and improved. FedRAMP now works with the community to understand the impact of its policies and adjust them based on real world experiences.

This RFC builds on stakeholder feedback to FedRAMP’s recent RFC-0008 Continuous Reporting Standard and incorporates previous plans to update the Continuous Monitoring Performance Management Guide for 20x.

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.

This standard implements changes in FedRAMP policy to meet this intent by:

• Defining new plain-language terms to move away from some commonly used but confusing language
• Including all weaknesses in the definition of a vulnerability
• Encouraging urgent mitigation of vulnerabilities prior to remediation
• Establishing requirements for assessing the context of vulnerabilities to determine impact and urgency
• Directly defining potential adverse impact levels
• Prioritizing the discovery, mitigation, and remediation of vulnerabilities in internet-reachable resources
• Setting expectations for continuous assessment, detection, and response where feasible with specific worst-case timelines for vulnerability management
• Requiring POA&Ms only when providers won’t respond within the recommended timelines

Reviewers are advised to read through the entire document for the full context and are reminded that FedRAMP 20x definitions for all standards apply to terms in this document; these terms are italicized when referenced.

Effective Date(s) & Overall Applicability

This is a draft standard released for public comment; it does not apply to any FedRAMP authorization and MUST NOT be used in draft form.

• FedRAMP 20x:
  • This standard will initially apply to all FedRAMP 20x authorizations when formalized.
• FedRAMP Rev5:
  • See Balancing FedRAMP Rev5 against improvements to FedRAMP 20x for general information how improved FedRAMP standards will be applied carefully and deliberately to Rev5 authorizations.

Background & Authority

OMB Circular A-130: Managing Information as a Strategic Resource defines continuous monitoring as “maintaining ongoing awareness of information security, vulnerabilities, threats, and incidents to support agency risk management decisions.”

The FedRAMP Authorization Act (44 USC § 3609 (a) (7)) directs the Administrator of the General Services Administration to “coordinate with the FedRAMP Board, the Director of the Cybersecurity and Infrastructure Security Agency, and other entities identified by the Administrator, with the concurrence of the Director and the Secretary, to establish and regularly update a framework for continuous monitoring…”

Purpose

The FedRAMP Continuous Vulnerability Management Standard ensures FedRAMP Authorized cloud service offerings use automated systems to effectively and continuously identify, analyze, prioritize, mitigate, and remediate vulnerabilities and related exposures to threats; and that information related to these activities are effectively and continuously reported to federal agencies for the purposes of ongoing authorization.

Expected Outcomes

• Cloud service providers following commercial security best practices will be able to meet and validate FedRAMP security requirements with simple changes and automated capabilities
• Third-party independent assessors will have a simpler framework to assess security and implementation decisions that includes consideration of engineering decisions in context
• Federal agencies will be able to easily, quickly, and effectively review and consume security information about the service to make informed risk-based authorizations based on their use case

---

Definitions

FRD-CVM-01

Vulnerability: Has the meaning given in NIST FIPS 200, which is “weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.”

Note: See also the meaning given to “security vulnerability” in 6 USC § 650 (25), which is “any attribute of hardware, software, process, or procedure that could enable or facilitate the defeat of [...] management, operational, and technical controls used to protect against an unauthorized effort to adversely affect the confidentiality, integrity, and availability of an information system or its information.” This includes software vulnerabilities, misconfigurations, exposures, weak credentials, insecure services, and other weaknesses.

Reference: https://csrc.nist.gov/pubs/fips/200/final
Reference: https://www.govinfo.gov/app/details/USCODE-2024-title6/USCODE-2024-title6-chap1-subchapXVIII-sec650

FRD-CVM-02

Credibly exploitable vulnerability: A vulnerability where a likely threat actor with knowledge of the vulnerability would likely be able to gain unauthorized access, cause harm, disrupt operations, or otherwise have an undesired adverse impact; vulnerabilities must be reachable and not fully mitigated to be credibly exploitable.

FRD-CVM-03

Remediate: Permanently remove a vulnerability; remediated vulnerabilities are not exploitable and no longer appear in scans or other analyses.

Note: See also the meaning given to “remediation” in NIST SP 800-216, which is “the neutralization or elimination of a vulnerability or the likelihood of its exploitation.”

Reference: https://csrc.nist.gov/pubs/sp/800/216/final

FRD-CVM-04

Mitigate: Temporarily reduce the risk that a vulnerability will be exploited or the potential adverse impact if it is exploited; mitigated vulnerabilities still appear in assessments until they are remediated.

Note: See also the meaning given to “mitigation” in NIST SP 800-216, which is “the temporary reduction or lessening of the adverse impact of a vulnerability or the likelihood of its exploitation.”

Reference: https://csrc.nist.gov/pubs/sp/800/216/final

FRD-CVM-05

Fully Mitigate: Mitigate a vulnerability to the point where there is no reasonable probability of exploitation by any reasonable threat source, or the potential adverse impact of exploitation is Very Low; fully mitigated vulnerabilities still appear in assessments until they are remediated.

FRD-CVM-06

False Positive: Has the meaning given in NIST SP 800-115, which is “an alert that incorrectly indicates that a vulnerability is present.”

Reference: https://csrc.nist.gov/pubs/sp/800/115/final

FRD-CVM-07

Internet-reachable: Information resources that are reachable over the public internet such that anyone with an internet connection can interact with or deliver payloads to the information resource.

Note: This includes information resources that have no direct route to the internet but receive or process information or other payloads triggered by internet activity such as some logging services, some application services that process data submitted from internet-facing services, etc.

FRD-CVM-08

Known Exploited Vulnerability: Has the meaning given in CISA BOD 22-01, which is any vulnerability identified in CISA’s Known Exploited Vulnerabilities catalog.

Reference: https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
Reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

FRD-CVM-09

Potential adverse impact (of vulnerability exploitation): The estimated effect of unauthorized access, disruption, harm, or other adverse impact to federal information that is likely to be caused by a threat actor exploiting a vulnerability. FedRAMP uses the five qualitative values described in NIST SP 800-30 Appendix H, which are:

1. Very High: Exploitation could be expected to have multiple severe or catastrophic adverse effects.

2. High: Exploitation could be expected to have a severe or catastrophic adverse effect. A severe or catastrophic adverse effect means that, for example, the threat event might: (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life-threatening injuries.

3. Moderate: Exploitation could be expected to have a serious adverse effect. A serious adverse effect means that, for example, the threat event might: (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life-threatening injuries.

4. Low: Exploitation could be expected to have a limited adverse effect. A limited adverse effect means that, for example, the threat event might: (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.

5. Very Low: Exploitation could be expected to have a negligible adverse effect. Note: See also NIST FIPS 199 for additional background on measuring Potential Impact on Organizations and Individuals. Reference: https://csrc.nist.gov/pubs/sp/800/30/r1/final
   Reference: https://csrc.nist.gov/pubs/fips/199/final

FRD-CVM-10

Promptly: As quickly as possible and without unnecessary delay.

Requirements

FRR-CVM

These requirements apply ALWAYS to ALL FedRAMP Authorized cloud services based on the current Effective Date(s) and Overall Applicability of this standard.

FRR-CVM-01

Providers MUST establish and maintain programs that meet the requirements and timeframes in this standard to detect, evaluate, report, mitigate, and remediate vulnerabilities; these requirements supplement controls in FedRAMP Rev5 Baselines and Key Security Indicators in FedRAMP 20x.

Note: FedRAMP recommends that providers reference CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) methodology and CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks.

Reference: https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
Reference: https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks

FRR-CVM-02

Providers MUST create and maintain vulnerability reports showing vulnerability management activity that include at least the following information about all detected vulnerabilities within the FedRAMP Authorized cloud service offering:

1. Provider’s internal unique identifier for the vulnerability or grouping of similar vulnerabilities
2. Relevant Common Vulnerabilities and Exposures (CVE) ID(s) and/or similar public identifiers
3. Timeline (including at least time frames for detection, mitigation, and remediation)
4. Internet-reachable status of affected resources
5. Exploitability assessment (is it credibly exploitable?)
6. Potential adverse impact assessment
7. Mitigation and/or remediation plan (including any customer responsibilities)
8. Mitigation and/or remediation measures taken (including any customer responsibilities)
9. Changelog or other record of updates
10. Point of contact for additional information

Note: This information SHOULD be limited to a minimum level of detail required (see FRR-CVM-07).

FRR-CVM-03

Providers MUST make vulnerability reports available to all necessary parties in similar human-readable and compatible machine-readable formats, including at least FedRAMP, CISA, and all agency customers.

FRR-CVM-04

Providers MUST adjust the risk and severity of vulnerabilities using CVSS base scores (if applicable) AND the context of the vulnerability, factoring for at least criticality, reachability, exploitability, detectability, prevalence, and mitigation, to determine if vulnerabilities are credibly exploitable and the potential adverse impact of exploitation.

FRR-CVM-05

Providers SHOULD mitigate and/or remediate vulnerabilities promptly, within the time frames established in FRR-CVM-TM, and MUST create a FedRAMP Plan of Action & Milestones (or future equivalent) to address any vulnerabilities that will not be addressed within those time frames.

FRR-CVM-06

Providers SHOULD use automated systems to identify, mitigate, and/or remediate credibly exploitable vulnerabilities in internet-reachable information resources with minimal or no human intervention.

FRR-CVM-07

Providers SHOULD NOT share specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST share sufficient information about vulnerabilities for oversight, tracking, analysis, action, and risk assessment with all necessary parties.

FRR-CVM-08

Providers SHOULD maintain records of all false positive vulnerabilities and exclude validated false positive vulnerabilities from vulnerability reports.

FRR-CVM-09

Providers SHOULD group similar vulnerabilities detected across different resources together for tracking, action, and reporting; these groups MUST use sensible provider-defined shared characteristics such as (but not limited to) common root cause, affected component, or remediation strategy.

FRR-CVM-TM

These requirements identify specific time frame-based goals related to continuous vulnerability management.

FRR-CVM-TM-01

Providers MUST provide up-to-date vulnerability reports to all necessary parties at least monthly and SHOULD provide these continuously.

FRR-CVM-TM-02

Providers MUST make historical vulnerability reports covering at least the preceding 24 months available to all necessary parties.

FRR-CVM-TM-03

Providers SHOULD remediate Known Exploited Vulnerabilities according to the due dates in the CISA Known Exploited Vulnerabilities Catalog (even if the vulnerability has been fully mitigated).

Reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

FRR-CVM-TM-04

Providers SHOULD discover, analyze, and assess all internet-reachable resources for vulnerabilities using both authenticated and unauthenticated assessments continuously, otherwise at regular intervals at least every three calendar days.

FRR-CVM-TM-05

Providers SHOULD fully mitigate or remediate credibly exploitable vulnerabilities in internet-reachable resources promptly, within three calendar days of detection.

FRR-CVM-TM-06

Providers SHOULD discover, analyze, and assess all resources that are NOT internet-reachable for vulnerabilities using both authenticated and unauthenticated assessments continuously, otherwise at regular intervals at least once every seven calendar days for unauthenticated assessments and at least once every month for authenticated assessments.

FRR-CVM-TM-07

Providers SHOULD mitigate or remediate credibly exploitable vulnerabilities in resources that are NOT internet-reachable promptly, within seven calendar days of detection, until or unless the potential adverse impact is Low or Very Low.

FRR-CVM-TM-08

Providers SHOULD mitigate or remediate credibly exploitable impact vulnerabilities in resources that are NOT internet-reachable promptly, within 21 calendar days of detection until or unless the potential adverse impact is Very Low.

FRR-CVM-TM-09

Providers MUST fully mitigate or remediate all remaining detected vulnerabilities on a regular basis promptly, at least every six months.

Quick Reference - Vulnerability Response Time Frames:

Applies to	Reachability	Impact	Action	Max Time
Credibly exploitable vulnerabilities	Internet-reachable	Very High, High, Moderate, Low	Fully mitigate or remediate	3 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Very High, High, Moderate	Mitigate to Low or remediate	7 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Low	Fully mitigate or remediate	21 Days
All detected vulnerabilities	Both	All	Fully mitigate or remediate	6 Months

Quick Reference - Discovery and Analysis Time Frames:

Assessment Type	Target Resources	Assess At Least
Authenticated	Internet-reachable	Every 3 days
Unauthenticated	Internet-reachable	Every 3 days
Unauthenticated	Not internet-reachable	Every 7 days
Authenticated	Not internet-reachable	Every 1 month

FRR-CVM-AY

These requirements provide guidance on the application of this standard.

FRR-CVM-AY-01

Providers MAY share vulnerability reports publicly or with other parties when doing so will not have a likely impact on the confidentiality, integrity, or availability of federal information.

FRR-CVM-AY-02

Providers MAY provide additional security relevant metrics in their reporting as they deem appropriate.

FRR-CVM-AY-03

All parties SHOULD follow FedRAMP’s best practices and technical assistance on continuous vulnerability management and vulnerability reporting where applicable.

FRR-CVM-EX

These exceptions MAY override FedRAMP requirements for this standard.

FRR-CVM-EX-01

Providers MAY be required to share additional vulnerability information, alternative reports, or to report at an alternative frequency as a condition of a FedRAMP Corrective Action Plan or other agreements with federal agencies.

FRR-CVM-EX-02

Providers MAY be required to provide additional information or details about vulnerabilities, including sensitive information that would likely lead to exploitation, as part of review, response or investigation by necessary parties; providers MUST NOT use this standard to reject requests for additional information from necessary parties which also includes law enforcement, Congress, and Inspectors General.

[pete-gov]

Please Note

This thread is for formal, public comment only; commenters may respond to each others comments, however FedRAMP's participation in this thread is limited and general Q&A and casual discussion intermixed in formal public comment creates complications.

For casual discussion about this RFC prior, during, or after public comment, please use this thread in the General RFC Discussion category: Q&A on RFC-0012 and casual open discussion

---

Added 2025-08-06:

For public awareness, the primary purpose of public comment is for FedRAMP to receive information and opinions by giving "interested persons an opportunity to participate in the rule making through submission of written data, views, or arguments" (per the Administrative Procedures Act).

FedRAMP does not respond to questions in public comments and they are the most difficult form of public comment to consider because the commenter's view, argument, or opinion can only be inferred. In most cases, FedRAMP is forced to interpret questions as simply a single opinion that FedRAMP should provide an answer to the question in final guidance or directives.

As an additional notice for public awareness, FedRAMP reiterates that members of the public may submit multiple comments during the public comment period.

[iteuscher]

Comments on RFC‑0012: Continuous Vulnerability Management Standard

1. Authenticated vs Unauthenticated Assessments (FRR‑CVM‑TM‑04, TM‑06)

The RFC (FRR-CVM-TM-04 and TM-06) references authenticated and unauthenticated assessments but doesn’t define what “authenticated” means for containerized, serverless, or managed compute where traditional credential-based access doesn’t exist. While the authenticated/unauthenticated distinction has been historically meaningful for credential-based access in VM-based systems (e.g., SSH or WMI), it becomes ambiguous in cloud-native architectures where ephemeral containers, immutable infrastructure, and serverless functions often lack persistent credentials or interactive access paths. In many cases, enabling that kind of access (e.g., SSH into containers) introduces unnecessary risk by increasing the attack surface, violating least privilege, and deviating from secure design principles.

For example, during a recent FedRAMP High review, we went back and forth with our auditors on RA-5 and RA-5(5) because they wanted to see credentialed scans of all components, including our containers. Our containers, by design, have no SSH keys or other login methods for a vulnerability scanner to perform an authenticated scan and opening that access would increase our attack surface. Instead, we use vulnerability scanning agents in the cluster, CI/CD-integrated image scans, and runtime monitoring, which meet the same intent but aren’t “authenticated” scans in the traditional sense. There is value in dividing the assessment types based on the level of access they have to the compute environment (OS, VM, container, etc) but using the authenticated/unauthenticated language is potentially confusing as compute continues to move away from traditional server/VM host based systems that have credentials and can provide “authenticated” access.

Recommendation: FedRAMP should consider rewording the authenticated vs. unauthenticated terminology or provide additional guidance that recognizes modern container/serverless scanning practices (e.g., build-time image scanning, agent-based runtime scanning, etc) as valid approaches. This would prevent misunderstandings, reduce pressure to adopt outdated practices, and better reflect cloud-native security best practices to future-proof the new standard.

Note: this also applies to the 20x KSI-MLA-04 "Perform authenticated vulnerability scanning on publicly accessible components”

FRR‑CVM‑TM‑04, TM‑06 "using both authenticated and unauthenticated assessments"

2. Credibly Exploitable Vulnerabilities (FRR-CVM-02)

The focus on credibly exploitable vulnerabilities supports good risk management practice by moving past CVSS base scores and incorporating reachability, exploitability, etc.

Recommendation: Keep the focus on which vulns are credibly exploitable in the CSP's environment not just which vulns have been exploited (e.g. KEVs) since the same vulnerability may be exploitable in one environment but not in another due to the architecture or defense in depth.

FRR-CVM-02 5. Exploitability assessment (is it credibly exploitable?)

3. Fast Response Time Frames (FRR‑CVM‑TM‑05)

Requiring three calendar days to fully mitigate or remediate credibly exploitable, internet‑reachable vulnerabilities will likely frustrate GRC and cyber teams during long U.S. holiday weekends. That said, historically significant incidents (e.g., Kaseya VSA – July 4, 2021; MOVEit MFT – Memorial Day 2023) have occurred during these windows, so the rationale is understandable. Perhaps the time frames can be adjusted based on FedRAMP Level (Low, Mod, High) so that a FedRAMP High service has tighter requirements than a FedRAMP Low offering. The three calendar days requirement for Low/Mod might disincentivize SMBs from pursuing FedRAMP authorization due to lack of Human Resources to respond within those timelines (or the high cost of using a MSP to cover this requirement).

Recommendation: Consider tight timelines (e.g. 3 calendar days) for FedRAMP High with slightly longer timelines for Moderate and Low authorization levels.

FRR-CVM-TM-05 “Providers SHOULD fully mitigate or remediate credibly exploitable vulnerabilities in internet-reachable resources promptly, within three calendar days of detection.”

4. Monthly Minimum, Continuous Ideal (FRR‑CVM‑TM‑01)

Requiring monthly reports at minimum while clearly signaling “continuous” as the goal is a pragmatic bridge from Rev5 to 20x. This gives agencies a minimum requirement bar while encouraging CSPs to use automation for parsing vuln scans and managing POA&M reporting.

Recommendation: Require a machine‑readable format (e.g. SARIF, JSON schema) for continuous feeds, while allowing human-readable summaries for monthly reporting. This will facilitate automated ingestion by agencies and improve comparability while retaining the Rev5 monthly reporting cadence as the minimum bar.


FRR-CVM-TM-01 “MUST… at least monthly and SHOULD provide these continuously.”

5. 24 Months of Historical Reports (FRR‑CVM‑TM‑02)

“Historical vulnerability reports covering at least the preceding 24 months” would benefit from more clarity on how this should be presented. Is this a trend graph? Details of every vulnerability? I assume that an agency will want to see a summary/graph of this historical data for it to be useful but clarity on whether the CSP should present that (e.g., a trend graph in their trust center) or if the CSP gives the raw data and the agency parses and graphs would be helpful.

Recommendation: Add clarity on the required depth (all records vs. summarized statistics), format (raw vs. aggregated), and visual expectations (e.g., trend graphs, MTTR/MTTM distributions, SLA adherence) for historical reports. Potentially specify minimum historical metrics and visualizations (e.g., mean/median/95th percentile time-to-mitigate by reachability & impact, KEV closure timeliness, % false positives, vulnerability backlog trend) and allow providers to host the full data in trust centers while providing agencies with both machine-readable data and human-readable summary.

FRR-CVM-TM-02 “Providers MUST make historical vulnerability reports covering at least the preceding 24 months available…”

6. Internet‑Reachable Definition (FRD‑CVM‑07)

Separating internet‑reachable from non‑internet‑reachable resources is smart and helpful. The current Note is good, but practical edge cases will arise (e.g., assets reachable via restricted IP allowlists, reachable by VPC private endpoints, API layered behind load balancer, etc). The concept is understood and appreciated but adding even more details to the definition of internet reachable will help reduce future Q&A, loopholes, and “gaming” of the requirements.


Recommendation: Improve the definition of internet‑reachable by adding decision criteria and examples for common “edge-cases” such as: internet access only via content delivery, API gateways, VPC private endpoint, etc.

FRD-CVM-07 “Internet-reachable”

7. POA&Ms as Exceptions (FRR‑CVM‑05)

Setting POA&Ms as deviations from recommended timelines instead of normal vuln management within the timelines is the right move. The language in FRR-CVM-05 that POA&Ms are required “only when providers won’t respond within the recommended timelines” is appreciated and should be kept. This will reduce noise by separating routine, timely remediation from true schedule/priority exceptions.

Recommendation: Keep this adjustment to the function of POA&Ms as it stands in the RFC.

FRR-CVM-05 “…create a FedRAMP Plan of Action & Milestones (or future equivalent) to address any vulnerabilities that will not be addressed within those time frames.”

Closing

Overall, this RFC is a positive step toward risk-based, automation-first vulnerability management. Paramify is excited to see the FedRAMP PMO’s continued push to maximizing the use of automation for risk management activities such as evidence collection, authorization documentation, and now vulnerability management and reporting. Paramify fully supports the direction and vision of this RFC.

-- Isaac Teuscher - Paramify

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I agree that this RFC is overall positive and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

1. I think this "gap" can be easily covered by CSP discretion for what makes "sense". Personally I don't see it is as a gap. Some products (appliances etc) can't be scanned with authentication, and vice versa. Realistically, if we do unauthenticated network scans of all the resources/networks that containers run on, thats the unauthenticated scan, and then the authenticated one is the container scanning and/or the authenticated scanning of the node itself (if thats available to you, as the CSP, as its not with some providers using serverless). Personally, I think the discretion here allows the program to grow as new technologies emerge and aligns with the programs intent to allow CSPs to "create" better and provide federal agencies with the latest and greatest in the most efficient way. As new technologies emerge, having strict standards often means we are all only focused on the square peg & round hole, rather than focusing on what makes actual sense for true security.
2. Agree, I love the move away from CVSS Scores. So ➕ on that.
3. In looking at the intent of these timelines these don't scare me. Credibly exploitable vulnerabilities in our CSP environments are rare, and the focus of this standard is clear that the first action considered should be to mitigate. Remediation is always a preference, but not always practical (patches don't always exist etc). So the way we are looking at things, these vulnerabilities will basically trigger alarms that get on-call support when in off hours. The FIRST thing that should be done is evaluate its true exploitability, even with internal knowledge. If that proves that this is actually not exploitable with current information, then this is no longer credible exploitable, and adjust the vulnerability appropriately, and can all go home to resume "normal" vulnerability operations. Assuming we do find that it is credible exploitable through manual methods as well, the second actions we will be looking at are the quick wins to mitigate the likelihood of exploitability. That COULD be full remediation, but could also be a specific WAF rule, a relatively quick/safe application change etc. As I mentioned, this may not remediation, but it mitigates to, again, no longer being credibly exploitable and no longer requires the 3/7/21 days. We have every intention of full remediation "quickly" - but to align with safe release practices and such, that may be 2-4 weeks, which is fine if the issue is not credibly exploitable anymore.
4. Personally, I don't think there should be specific machine-readable requirements coming from FedRAMP right now. The program has made clear that centralized systems to recieve/review vulnerabilities are on the way out. Until something is centralized and mandated, I think its more flexible with CSP engineering teams to be able to get the data "however" their systems produce it now, so we can all start collaborating on whats specifically working and not working.
5. Personally, I prefer not to have specificity here. Rather than retaining 2 years worth of "continuous reports" in an actual versioned format, some of us would prefer to just have a realtime changelog on each item. And some may prefer the former. Either way, the same information is retained. But the former, on a true "continuous" reporting mechanism is unreasonable and more difficult to parse, but might be more possible for some CSPs than others.
6. As repeated previously, I think not having so many "specifics" from FedRAMP is a good thing. It enables us to have more thoughtful conversations about actual security risk, rather than just checking boxes. Private VPC endpoints are sometimes exposed directly to the internet, but not always. Allowing CSPs to put their true context into their systems is best. I read the intent of FedRAMP 20x to encourage more thoughtful conversations about risk between agencies and CSPs, rather than check-box compliance. Asking FedRAMP to provide edge cases and decision criteria removes a CSPs ability to provide their own context that the program might not be able to conceive today.
7. Agreed, though admittedly, many CSPs are already doing this as endorsed by several agencies and the PMO for Rev5 practices.

[pete-gov]

Public comment received via email from Autodesk, reproduced in entirety here (note that FedRAMP can't respond to public comments during the public comment period):

---

Happy Friday!! I’ve reviewed RFC-0012: Continuous Vulnerability Management Standard, and I appreciate the intent to modernize and improve risk-based vulnerability management for CSPs and agencies. I wanted to offer a few questions and comments that may help clarify the implementation path for providers like us:

Clarification Questions:

Dashboard Requirements:
Could FedRAMP provide more detailed guidance on what qualifies as an acceptable continuous monitoring dashboard?

Specifically:

Are there preferred platforms or formats (e.g., API endpoints, CSV reports, hosted portals)?
Will FedRAMP release a standard schema or minimum data fields to ensure consistency and interoperability?

Vulnerability Prioritization:

How should CSPs balance CVSS scores, exploitability indicators (e.g., EPSS, KEV), and asset exposure when prioritizing vulnerabilities? Will there be a recommended scoring methodology or risk framework?

Use of POA&Ms:

Under what conditions can CSPs still utilize a POA&M for delayed remediation? Will FedRAMP publish examples or thresholds for what constitutes valid justification for POA&M use under the updated model?

Tool Compatibility and Validation:

Is FedRAMP planning to approve or recommend specific vulnerability scanning tools that support the automation and reporting requirements in RFC-0012? Will there be a tool validation process CSPs must follow?

Transition Timeline:

Can FedRAMP clarify the transition plan and expected timeline for replacing monthly ConMon reports with real-time dashboards? Will CSPs be allowed a phased implementation period?

Comments:

Recommend FedRAMP consider providing a standardized dashboard template or data schema to streamline implementation for CSPs and reduce variance for agency consumers.

These changes may increase complexity for smaller CSPs. It may help to publish baseline tooling recommendations or sample dashboards to ease the compliance burden.

Guidance for federal agencies on how to consume and interpret the new real-time data would be beneficial to ensure alignment between CSPs and agency partners.

Lastly, we would be interested in participating in a pilot or early adopter program for RFC-0012 implementation if such opportunities become available.

Thank you for your continued work in modernizing FedRAMP and promoting scalable, risk-based compliance. I look forward to any additional resources or clarifications you may be able to provide.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

1. Dashboard Requirements - From my take, FedRAMP is asking industry to create these and present them so we can start to develop this. This allows CSPs to create what makes sense "for them." I've already seen plans to collaborate with 3rd party providers to provide one with the data from my vulnerability management program that we feed into it, since creating dashboards of security information for agencies is not a part of every CSP's business.
2. Vulnerability Prioritization - Personally, I love that this allows CSPs to come up with the formulas for evaluation and allows them to grow as new intelligence and feeds come available to enhance this information. So right now as a CSP, we're working on the things that make sense for us right now with the automated information we have access to.
3. Use of POA&Ms - From my read of the RFC, a POA&M doesn't specify what conditions are "okay" to add something to the POA&M. The justification is simply that its past the SLA. WHY that is past the SLA is for CSPs to communicate to agencies, and for agencies to review as to why and make sure that specific instance of a past-SLA vulnerability is reasonable enough to continue utilizing that CSP in the aggregate with the whole program. Requesting that government agencies specify the only reasons why something is allowed to go past their SLA removes nuance and actual security decisions. From what I can tell in this RFC, the intention is that traditional "POA&Ms" by CSPs are MUCH fewer than current POA&M practices, and instead are a true list of valid risks.
4. Tool Compatibility and Validation - For what its worth, FedRAMP has never specified that only one tool or set of tools can work. And each CSP can technically make most scanners work to meet requirements, especially if they put in some engineering effort to report on the necessary topics/format.
5. Transition Timeline - From what I can tell, 20x standards do not apply to Rev5 CSPs yet, and we are a ways from that. Historically any new FedRAMP standard allows transition time. The change from Rev4 to Rev5 took years.

➕ on "Guidance for federal agencies on how to consume and interpret the new real-time data would be beneficial to ensure alignment between CSPs and agency partners."

[polarstar-cyber]

As a security practitioner, it's incredible to see the evolution of one of the core building blocks of a security program. As modern enterprises have become more complex, so has vulnerability management. This is absolutely a step in the right direction. Much of the current text provides expectations for a provider in a very mature and efficient state of vulnerability management, but does not provide stepping stone standards and processes to reach that position.

---

1. Credibly Exploitable Vulnerabilities (FRR-CVM-02)

Context:
The language used in vulnerability management is largely centered around hypotheticals, such as "credible" or "could". As a practitioner, this type of vague language makes it challenging to consistently demonstrate mission impact and value. Although the language as written is reasonable to improve prioritization amongst the high volume of security signals, larger enterprises will still struggle to further segment “Critical” and “High” issues due to the high volume of issues that are all arguably “credible”.

Some organizations face CVE volumes in the millions. If 1% of a million CVEs are "credibly exploitable", that is still 10,000 issues that require immediate attention. Credibly exploitable doesn't necessarily mean it's been proven — this can damage the trust relationship between security and their cross-departmental partners if mismanaged. Practitioners understand that not every vulnerable component is technically exploitable, but this distinction in the industry is blurry.

In practice, one of the biggest differentiators in prioritization is a deterministic set of steps to reliably demonstrate the impact of a vulnerability. This typically comes in the form of penetration testing in lower environments in conjunction with custom tests to continuously validate the steps to reproduce are still demonstrable. This separates vulnerabilities from those that are "credible" but not yet proven, to those that are definitively possible. By their very nature, they serve as great candidates for test automation.

This type of vulnerability classification reinforces trust across departmental units on vulnerability quality and serves as a useful metric to better understand testing capacity. By distinguishing the two, the security vendor market can better transition from F.U.D. through sheer vulnerability detection volume and leverage advanced reachability analysis for security teams to demonstrate mission impact.

Recommendation:

• Add a new definition for "Validated Exploitable Vulnerabilities" to describe a vulnerability for which successful exploitation has been confirmed through internal testing, demonstrating that a threat actor could reproduce impact using a deterministic and documented sequence of steps. To be considered validated, the vulnerability must be reachable, reproducible, and not fully mitigated, with evidence showing it can result in unauthorized access, operational disruption, or other adverse effects.
• Language should also include that providers must leverage a Security Signal Actionability Standard to determine which security signals and factors should undergo additional validation efforts. For example, there may be certain factors relevant to a credibly exploitable vulnerability that would spark a time-boxed effort to demonstrate impact (either manual or through automated efforts).

---

2. Mitigate (FRD-CVM-04)

Context:
The current definition for mitigation is very simple. Mitigation is a common and standard practice in vulnerability management as remediating all issues is practically infeasible. Our position is that mitigation is an appropriate measure to address a detected vulnerability and should be encouraged given the tradeoffs that might exist.

For example, an organization can validate that there is a confirmed monitoring mechanism for a vulnerability that will trigger an alert and appropriate response. This would meet the definition of a mitigated vulnerability. By including such language in the definition, practitioners can better connect the practice of vulnerability detection to incident identification.

Recommendation:

• Add explicit language to the definition of "mitigate" to include monitoring capabilities with an associated response playbook as an example.
• Provide a reference to CISA Cybersecurity Incident & Vulnerability Response Playbooks with language using "should", similar to how it was included in FRR-CVM-01.

---

General Comment

• The document recommends strict vulnerability response timelines. As others have mentioned, this can be very difficult in practice to enforce. To help get there, the above recommendations are focused on enabling feedback loops that justify the mission impact and value of vulnerability management efforts. These feedback loops aim to improve vulnerability prioritization and continuously mature detection capabilities.

---

Max Zhou
Polarstar Cybersecurity Group

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

1. Personally, I like that Credibly Exploitable allows discretion to help determine that. Allowing CSPs, 3PAOs, and Agencies to review HOW that is determined, rather than prescribing by a single organization for hundreds or thousands of CSPs that all operate very differently is a better approach. It allows CSPs to determine this. And in your example of CVE volumes in the millions, and 1% are credibly exploitable, thats still a ~90% decrease in the number of vulnerabilities that have to be remediated within 30 days under the current model. And CSPs have the capability to "tune" these determinations to be even more accurate as time goes on. But if something is credibly exploitable and internet facing by a CSPs own determination, they should be testing with some manual intervention to confirm that, quickly. If that testing within needed timelines reveals that this is NOT exploitable, then you have proof to show that, can add to the vulnerability information that determination, and can mark it as not credibly exploitable. If this is happening more often than not, then it sounds like further tuning of credibly exploitable determinations needs to occur. Adding in validated exploitable as the bar to warrant enhanced timelines, in my opinion, would add detection time exponentially, which increases risk. Just because we confirmed that a vulnerability is exploitable doesn't reduce the risk of that vulnerability. Raising that awareness within the CSP faster when something is credible, by your own determinations, helps improve security posture overall.
2. Given that the RFC gives broad latitude to develop your own practices for how you determine something is mitigated (Ie the mitigating factors that help), It sounds like you can already do this for your organization. In my opinion, we should NOT add specifics like logging or a response playbook to the definitions in this standard, as that alone is not a sufficient mitigating factor to always lower risk. And in fact relying solely on that is quite reactive which historically is proven to be less effective at managing risk than preventative measures.

[kcarr91]

1. FRR-CVM-04 - Should be made clearer that is the responsibility of the CSP. I know it says Providers but I could see this become a very large point of contention with Agency customers. Consider adding in something along the lines of.

Providers MUST adjust and assign their own risk and severity of vulnerabilities using .....

Or maybe a note underneath to make it clear. I have a feeling a lot of agency customers will have issue with this and thus I would ask this to be defined. If they see a CVSS base score that results in a High rating they will likely state that can’t be risk reduced to a low as that is how they have operated for a decade plus.

2. FRR-CVM-05 As this could be another point of contention with Agency customers to make it even more clear I would suggest there be a note added.

Note: Providers are only required to note vulnerabilities which are overdue or not expected to be remediated within the required timeframes on their POA&M. Providers MAY include additional vulnerabilities within SLAs on the POA&M at their discretion

3. FRR-CVM-08 - It should be made clear if the records of all false positive need to be provided to agency customers as part of the vulnerability reports noted in FRR-CVM-02.

4. Thank you for defining Internet reachable in FRD-CVM-07.

5. Question

Would a Fully mitigated vulnerability show up on the POA&M?
i would think so, but it only notes they will show up in the assessments (FRD-CVM-04), doesn’t say about POA&M and isn’t super clear to me. However in the Quick Reference - Vulnerability Response Time Frames the action is “Fully mitigate or remediate“ within 6 months. So that leads me to believe that once something is Fully mitigated then it is no longer a concern and thus doesn’t need to show up on the POA&M anymore.

6. Concern

FRR-CVM-04 - Having spent considerable time in this industry, particularly from my previous time on the 3PAO side and engaging with 40+ CSPs, I have some concerns about allowing CSPs to fully define their own risk ratings. In my experience, CSPs often express overly strong confidence in their security posture and compensating controls. I worry that this approach could result in tons of CSPs just risk rating everything as low or very low.

The counterargument, of course, is that agencies will provide oversight to prevent such issues. However, I don't believe that agency FedRAMP review teams are equipped to engage in these highly technical discussions. Even if they do push back, this approach will likely devolve into disputes over specific risk ratings rather than maintaining focus on the broader risk landscape and strategic priorities. Additionally I greatly worry about the ATO process that agencies have and this new process of risk ratings not aligning with their current standards in the same way the current FedRAMP rev 5 baseline currently does.

There likely needs to be a centralized starting point for at least vulnerability scan findings to start from. For example i think it would be helpful to use a more advance metric starting point when available. So my suggestion would be use something like CVSS v4 Threat score if available, if not available use CVSS v3 Temporal score, if neither are available then define the Provider should define the applicable risk rating more applicable to their environment.

[pete-gov]

For public awareness, the primary purpose of public comment is for FedRAMP to receive information and opinions by giving "interested persons an opportunity to participate in the rule making through submission of written data, views, or arguments" (per the Administrative Procedures Act).

FedRAMP does not respond to questions in public comments and they are the most difficult form of public comment to consider because the commenter's view, argument, or opinion can only be inferred. In most cases, FedRAMP is forced to interpret questions as simply a single opinion that FedRAMP should provide an answer to the question in final guidance or directives.

As an additional notice for public awareness, FedRAMP reiterates that members of the public may submit multiple comments during the public comment period.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

5. From the way this RFC reads, it seems to indicate that fully mitigated vulnerabilities do NOT get added to POA&Ms, but DO get provided in other "assessments" and vulnerability reports. POA&Ms are for things that are overdue. Fully mitigated is the action taken within the response timeframes, and as such can't be overdue. I expect that the concept of "POA&Ms" will change drastically with this standard and future standards though, so I'm envisioning a future "POA&M equivalent" to be just the subset of vulnerabilities in continuous reporting that are overdue, and also have a list in that reporting that have been remediated and fully mitigated.

6. As someone that comes from a 3PAO working with dozens of CSPs as well, I can appreciate your concern and to some extent share it, but "bad faith" tactics aren't fully prevented in current standards, and can't be fully prevented in new ones. Personally I'd rather the full adjustment methodology CSPs utilize be continuously available to all agencies and 3PAOs for the CSP, and part of evaluation be to assess what conditions a vulnerability would be considered credibly exploitable and/or high/very high risk. If that formula for which a CSP utilizes to automatically assess and risk-adjust upon detection won't ever produce vulns that are credibly exploitable in their environment, obviously thats a problem that needs to be raised, and isn't that the exact point of the 3PAO and agency reviews? The program could of course put in standards to ask for that evaluation etc, but specifically requiring a set rubric for exactly how that is determined leaves out nuance of the CSPs architecture, development practices, and overall security posture. Being overly prescriptive for hundreds of CSPs doesn't provide actual security, it provides a check-box. And it also prevents CSPs from adopting new threat intelligence feeds or methodologies that provide better information. Requiring a prescriptive formula for risk adjustments is not working right now, nor is reviewing each and every one individually. I prefer the currently-written RFC as it allows CSPs to continuously adapt, tune, and improve upon their assessments as the world changes, rather than waiting for a government agency to allow them to do it.

[kcarr91]

Sorry for #5 i should have phrased that better, I wasn't expecting a response. Rather than the word question i should have noted something along the lines of "point of clarification requested in the final version of this standard".

cb-axon thanks for your response. Honestly I'm not sure what is best for #6 i don't have an idea that i think would be perfect. However we can't let the perfect be the enemy of the good. I agree with the overall direction however i do worry that there will be a lot of CSPs that just rate everything low/very low and do nothing to improve their overall security posture as pressure from the business will not prioritize vulns correctly. If there is just something that could prevent a CSP doing no analysis and rating everything low that would be great to work in something like that.

Maybe CSPs could be required to just write a one pager or something that describes their risk rating process and have that stored on their repository. That way still leaves it up to the CSP but they have to explain their overall risk rating process in a low lift way. Could be helpful for end customers to understand and makes CSPs at least put some thought into it.

[badgerinspace]

Overall comments:
RFC-0012 takes a novel approach to issues that have established solutions already. While they are not the best solutions and very much could be improved, I believe this approach would not be that improvement. The main flaw is centered around the need to create a new way to describe exploitability, rather than utilizing CVSS vector data, which already does this and provides numerous methods to make the described exploitability more accurate.

1. CSPs have always been able to move the various CVSS vector "levers" to risk adjust vulnerabilities based on exploitability, impact, and temporal metrics. However, these adjustments have always been optional. Based on the wording in FRR-CVM-01, CSPs would now be required to effectively determine various extra details about each vulnerability, instead of optionally choosing to. If a CSP were to implement this process correctly and with rigor, it would require huge swaths of developer / engineer hours to determine the credible exploitability for each vulnerability. Take the following examples, the first being a common, current CSP process and the second being the RFC-012 process:

   • Scenario 1 (current process): A CSP runs automated scans and utilizes the provided CVSS data to triage vulnerabilities based on severity. This process is standardized, easy to replicate, and does not require extensive additional analysis unless they want to, for example, drill into the details and determine if vulnerabilities should have an exploitability metric of AV:N or AV:L. This determination would be made in a risk adjustment, on a selective basis and very likely greatly reduce the associated risk severity as locally exploited vulnerabilities are less of a threat than network exploited vulnerabilities. However, this process is optional and analysis beyond the basic scan and severity assignment is not required.
   • Scenario 2 (RFC-0012 process): A CSP runs automated scans, but instead of using CVSS, they must create custom severity determinations for each vulnerability. Where this was once an optional process through risk adjustments, it now must be done for every vulnerability. Some details can be easy, such as reachability. Others, such as determining "credibly exploitable vulnerability" status involves a more nuanced understanding of the vulnerability, the exploitation path, and the impact it would have to the CSP's system. While it would be nice for automated tools to handle this process for the CSP, how would an automated tool handle the deeper understanding of exploitation path for this specific CSP? The CSP might be using a custom fork of the vulnerable code or may have the vulnerable code in their system, but it's never touched by any system processes. Likewise, how would an automated tool handle understanding the impact to the CSP's system? It would need such detailed information as to understand what vulnerability exploitation would result in, while combining security tooling in place that could block execution or firewall rules that could block connections. This is certainly plausible, but automated tooling that incorporates all factors accurately for every CSP with every possible combination of unique situation for an adjustment to the exploitation or impact is near impossible. Every CSP system is designed differently and uses different security tooling. The point of detailing this scenario is to show that no longer would a CSP have the choice of drilling into this level of depth for a risk adjustment, they would instead be forced to execute huge swaths of developer / engineer time to achieve a deeper understanding of each vulnerability. That is, assuming this process is followed with rigor. Because the reality would likely lack that rigor, while pushing the buck to "automated tools" that make blanket assumptions about the credible exploitability of a given vulnerability.
     • Based on years of experience seeing hundreds of RA justifications, I implore FedRAMP to not assume that automated tooling can handle the thousands of edge cases that exist when it comes to handling vulnerabilities. Of course, the language in FRR-CVM-06 and related requirements state that automated tooling should be used, but not that it has to be used, but the reality is that automated tooling will take shortcuts to determine credible exploitability and requiring CSPs to follow this process for every vulnerability will realistically force their hand to automated tooling or will force manual processes that lack the rigor to understand the exploitability and impact involved.

2. FRR-CVM-01 states that all listed requirements supplement controls in the Rev5 baseline, which indicates that the typical 30/90/180 remediation timelines are still required, yet FRR-CVM-TM-09 states that all vulnerabilities must be remediated in 180 days (6 months). Based on the Rev5 baseline control language, wouldn't high and moderate severity vulnerabilities of any kind need to be remediated far faster than 180 days?

3. FRR-CVM-02 does not discuss risk severity with or without the context of CVSS, but then FRR-CVM-04 requires risk adjustments to use CVSS base scores (for any vulns that have CVSS base scores). How are these concepts compatible? CVSS would need to be recorded from the start to incorporate adjustments to it later on.

4. FRR-CVM-09 has the potential to be abused through root cause and remediation strategy. Swaths of generally unrelated vulnerabilities could be combined under one singular root cause, such as "OS version is out of date" or one remediation strategy such as "Update the OS version".

5. FRR-CVM-TM-03 has the same issue as current CISA KEV guidance: Due dates in the KEV database are assigned based on original detection date of exploitation. This generally means 2-3 weeks after the CVE was added to the KEV database, it's due for remediation. The reality in vulnerability management is that these CVEs can pop up at any time. A CVE in the KEV database might go unnoticed in certain software packages for months or years, only to be suddenly detected on a package that was otherwise up to date on patches. An engineer might add an out of date package to an image when they shouldn't have done so and now the image is affected by a KEV from 6 months ago. These common scenarios put CSPs in the awkward situation of meeting a due date that could be months or years in the past. Without realistic timelines to work towards, this can cause KEVs to stay open far longer than they should.

Suggested changes:

1. Use the pre-existing CVSS vector metrics to determine credible exploitability instead of defining new ways to determine exploitability.

   • CVSS standards have existed for decades and evolved over time. It already contains defined processes for determining exploitability and impact such as network vs local exploitation. It also contains temporal metrics such as the maturity of the exploit and if a remediation is available. Modern vulnerability scan tooling has largely incorporated CVSS and many tools provide vector strings as well, making adjustments even easier if properly utilized. The data is almost always there because of CVSS, it's just a matter of using it properly.
   • Instead of forcing aforementioned scenario 2, allow CSPs to continue using base CVSS and determine if they want to undertake the process of adjusting the recorded exploitability and impact values.

2. As FRR-CVM-01 states that all listed requirements supplement controls in the Rev5 baseline, explicitly state whether the 30/90/180 timelines defined in RA-5 must be followed or, as FRR-CVM-TM-09 indicates, all non-credibly exploitable vulnerabilities that are not internet-reachable are extended to a 6 month remediation timeline. This conflicts with existing Rev5 guidance.

3. Explicitly state that base CVSS must be recorded in FRR-CVM-02. Without this, FRR-CVM-04 creates conflicting guidance.

4. Define characteristics in FRR-CVM-09 more concretely, otherwise the risk of abuse is high.

5. Define more concrete remediation timelines for CISA KEVs, rather than relying on the published due dates in the KEV database, as stated in FRR-CVM-TM-03. The same issue exists in current guidance and causes remediation timeline confusion for KEVs detected on software months or years after being published to the KEV database. Based on the typical due dates of KEVs added to the database, a concrete remediation timeline for KEVs would fall between 2-3 weeks.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

1. In my experience with how things are done now, automated risk adjustments are not allowed right now, so this is an improvement. The way I read this RFC, automated assessment upon detection is optional, but obviously encouraged given the timelines identified. But to be honest, this is information most CSPs and Agencies should WANT to have, so they can properly prioritize issues. CVSS Alone doesn't help and is often a misnomer. Prioritizing for manual review based on base CVSS score alone is flawed, and a guaranteed way to get engineering teams to bring out the pitchforks. So personally, I can't WAIT to be able to implement this automation. It doesn't have to be complicated or engineering intensive to create. But the more effort thats put into it, the more accurate its likely to be. We as a society have access to tons of information that can help determine exploitability. EPSS Scores, likelihood analysis, automated testing/exploitation etc. Using those tools to build a "formula" will be able to do this. I don't read this standard as requiring automated tools to assess the environment specifically, but instead assess based on a CMDB of the different assets/asset classes and their security mitigations (internet reachable, internal, requires elevated access, not even accessible by 99% of network resources, requires hard-token auth etc). Those factors can be automatically added into a the adjustment to provide the necessary context that we all generally want Agencies to utilize. Can it always be improved upon? Of course, but this is still better than where we are at today.

2. Personally, I've seen plans to take a CVSS score from a scanner and utilize it in part of the automated analysis. The output will provide a different score that can be aligned with potential adverse impact. CVSS doesn't align with potential adverse impact in each environment, and doesn't have the more granular concept of very high/very low. So moving away from only 3 tiers of risk provides a lot more context in my opinion, and allowing CSPs, 3PAOs, and Agencies to collaborate on the right ratings for the output is more aligned with true security discussions.

3. I don't disagree. I think agency and 3PAO reviews on grouping strategies will help combat this. But not allowing grouping prevents context and reasonable collections of issues that allow for actual security discussions. Otherwise true risk gets lost in the fray. For example, I've seen vulnerability scanners give separate plugins/detections for over 600 kernel vulns with no credible path to exploitability in the environment, and over 99% with "low" risk ratings. Without grouping, an agency only sees a number of "CVEs" (which is not a true measure of risk) but doesn't see the overall concept of "This kernel needs a patch" unless they read at least several in succession. Even today, certain scanners DO group vulnerabilities together this way, and all agencies just trust this grouping, so why is it permissible for a scanner to do it, but not a CSP? Is it not possible for a CSP to employ personnel that are capable of properly grouping?

Suggested changes:

1. Using CVSS for these adjustments can already be done under this RFC. Do you see somewhere that it says you can't use CVSS scoring as the basis for your assessment/analysis? Also, CVSS metrics do not inherently "define" credibly exploitable. It is something that can be added to it with additional scores, but you'd still run into the question of "where does that information come from?" So providing that information to a new CVSS score still needs to be injected, and on the quantity of vulnerabilities from scanners that most CSPs deal with, eevn today, its not practical to rely solely on manual input alone. The resources required to do manual review for every vulnerability, even to only risk adjust it, is far greater than the engineering resources to automate it similarly. At least in every organization I've ever seen.
2. I disagree that this creates conflicting guidance. FRR-CVM-02 requires that the assessment for credibly exploitable and adverse impact be listed. If your assessment includes CVSS Score, it would be in there, no?

[johnfosborneiii]

FRR-CVM-02
Providers MUST create and maintain vulnerability reports showing vulnerability management activity...

Will the PMO continue to provide scanner/report configuration guidelines such as those found in the FedRAMP Vulnerability Scanning Requirements (i.e."The CSP must enable all non-destructive detections within the scanner")?

Since scanners often have widely different default configurations, those guidelines have helped make scan results more consistent

FRR-CVM-04
Providers MUST adjust the risk and severity of vulnerabilities using CVSS base scores (if applicable) AND the context of the vulnerability, factoring for at least criticality, reachability, exploitability, detectability, prevalence, and mitigation, to determine if vulnerabilities are credibly exploitable and the potential adverse impact of exploitation.

NIST provides existing guidance for adjusting CVSS scores using environmental and temporal factors:

• NIST CVSS Scoring System Calculator
• NIST IR 7435
  The Common Vulnerability Scoring System (CVSS) and its Applicability to Federal Agency Systems

Will the FedRAMP PMO recommend providers follow existing NIST guidance or otherwise provide new criteria to ensure consistency in assessing the risk of a particular vulnerability?

FRD-CVM-08
Known Exploited Vulnerability: Has the meaning given in CISA BOD 22-01, which is any vulnerability identified in CISA’s Known Exploited Vulnerabilities catalog.

I'm concerned about masking the explolitation risk by limiting this definition strictly to entries in the CISA KEV database. Vulnerabilities can be exploited quickly in the wild with AI, for example ChatGPT 4 can exploit 87% of one-day vulnerabilities and the CISA KEV typically lags behind other industry sources

Has the PMO considered including other industry exploitation databases and/or vulnerabilities with a particular CVSS/EPSS score?

FRD-CVM-07 (Internet-reachability)
Note: This includes information resources that have no direct route to the internet but receive or process information or other payloads triggered by internet activity such as some logging services, some application services that process data submitted from internet-facing services, etc.

It would be helpful to provide a table of what would be considered internet reachable. For instance, would telemetry, centralized logging, monitoring agents, cron jobs be considered internet reachable? I could see this be interpreting a number of different ways as it is currently constructed

[pete-gov]

For public awareness, the primary purpose of public comment is for FedRAMP to receive information and opinions by giving "interested persons an opportunity to participate in the rule making through submission of written data, views, or arguments" (per the Administrative Procedures Act).

FedRAMP does not respond to questions in public comments and they are the most difficult form of public comment to consider because the commenter's view, argument, or opinion can only be inferred. In most cases, FedRAMP is forced to interpret questions as simply a single opinion that FedRAMP should provide an answer to the question in final guidance or directives.

As an additional notice for public awareness, FedRAMP reiterates that members of the public may submit multiple comments during the public comment period.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

Will the FedRAMP PMO recommend providers follow existing NIST guidance or otherwise provide new criteria to ensure consistency in assessing the risk of a particular vulnerability?

I hope they don't. While I agree CVSS can be a useful tool, it has its flaws, and doesn't work for every organization/architecture to add in the sufficient level of context. CVSS scores also do not align with the adverse impact ratings which provide, at minimum, more context than "low moderate and high." I've seen plans that incorporate additional information from outside NVD and Nist to help do this assessment, including EPSS scores, and even CISA's SSVC. Requiring or even recommending a specific methodology doesn't allow organizations to leverage new technology and feeds to perform this analysis, and requires government agencies to release something (which historically has been proven not move at the pace of innovation) in order for improvements to occur.

I'm concerned about masking the exploitation risk by limiting this definition strictly to entries in the CISA KEV database

where is this limited? The way the definition of "Credibly exploitable vulnerability" reads, it does NOT say to only use KEVs, or even mention them. And in the continuous reporting, it requires credibly exploitable and adverse impact, not KEV. FRD-CVM-08 is simply a definition by CISA that is commonly referenced. That doesn't mean CSPs can't add to that definition or other feeds can't.

It would be helpful to provide a table of what would be considered internet reachable.

I think not having so many "specifics" (And instead just the intent) from FedRAMP is a good thing. It enables us to have more thoughtful conversations about actual security risk, rather than just checking boxes. Private VPC endpoints are sometimes exposed directly to the internet, but not always. Allowing CSPs to put their true context into their systems is best. I read the intent of FedRAMP 20x to encourage more thoughtful conversations about risk between agencies and CSPs, rather than check-box compliance. Asking FedRAMP to provide edge cases and decision criteria removes a CSPs ability to provide their own context that the program might not be able to conceive today.

[pete-gov]

The following comment was received via the Public Comment Form on 7/23/2025 by AppOmni.

---

AppOmni, a FedRAMP-Moderate–authorized SaaS Security Posture Management (SSPM) provider (ATO granted 09 July 2025), appreciates the opportunity to comment on RFC-0012, “Continuous Vulnerability Management Standard.” Our platform continuously monitors more than 40 SaaS applications for Federal and commercial customers.

We applaud the draft standard’s focus on contextual risk scoring and its explicit objective of “prioritizing the discovery, mitigation, and remediation of vulnerabilities in internet-reachable resources.”

Recommendation 1 — Clarify “internet-reachable resources” to include identity-based SaaS exposures.
In multi-tenant SaaS (e.g., Salesforce, Microsoft 365, ServiceNow), records or APIs can be reachable from the public internet via externally shared links, over-privileged guest accounts, or stale OAuth tokens even when the underlying infrastructure is not exposed. We suggest amending § FRR-CV-02 to state that “internet-reachable resources” include SaaS data objects and APIs that are effectively accessible without authentication or via publicly discoverable credentials.

Recommendation 2 — Accept machine-readable SaaS evidence.
To align with the draft’s goal of reducing bespoke reporting (§ FRR-CVM-05), we recommend explicitly permitting JSON/CSV exports from commercial SSPM tools as acceptable evidence for contextual reachability and remediation status.

Recommendation 3 — Expand contextual factors table.
Appendix A lists KEV status and EPSS. We propose adding “effective permissions” and “external sharing state,” which materially affect exploitability within SaaS environments.

Any questions or a request for our capability statement or a briefing can be directed to the included email address. Thank you.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive; and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

Recommendation 1 - This is a great example and I'd agree those should be considered internet reachable in some scenarios. I think not having so many "specifics" (And instead just the intent) from FedRAMP is a good thing. It enables us to have more thoughtful conversations about actual security risk, rather than just checking boxes. Private VPC endpoints are sometimes exposed directly to the internet, but not always. Allowing CSPs to put their true context into their systems is best, in my opinion. I read the intent of FedRAMP 20x to encourage more thoughtful conversations about risk between agencies and CSPs, rather than check-box compliance. Asking FedRAMP to provide edge cases and decision criteria removes a CSPs ability to provide their own context that the program might not be able to conceive today.

Recommendation 2 - Personally, if we aren't going to require a specific schema or format, explicitly permitting a certain format will be effectively an endorsement, and be the eventual requirement, which can stifle current innovation. I don't think explicitly permitting or disallowing should be done until there is something proven not to work.

Recommendation 3 - Where is this appendix A? from the way the RFC reads currently, I don't see specific limits or requirements on exploitability determinations, so is there a reason why you believe these wouldn't be allowed? As I've said, I don't think this standard should get that specific, and should be adaptable enough to grow with industry innovation.

[pete-gov]

The following comment was received via the Public Comment Form on 7/24 by an unknown CSP.

---

In regards to the Discovery and Analysis Time Frames in section FRR-CVM-TM, running vulnerability scans every 3-7 days on top of the usual monthly scans would create significant overhead for diminishing returns. I'm all for checking vulnerability scan results against the KEV to see if there are any matches, and I think a quick remediation of any matches is important, but running vulnerability scans that often seems excessive. In my experience, our vulnerability scan results don't change much month to month. The KEV also doesn't change significantly over the course of 3 days.

[pete-gov]

The following comment was received via the Public Comment Form on 7/30 by an unknown CSP.

---

The current timelines seem very rigid, and don't allow room for situations where internet-available vulnerabilities cannot be reasonably tested and patched within 3 days, such as Log4J. Additional guidance for such situations would be much appreciated.

[Christcpd]

As a CISO for an MSP/MSSP, this standard, as written, concerns me. The timeframes are aggressive; probably the most aggressive I have seen in my career. The definition of what constitutes a vulnerability needs refining. I'm going to post comments in a few comments here.

TBH, I fed this into Gemini (corporate license, no training, and well, this is a public document.)

1. Subjectivity and Ambiguity in Definitions
The standard's effectiveness relies on clear, objective definitions, but several key terms are open to interpretation, which could lead to disputes between providers and auditors.

• "Credibly Exploitable Vulnerability": This definition hinges on the word "likely"—a "likely threat actor" who would "likely be able to gain unauthorized access". This is inherently subjective. A cloud provider's security team might assess the likelihood as low, while a federal agency or auditor might view it as high. This ambiguity could become a central point of conflict during assessments.
• "Fully Mitigate": This is defined as reducing risk to the point where there is "no reasonable probability of exploitation". The term "reasonable" is not defined and is highly contextual. What one engineer considers a reasonable mitigation, another might see as insufficient, making consistent enforcement difficult.
• "Vulnerability": The definition is rightly expanded beyond CVEs to include misconfigurations and weak credentials. However, this breadth creates ambiguity. For example, what constitutes a "weak" credential? Without a specific, measurable standard (e.g., complexity, length, MFA enforcement), this becomes a subjective judgment call. Does this mean STIG scans now?

2. Aggressive and Potentially Unrealistic Timelines
The timelines for remediation, particularly for internet-facing systems, are extremely aggressive and may not align with safe and stable IT operational practices.

• 3-Day Remediation for Internet-Reachable Vulnerabilities: The requirement to fully mitigate or remediate credibly exploitable vulnerabilities on internet-reachable resources within three calendar days is the most challenging specification.
• Dependency on Vendors: Remediation often requires a patch from a software vendor. It is common for vendors to take longer than three days to develop, test, and release a security patch.
• Risk of Service Disruption: Rushing a patch or a significant configuration change into a production environment without adequate testing can cause service disruptions or introduce new bugs. A 3-day window for discovery, analysis, testing, and deployment across a complex cloud service is often unachievable without accepting significant operational risk.
• 7-Day Mitigation for Internal Vulnerabilities: Similarly, the 7-day timeline to mitigate or remediate non-internet-reachable vulnerabilities with moderate to very high impact is demanding. While more generous, this is still a tight window for potentially complex internal systems that may require significant effort to patch and test.

3. Significant Administrative and Operational Burden
The documentation and reporting requirements, while thorough, could create a significant administrative burden that diverts resources from active security management.

• Extensive Reporting for Every Vulnerability: Providers MUST create detailed vulnerability reports for all detected vulnerabilities, including a unique ID, timeline, exploitability assessment, impact assessment, and remediation plan . For large environments that may have thousands of low-level vulnerabilities at any given time, this level of detailed, individualized tracking is a massive undertaking. The allowance for grouping vulnerabilities helps, but the initial documentation requirement remains substantial.
• Lack of a Specified Machine-Readable Format: The document requires reports in a "compatible machine-readable format" but does not specify one. This ambiguity forces providers to guess or support multiple formats (e.g., JSON, XML, CSV), increasing implementation costs and complexity. Specifying a standard like the Vulnerability Exploitability eXchange (VEX) would be more effective.
• Automated Remediation Expectation: The standard states that providers SHOULD use automated systems to remediate vulnerabilities with "minimal or no human intervention". While this is a laudable goal, it is at the cutting edge of security technology (SOAR). Implementing such automation safely without causing outages is extremely difficult and expensive, making this an unreasonable expectation for many providers, even as a "SHOULD."

[Christcpd]

On the Credibly Exploitable Vulnerability definition needs to be clarified "A vulnerability where a likely threat actor with knowledge of the vulnerability would likely be able to gain unauthorized access, cause harm, disrupt operations, or otherwise have an undesired adverse impact in the CSP's specific environment;"

Remove the "must be reachable" as everything is reachable in one way or another. Internet reachable is one thing and the highest risk. However, with the assumed breach, malicious internal actor, or unintended actor (phished, malware, etc) allows for taking advantage of credible vulns.

I see the priority matrix for remediation as:

• Internet Reachable, CEV (3 Days)
• Internet Reachable, KEV (7 Days)
• Internet Reachable, High (10 Days)
• Internal, CEV (14 Days)
• Internal, KEV (18 Days)
• Internal, High (21 Days)
• Internet Reachable, Medium (90 Days)
• Internal, Medium (90 Days)
• Internet, Reachable, Low (180 Days)
• Internal, Low (180 Days)

Given the automation of Vulnerability DETECTION, it is easy to incorporate this type of day calculators. It also will require a change in mindset around scanning; a move to "realtime" scanning rather than point in time scanning. I use Trend Vision One and it "scans" once a day so my vuln scan is always up to date. So hitting that 3 day on a IR, CEV is doable.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive; and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

1. Subjectivity and Ambiguity in Definitions
   Unfortunately, I think the vast majority of perceived risk is subjective until proven with actual exploit. But if we wait for a proven exploit, we'll always be behind. Personally, I prefer to have more thoughtful conversations about security and I believe these definitions support that. I would design a program that is reasonable and defensible, and if an agency wants to tell me that it doesn't meet their needs, I'd need to discuss their actual concerns and have them define what reasonable is in this scenario. In every instance that I've done this I've been able to show how the areas they are concerned about are already accounted for in the program I'm operating. But doing this vulnerability by vulnerability is not useful, and instead allowing us all to focus on the "how" we are determining these ratings writ large is more productive. STIG alignment can be a vulnerability, and is technically required in Rev5 baselines already. Overall, I think these definitions allow growth in technology as security posture evolves.
2. Aggressive and Potentially Unrealistic Timelines -
   In normal practices I don't disagree. The way we are looking at things, these vulnerabilities will basically trigger alarms that get on-call support when in off hours. The FIRST thing that should be done is evaluate its true exploitability, even with internal knowledge. If that proves that this is actually not exploitable with current information, then this is no longer credible exploitable, and adjust the vulnerability appropriately, and can all go home to resume "normal" vulnerability operations. Assuming we do find that it is credible exploitable through manual methods as well, the second actions we will be looking at are the quick wins to mitigate the likelihood of exploitability. That COULD be full remediation, but could also be a specific WAF rule, a relatively quick/safe application change etc. As I mentioned, this may not be remediation, but it mitigates to, again, no longer being credibly exploitable and no longer requires the 3/7/21 days. We have every intention of full remediation "quickly" - but to align with safe release practices and such, that may be 2-4 weeks, which is fine if the issue is not credibly exploitable anymore.
   And if CSPs are unable to get these even mitigated down or remediated within these time frames, I believe the intent is to effectively let agencies know so it can be a thoughtful discussion on the actions being done, given that these should be a rare occurrence.

[pete-gov]

Public comment received via email from Salesforce:

---

Section: Definitions

Text: N/A

Comment: Likelihood, impact, and risk all come up a lot here as core concepts.

Proposing that we formally add a risk definition in this section as a function of likelihood and impact as per NIST: https://csrc.nist.gov/glossary/term/risk
Section: FRD-CVM-02

Text: A vulnerability where a likely threat actor with knowledge of the vulnerability would likely be able to gain unauthorized access...

Comment: To align with generally accepted legal terminology and FRD-CVM-05, proposing we switch from using "likely be to able to gain" to "reasonable" etc.

So going from "knowledge of the vulnerability would likely be able to gain..." to "knowledge of the vulnerability would reasonably be able to gain..."

Also remove "likely" from before threat actor as its redundant when mentioned again later in the sentence
Section: FRD-CVM-04

Text: Mitigate: Temporarily reduce the risk that a vulnerability will be exploited or the potential adverse impact if it is exploited...

Comment: Proposing that "risk" here should really be "likelihood", as risk = likelihood x impact, and impact is mentioned later in the sentence as another input.

So in short - mitigation should either target the likelihood of a vulnerability being exploited or the impact of its exploitation (or both), which both reduce overall risk.
Section: FRD-CVM-05

Text: ...fully mitigated vulnerabilities still appear in assessments until they are remediated...

Comment: Some of our "fully mitigated' vulnerabilities may not ever be remediated due to fundamental architectural limitations.

If these vulnerabilities must stay on our assessments, we would like to confirm that, as long as we can show they are fully mitigated and risk is negligible (they are not exploitable), they would not contribute to any punitive measures from FedRAMP or agency customers.
Section: FRR-CVM-02

Text: Providers MUST create and maintain vulnerability reports showing vulnerability management activity that include at least the following information about all detected vulnerabilities...

Comment: This may be asymmetrically noisy for CSOs with larger environments if we have to do this for all detected vulnerabilities.

We are proposing that these reports are only required for vulnerabilities that are mitigated or planned to be mitigated, rather than all detected vulnerabilities. Even if automated, filling in 5 through 8 for quickly remediated vulnerabilities may be a big uplift for larger environments.
Section: FRR-CVM-03

Text: Providers MUST make vulnerability reports available to all necessary parties...

Comment: Proposing that we add here "Providers MUST make vulnerability reports as established in FRR-CVM-02 available to all..." so that it is more clear that we are referring to the previously defined report format.
Section: FRR-CVM-06

Text: False Positive: Has the meaning given in NIST SP 800-115, which is “an alert that incorrectly indicates that a vulnerability is present."

Comment: Deviations have three categories (as of today). Where FP is fully explained and included, suggesting that operational requirements and vendor dependencies (along with their SLAs) are included too as additional terms.

Together, these three scenarios can be showcased as common examples of how CSPs justify why some vulnerabilities can only be initially mitigated rather than remediated due to internal (OR) or external limitations (VD).
Section: FRR-CVM-TM-01

Text: Providers MUST provide up-to-date vulnerability reports to all necessary parties at least monthly and SHOULD provide these continuously.

Comment: Many CSPs have state, local, commercial, and other customers that also use FedRAMP authorized CSOs; however, the vulnerability reports in FRR-CVM-02 should only be accessible to those in the federal space.

Proposing that we update this language to define necessary parties as Authorizing Officials, third party assessors, federal agency customers, and regulatory personnel, so that there is less confusion about who is required (FRR-CVM-TM-01) and who is optional (FRR-CVM-AY-01).
Section: FRR-CVM-TM-07

Text: Providers SHOULD mitigate or remediate credibly exploitable vulnerabilities in resources that are NOT internet-reachable promptly, within seven calendar days of detection...

Comment: Proposing to add the word "impact" here or remove it in FRR-CVM-TM-08 for consistency as they're referring to the same concept.
Section: FRR-CVM-TM-07, FRR-CVM-TM-08

Text: N/A

Comment: Proposing to reword these such that they do not define the vulnerabilities in scope via negation. This would better match the guidance in the "Impact" column of the Quick Reference Table. So instead of using "unless" statements, -07 should be "within seven calendar days of detection if the potential adverse impact is Very High, High, or Moderate".

Then -08 would be "... if the potential adverse impact is Low".

[aj327]

Disclaimer for transparency: I work at Chainguard, which provides ~600 secure, zero-CVE container images with FIPS 140-3 validated cryptography and STIG-hardening out of the box with a contractual CVE remediation SLA.

1. Tightening Up Internet‑Reachable Definition (FRD‑CVM‑07)

The current definition of internet reachability in RFC-0012 states “This includes information resources that have no direct route to the internet but receive or process information or other payloads triggered by internet activity”. This broad definition could be interpreted to suggest that any vulnerability across the entire FedRAMP boundary is internet reachable and that every system needs to be air gapped to be non-reachable. Of course we recognize this isn’t the PMO’s intent; however, leaving the definition this value will either A) make it so challenging for CSPs that they get discouraged because everything is a P0 or B) push CSPs to completely ignore this definition and state that nothing is internet reachable at all out of frustration.

Recommendation: Make it much clearer and more objective as to what “internet reachable” means. This will ease many CSPs concerns, especially those that don’t have huge security or compliance teams to do deep analysis on every CVE. Providing some sort of decision tree or scorecard will likely go a long way here.

2. Vulnerability Severity / Risk Scoring (FRD-CVM-02 and -09; FRR-CVM-04)

We appreciate the PMO’s objective of moving away from a purely CVSS-based ConMon process to one that takes into consideration your existing security controls, environment context, and other mitigating factors so that security teams can prioritize the real risks; however, giving every CSP carte blanche to determine their own risk, severity, exploitability, and reachability scores is dangerous. Huge companies (such as those on the recent ConMon panel) have armies of people and tools to do the arduous work of scanning, contextual analysis, risk threat modeling, and more; however, the average company (even in enterprise) does not. This demand for deep assessment, analysis, and re-scoring will create a significant burden for the average company, which may encourage them to just downgrade every vulnerability to low impact, creating more risk for all stakeholders.

Recommendation: There is existing guidance from NIST (linked here) on how to adjust CVSS scores based on implementation in your product-specific context. In this guidance, NIST encourages CSPs to adjust CVSS scores but in a well defined and scoped manner. Specifically, CSPs are able to adjust the environmental and temporal components of the score after starting with the NVD base score. Providing some guardrails for how CVSS are adjusted will 1) simplify and standardize the process for CSPs, the PMO, and agencies, 2) mitigate the risk of CSPs gaming the system, and 3) contribute meaningfully towards reducing security risk as we get deeper into the age of coding agents and LLMs.

3. Expanding the Scope of “Credibly Exploitable” (FRD-CVM-02 and -08)

RFC-0012 largely defines “credibly exploitable” as what’s in the KEV and then what the CSP’s own assessment of exploitable means. We believe this scope is too narrow for a few reasons:
It ignores other valuable databases like VulnCheck that move faster and have a broader scope of data
It is becoming increasingly easier and easier for AI to exploit vulnerabilities. Even just 1 year ago in July 2024, IBM showed that ChatGPT (then based on GPT-4o) was able to exploit 87% of one-day vulns. That was before we had reasoning models like (o3 or Opus 4) which will likely only make things worse.

Recommendation: Expand the definition of credibility exploited to not only include what’s in the KEV but also what is in VulnCheck. Additionally, require that critical vulnerabilities be treated as credibly exploitable given the growing likelihood of AI coding systems / agents to penetrate vulnerabilities. This will bolster security while still giving CSPs more flexibility on how to prioritize the long tail of vulns.

4. Remediation Timelines (FRR-CVM-TM-03 through -09)

When we typically talk to CSPs about CVE mitigation/remediation SLAs such as those laid out in FRR-CVM-TM, there is often confusion about “when the clock starts”. It is not clear to me where the PMO has defined the starting clock for remediation/mitigation. Is it when a patch is released upstream? Is it when your scanner flags it? Is it when the Linux provider flags it?

Recommendation: We suggest the “starting gun” for remediation / mitigation timelines begin when a patch is available upstream from the software maintainers. Vulnerabilities that have upstream patches available and are not mitigated/remediation within the 3/7/21 day timeline, must be in POA&Ms.

5. Triage, Analysis, and Management vs. Risk Surface Elimination

The overall approach espoused in RFC-0012 is centered around finding, analyzing, and, most importantly, managing vulnerabilities. It follows the evolution of scanner tools over the last 5-10 years – start with scanning to get visibility and then layer in contextual analysis for prioritization. This is sound logic as security & engineering orgs should be focusing their capacity on the highest priority risks.

That said, “managing” vulnerabilities is easiest for big companies with deep benches of talent, expertise, and tools. It is much harder for the average company, who then has an incentive to game the management of those CVEs (or ignore them altogether).

But what every company can do, with free tools and open source technologies, is drastically reduce their attack surface. At the container level, that means building on distroless containers, slim distros, and / or scratch. This path is one that also encourages more focused on risk reduction, as opposed to compliance.

Recommendation: The PMO should strike a better balance between reactive vulnerability management and proactive attack surface elimination. We are not asking the PMO to point CSPs at any one vendor or technology, but rather recommending that the PMO make hardened, minimal open source components the standard for the next decade of FedRAMP. This will move the whole industry forward by securing production environments by default.

[cb-axon]

Just writing to provide the way I'm viewing these items in hopes that it helps manage these standards if/when released. Assuming they don't change much. I believe that this RFC is overall positive; and in my opinion, gives the industry a chance to implement actual security, rather than focusing on compliance for compliance sake, when its not actually benefiting security.

1. I think not having so many "specifics" from FedRAMP is a good thing. It enables us to have more thoughtful conversations about actual security risk, rather than just checking boxes. Private VPC endpoints are sometimes exposed directly to the internet, but not always. Allowing CSPs to put their true context into their systems is best. I read the intent of FedRAMP 20x to encourage more thoughtful conversations about risk between agencies and CSPs, rather than check-box compliance. Asking FedRAMP to provide edge cases and decision criteria removes a CSPs ability to provide their own context that the program might not be able to conceive today.

2. The way I read this RFC, CSPs are encouraged to provide automated assessments. I agree most CSPs don't have armies of people to do Vuln analysis, but I don't read this as requiring "deep" analysis and assessment, and especially not manually. Yes CSPs are expected to provide an assessment, but using the tools provided with vulnerability scanners, I'd imagine most CSPs would have the resources build even basic automation to provide a higher-context adverse impact score and credibly exploitable rating, especially when it has the potential to save so many engineering resources fixing "vulnerabilities" without context and without any real security improvement. If that automation is realistic and properly cuts the number of high and moderate vulnerabilities by 99%, I'd consider that a win because it will significantly reduce engineering burden even short term.

3. Does Credibly exploitable limit you to not using these external sources? I don't read it that way. I read it as we can use resources available to us if we want to. I don't see why this definition wouldn't allow a CSP to use VulnCheck if it made sense to utilize it. I also believe that we should not be automatically requiring "critical" vulnerabilities to be considered credibly exploitable. I would say each CSP SHOULD be accounting for mounting AI exploitation in their risk determinations, but having FedRAMP or any agency require a specific formula or hard "rules" here will stifle innovation and lower efficiency. I think if we do rules like that, it will lower efficiency enough to actually make us worse at responding to real risks.

4. I understand the confusion, and personally I like that theres some play here to allow for nuance. Initial detection time/date is where my mind goes, but as things change, that resets. So the way I'm thinking about it, if I have a credibly exploitable public vulnerability, if I then within 2 days take mitigation actions that no longer make that vulnerability credibly exploitable, the vulnerability then moves to no longer credibly exploitable, and gets a new SLA based on that. With the grouping ability, I may have the same vulnerability on some assets that are credibly exploitable, and others that are not, with different due dates because of that fact. Thats not to say I won't remediate them all at the same time, but that I don't HAVE to.
   But stating that the remediation/mitigation timelines is only when a patch is available I believe is dangerous. A patch is not the only way to remediate or mitigate a vulnerability. It could be isolation, network rules, code changes etc. If I have to wait for an upstream vendor for a patch to lower the risk on an exploitable public vulnerability, I believe I'm doing something wrong. There are many other levers to pull, and they all should be considered.

[robgil]

Thank you for driving modernization of the Vulnerability Management guidance! Overall I think this is a great step forward and is a great target state. With FedRAMP moving faster than GovRAMP and DISA, we're concerned this is going to cause confusion and undue burden on CSPs when they have to address vulnerability management in three different ways.

Here are the general questions and feedback from the Okta team.

• Will there be reciprocity with DISA/GovRAMP?
• Will the POAM template change? Will it be aligned with DISA?
• What is the expected timeline to shift to the new definition of vulnerability?
• When are CSPs expected to change their deviation processes?
• When are CSPs expected to start tracking reachability context?
• Will FedRAMP define reachability? (Load balancer? Or all the way to App?)
• Can you now make a deviation from a High to a Low based on reachability?
• How does FedRAMP define “credibly exploitable”?
• Would contextualized vulnerabilities still have to go through individual risk adjustment approvals? Concern regarding scalability.
  • It would help if FedRAMP can release a framework or more detail on the risk adjustments process. Much of the adjustment process is still up to interpretation based on the RFC. Ideally, CSPs risk adjustment framework would be evaluated rather than each individual line item.
• Will agencies be required to adhere to this RFC? Or will they have autonomy in applying their own vulnerability requirements for CSPs? How will (or will) FedRAMP help/intervene when individual agencies deviate from FedRAMP vuln mgmt standards?
• Will there be new published thresholds from the PMO in the common performance guides due to the addition of new types of vulnerabilities to the POAM? If we are expanding the scope of vulnerability types reported on, adding in configuration scan items, CSPs can't be expected to be under previously published levels.
• We strongly suggest that the thresholds be updated with more detailed categories of vulns and corresponding target thresholds rather than “no more than 10 late moderates”
• “Requiring POA&Ms only when providers won’t respond within the recommended timelines” - needs clarification. Does this suggest vendor dependencies won’t need to be on the POAM? What if it's OSS with no concrete promises. Have they considered security impacts related to 3rd party software?
• Need clarification on definition of mitigate “the temporary reduction or lessening of the adverse impact of a vulnerability or the likelihood of its exploitation”. Is this only talking about preventative controls? Not detective?
• Definition of fully mitigate: “no reasonable probability of exploitation by any reasonable threat source”. Are CSPs expected to consider insider threat in this probability?
• Remediation Timelines – Trigger and Counting
  • Are the 3/7/21-day deadlines calendar days or business days?
  • Does the timeline begin at discovery, vendor disclosure, or CISA KEV listing?
  • Why ask?
    • This directly drives SLA design, patch pipelines, and engineering workload. Ambiguity risks noncompliance findings and missed deadlines during audits. Affects customer-facing commitments and trust (especially government agencies expecting strict adherence).
• Contextual Risk Prioritization – Standard vs CSP Discretion
  • Will FedRAMP provide a standardized rubric for exploitability/reachability scoring, or must CSPs justify their own methodology?
    • Okta’s risk scoring for vulnerabilities impacts both engineering prioritization and audit evidence.
    • Lack of standardization could lead to inconsistent expectations between 3PAOs, JAB, and agencies.
    • Impacts customer communications, agencies will want to understand why Okta labels a vulnerability High vs Moderate.
• POA&M Elimination – Documentation Expectations
  • If POA&Ms are eliminated for timely remediations, how should CSPs document mitigations or fixes for agency audits and 3PAO reviews?
    • Okta’s FedRAMP continuous monitoring relies heavily on POA&Ms today.
    • A fundamental shift in documentation could require new reporting systems and education for agencies expecting POA&Ms.
    • Without clarity, Okta risks audit findings for “missing” historical records.
• Applicability to Inherited Services (AWS/Azure)
  • How will timelines apply when vulnerabilities are in inherited infrastructure (e.g., AWS/Azure) vs Okta’s SaaS layer?
    • Okta inherits FedRAMP controls from AWS; unclear timelines could force double remediation responsibility or unrealistic SLA enforcement.
    • Critical for shared responsibility models and communicating obligations to agencies.
• Automation & Reporting – API/Schema Requirements
  • Will FedRAMP provide standard API/data schema for continuous vulnerability reporting, and what is the required frequency?
    • Okta’s vulnerability data comes from multiple tools (Qualys, Wiz(?), internal pipelines).
    • Without clear schema, automation could become costly and duplicative.
    • Impacts both engineering builds and customer-facing transparency portals.

Thanks for all you do!
Rob and the Okta Team

[pete-gov]

For public awareness, the primary purpose of public comment is for FedRAMP to receive information and opinions by giving "interested persons an opportunity to participate in the rule making through submission of written data, views, or arguments" (per the Administrative Procedures Act).

FedRAMP does not respond to questions in public comments and they are the most difficult form of public comment to consider because the commenter's view, argument, or opinion can only be inferred. In most cases, FedRAMP is forced to interpret questions as simply a single opinion that FedRAMP should provide an answer to the question in final guidance or directives.

As an additional notice for public awareness, FedRAMP reiterates that members of the public may submit multiple comments during the public comment period.

[mherckis-wiz]

On behalf of Wiz, we appreciate the FedRAMP's proposed Continuous Vulnerability Management Standard in RFC-0012 and the opportunity to comment on it.

As both a CSP managing a FedRAMP environment and a platform that supports efforts for many seeking and maintaining a FedRAMP certification, we applaud the effort to move toward context-based vulnerability prioritization. Wiz believes FedRAMP has an opportunity to further emphasize context and risk-driven vulnerability management in this proposal to ensure it focuses on leading private sector practices and avoids requiring continued focus on minimal risk or administrative tasks that may steal resources from critical risk reductions.

Overview

While the technology Wiz uses to manage risk is practically identical across our commercial and FedRAMP environments, our FedRAMP operational model and the administrative and engineering overhead related to vulnerability management are significantly higher.

Wiz uses context-based issues with high priority to prioritize risk, mitigation and prioritization in both environments. However, an inordinate amount of engineering resources are spent managing non-contextual vulnerabilities to remediate them within the 30/90/180-day timeframe based solely on CVSS scores and their existence ‘somewhere’ in the environment, whether internet facing or isolated in the backend. This can be highly inefficient.

We are like all CSPs, compelled to treat a CVSS score of 7.5 on an internal backend system with the same 30-day fire drill as one on a public-facing API.

A context based risk model would never prioritize these two issues equally.

Security and engineering resources are always highly contested in any organization. The FedRAMP compliance regime allocates resources toward rectifying entries in the multi-thousand-line POA&M for ‘context-blind’ vulnerabilities that could have otherwise been spent on improving mitigations in existing systems and ‘root-causing’ security issues.

Therefore, while a positive move in the right direction, we recommend that the Continuous Vulnerability Management Standard move more aggressively towards:

• Automated and near-real time continuous monitoring;
• A focus on risk in context that prioritizes toxic combinations of risk rather than CVEs and CVSSs, such as the accidental commit of access keys or misconfigurations that provide access sensitive data; and,
• An acceptance of industry-based context-based risk calculations.

Comments on Continuous Vulnerability Management Standard (RFC-0012)

FRD-CVM-01: Vulnerability

Wiz appreciates that FedRAMP is leveraging a definition of Vulnerability that includes a broad range of weaknesses beyond standard Common Vulnerabilities and Exposures (CVEs) catalogued within that program. We recommend that FedRAMP emphasize this broad definition both in its communications with CSPs going through the program, agency authorizing officials, and all operational practices.

FRD-CVM-02: Credibly exploitable vulnerability

Wiz recommends the ‘credibly exploitable vulnerability’ definition include, “based on contextual risk to the environment” within the definition to ensure it is grounded in the specific CSP environment and not based on a CVE score.

Additionally, we recommend aligning on NIST SP 800-30 Appendix G terms to avoid defining a new Likelihood level between Moderate and High and ensure organizations are leveraging the same understanding of risk. SP 800-30 leverages "highly likely" at High and "somewhat likely" at Moderate specifically to avoid ambiguity. Additionally, because Impact levels are defined in this RFC using SP 800-30 definitions, this would link FedRAMP’s renewed focus on security with established risk calculations which simplifies conversations about system risk among CSPs, 3PAOs, and agencies.

FRD-CVM-07: Internet-reachable

The definition of internet reachable should be expanded to include vulnerabilities that have no direct route to the internet but are exposed due to other vulnerabilities, misconfigurations or weaknesses (for instance, a publicly exposed repository with cleartext cloud keys providing access to a separate, sensitive environment).

FRR-CVM-01; FRR-CVM-02

Wiz appreciates the effort by FedRAMP to move towards prioritization of risk from vulnerabilities. Wiz notes that while the Stakeholder-Specific Vulnerability Categorization (SSVC) has merits, it is very focused on a vulnerability’s perceived interest to attackers in absence of where the vulnerability exists within the context of the CSPs environment. This is a concern as it does not move individual CSPs towards prioritizing remediations based on the contextual risk of their environment.

Wiz recommends the requirements specifically note the acceptance of widely accepted industry risk calculations as a means to determine accurate prioritization. These combinations of risk may or may not include traditional CVEs, including misconfigurations and embedded secrets.

We recommend FedRAMP make clear these vulnerabilities and their prioritization not be tied to specific CVEs.

FRR-CVM-04

Wiz applauds the focus on “the context of the vulnerability” in addition to Common Vulnerability Scoring System (CVSS) and other static analyses. To that end, we recommend that FedRAMP includes toxic combinations of risk such as misconfigurations, its proximity to risk factors such as sensitive data, and embedded secrets in addition to the factors listed in the standard.

FRR-CVM-09

Wiz would recommend either:

a) expanding FRR-CVM-09 to permit groupings based on attack chains or toxic combinations of concerns–including entitlements, weaknesses and misconfigurations–that together create a measurable vulnerability for the environment.

AND/OR

b) creating a FRR-CVM-10 that explicitly calls for grouping toxic combinations of varied weaknesses and vulnerabilities that–when taken in context together–create greater impact and urgency.

FRR-CVM-TM-04 and FRR-CVM-TM-06

Wiz believes that the timeframes for CSPs to “discover, analyze, and assess all resources” in the environment are very long for continuous monitoring. We would recommend shorter interludes. We also would recommend requiring that all environments must be discovered, analyzed and assessed within 24 hours of new code or resources being committed to the environment.

Recognizing that there may be operational issues that delay discovery or automated scanning in rare instances, FedRAMP may want to caveat with an exception for operational outages. Alternatively, FedRAMP might create a requirement (‘MUST’) within the current timeframe and an expectation (‘SHOULD’) within the shorter timeframe.

FRR-CVM-TM-09

Wiz would recommend against requiring the mitigation and remediation of all vulnerabilities, regardless of the risk they create in the environment. All software has some modicum of weaknesses and vulnerabilities. This is particularly true of low level vulnerabilities and weaknesses that do not pose any real risk to the environment.

Requiring low risk vulnerabilities to be remediated within six months–or any timeframe–moves FedRAMP away from a risk-based security model.

Additionally, building on our revised definition of FRD-CVM-07, to reflect the realities of what is “internet reachable,” Wiz would suggest vulnerabilities that are not internet accessible should be considered as less likely to be exploited and FedRAMP's focus on contextual risk as a method of prioritization for resolving vulnerabilities in a system should extend to this effort.

Wiz suggests FedRAMP can align with established risk calculations in NIST SP 800-30 by setting the acceptable level of impact reduction for assets that are not internet-reachable to Moderate, reflecting Table I-2 (p. I-1). This sets overall risk at Low even for High-impact vulnerabilities when the overall likelihood is Low or Very Low (i.e. non-internet-reachable). Accepting mitigation to moderate impact would reduce burden on operational and engineering teams, simplify conversations about risk among stakeholders, and maintain FedRAMP's focus on reachability (reflecting "Overall Likelihood").

[pete-gov]

The following public comment was sent via email by Horizon3.ai as an attached PDF file.

Concept Paper_ Executing FedRAMP RFC-0012's Vulnerability Management Standard with CAPT.pdf

---

It's a pleasure to be involved with the FedRAMP 20x discussion program. Please find our attached whitepaper that discusses the concepts of how Continuous Autonomous Pentesting (CAPT) can become a key concept in the execution of the Continuous Vuln Management Standards development.

Happy to answer questions on these concepts or to deep dive with our team on this project as it progresses.

Concept Paper: Executing FedRAMP RFC-0012's

Vulnerability Management Standard with Continuous

Autonomous Pentesting (CAPT) tools.

The proposed RFC-0012 FedRAMP Continuous Vulnerability Management Standard marks a
fundamental shift in how FedRAMP approaches vulnerability management, moving towards a
risk-based, automated, and continuous paradigm. This standard aims to ensure cloud service
providers (CSPs) promptly detect and respond to critical vulnerabilities by considering the entire
context of a vulnerability with a focus on exploitability rather than solely relying on Common
Vulnerability Scoring System (CVSS) scores. Continuous Autonomous Pentesting solutions,
with exploitability-informed Risk-Based Vulnerability Management (RBVM), is uniquely
positioned to execute the core concepts and requirements outlined in RFC-0012 by replacing
theoretical risk with provable exploitation and enabling automated, closed-loop remediation
workflows at scale and at a frequency that was previously not possible. With the advent of
autonomous pentesting solutions, the above concepts are now in the art of the possible to build
effective and efficient vulnerability management programs around with repetitive, autonomous
pentesting as the key driver of data collection and prioritized action.

1. Shift to Contextual and Risk-Based Prioritization Beyond CVSS Scores

RFC-0012 explicitly states its intent to move away from sole reliance on CVSS scores, requiring
providers to adjust the risk and severity of vulnerabilities by considering context such as
criticality, reachability, exploitability, detectability, prevalence, and mitigation. The standard
emphasizes determining if vulnerabilities are "credibly exploitable" and assessing their "potential
adverse impact".
Using a Risk Based Vulnerability Management (RBVM) approach through Continuous
Autonomous Pentesting (CAPT) directly fulfills this requirement by prioritizing vulnerabilities
based on what's exploitable, aligning to attacker behavior, and accounting for business impact.
It moves "past CVSS base scores and incorporates reachability and exploitability." at the
foundation of its context scoring methodology and results.
● Exploitable Attack Surface : CAPT proves exploitability by executing production-safe
attacks across internal, external, and cloud scopes, assessing which weaknesses
persist, reappear, or are reintroduced, and the effectiveness of security controls. This
provides a "validated baseline of what an attacker could achieve today—not last
quarter". This direct validation distinguishes "credibly exploitable" vulnerabilities from
theoretical ones, providing a "deterministic set of steps to reliably demonstrate the
impact".
● Threat Actor Pressure : CAPT aligns prioritization with attacker urgency by tracking
"Known Threat Actor Tactics" (mapping to real-world TTPs) and "Known Exploitable
Vulnerabilities" (KEVs), including CISA KEVs continuously validated in the environment.

This directly supports RFC-0012's requirement for providers to remediate Known
Exploited Vulnerabilities according to CISA's due dates.
● Precise Business Impact : CAPT determines business impact not just from
Configuration Management Data Base (CMDB) entries, but from what it actually
accessed or impacted through "High Value Targeting" which is the process of inferring
importance of compromised assets and "Advanced Data Pilfering" which is the process
for inspecting accessed data for secrets, PII, IP). This directly aligns with RFC-0012's
definition of "potential adverse impact" based on estimated effects of unauthorized
access or harm to federal information, which uses qualitative values like Very High, High,
Moderate, Low, and Very Low.

2. Emphasis on Automation and Continuous Processes

A cornerstone of RFC-0012 is the encouragement of automated vulnerability management, with
expectations for continuous assessment, detection, and response where feasible. Providers
"SHOULD use automated systems to identify, mitigate, and/or remediate credibly exploitable
vulnerabilities in internet-reachable information resources with minimal or no human
intervention".
CAPT's Find-Fix-Verify (FFV) loop is designed to operationalize remediation, shrinking the time
between exposure and resolution at machine speed through the method of continuous
pentesting, not just vulnerability scanning. Current method of creating exhaustive POAM
documents for noisy vulnerabilities that are not exploitable wastes precious time. Using CAPT
in a Find Fix Verify loop can support more efficient work processes to fix what matters.
● Autonomous Discovery and Validation : CAPT autonomously uncovers attack paths
and validates them through real actions, providing proof of exploited vulnerabilities,
lateral movement, and impact. Frequent pentesting is the only way to truly identify and
illuminate exploitable weaknesses from an attacker’s perspective.
● Automated Remediation Workflows : MCP Servers or Model Context Protocol servers
are revolutionizing the speed and scale for the integration of security software tools and
unlocks a new level of near-autonomous workflows for security practitioners. An MCP
server acts as a structured, read-only bridge between attack data and agentic workflows.
This enables organizations to build "Agentic Remediation Workflows" that:
○ Fix only what matters, based on provable attack paths - this avoids the extra
work of creating POAMs and fixing non-exploitable vulnerabilities.
○ Eliminate manual effort in analysis, triage, and context collection - pentesting at
scale and speed by autonomous tools is now more reliable, more effective, and
faster than human-managed vulnerability management programs.
○ Autonomously validate that fixes worked via repetitive tests - this enables
security program managers and auditors to not just supervise effort, but
supervise outcomes.
○ Close the loop—Find → Fix → Verify—at machine speed - the adversaries in
2025 are generating attacks with AI. it’s imperative that we defend networks by

fighting algorithm versus algorithm at scale with humans in the loop where
required.
● Integration with Existing Tools : MCP servers enable seamless integration with
ticketing systems (Jira, ServiceNow), SOAR platforms for automated remediation, GRC
platforms for reporting, and dashboards for continuous visibility, aligning with
FedRAMP's goal to facilitate the use of existing commercial tools.
● Specific Automated Workflows : CAPT supports numerous "Agentic Remediation
Workflows" that directly implement RFC-0012's continuous and automated goals:
○ Exploit-Driven Vulnerability Remediation : CAPT triggers the remediation
process with contextual data, allowing agentic systems to generate plans and
tools to open tickets for manual or automated patching, followed by CAPT's
one-click-verify retest to verify the fix.
○ Infrastructure-as-Code (IaC) Fix-Verify Loop : For cloud misconfigurations,
CAPT identifies the resource and impact, an agentic system locates the IaC,
creates a pull request for modification, and CAPT verifies the fix via a scoped
retest.
○ Credential Abuse + Privilege Remediation : CAPT surfaces compromised
credentials and their abuse, flagging over-permissioned accounts for an agentic
system, leading to automated key rotation, account disabling, or RBAC policy
adjustments confirmed by CAPT.
○ KEV Exposure Remediation and Verification : CAPT confirms exploitability of
CISA KEVs, allowing agentic systems to prioritize fixes and deploy
patches/mitigations, with CAPT then revalidating the KEV is no longer
exploitable. This supports the continuous discovery and remediation of KEVs
which are clearly confirmed exploitable vulnerabilities with clear standards for
remediation.
○ EDR / Detection Ineffectiveness Remediation : CAPT logs undetected
post-exploitation actions, allowing agentic systems to identify detection gaps and
add/improve rules in SIEMs, with CAPT rerunning actions to confirm detection.
○ Attack Path Risk Reduction via Network Segmentation : CAPT demonstrates
lateral movement due to weak segmentation, exposing the attack path. Agentic
systems analyze rules, deploy microsegmentation policies, and CAPT confirms
the path is broken.
○ Tripwire Deployment & Response Automation : CAPT deploys deception
tripwires to high-value assets, and its MCP server surfaces their monitoring
status, enabling agentic systems to monitor triggers and initiate SOAR playbooks
for containment.
○ Multi-System Workflow Orchestration : CAPT's MCP provides structured data
for an agentic system to orchestrate workflows across multiple tools (e.g., Jira,
GitHub, ArgoCD, Slack) for remediation and verification.
○ Read-Only Incident Response Enrichment : CAPT MCP can be queried during
incident response to correlate alerts with prior attack paths, enriching IR actions
and containment steps.

○ Automated Policy Hardening Recommendations : CAPT identifies recurring
misconfiguration patterns across pentests, allowing agentic systems to generate
hardened baseline templates for policy updates, which CAPT then validates.

3. Refined Definitions and Stricter Timelines

RFC-0012 introduces clarified definitions such as "Vulnerability" (to include misconfigurations,
exposures, insecure services), "Credibly exploitable vulnerability", and distinguishes "Mitigate"
from "Remediate". It also prioritizes "internet-reachable" resources for aggressive timelines.
The standard sets explicit and aggressive timelines for mitigating and remediating
vulnerabilities, especially for "internet-reachable credibly exploitable" vulnerabilities with "Very
High, High, Moderate, or Low" impact, requiring mitigation or remediation within three calendar
days of detection.
The definition of “exploitability” is likely to pose the greatest difficulty in creating standards. It is
our firm belief that the confirmation from a pentest that a significant impact (domain
compromise, host compromise, ransomware exposure, data exposure, critical infrastructure
compromise, etc) is achievable by an “adversary” is the litmus test for exploitability. This
includes using CVEs, KEVs, misconfigurations, default passwords, and other non-CVE
vulnerabilities that allow or enable threat actors to achieve their objectives. We offer that
significant effort should be taken to ensure exploitability is always confirmed through a test, not
via theoretical analysis. Additionally, the context of a pentest must also be considered in terms
of the impacts that are proven. External tests that find internet exposed exploitable weaknesses
should always be the #1 priority for remediation, but the context of internal weaknesses and
exploitable weaknesses will determine the urgency to remediate.
CAPT's capabilities are engineered to meet these demands:
● Proof-Based Exploitation and Impact : CAPT's ability to prove an exploited
vulnerability and its impact directly informs whether it is "credibly exploitable" and helps
assess its "potential adverse impact". Proof of exploitability must be shown via the host
details and the commands utilized to exploit the weakness and gain an effect. In most
cases this will require the chaining of weaknesses together to achieve a useful
adversarial effect.
● Accelerated Find-Fix-Verify (FFV) Loop : The core FFV loop, from pentest finding to
verified resolution, is designed for speed. CAPT autonomously uncovers an attack path
and validates it through real actions. Findings contain context like exploit chain and
business impact, and CAPT can be used to re-execute the exact chain to verify
resolution of issues after a ticket is marked mitigated/remediated, finally after Pentest
verification, a ticket can be properly closed with proof of remediation.
● Mitigation Workflows : While a fix is in progress, CAPT helps trigger immediate actions
to narrow the attacker’s window of opportunity, such as enhancing detection and
response with telemetry feeds for EDR rule tuning, deploying HoneyTokens for early
warning, and reducing blast radius by isolating affected assets or rotating credentials.

This supports RFC-0012's encouragement of "urgent mitigation... prior to remediation".
This proactive and automated mitigation helps meet the specified "promptly"
requirements.

4. Re-purposing of POA&Ms and Reporting

RFC-0012 significantly re-purposes Plan of Action & Milestones (POA&Ms) for vulnerability
management, requiring them only when providers will not respond within the recommended
timelines. This aims to reduce administrative noise.
CAPT's agentic remediation workflows directly support this by accelerating remediation and
reducing the exploitation window. By enabling organizations to fix what matters faster and with
automated verification, CAPT reduces the instances where POA&Ms for delayed remediation
would be necessary, aligning with FedRAMP's goal to facilitate compliance for CSPs following
commercial security best practices.
Furthermore, RFC-0012 requires up-to-date vulnerability reports at least monthly and
encourages continuous provision in human-readable and compatible machine-readable formats.
CAPT's MCP Server exposes detailed findings, attack paths, tripwire events, and retest results
via a structured GraphQL API, making it easy to integrate with ticketing systems, GRC
platforms, and dashboards to support continuous reporting and provide the necessary
information (e.g., unique ID, CVE ID, timeline, internet-reachable status, exploitability, impact,
mitigation/remediation plan/measures). This also helps with the recommendation for
machine-readable formats for continuous feeds.

Conclusion

The RFC-0012 FedRAMP Continuous Vulnerability Management Standard represents a pivotal
evolution in federal cloud security, moving towards a more proactive, risk-based, and automated
approach. CAPT, with its agentic RBVM, is an ideal solution for CSPs aiming to comply with and
even exceed these new requirements. By autonomously proving exploitability, aligning to
real-world attacker behaviors, quantifying business impact, and driving closed-loop, automated
Find-Fix-Verify workflows, CAPT enables organizations to fundamentally redefine how they
identify, prioritize, and eliminate risk. This fusion of autonomous pentesting, high-value targeting,
and agentic systems, facilitated by the CAPT MCP Server, provides the proof-based
prioritization and machine-speed remediation necessary to meet FedRAMP's stringent timelines
and continuous monitoring goals, ultimately ensuring a more secure federal cloud ecosystem.
The systems and processes listed above in this document have been proven and adopted by
major organizations in both industry and government with exceptional outcomes.
POC for this document is Corey Brunkow, Corey@horizon3.ai and Tony Pillitiere,
tony@horizon3.ai

[pete-gov]

The following public comment was submitted to the Public Comment Form by Vanta.

---

This RFC is a great direction towards a risk-based vulnerability management process, with some nuances to call out and require clarification. Below are a few key comments that Vanta has:

1. FRR-CVM-02: Out of the list of items in CVM-02, Vanta would like to call out the focus on “credibly exploitable vulnerabilities.” Vanta fully supports the emphasis on credibly exploitable vulnerabilities vs security vulnerability.

--This has been a common question on who determines what is a credibly exploitable vulnerability and I recognize that response is “the owner of the CSO is responsible.” I think it would be best to explicitly call this out when this is published with minimum requirements. ----Having a list of minimum requirements would prevent many CSPs from saying that the vulnerability is not credibly exploitable.

--Part of CVM-02, part 1 - it would be beneficial to have criteria on grouping “similar vulnerabilities, for instance: same container, same CWE, another broad class?

--Clarity is needed for the timeline for detection- when it is found, or when it was introduced?
Potential adverse impact assessment is vague and could get overly complicated

--Clarity is needed for what the changelog is for. Is it for scans or fixes? Essentially this is additional administrative overhead

2. FRR-CVM-04: The main concern here is that if we need to consider ""at least criticality, reachability, exploitability, detectability, prevalence, and mitigation"", does that mean we need to explicitly document our considerations in each of those categories for every single vulnerability that is found? Some of those can be automated or are simple binary yes/no answers, but others like criticality or detectability may be much more nuanced and take some time to evaluate.

3. FRR‑CVM‑05: Shifting the intent of a POAM for items that cannot be addressed within intended would lessen unnecessary paperwork, given many vulnerabilities are resolved within intended SLAs. This is a great move forward

--However, a credibly exploitable vulnerability with a low impact still has a 21 day remediation timeline. I recognize this is credibly exploitable, but given a low impact I feel it should be aligned with the low remediation timeline of 180 days. It would be more reasonable to align the remediation timelines in this case with the impact. I anticipate this timeline written as is will still create massive POAMs

4. FRR-CVM-05: As many mentioned, the strict timelines for remediation (3 calendar days for credibly exploitable vulnerabilities that are internet reachable) could frustrate many teams. It was suggested that the stricter timelines could be best applicable for FedRAMP High systems. The 3 calendar days is currently stricter than existing remediation timeline

5. FRR-CVM-06: It’s difficult to understand what a system would look like to mitigate/remediate vulnerabilities with no human interaction. It seems there would be some human intervention needed for remediation or to even identify the credibly exploitable vulnerabilities. This could be a big risk to Availability in the CIA triad.

6. FRR-CVM-03: It would be beneficial for PMO to provide guidance on secure and acceptable standards of doing so and to clarify public/private submissions. I recognize that PMO is pushing towards more public reporting with 20x, but raw vulnerability reports have sensitive information that companies would not be comfortable disclosing. This is slightly tied with CVM-07 (Providers SHOULD NOT share specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST share sufficient information about vulnerabilities for oversight, tracking, analysis, action, and risk assessment with all necessary parties.) Some of the sufficient information as depicted above could still be considered sensitive among companies

7. FRR-CVM-08: I recognize that providers hold records for the false positives, but who determines that a finding is an actual false positive?

8. FRR-CVM-TM Family: These requirements identify specific time frame-based goals related to continuous vulnerability management.

--There are several controls listed here (FRR-CVM-TM-01, FRR-CVM-TM-04, FRR-CVM-TM-05,
FRR-CVM-TM-08 ) that refer to providing something continuously, or performing continuous vulnerability assessments. Specific parameters would be more helpful to determining these expectations. For instance, FRR-CVM-TM-01 states that Providers MUST provide up-to-date vulnerability reports to all necessary parties at least monthly and SHOULD provide these continuously. The monthly and continuous requirement seem to contradict each other, unless continuous in this case means “ad-hoc upon request”

Thank you for taking these comments into consideration! We truly appreciate the engagement regarding this topic and looking forward to working together!

[pete-gov]

The following public comment was submitted to the Public Comment Form by Cloudflare.

---

-Overall, this RFC leaves a lot of room for interpretation. We recommend adding significant detail and examples to differentiate or define the requirements as written. For example, the difference between High and Moderate is semantics and can have different interpretations, and the definition for "credibly exploitable" will lead to disagreements and conflict between CSPs, Agencies, and 3PAOs. Please note the vulns on the KEV may be exploitable in some environments, but not others and therefore, may not pose a significant risk to some CSPs.

-We recommend adding a new definition for "validated exploitable vulnerabilities" to include reachability, reproducibility, evidence of access or level of disruption, mitigation status, and compensating controls.

-The vulnerability response timelines and the discovery and analysis timelines are incredibly strict and unlikely to be met by large CSPs. We encourage reconsidering these timelines

-FRR-CVM-TM-04 - the expectation to run and analyze vulnerability scans every 3 calendar days in addition to monthly scans creates significant effort with low return value

-FRR-CVM-TM-05 - the expectation to mitigate fully mitigate or remediate credibly exploitable vulnerabilities in internet-reachable resources within 3 calendar days of detection is unattainable considering the effort for analysis, testing, and deployment in complex environments. Quick patching timelines can lead to substantial risk.

-There are instances in which internet-facing vulnerabilities cannot be tested within a 3 calendar day window, such as Log4j. Please provide guidance for these instances.

-Will there be a recommended scoring methodology to balance CVSS, EPSS, and KEV?

-FRR-CVM-TM-03 - Oftentimes, CSPs will discover a new vuln in their environment, check the KEV catalog, and the due date will be in the past. Please clarify what remediation timeline CSPs should follow in such instances.

-FRD-CVM-04 and FRD-CVM-05 mention that mitigated vulnerabilities still appear in assessments until they are remediated, but makes no mention on if they should be included in the POA&M reporting. Please clarify.

-FRR-CVM-04 - Currently the responsibility is on the agency customers to approve risk adjustments, this reads as if the responsibility is now on the CSPs. Does this relinquish the agency responsibility to approve risk adjustments? Please clarify this.

-FRR-CVM-08 - Currently, FPs are not removed from the vuln scans themselves, but rather, are noted as FPs in the POA&M and moved to the closed tab, if the DR is approved. Does this process remove the need for FP approvals? Additionally, please clarify if removing the FPs from the scan results means adjusting the scans directly or manually removing them? Either way, this adds a good amount of effort month over month, rather than the current process of just removing them from our reporting metrics.

-FRR-CVM-09 - How will this be regulated? Is it fully up to the CSPs discrepancy how vulns are grouped together? Do customer agencies need to sign off on this? More guidance and structure around grouping would be useful. 

-This RFC makes no mention of vendor dependencies, it would be beneficial to see that be included into these response timelines as dependencies significantly alter what remediation actions are possible for the CSP to perform.

-There has been a lot of chatter about automation and it is mentioned a few times in this RFC, but there has not been any significant guidance around expectations for automation. Guidance on automation and tooling requirements, the expected outcome for automated tools, and specifications regarding a "compatible machine readable format" would be helpful. Additionally, are ConMon reports being replaced with real-time dashboards and if so, what is the timeline for that? Adding automation tools will take significant time for large CSPs, so the more clarity, the better. This ambiguity can and will lead to obstacles during roll out especially for large CSPs with multiple agencies to report to. 

-More guidance on "internet-reachable" would be helpful as some components may only be reachable through API gateways or content delivery, etc. 

-This RFC mentions only reporting POA&M items when "providers won't respond within recommended timelines", we'd appreciate more guidance around this. Under what conditions can a POA&M be used for delayed remediation? Threshold examples would be useful.

-Define authenticated scans for containerized, serverless, and managed compute components (agent-based runtime scanning, build-time image scanning)

-The Quick Reference of Vulnerability Response Time mentions fully remediating/mitigating vulns within 6 months - does this mean those vulns don't need to show up in the POA&M anymore?

[ktrychon1]

General Support for RFC-0012
Edera strongly supports FedRAMP's RFC-0012 Continuous Vulnerability Management Standard and the broader FedRAMP 20x initiative's focus on automation-driven compliance. As a provider of secure-by-design Kubernetes and AI infrastructure solutions, Edera believes this standard represents a critical step toward enabling federal agencies to adopt modern cloud technologies while maintaining the highest security standards.

Our company specializes in container workload isolation and hardened runtime using Type 1 hypervisor technology, fundamentally eliminating shared kernel vulnerabilities and lateral movement risks in Kubernetes and AI environments. This perspective informs our comments on how the standard can better accommodate infrastructure-level security controls that prevent vulnerabilities from being exploitable in the first place.

We commend FedRAMP for several key aspects of this standard:

1. Automation-First Approach: The emphasis on automated vulnerability management (FRR-CVM-06) aligns with industry best practices and reduces human error while improving response times.
2. Contextual Risk Assessment: Requiring providers to consider vulnerability context beyond CVSS scores (FRR-CVM-04) represents a mature approach to risk management that acknowledges the complexity of modern threat landscapes.
3. Prioritization of Internet-Reachable Resources: The aggressive 3-day timeline for internet-facing vulnerabilities appropriately reflects the elevated risk these resources face.
4. Clear Definitions: The plain-language definitions, particularly for "credibly exploitable vulnerability" (FRD-CVM-02), provide necessary clarity for implementation.

Infrastructure-level security controls represent a fundamental shift from reactive vulnerability management to proactive threat prevention that delivers significant cost savings to federal agencies. Traditional approaches require continuous cycles of vulnerability identification, assessment, patching, and validation—consuming substantial resources in perpetuity. In contrast, secure-by-design architectures eliminate entire attack vectors through architectural controls, dramatically reducing the ongoing operational burden and associated costs.

By solving security challenges at the architecture level, organizations can avoid the endless cycle of patching individual vulnerabilities, leading to substantial savings in personnel time, system downtime, and operational overhead. These cost efficiencies are directly passed on to federal customers, representing responsible stewardship of taxpayer dollars. This RFC's emphasis on contextual risk assessment creates an opportunity to properly recognize these preventive measures, ensuring that organizations implementing advanced security architectures receive appropriate credit for their investments in foundational security controls that benefit both security posture and fiscal responsibility.

Specific Recommendations for Enhancement

1. Recognition of Infrastructure-Level Security Controls

Issue: The current standard focuses primarily on software vulnerabilities detected through traditional scanning methods without adequately recognizing infrastructure-level security controls that can prevent entire classes of vulnerabilities from being exploitable.
Recommendation: Enhance FRD-CVM-02 (Credibly Exploitable Vulnerability) to explicitly acknowledge that vulnerabilities may not be credibly exploitable due to infrastructure-level isolation controls, even when the underlying software vulnerability exists. We would like FedRAMP to clearly define what "credibly exploitable" means, especially in the context of mitigating controls.

Suggested Language Addition:

"Infrastructure-level security controls, including but not limited to hypervisor-based isolation, hardware security modules, network segmentation, and other architectural security measures, may render vulnerabilities non-exploitable even when the vulnerable code is present. Providers implementing such controls may classify affected vulnerabilities as not credibly exploitable with appropriate documentation and assessment, while maintaining standard reporting requirements."

Justification: Organizations implementing secure-by-design architectures will have better outcomes when implementing these controls. For example, research has demonstrated that container escape vulnerabilities become non-exploitable when containers run in isolated virtual machines rather than shared kernel namespaces (Moore, M. "Hypervisor-based Container Isolation," arXiv:2501.04580, 2025). While the underlying vulnerability still requires patching according to standard timelines, these architectural solutions provide superior security outcomes and should be recognized in risk assessments and deviation justifications.

2. Clarification of "Full Mitigation" for Architectural Controls

Issue: FRD-CVM-05 (Fully Mitigate) focuses on reducing exploitation probability but doesn't clearly address scenarios where architectural controls eliminate or mitigate entire attack vectors.

Recommendation: Clarify that architectural security controls can constitute effective mitigation for affected vulnerability classes while maintaining patching requirements.

Suggested Enhancement:

"Architectural security controls that eliminate attack vectors (such as hypervisor boundaries or hardware-enforced separation) may constitute effective mitigation for vulnerabilities that depend on those attack vectors. Such mitigations may extend remediation timelines or modify prioritization through the Plan of Action and Milestones (POAM) process, while the underlying software vulnerability still requires patching according to standard procedures."

3. Enhanced Deviation Justification Process

Issue: FRR-CVM-02 requires detailed vulnerability reporting that may benefit from clearer guidance on how infrastructure controls factor into deviation justifications.

Recommendation: Provide explicit guidance on how infrastructure-level security controls should be documented in deviation justifications and POAM development.

Suggested Addition:

"Providers implementing infrastructure-level security controls may reference these controls in deviation justifications and POAM development. Such documentation should include independent validation of control effectiveness, scope of protection, and residual risk assessment. This information supports risk-based prioritization decisions while maintaining full reporting requirements."

3. Enhanced Deviation Justification Process

Issue: FRR-CVM-02 requires detailed vulnerability reporting that may benefit from clearer guidance on how infrastructure controls factor into deviation justifications.

Recommendation: Provide explicit guidance on how infrastructure-level security controls should be documented in deviation justifications and POAM development.

Suggested Addition:
"Providers implementing infrastructure-level security controls may reference these controls in deviation justifications and POAM development. Such documentation should include independent validation of control effectiveness, scope of protection, and residual risk assessment. This information supports risk-based prioritization decisions while maintaining full reporting requirements."

Implementation Considerations

Timeline Feasibility
The proposed timelines (3 days for internet-reachable, 7 days for internal) are aggressive but achievable with proper automation. Organizations without automated remediation capabilities may struggle to meet these requirements, emphasizing the importance of secure-by-design approaches that prevent vulnerabilities from being exploitable.

Assessment Methodology
Third-party assessors (3PAOs) will need training and guidance on evaluating infrastructure-level security controls. FedRAMP should develop specific assessment criteria for architectural security measures.

Pilot Program Participation
Edera recommends that the FedRAMP 20x pilot program include organizations implementing different foundational security approaches to test the standard's applicability across various technical implementations. Specifically, the pilot should include:

1. Traditional shared-kernel container platforms (Docker, containerd)
2. Hypervisor-based container isolation solutions (Kata Containers, Firecracker, gVisor)
3. Hardware-enforced security architectures (Intel TXT, AMD Memory Guard, ARM TrustZone)
4. Network-based isolation approaches (micro-segmentation, zero-trust networking)
5. Traditional VM-based architectures with various hypervisors

This comprehensive testing approach will help validate whether the proposed enhancements appropriately recognize different security control mechanisms and ensure the standard doesn't inadvertently favor or exclude particular architectural approaches.
Edera recommends that the FedRAMP 20x pilot program include diverse security architectures to test the standard's applicability across different technical approaches, including secure-by-design solutions.

Technical Comments

Definition Refinements
FRD-CVM-07 (Internet-reachable): The current definition appropriately includes resources that process internet-triggered data. Consider expanding to explicitly include AI inference endpoints and API gateways that may not be directly internet-facing but process untrusted data.

FRR-CVM-TM-05: The 3-day remediation timeline for credibly exploitable vulnerabilities in internet-reachable resources should allow for "mitigation to non-exploitable" as an acceptable interim measure while permanent remediation is pursued.
Automation Integration

The standard's emphasis on automation aligns with industry trends toward Infrastructure as Code and DevSecOps practices. Consider providing guidance on integrating vulnerability management with CI/CD pipelines and container security scanning.
Innovation Incentives

This standard should encourage innovation in security architecture rather than simply improving detection and response to vulnerabilities. By recognizing and providing credit for secure-by-design approaches, FedRAMP can incentivize the development and adoption of more fundamentally secure technologies.

Organizations investing in advanced security architectures should not be penalized by having to treat prevented vulnerabilities the same as actual risks. This principle will encourage continued innovation in federal cybersecurity.

Final Thoughts
RFC-0012 represents an important evolution in federal cybersecurity requirements that appropriately emphasizes automation, risk-based approaches, and rapid response. With the enhancements suggested above, this standard can better accommodate the full spectrum of modern security technologies while maintaining the rigorous security posture required for federal systems.

Edera looks forward to participating in the FedRAMP 20x pilot program and working with federal agencies to demonstrate how secure-by-design infrastructure can simplify compliance while improving security outcomes. We appreciate FedRAMP's commitment to engaging with the security community and welcome the opportunity to provide additional technical input as this standard evolves.

For questions or clarification on these comments, please contact:
Kaylin Trychon | Edera
Website: https://edera.dev
Email: kaylin@edera.dev

[junefam]

FRD-CVM-05

Fully mitigate definition

As a practitioner, achieving complete vulnerability elimination is extremely difficult due to system complexity, prioritization constraints, and the fact that permanent removal is not always feasible. A more practical goal is reducing vulnerabilities to Very Low risk through secure implementation and compensating controls.

Demonstrating that an issue is fully mitigated is also challenging. It often requires continuous, automated testing and monitoring alerts to confirm that existing controls remain effective.

Recommendation
The minimum baseline security controls that must always be in place should be defined.

Clarification on what kinds of risk reduction approaches are acceptable when a vulnerability can’t be completely removed (e.g., compensating controls, monitoring, configuration hardening).

Vulnerability Response Time Frames

Sharing the same sentiment with many comments above, applying the same SLA across all vulnerability impact levels is not practical. While impact ratings do not always map directly to remediation effort, lower-severity findings can reasonably be tolerated with longer response times.

SLA timelines should account for the time required to remediate, validate through testing, and establish monitoring—processes that depend on feedback loops from practitioners.

Recommendation
Extending remediation timelines for Moderate and Low impact findings and gathering additional practitioner input to define realistic, achievable SLA targets.

---

Overall, this is a great step toward improving the vulnerability management program by incorporating both business and security context. As a practitioner, I find the traditional approach too rigid, since a High CVSS score does not always reflect the true urgency or business impact. An effective model should factor in exploitability, asset criticality, and operational impact to better guide prioritization and remediation efforts.

[cb-axon]

We support this RFC and believe it represents a strong and much-needed shift in FedRAMP’s approach to vulnerability management. By clearly distinguishing between overdue vulnerabilities requiring POA&Ms and those fully mitigated within the required timeframe, the program enables engineering teams to focus where it matters most. This change avoids burdening organizations with unnecessary administrative overhead while still preserving transparency through continuous assessments and reporting.

This direction mirrors the broader industry trend toward automation and continuous intelligence. Many tools are emerging that already provide threat context at the point of detection, and this standard harmonizes with that momentum. We view this as an exponential gain for the ecosystem, not just incremental.

We see substantial engineering resource savings in this model, with focus directed to truly credibly exploitable vulnerabilities - which, in a well-architected FedRAMP system, should be rare. This prioritization not only improves efficiency but also strengthens the quality of threat intelligence available to the broader community. When paired with context-based scoring, the approach moves beyond CVSS to reflect real risk more accurately, incorporating exploitability, impact, and mitigation status.

A particularly valuable element of this RFC is the definition of “Credibly Exploitable Vulnerability.” It provides appropriate discretion for CSPs to continuously build and maintain automation to make this determination, using multiple sources. Today, this may include feeds like CISA KEV and EPSS, but over time it can extend to new databases and threat intelligence sources as they emerge. This flexibility allows the standard to grow with the industry, rather than relying on frequent revisions that may not come in time. It also fosters CSP creativity in designing effective solutions, rather than having the standard prescribe the solution itself. In practice, this will enable ongoing innovation that directly improves security posture.

Automated risk assessment at the point of detection is critical to reducing noise. By immediately applying context such as exploitability, reachability, and potential adverse impact, automation helps separate routine vulnerabilities from those that truly require attention. The current model forces many routine patches that are not high risk to still require manual effort within 30 days, often just to risk-adjust. On top of that, arbitrary rules that prevent adjusting findings from high to low further stifle engineering teams from focusing on solving real security issues. Automation ensures engineering resources are directed toward the vulnerabilities that matter most, while minimizing distraction from low-risk findings that can otherwise overwhelm teams and slow response.

We do see a potential risk if CSPs are not empowered to adopt this methodology across the board due to differing requirements from other government agencies, such as DoD, who may continue requiring the “old” approach. This would dilute the benefits of the RFC and limit adoption of what is clearly a more effective and efficient methodology. To address this, we encourage OMB and GSA to bolster the awareness with other federal agencies with empirical evidence demonstrating the effectiveness of this approach, highlighting the risk-based value it provides to authorizing officials. Evidence-backed validation will help agencies feel confident in accepting the new methodology, rather than defaulting to legacy processes.

We also suggest strengthening the standard by including explicit methods to reduce false negatives (cases where a vulnerability is credibly exploitable with low-or-greater adverse impact, but is missed by CSP automated analysis). Guardrails that mitigate this risk would further ensure the effectiveness of the approach and bolster trust, while still preserving flexibility and innovation.

We would encourage some softening of the strict response timelines to balance operational realities with risk urgency. Nonetheless, allowing thoughtful discussions when those timelines can't be met is necessary. The shift to continuous reporting will foster more reasonable and meaningful conversations between providers and customers, moving beyond reactive compliance checklists to proactive security dialogue.

[Rene2mt]

Thanks FedRAMP PMO for this robust RFC, shifting from the legacy compliance mindset to an approach that prioritizes addressing the vulnerabilities that actually matter in the context of one's system. Please find my comments and recommendations below.

Summary & Motivation Section

Once the RFC phase is completed, a modified version informed by public comment will be tested and evaluated with volunteer cloud service providers during a 20x Pilot and Rev5 Beta Tests then routinely refined and improved.

• Comment: Given how significant a departure this standard is from current vulnerability management guidance, I'm glad there will be a pilot phase.
• Recommendation: The pilot should involve a variety of CSPs (e.g., hyperscale and small CSPs, IaaS, PaaS, SaaS) to really stress test the concepts being proposed in this RFC.

FRD-CVM-02

Credibly exploitable vulnerability: A vulnerability where a likely threat actor with knowledge of the vulnerability would likely be able to gain unauthorized access, cause harm, disrupt operations, or otherwise have an undesired adverse impact

• Comment: CEV definition seem a bit fuzzy to me, particularly due to the use of "likely". The term "likely" helps account for context in a given system, but I think the proposed definition below can account for that.
• Recommendation: Terms like Exploitability and/or Exploit Maturity seem more useful to me in conducting a risk analysis. In fact, maybe Credibly Exploitable should be defined a vulnerability that 1) has exploits in development or use and 2) a (determined) exploitability rating in the context of the system. Exploitability (e.g., from CVSS, EPSS, vendor ratings) could be adjusted by CSPs based on their specific system context (controls in place, etc.).

FRD-CVM-05

Fully Mitigate: Mitigate a vulnerability to the point where there is no reasonable probability of exploitation by any reasonable threat source, or the potential adverse impact of exploitation is Very Low; fully mitigated vulnerabilities still appear in assessments until they are remediated.

• Recommendation:
  • Consider changing "reasonable probability" to "very low or negligible probablility"
  • Consider changing "any reasonable threat source" to "a threat source".

FRD-CVM-07

Internet-reachable: Information resources that are reachable over the public internet such that anyone with an internet connection can interact with or deliver payloads to the information resource.

• Comment: This definition is simple yet likely to mean different things in the context of different systems, and could result in a lot of back and forth between CSPs, 3PAOs, and agency AOs.
• Recommendation: If not within the standard, please provide a supporting Technical Assistance guide with something like this to make sure all stakeholders have a common understanding (note, as new technologies or edge cases are identified, the CSPs could collaborate with FedRAMP PMO to expand the Technical Assistance)

[1] Does the resource have a public IP address?
 ├── Yes ──▶ Proceed to [2]
 └── No
     ↓
[1a] Can the resource receive traffic from the internet
     through a forwarding component (e.g., NAT Gateway,
     proxy, reverse proxy, load balancer, firewall, or 
     web hook listener) **without additional security controls**?
     ├── Yes ──▶ Internet-reachable
     └── No ──▶ Proceed to [5]

[2] Are any ports open to 0.0.0.0/0 (or equivalent)?
 ├── Yes ──▶ Internet-reachable
 └── No ──▶ Proceed to [3]

[3] Is the resource accessible from the internet
    without a tunnel (VPN/IAP/ZTNA)?
 ├── Yes ──▶ Internet-reachable
 └── No ──▶ Proceed to [4]

[4] Is access restricted to a known set of IPs via
    strong access controls (e.g., VPN, IAP, IP allow list)?
 ├── Yes ──▶ Not internet-reachable
 └── No ──▶ Internet-reachable

[5] Can the resource only be accessed from a private
    subnet or internal network (e.g., VPC-only)?
 ├── Yes ──▶ Not internet-reachable
 └── No ──▶ Investigate further

I'm sure folks will punch holes through this overly simplified decision tree BUT I think documenting something like it either in the standard or supporting Technical Assistance will result in a more precise definition and better-aligned understanding amongst all stakeholders.

FRR-CVM-02

• Recommendation:
  • Allow CSPs to consider reporting either vulnerabilities by "asset class" or individually per asset (FRR-CVM-09). Grouping by "asset class" may be more manageable and also better inform level of risk / rationale for derived risk level
  • Allow CSPs to optinally report on # of assets in class affected. Again, could be useful in assessing risk
  • Remove or make bullet # 8 optional. The remediation for the majority of vulnerabilities will likely be "apply patch ..."
  • Remove or make bullet # 9 optional. This RFC requires a 24 month retention of records. Alternatively, replace this with an append-only notes field
  • Remove or make bullet # 10 option. Most CSPs will have a generic security@mycloud.com address repeated for every vulnerability report.
  • Consider adding source field to provide details on how it was discovered (e.g., scanner, pentest, etc.)
  • Consider adding status field...may need to standardize on some common status values.
  • Consider adding one or more of the following fields (e.g.,title,summary, description)
  • Consider adding optional suggested customer action ...could be useful when there are actions customer can take to reduce their risk exposure.

FRR-CVM-03

Providers MUST make vulnerability reports available to all necessary parties in similar human-readable and compatible machine-readable formats, including at least FedRAMP, CISA, and all agency customers.

• Recommendation:
  • "Human-readable" kind of implies file (e.g., think legacy one pagers 😄), but we may want to explicitely state CSPs can/should freely explore other formats and delivery mechanisms, including files, (e.g., CSV, spreadsheet), APIs, and online dashboards.

FRR-CVM-04

Providers MUST adjust the risk and severity of vulnerabilities using CVSS base scores (if applicable) AND the context of the vulnerability, factoring for at least criticality, reachability, exploitability, detectability, prevalence, and mitigation, to determine if vulnerabilities are credibly exploitable and the potential adverse impact of exploitation.

• Comment: The phrasing "Must adjust the risk..." seems off at first.
• Recommendation: Change to something like
  • Provides MUST conduct a risk analysis of every detected vulnerability, and SHOULD consider CVSS base scores (if applicable), the context of the vulnerability, factoring for at least criticality, reachability, exploitability, detectability, prevalence, and mitigations to determine the adjusted risk and if the vulnerabilities are credibly exploitable.
    • CSPs should have some discretion and use their best judgement to include other factors that contribute to their risk adjustments

FRR-CVM-05

Providers SHOULD mitigate and/or remediate vulnerabilities promptly, within the time frames established in FRR-CVM-TM, and MUST create a FedRAMP Plan of Action & Milestones (or future equivalent) to address any vulnerabilities that will not be addressed within those time frames.

• Comment: I'm all for providing vulnerability reports (e.g., API, dashboard, etc.) per FRR-CVM-02 rather than spreadsheet POA&M. That data can be ingested by agencies for their POA&M management requirements.
• Recommendation: Very lows are understood to have no further action required, so they should be excluded from the POA&M but should be part of the vulnerability reports.

FRR-CVM-TM-01

Providers MUST provide up-to-date vulnerability reports to all necessary parties at least monthly and SHOULD provide these continuously.

• Comment: From a CSP perspective, being able to satisfy this via a publish/subscribe model, APIs or a dashboard greatly simplifies making this available to all necessary parties. Let's make this process as frictionless as possible.

FRR-CVM-TM-04

Providers SHOULD discover, analyze, and assess all internet-reachable resources for vulnerabilities using both authenticated and unauthenticated assessments continuously, otherwise at regular intervals at least every three calendar days.

• Comment: This is going to be a lot harder for larger or very large CSPs. Once you get past a certain # of assets, it seems like meeting the 3 calendar days to "discover, analyse, and assess" may not be feasible for super large systems. Surely, the pilot will help determine how well this requirement will scale.

FRR-CVM-TM-05

Providers SHOULD fully mitigate or remediate credibly exploitable vulnerabilities in internet-reachable resources promptly, within three calendar days of detection.

• Comment: Similar to previous comment, I have some concerns with how well this scales when dealing with a massive # of assets, or in some cases, legacy or monolithic systems (e.g., agencies that lift & shift legacy systems to the cloud) where expedited remediations might not be possible. Even with automation, most CSPs would probably need 24x7 coverage to (consistently) meet the three day requirement as not all mitigations or remediations may be automated. I completely understand the rationale for it but also recognize the challenges in meeting the requirement. Lastly, this is one requirement where perhaps one size does not fit all. If we are prioritizing vulnerability management based on risks, the system's impact level should also factor in the overall risk and the corresponding remediation timeframes.
• Recommendation:
  • Change "within three days of detection" to "within seven days of detection for high impact systems; 10 days of detection for moderate impact systems; 14 days of detection for low impact systems". This still exceeds FedRAMP's current requirements, shifts in the right direction, and could be adjusted in the future as SOAR, XDR and other solutions become more univeral.
  • update the quick reference "Vulnerability Response Time Frames" and "Discovery and Analysis Time Frames" tables accordgingly.

FRR-CVM-TM-07

• Comment: See FRR-CVM-TM-05 comment
• Recommendation:
  • Change "within seven days of detection" to "within fourteen days of detection for high impact systems; twenty-one days of detection for moderate impact systems; thirty days of detection for low impact systems".
• update the quick reference "Vulnerability Response Time Frames" and "Discovery and Analysis Time Frames" tables accordgingly.

FRR-CVM-TM-08

• Comment: See FRR-CVM-TM-05 comment
• Recommendation:
  • Change "within twenty-one days of detection" to "within thirty days of detection for high, moderate, and low impact systems".
• update the quick reference "Vulnerability Response Time Frames" and "Discovery and Analysis Time Frames" tables accordgingly.

[mjprager]

Microsoft Azure supports the direction of FedRAMP 20X, and in particular the improvements to Vulnerability Management represented in RFC 0012. This updated standard recognizes the security measures implemented through architecture often appreciably mitigates the original risk, and doesn’t put arbitrary limits like “can only move one level”.

A few comments and recommendations below (which I would like to note is far less than what I might have for comments on existing Vuln Mgmt standards...):

• Recommend changing from “MUST” to “SHOULD” in FRR-CVM-04 “Providers MUST adjust the risk and severity of vulnerabilities using CVSS base scores (if applicable) AND the context of the vulnerability, factoring for at least criticality, reachability, exploitability, detectability, prevalence, and mitigation, to determine if vulnerabilities are credibly exploitable and the potential adverse impact of exploitation.”.

• Clarify in the “Quick Reference – Vulnerability Response Time Frames” table that vulnerabilities which are Fully Mitigated (and therefore have a Very Low risk) do not need to be remediated within 6 months. Without this change, there is conflicting guidance on how to handle Very Low vulnerabilities (see definition in FRD-CVM-05 which includes “fully mitigated vulnerabilities still appear in assessments until they are remediated”). It’s unclear what “assessments” mean in this context, and regardless, if it’s fully mitigated, there is no value in continuing to report on it as a POAM.

• Concerns about “Including all weaknesses in the definition of a vulnerability”. Clearly this covers vuln scans, audits, pen test findings, and “self-declared” POAMs, but in a similar vein to RFC-0012 FedRAMP Continuous Vulnerability Management Standard #59 (comment), some may construe that there is a requirement to report unmitigated, non-public vulnerabilities, which may actually increase the risks for all. The reporting should be focused on published vulnerabilities (especially those actively exploited or highly critical) and shared only when mitigation or a fix is ready.

• Lastly, I suggest slight changes of the timeframes from:

Applies to	Reachability	Impact	Action	Max Time
Credibly exploitable vulnerabilities	Internet-reachable	Very High, High, Moderate, Low	Fully mitigate or remediate	3 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Very High, High, Moderate	Mitigate to Low or remediate	7 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Low	Fully mitigate or remediate	21 Days
All detected vulnerabilities	Both	Very Low	Fully mitigate or remediate	6 Months

To:

Applies to	Reachability	Impact	Action	Max Time from Detection
Credibly exploitable vulnerabilities	Internet-reachable	Very High, High, Moderate, Low	Fully mitigate or remediate	7 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Very High, High, Moderate	Mitigate to Low or remediate	14 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Low	Fully mitigate or remediate	30 Days
All detected vulnerabilities	Both	Remaining except Very Low	Fully mitigate or remediate	6 Months

*Very Low = no need to report anymore on POAM, should still appear in dashboards

Comments: This should not be construed that CSPs aren't taking credibly exploitable vulnerabilities seriously - we absolutely do. I've been in ConMon for almost six years now, and I can not recall ANY of the vulns in the past where we received an external mandate (such as an emergency directive) and the security team wasn't already on it. This won't change our mitigation and response urgency - the slight increase in time allows for detections to be fine tuned and/or fresh scans to come in, and those are a MUCH more reliable signal than manual tracking; it also allows for the compliance team to gather the story from security (without getting in their way and taking away efforts from driving mitigation/remediation) and as mentioned elsewhere; and allows for reasonable human time for the summary reporting of the remaining burndown plan, when you take in to account weekends. And as mentioned by others, moving with too much haste can potentially compromise availability.

I encourage the release of this as a balanced improvement, due to the considerable time savings it will have for both agencies and CSPs.

A hearty thanks to the FedRAMP PMO and the entire community for such thoughtful, passionate discussions on this important topic.

[davidking-777]

Thank you FedRAMP PMO for driving the modernization of the Continuous Vulnerability Management Standard. Microsoft 365 is encouraged by the goal to leverage existing commercial best-practices and tools and reduce the need for custom government-only reporting requirements.

RFC-12 is s significant improvement over existing processes, and we encourage the release to significantly improve the experience for both agencies and CSPs.

---

I offer the following comments to improve the standard:

• FRR-CVM-02

While I understand the importance of reporting all detected vulnerabilities, I agree with Salesforce that this is likely to be asymmetrically noisy for larger CSPs who perform continuous scanning and patching. The requirement for detailed reports including columns 5–8 should only apply to vulnerabilities that are mitigated or planned to be mitigated outside the provided timelines. Even if automated, filling in 5 through 8 for vulnerabilities that are automatically patched within the timelines is likely to be a significant effort.

• FRR-CVM-04

Recommend changing “MUST adjust the risk and severity of vulnerabilities” to “SHOULD adjust the risk and severity of vulnerabilities.”

• General Comment

Concur with HackerOne that specific guidance with regards to Vulnerability Disclosure Programs is needed with FedRAMP’s expansion to include “all weaknesses” in the required vulnerability reporting.
Prematurely reporting undisclosed, unmitigated vulnerabilities and centralizing this information for all CSPs is likely to significantly increase risk to the US Federal Government.

• Suggested Modification to Quick Reference - Vulnerability Response Time Frames

From:

Applies to	Reachability	Impact	Action	Max Time from Detection
Credibly exploitable vulnerabilities	Internet-reachable	Very High, High, Moderate, Low	Fully mitigate or remediate	3 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Very High, High, Moderate	Mitigate to Low or remediate	7 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Low	Fully mitigate or remediate	21 Days
All detected vulnerabilities	Both	Remaining except Very Low	Fully mitigate or remediate	6 Months

To:

Applies to	Reachability	Impact	Action	Max Time from Detection
Credibly exploitable vulnerabilities	Internet-reachable	Very High, High, Moderate, Low	Fully mitigate or remediate	7 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Very High, High, Moderate	Mitigate to Low or remediate	14 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Low	Fully mitigate or remediate	30 Days
All detected vulnerabilities	Both	Remaining except Very Low	Fully mitigate or remediate	6 Months

* Very Low = no need to report anymore on POAM, should still appear in dashboards

Explanation

The increase in time frame for reporting remediation of credibly exploited vulnerabilities is not an indication that CSPs don’t take them seriously or that they shouldn’t remediate within those timelines. Instead, the increase in timelines is suggested to allow CSPs sufficient time to rescan and prepare the necessary reporting for the US government. Furthermore, given that one of the chief risks outlined in FRD-CVM-09 is “degradation or loss of mission capability,” it is critical that CSPs be provided sufficient time to safely remediate while mitigating risks to availability and impacts on the services that enable key mission capabilities.

[pete-gov]

The following public comment was received via email from CSP-AB including an attached document. This was converted to markdown.

csp-ab-rfc-0012-comments.pdf

---

Email:

Here is the formal submission of the CSP-AB's comments for RFC-0012. It contains comments but also a suggested framework to implement the standard. While we know you are not going to respond we would welcome any areas where you think our collaboration would be valuable.Some of our members will be starting to model solutions and running systems that can execute the automated risk adjustments. Based on our thoughts these implementations will help clear the noise from vulnerability scans to focus on items that actually impact government data and missions.

We also will be defining schemas for reporting and dashboarding and feel like there are areas where our work could be used in the public domain or by the government.

Document:

RFC 12

CSPs will follow this basic process

1. Define Asset/Resource (which may include asset class) with the following attributes (other attributes might be added as appropriate by the individual CSP.)
   1. Type/function/role/service
   2. OS
   3. Location (external/internal)
   4. Applicable mitigations
2. When scanning the output, we will use the asset DB to apply the appropriate Asset Class Mitigations to the identified vulnerabilities
3. The Original risk rating may be adjusted manually/automatically based on mitigation (CSPs will be able to define their own rubric or leverage existing frameworks depending on their complexity and needs)
4. Each CSP may have a different way of applying those mitigations for risk reduction.
5. Each identified vulnerability/asset class pair will be put into a vulnerability dashboard.

The process of using this automation to enumerate the adjusted risk of the vulnerability/asset class pairs shall serve to meet the “assess” portion of the mitigation/remediation requirements.
The dashboard will report the number of vulnerabilities per asset or asset class and may include their risk levels.
This will fulfill the CSP’s vulnerability reporting requirements.
Information needed for an agency to manage their POAM reports for any manual finding and all vulnerabilities that are not fully mitigated/remediated within the SLA period will be provided for the Very High, High, and Moderate categories.

FRD-CVM-05 definition said: Fully Mitigate: Mitigate a vulnerability to the point where there is no reasonable probability of exploitation by any reasonable threat source, or the potential adverse impact of exploitation is Very Low; fully mitigated vulnerabilities still appear in assessments until they are remediated.

Very Lows are either fully mitigated or remediated. They will not be tracked via POAM though fully mitigated will remain in the vulnerability report and monitored for risk escalation but will not be added to POAM reports.

The Dashboard may include the following information

• Vulnerability
• Asset or Asset Class
• Discovery date
• Number of assets in the class affected
• Risk level
• Original risk level
• Mitigations applied

CSPs may get third party review and approval of the risk automated risk analysis, mitigation methodology, asset classification methodology and completeness of information if needed. CSPs will provide all methodology for asset classification, risk mitigation application and risk scoring to agencies to prove and provide assurance of the effectiveness of the security of the system.

Trend information should be available to assist agencies in understanding the health and effectiveness of the CSO. This will also ensure that vulnerabilities that cannot be mitigated within the appropriate SLA are elevated and given an actual mitigation/remediation plan that can be reviewed and tracked in the agency POAM.

Applies to	Reachability	Impact	Action	Max Time	Change To
Credibly exploitable vulnerabilities	Internet-reachable	Very High, High, Moderate, Low	Fully mitigate or remediate	3 Days	7 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Very High, High, Moderate	Mitigate to Low or remediate	7 Days	14 Days
Credibly exploitable vulnerabilities	Not internet-reachable	Low	Fully mitigate or remediate	21 Days	30 Days
All detected vulnerabilities	Both	Very Low	Fully mitigate or remediate	6 Months	6 Months

While this methodology does assess on discovery the timeline to remediate and/or fully mitigate especially at scale are aggressive. Partial mitigation is provided by the security architecture but to look at all assets and get to full mitigation and coordinate efforts across teams is not always possible in 3 days. Large complex systems need time to ensure that fixes also do not cause an even worse loss of CIA and introduce significant risk to the availability of critical systems supporting federal workloads. Some temporary mitigations might be used until the final mitigation/remediation plans are finalized and executed. The extra time does not slow progress but allows for focus on those identified issues before documentation and notification to agencies about the full remediation/mitigation strategy. This will also limit the back and forth on partial plans and information drift.

Information Provided to Agencies for Population of their Agency POAM

The CSPs will provide the following information to the agencies to populate their POAM items when the remediation/full mitigation is past the defined SLAs.

Fields:

• Source - Vuln scan (overdue per adjusted risk only), CSP self-declared, security findings from assessments, control gaps, manual findings, BODs, EOs, Inspector General (IG) findings
• Status - Detected, Evaluating, Mitigated, Fully Mitigated, Remediated, Accepted, for overdue items only
• Weakness Source Identifier(s) (vuln id, plugin id, CVE)
• Name/Summary/Title
• Vulnerability Description(s)
• CISA known exploitable vulnerabilities (KEV) & CISA KEV Due Dates
• Current Assigned Risk Rating
• Asset(s)/Class(es)
• Initial Date Discovered
• Remediation actions with dates
• Rationale
• Due Dates
• Suggested Customer Actions
• Notes - Any relevant information about overdue items or deviations from remediation plan

Because of the automated mitigation application in this framework, the detection and for the most part the evaluating categories will not be a status used in reporting more detailed information to the agencies. Only items that fall out of SLA will need more detailed information. The vuln report will carry the full mitigated but will not be managed unless the impact level changes or it could be part of a gov wide inquiry for prevalence in the government ecosystem.

Excluded:

First party non-CSO products with Internally known vulnerabilities that have no patch available or require no customer action to remediate. Releasing these vulnerabilities on a POAM is basically public exposure and would increase the likelihood of attempted exploitation. Additionally, most CSPs who have developed products and infrastructure also have other governments and industries that leverage the technology, and disclosure may and likely will create legal exposures.

[pete-gov]

The following public comment was received via email from Rubrik.

---

Thanks for the opportunity to provide feedback on RFC-0012. Rubrik comments captured below.

• Will FedRAMP require a separate vulnerability report in addition to the Plan of Action and Milestones (POA&M) template, and will FedRAMP provide a template for this report? Or is it the intent that the vulnerability report as described in FRR-CVM-02 will replace the existing POA&M? (FRR-CVM-02)
• Request that FedRAMP clarify whether a vulnerability severity may be risk-adjusted to a lower level than assessed by a scanning tool without a Deviation Request? (FRR-CVM-04)
• Request that FedRAMP clarify if there is any material difference between “credibly exploitable vulnerabilities” and “credibly exploitable impact vulnerabilities” as used in FRR-CVM-TM-07 and FRR-CVM-TM-08. (FRR-CVM-TM-07 / FRR-CM-TM-08)
• Request that FedRAMP provide clarification on what circumstances must exist in order for a vulnerability to be credibly exploitable. What set of circumstances should exist (or not) to make a vulnerability to more "likely" be exploited? (FRD-CVM-02)
• The definition of "internet-reachable" is overly broad. Request that FedRAMP provide clearer, more objective definitions of resources that would fall within this category. (FRD-CVM-07)
• Please clarify the scope of "Other weaknesses" as part of the FRD-CVM-01 definition. (FRD-CVM-01)
• Request that FedRAMP specify what "compatible machine-readable formats" is expected to include. (FRR-CVM-03)
• Request further clarity on how CSPs should track and report on vulnerabilities that fall into existing deviation categories (e.g. Operational Requirement, Vendor Dependency).

[pete-gov]

The following public comment was received via email from the Hacking Policy Council. It was also included as a PDF. Automated markdown conversion is included below.

HPC Comments on FedRAMP's Continuous Vulnerability Management Standard.pdf

---

Comments on FedRAMP’s Continuous Vulnerability Management Standard (RFC-0012)

August 21, 2025

The Hacking Policy Council (“HPC”) submits the following comments in response to the Request for Information (RFI) related to FedRAMP’s RFC-0012 - Continuous Vulnerability Management Standard.1 We thank FedRAMP for the opportunity to provide feedback and to work together on building a more effective security ecosystem.

The HPC is a group of experts dedicated to creating a more favorable legal, policy, and business environment for good faith security research, penetration testing, independent repair for security, and vulnerability disclosure and management.2 From this perspective, we respectfully offer the following recommendations to help better align FedRAMP’s standard with broader federal security objectives.

1. Role of Information Sharing in Vulnerability Management

We appreciate FedRAMP’s efforts to create greater consistency in how cloud service providers (CSPs) approach security for Executive departments and agencies.

Under RFC-0012, FedRAMP requires cloud service providers (CSPs) to immediately share unmitigated vulnerabilities that will likely have an impact on federal information. This requirement reflects an interpretation that goes beyond the Federal Information Security Modernization Act (FISMA)’s intent and may benefit from additional clarification. FISMA establishes a framework for securing federal information systems and directs agencies to implement policies and procedures to manage risks to their information and information systems. The accompanying OMB guidance, Circular A-130, provides further clarification on how agencies should implement these statutory requirements. It defines “information security continuous monitoring” as maintaining ongoing awareness of information security, vulnerabilities, threats, and incidents to support agency risk management.3In this context, the terms “continuous” and “ongoing” mean that security controls and agency risks are assessed and analyzed at a frequency sufficient to support risk-based security decisions that adequately protect the agency. Because this guidance emphasizes risk management rather than

1 FedRAMP RFC -0012, Continuous Vulnerability Management Standard https://www.fedramp.gov/rfcs/0012/ 2 Hacking Policy Council, https://hackingpolicycouncil.org.
3,Office of Management & Budget, Circular No. A-130: Managing Information as a Strategic Resource (revised Nov. 28, 2000), https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf.

1
information-sharing obligations for unmitigated vulnerabilities, we recommend that FedRAMP clarify how the proposed requirement aligns with existing statutory and policy frameworks. Providing this clarity would ensure that CSPs can meet FedRAMP expectations while maintaining consistency with broader federal guidance.

2. Risks of Premature Vulnerability Disclosure

FedRAMP’s proposed vulnerability disclosure sharing prior to identifying mitigations raises several concerns:

● Risk of alerting adversaries. Requiring that companies provide information about unmitigated vulnerabilities can increase the likelihood that malicious actors identify potential entry points within federal systems. Industry best practices for coordinated vulnerability disclosure emphasize limiting pre-mitigation sharing to minimize exposure and reduce the likelihood of exploitation. Even without sharing full technical details, CERT notes that “the mere knowledge of a vulnerability’s existence can be sufficient for a skilled attacker to discover and exploit it.”4 A critical consideration that RFC-0012 does not address is how sensitive vulnerability information will be safeguarded once reported. Requiring CSPs to provide immediate details of unmitigated vulnerabilities raises the question of who within the government is responsible for protecting this information, and what controls are in place to prevent unauthorized access or misuse. Creating a centralized repository of unmitigated vulnerabilities could therefore amplify risk, making CSPs, and by extension the federal systems they support, an even more attractive target for malicious actors.

● International precedent. There are international implications to consider. Similar approaches in foreign regulatory regimes, such as the European Union’s Cyber Resilience Act (CRA)5, mandate reporting unmitigated vulnerabilities to government authorities like ENISA.6 While we do not believe that FedRAMP’s guidelines are intended to create the same broad reporting requirements, there is a risk that other governments may interpret them as such. This misinterpretation could encourage similar mandates abroad – including in authoritarian or less secure regulatory environments – potentially undermining global cybersecurity resilience. Avoiding frameworks like the EU’s, which have faced international criticism, helps ensure that U.S. policies maintain strong security standards without producing unintended consequences.

Recommendation: To specifically address the issue of sharing unmitigated vulnerabilities in RFC-0012, we recommend editing FRR-CVM-07 and FRR-CVM-TM-01 as follows.

4 CERT, Guide to Coordinated Vulnerability Disclosure, 5.7 Disclosure Timing, Sep. 16, 2019, https://vuls.cert.org/confluence/display/CVD/5.7+Disclosure+Timing\#id-5.7DisclosureTiming-ReleasingPartialInf. 5 Cyber Resilience Act (CRA), https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act 6 Hacking Policy Council, Cyber Resilience Act - Vulnerability Reporting Obligation, March 2023, https://cdn.prod.website-files.com/62713397a014368302d4ddf5/648c6cc44c0f10df3fdf47a5\_CRA%20Vulnerability%2 0Disclosure%20Obligations%20-%20HPC%20-%20April%204%202023.pdf

2
FRR-CVM-07: Providers SHOULD MUST NOT share specific, unmitigated vulnerability information, but MUST SHOULD share sufficient information for oversight, tracking, analysis, action, and risk assessment with all necessary need parties on a need-to-know basis after mitigation is complete.

FRR-CVM-TM-01: Providers MUST provide up-to-date vulnerability reports to all necessary parties on a need-to-know basis at least monthly after mitigation of a vulnerability, and SHOULD provide ongoing updates as needed.

3. Integrating Coordinated Vulnerability Disclosure and Human-Augmented Systems

Given the risks associated with premature vulnerability disclosure, it is critical that any vulnerability management standard not only emphasizes rapid detection but also promotes secure, responsible practices that protect federal systems while fostering collaboration with the broader security community. While RFC-0012 currently states that providers “SHOULD use automated systems to identify, mitigate, and/or remediate credibly exploitable vulnerabilities in internet-reachable information resources with minimal or no human intervention,” HPC recommends amending this language to explicitly encourage the use of human-augmented systems.

Human-augmented approaches can increase speed and accuracy – including continuous penetration testing, bug bounty programs, and other coordinated vulnerability disclosure mechanisms – play a vital role in identifying vulnerabilities that automated systems alone may miss. These methods also help mitigate the risks associated with premature reporting and centralized repositories of sensitive vulnerability data by ensuring that information is handled responsibly and with appropriate safeguards. Incorporating both automated and human-driven practices ensures a more comprehensive and resilient vulnerability management strategy, leveraging the strengths of both approaches to better protect our nation’s critical infrastructure.

Recommendation: To specifically address this concern, we recommend amending FRR-CVM-06 as follows:

Providers SHOULD use both automated and human-augmented systems (e.g., penetration testing and continuous bug bounty programs) to identify, mitigate, and/or remediate credibly exploitable vulnerabilities in internet-reachable information resources. with minimal or no human intervention.

* * *

The HPC values FedRAMP’s leadership in strengthening the federal government’s cybersecurity posture and appreciates the opportunity to provide input on RFC-0012. As the vulnerability management standard evolves, we encourage FedRAMP to focus on three priorities: clarify how the requirements align with existing statutory and policy frameworks; ensure sensitive information is safeguarded through responsible reporting requirements; and incorporate both automated and human-augmented approaches to detection and mitigation. We

3
look forward to continuing to work with FedRAMP as a partner in advancing vulnerability management.

Thank you for considering our feedback and we look forward to working with you moving forward.

Sincerely,

The Hacking Policy Council

[pete-gov]

The following public comment was received via email from Adobe. These comments were included as a PDF and I guess if there's one company that might have a policy that they only send things as PDF instead of plain text it would be Adobe so this isn't a surprise. ;)

Adobe comments re continuous vuln management - 0012.pdf

---

Adobe Inc. Comments In Response to FedRAMP PMO RFC-0012 Aug. 21, 2025

Adobe appreciates the opportunity to provide feedback on RFC-0012, the proposed Continuous Vulnerability Management Standard.1 We commend the FedRAMP PMO for its continued efforts to modernize vulnerability management practices in a way that supports both agency oversight and operational efficiency for cloud service providers (CSPs). Below are Adobe’s comments on the draft standard.

1. Clarification of Definitions and Metrics

FRD-CVM-02 defines “credibly exploitable vulnerability” but does not impose a specific metric regarding how this determination should be made. We appreciate that the PMO intends to provide companies with flexibility, and we encourage the PMO to help ensure the draft standard clearly communicates that CSPs can use a variety of tools, vendor software, or established metrics such as the Exploit Prediction Scoring System (EPSS) for this determination. These tools provide data-driven assessments of exploitability and are already used by many CSPs to prioritize vulnerabilities based on real-world threat intelligence.

FRD-CVM-07 expands the definition of “internet-reachable” to include systems that process payloads triggered by internet activity, even if they are not directly accessible from the internet. This appears to contradict the core definition, as “internet-reachable” implies inbound connectivity – where external networks can initiate communication with the system. In our experience, systems that are not directly exposed to the internet typically incorporate defense-in-depth safeguards that help mitigate risk from vulnerabilities. Expanding the “internet-reachable” concept risks creating unnecessary alerts and confusion. We recommend maintaining the narrower scope of “internet reachable” and clarifying that outbound-only tools, systems, and services that are not internet-exposed are out of scope.

2. Vulnerability Reporting Requirements

FRR-CVM-02 introduces several new reporting elements:

a. Point 1 references “grouping of similar vulnerabilities.” We support this approach and

recommend explicitly cross-referencing FRR-CVM-09, which provides helpful guidance on grouping by shared characteristics such as root cause or remediation strategy. This would also support grouping POA&M entries by fix action, which would streamline reporting and remediation tracking.

b. Point 3 requires timelines for detection, mitigation, and remediation. We recommend clarifying

how this will be reflected in the POA&M, such as whether new columns will be added.

1 https://www.fedramp.gov/rfcs/0012/

1

Additionally, if a CSP remediates a vulnerability without a separate mitigation step, please clarify if “N/A” or other indicator would be acceptable for the mitigation field. We recommend a flexible approach to both points, as vulnerability types differ and organizations require time to assess and mitigate. If the PMO envisions a flexible approach, we recommend making this clear in the final standard.

c. Point 4 again references “internet-reachable” status. As noted above regarding Point 1, we

recommend clarification that this does not include outbound-only connectivity.

d. Points 7 and 8 use “and/or” while Point 3 uses “and.” We recommend standardizing this

language and providing clarification on whether mitigation is optional when remediation is performed directly.

3. Risk Adjustment and Use of External Tools

FRR-CVM-04 requires providers to adjust vulnerability severity using both CVSS and contextual factors. We support this approach and again suggest that tools like EPSS or commercial scoring software be explicitly permitted to support these assessments. This would promote consistency and reduce subjectivity in determining exploitability and impact.

4. POA&M Alignment and Reporting Sensitivity

FRR-CVM-05 requires a POA&M entry for any vulnerability not addressed within the prescribed timeframes. We recommend confirming whether CSPs should begin adjusting their POA&M templates now or wait for updated guidance.

FRR-CVM-07 advises against sharing sensitive vulnerability information that could lead to exploitation. However, FRR-CVM-02 and FRR-CVM-03 require detailed reporting, including CVEs, asset exposure, and exploitability. We recommend clarifying how CSPs should balance these requirements, especially when sharing reports with multiple agencies, to avoid incurring risks of premature public disclosure of the vulnerability information.

5. Positive Developments and Suggested Enhancements

We commend the PMO for several forward-looking provisions:

a. FRR-CVM-09 is a major improvement, allowing vulnerability grouping for more efficient tracking

and reporting.

2

b. FRR-CVM-TM-01 is a welcome shift toward continuous vulnerability management and away

from point-in-time reporting.

We also offer the following suggestions:

a. FRR-CVM-TM-03: The remediation timeline for Known Exploited Vulnerabilities (KEVs) should account

for detection date. For example, if a KEV is detected after its CISA due date, the remediation window (e.g., 21 days) should begin from the detection date.

b. Quick Reference Table: The “Impact” column omits “Very Low” in several rows. For example, a credibly exploitable vulnerability with Very Low impact on an internet-reachable asset is not addressed. We recommend including this case and clarifying its associated SLA. Additionally, the action for non- internet-reachable vulnerabilities should allow mitigation to “Very Low,” not just “Low.”

* * *

Adobe supports the direction of RFC-0012 and appreciates the PMO’s efforts to modernize vulnerability management in a way that is both rigorous and practical. We look forward to continued collaboration and are happy to provide further input as the standard evolves.

Please do not hesitate to contact us if we can provide additional input or clarification.

[pete-gov]

The following public comment was submitted via the Public Comment Form by Datavant.

---

Datavant appreciates the opportunity to provide feedback on the RFC-0012 Continuous Vulnerability Management Standard. We commend FedRAMP for their continued commitment to reducing risk to federal systems by ensuring Cloud Service Providers (CSPs) promptly detect, respond, and report critical vulnerabilities.

Datavant is the data collaboration platform trusted for healthcare. With a mission to make the world’s health data secure, accessible, and actionable, Datavant works with payers, providers, life sciences, legal and insurance clients globally to accelerate insights. Datavant enables more than 60 million healthcare records to move between thousands of organizations across the healthcare ecosystem, more than 80,000 hospitals and clinics, 75% of the 100 largest health systems, 300+ real-world data partners, and 17 Federal, State, Local Government Agencies.

Datavant fully supports FedRAMPs objectives but believes that implementation details must be adjusted for operational feasibility and to meet expected outcomes. As drafted, RFC-0012 imposes infeasible requirements that would undermine, rather than strengthen, vulnerability management—presenting significant challenges for reasonable and sustainable compliance. Datavant urges FedRAMP to recalibrate requirements to align with industry best practices and welcomes the opportunity to collaborate further. We have outlined our specific areas of concern below with the associated recommendations.

Datavant’s feedback on the proposed definitions or requirements of concern are split into two categories: (1) requirements that are misaligned with implementation realities, and (2) requirements that create excessive operational burden. We have offered recommendations below to address the spirit of these requirements through vulnerability management industry best practices.

1. Requirements Misaligned with Implementation Realities

FRR-CVM-TM-04, FRR-CVM-TM-06, FRR-CVM-TM-09

Concern: The requirements for “authenticated” scans do not account for assets that are unable to be scanned in an authenticated manner, whether by inability for an agent to be installed or technical limitations preventing authentication into the target.

Recommendation: Adjust the requirements to be clearer and specify that authenticated scans are to be performed only on asset types that are technically compatible with such methods, ensuring scan requirements are aligned with asset capabilities.

FRR-CVM-TM-05, FRR-CVM-TM-07, FRR-CVM-TM-08. FRR-CVM-TM-09

Concern: In large-scale environments, vulnerability scans can generate a high volume of findings. Assessing each for exploitability and contextual risk requires considerable time and expertise, which naturally delays remediation efforts. Remediation itself often takes days due to triage, vendor dependencies, and cross-team coordination. Additionally, vendor patch cycles do not always align with the RFC proposed timelines—resulting in situations where it would not be possible to remediate. Patching and configuration changes require structured steps—change management, testing, and collaboration—that are inherently time-consuming. These steps exist to preserve system stability and mitigate causing an incident (that could potentially be just as impactful as a vulnerability being exploited). The proposed timelines overlook these operational realities.

Recommendation: Implementing a tiered remediation based on risk and context and increasing SLAs to support detection triage requirements and CSP operational realities.

Critical/High Credibly Exploitable (internet facing) - 7 days
Critical/High Credibly Exploitable (NOT internet facing) - 30 days
Medium Risk Credibly Exploitable (internet facing) - 30 days
Medium Risk Credibly Exploitable (NOT internet facing) - 60 days
Low Risk Credibly Exploitable (internet facing) - 60 days
Low Risk Credibly Exploitable (NOT internet facing) - 90 days
All detected vulnerabilities (internet reachable or not) - 180 days

Additionally, the administrative burden associated with POAM development can be significantly reduced under the proposed SLA model, as extended remediation timelines would allow teams to focus on resolving vulnerabilities directly, rather than diverting resources to documentation efforts.

FRR-CVM-05

Concern: The phrase “…to address any vulnerabilities that will not be addressed within those time frames” suggests CSPs must forecast which vulnerabilities may miss SLA deadlines, rather than simply report those unresolved after the fact. Accurately predicting this is impractical and requiring it creates unnecessary operational burden—compared to reporting only past-SLA vulnerabilities.

Recommendation: Require a FedRAMP Plan of Action & Milestones (or equivalent) only for vulnerabilities unresolved beyond SLA deadlines.

FRR-CVM-06

Concern: Automated mitigation or remediation bypasses prudent change control and testing and introduces significant risk in CSP environments. Such controls can trigger outages or other impacts as severe as, or worse than, an actual exploit.

Recommendation: Eliminate the concept of automated mitigation or remediation from the RFC.

2. Requirements that Create Excessive Operational Burden

FRD-CVM-02

Concern: “…vulnerabilities must be reachable and unmitigated to be credibly exploitable.” For non–public-facing systems, reachability is difficult to predict. The only definitive proof comes if an attacker has already bypassed perimeter defenses—at which point the issue is a security incident, not a vulnerability management matter.

Recommendation: Scope the defined term “Credibly exploitable vulnerability” to apply only to “Internet-reachable” (FRD-CVM-07) and/or “Known Exploited Vulnerability” (FRD-CVM-08), where the attribute of Attack-Complexity = Low applies to the latter.

FRR-CVM-02

Concern: Not all attributes listed in the proposed requirement align with POAM requirements and are not always utilized or supported by scan tooling.

Recommendation: Report attributes should be required only where technically feasible, supported by CSP scanning tools, and not imposing undue operational burden. Attributes unnecessary for effective tracking (e.g., internal unique identifiers) should not be mandated.

Datavant fully supports FedRAMP’s purpose and objective of strengthening continuous vulnerability management. However, RFC-0012, as currently drafted, would create infeasible obligations that undermine security rather than advance it.

We urge FedRAMP to adopt risk-based, technically achievable standards grounded in industry best practice as recommended above. Doing so will ensure that continuous monitoring is both effective and sustainable for CSPs, thereby protecting federal systems without introducing new operational risks. Datavant is prepared to collaborate further to ensure the final standard reflects this balance.

[pete-gov]

The following public comment was received via the Public Comment Form from Elastic.

---

The proposed changes introduce an element of subjectivity into determining whether vulnerabilities are “credibly exploitable.” While giving CSPs more flexibility to make this determination within their specific environments can be valuable, it may also lead to increased internal debate about exploitability rather than focusing on timely remediation.

FedRAMP guidance does address this by urging CSPs to remediate vulnerabilities—especially KEVs—whenever possible. For mature CSPs with well-aligned teams, these changes could enhance the ability to define clear parameters for “credibly exploitable” vulnerabilities, enabling more effective automation and streamlining of remediation or mitigation processes.

However, for organizations without such alignment, increased subjectivity could complicate compliance efforts, particularly if remediation teams frequently push back or seek exceptions instead of addressing vulnerabilities.

Additionally, the current framing of “credible exploitability” appears more focused on external threat actors. Insider threats, which may have greater capacity to bypass perimeter protections, should also be considered.

Question for FedRAMP PMO: How does the PMO intend for CSPs to incorporate insider threat considerations into their determinations of whether a vulnerability is “credibly exploitable”?