What Is the National Vulnerability Database?
The National Vulnerability Database (NVD) is the U.S. government's official repository of standards-based vulnerability management data. Maintained by NIST, it enriches and hosts every CVE (Common Vulnerabilities and Exposures) entry published by MITRE with additional analysis: CVSS severity scores, affected product ranges, remediation references, and CWE classifications.
When your scanner finds a vulnerability on a system, it is referencing NVD data. When your patch management tool assigns a severity level, it is reading CVSS scores that originate in NVD. The database is updated continuously and is freely accessible at nvd.nist.gov/vuln/search. For defense contractors subject to CMMC, NVD is not just a reference tool. It is the authoritative source behind your legal obligation to scan for and remediate vulnerabilities on any system that processes, stores, or transmits Controlled Unclassified Information (CUI).
The CMMC Compliance Obligation
Two NIST SP 800-171 requirements directly tie NVD data to your CMMC Level 2 certification. Both fall under the Risk Assessment (RA) domain and carry a combined SPRS point value of 6.
| Requirement | Description | SPRS Points | POA&M Eligible |
|---|---|---|---|
| RA.L2-3.11.2 | Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems are identified. | 5 | No |
| RA.L2-3.11.3 | Remediate vulnerabilities in accordance with risk assessments. | 1 | Yes |
RA.L2-3.11.2 carries 5 SPRS points and is not POA&M eligible. That means you cannot defer it to a plan of action after your assessment. If you cannot demonstrate an active, periodic vulnerability scanning program on your CUI systems at the time of your C3PAO assessment, you lose 5 points immediately with no path to reclaim them before certification.
The System and Information Integrity (SI) domain adds a second layer. SI.L2-3.14.1 requires that you identify, report, and correct information system flaws in a timely manner. When a scanner finds a Critical or High CVE on a CUI-scoped asset, SI.L2-3.14.1 is the requirement that governs your response timeline.
Recent NVD Entries: What This Looks Like in Practice
The screenshot at the top of this article is from 1TEN's Vulnerability Lifecycle module. The entries below are real CVEs currently tracked in NVD that are relevant to software many DIB contractors run. These examples illustrate why a continuous scanning program matters. The threat landscape does not pause between your quarterly scans.
| CVE | Severity | Affected Software | Summary |
|---|---|---|---|
| CVE-2025-66494 | High | Foxit PDF Reader/Editor | Use-after-free vulnerability in PDF file parsing. Affects 4 assets in the example environment. Active exploitation has been observed in document-heavy environments. |
| CVE-2025-55310 | High | Foxit PDF Editor (Windows/macOS, pre-13.x) | An issue discovered in Foxit PDF Editor versions before 13.2. Remote code execution is possible via crafted PDF documents. |
| CVE-2025-59802 | High | Foxit PDF Editor/Reader pre-2025.2.1 | Signature spoofing via OCG (Optional Content Groups) allows attackers to make malicious documents appear digitally signed by a trusted authority. |
| CVE-2016-6662 | Critical | Oracle MySQL 5.5.x, 5.6.x, 5.7.x | Remote code execution in Oracle MySQL through multiple versions. Despite its 2016 date, this CVE still surfaces in environments running legacy database versions without patching programs. |
| CVE-2016-9843 | Critical | zlib 1.2.8 (crc32_big function) | The crc32_big function in crc32.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving big-endian CRC calculation. |
The 2016 entries deserve specific attention. A contractor with no active scanning program may not know those vulnerabilities have been present in their environment for years. C3PAO assessors have found exactly this scenario during formal assessments. An unpatched 2016 Critical CVE on a CUI system is not a historical footnote. It is a current finding.
How 1TEN Retrieves and Tracks the Compliance Obligation
1TEN's Vulnerability Lifecycle module connects NVD CVE data directly to your CMMC compliance record. The workflow runs as follows.
Vulnerability scan results (from Tenable, Qualys, Rapid7, or any scanner that exports CVE-tagged findings) are imported into the platform. 1TEN maps each CVE to the affected asset instances in your Asset Inventory, applies the NVD CVSS severity, and opens a tracked finding in the Vulnerability Lifecycle queue.
Each finding in the queue displays the CVE identifier, severity badge, number of affected asset instances, a truncated NVD description, and current SLA status. The tabs across the top of the module separate findings into four states: Open, Patched, Risk Accepted, and SLA Breached. This separation matters for your C3PAO assessor. When they ask to see your vulnerability management evidence, you can show them the Patched tab as a remediation log and the Risk Accepted tab as your documented risk acceptance decisions, both of which are required artifacts under RA.L2-3.11.3.
The Vulnerability Lifecycle module also feeds the Compliance Calendar. Upcoming scan cadence tasks appear as scheduled items, so the RA.L2-3.11.2 obligation to scan periodically is automatically enforced through the recurring task system rather than relying on someone remembering to run a scan.
All findings are linked to your System Security Plan automatically. When your SSP is exported for your C3PAO, the RA domain section reflects your current scan program, open findings count, and remediation SLA configuration, giving assessors a complete picture without manual document assembly.
Common Tools Used to Address NVD Findings
Tracking CVEs is the compliance layer. Actually closing them requires patching and configuration tooling. The following are the most widely used tools in DIB contractor environments for vulnerability detection and remediation.
| Tool / Category | What It Does | Relevant CMMC Requirements |
|---|---|---|
| Tenable Nessus / Tenable.io | Industry-standard vulnerability scanner. Produces CVE-tagged findings with CVSS scores, asset mapping, and remediation priority queues. Nessus Essentials is free for up to 16 IPs. | RA.L2-3.11.2, SI.L2-3.14.1 |
| Qualys VMDR | Cloud-based vulnerability management with agent and agentless scanning. Integrates with patch management workflows for one-click remediation tasking. | RA.L2-3.11.2, SI.L2-3.14.1 |
| Rapid7 InsightVM | Real-time vulnerability analytics with remediation workflow and risk-prioritized findings. Well-suited to environments where engineering and IT security share remediation responsibilities. | RA.L2-3.11.2, RA.L2-3.11.3 |
| OpenVAS (Greenbone) | Open-source vulnerability scanner maintained by Greenbone. A cost-effective option for smaller DIB contractors with limited security budget. Produces NVD-referenced CVE findings. | RA.L2-3.11.2 |
| Windows Server Update Services (WSUS) / Microsoft Intune | Patch deployment for Windows environments. Patches identified CVEs on endpoints and servers. WSUS is on-premises; Intune is cloud-based. Both produce patch compliance reports. | SI.L2-3.14.1, CM.L2-3.4.2 |
| Wazuh SIEM | Open-source SIEM and XDR with a built-in vulnerability detection module. Wazuh agents monitor installed packages against the NVD feed in near real time, generating alerts when new CVEs affect installed software versions. Pairs well with 1TEN's AU domain evidence requirements. | RA.L2-3.11.2, SI.L2-3.14.4, AU.L2-3.3.1 |
| CrowdStrike Falcon / Microsoft Defender for Endpoint | Endpoint detection and response (EDR) platforms with vulnerability assessment features. Provide continuous endpoint visibility and alert on active exploitation attempts for known CVEs. | SI.L2-3.14.2, SI.L2-3.14.1 |
Tool selection matters less than process. A contractor running Nessus Essentials on a documented quarterly schedule, with findings imported into a tracking system and remediated against a risk-based priority order, satisfies RA.L2-3.11.2 and RA.L2-3.11.3. A contractor with a commercial enterprise scanner but no remediation tracking or evidence of periodic scans does not. The scan is the detection step. The tracking, prioritization, and documented closure are the compliance step.
FAQ
NIST SP 800-171 requires scans to be conducted "periodically and when new vulnerabilities affecting those systems are identified." NIST does not define a specific frequency. Most C3PAO assessors look for evidence of at least quarterly scans on CUI-scoped assets, with triggered scans documented when significant new CVEs are published. Whatever cadence you define, document it in your SSP and follow it consistently.
No. RA.L2-3.11.3 requires remediation "in accordance with risk assessments," which means you can prioritize based on severity and context. Critical and High CVEs affecting CUI systems need fast action and clear documentation. Lower-severity findings can be managed on a longer timeline with documented justification. What you cannot do is leave Critical or High findings completely undocumented with no remediation plan.
RA.L2-3.11.3 is POA&M eligible, so yes, open findings with documented remediation plans and milestones can be carried into your assessment. However, RA.L2-3.11.2 (the scanning requirement itself) is not POA&M eligible. You must have an active scanning program in place at the time of assessment. The existence of open CVEs does not fail your assessment automatically. The absence of a scanning program does.
Assessors will typically ask for: dated scan reports showing scope and tool used, a current list of open findings with severity and age, evidence that Critical and High findings have been remediated or documented in a POA&M, your defined scan cadence in the SSP, and any risk acceptance decisions for findings you have chosen not to patch. All of these artifacts are generated or imported through 1TEN's Vulnerability Lifecycle module and linked to your SSP export automatically.
1TEN is a compliance management platform, not a scanner. Your vulnerability scanner (Tenable, Qualys, Rapid7, OpenVAS, Wazuh, or similar) detects and identifies CVEs on your systems. Those findings are imported into 1TEN's Vulnerability Lifecycle module, where they are tracked against your assets, assigned SLA timers, linked to RA and SI domain requirements, and incorporated into your SSP and assessment evidence package.