Procurement offices have always been where ambition meets paperwork. A cybersecurity executive order can promise to transform how the federal government buys software, but until those ideas find their way into a Federal Acquisition Regulation clause and a line in a Statement of Work, nothing actually changes at the agency buying desk. What has happened over the last three years, though, is that a lot of those lines have been written. Software vendors selling into federal, state, or local government now face a genuinely different procurement environment, and the changes extend well beyond the well-publicized headline of Executive Order 14028.
The Federal Baseline
Executive Order 14028, issued in May 2021, set the frame. It directed the National Institute of Standards and Technology to publish guidance on secure software development, which became NIST Special Publication 800-218, the Secure Software Development Framework. OMB Memorandum M-22-18 then required federal agencies to obtain self-attestations from software producers confirming conformance with SSDF practices before using their software. M-23-16 extended the timelines and clarified the scope, and CISA published a common self-attestation form that vendors can submit through a central repository.
This is not a small administrative lift. The attestation requires the vendor's CEO or a designated senior executive to sign a statement about the company's secure development practices, including build environment protections, provenance of components, and vulnerability disclosure. The attestation becomes a contractual representation, and false statements carry potential False Claims Act exposure. Vendors that were accustomed to shipping software into government agencies through resellers and catalog buys have suddenly had to build the internal processes needed to support those attestations.
Where FAR Comes In
The FAR Council has been working on a new clause for cybersecurity standards, and the proposed rule published in late 2023 signaled the direction: SBOM requirements, incident reporting obligations, and access-to-systems provisions for government assessors. The final rule has been slow in coming, but many agencies have already moved the underlying requirements into Defense Federal Acquisition Regulation Supplement clauses and agency-specific supplements. The General Services Administration has pushed SBOM language into its Multiple Award Schedule contracts, and the Department of Veterans Affairs has its own supply chain risk management requirements through VAAR.
Beyond the horizontal rules, agency-specific frameworks compound the picture. The Department of Homeland Security runs CISA and carries its own requirements through HSAR. The intelligence community applies the Committee on National Security Systems policies, which have stricter supply chain expectations than civilian agencies. The Department of Energy operates under its own cybersecurity capability maturity model variants for supplier assessments in the national laboratory system. A vendor selling to multiple agencies must navigate all of these in parallel.
State and Local Governments Move at Their Own Pace
Public-sector procurement is not just federal. States and municipalities purchase large volumes of software, often through multi-state cooperatives like NASPO ValuePoint. Several states have passed or are considering legislation that mirrors parts of EO 14028. New York's Department of Financial Services 23 NYCRR Part 500 has long covered financial services supervision but is increasingly treated as a template for other state procurement authorities. California's AB 2273 and the California Privacy Rights Act have separate software implications. Texas DIR has published its own supply chain guidance for state agencies.
At the municipal level, cities have become sensitive to software supply chain risk after several high-profile ransomware events. Atlanta, Baltimore, and more recently smaller cities across the Midwest have all experienced disruptive incidents linked in some way to vendor software. Procurement officers in those cities have started asking suppliers for SBOMs, vulnerability disclosure policies, and evidence of secure development lifecycle practices. The requests are inconsistent in format, which is a pain point for vendors trying to respond at scale, but the direction is unmistakable.
The FedRAMP Dimension
FedRAMP has always been a major gating factor for cloud service providers selling into federal agencies. The FedRAMP PMO has been tightening expectations around software supply chain controls within the baselines, in particular the SR control family from NIST SP 800-53 Revision 5. Authorized providers are now expected to maintain an up-to-date SBOM for their service, to track and disclose vulnerabilities in third-party components, and to support the agency authorizing official's ability to make risk decisions based on that information.
The FedRAMP 20x initiative announced by GSA in 2024 is aimed at reducing the time and cost of authorization, but it brings with it higher automation expectations. Providers that want to take advantage of the faster path need to demonstrate continuous monitoring, machine-readable compliance artifacts, and an ability to evidence SSDF practices with minimal manual effort. For smaller SaaS vendors, this is a daunting runway to build. For larger ones, it is an opportunity to widen their moat against competitors who cannot meet the bar.
The Attestation Itself
The CISA common self-attestation form is short on its face, but the operational work behind it is substantial. The form asks the vendor to attest to four domains: secure software development environments, provenance of software components, vulnerability disclosure, and automation of security checks. Each of those maps to multiple SSDF practices. To sign the form credibly, a vendor needs evidence: build logs, signed artifacts, SCA scan results, dependency inventories, vulnerability disclosure policies, and documentation of the secure development environment.
Agencies are not supposed to require the evidence with every attestation, but they can request it, and increasingly do during procurement due diligence. Several agencies have been clear that they will ask for an SBOM and will ask to see SBOM-related policies. A vendor that cannot produce an SBOM for its own product in both SPDX and CycloneDX formats within a reasonable window will struggle to complete procurement even if the attestation was signed.
What Procurement Teams Want to See
Speak to a federal contracting officer or a state CIO and the wishlist is consistent. They want a vendor that can produce machine-readable SBOMs on demand, articulate a vulnerability disclosure and response policy, provide evidence of secure build environments, share audit artifacts from a third-party assessor when requested, and respond rapidly to zero-day disclosures in their software stack. They want all of this without six rounds of legal redaction. The vendors that have invested in internal platforms to generate these artifacts automatically have dramatically shorter sales cycles in the public sector than vendors that treat each request as a bespoke fire drill.
The other thing procurement teams want is transparency about subcontractors and open source components. OMB Memorandum M-22-18 makes clear that the self-attestation covers the vendor's own development practices but also the third-party components in the product. A vendor that depends heavily on open source, as almost every modern software company does, needs to be able to speak confidently about how those components are selected, updated, and monitored for vulnerabilities.
The Quiet Pressure of CISA's SSCRM
CISA has been publishing guidance and templates on software supply chain risk management that, while not strictly regulatory, act as strong signals. The Secure by Design initiative, the Secure Software Attestation Common Form, and the ongoing work on SBOM tooling all shape what agencies come to expect. Vendors that align their internal practices with this guidance find themselves naturally well-positioned for the procurement questions that follow.
How Safeguard Helps
Safeguard was built with public-sector procurement in mind. We generate SBOMs in SPDX and CycloneDX formats from your repositories, builds, and containers, and we produce the evidence artifacts that underpin an SSDF self-attestation. Our compliance reports map findings directly to SSDF practices, NIST SP 800-53 controls, and FedRAMP baseline requirements, so you can respond to agency requests in hours instead of weeks. When a procurement office asks for proof of secure build environments, dependency provenance, or vulnerability response cadence, Safeguard produces defensible documentation from live data rather than static attestations. The result is a shorter procurement cycle and fewer post-award surprises.