Executive Order 14028 changed everything for government software suppliers. If your company sells software to federal agencies, the question is no longer whether you'll need to provide SBOMs -- it's how quickly you can produce them and whether they meet the requirements.
This guide is for government contractors, ISVs selling to federal agencies, and anyone in the federal software supply chain who needs to understand what compliance actually looks like.
The Regulatory Foundation
Executive Order 14028
Signed in May 2021, EO 14028 ("Improving the Nation's Cybersecurity") set the wheels in motion. Section 4 specifically addresses software supply chain security and directs NIST to develop guidance for SBOMs, secure development practices, and software security testing.
The executive order applies to software purchased by federal agencies, which means it flows down to every contractor and vendor in the supply chain. If you sell software to the federal government -- directly or indirectly -- this applies to you.
NIST SSDF (SP 800-218)
The Secure Software Development Framework is NIST's response to EO 14028. It outlines practices for secure software development, including:
- PS.3: Archive and protect each software release, including its SBOM
- PW.4: Verify third-party software components and reuse existing, well-secured components
- RV.1: Identify and confirm vulnerabilities on an ongoing basis
Self-attestation against the SSDF is now required for critical software sold to federal agencies. This means you need to demonstrate that you follow these practices, and SBOMs are explicitly part of the framework.
OMB Memoranda
OMB M-22-18 and M-23-16 established timelines and requirements for agencies to collect software attestation from vendors. Key requirements include:
- Vendors must attest to following secure development practices
- Agencies may request SBOMs and other artifacts
- Critical software has tighter requirements and shorter timelines
CISA SBOM Guidance
CISA has published extensive guidance on SBOM minimum elements, including:
- Baseline component information: Supplier name, component name, version, unique identifier, dependency relationship, author of SBOM data, timestamp
- Automation support: SBOMs must be machine-readable
- Practices and processes: Known unknowns must be documented, SBOMs must be updated with each release
What Compliance Actually Requires
Let's get specific about what a government contractor needs to have in place.
SBOM Generation
You need to produce SBOMs for every version of software you deliver to federal agencies. These SBOMs must:
- Be in a standard machine-readable format (SPDX or CycloneDX)
- Include all direct and transitive dependencies
- Be generated as part of your build process, not manually assembled
- Be updated with every release, patch, or update
- Include the minimum elements defined by CISA
For most organizations, this means integrating SBOM generation tools into your CI/CD pipeline. Manual SBOM creation is neither scalable nor reliable.
Self-Attestation
Under the current framework, you need to self-attest that your development practices align with the NIST SSDF. This includes attesting that you:
- Maintain SBOMs for your software
- Use automated tools to identify vulnerabilities in components
- Have processes for addressing known vulnerabilities
- Protect your build environments from tampering
The attestation form (available from CISA) must be signed by a company executive. This is not a checkbox exercise -- it creates executive-level accountability for your software security practices.
Artifact Delivery
When an agency requests an SBOM, you need to be able to deliver it promptly. Some agencies are building automated systems to ingest and process SBOMs, so your delivery mechanism needs to support machine-readable formats, not PDFs.
Practically, this means:
- Having a system to store and retrieve SBOMs by software product and version
- Being able to deliver SBOMs in both SPDX and CycloneDX formats (different agencies may have different preferences)
- Including SBOMs in your standard delivery packages alongside software artifacts
Vulnerability Management
Having an SBOM is step one. You also need to demonstrate that you actively monitor the components in your SBOMs for newly disclosed vulnerabilities and have processes to remediate them.
This means:
- Continuous scanning of your component inventory against vulnerability databases
- A defined process for assessing vulnerability impact and prioritizing remediation
- Documentation of your vulnerability response timeline and procedures
- Communication protocols for notifying customers (agencies) of significant vulnerabilities
Common Pitfalls for Government Contractors
Incomplete Dependency Trees
The most common SBOM quality issue is incomplete dependency trees. Your SBOM lists the libraries you explicitly include, but what about the libraries those libraries depend on? Transitive dependencies are where most vulnerabilities hide.
Ensure your SBOM generation tool captures the full dependency tree, not just top-level dependencies.
Build vs. Runtime Discrepancy
Your SBOM should reflect what actually gets deployed, not just what's in your source code. Build-time dependencies that aren't included in the final artifact shouldn't be in the SBOM, and runtime dependencies that are pulled in through other mechanisms need to be captured.
Container and Infrastructure Components
If you deliver containerized software (and many government contractors do), your SBOM needs to include the container base image components and any infrastructure software bundled in the deployment.
Subcontractor Management
If you use subcontractors who contribute code or components, their contributions need to be captured in your SBOM. This requires flowing down SBOM requirements to your subcontractors, which many prime contractors have been slow to do.
SBOM Freshness
An SBOM from six months ago is not useful. Your SBOMs need to be current -- generated with each build or release, not periodically refreshed.
Implementation Roadmap
Month 1-2: Assessment
- Inventory all software products delivered to federal agencies
- Identify current SBOM generation capabilities (likely minimal)
- Assess CI/CD pipeline integration points
- Review NIST SSDF against current practices
Month 3-4: Tooling and Integration
- Select and deploy SBOM generation tools
- Integrate into CI/CD pipelines for all federal software products
- Establish SBOM storage and retrieval system
- Begin continuous vulnerability monitoring
Month 5-6: Process and Documentation
- Document SBOM generation and management procedures
- Create vulnerability response processes specific to component vulnerabilities
- Train development teams on SBOM practices
- Prepare self-attestation documentation
Month 7+: Operationalize
- Generate SBOMs with every release
- Continuously monitor for new vulnerabilities
- Respond to agency SBOM requests
- Regularly review and improve processes
The Competitive Advantage
Here's the thing that many contractors miss: SBOM compliance is not just a cost center. It's becoming a competitive differentiator. Agencies are starting to include software security practices in their evaluation criteria. Contractors who can demonstrate mature SBOM programs will have an edge in competitive procurements.
Some agencies are already listing SBOM delivery as a requirement in Statements of Work. Others are incorporating it into their risk-based acquisition decisions. Being ahead of this curve matters.
How Safeguard.sh Helps
Safeguard.sh gives government contractors a turnkey SBOM compliance platform. The tooling integrates into your CI/CD pipeline to automatically generate SBOMs in both SPDX and CycloneDX formats for every build. Generated SBOMs are stored in a centralized repository where they can be retrieved by product and version when agencies make requests.
The platform provides continuous vulnerability monitoring against NVD and other databases, alerting your security team when newly disclosed vulnerabilities affect components in your delivered software. For self-attestation, Safeguard.sh generates the documentation and evidence trails that demonstrate your compliance with NIST SSDF practices.
Government contractors using Safeguard.sh can move from zero SBOM capability to full compliance readiness in weeks, not the months-long implementation timeline that building this in-house requires.