KSI-AFR-VDR—Vulnerability Detection and Response
Formerly KSI-AFR-04
>Control Description
>NIST 800-53 Controls
>FRMR Requirements42
Normative requirements from the FedRAMP Requirements and Recommendations document — 14 mandatory, 22 recommended, 6 optional.
Vulnerability Detection
Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering using appropriate techniques such as assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, supply chain monitoring, and other relevant capabilities; this process is called vulnerability detection.
Vulnerability Response
Providers MUST systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities within their cloud service offering; this process is called vulnerability response.
Documentation for Recommendations
Providers MUST document the reason and resulting implications for their customers when choosing not to meet FedRAMP recommendations in this process; this documentation MUST be included in the authorization data for the cloud service offering.
Evaluate Exploitability
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities.
The simple reality is that most traditional vulnerabilities discovered by scanners or during assessment are not likely to be exploitable; exploitation typically requires an unrealistic set of circumstances that will not occur during normal operation. The likelihood of exploitation will vary depending on so many factors that FedRAMP will not recommend a specific framework for approaching this beyond the recommendations and requirements in this document.
The proof, ultimately, is in the pudding - providers who regularly evaluate vulnerabilities as not likely exploitable without careful consideration are more likely to suffer from an adverse impact where the root cause was an exploited vulnerability that was improperly evaluated. If done recklessly or deliberately, such actions will have a potential adverse impact on a provider's FedRAMP authorization.
Evaluate Internet-Reachability
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities.
FedRAMP focuses on internet-reachable (rather than internet-accessible) to ensure that any service that might receive a payload from the internet is prioritized if that service has a vulnerability that can be triggered by processing the data in the payload.
The simplest way to prevent exploitation of internet-reachable vulnerabilities is to intercept, inspect, filter, sanitize, reject, or otherwise deflect triggering payloads before they are processed by the vulnerable resource; once this prevention is in place the vulnerability should no longer be considered an internet-reachable vulnerability.
A classic example of an internet-reachable vulnerability on systems that are not typically internet-accessible is [SQL injection](https://en.wikipedia.org/wiki/SQL_injection), where an application stack behind a load balancer and firewall with no ability to route traffic to or from the internet can receive a payload indirectly from the internet that triggers the manipulation or compromise of data in a database that can only be accessed by an authorized connection from the application server on a private network.
Another simple example is the infamous Log4Shell (https://en.wikipedia.org/wiki/Log4Shell) vulnerability from 2021, where exploitation was possible via vulnerable internet-reachable resources deep in the application stack that were often not internet-accessible themselves.
Estimate Potential Adverse Impact
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the potential adverse impact of exploitation on government customers AND assign one of the following potential adverse impact ratings:
Monthly Activity Report
Providers MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly.
Mark Accepted Vulnerabilities
Providers MUST categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability.
Persistent Reporting
Providers MUST report vulnerability detection and response activity to all necessary parties persistently, summarizing ALL activity since the previous report; these reports are authorization data and are subject to the FedRAMP Authorization Data Sharing (ADS) process.
Responsible Disclosure
Providers MUST NOT irresponsibly disclose specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.
Vulnerability Details
Providers MUST include the following information (if applicable) on detected vulnerabilities when reporting on vulnerability detection and response activity, UNLESS it is an accepted vulnerability:
- Provider's internally assigned tracking identifier
- Time and source of the detection
- Time of completed evaluation
- Is it an internet-reachable vulnerability or not?
- Is it a likely exploitable vulnerability or not?
- Historically and currently estimated potential adverse impact of exploitation
- Time and level of each completed and evaluated reduction in potential adverse impact
- Estimated time and target level of next reduction in potential adverse impact
- Is it currently or is it likely to become an overdue vulnerability or not? If so, explain.
- Any supplementary information the provider responsibly determines will help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the vulnerability
- Final disposition of the vulnerability
Accepted Vulnerability Info
Providers MUST include the following information on accepted vulnerabilities when reporting on vulnerability detection and response activity:
- Provider's internally assigned tracking identifier
- Time and source of the detection
- Time of completed evaluation
- Is it an internet-reachable vulnerability or not?
- Is it a likely exploitable vulnerability or not?
- Currently estimated potential adverse impact of exploitation
- Explanation of why this is an accepted vulnerability
- Any supplementary information the provider determines will responsibly help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the accepted vulnerability
Notify FedRAMP
Agencies MUST notify FedRAMP after requesting any additional vulnerability information or materials from a cloud service provider beyond those FedRAMP requires by sending a notification to [info@fedramp.gov](mailto:info@fedramp.gov).
Implementation Summaries
Providers MUST maintain simple high-level summaries of at least the following for each Key Security Indicator:
- Goals for how it will be implemented and validated, including clear pass/fail criteria and traceability
- The consolidated _information resources_ that will be validated (this should include consolidated summaries such as "all employees with privileged access that are members of the Admin group")
- The machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- The non-machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- Current implementation status
- Any clarifications or responses to the assessment summary
Group Vulnerabilities
Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to identify logical groupings of affected information resources that may improve the efficiency and effectiveness of vulnerability response by consolidating further activity; requirements and recommendations in this process are then applied to these consolidated groupings of vulnerabilities instead of each individual detected instance.
Evaluate False Positives
Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are false positive vulnerabilities.
Evaluation Factors
Providers SHOULD consider at least the following factors when considering the context of the cloud service offering to evaluate detected vulnerabilities:
- **Criticality**: How important are the systems or information that might be impacted by the vulnerability?
- **Reachability**: How might a threat actor reach the vulnerability and how likely is that?
- **Exploitability**: How easy is it for a threat actor to exploit the vulnerability and how likely is that?
- **Detectability**: How easy is it for a threat actor to become aware of the vulnerability and how likely is that?
- **Prevalence**: How much of the cloud service offering is affected by the vulnerability?
- **Privilege**: How much privileged authority or access is granted or can be gained from exploiting the vulnerability?
- **Proximate Vulnerabilities**: How does this vulnerability interact with previously detected vulnerabilities, especially partially or fully mitigated vulnerabilities?
- **Known Threats**: How might already known threats leverage the vulnerability and how likely is that?
Design For Resilience
Providers SHOULD make design and architecture decisions for their cloud service offering that mitigate the risk of vulnerabilities by default AND decrease the risk and complexity of vulnerability detection and response.
Automate Detection
Providers SHOULD use automated services to improve and streamline vulnerability detection and response.
Detect After Changes
Providers SHOULD automatically perform vulnerability detection on representative samples of new or significantly changed information resources.
Maintain Security
Providers SHOULD NOT weaken the security of information resources to facilitate vulnerability scanning, detection, or assessment activities.
Avoid KEVs
Providers SHOULD NOT deploy or otherwise activate new machine-based information resources with Known Exploited Vulnerabilities.
Remediate KEVs
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) as required by CISA Binding Operational Directive (BOD) 22-01 or any successor guidance from CISA.
Historical Activity
Providers SHOULD make all recent historical vulnerability detection and response activity available in a machine-readable format for automated retrieval by all necessary parties (e.g. using an API service or similar); this information SHOULD be updated persistently, at least once every 14 days.
Persistent Sample Detection
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 3 days.
Persistent Drift Detection
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 14 days.
Persistent Complete Detection
Providers SHOULD persistently perform vulnerability detection on all information resources that are NOT likely to drift, at least once every month.
Evaluate Vulnerabilities Quickly
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-EVA (Evaluation) within 5 days of detection.
Mitigation and Remediation Expectations
Providers SHOULD partially mitigate, fully mitigate, or remediate vulnerabilities to a lower potential adverse impact within the timeframes from evaluation shown below (in days), factoring for the current potential adverse impact, internet reachability, and likely exploitability:
Remaining Vulnerabilities
Providers SHOULD mitigate or remediate remaining vulnerabilities during routine operations as determined necessary by the provider.
Internet-Reachable Incidents
Providers SHOULD treat internet-reachable likely exploitable vulnerabilities with a potential adverse impact of N4 or N5 as a security incident until they are partially mitigated to N3 or below.
High-Level Overviews
Providers SHOULD include high-level overviews of ALL vulnerability detection and response activities conducted during this period for the cloud service offering; this includes vulnerability disclosure programs, bug bounty programs, penetration testing, assessments, etc.
Review Vulnerability Reports
Agencies SHOULD review the information provided in vulnerability reports at appropriate and reasonable intervals commensurate with the expectations and risk posture indicated by their Authorization to Operate, and SHOULD use automated processing and filtering of machine readable information from cloud service providers.
Maintain Agency POA&M
Agencies SHOULD use vulnerability information reported by the Provider to maintain Plans of Action & Milestones for agency security programs when relevant according to agency security policies (such as if the agency takes action to mitigate the risk of exploitation or authorized the continued use of a cloud service with accepted vulnerabilities that put agency information systems at risk).
Do Not Request Extra Info
Agencies SHOULD NOT request additional information from cloud service providers that is not required by this FedRAMP process UNLESS the head of the agency or an authorized delegate makes a determination that there is a demonstrable need for such.
Application within MAS
Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.
6 optional guidance (MAY)
Additional Requirements
FedRAMP MAY require providers 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.
Sensitive Details
FedRAMP MAY required providers to share 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.
Sampling
Providers MAY sample effectively identical information resources, especially machine-based information resources, when performing vulnerability detection UNLESS doing so would decrease the efficiency or effectiveness of vulnerability detection.
Non-Internet-Reachable Incidents
Providers MAY treat likely exploitable vulnerabilities that are NOT internet-reachable with a potential adverse impact of N5 as a security incident until they are partially mitigated to N4 or below.
Responsible Public Disclosure
Providers MAY responsibly disclose vulnerabilities publicly or with other parties if the provider determines doing so will NOT likely lead to exploitation.
AFR Order of Criticality
Providers MAY use the following order of criticality for approaching Authorization by FedRAMP Key Security Indicators for an initial authorization package:
- Minimum Assessment Scope (MAS)
- Authorization Data Sharing (ADS)
- Using Cryptographic Modules (UCM)
- Vulnerability Detection and Response (VDR)
- Significant Change Notifications (SCN)
- Persistent Validation and Assessment (PVA)
- Secure Configuration Guide (RSC)
- Collaborative Continuous Monitoring (CCM)
- FedRAMP Security Inbox (FSI)
- Incident Communications Procedures (ICP)
>Trust Center Components4
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express vulnerability posture through automated dashboards — scanner APIs feeding live severity distributions, CISA KEV matching running continuously, and remediation SLA compliance tracked as a real-time metric. VDR dashboards go beyond simple scan counts to show N-rating distributions, attack surface graph analysis, and remediation velocity trends that prove risk is actively managed.
Vulnerability Metrics Dashboard
Dashboard expressing vulnerability posture — severity distributions, remediation SLA compliance, and resolution velocity as live metrics
Vulnerability Disclosure Program
How external researchers report vulnerabilities — scope, safe harbor provisions, and submission process as a product feature
Vulnerability Scan Reports
Scan results expressing coverage and remediation rates — generated from automated scanning pipelines
Remediation SLA Policy
Human-readable SLAs for vulnerability remediation by severity (Critical: 30 days, High: 60 days per FedRAMP)
>Programmatic Queries
CLI Commands
snyk test --severity-threshold=medium --json | jq '{total: .vulnerabilities | length, critical: [.vulnerabilities[] | select(.severity=="critical")] | length, high: [.vulnerabilities[] | select(.severity=="high")] | length}'snyk iac test --severity-threshold=medium>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does your vulnerability scanning cover all in-scope asset types — containers, serverless functions, IaC templates, APIs, and third-party dependencies — or are there blind spots?
- •How do you ensure vulnerabilities in inherited or shared-responsibility components (e.g., managed services, OS images) are also detected and tracked?
- •Are there any classes of vulnerabilities (logic flaws, misconfigurations, supply chain) not covered by your automated scanning, and how are those gaps addressed?
- •When risk acceptances or deviations from remediation timelines are approved, how do you document the justification and track the residual risk?
Automation & Validation:
- •What happens if a vulnerability scan fails to complete or returns incomplete results — how is the failure detected and the scan retried?
- •How do you automatically validate that a remediated vulnerability is actually fixed and not just marked as closed (e.g., re-scanning after patching)?
- •What automated workflow triggers when a critical or high vulnerability is discovered, and what is the maximum time from detection to first response?
- •How do you prioritize vulnerabilities using exploitability data (EPSS, KEV catalog, active exploitation intelligence) in addition to CVSS scores?
Inventory & Integration:
- •What scanning tools compose your VDR stack (infrastructure scanners, DAST, SAST, SCA, container scanning), and how do findings aggregate into a single view?
- •How does your vulnerability management platform integrate with your ticketing system to ensure every finding becomes an assignable, trackable work item?
- •Are vulnerability findings correlated with your asset inventory to confirm every in-scope resource has been scanned?
- •How do you track vulnerabilities that span multiple tools or detection methods to avoid duplicate tracking or missed remediation?
Continuous Evidence & Schedules:
- •How do you demonstrate compliance with FedRAMP remediation timeframes (critical: 30 days, high: 30 days, moderate: 90 days) across all findings?
- •Is vulnerability data (open findings, remediation timelines, scan coverage) available via API for FedRAMP or agency consumption?
- •How do you detect when scan coverage drops — for example, when new assets are deployed but not yet included in scanning schedules?
- •What evidence shows continuous vulnerability detection and response activity between formal assessment cycles?
Update History
Ask AI
Configure your API key to use AI features.