As 2023 draws to a close, software vendors selling to the U.S. federal government face increasingly concrete requirements around Software Bills of Materials. What started as an aspirational goal in Executive Order 14028 (May 2021) has evolved into specific compliance requirements with real deadlines and real consequences.
The Regulatory Timeline
Executive Order 14028 (May 2021)
The foundational document. EO 14028 directed NIST to develop SBOM guidelines and instructed federal agencies to require SBOMs from software suppliers. It didn't specify exact requirements but set the direction.
NIST SSDF (February 2022)
NIST published the Secure Software Development Framework (SSDF), SP 800-218, which became the reference standard for secure development practices that federal agencies require from suppliers. SSDF includes SBOM generation as part of secure development.
OMB Memorandum M-22-18 (September 2022)
OMB M-22-18 put teeth behind EO 14028. It required that software vendors:
- Self-attest that they follow secure development practices consistent with NIST SSDF
- Provide this attestation before their software can be used by federal agencies
- Be prepared to provide SBOMs and other artifacts upon request
The memo established a phased timeline:
- Critical software (as defined by CISA): Requirements effective within 9 months
- All other software: Requirements effective within 12 months
OMB Memorandum M-23-16 (June 2023)
M-23-16 updated the timeline and provided additional guidance, extending some deadlines and clarifying the self-attestation form. The updated deadlines pushed compliance into late 2023 and early 2024.
CISA Secure Software Development Attestation Form (2023)
CISA developed the standard attestation form that vendors must complete. The form requires the vendor's CEO or authorized representative to attest that the company:
- Maintains a secure software development environment
- Employs automated tools for vulnerability scanning
- Maintains provenance data for software components
- Provides an SBOM for the software (or can provide one upon request)
What Vendors Actually Need to Do
1. Self-Attestation
Every vendor selling software to federal agencies must complete CISA's self-attestation form. This is the minimum requirement and it's non-negotiable.
The attestation covers:
- Secure development environment (separate build environments, MFA, logging)
- Automated scanning (SAST, SCA, container scanning)
- Provenance tracking (knowing where your components come from)
- Vulnerability management (process for responding to and remediating vulnerabilities)
- SBOM capability (ability to generate and provide SBOMs)
Signing the attestation carries legal weight. False attestation to a federal agency has consequences. Vendors should treat this as a compliance commitment, not a checkbox exercise.
2. SBOM Generation Capability
The current requirements don't mandate that vendors proactively deliver SBOMs with every software shipment. Instead, vendors must be able to produce SBOMs when requested. However, the trend is clearly toward proactive SBOM delivery, and forward-thinking vendors are already including SBOMs with their releases.
SBOMs should:
- Follow NTIA's minimum elements for SBOMs (supplier name, component name, version, dependency relationships, unique identifiers, timestamp)
- Be in a machine-readable format (SPDX or CycloneDX)
- Cover all components, including open-source dependencies
- Be generated as part of the build process, not manually created
3. Vulnerability Response Process
Vendors must demonstrate that they have a process for:
- Monitoring for vulnerabilities in their software components
- Responding to newly disclosed vulnerabilities in a timely manner
- Communicating vulnerability information to customers
- Providing patches or mitigations
This goes beyond having a vulnerability scanner—it requires an operational process with defined SLAs and communication channels.
4. Third-Party Assessment (for Critical Software)
For software designated as "critical" by CISA, agencies may require third-party assessment rather than self-attestation. This means an independent assessor verifies the vendor's secure development practices, similar to a SOC 2 or FedRAMP assessment.
Practical Challenges
Defining "Software"
OMB's guidance applies to software "used by federal agencies," but the definition of what constitutes "software" in this context has been subject to interpretation. Does it include:
- SaaS products? (Generally yes, with some nuance)
- Open-source software used by agencies? (Complex—who attests for open-source?)
- Embedded software in hardware products? (Generally yes)
- Firmware? (Increasingly yes)
The Open-Source Gap
Much of the software used by federal agencies is open source. Open-source maintainers generally can't (and won't) complete federal attestation forms. This puts the burden on vendors who package, distribute, or support open-source software for federal customers.
Supply Chain Depth
The attestation requires knowledge of your software's components, but many vendors don't have complete visibility into their transitive dependency tree. A vendor might confidently attest to their own code while unknowingly including a vulnerable or malicious transitive dependency.
Small Vendor Burden
The compliance requirements, while reasonable for large enterprises, can be burdensome for small software companies. Implementing SBOM generation, vulnerability scanning, and secure development practices requires investment that small vendors may struggle to make.
The Enforcement Question
As of late 2023, enforcement remains the open question. Federal agencies are responsible for ensuring their suppliers comply, but:
- Many agencies are still building the capability to consume and analyze SBOMs
- The attestation collection process is being standardized but isn't fully operational
- Consequences for non-compliance are not yet well-defined
However, the direction is clear. Vendors who delay compliance will eventually face procurement barriers. Smart vendors are treating the current period as preparation time, not a grace period.
How Safeguard.sh Helps
Safeguard.sh provides the technical foundation for federal SBOM compliance. Our platform generates SBOMs in SPDX and CycloneDX formats, maintains continuous vulnerability monitoring across your component inventory, and produces the documentation needed for self-attestation and third-party assessment. For vendors navigating the federal compliance landscape, Safeguard.sh streamlines the process from SBOM generation to attestation preparation, ensuring you can meet agency requirements without building the entire capability from scratch.