Compliance
Vulnerability management is not optional. Nearly every regulatory framework that governs software security requires organizations to identify, track, and remediate known vulnerabilities in their systems. Whether you are shipping software to the federal government, processing payment card data, or operating a SaaS platform, continuous vulnerability scanning is a baseline expectation — not a nice-to-have.
NIST SP 800-53
Security and privacy controls for information systems and organizations.
NIST SP 800-53 is the foundational control catalog used by federal agencies and many private-sector organizations. Three control families are directly relevant to vulnerability scanning:
RA-5: Vulnerability Monitoring and Scanning
Requires organizations to scan for vulnerabilities in information systems and hosted applications at a defined frequency, analyze scan results, and remediate legitimate vulnerabilities within organization-defined response times. RA-5 also mandates sharing vulnerability information across the organization to enable situational awareness.
SI-2: Flaw Remediation
Requires organizations to identify, report, and correct information system flaws. This includes installing security-relevant software updates within defined time periods and incorporating flaw remediation into the configuration management process. SI-2 establishes that scanning alone is insufficient — organizations must also track remediation to closure.
CM-8: System Component Inventory
Requires organizations to develop and maintain an inventory of system components that is accurate, current, and at a level of granularity sufficient for tracking and reporting. In the context of container scanning, this maps directly to maintaining a software bill of materials (SBOM) for deployed artifacts.
NIST SP 800-171
Protecting Controlled Unclassified Information (CUI) in nonfederal systems.
NIST SP 800-171 defines the security requirements for protecting CUI when it resides on nonfederal systems. It is the basis for DFARS 252.204-7012, making it mandatory for all Department of Defense (DoD) contractors and subcontractors. Two requirements address vulnerability management directly:
- 3.11.2 — Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified and reported.
- 3.11.3 — Remediate vulnerabilities in accordance with risk assessments.
For organizations pursuing CMMC (Cybersecurity Maturity Model Certification), these controls are assessed at Level 2 and above. Failure to demonstrate active vulnerability scanning and remediation will result in assessment findings.
FedRAMP
Federal Risk and Authorization Management Program for cloud service providers.
FedRAMP requires cloud service providers (CSPs) selling to federal agencies to implement continuous monitoring, which includes monthly vulnerability scanning of all system components. Key requirements include:
- Monthly operating system and application-level vulnerability scans with results reported to the authorizing agency.
- High-severity findings (CVSS 7.0+) must be remediated within 30 days. Critical findings (CVSS 9.0+) require remediation within 15 days in some agency-specific baselines.
- All findings not remediated within the defined window must be documented in a Plan of Action and Milestones (POA&M) with target completion dates.
- Container images used in production must be scanned before deployment and rescanned on a recurring basis.
FedRAMP continuous monitoring reports are reviewed by agency Authorizing Officials, making scan accuracy and completeness a direct factor in maintaining authorization.
Executive Order 14028
Improving the nation's cybersecurity through software supply chain transparency.
Executive Order 14028 (May 2021) established that software vendors selling to the federal government must provide a Software Bill of Materials (SBOM) for their products. The NTIA defined the minimum elements that an SBOM must include:
- Supplier name for each component
- Component name and version string
- Unique identifiers (such as CPE or PURL)
- Dependency relationships between components
- Author of the SBOM data
- Timestamp indicating when the SBOM was generated
The order also directs agencies to adopt a "zero trust" architecture and mandates that critical software vendors attest to secure development practices. SBOM generation is no longer a voluntary best practice — it is a contractual requirement for federal procurement.
PCI-DSS 4.0
Payment Card Industry Data Security Standard for organizations handling cardholder data.
PCI-DSS 4.0 applies to any organization that stores, processes, or transmits credit card data. Two requirements are directly relevant to vulnerability scanning:
Requirement 6: Develop and Maintain Secure Systems and Software
Requires organizations to establish a process for identifying and assigning risk rankings to newly discovered vulnerabilities, and to install applicable security patches within defined timeframes. Critical patches must be installed within one month of release. Custom application code must be reviewed for vulnerabilities before deployment.
Requirement 11.3: Vulnerability Scanning
Mandates internal vulnerability scans at least quarterly and after any significant change. External scans must be performed by an Approved Scanning Vendor (ASV). Scans must achieve a "passing" result, meaning no vulnerabilities scored CVSS 4.0 or higher remain unresolved. Rescans are required until a passing result is achieved.
SOC 2 Type II
Trust Services Criteria for service organizations handling customer data.
SOC 2 Type II audits evaluate the operating effectiveness of controls over a period of time (typically 6-12 months). The Common Criteria control CC7.1 requires that the entity uses detection and monitoring procedures to identify changes to configurations that result in new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.
In practice, auditors expect to see:
- Evidence of regular vulnerability scanning with timestamps and results
- A documented process for triaging and remediating findings
- Proof that critical and high vulnerabilities were addressed within the organization's stated SLA
- Exportable scan reports that can be provided to the audit firm
For SaaS vendors, SOC 2 reports are frequently requested by enterprise customers during vendor security assessments. The ability to produce structured, machine-readable vulnerability scan evidence significantly reduces audit preparation time.
HIPAA
Health Insurance Portability and Accountability Act security requirements.
The HIPAA Security Rule requires covered entities and business associates to implement technical safeguards that protect electronic Protected Health Information (ePHI). While HIPAA does not prescribe specific scanning tools or frequencies, the Risk Analysis requirement (45 CFR 164.308(a)(1)) mandates that organizations:
- Conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI
- Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level
- Regularly review records of information system activity, including audit logs and access reports
In enforcement actions, OCR has consistently cited the failure to conduct adequate risk analysis — which includes vulnerability identification — as a primary basis for penalties. Organizations handling PHI should treat vulnerability scanning as a core component of their risk analysis program.
CISA BOD 22-01
Binding Operational Directive requiring remediation of Known Exploited Vulnerabilities.
Binding Operational Directive 22-01 requires all federal civilian executive branch (FCEB) agencies to remediate vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) catalog within specified timeframes. The KEV catalog contains CVEs that CISA has confirmed are being actively exploited in the wild.
- Agencies must remediate internet-facing KEV entries within 15 calendar days of the vulnerability being added to the catalog
- All other KEV entries must be remediated within 25 calendar days
- Agencies must report remediation status to CISA on a recurring basis
While BOD 22-01 is binding only for federal agencies, CISA strongly recommends that all organizations use the KEV catalog to prioritize remediation. Many private-sector security teams have adopted KEV as a prioritization signal alongside CVSS and EPSS scores.
How ScanRook helps
Mapping ScanRook capabilities to compliance requirements.
ScanRook is designed to produce the artifacts and evidence that compliance frameworks require. The following table maps specific scanner features to the regulatory controls they support:
SBOM generation (CycloneDX, SPDX)
EO 14028 SBOM mandate, CM-8 component inventory
CVE tracking with fix status and fixed-in versions
RA-5 vulnerability scanning, SI-2 flaw remediation, PCI-DSS 11.3
EPSS probability scoring and prioritization
Risk-based remediation for SOC 2, FedRAMP POA&M triage
CISA KEV catalog flagging
BOD 22-01 KEV remediation timelines
Structured JSON report export
SOC 2 audit evidence, FedRAMP monthly reporting, PCI-DSS scan documentation
Self-hosted deployment option
Data sovereignty, HIPAA ePHI handling, air-gapped environments
Compliance is not about checking boxes — it is about building a defensible, repeatable process for identifying and addressing risk. ScanRook provides the scanning engine and structured output that organizations need to demonstrate that process to auditors, assessors, and customers.
Further reading
Related guides and documentation.
- Compliance Scanning Guide — A practical walkthrough for integrating ScanRook into your compliance program.
- Enrichment — How ScanRook queries OSV, NVD, distro feeds, EPSS, and KEV to produce actionable findings.