Federal contractors now face a stack of overlapping software supply chain mandates that didn't exist five years ago, and the deadlines are no longer theoretical. CMMC 2.0 became effective on December 16, 2024, and DoD has begun phasing the CMMC contract clause into new solicitations. OMB Memo M-22-18 requires every agency to collect a self-attestation of secure software development practices before using third-party software — including SaaS — and CISA's standard attestation form has been in circulation since March 2023. Layer on NIST SP 800-171 Revision 3 (finalized May 2024), NDAA Section 1655's SBOM directives, and FAR case 2023-002 on cyber incident reporting, and a mid-size defense contractor can be juggling four or five distinct compliance regimes simultaneously, each with its own evidence requirements. This post breaks down what's actually required, by which date, and what happens when a contractor can't produce the evidence an assessor or contracting officer asks for.
What is CMMC 2.0 and when do contractors need to comply?
CMMC 2.0 is the Department of Defense's tiered cybersecurity certification model, and the final rule (32 CFR Part 170) took effect December 16, 2024, with the companion DFARS contract clause rule (48 CFR) finalized in 2025 to begin appearing in new solicitations. The model has three levels: Level 1 (Foundational, 15 basic safeguarding requirements, annual self-assessment) covers contractors handling Federal Contract Information; Level 2 (Advanced, 110 controls mapped to NIST SP 800-171 Rev 2) requires either self-assessment or third-party assessment via a C3PAO depending on data sensitivity; Level 3 (Expert, adds 24 controls from NIST SP 800-172) requires government-led assessment. DoD estimates roughly 220,000 companies in the Defense Industrial Base will eventually need some level of certification, with the rollout phased over a three-year period following the clause's appearance in contracts. A Level 2 assessment against 110 controls routinely surfaces software composition and vulnerability management gaps — control CA.L2-3.12.1 and RA.L2-3.11.1 specifically require systems to identify and remediate vulnerabilities, which in practice means having an accurate inventory of every open-source and third-party component in your software.
What does OMB Memo M-22-18 actually require from software producers?
OMB M-22-18, issued September 14, 2022, requires federal agencies to obtain a self-attestation from any software producer whose software touches federal information systems, confirming the software was developed in conformance with NIST SP 800-218 (the Secure Software Development Framework). The follow-up memo M-23-16 (June 2023) extended attestation deadlines and clarified that agencies could request a Plan of Action and Milestones (POA&M) in lieu of full conformance, but the underlying obligation didn't go away — it moved the deadline for critical software to no earlier than three months after OMB approved the centralized attestation collection process, and for all other software to six months after that. CISA published its common self-attestation form in March 2023, and by 2024 agencies were actively requesting it from vendors before renewing or awarding contracts. The form asks producers to attest to specific SSDF practices: using automated tools to check for known vulnerabilities (PW.7/PW.8), maintaining provenance data for internal and third-party code, and separating build environments. A vendor that can't back up the attestation with actual tooling — not just a signed PDF — is exposed if an agency later asks for supporting evidence, which M-23-16 explicitly permits agencies to do.
Do federal contractors need to produce a Software Bill of Materials?
Yes — SBOM generation has been a federal software supply chain requirement since Executive Order 14028 (May 12, 2021) directed NIST to define minimum SBOM elements, which NTIA published in July 2021 and CISA has continued to refine, including a 2024 update covering SBOM types and integrity checks. NDAA Section 1655 (FY2023) went further, directing an update to FAR/DFARS to require SBOMs for software delivered to DoD, and several agencies — including CISA and VA — have already built SBOM ingestion pipelines to receive them from vendors. The minimum elements are specific: supplier name, component name, version string, dependency relationships, unique identifiers (like a CPE or PURL), author of the SBOM data, and a timestamp — in either SPDX, CycloneDX, or SWID format. In practice, a single mid-sized application can produce an SBOM listing 400-800+ dependencies once transitive packages are included, and that number changes with every release, which is why a point-in-time SBOM generated manually for a single audit is already stale by the next sprint. Contractors delivering software to DoD program offices are increasingly seeing SBOM delivery written directly into contract data requirements lists (CDRLs).
What happens if a contractor fails a CMMC assessment or can't support an attestation?
A failed CMMC assessment or an unsupported self-attestation results in contract ineligibility, not just a deficiency notice — DoD's rule makes CMMC certification a condition of contract award at the applicable level, meaning a contractor without a current certification simply cannot be awarded (or in some structures, cannot continue performance on) a covered contract. The False Claims Act adds a second layer of exposure: DOJ launched its Civil Cyber-Fraud Initiative in October 2021 specifically to pursue contractors who knowingly misrepresent their cybersecurity compliance in contracts, grants, or attestations, and there have been multi-million-dollar settlements since — including a $4 million settlement in 2024 involving a government IT contractor's cybersecurity misrepresentations. That means a self-attestation submitted under M-22-18 that overstates a contractor's actual SSDF conformance isn't just a compliance gap, it's a potential qui tam liability. Practically, assessors and contracting officers are asking for artifacts: vulnerability scan history, SBOM records tied to specific releases, and evidence that identified vulnerabilities were actually remediated rather than just logged.
How does NIST SP 800-161 change supply chain risk management obligations?
NIST SP 800-161 Revision 1 (published May 2022) formalized Cybersecurity Supply Chain Risk Management (C-SCRM) as a required practice for federal agencies and, by extension, the contractors supplying them, requiring risk assessment across the entire supplier and component chain rather than just the prime contractor's own code. It's the control set referenced by FedRAMP's supply chain risk management requirements and increasingly cited in agency RFPs asking vendors to describe their C-SCRM program. Combined with FASCSA (the Federal Acquisition Supply Chain Security Act, which established the FASC and gives agencies authority to exclude specific suppliers) and Section 889 restrictions on covered telecom equipment, contractors now need to track risk not just at the application layer but at the vendor and component-origin layer — where was this library published, by whom, and has that maintainer account shown signs of compromise. This is a materially different question than "do we have a vulnerability scanner," and most legacy AppSec tooling built for OWASP Top 10-style findings wasn't designed to answer it.
How Safeguard Helps
Safeguard maps directly onto the evidence federal contractors actually need to produce under these mandates. Our SBOM generation and ingestion pipeline produces NTIA-minimum-element-compliant SPDX and CycloneDX documents tied to every build, so a CDRL deliverable or a CISA-bound SBOM is a current export rather than a quarterly scramble. Reachability analysis cuts through the noise that makes SSDF conformance and CMMC RA.L2-3.11.1 evidence hard to produce honestly — instead of attesting to "we scan for vulnerabilities" against a list of hundreds of CVEs across transitive dependencies, contractors can show which vulnerabilities are actually exploitable in their running code, which is what a False Claims Act-conscious attestation should be based on. Griffin, Safeguard's AI remediation engine, and auto-fix pull requests close the loop by turning identified, reachable vulnerabilities into merged fixes with an audit trail, giving contractors a defensible remediation record if an agency or C3PAO assessor asks for proof rather than a promise.