Supply chain security for aerospace and defense contractors serving the U.S. Department of Defense in 2026 is defined by one overriding fact: the CMMC Program Rule (Title 32 CFR Part 170) became effective on 16 December 2024, and the companion DFARS rule (Title 48 CFR, finalized in 2025) is now appearing in contract clauses. Phase 1 of the CMMC Program -- self-assessments for Level 1 and some Level 2 contracts -- began in 2025, with Phase 2 requiring third-party assessments for many Level 2 contracts rolling out through 2026. For software flowing through the defense industrial base (DIB), the combination of CMMC, DFARS 252.204-7012/-7020/-7021, NIST SP 800-171 Revision 3, and the flow-down of Executive Order 14028 secure software development attestation represents the strictest and most enforceable supply chain regime any sector faces.
This post covers what aerospace and defense primes, Tier-1 subs, and specialty software suppliers to the DoD need to have in place for supply chain security in 2026.
What changes under the CMMC final rule in 2026?
CMMC 2.0 codified at 32 CFR Part 170 sets three assessment levels. Level 1 covers Federal Contract Information (FCI) with 15 basic safeguarding requirements from FAR 52.204-21. Level 2 covers Controlled Unclassified Information (CUI) and maps to the 110 requirements of NIST SP 800-171 R2 (with R3 adoption pending). Level 3 covers CUI associated with the highest priority programs and adds a subset of NIST SP 800-172 enhanced requirements.
The assessment model is tiered: Level 1 and a subset of Level 2 allow annual self-assessment with senior official affirmation. Most Level 2 contracts require triennial C3PAO (Certified Third-Party Assessment Organization) assessments. Level 3 requires DIBCAC-led government assessments. Phase 1 began on the effective date of the DFARS rule (in 2025), with phased inclusion of CMMC requirements in solicitations over three years.
For software supply chain, the critical 800-171 families are 3.11 (Risk Assessment), 3.14 (System and Information Integrity), 3.17 (Supply Chain Risk Management -- added in Rev 3), and elements of 3.4 (Configuration Management) and 3.13 (System and Communications Protection).
How does NIST SP 800-171 Revision 3 change supply chain requirements?
NIST SP 800-171 R3, published 14 May 2024, introduced a new SR family (Supply Chain Risk Management) mirroring the SP 800-53 R5 SR controls:
- SR-2: Supply chain risk management plan
- SR-3: Supply chain controls and processes
- SR-5: Acquisition strategies, tools, and methods
- SR-6: Supplier assessments and reviews
- SR-8: Notification agreements
- SR-10: Inspection of systems or components
- SR-11: Component authenticity
- SR-12: Component disposal
The DoD issued class deviations and guidance in 2024-2025 clarifying the transition to R3 for CMMC assessment objectives. In 2026, many contracts reference 800-171 R2 while the assessment guide migrates to R3. Contractors targeting Level 2 assessments should be positioned to demonstrate R3-aligned SR practices even when contracts cite R2.
What does DFARS 252.204-7012 still require?
DFARS 252.204-7012 -- the "safeguarding covered defense information and cyber incident reporting" clause -- has been in contracts since 2016. It requires compliance with NIST SP 800-171 (with the R3 transition underway), 72-hour cyber incident reporting via DIBNet, malicious software submission, media preservation, cloud service requirements (FedRAMP Moderate equivalent), and contractor flow-down to subcontractors handling CUI.
A software supply chain compromise that results in unauthorized access to CUI is a reportable cyber incident. Your incident response plan must be able to identify, within hours, what software is running, what is compromised, and whether CUI was exposed. That depends on a current SBOM.
How does DFARS 252.204-7020 change assessment exposure?
DFARS 252.204-7020 (NIST SP 800-171 DoD Assessment Requirements) requires contractors to have current Basic, Medium, or High assessment scores in the Supplier Performance Risk System (SPRS). The Basic assessment is a self-assessment; Medium and High are DIBCAC-led. Prime contractors must verify subcontractor SPRS scores before awarding subcontracts involving CUI. Scores below 110 with material deficiencies can delay or disqualify subcontract awards.
In 2026, primes are pushing SPRS scoring down the chain more aggressively. If your score reflects gaps in SR controls because you lack SBOM workflows, that gap is visible to your customers through SPRS.
What about DFARS 252.204-7021 and CMMC clauses?
DFARS 252.204-7021, published as part of the CMMC DFARS rule, mandates the CMMC level and assessment type required for each contract. Contractors must maintain the required level throughout contract performance. Annual affirmations by a senior official are required for Level 2 and Level 3. False affirmations carry False Claims Act exposure -- something the DOJ's Civil Cyber-Fraud Initiative has used to extract multi-million-dollar settlements since 2022.
How does EO 14028 flow down to defense software?
Executive Order 14028 (May 2021) and OMB Memoranda M-22-18 and M-23-16 require federal agencies to obtain self-attestations from software producers that they follow secure development practices aligned with NIST SP 800-218 (SSDF) and to collect SBOMs where required. CISA's Secure Software Development Attestation Form and the associated CISA repository operationalize this. DoD contracts reference these requirements for contractor-developed software delivered to DoD.
The attestation is signed by a company officer and covers 12 specific practices including multi-factor authentication for the development environment, trusted source code supply chains, provenance data, and vulnerability disclosure. The SBOM, while not universally required on every attestation, is increasingly requested for high-impact software.
What SBOM depth do DoD customers actually want?
From program-office requirements in 2024-2025 and the evolving guidance in the DoD Enterprise DevSecOps Reference Design and the Software Acquisition Pathway:
- Full transitive dependency resolution, not just direct dependencies.
- Firmware and bootloader components for embedded systems, mission computers, and weapon platforms.
- Container image layers for anything deployed on Platform One, Kessel Run, or equivalent platforms.
- Build provenance at SLSA Level 3 or higher for software supporting warfighter missions.
- Cryptographic material inventory where relevant for FIPS 140-3 validated module claims.
- Delta SBOMs for updates delivered over the air or through sustainment channels.
- Retention for the full program lifecycle -- often 20-40 years for major weapon systems.
How do classified and ITAR constraints shape the SBOM workflow?
Aerospace and defense software often involves classified environments, ITAR-controlled technical data, or export-controlled components under EAR. SBOM tools and storage must respect these constraints. Practical considerations:
- SBOM generation tools running on classified networks need vulnerability databases mirrored into those networks with a documented data-import process.
- SBOMs themselves can contain export-controlled information (component names and versions can reveal weapon system architecture) and must be handled accordingly.
- Cross-domain solutions (CDS) are needed to transfer SBOM-derived information between classification levels.
- Vendor relationships for SBOM platforms must accommodate U.S. person requirements, supply chain risk management for the tooling itself, and FedRAMP High equivalence for cloud deployments.
What about nation-state supply chain threats?
The threat environment for DIB contractors is defined by nation-state adversaries. The 2020 SolarWinds compromise attributed to APT29 reached multiple defense-related networks. The 2024 XZ Utils backdoor -- attributed to a long-running adversary-prepositioned implant in OpenSSH -- showed the depth an adversary is willing to go to reach DIB targets. NSA, CISA, and FBI joint advisories in 2024-2025 have emphasized the persistent targeting of DIB software supply chains.
Defense against these threats requires SBOM-informed continuous monitoring, build provenance attestations, and aggressive ingress control on open-source packages. It also requires vendor due diligence for small specialty suppliers that may be sole-source for critical components.
How Safeguard.sh Helps
Safeguard.sh is engineered for the aerospace and defense environment. The platform generates and ingests SBOMs in SPDX and CycloneDX from source, container, and firmware artifacts; supports SLSA build provenance attestations; and retains supply chain evidence across the full 20-40 year weapon system lifecycle that DIB programs require.
For CMMC Level 2 and Level 3 assessments, Safeguard.sh produces the evidence that C3PAOs and DIBCAC assessors ask for against 800-171 R3 SR-family controls, SI controls, and CM controls. The platform supports SPRS-aligned self-assessment scoring so primes and subs can confidently report under DFARS 252.204-7020.
For classified and ITAR-constrained environments, Safeguard.sh offers deployment options that support air-gapped operation, U.S.-person-only handling, and FedRAMP-aligned cloud postures. For EO 14028 self-attestations and SBOM deliverables to DoD program offices, Safeguard.sh produces the artifacts CISA's repository accepts and that program-office cybersecurity leads expect. For DIB contractors building toward or maintaining CMMC status in 2026, Safeguard.sh consolidates the software supply chain control base into a single operational platform aligned with the actual evidence requirements.