If you sell software to the U.S. federal government — or you're a vendor two tiers down a prime contractor's supply chain — you've probably heard the acronym soup by now: EO 14028, NIST SP 800-218, OMB M-22-18, and the CISA Secure Software Development Attestation Form. Strip away the jargon and it comes down to one requirement: before an agency can use your software, you (or your CEO) must sign a federal form attesting that you built it using the practices in NIST's Secure Software Development Framework (SSDF). That form asks about isolated build environments, provenance tracking for first-party and third-party code, automated vulnerability tooling, and a documented vulnerability disclosure process — and false attestations carry False Claims Act exposure. Competitors like Anchore have built SBOM and scanning tools that touch pieces of this, but attestation is a documentation and evidence problem as much as a scanning problem. Here's what the requirement actually says, when it applies, and what "covering it" really requires.
What is NIST SP 800-218 (SSDF), and why is it suddenly a procurement requirement?
NIST SP 800-218 is a catalog of 42 secure development practices — not a law by itself, but it became a procurement gate the moment OMB tied it to federal software purchasing. NIST published the Secure Software Development Framework (SSDF) Version 1.1 in February 2022, in response to Executive Order 14028 (May 2021), which followed the SolarWinds and Log4j incidents and directed NIST to define what "secure software development" actually means in practice. The SSDF organizes its 42 practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). By itself, SSDF was voluntary guidance. It became mandatory for a huge swath of the software market when OMB Memorandum M-22-18, issued September 14, 2022, required every federal agency to collect a signed attestation from software producers confirming their development practices conform to SSDF — before that software can be used on government systems. That single memo turned a 40-page NIST document into a sales-blocking compliance checkpoint for anyone selling to, or subcontracting into, the federal government.
What exactly does the CISA attestation form require you to certify?
The CISA Secure Software Development Attestation Form requires you to certify four specific claims, not a general promise of "good security." CISA released the form in March 2023 and finalized it in June 2023 after OMB M-23-16 amended the original memo. Signed by a company officer (CEO or designee — not a compliance manager), the form attests that: (1) the software was developed in a separate build environment isolated from unauthorized access; (2) the producer employs automated tools or processes to check for and remediate vulnerabilities, generating a "trusted source" for provenance data; (3) the producer maintains an accurate, up-to-date inventory of first-party and third-party components — in practice, this means SBOM-grade data on your open-source dependencies; and (4) the producer maintains a vulnerability disclosure program that accepts, triages, and discloses vulnerabilities in a timely manner. Each claim maps back to specific SSDF practices (PO.5, PS.1, PS.3, PW.4, PW.7, PW.8, RV.1, RV.2 among them), which means an attestation isn't a legal formality — it's a claim that your CI/CD pipeline, your dependency management, and your incident response process all actually do these things, continuously, not just on the day you signed.
When do agencies need your attestation on file — and what happens if you miss the deadline?
Agencies are required to collect attestations before using new or renewed "critical software," and the practical trigger is any new procurement, renewal, or major version update after the rule took effect. M-22-18 originally set a three-month clock for critical software and six months for all other software after CISA published its form; M-23-16 later adjusted those windows and clarified that self-attestation is required regardless of deployment model — on-prem, SaaS, or cloud-hosted. Missing the deadline doesn't just mean a delayed sale: agencies are directed to stop using non-compliant software, and if it later comes out that an executive signed an attestation the company couldn't actually back up, that's a potential False Claims Act violation — the same statute that's produced multi-million dollar settlements in cybersecurity cases (Verizon's $4M settlement and Aerojet Rocketdyne's $9M settlement over misrepresented security controls are the cautionary tales procurement and legal teams now cite). For a mid-size ISV, that turns a one-page form into something legal, engineering, and the CEO's office all need to review before signature — every time you renew.
Is self-attestation enough, or do you need a third-party SSDF assessment?
Self-attestation is the default and covers the vast majority of vendors, but a subset of "critical software" can be required to undergo third-party assessment instead. Under M-23-16, agencies retain discretion to require an assessment from a FedRAMP-authorized third-party assessment organization (3PAO) or an agency-approved assessor when the software poses elevated risk — think identity and access management systems, or software with direct control over other software's execution (the same "critical software" category EO 14028 defined narrowly at the outset). For everyone else, self-attestation is legally sufficient, but "sufficient" doesn't mean "unsupported" — CISA and agency CIOs have signaled they can request supporting artifacts (SBOMs, vulnerability disclosure policy documentation, build pipeline evidence) after the fact, and several agencies have started asking for this evidence bundle proactively during vendor risk reviews rather than waiting for an audit trigger. In practice, most vendors that plan to self-attest still need to assemble the same evidence a 3PAO would ask for — they just don't submit it upfront.
How does Anchore handle SSDF attestation, and where does that approach break down?
Anchore approaches SSDF primarily as an SBOM and vulnerability-scanning problem, which covers one of the four attestation claims well and leaves the other three as manual work. Anchore's tooling (Syft for SBOM generation, Grype for vulnerability scanning, Anchore Enterprise for policy gates) is genuinely strong at producing component inventories — that maps cleanly to the SSDF's third-party component tracking requirement. But the attestation form asks for four distinct things, and Anchore's published guidance on SSDF compliance largely stops at "here's how to generate an SBOM" and "here's how to scan for CVEs." Isolated build environment attestation, vulnerability disclosure program documentation, and continuous evidence that automated remediation tooling is actually running in production pipelines are left to the customer to assemble — often in spreadsheets, screenshots, and Confluence pages stitched together right before a renewal deadline. Anchore also doesn't map its scan output back to specific SSDF practice IDs or generate attestation-ready evidence packages, so security teams end up doing the SSDF-to-tool mapping by hand, re-doing it every audit cycle, and hoping the CEO's signature holds up if a customer's procurement office ever asks for backup documentation.
How Safeguard Helps
Safeguard treats SSDF attestation as a continuous evidence problem, not a once-a-year form-filling exercise. Instead of asking your team to manually map scan results to SSDF practice IDs, Safeguard continuously ingests signals from your build pipeline, dependency graph, and vulnerability management workflow, and maps them directly to the specific PO/PS/PW/RV controls the CISA form references — so when your CEO is asked to sign, there's a live evidence trail behind every one of the four claims, not a best-effort reconstruction. Safeguard generates and maintains SBOMs alongside build provenance attestations (in-toto and SLSA-aligned) automatically on every release, closing the gap between "we generated an SBOM once" and "we can prove build isolation and component tracking on this specific artifact you're procuring today." For the vulnerability disclosure and remediation claims, Safeguard tracks disclosure timelines and remediation SLAs against the same dataset used for attestation, so there's one source of truth instead of a scanning tool plus a separate VDP tracker plus a spreadsheet. And because attestations recur with every renewal and major release, Safeguard keeps evidence current continuously rather than requiring a scramble before each deadline — so the next attestation is a five-minute review of already-current evidence, not a two-week fire drill across engineering, legal, and the executive team.