RA-5 Vulnerability monitoring and scanning
What the standard requires
a. Monitor and scan for vulnerabilities in the system and hosted applications [organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system are identified and reported; b. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: 1. Enumerating platforms, software flaws, and improper configurations; 2. Formatting checklists and test procedures; and 3. Measuring vulnerability impact; c. Analyze vulnerability scan reports and results from vulnerability monitoring; d. Remediate legitimate vulnerabilities [response times] in accordance with an organizational assessment of risk; e. Share information obtained from the vulnerability monitoring process and control assessments with [personnel or roles] to help eliminate similar vulnerabilities in other systems; and f. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.
Quoted verbatim from NIST SP 800-53 Rev 5 (OSCAL catalog), which is in the public domain.
Maps to 3 controls in 3 other frameworks
Mappings are CMDash’s own, seeded with the product and shown on both frameworks they connect. In the product they mean evidence you attach here also counts against the controls listed above.
Integrations that carry evidence for this family
These connectors produce data relevant to FedRAMP Moderate’s Risk Assessment family, which is the granularity CMDash publishes — there is no pre-built per-control mapping, and claiming one would be inventing it. You decide which evidence answers which control.
In CMDash this control is a row with an owner, a status, uploaded evidence kept with its full history, and an export an assessor can read.