Open source vulnerability scanning for CMMC

Open source vulnerability scanning for CMMC: what Level 2 asks of your scanning program

A contractor that handles CUI must show that its systems in the CUI boundary are scanned for vulnerabilities and that findings are remediated by risk. CMMC Level 2 mirrors NIST SP 800-171 Rev. 2, so RA.L2-3.11.2 and RA.L2-3.11.3 must be MET, not placed on a POA&M. Under the scoring method, RA.L2-3.11.2 is worth 5 points and cannot be carried on a POA&M, so it must be fully satisfied for Conditional or Final Level 2 status. Open-source scanners can support both requirements, provided the scanner configuration, scan results and remediation records are complete and in final form. Assessors judge the records, not the tool brand.

Timing matters as much as the tool. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification, and opened a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because the DoW CIO page and the eCFR text describe the phase schedule differently, confirm with your contracting officer which assessment type and phase applies to your contracts before you set your evidence plan.

Start by writing down what the scanner must cover: the in-scope hosts, the applications in the CUI boundary, and the scan frequency you will define, since 3.11.2 requires you to set that frequency and scan at it. Document the scanner configuration, such as the Greenbone or Wazuh settings, credentials and target lists, because assessors examine tool configuration as an assessment object. Then decide how findings move into remediation decisions tied to your risk assessment. Confirm these choices with your assessor's expectations and your DoW CIO assessment guide before you treat the program as complete.

Mapping RA.L2-3.11.2 and RA.L2-3.11.3 to scanning functions

This table maps each assessment objective in NIST SP 800-171A for RA.L2-3.11.2 and RA.L2-3.11.3 to the scanning function an assessor will look for, and to how Greenbone or Wazuh can be configured to meet it. Read it as a checklist: each row names what the function must do, the configuration that supports it, and the record that shows it. The main takeaway is that both requirements must be MET, not placed on a POA&M, so scan scope, authentication and feed currency need to be right before the assessment.

Requirement and objective	What the function must do	Greenbone or Wazuh configuration	Evidence an assessor examines
3.11.2: define scan frequency	Set and document how often systems and applications are scanned, in a written scanning plan tied to the CUI boundary	Create recurring Greenbone tasks in gvmd, or schedule Wazuh vulnerability detection reviews, and record the cadence in the scanning plan	Approved scanning plan, schedule export and configuration documentation for the scanner
3.11.2: scan systems periodically	Scan every in-scope host at the defined frequency, including hosts that are not always online	Define targets for all CUI boundary hosts in Greenbone, use asset discovery to catch gaps, and confirm Wazuh agents report inventory from each endpoint	Scan results per host by date, target lists matching the system inventory
3.11.2: scan applications periodically	Cover in-scope applications and services, not only operating systems	Include application ports and web services in Greenbone target scans and use Notus results for installed software, since Notus compares installed software against known vulnerable versions	Scan results listing application findings, with the scan configuration showing those services were in scope
3.11.2: scan when new vulnerabilities are identified	Trigger additional scans when new vulnerabilities affecting in-scope systems are published	Run ad hoc Greenbone tasks after critical advisories, and use Wazuh vulnerability detection, which correlates agent inventory with vulnerability data, to flag affected endpoints between scheduled scans	Dated event-driven scan records linked to the advisory that prompted each one
3.11.2: authenticated scanning and feed currency	Scan with credentials where needed to see installed packages and configuration, and keep vulnerability data current	Configure Greenbone credentials for Windows and Linux targets, and confirm the feed update schedule, since Community Feed releases exclude some enterprise product tests; for Wazuh, confirm the CTI or offline repository is updated	Credential configuration (without secrets), feed update logs and feed versions recorded with each scan
3.11.3: identify vulnerabilities	Turn scan output into a verified list of vulnerabilities per system, with false positives reviewed and recorded	Use Greenbone results or Wazuh alerts as the source, import reports into DefectDojo if several scanners are used, and document review decisions for each finding	Consolidated findings list with severity, asset, status and reviewer notes
3.11.3: remediate per risk assessment	Fix or formally handle each vulnerability according to the risk assessment, with deadlines set by risk level	Track each finding to a remediation ticket with an owner and due date set by the risk assessment, then rescan to confirm closure in Greenbone or Wazuh	Risk assessment that defines remediation priority, remediation tickets, and rescan results showing closure or accepted risk

Which open-source scanners fit a CMMC Level 2 boundary

RA.L2-3.11.2 and RA.L2-3.11.3 require periodic scanning and risk-based remediation across systems and applications in the CUI boundary. The cards below cover the open-source components that can produce scan results, inventory data and tracking records, and the limits each one has when an assessor reviews the evidence.

Greenbone Community Edition

Greenbone Community Edition is released under open-source licenses and is built from gvmd, the openvas-scanner with the Notus Scanner, PostgreSQL, the Greenbone Security Assistant web interface and feed data containers. The Community Feed excludes vulnerability tests for enterprise products, so confirm that every product in the CUI boundary is covered before relying on it for 3.11.2. Authenticated scan credentials determine how deep host findings go, and that coverage should be tested and recorded. Scan results can be imported into DefectDojo for tracking.

Wazuh vulnerability detection

Wazuh agents collect the software inventory from endpoints, and the Wazuh server correlates that inventory with vulnerability data from the Wazuh Cyber Threat Intelligence platform or an offline repository. This makes it useful for continuous inventory-based detection in CUI enclaves where agents are already deployed. Confirm that the offline vulnerability repository is kept current if the enclave has no internet access, because stale data weakens the 3.11.2 evidence. The dashboard includes prebuilt compliance views, but those views do not replace the assessment objectives in NIST SP 800-171A.

Wazuh server cluster scaling

The Wazuh server can run as a cluster for horizontal scaling and manages agent configuration and upgrades remotely. This matters when the CUI boundary spans many endpoints or several enclaves that must be monitored with the same scan policy. Plan the cluster inside the boundary, define who administers agent groups, and record configuration changes, since assessors will ask how scanning configuration is documented and kept under control. Confirm sizing with the vendor documentation for your endpoint count.

Greenbone scan and tracking workflow

Greenbone scan tasks run on schedule through gvmd, and results can be exported in CSV or XML and imported into DefectDojo, which supports OpenVAS and Greenbone reports. This gives a single place to record remediation owners, risk ratings and due dates, which is the record 3.11.3 asks for. Check that the import keeps finding identifiers stable across rescans, and that the remediation decisions are dated and approved in the tracker rather than only in the scanner.

Trivy for container and dependency findings

Trivy scans container images, file systems and software dependencies for known vulnerabilities, which covers components that host scanners often miss, such as application libraries inside CUI-processing services. Its results should be imported into the same tracker as host findings so that 3.11.2 covers applications as well as systems. Confirm which vulnerability database the deployment uses and how it is refreshed inside an isolated network, and confirm the license of any edition you select.

Dependency-Track for component tracking

Dependency-Track tracks software components from SBOMs and matches them against known vulnerabilities over time, so new CVEs can be linked to applications already deployed. This supports the requirement to scan when new vulnerabilities affecting the environment are identified, not only on a fixed calendar. Check how SBOMs are produced for each CUI application, how they are stored, and whether the team can show the date a new vulnerability was matched to a deployed component.

How to place scanners inside the CUI boundary without widening scope

A vulnerability scanner that stores, processes or has credentials to systems in the CUI boundary becomes part of that boundary, so placement is the first scope decision to make. Put the Greenbone or Wazuh components in the same enclave as the systems they scan only if the enclave is already documented in your system security plan, and record which assets the scanner reaches, which credentials it holds and who can administer it. Treat scanner administrators as privileged users: restrict their accounts, log their sessions, and confirm with your assessor how their activity will be evidenced. Scanner data such as credentialed scan results can expose configuration details, so decide where those results are stored before the first scan runs.

Sizing and feed handling are the operational details that most often drift. The Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, and the Greenbone Community docs recommend 4 cores, 8 GB and 60 GB. Feed data such as vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories is loaded into volumes by dedicated data containers at startup, so confirm where those volumes live, who can update them and how updates are logged. Ask your system owners to agree a scan window and scan safety settings for each target class, including whether credentialed or aggressive checks run against production databases and operational technology. The scanner itself does not make a system compliant with RA.L2-3.11.2; the evidence that the scanning ran as documented, under agreed settings, is what an assessor will examine.

Scanning choices for connected, offline and mixed CUI environments

A connected enclave can reach vulnerability data sources directly, so the scanner updates its feeds on a schedule and scans run against current data. This is the simplest model to operate, but the scan record has to show that the feed was current when each scan ran, not just that the scanner was installed. Greenbone Community Containers load feed data such as vulnerability tests, Notus data and CVE and CPE data through dedicated data containers at startup, and Wazuh vulnerability detection correlates agent inventory with its Cyber Threat Intelligence data, so both need a documented update routine.

Scheduled feed updates: Document the update schedule for each scanner and keep the logs that show each update completed.
Scan cadence record: Tie each scheduled scan task to the scan frequency your system security plan defines for RA.L2-3.11.2.
Event-driven scans: Show a process that triggers an extra scan when a new vulnerability affecting your systems is identified.
Credentialed coverage: Keep authenticated scan configurations and the list of targets they cover.
Change control: Record scanner and feed version changes so results can be traced to the data that produced them.

Confirm with the assessor how they expect feed currency to be shown and whether they accept scheduler logs as scan records.

Scan and remediation records assessors examine

This table lists the records an assessor is likely to ask for under RA.L2-3.11.2 and RA.L2-3.11.3, which system produces each one, and what it proves. Read it as a checklist: a requirement is MET only when the records are final, dated and consistent with the system security plan, and drafts do not count toward the assessment.

Evidence item	What it proves	Produced by
Scanner configuration and tool documentation	Which scanner, feed and settings were used, and that scanning covers systems in the CUI boundary	gvmd, Wazuh (configuration files and admin records)
Defined scan schedule	The scanning frequency the organization set, as required by the first assessment objective of 3.11.2	gvmd scheduled tasks, Wazuh configuration
Scan results for systems and applications	Authenticated and unauthenticated scans covered in-scope hosts and applications at the defined frequency	gvmd reports, Wazuh vulnerability detection inventory
Event-driven scan records	Scans run when new vulnerabilities affecting the environment were identified, as 3.11.2 requires	gvmd task history, Wazuh CTI update logs
Remediation tickets tied to risk assessment	Each finding was prioritized and fixed in line with the organization's risk assessment under 3.11.3	Ticketing system, DefectDojo finding records
Rescan results after remediation	The fix worked and the vulnerability no longer appears, closing the loop on identified vulnerabilities	gvmd rescans, Wazuh re-evaluation, DefectDojo status history
Patch and vulnerability management records	Patches and fixes were applied, with dates and owners, supporting the remediation objective	Ticketing system, Wazuh inventory history, change records
System security plan references	The scanning and remediation process is described in the SSP and matches what the tools actually do	Organization's SSP, cross-referenced to scanner and ticket records

What scanning tools alone do not satisfy

A scanner produces findings, but RA.L2-3.11.2 and RA.L2-3.11.3 are assessed on the whole cycle: the scan plan, the risk basis for fixes, the credentials behind the results and the records that show it happened. The cards below cover what you must supply around the tool, and what to confirm before an assessment.

Risk assessment drives fix priority

RA.L2-3.11.3 requires remediation in accordance with risk assessments, so the assessor will ask why a given finding was fixed first or deferred. Your organization must maintain a documented risk assessment that rates severity, asset criticality, CUI exposure and exploit status for each finding class. Greenbone and Wazuh report severity scores, but they do not know which systems hold CUI or how your environment is exposed. Check that the risk criteria in your documentation match the priorities your tickets actually follow.

POA&M cannot carry 3.11.2 or 3.11.3

Under 32 CFR 170.21(a)(2), a 5-point requirement such as RA.L2-3.11.2 cannot sit on a Plan of Action and Milestones, so it must be fully MET before a Conditional or Final Level 2 status. Scanning gaps, such as a subnet left out of the scan schedule, therefore cannot be deferred to a later date. Confirm with your assessor and your sponsor how the POA&M rules apply to the rest of your 110 requirements, and plan scan coverage before the assessment rather than during it.

Authenticated scanning credentials

Unauthenticated scans miss missing patches in installed software, which is the core of what 3.11.2 asks you to find. Your organization must create and rotate scan accounts on Windows, Linux, network devices and databases inside the CUI boundary, and record who owns them. Confirm that each credential has the least privilege needed for patch inspection, that secrets are stored in a managed vault, and that failed logins appear as scan errors rather than as clean results.

Evidence in final form

A requirement is MET only when every applicable assessment objective is satisfied with evidence in final form, not drafts. Scanner exports, scan configuration files, the security assessment report and patch records must be dated, approved and retained under your own document control. Assign an owner for each record type and decide where final versions live. A half-finished export from an automated job does not count, so review the evidence set against the assessment objectives before the assessor arrives.

Uncertain Phase II and certification timing

On 13 July 2026 the Department of War suspended CMMC Phase II, including the Level 2 C3PAO certification requirement, while a 60-day review runs. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place, and the DoW CIO site describes Level 2 as self-assessment only during Phase 1. Confirm with your contracting officer which assessment type applies to your contracts and when, and keep your scanning program to the stricter standard so a change in schedule does not change your technical controls.

Staffing for remediation

Scanning produces findings on a schedule, but someone must triage them, open tickets, coordinate patch windows and confirm closure. Name an owner for scan operations, an owner for triage against the risk assessment, and system owners who accept remediation dates for their assets. Ask who handles exceptions for systems that cannot be patched on schedule, and how those exceptions are approved and reviewed. Without named people, the scanner's history shows the same findings reappearing across assessment cycles.

CMMC vulnerability scanning questions buyers ask before hiring help

Are open-source scanners accepted for CMMC RA.L2-3.11.2?

CMMC does not name approved scanner brands for RA.L2-3.11.2. The requirement calls for periodic scanning of organizational systems and applications, and for scanning when new vulnerabilities affecting them are identified. NIST SP 800-171A asks assessors to examine the scanning tools, their configuration documentation, the scanning results and the patch and vulnerability management records. An open-source tool such as Greenbone or Wazuh can satisfy those objects if the scan frequency is defined, the scope covers systems and applications in the CUI boundary, and the configuration and results are documented. The assessor judges whether the evidence meets each objective, so confirm the approach with your C3PAO or assessor before you commit to a tool.

What drives the cost of CMMC vulnerability scanning?

The main cost drivers are the number of assets inside the CUI boundary, the number of applications that need authenticated scanning, the feed you choose, and the amount of remediation tracking you need. Greenbone's Community Feed excludes vulnerability tests for enterprise products, so confirm whether your estate includes products that require the Enterprise Feed. Wazuh vulnerability detection depends on either its Cyber Threat Intelligence platform or an offline repository, which affects how you design updates. Ask a quote to separate one-time work (design, deployment, documentation, evidence templates) from recurring work (feed updates, scan reviews, patch coordination, monthly reporting) and to state which parts are paid to a partner and which remain with your staff.

How long does it take to set up CMMC vulnerability scanning?

No fixed duration applies to every environment, so confirm the timeline in a scoped quote rather than relying on a generic figure. Setup time depends on the size of the CUI boundary, how many network segments need scanner access, whether credentials for authenticated scans are available, whether the environment is connected to the internet for feed updates, and how much of the scan policy and documentation must be written from scratch. Greenbone's Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended, so hardware lead time can also affect the schedule. Ask the partner to list the milestones, the dependencies on your team, and the evidence each milestone produces.

What does the work need from our internal staff?

Your staff must supply the boundary definition, the asset inventory, the network routes and firewall rules that let the scanner reach targets, and the credentials for authenticated scans. Someone with authority over change windows must approve scan schedules, because scans can disrupt fragile systems. Your security owner must own the risk ratings used to set remediation deadlines, since RA.L2-3.11.3 requires remediation in accordance with risk assessments. System owners must act on findings and record the outcome. Plan for these hours from the start. A partner can draft the procedures and reports, but the decisions and the records that show them must come from your organization.

Can our team run CMMC vulnerability scanning without outside help?

A capable internal team can run open-source scanning for CMMC, provided it has someone who can administer the scanner, maintain feeds, tune scan policies, triage results and keep the documentation current. The harder part is often the evidence: the scan configuration, the frequency definition, the results, the risk-based remediation records and the final-form documents that assessors examine. Under the CMMC rules, a requirement is MET only when all applicable objectives are satisfied with evidence in final form, not drafts. If your team lacks scanner administration or assessment experience, consider a fixed-scope engagement for design and handover, then run the tool in-house with a documented runbook. DeployOpen implements and documents self-hosted platforms inside the client's infrastructure, and prepares evidence for assessments without issuing certifications.

How does the CMMC Phase II suspension affect scanning timing?

The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. The suspension does not remove RA.L2-3.11.2 or 3.11.3 from Level 2. Because scoring treats them as 5-point requirements that cannot sit on a POA&M, build scanning now, and confirm your contract obligations and current requirements with your contracting officer and assessor.

What evidence will assessors ask for from our scanning program?

Assessors working from NIST SP 800-171A look for the scanning tool and its configuration documentation, the scan results, the security assessment report, and the patch and vulnerability management records. For RA.L2-3.11.2 they check that scanning is defined at a set frequency, that both systems and applications are scanned at that frequency, and that scans also run when new vulnerabilities are identified. For RA.L2-3.11.3 they check that vulnerabilities are identified and remediated in line with the risk assessment. Keep scan schedules, dated result exports, ticket histories showing remediation or documented risk acceptance, and the risk assessment that set the deadlines. Confirm the exact artifacts and format with your assessor before you define the evidence set.

Where to read the official CMMC and NIST requirements

Before you scope a scanner, read the assessment objectives your assessor will use. For RA.L2-3.11.2 and RA.L2-3.11.3, the controlling text is *NIST SP 800-171A* (June 2018), which splits 3.11.2 into five objectives: defining the scanning frequency, scanning both systems and applications at that frequency, and scanning when new vulnerabilities are identified. It splits 3.11.3 into two: identifying vulnerabilities and remediating them in accordance with risk assessments. Use those objectives as your checklist for the scanner configuration documents, scan results, risk assessment and patch records you will need to produce. Read the NIST SP 800-171A assessment guide directly rather than relying on summaries.

Next, read the scoring and POA&M rules in *32 CFR Part 170*, specifically the scoring methodology at 170.24 and the POA&M limits at 170.21. Because RA.L2-3.11.2 is worth more than one point, it cannot be carried on a POA&M and must be MET for Conditional or Final Level 2 status. That makes the scan cadence a hard requirement from day one, not a remediation item. The DoW CIO *CMMC Assessment Guide, Level 2* (Version 2.13, September 2024) shows how assessors will test each objective, so align your evidence with its wording. Confirm with your contracting officer or the DoW CIO which assessment guide version applies to your contract.

Verify phase status before you commit budget. On 13 July 2026 the Department of War suspended CMMC Phase II and started a 60-day review, while Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. The eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule, so the eCFR and the DoW CIO *About CMMC* page can disagree. Check the DoW CIO About CMMC page on the day you plan, and record the date you checked in your scope document. Treat the scanning obligations as unchanged regardless of phase, because they sit inside the NIST SP 800-171 Rev. 2 requirements that the rule still incorporates.

How DeployOpen scopes, deploys and supports CMMC scanning

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including scanning for systems in the CUI boundary. The work starts with a written scope that defines which assets, scanners and assessment records the CMMC Level 2 evidence will rely on.

How we scope

Agree in writing which CUI boundary assets, hosts, applications and cloud accounts are in scan coverage.
Define the scan frequency and remediation approach that the organization's own risk assessment will support.
Confirm which deliverables, timelines and responsibilities apply, since most engagements are fixed-scope with written terms.

How we build

Deploy Greenbone Community Containers or Wazuh inside the client's environment, with credentialed scan configuration documented.
Configure scheduled tasks, scan targets and reporting so scan results are retained as assessment evidence.
Test scanning coverage and result handling against the scope before the platform is accepted for use.

How we hand over

Deliver configuration documentation, scan schedules, and the procedures that show how findings are triaged and remediated.
Document how risk-based remediation decisions are recorded, so assessors can trace each finding to its outcome.
Provide operator handover so the client's staff can run scans and produce reports without ongoing dependency.

How we support

Ongoing support, upgrades and continuous testing are available as retainers based on the written scope.
Upgrade feeds, scanner components and platform releases on a schedule agreed with the client's change process.
Confirm with your C3PAO or assessor which evidence formats they expect before the assessment window opens.

Open source vulnerability scanning for CMMC