SecurityUSA

NIST-SSDF

Make secure development practices easier to evidence

Connect software-security responsibilities to the work completed across development and release.

Full title
NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
Issued by
National Institute of Standards and Technology (NIST)
Current version
Version 1.1, February 2022. A draft Version 1.2 (SP 800-218 Rev. 1) was released for comment in December 2025.
Applies to
Software producers of any size, and the organisations that buy or build software
Nature
Voluntary set of practices. NIST does not certify against it. US federal buyers may refer to it in procurement.
Structure
Four practice groups (PO, PS, PW, RV) with 19 practices, each broken into tasks with examples and references

Overview

What the SSDF is

The Secure Software Development Framework is a set of high-level practices for building security into software development. It is not tied to any language, tool or method, so it can be added to waterfall, agile or DevOps life cycles. Its aims are to reduce the number of vulnerabilities in released software, limit the impact of those that remain, and address their root causes so they do not recur.

Version 1.1, published as SP 800-218 in February 2022, was produced in response to Section 4 of Executive Order 14028 on improving the nation’s cybersecurity. It groups 19 practices into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. Each practice is broken into tasks, with notional implementation examples and references to other secure development standards.

NIST released an initial public draft of SSDF Version 1.2, SP 800-218 Revision 1, on 17 December 2025, with comments closing on 30 January 2026. The draft proposes new practices on continuous process improvement and on robust and reliable software updates, more implementation examples and updated mappings, and addresses AI used in development. As at October 2026 the final version had not been published, so Version 1.1 remains the current final text. NIST has separately published SP 800-218A, a community profile for generative AI and dual-use foundation models.

SSDF practices formed the basis of the US common secure software development self-attestation form used in federal procurement. In January 2026, OMB memorandum M-26-05 rescinded the earlier memoranda that made that attestation mandatory, leaving agencies to take a risk-based approach and to use the form if they choose. Suppliers to US federal agencies should check what their buyer currently asks for.

Who it applies to

The SSDF is written for anyone who produces or acquires software, including:

  • Software product companies and SaaS providers
  • In-house development teams in banks, government bodies and enterprises
  • IT services firms that build software for clients
  • Suppliers selling software to US federal agencies
  • Buyers who want a common vocabulary for asking suppliers about secure development
  • Developers of AI systems, through the SP 800-218A community profile

The SSDF is voluntary. It becomes an obligation only where a contract, a procurement requirement or an internal policy adopts it.

Structure

How the SSDF is organised

Four practice groups and 19 practices in Version 1.1. Each practice has tasks (such as PO.1.1), notional implementation examples and references. PW.3 was withdrawn in Version 1.1 and its content moved to PO.1.3 and PW.4.

PO

Prepare the Organization

People, processes and technology are ready to develop software securely, at organisation level and for each project.

PO.1 Define Security Requirements for Software Development
Security requirements for the organisation’s infrastructure and processes, for the software it develops, and for third-party components it acquires.
PO.2 Implement Roles and Responsibilities
Roles defined and people trained for them, with management commitment to secure development.
PO.3 Implement Supporting Toolchains
Tools chosen, deployed and configured to automate secure development and produce evidence.
PO.4 Define and Use Criteria for Software Security Checks
Criteria for security checks throughout the life cycle, with information gathered to show they are met.
PO.5 Implement and Maintain Secure Environments for Software Development
Development, build, test and distribution environments separated and protected, and developer endpoints secured.
PS

Protect the Software

All components of the software are protected from tampering and unauthorised access.

PS.1 Protect All Forms of Code from Unauthorized Access and Tampering
Source code, executable code and configuration stored with least-privilege access and integrity protection.
PS.2 Provide a Mechanism for Verifying Software Release Integrity
Information, such as cryptographic hashes or signatures, that lets acquirers verify a release is legitimate.
PS.3 Archive and Protect Each Software Release
Releases archived and protected, with provenance data such as a software bill of materials collected and maintained.
PW

Produce Well-Secured Software

Software is produced with minimal security vulnerabilities in its releases.

PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks
Risk modelling and secure design, tracking how requirements and risks are addressed.
PW.2 Review the Software Design
Design reviewed to verify it meets security requirements and addresses risk information.
PW.4 Reuse Existing, Well-Secured Software When Feasible
Acquiring and maintaining well-secured components, including third-party and open-source software, rather than duplicating functionality.
PW.5 Create Source Code by Adhering to Secure Coding Practices
Secure coding practices suited to the languages and environment.
PW.6 Configure the Compilation, Interpreter, and Build Processes
Build tools and settings chosen to improve executable security.
PW.7 Review and/or Analyze Human-Readable Code
Code review and code analysis to find vulnerabilities and verify security requirements.
PW.8 Test Executable Code
Security testing of executable code to find vulnerabilities and verify requirements.
PW.9 Configure Software to Have Secure Settings by Default
A secure default configuration, with guidance for administrators.
RV

Respond to Vulnerabilities

Residual vulnerabilities in releases are found and responded to, and similar ones are prevented in future.

RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis
Monitoring for vulnerabilities, a policy for receiving reports, and continuous gathering of information about them.
RV.2 Assess, Prioritize, and Remediate Vulnerabilities
Analysing each vulnerability, planning and carrying out the response, including advisories and fixes.
RV.3 Analyze Vulnerabilities to Identify Their Root Causes
Root-cause analysis, looking for similar flaws and improving the life cycle to prevent recurrence.
Draft 1.2

Proposed in the Version 1.2 draft

From the December 2025 initial public draft of SP 800-218 Rev. 1. These are proposals and may change in the final text.

PO.6 Continuous Process Improvement
Improving secure development procedures across all SSDF practices.
PW.10 Robust and Reliable Updates
Testing and delivering software updates reliably, including rollback mechanisms.
AI in development
Coverage of AI-generated code and AI used as a participant in build, test and deployment processes.

Implementation roadmap

How to implement it, step by step

A practical sequence for adopting the SSDF across development teams.

  1. 1

    Set scope and requirements

    Decide which products, teams and pipelines are in scope. Record the security requirements that apply, including customer, contractual and regulatory ones.

    OutputsScope statementSecurity requirements list
  2. 2

    Assign roles and train

    Name owners for secure development, security review and vulnerability response, and train developers for their roles.

    OutputsRoles matrixTraining records
  3. 3

    Assess current practice

    Compare each SSDF task with what teams already do, and record gaps with owners and dates.

    OutputsSSDF gap assessment
  4. 4

    Secure the environments and toolchain

    Separate and protect development, build and distribution environments, protect code repositories, and configure tools to produce evidence automatically.

    OutputsEnvironment controlsToolchain configuration
  5. 5

    Build security into design and code

    Introduce risk modelling, design review, secure coding standards, code analysis and security testing with defined pass criteria.

    OutputsSecure coding standardCheck criteriaTest results
  6. 6

    Manage third-party components

    Keep an inventory of components, including open-source software, assess them before use and track their vulnerabilities.

    OutputsComponent inventorySBOMs
  7. 7

    Protect releases

    Sign or hash releases, archive them and keep provenance data so customers can verify what they receive.

    OutputsRelease integrity recordsRelease archive
  8. 8

    Run vulnerability response

    Publish a vulnerability disclosure policy, triage and fix reports, issue advisories and analyse root causes to stop recurrence.

    OutputsDisclosure policyVulnerability recordsRoot-cause analyses

Audit and evidence guide

What auditors look for, and the evidence to keep

NIST does not certify SSDF conformance. Organisations show their practices through internal reviews, customer due diligence, third-party assessments or, where a buyer asks for it, a self-attestation.

What reviewers look for

  • Documented security requirements for development and for acquired components
  • Defined roles, training and management commitment
  • Separation and protection of development, build and distribution environments
  • Access control and integrity protection for code repositories
  • Design review and risk modelling for significant changes
  • Code review, analysis and security testing results against defined criteria
  • Inventory and assessment of third-party and open-source components
  • Release integrity mechanisms and provenance data
  • A vulnerability disclosure policy and records of response and root-cause analysis

Key dates and cycles

SSDF Version 1.1 (SP 800-218)February 2022
SP 800-218A generative AI profileJuly 2024
Draft Version 1.2 released17 December 2025
Draft 1.2 comments closed30 January 2026
Security checksPer the criteria in PO.4
Vulnerability monitoringOngoing (RV.1)

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Preparation

  • Secure development policy
  • Security requirements
  • Roles and training records
  • Toolchain configuration

Environments

  • Environment separation
  • Build system access controls
  • Developer endpoint protection

Code and releases

  • Repository access reviews
  • Signed commits or releases
  • Release archive
  • SBOMs

Design and build

  • Design reviews
  • Risk models
  • Build configuration

Verification

  • Code review records
  • Static and dynamic analysis results
  • Security test reports

Components

  • Component inventory
  • Third-party assessments
  • Component vulnerability tracking

Vulnerability response

  • Disclosure policy
  • Vulnerability tickets
  • Advisories
  • Root-cause analyses

Areas that often need attention

  • Security tools run, but no criteria for what blocks a release
  • Build and distribution systems with broad access
  • No inventory of open-source and third-party components
  • Releases that customers cannot verify
  • No published way to report vulnerabilities
  • Vulnerabilities fixed without root-cause analysis
  • Evidence spread across tools and never collected for review

How Netra helps

Where each part of the work lives in Netra

Netra loads SSDF practices as requirements, tasks and policies, and links the evidence your development tools produce to each practice.

Practices and tasks owned

Task Engine

SSDF tasks arrive as Netra tasks with owners and due dates, and recurring tasks cover reviews and checks.

Status for each practice

Compliance Centre

Status is derived from completed tasks and evidence, never typed in, and one task can count towards SP 800-53 or ISO 27001 where the work is the same.

Secure development policy and standards

Policy Hub

A policy library generated at onboarding, with a policy score that rises as the work behind each policy is done.

Third-party components and suppliers

Third-Party Risk

Finds vendors from what Accounts and Purchase pay, assesses them through a vendor portal and records decisions with ratings.

Systems and repositories in scope

Asset Management

Assets such as build systems and repositories linked to the tasks that protect them.

Software security risks

Risk Manager

A risk register with inherent and residual heatmaps, with risks reduced as linked tasks complete.

Drafting procedures

Netra AI

Drafts SOPs and suggests missing evidence from the organisation’s own records. It never changes status on its own.

Netra organises work and evidence for SSDF practices. It does not scan code, test software or manage vulnerabilities, and it does not complete or submit attestations. Adopting the SSDF in Netra does not by itself establish conformance.

Common questions

More questions about Netra

Related frameworks

View all frameworks
Security

NIST SP 800-53

Organise a tailored security and privacy control programme

Security

ISO 27001:2022 (Security Controls)

Make security controls visible through completed work

AI governance

NIST AI RMF 1.0

Turn responsible AI goals into accountable work

See NIST-SSDF in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.