The NIST Secure Software Development Framework (SSDF), published as Special Publication 800-218, is a set of high-level, outcome-focused practices for building software securely across the development lifecycle. It does not prescribe specific tools; it describes what secure development looks like — preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities — and maps those outcomes to existing standards. Its practical weight comes from Executive Order 14028 and the OMB memos that require software producers to attest to SSDF conformance before selling to US federal agencies. This FAQ answers the questions producers ask most, and notes Safeguard's own posture honestly: our platform is architected for FedRAMP HIGH and DoD Impact Level deployment, and our SOC 2 Type II audit is in progress.
Frequently Asked Questions
What is the NIST SSDF? The SSDF is NIST's Secure Software Development Framework, documented in SP 800-218, which defines a core set of secure development practices that any organization can adopt regardless of language, platform, or methodology. It is deliberately technology-agnostic and outcome-oriented, describing goals rather than mandating specific products. It has become the reference framework for US federal software procurement expectations.
What are the four SSDF practice groups? The SSDF organizes its practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). PO covers people, process, and tooling readiness; PS covers protecting code and releases from tampering; PW covers designing, writing, and verifying secure code; and RV covers identifying and remediating vulnerabilities after release. Each practice breaks into tasks with notional implementation examples and references to other standards.
Is the SSDF mandatory? The framework itself is voluntary, but conformance is effectively required to sell software to the US federal government. Under the relevant OMB guidance, agencies must obtain a self-attestation of SSDF conformance from software producers before using their software. So while no law forces you to adopt the SSDF, the federal market does.
What is the CISA Secure Software Development Attestation Form? It is the standardized common form, released by CISA in 2024, on which a software producer attests that it follows specified SSDF practices for the software it sells to federal agencies. The form distills the SSDF into a defined set of attestable statements about secure development, build integrity, provenance, and vulnerability handling. Producers submit it to the agency or through CISA's central repository for attestations.
Who signs the attestation? The attestation must be signed by the software producer's chief executive officer or a designated employee with the authority to bind the company. This deliberately places accountability at the executive level, because a false attestation can carry legal consequences under federal false-claims exposure. It is not a form for an engineer to sign quietly; it is a corporate commitment.
What happens if we cannot fully attest? If you cannot attest to every element, you may submit a plan of action and milestones documenting the gaps and your remediation timeline, and the agency may accept the software while you close them. Alternatively, a producer can back its attestation with an assessment by a FedRAMP-recognized third-party assessment organization. The key is that unresolved gaps must be documented and managed, not ignored.
Does the SSDF require an SBOM? The SSDF does not name a software bill of materials as a hard requirement, but practices under PW and PS on tracking components and provenance map directly to SBOM generation, and the surrounding federal guidance increasingly expects one. An SBOM is one of the cleanest ways to evidence that you know what is in your software. Safeguard's SBOM Studio produces version-controlled, machine-readable SBOMs so the component-inventory practices are continuously satisfied.
How does the SSDF relate to EO 14028? Executive Order 14028 on improving the nation's cybersecurity directed NIST to develop secure software development guidance, which became the SSDF, and directed OMB to require agencies to obtain conformance attestations. The chain is EO 14028 to the SSDF to the OMB memos to the CISA attestation form. Understanding that lineage explains why a voluntary framework has procurement-level teeth.
What is SP 800-218A? SP 800-218A is a community profile that augments the SSDF with practices specific to generative AI and dual-use foundation models, addressing risks in training data, model provenance, and AI-specific supply chains. It layers onto the core SSDF rather than replacing it. If you develop or heavily integrate AI models, it is the companion document to read alongside SP 800-218.
How does the SSDF map to other frameworks? The SSDF was designed as a unifying layer and includes references from each practice to established sources such as OWASP SAMM, BSIMM, ISO/IEC 27034, and various NIST publications. This means evidence you already produce for those frameworks generally supports SSDF conformance too. You are usually mapping existing work, not starting from zero.
What evidence backs an SSDF attestation? Auditors and program reviewers look for demonstrable practice: automated testing results, dependency and vulnerability scan records, secure build and provenance data, and vulnerability-response timelines. The recurring weakness is the RV group — showing that vulnerabilities are actually found and fixed on a schedule. Safeguard's software composition analysis generates the continuous, dated vulnerability and remediation evidence that the Respond to Vulnerabilities practices depend on.
How does the SSDF relate to provenance and SLSA? The Protect the Software practices call for safeguarding build integrity and archiving provenance, which aligns closely with SLSA (Supply-chain Levels for Software Artifacts) and signed attestations. Producing signed provenance and verifiable build data is how you evidence PS.3 and related tasks. Policy gates that block unsigned or unverified artifacts turn these practices into enforced controls rather than aspirations.
How does Safeguard help with SSDF conformance? Safeguard maps continuous scanning, SBOMs, and policy gates to SSDF practice groups so the attestable statements are backed by exportable evidence rather than assertions. The Griffin AI detection engine applies consistent secure-development checks to every change, and the compliance workspace organizes findings and remediation history into the evidence an attestation reviewer would expect.
To go further, compare Safeguard against other tools on the comparison page, and read the full product documentation at docs.safeguard.sh.