Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Since July 13, 2026, defense solicitations may require only Level 1 or Level 2 self-assessments, while Phase 2 remains suspended.
- None of the 110 Level 2 requirements mention open source, but software is an asset, so open-source packages on in-scope systems are covered like the rest.
- Four requirements reach them: inventory, user-installed software, vulnerability scanning, and flaw remediation.
- Three of those are five-point requirements, so a gap in any of them can’t be deferred on a plan of action and milestones.
The Cybersecurity Maturity Model Certification (CMMC) compliance requirements don’t ask anything of your open source specifically. However, the 110 requirements CMMC sets for contractors handling Controlled Unclassified Information (CUI) still reach the open-source packages in your build. That holds even after the Pentagon paused Phase 2 of the CMMC program on July 13, 2026, the step that would have made third-party assessment a condition of award on applicable contracts. Those same 110 requirements remain the basis for self-assessments.
What CMMC Compliance Requirements Cover
CMMC has three levels. The level that applies to you depends on the information involved and the requirements in your contract or solicitation.
| Level | Information | Requirements | Who assesses |
|---|---|---|---|
| Level 1 | Federal Contract Information (FCI) | 15 basic requirements from the Federal Acquisition Regulation | You, through an annual self-assessment |
| Level 2 | CUI | 110 requirements from the National Institute of Standards and Technology (NIST) SP 800-171 Revision 2 | You, or a CMMC Third-Party Assessment Organization (C3PAO), when the solicitation calls for it (paused for now) |
| Level 3 | CUI on selected programs | 24 selected requirements from NIST SP 800-172, on top of Level 2 | The Defense Contract Management Agency (DCMA) |
The 110 Level 2 requirements run across 14 families, from access control to system and information integrity.
Where CMMC Compliance Requirements Stand in 2026
The Defense Federal Acquisition Regulation Supplement (DFARS) rule that incorporates CMMC into contracts took effect on November 10, 2025, marking the start of Phase 1. Under Phase 1, the Department of Defense (DoD) includes, where applicable, a Level 1 or Level 2 self-assessment requirement as a condition of award.
Phase 2, due on November 10, 2026, would have added Level 2 assessments by C3PAOs as a condition of award. On July 13, 2026, the DoD chief information officer suspended it. Program managers can now require only self-assessments at Level 1 or Level 2, and contracts that already call for a C3PAO or government-led assessment are to be amended at the next option period or administrative change.
The program rule itself hasn’t been rewritten since the suspension was communicated via memos, so it still describes the original four phases. The DoD chief information officer’s CMMC page is where changes are posted.
For now, the 110 requirements are the common ground, and open source comes in through them.
What the Rule Says About Open-Source Components
The 110 Level 2 requirements are the requirements in NIST SP 800-171 Revision 2, and the program rule states they’re identical. NIST has since replaced Revision 2 with Revision 3, but CMMC still uses Revision 2, and so does DoD’s assessment guide. The practical effect is that the version of the requirements that applies to your open-source packages is the Revision 2 text, not the Revision 3 text.
Each of the 110 requirements comes with two companions in the NIST and DoD documents: a set of assessment objectives (a checklist of conditions that must be met for the requirement to count as met) and a discussion (explanatory text that describes intent but isn’t itself a requirement).
The Level 2 assessment guide asks self-assessors to use the same criteria that a third-party assessor would and not to take what staff say in interviews as proof of what the system actually does. The rule’s scoring section sets the evidence standard: drafts, working papers, and unapproved policies don’t count. For open source, that means a draft inventory or a scanning policy that nobody has signed off on doesn’t count as evidence.
None of the 110 requirement statements name open source or mention software bills of materials (SBOMs), provenance, or supply chain. Software comes in through the definitions. In CMMC, software is an asset, so the open-source packages on a system in your assessment scope are covered by the same requirements as the rest of that system’s software. What puts a system in scope is what it does with CUI: assets that process, store, or transmit it are assessed against every Level 2 requirement. Scope also takes in assets that protect those systems, such as firewalls and identity services. A build server or developer workstation that never touches CUI can fall outside it, which is the scoping judgment the user-installed software requirement turns on later. DoD’s scoping guide has the full breakdown.
Supply chain risk is named in two Level 3 requirements, but Level 3 is a separate tier with its own government-led assessment, so neither requirement applies at Level 2.
Four Practices That Reach Your Dependency Tree
Keep an inventory of what’s on the system (CM.L2-3.4.1). You have to maintain a list of the hardware and software that make up each in-scope system, including version numbers, and keep it up to date as the system changes. Open source comes into play here because the packages in your application, including those pulled in indirectly by other packages, are software with version numbers. If they aren’t on the list, the list is incomplete.
Control what users install (CM.L2-3.4.9). You need a policy on which software users may install, a way to enforce it, and a way to see what has been installed. NIST’s explanatory text says the policy may prohibit software “with unknown or suspect pedigrees,” which is the closest Level 2 comes to asking where software came from. That “pedigree” line is guidance, so it can’t count against you on its own. The requirement itself, a policy on what gets installed, enforcement of it, and a record of what was installed, is not optional, and if your build environment is inside the assessment scope, the packages developers add to it can count as installs like any other.
Scan for vulnerabilities on a schedule (RA.L2-3.11.2). You have to scan systems and applications at a frequency you define and run additional scans when new vulnerabilities are announced. Open-source packages in your applications are part of what gets scanned.
Taken together, the inventory, user-installed software, and vulnerability scanning requirements cover what’s in your build, what’s allowed into it, and which known vulnerabilities it carries. The fourth, fixing flaws in a timely manner (SI.L2-3.14.1), covers what happens once a vulnerability is found.
Why Timely Flaw Remediation Needs a Number You Define
SI.L2-3.14.1 says to identify, report, and correct system flaws in a timely manner, but nothing in the requirement, NIST’s explanatory text, or DoD’s assessment guide says how long “timely” is. All three leave it to you to set a timeframe, and the guide’s own example is a set number of days based on the severity of the flaw. What you have to show is that you defined one and that you met it.
A timeframe you regularly miss leaves a record of the gap, and without a defined timeframe, the assessment checklist can’t be completed.
The harder case is a component nobody maintains anymore, because no fix is coming from upstream. The guide counts applied patches, configuration changes, and workarounds or mitigations as ways to correct a flaw, so you have more than one route. You can replace the component, move to a newer release series, put a workaround in place, or get a fix applied to the version you run, and each leaves different evidence behind. Replacing or moving up assumes a substitute or newer series exists and that your code can take the change, which is why upgrading isn’t always an option, particularly when the component sits deep in the tree.
What a POA&M Can and Can’t Cover
An assessment ends in one of three results for each requirement (MET, NOT MET, or not applicable) and in an overall status. Final status means everything is met. Conditional status means a few gaps remain, and you’ve committed to closing them.
The rule’s scoring methodology assigns 1, 3, or 5 points to each requirement based on the potential damage a gap could cause. You start at 110 and lose points for each requirement you haven’t met. Of the four requirements that apply to your open-source packages, three (inventory, vulnerability scanning, and flaw remediation) are worth five points each, and user-installed software is worth one.
A plan of action and milestones (POA&M) lets you carry a few gaps past an assessment, and section 170.21 of the program rule limits it sharply. You only get a Conditional status, the one that allows a POA&M, with a score of at least 88 out of 110.
Only requirements worth one point can be included in the plan, except for the encryption requirement, which is normally worth five points but can be included when it’s scored at three because the encryption used isn’t validated under the Federal Information Processing Standards (FIPS). The rule also bars six specific requirements from the plan regardless of the score: the system security plan requirement, two covering external connections and public information, and three physical access requirements.
Putting a gap on the plan doesn’t change its finding, which stays NOT MET until it’s closed.
Whatever lands on the plan must be closed and confirmed within 180 days, or the Conditional status will expire. That 180-day closeout applies to both a Level 2 self-assessment and a third-party assessment.
Inventory, vulnerability scanning, and flaw remediation are five-point requirements, so none of them can go on the plan: you either meet them at assessment time or you don’t get Conditional status. User-installed software is a one-point requirement, so a gap there can go on the plan as long as your overall score is still at least 88. It still counts as NOT MET and has to be closed within 180 days.
Note: The operational plan of action under CA.L2-3.12.2 is a separate artifact. The rule defines it as a record of temporary vulnerabilities and deficiencies and how they’ll be fixed, with no timeline attached, and it isn’t the same as an assessment POA&M. The 180-day deadline belongs to the POA&M.
CMMC Compliance Requirements for Contractors and Small Businesses
The program rule applies to DoD contract and subcontract awardees that process, store, or transmit FCI or CUI in the course of their work, and it flows down to subcontractors that do the same. DoD program managers determine the CMMC level for each procurement based on the information involved and the program’s criticality, so two companies of the same size can end up with different levels. Within Level 2, the 110 requirements are one list for everyone.
Size shows up in DoD’s own reasoning. The July 13 announcement that suspended Phase 2 said the department’s review aims to lower barriers for small and non-traditional businesses. Until that review produces changes, the self-assessment regime is the relief that exists.
Where SecureChain Fits
SecureChain from TuxCare delivers open-source packages that are screened before they reach you and patched for as long as you depend on them. It works as a single source for JavaScript, Python, Java, Go, Rust, and PHP.
Each package is rebuilt from source in isolated environments and checked for malware and suspicious code, and anything that fails inspection is blocked before it reaches your environment. Active components are patched under a service-level agreement. When upstream maintenance ends, Endless Lifecycle Support (ELS) continues to provide fixes for unmaintained components.
It also produces records about what it delivers, including provenance at Supply-chain Levels for Software Artifacts (SLSA) Level 3, an SBOM, and Vulnerability Exploitability eXchange (VEX) data.
What You’ll Be Asked to Show
Nothing in CMMC uses the words “open source.” But when you score yourself on your system inventory, your scan results, and your record of what was fixed and when, every open-source package in your applications must show up in each of them. If you can’t produce those three things for a package today, that’s the gap to close first.
FAQ
What Are CMMC Compliance Requirements?
The Cybersecurity Maturity Model Certification (CMMC) program sets security requirements for defense contractors handling Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). Level 1 covers 15 basic requirements, Level 2 covers the 110 requirements in the National Institute of Standards and Technology’s SP 800-171 Revision 2, and Level 3 adds 24 selected requirements from SP 800-172.
When Is CMMC Compliance Required in 2026?
It depends on the contract. Since November 10, 2025, new Department of Defense solicitations can require Level 1 or Level 2 self-assessments as a condition of award under the Cybersecurity Maturity Model Certification (CMMC) program. Phase 2, which would have added third-party Level 2 assessments on November 10, 2026, has been suspended since July 13, 2026.
What Are CMMC Compliance Requirements for Small Businesses?
Small businesses face the same requirements as other contractors at their level. The program rule sets requirements by the type of information handled, and Level 2 is one list of 110 requirements for everyone. The Department of Defense’s July 2026 announcement pausing part of the program said its review aims to lower barriers for small and non-traditional businesses.
Does CMMC Level 2 Require Open-Source Provenance Records?
No. In the Cybersecurity Maturity Model Certification (CMMC) program, none of the 110 Level 2 requirements names open source or provenance. The discussion for user-installed software, CM.L2-3.4.9, says prohibited installs may include software with unknown or suspect pedigrees, but that’s discussion text. Supply chain risk is named in two Level 3 requirements.
Can a Plan of Action and Milestones Cover Flaw Remediation?
It can’t. A plan of action and milestones can hold only one-point requirements, apart from one encryption exception, and flaw remediation (SI.L2-3.14.1) is scored at five points under the program rule. A plan also needs a score of at least 88 of 110 and has to be closed within 180 days, or the Conditional status expires.
How Do You Maintain CMMC Compliance After an Assessment?
Under the Cybersecurity Maturity Model Certification (CMMC) program, an affirming official, the person with authority to attest to the company’s compliance, has to confirm continuing compliance every year. A Level 2 status lasts three years before it needs a new assessment, and Level 1 self-assessments repeat annually.
