In February 2022, NIST published Special Publication 800-218, formalizing the Secure Software Development Framework (SSDF) as the federal government's baseline for how vendors build software. Two years later, that guidance stopped being optional: under OMB Memorandum M-22-18, any company selling software to a U.S. federal agency must attest, through a CISA-hosted form, that its development practices satisfy SSDF requirements. For a company like Aqua Security — built primarily around runtime container and cloud workload protection — SSDF attestation exposes a structural gap. The framework asks how software is built, tested, and shipped, not just how a container behaves once it's running in production. This post breaks down what SSDF actually requires, why the attestation mandate changed the compliance calculus for every software vendor, how CNAPP-first tools like Aqua map (or don't) to it, and where Safeguard fits into closing that gap.
What Is the NIST SSDF, and Why Does It Matter for "SSDF NIST" Compliance in 2026?
The NIST SSDF is Special Publication 800-218, a catalog of secure development practices organized into four groups: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV) — 19 practices broken into 42 individual tasks. NIST released it in February 2022 in direct response to Executive Order 14028, signed May 12, 2021, after the SolarWinds compromise exposed how little visibility the federal government had into vendor build pipelines. In February 2024, NIST followed up with SP 800-218A, adding SSDF profile guidance for generative AI and dual-use foundation models. What makes SSDF different from a typical security checklist is that it's practice-based, not tool-based: it tells you what outcome to achieve (e.g., "maintain provenance data for internal and third-party code") without prescribing which scanner or platform produces it. That flexibility is also why searches for "ssdf nist" spike every time a new attestation deadline or procurement clause lands — vendors need to translate abstract practices into concrete, auditable evidence.
What Does SSDF Actually Require a Software Producer to Do?
SSDF requires producers to generate specific artifacts at specific points in the SDLC, not just run periodic scans. Under PS.3.1, producers must archive and provide provenance data for each software release, including the origin of first-party and third-party components. Under PW.4.1, producers must verify that acquired components come from a vetted, well-maintained source and track them well enough to respond when one is compromised — the practical implementation of this is a maintained SBOM (Software Bill of Materials) in a machine-readable format like CycloneDX or SPDX. Under PW.7.1 and PW.7.2, producers must review human-written and machine-generated code for security defects before release, using techniques such as static analysis. Under RV.1.1–RV.1.3, producers must identify and confirm vulnerabilities on an ongoing basis and remediate them within a documented, risk-based timeframe. Each of these tasks needs to produce a retained record — a signed attestation, a build log, an SBOM diff — because the entire framework is designed to be auditable after the fact, not just followed in spirit.
Why Did SSDF Attestation Become Mandatory for Federal Software Vendors?
SSDF attestation became mandatory because OMB Memorandum M-22-18, issued September 14, 2022, and clarified by M-23-16 in June 2023, directs federal agencies to collect a signed self-attestation from any software producer whose product touches an agency system — no attestation, no procurement. CISA finalized the "Secure Software Development Attestation Form" in March 2024, and it applies retroactively to software developed or modified after September 14, 2022. The form requires either a self-attestation signed by a company's CEO or COO (not delegable to a security team) or, for higher-assurance cases, a third-party assessment. Agencies must retain the completed attestation for as long as the software is in use plus three years afterward. This is the mechanism that turned SSDF from "recommended practice" into a hard gate: a vendor can have excellent runtime security posture and still fail procurement if it can't produce the build-time evidence the attestation form asks for — provenance records, vulnerability disclosure processes, and vetted-component tracking among them.
How Does Aqua Security's Platform Map to SSDF's Requirements?
Aqua Security maps to a meaningful slice of SSDF, but its core architecture — a CNAPP (Cloud Native Application Protection Platform) built around the open-source Trivy scanner, container image scanning, and Kubernetes runtime protection — was designed to catch vulnerabilities and misconfigurations in deployed and deploying workloads, not to produce the build-time attestation record SSDF asks for. Aqua's own SSDF-related content frames the framework largely as a vulnerability-scanning checklist: scan the image, flag the CVE, block the deploy. That covers parts of PW.4 (identifying known vulnerabilities in components) reasonably well. It does far less for PS.3 (provenance data tied to a specific release), PO.1–PO.5 (organizational policy and role definitions the attestation form's CEO/COO signature depends on), and RV.1's requirement for a documented, ongoing disclosure and remediation process across the full software lifecycle rather than the runtime slice. A tool that scans a finished container image after it's built can tell you what's inside the box; it can't tell a federal contracting officer how the box was assembled, by whom, or from what verified sources.
Where Do CNAPP-Style Tools Fall Short on the Build-Time Half of SSDF?
CNAPP tools fall short because roughly a third of SSDF's 42 tasks — most of the PW group and all of PS — concern controls that only exist inside the CI/CD pipeline, not the runtime environment a CNAPP is built to watch. Generating SLSA-style signed provenance, producing a reproducible build record, enforcing that every dependency resolves to a source with a known SBOM, and gating a release when a component fails a policy check all have to happen at build time, before an artifact ever reaches a registry or cluster. A scanner bolted onto the end of that pipeline can flag a vulnerable package after the fact, but it can't attest to how the artifact was produced, and it can't stop a build from shipping in the first place — it can only alert once the image already exists. For an audit against CISA's attestation form, the difference matters: "we scanned it and found nothing critical" and "here is the signed provenance chain, SBOM, and code review record for this exact build" are not the same answer, and only the second satisfies what SSDF's PS and PW practices are actually asking for.
How Safeguard Helps
Safeguard is built around the assumption that SSDF compliance has to be produced where the software is actually built, not bolted on afterward as a scan. Safeguard generates SLSA-aligned, cryptographically signed provenance for every build, automatically producing the artifact-level evidence PS.3.1 requires without engineering teams manually assembling it before an audit. It generates and maintains SBOMs in CycloneDX and SPDX formats continuously as dependencies change, satisfying PW.4.1's requirement to track and vet third-party components rather than snapshotting them once a quarter. Safeguard signs build artifacts with Sigstore-compatible signing so that provenance can be independently verified downstream, and it enforces policy gates directly in the CI/CD pipeline so a release with an unvetted component or a failed code review check is blocked before it ships, rather than flagged after deployment — directly addressing the gap CNAPP-only tooling leaves at PW.7 and PS.3. For RV.1's ongoing vulnerability response requirement, Safeguard tracks time-to-remediation against a documented SLA and keeps the historical record auditors and CISA's attestation form both expect to see. Perhaps most practically, Safeguard maps its evidence output directly onto CISA's Secure Software Development Attestation Form fields, so a compliance or legal team preparing a CEO/COO signature isn't reverse-engineering scan reports into attestation language — the evidence is already organized by the SSDF task it satisfies. That's the difference between a platform that secures software after it's built and one that proves, with evidence, how it was built in the first place.