NIST SSDF SP 800-218 for Software Vendors

The NIST SSDF (Secure Software Development Framework, NIST SP 800-218) is the most widely referenced description of what secure software development should include. It is short, technology-neutral and written as outcomes, not tools: protect your code and builds, design and test for security, and respond properly when vulnerabilities are found. It became prominent in 2022 when US federal policy required software suppliers to attest to SSDF practices.

In January 2026, OMB memo M-26-05 rescinded the government-wide attestation requirement, leaving each agency to decide what assurance to ask for. The framework itself remains current and widely used, and it maps closely to secure development duties in the EU Cyber Resilience Act and to customer security reviews. This guide explains the four practice groups, what each means in a real development team, the attestation form, and how to adopt the SSDF without slowing delivery.

What is the NIST SSDF?

SP 800-218 describes a core set of high-level secure software development practices that can be integrated into any software development life cycle, whether waterfall, agile or DevOps. Each practice has tasks, notional implementation examples and references to other frameworks such as BSIMM, OWASP SAMM, the OWASP ASVS, SAFECode and ISO standards. NIST deliberately avoids prescribing specific tools or methods.

The practices are organised into four groups:

Prepare the Organization (PO): people, processes and technology are ready for secure development.
Protect the Software (PS): all components are protected from tampering and unauthorised access.
Produce Well-Secured Software (PW): software is released with minimal security vulnerabilities.
Respond to Vulnerabilities (RV): residual vulnerabilities are identified and addressed, and future ones prevented.

SP 800-218A adds a community profile for producers of generative AI models and dual-use foundation models, covering practices such as protecting training data and model weights.

History and why the SSDF was introduced

NIST first published secure development practices as a white paper in 2020, drawing on established industry models. After high-profile software supply chain attacks, US Executive Order 14028 (May 2021) directed NIST to publish guidance on secure software development, and NIST released SP 800-218 version 1.1 in February 2022. OMB memoranda M-22-18 (September 2022) and M-23-16 then required federal agencies to obtain attestations from software producers that they followed SSDF-based practices, and CISA published a common Secure Software Development Attestation Form in 2024.

In January 2026, OMB memo M-26-05 rescinded M-22-18 and M-23-16. Agencies may still use the attestation form and other resources, but the decision is now risk-based and agency-specific. NIST's SSDF page continues to list version 1.1 as current.

Who uses the SSDF?

Software companies and SaaS providers selling to US government agencies, which may ask for attestation or evidence.
Enterprises writing secure development requirements into supplier contracts.
Outsourced development firms that need a recognised description of their process.
Manufacturers preparing for the EU Cyber Resilience Act, whose essential requirements overlap with SSDF practices.
Internal development teams setting their own standards.

It is voluntary and global in use.

The practices explained

PO: Prepare the Organization

PO.1 Define security requirements for software development, for infrastructure and processes and for the software itself, including requirements from laws, customers and policies.
PO.2 Implement roles and responsibilities, with training for each role.
PO.3 Implement supporting toolchains, with security tools integrated and configured.
PO.4 Define and use criteria for software security checks, such as release gates.
PO.5 Implement and maintain secure environments for development, build and test, separated and hardened.

PS: Protect the Software

PS.1 Protect all forms of code from unauthorised access and tampering, using least privilege, version control and signed commits where appropriate.
PS.2 Provide a mechanism for verifying software release integrity, such as cryptographic signatures and published hashes.
PS.3 Archive and protect each software release, including provenance data such as an SBOM, so that vulnerabilities can be analysed later.

PW: Produce Well-Secured Software

PW.1 Design software to meet security requirements and mitigate risks, using threat modelling and risk analysis.
PW.2 Review the design against requirements.
PW.4 Reuse existing, well-secured software rather than duplicating functionality, and manage third-party components.
PW.5 Create source code following secure coding practices.
PW.6 Configure compilation, interpreter and build processes to improve security.
PW.7 Review and analyse code using human review and automated analysis.
PW.8 Test executable code to find vulnerabilities, including dynamic testing and fuzzing where appropriate.
PW.9 Configure software to have secure settings by default.

RV: Respond to Vulnerabilities

RV.1 Identify and confirm vulnerabilities on an ongoing basis, including through a disclosure programme and monitoring of components.
RV.2 Assess, prioritise and remediate vulnerabilities, and publish advisories.
RV.3 Analyse vulnerabilities to identify their root causes, and fix classes of problems in the process.

A practical baseline for a small team

The SSDF can look heavy for a team of ten developers, but most practices map to a handful of concrete habits:

Practice	Small-team implementation	Evidence
PO.1, PO.4	A one-page secure development standard with release criteria	The standard, and pipeline gates that enforce it
PO.2	Annual secure coding training plus onboarding for new developers	Training records
PO.3, PO.5	SSO and MFA on code hosting and CI, separate staging and production accounts	Identity provider and cloud account settings
PS.1	Protected main branch, required review, no direct pushes	Repository settings and pull request history
PS.2, PS.3	Signed release artifacts, SBOM attached to each release	Release pages, signatures, stored SBOMs
PW.1, PW.2	A short threat-modelling checklist for features touching authentication, payments or personal data	Completed checklists linked to tickets
PW.4	Dependency policy: approved sources, update cadence, licence checks	Dependency scanner reports
PW.5, PW.7, PW.8	Coding standard, static analysis and secret scanning in CI, dynamic scan of staging	CI logs and scan reports
PW.9	Secure defaults review before each major release	Release checklist
RV.1 to RV.3	security.txt contact, vulnerability tracker with fix timelines, root cause note for serious issues	Tracker, advisories, root cause notes

None of this needs a dedicated security team. It needs owners, automation and the discipline to keep evidence, which is also what makes customer security reviews quick.

The Secure Software Development Attestation Form

CISA's common form asks a software producer's chief executive or designee to attest that the software was developed following secure practices drawn from the SSDF, in four areas: secure development environments; good-faith efforts to maintain trusted source code supply chains; maintaining provenance data for internal and third-party code; and employing automated tools or processes that check for security vulnerabilities. Since M-26-05, agencies may still request it, but it is no longer required government-wide. Producers selling to federal agencies should check each agency's and contract's requirements and be ready to provide either the attestation or equivalent evidence, such as an SBOM.

How to adopt the SSDF step by step

Assess your current life cycle against the practices and tasks, recording what exists and the evidence for it.
Set security requirements and release criteria (PO.1, PO.4): for example, no critical findings open at release, all dependencies scanned, code reviewed.
Secure the toolchain (PO.3, PO.5, PS.1): SSO and MFA for code hosting and CI, protected branches, least privilege, separate environments, secrets management.
Add automated checks (PW.7, PW.8): static analysis, dependency scanning, secret scanning, container and infrastructure-as-code scanning, dynamic testing.
Introduce lightweight threat modelling for new features (PW.1).
Sign releases and keep provenance (PS.2, PS.3): signatures, hashes, SBOMs and build records per release.
Review defaults (PW.9): secure configuration out of the box.
Run a vulnerability response process (RV): intake, triage, fix timelines, advisories and root cause analysis.
Train developers by role (PO.2).
Measure and improve, using a maturity model such as OWASP SAMM.

Using the SSDF with outsourced development

When development is outsourced, the SSDF applies across the relationship. The buyer should define security requirements and release criteria in the contract (PO.1, PO.4), require access controls and protected repositories it can see (PS.1), receive SBOMs and signed releases (PS.2, PS.3), and agree how vulnerabilities found after delivery are reported and fixed (RV). The development partner should show its secure coding standard, review and scanning evidence, and training records. Agreeing this at the start avoids disputes later about who owns a vulnerability found in production, and gives the buyer the evidence it needs for its own customers and auditors.

Documentation and evidence

Secure development policy and requirements.
Role definitions and training records.
Toolchain configuration: branch protection, CI security checks, access controls.
Threat models and design reviews for significant features.
Code review records and scan results with remediation.
Release signing procedures, SBOMs and provenance records.
Vulnerability disclosure policy, vulnerability tracker and advisories.
Root cause analyses for significant vulnerabilities.

Assessment and certification

There is no SSDF certification. Producers self-assess and, where agencies ask, sign the attestation form. Some customers request third-party assessments, and many accept evidence from ISO/IEC 27001 secure development controls, SOC 2 change management testing, penetration test reports and SBOMs.

Timeline and cost considerations

Teams with modern tooling often already meet many practices and need mainly to fill gaps and document. Larger changes are usually build integrity (signing and provenance), formal vulnerability response and threat modelling. Costs include security tooling, developer time for remediation and training, and process overhead, which automation keeps small.

Benefits and the risk of skipping it

SSDF practices reduce vulnerabilities reaching production, make supply chain attacks harder, speed up response when issues are found, and give a credible answer to customers and regulators. Without them, teams ship known-vulnerable components, cannot prove what is in a release, and handle vulnerability reports ad hoc, which is costly under laws such as the CRA that set reporting deadlines.

Common mistakes and challenges for IT companies

Tools without gates. Scanners that produce reports nobody acts on do not satisfy PO.4.
Unprotected build systems. CI runners with broad credentials and no isolation are a supply chain risk.
No provenance. Without SBOMs and build records, you cannot answer "are we affected?" quickly.
No public way to report vulnerabilities.
Fixing bugs without root cause analysis, so the same class recurs.
Attesting without evidence, which creates legal risk with government customers.

Best practices, tools and technologies

Protected branches, mandatory reviews and signed commits for critical repositories.
Ephemeral, isolated build runners with short-lived credentials.
SBOM generation and artifact signing in the pipeline, aligned with SLSA.
SAST, SCA, secret scanning and DAST with severity-based release gates.
A security.txt file and a published disclosure policy.
Developer training tied to the OWASP Top 10 and your stack.

These practices are part of how we deliver projects in custom software development and web application development.

How the SSDF relates to other frameworks

Framework	Relationship
OWASP SAMM	Maturity model for measuring and improving secure development; mapped in the SSDF.
OWASP ASVS	Testable application security requirements that support PW practices.
SBOM and SLSA	Provenance and build integrity practices supporting PS.3 and PS.2.
Cyber Resilience Act	EU law with essential requirements that overlap with SSDF practices.
NIST SP 800-53	SA and SR control families cover secure development and supply chain from the acquirer's side.

Real-world implementation examples

Many large software vendors published SSDF attestations or mapping documents for federal customers in 2024 and 2025, and CISA operated a repository for attestations. After M-26-05, vendors report that some agencies still request the form while others ask for SBOMs or their own questionnaires.

An illustrative case for a SaaS vendor: mapping its process to the SSDF shows strong PW practices but gaps in PS and RV. It moves builds to isolated runners, signs container images, stores SBOMs per release, publishes a disclosure policy and adds root cause analysis to its incident template. The same changes later satisfy a European customer's CRA-related questionnaire.

Next steps

Map your life cycle to the SSDF tasks.
Close gaps in build integrity, provenance and vulnerability response first.
Automate checks and set release gates.
Prepare an attestation or evidence pack for government and enterprise buyers.
Measure maturity over time with OWASP SAMM.

Frequently asked questions

Is the NIST SSDF mandatory?

No. It is voluntary. Since OMB M-26-05 in January 2026, US federal agencies decide whether to require SSDF attestation or other evidence from software producers.

What is the current version of the SSDF?

Version 1.1, published as SP 800-218 in February 2022, with SP 800-218A adding a profile for generative AI and dual-use foundation models.

What are the four SSDF practice groups?

Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV).

Is the CISA attestation form still required?

Not government-wide. Agencies may still use it, so check each contract or solicitation.

Is there an SSDF certification?

No. Producers self-assess or attest, and some customers ask for independent assessments.

How does the SSDF relate to the OWASP Top 10?

The SSDF describes the development process; the OWASP Top 10 describes common web risks that the process should prevent and test for.

Does the SSDF require an SBOM?

It requires archiving releases with provenance data; an SBOM is the usual way to meet that and is listed as an example.

Does the SSDF apply to SaaS?

Yes. Its practices apply to any software, including software delivered as a service.

Can agile teams use the SSDF?

Yes. It is life-cycle neutral and designed to be integrated into agile and DevOps practices.

Who in the company should own the SSDF?

Usually the head of engineering, with a security lead or champion in each team. Executives need to be involved if customers ask for a signed attestation, because the form is signed at that level.

How does the SSDF help with the EU Cyber Resilience Act?

Many CRA essential requirements, such as vulnerability handling, secure defaults, testing and SBOMs, correspond to SSDF practices, so an SSDF-aligned process is a strong foundation.