Federal software procurement has changed fundamentally in the past two years. What used to be a checkbox exercise — submit a security questionnaire, get a contract — is now a technical compliance challenge that requires real infrastructure, real processes, and real investment.
If your company sells software to federal agencies, this playbook covers what you need to know and do.
The Regulatory Stack
Federal software procurement security requirements come from multiple overlapping sources:
Executive Order 14028 established the policy direction: software vendors must attest to secure development practices and provide SBOMs.
OMB M-22-18 and M-23-16 translated the EO into specific requirements for federal agencies, including the self-attestation form that vendors must complete.
NIST SP 800-218 (SSDF) defines the secure software development practices that vendors attest to.
CISA SBOM Minimum Elements specifies what an SBOM must contain to satisfy federal requirements.
Agency-specific guidance adds additional requirements. DoD has its own SBOM requirements. DHS has its own. Each civilian agency may have supplementary expectations.
The practical implication: compliance is not a single standard. It is a stack of overlapping requirements that you need to satisfy simultaneously.
The Attestation Requirement
The most immediate requirement is the secure software development attestation form. This form requires the CEO, COO, or equivalent executive to attest that the company follows SSDF practices.
The attestation covers:
- Development environment security — separation of build environments, access controls, audit logging
- Source code provenance — maintaining a provenance record for all source code, including open-source components
- Vulnerability management — operating a vulnerability disclosure program, monitoring for known vulnerabilities, and patching within defined timeframes
- SBOM production — generating and maintaining SBOMs for delivered software
- Build integrity — employing automated tools to maintain trusted source code supply chains
This is not a technical controls assessment. It is a management assertion that carries legal weight. If the attestation is false, the False Claims Act applies.
For most mature software companies, the practices described in the attestation are things they already do. The gap is typically in documentation and evidence collection, not in the practices themselves. You might already separate your build environments, but can you demonstrate it to an auditor?
The SBOM Requirement
Federal SBOM requirements have moved from "recommended" to "required" for new contracts. The specifics:
Format: CycloneDX 1.5+ or SPDX 2.3+. Earlier versions may not include all required fields.
Minimum fields per component:
- Supplier name
- Component name
- Version string
- Unique identifier (PURL recommended, CPE accepted)
- Dependency relationship
- Author of SBOM data
- Timestamp
Delivery: SBOMs must be delivered with the software or made available through a discoverable mechanism. Some agencies accept a URL; others require direct inclusion with the deliverable.
Update cadence: SBOMs must be updated with each software release. For SaaS products, the expectation is that SBOMs are updated on a regular cadence aligned with the release cycle.
Vulnerability information: While not strictly required in the SBOM itself, agencies increasingly expect accompanying vulnerability analysis — a list of known CVEs affecting SBOM components, with risk assessments and mitigation plans.
The Procurement Timeline
Understanding when these requirements apply:
New contracts (effective now): All new software procurement contracts should include SBOM and attestation requirements. In practice, adoption varies by agency and contracting officer.
Contract renewals and option exercises (rolling): Existing contracts are expected to incorporate these requirements at renewal or option exercise.
Existing contracts without modification (gray area): The legal mechanism for requiring SBOMs from vendors under existing, unmodified contracts is unclear. Most agencies are handling this through negotiation rather than enforcement.
Subcontracts: Prime contractors are increasingly flowing SBOM requirements down to subcontractors. If you supply software to a prime contractor that sells to the government, expect to receive SBOM requirements.
Building the Infrastructure
Here is what a vendor needs to build to comply:
Automated SBOM Generation
Integrate SBOM generation into every CI/CD pipeline. Every build should produce an SBOM as a first-class artifact, stored alongside the software deliverable.
Key considerations:
- Support both CycloneDX and SPDX to satisfy different agency preferences
- Include transitive dependencies, not just direct ones
- Validate SBOM output against CISA minimum elements before delivery
- Include hash values for all components for integrity verification
Vulnerability Monitoring
Implement continuous monitoring of SBOM components against vulnerability databases. When a new CVE affects a component in your SBOM:
- Assess the impact on your product
- Determine the remediation plan
- Communicate to affected customers within your defined timeline
- Update the SBOM when the remediation ships
Evidence Collection
The attestation requires you to demonstrate your security practices, not just claim them. Build evidence collection into your development workflow:
- Audit logs for build environment access
- Code review records for all changes
- Vulnerability scan results
- SBOM generation and validation records
- Incident response logs
- Training records for development staff
Customer Communication
Federal customers expect proactive communication about security issues. Build a notification workflow:
- Vulnerability advisories when new CVEs affect your product
- Updated SBOMs with each release
- Patch availability notices
- End-of-support and end-of-life timelines
Common Mistakes
Generating SBOMs only when asked. SBOMs should be produced automatically on every build, not generated ad hoc when a customer requests one. Ad hoc generation is error-prone and does not scale.
Treating attestation as a one-time exercise. The attestation covers ongoing practices. If your security practices degrade after the initial attestation, you are in violation.
Ignoring subcontractor SBOMs. If your product includes components from subcontractors, those components need to be in your SBOM. Build a process for collecting and integrating subcontractor SBOMs.
Underinvesting in SBOM quality. An SBOM with missing fields, incorrect versions, or incomplete dependency trees is worse than no SBOM — it creates a false sense of transparency and exposes you to attestation liability.
How Safeguard.sh Helps
Safeguard provides the complete infrastructure for federal SBOM compliance. Automated SBOM generation in CI/CD pipelines, validation against CISA minimum elements, continuous vulnerability monitoring, customer notification workflows, and evidence collection for attestation support. For vendors navigating the federal procurement landscape, Safeguard takes you from requirements to compliance with minimal engineering overhead. Our platform handles the SBOM lifecycle so your team can focus on building the software your customers need.