If you are a defense contractor, software supply chain security is not optional and not aspirational. It is a contractual obligation backed by the full weight of federal acquisition regulation. The intersection of SBOMs, CMMC, and DoD acquisition requirements creates a compliance landscape that is complex but navigable if you understand how the pieces fit together.
The Regulatory Stack
Defense contractors face a layered set of requirements that all touch software supply chain security.
Executive Order 14028
The May 2021 Executive Order on Improving the Nation's Cybersecurity directed NIST to publish guidance on software supply chain security, which resulted in the Secure Software Development Framework (SSDF, SP 800-218) and minimum SBOM requirements. While the EO applies directly to software sold to the federal government, its influence extends to all defense acquisition.
DFARS 252.204-7012
This clause requires contractors handling Controlled Unclassified Information (CUI) to implement NIST SP 800-171 security controls. While 800-171 does not explicitly mention SBOMs, several controls relate directly to software supply chain security, including supply chain risk management (3.16) and system and information integrity (3.14).
CMMC 2.0
The Cybersecurity Maturity Model Certification formalizes the assessment of NIST 800-171 implementation. CMMC Level 2 requires compliance with all 110 controls in 800-171, and Level 3 adds a subset of 800-172 enhanced controls. Software supply chain practices support multiple control families.
NIST SP 800-171 Rev 3
The latest revision, published in 2024, updates the control set and adds more explicit requirements around supply chain risk management. Contractors should be preparing for Rev 3 requirements even if current contracts reference Rev 2.
Where SBOMs Fit in CMMC
SBOMs are not a standalone CMMC requirement. Instead, they are a mechanism for implementing and demonstrating compliance with several control families.
Supply Chain Risk Management (SR): Controls in this family require organizations to identify, assess, and mitigate supply chain risks. An SBOM is the foundational artifact that enables supply chain risk assessment for software. Without knowing what components are in your software, you cannot assess the risk they introduce.
System and Information Integrity (SI): Controls requiring vulnerability monitoring (SI-2, SI-5) and flaw remediation are directly supported by SBOM-based vulnerability correlation. When a new CVE is published, your SBOM lets you determine within minutes whether your systems are affected.
Configuration Management (CM): Controls requiring component inventory (CM-8) and configuration baselines (CM-2) are naturally addressed by maintaining current SBOMs. An SBOM is effectively a software component inventory.
Risk Assessment (RA): Controls requiring vulnerability scanning and risk assessment (RA-5) benefit from SBOM data that identifies all software components subject to vulnerability analysis.
Practical Implementation for Defense Contractors
Step 1: Inventory Your Software Deliverables
Identify every piece of software you deliver to the DoD or use to process CUI. This includes:
- Custom-developed applications
- Commercial off-the-shelf (COTS) software you integrate
- Open-source components in your products
- Development and build tools in your pipeline
- Cloud services and SaaS platforms
For each, determine whether you can generate an SBOM, need to request one from a vendor, or need to perform binary analysis.
Step 2: Establish SBOM Generation
For software you develop, integrate SBOM generation into your CI/CD pipeline. Use CycloneDX or SPDX format -- both are acceptable under current DoD guidance, though CycloneDX tends to be more widely supported in security tooling.
For COTS and third-party software, request SBOMs from vendors. Include SBOM delivery requirements in your procurement contracts. Where vendors cannot provide SBOMs, consider binary analysis tools like FOSSA or Black Duck.
Step 3: Implement Vulnerability Correlation
Generating SBOMs without correlating them against vulnerability databases is like doing an inventory without checking for recalls. Set up automated correlation against:
- National Vulnerability Database (NVD)
- CISA Known Exploited Vulnerabilities (KEV) catalog
- GitHub Advisory Database
- OSV (Open Source Vulnerability) database
Pay special attention to the KEV catalog. CISA Binding Operational Directive 22-01 requires federal agencies to remediate KEV vulnerabilities within specified timelines, and defense contractors should treat KEV entries as high-priority remediation items.
Step 4: Define Remediation SLAs
Establish clear timelines for vulnerability remediation based on severity and exploitability:
- KEV-listed vulnerabilities: Remediate within CISA-specified timelines (typically 14-21 days)
- Critical CVEs with high EPSS scores: 30 days
- High CVEs: 60 days
- Medium CVEs: 90 days
- Low CVEs: Next scheduled maintenance
Document these SLAs in your System Security Plan (SSP) and demonstrate adherence during CMMC assessments.
Step 5: Maintain Audit Evidence
CMMC assessors will want to see evidence that your software supply chain practices are implemented, not just documented. Maintain:
- Historical SBOMs showing component evolution over time
- Vulnerability correlation reports with triage decisions
- VEX statements documenting exploitability analysis
- Remediation records showing timely response to identified vulnerabilities
- Policy gate results from CI/CD pipeline showing enforcement
This evidence directly supports your Plan of Action and Milestones (POA&M) and demonstrates continuous monitoring, which is critical for CMMC Level 2 and above.
Handling Classified and CUI-Adjacent Software
Software that processes CUI has additional handling requirements. SBOMs for CUI systems should:
- Be stored in CUI-designated systems with appropriate access controls
- Not include detailed architecture information that could reveal system vulnerabilities (balance transparency with OPSEC)
- Be shared only with authorized personnel and assessors
- Be included in your CUI marking and handling procedures
For classified software, SBOM handling follows classification guide requirements. This is a domain where your security classification guide and your SBOM program must be coordinated.
Supply Chain Risk Management for Subcontractors
Prime contractors are responsible for flowing down security requirements to subcontractors. This means:
- Including SBOM requirements in subcontract agreements
- Validating that subcontractor-provided SBOMs meet quality standards
- Monitoring subcontractor compliance with vulnerability remediation timelines
- Maintaining a consolidated view of the software supply chain across all tiers
The practical challenge is that many small defense subcontractors lack the tooling and expertise to generate quality SBOMs. Primes that invest in subcontractor enablement -- providing tooling guidance, templates, and training -- will have more compliant supply chains.
Preparing for Assessment
When preparing for a CMMC assessment, your SBOM program should be able to demonstrate:
- Policy and procedure documentation: Written policies defining your SBOM generation, correlation, and remediation processes
- Tooling implementation: Evidence that SBOMs are generated automatically as part of your build process
- Continuous monitoring: Current vulnerability correlation data showing ongoing monitoring
- Remediation evidence: Records of vulnerabilities identified and remediated within SLA timelines
- Supply chain integration: Evidence of SBOM requirements in supplier agreements and incoming BOM validation
How Safeguard.sh Helps
Safeguard.sh provides the unified platform defense contractors need to operationalize their SBOM program for CMMC compliance. It generates and stores SBOMs with full version history, performs continuous vulnerability correlation with KEV integration, and produces the audit evidence that CMMC assessors require.
The policy gate feature lets you define remediation SLAs aligned with DoD requirements and enforce them automatically in your CI/CD pipeline. When an assessor asks to see evidence of your vulnerability management process, Safeguard.sh provides the complete audit trail from BOM generation through vulnerability identification, triage, and remediation.