Walk into any small machine shop in Ohio or a mid-sized avionics supplier in Arizona, and you will find the same conversation repeating itself: the prime contractor sent a new flow-down clause, and someone has to figure out what it means before the next delivery order. The Defense Industrial Base, which the Cybersecurity and Infrastructure Security Agency estimates at more than 300,000 companies, has spent the last several years wrestling with a set of regulations that once seemed distant. The Cybersecurity Maturity Model Certification, finalized by the Department of Defense in its 32 CFR Part 170 rulemaking, has moved from a theoretical framework into an actual contractual gate. Software supply chain practices sit at the heart of that gate, and most of the companies involved did not build their shops around software hygiene to begin with.
The Regulatory Stack the DIB Actually Works Under
CMMC does not stand alone. Underneath it lies NIST Special Publication 800-171 Revision 2, which defines the 110 security requirements for protecting Controlled Unclassified Information. The Defense Federal Acquisition Regulation Supplement clauses 252.204-7012, 7019, 7020, and 7021 translate those technical requirements into enforceable contract language. Layered on top are the requirements from NIST SP 800-172 for companies handling high-value assets, and a growing set of expectations tied to Executive Order 14028 and OMB Memoranda M-22-18 and M-23-16 on secure software development.
For a company building a component that will eventually integrate with a weapons system, the regulatory picture is not a single document but a stack. The DoD Chief Information Officer issues guidance on software assurance. The Defense Contract Management Agency assesses contractor compliance through the DIBCAC. The Defense Counterintelligence and Security Agency oversees facility clearances. NASA, the Missile Defense Agency, and the military services each publish their own supplemental instructions. A prime like Lockheed Martin or RTX sits atop that stack and cascades the requirements downward, usually with additional contractual overlays of its own.
Where the Software Supply Chain Intrudes
Historically, the DIB's cybersecurity conversation focused on perimeter controls, data at rest, and incident reporting. What changed is the realization that software components, whether embedded firmware in a navigation module or the Python libraries used to run a quality-assurance dashboard, are part of the attack surface and therefore part of the compliance surface. NIST SP 800-171 requirements like 3.4.1 (baseline configurations), 3.14.1 through 3.14.7 (system and information integrity), and 3.12.1 through 3.12.4 (security assessment) all touch software components directly.
The SolarWinds intrusion made the point vivid. A trusted update channel delivered malicious code into federal agencies and cleared defense contractors. The response across the DoD has been to treat third-party software, open source dependencies, and build infrastructure as items that must be inventoried, attested, and continuously monitored. DFARS 252.204-7012 already required rapid reporting of cyber incidents on contractor information systems, but CMMC elevates the underlying practices into auditable requirements with external assessment.
The SBOM Question
Executive Order 14028 launched the Software Bill of Materials conversation in earnest, and the DoD has followed suit. The Department's Enterprise DevSecOps Fundamentals and the associated Reference Designs now expect SBOMs for software delivered on contracts that touch CUI. The National Telecommunications and Information Administration's minimum elements for SBOMs remain the baseline format expectation, and both CycloneDX and SPDX are accepted. What is different in the DIB is that SBOMs are not a disclosure requirement to end users but a contractual artifact passed between tiers of suppliers.
A Tier 3 supplier building a printed circuit board assembly may deliver firmware to a Tier 2 integrator, which then delivers a subsystem to a Tier 1 prime, which delivers the platform to a program office. Each handoff can include an SBOM, and each tier is expected to ingest, analyze, and forward those SBOMs as part of its own deliverable. The operational mechanics of this have been painful. Small suppliers often lack the tooling, and even large primes have struggled to reconcile SBOMs from dozens of sub-suppliers into a cohesive view.
CMMC Levels and What They Actually Demand
Under the finalized CMMC 2.0 rule, contractors fall into three levels. Level 1 covers the 17 basic FAR 52.204-21 safeguards and applies to companies handling only Federal Contract Information. Level 2 covers all 110 NIST SP 800-171 controls and applies to most contractors handling CUI. Level 3 adds a subset of the enhanced NIST SP 800-172 requirements for programs with the highest risk.
For Level 2, which is where most DIB companies land, assessments by C3PAOs, accredited by the Cyber AB, are the new normal. Those assessments explicitly evaluate software supply chain practices: how a contractor ingests open source, how it manages build systems, whether it can produce evidence of SBOM generation for delivered software, and how it handles vulnerability response. A contractor that cannot produce an SBOM for its own application code or show evidence of a dependency update cadence will struggle with SC-8, SI-2, and CM-2 implementation objectives.
Human Realities on the Shop Floor
The compliance narrative reads cleanly on paper and crumbles on contact with reality. A typical mid-sized machine shop might have a single IT administrator, a contract-manufacturing MES running on an old Windows Server, and a CAD system with plugins nobody has updated in years. The engineers writing G-code for CNC machines are not thinking about software supply chain attestations. The company's exposure to open source is often invisible to leadership, hidden inside vendor-supplied tools and embedded controllers.
The DoD's Project Spectrum and the National Defense Industrial Association have both tried to meet these companies where they are. The DIB Cybersecurity Program offers shared threat intelligence. The Blue Cyber initiative runs free training for small business primes. And several primes have begun subsidizing CMMC preparation for their critical suppliers rather than watching the supply base shrink under compliance pressure. Still, the unevenness across the base is the defining feature of the current moment. Some suppliers have mature secure software development environments with signed builds, ephemeral runners, and continuous SBOM generation. Others are still patching a single SharePoint site and hoping.
The Prime Contractor's Problem
Primes are not bystanders in this. Under DFARS 252.204-7021, they are responsible for flowing CMMC requirements down to subcontractors handling CUI and for ensuring that those subcontractors maintain the required level. Supply chain risk management programs at companies like Northrop Grumman and General Dynamics now include software supply chain risk analysis as a standing line item. These programs use SBOMs, commercial threat intelligence, and continuous monitoring feeds to track the software components flowing into their products.
The practical challenge is that primes cannot realistically audit every Tier 3 supplier. They rely on a combination of contractual attestations, CMMC certification evidence, and spot-check assessments. When a zero-day hits a widely used library, primes need to know which of their suppliers ship affected components and how quickly those suppliers can remediate. That capability is still maturing, and most primes will privately acknowledge that their software supply chain visibility drops off sharply past Tier 2.
How Safeguard Helps
Safeguard is built for the layered reality of the Defense Industrial Base. We generate and validate SBOMs in both CycloneDX and SPDX formats, map findings directly to NIST SP 800-171 control families, and produce evidence artifacts that assessors look for during a CMMC Level 2 assessment. Primes use Safeguard to ingest SBOMs from their supplier base and to identify vulnerable components across their product lines within hours of a disclosure. Smaller suppliers get a guided experience that lowers the cost of generating attestations, maintaining a component inventory, and responding to flow-down requests. The goal is simple: make software supply chain compliance something the DIB can actually sustain across every tier.