NIST Secure Software Development Framework (SSDF)

Introduction: The NIST Secure Software Development Framework (SSDF)

The NIST Secure Software Development Framework (SSDF), formally published as NIST Special Publication 800-218, is a set of fundamental, sound and secure software development practices grouped into four families. It provides a common vocabulary and a risk-based, outcome-driven model that any organisation can integrate into an existing Software Development Life Cycle (SDLC) irrespective of the methodology (Agile, Waterfall, DevSecOps), the programming language, the platform or the tooling in use. The SSDF does not prescribe a single way of doing things; instead it describes what secure outcomes must be achieved, leaving the how to the producer's own environment and risk tolerance.

The SSDF rose to global prominence following US Executive Order 14028 (Improving the Nation's Cybersecurity, May 2021) and the subsequent OMB Memoranda M-22-18 and M-23-16, which require software producers selling to the US federal government to self-attest that they follow secure development practices aligned to the SSDF. Because the framework is vendor-neutral, technology-agnostic and freely available, it has become the de-facto baseline against which secure software engineering is judged worldwide, including for Indian and Gulf-region producers exporting into US supply chains. This guide is written for two audiences at once: the auditor or assessor who must verify conformance, and the implementer or product engineering team that must build the practices into their pipeline.

What is the NIST SSDF?

The NIST SSDF is a catalogue of secure software development practices, each expressed as a Practice, a set of Tasks, and supporting Notional Implementation Examples plus References to established standards (such as BSA, BSIMM, OWASP SAMM, ISO/IEC 27034, SAFECode and PCI SSF). It is deliberately abstract at the practice level so that it can be mapped onto whatever concrete controls, tools and processes an organisation already operates. The framework's central premise is that reducing the number of vulnerabilities in released software, reducing the potential impact of the exploitation of undetected or unaddressed vulnerabilities, and addressing the root causes of vulnerabilities to prevent recurrence is far cheaper and safer than reacting to incidents after release.

The SSDF is organised into four practice families identified by two-letter prefixes:

• Prepare the Organisation (PO) — ensure that people, processes and technology are ready to perform secure software development at the organisation level and, as appropriate, for individual development groups or projects.
• Protect the Software (PS) — protect all components of the software from tampering and unauthorised access, and safeguard the integrity of releases.
• Produce Well-Secured Software (PW) — produce software with minimal security vulnerabilities in its releases by applying secure design, coding, review and testing practices.
• Respond to Vulnerabilities (RV) — identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in future.

Each practice carries a unique identifier (for example PW.4 or RV.1), each task a numbered sub-identifier (for example PW.4.1), and each task is accompanied by illustrative examples and cross-references. SP 800-218A extends the base framework with additional practices and tasks specific to the producers of AI models and generative-AI systems, addressing concerns such as training-data provenance, model poisoning and misuse.

Who must comply with the NIST SSDF?

The SSDF is voluntary as a framework, but conformance is contractually or regulatorily mandatory for many producers. The following categories describe who is realistically obliged, or strongly expected, to demonstrate SSDF alignment.

• Regulated buyers increasingly reference the SSDF in Master Service Agreements, RFPs and vendor security questionnaires.
• Cyber-insurance underwriters use SSDF alignment as evidence of secure engineering maturity.
• Attestation is signed by a senior company official (typically the CEO or a designated officer) and may require a third-party assessor for critical software.

Structure of the NIST SSDF

The framework is hierarchical: four Practice families, each containing numbered Practices, each Practice containing numbered Tasks. Every task is supported by Notional Implementation Examples and References. The table below sets out the full structure of the practice families and their constituent practices as defined in SP 800-218, with the AI-specific additions of SP 800-218A noted separately.

Master assessment checklist — every practice and task

This is the operational heart of the guide. Each practice group below is presented with a heading, an explanation, and a two-column verification table listing what an auditor must verify and the typical evidence an implementer should produce. No practice family is omitted. Tasks are referenced by their SP 800-218 identifiers so that findings can be traced precisely.

PO.1 — Define Security Requirements for Software Development

Covers tasks PO.1.1 (identify and document all internal and external security requirements), PO.1.2 (identify and document security requirements for the development infrastructure and process) and PO.1.3 (communicate requirements to third parties and monitor their compliance).

PO.2 — Implement Roles and Responsibilities

Covers PO.2.1 (create roles and responsibilities and grant authority), PO.2.2 (provide role-based training and assess competency) and PO.2.3 (obtain upper-management commitment).

PO.3 — Implement Supporting Toolchains

Covers PO.3.1 (specify which tools or tool types must be included), PO.3.2 (deploy and maintain tools securely and integrate them), and PO.3.3 (configure tools to collect evidence and artefacts).

PO.4 — Define and Use Criteria for Software Security Checks

Covers PO.4.1 (define criteria for security checks and gather information to determine whether they are met) and PO.4.2 (implement processes, mechanisms and tooling to gather the necessary information).

PO.5 — Implement and Maintain Secure Environments for Software Development

Covers PO.5.1 (separate and protect each environment involved in development) and PO.5.2 (secure and harden development endpoints).

PS.1 — Protect All Forms of Code from Unauthorised Access and Tampering

Covers PS.1.1 (store all forms of code, including source, executables and configuration, based on the principle of least privilege so that only authorised personnel, tools and services have access).

PS.2 — Provide a Mechanism for Verifying Software Release Integrity

Covers PS.2.1 (make software integrity verification information available to consumers, such as cryptographic hashes or digital signatures).

PS.3 — Archive and Protect Each Software Release

Covers PS.3.1 (securely archive the necessary files and supporting data such as integrity information for each release) and PS.3.2 (collect, safeguard, maintain and share provenance data for all components of each release, for example a Software Bill of Materials).

PW.1 — Design Software to Meet Security Requirements and Mitigate Security Risks

Covers PW.1.1 (use forms of risk modelling such as threat modelling, attack modelling or attack-surface mapping to assess security risk), PW.1.2 (track and maintain security requirements, risks and design decisions) and PW.1.3 (where applicable, reuse standardised security features and services rather than creating proprietary ones).

PW.2 — Review the Software Design to Verify Compliance

Covers PW.2.1 (have a qualified person or automated process independent of the designer review the software design to confirm it meets security requirements and satisfactorily addresses identified risks).

PW.4 — Reuse Existing, Well-Secured Software When Feasible

Covers PW.4.1 (acquire and maintain well-secured software components from commercial, open-source and other third-party sources), PW.4.2 (create and reuse well-secured software) and PW.4.4 (verify that acquired components are secure and comply with organisational requirements).

PW.5 — Create Source Code by Adhering to Secure Coding Practices

Covers PW.5.1 (follow all secure coding practices appropriate to the development languages and environment, including using safe functions, validating inputs and encoding outputs).

PW.6 — Configure the Compilation, Interpreter and Build Processes

Covers PW.6.1 (use compiler, interpreter and build tools that offer features to improve executable security) and PW.6.2 (determine which compiler, interpreter and build tool features to use and how each should be configured, then implement and use the approved configurations).

PW.7 — Review and/or Analyse Human-Readable Code

Covers PW.7.1 (determine whether code review, code analysis or both should be used, and for which code) and PW.7.2 (perform the code review and/or analysis based on the organisation's secure coding standards, and record and triage discovered issues).

PW.8 — Test Executable Code to Identify Vulnerabilities and Verify Compliance

Covers PW.8.1 (determine whether executable code testing should be performed and, if so, which types) and PW.8.2 (scope, design, execute and document the testing, and record and triage discovered issues).

PW.9 — Configure Software to Have Secure Settings by Default

Covers PW.9.1 (define a secure baseline by determining how to configure each setting that has an effect on security so the default configuration is secure) and PW.9.2 (implement the default configurations, and document each setting for software administrators).

RV.1 — Identify and Confirm Vulnerabilities on an Ongoing Basis

Covers RV.1.1 (gather information from consumers and public sources on potential vulnerabilities and investigate reports), RV.1.2 (review, analyse and/or test the software's code to identify or confirm undetected vulnerabilities) and RV.1.3 (have a policy that addresses vulnerability disclosure and remediation, and implement roles, responsibilities and processes to support it).

RV.2 — Assess, Prioritise and Remediate Vulnerabilities

Covers RV.2.1 (analyse each vulnerability to gather sufficient information to plan its remediation) and RV.2.2 (develop and implement remediation for each vulnerability, prioritised by risk).

RV.3 — Analyse Vulnerabilities to Identify Their Root Causes

Covers RV.3.1 (analyse identified vulnerabilities to determine their root causes), RV.3.2 (analyse the root causes over time to identify patterns), RV.3.3 (review the SDLC to determine how to prevent similar vulnerabilities) and RV.3.4 (review the software for other instances of the reported vulnerability and remediate them proactively).

SP 800-218A — Additional practices for AI and generative-AI producers

The companion publication augments the base practices with AI-specific tasks addressing training data, model integrity and misuse. These are layered onto the existing PO/PS/PW/RV structure rather than forming a new family.

Scoping the assessment

Correct scoping determines the credibility and efficiency of an SSDF assessment. Because the SSDF applies at the organisational level and at the level of individual development groups or products, scope must be defined along several axes before any evidence is gathered.

• Organisational scope: which business units, development groups and legal entities are covered by the attestation or assessment.
• Product/line-of-code scope: which specific software products, versions, services or repositories are being attested; whether it is a single product or a product line.
• Environment scope: which development, build, test and release environments and toolchains are in scope, including cloud and on-prem.
• Component scope: the treatment of first-party code, reused internal modules, commercial third-party components and open-source dependencies (PW.4, PS.3.2).
• Criticality scope: whether any in-scope software meets NIST's definition of EO-critical software, which raises the depth of expected evidence.
• AI scope: whether SP 800-218A applies because AI/ML or generative-AI models are produced or embedded.
• Temporal scope: the SDLC period and release versions covered; the SSDF is continuous, so a point-in-time assessment must still evidence ongoing operation.
• Exclusions: legacy or end-of-life software and clearly demarcated out-of-scope systems, with documented justification.

Implementation approach (phased)

CyberSigma recommends a five-phase implementation that moves an organisation from ad-hoc security to a repeatable, attestable secure-SDLC. Each phase lists indicative activities and deliverables.

Phase 1 — Prepare and baseline (Prepare the Organisation)

• Activities: perform a gap assessment against all PO/PS/PW/RV practices; define security requirements (PO.1); assign roles and secure the tone from the top (PO.2); inventory existing toolchain and environments (PO.3, PO.5).
• Deliverables: SSDF gap report; security requirements register; RACI and role definitions; toolchain and environment inventory; prioritised remediation roadmap.

Phase 2 — Protect the pipeline (Protect the Software)

• Activities: enforce least-privilege repository access and branch protection (PS.1); implement code signing and release integrity (PS.2); establish secure archival and SBOM generation (PS.3).
• Deliverables: hardened source-control configuration; signing pipeline; SBOM (SPDX/CycloneDX); release archive and retention policy.

Phase 3 — Build securely (Produce Well-Secured Software)

• Activities: embed threat modelling and design review (PW.1, PW.2); adopt secure coding standards (PW.5); harden build configuration (PW.6); integrate SAST, SCA, DAST and secrets scanning as pipeline gates (PW.7, PW.8); define secure-by-default settings (PW.9).
• Deliverables: threat models; secure coding standard; hardened build definitions; automated security gates; secure-by-default baseline and hardening guide.

Phase 4 — Respond and disclose (Respond to Vulnerabilities)

• Activities: stand up a PSIRT and coordinated vulnerability disclosure process (RV.1); define risk-based remediation SLAs (RV.2); institute root-cause analysis and trend review (RV.3).
• Deliverables: vulnerability disclosure policy; PSIRT runbook; remediation SLA matrix; RCA process and trend dashboard.

Phase 5 — Attest, operate and improve

• Activities: assemble the attestation evidence package; complete the CISA/RSAA self-attestation (or third-party assessment for critical software); operationalise continuous monitoring; run periodic internal audits and maturity reviews.
• Deliverables: signed attestation and evidence artefacts; continuous-monitoring dashboards; internal audit reports; annual improvement plan.

Maturity and capability model

The SSDF itself does not mandate maturity levels, but CyberSigma applies a five-tier capability model (aligned in spirit with OWASP SAMM and BSIMM) to help organisations chart progress and target investment across the practice families.

Assessment and audit approach

A defensible SSDF assessment follows a structured lifecycle whether performed internally, by CyberSigma as an independent assessor, or in support of a formal attestation.

1. Initiation and scoping: agree the organisational, product, environment and component scope; confirm whether SP 800-218A (AI) applies; document exclusions.
2. Documentation review: examine policies, secure-SDLC standards, requirement registers, threat models and toolchain configurations against each practice.
3. Toolchain and pipeline inspection: verify that SAST, SCA, DAST, secrets scanning, signing and SBOM generation are integrated and enforced as gates.
4. Evidence sampling: select a representative set of products, releases and pull requests and trace them through the full lifecycle for practice conformance.
5. Interviews and walkthroughs: interview developers, security champions, build engineers and the PSIRT to confirm practices operate as documented.
6. Technical validation: independently re-run or review selected scans, verify release signatures, and validate an SBOM against actual dependencies.
7. Gap analysis and findings: rate each practice/task, record non-conformities and observations, and map findings to risk.
8. Remediation planning: agree corrective actions, owners and timelines; re-test critical gaps where required.
9. Reporting: issue the assessment report with the practice-by-practice conformance matrix and executive summary.
10. Attestation support: assist the signing official in completing the self-attestation (or third-party assessment) and assembling the evidence package.

Evidence request list

The following categorised list is the standard evidence pack CyberSigma requests for an SSDF assessment. Producing it in advance dramatically shortens the engagement.

• Governance (PO): security requirements register; secure-SDLC policy and standards; RACI/role definitions; management commitment records; training records.
• Toolchain and environments (PO): approved tool list; pipeline/CI-CD definitions; environment segregation and endpoint hardening baselines; security gate criteria and waiver register.
• Code protection (PS): repository access model and branch protection; code-signing configuration and key-management records; release archive and retention policy.
• Provenance (PS): SBOMs in SPDX or CycloneDX; component/dependency inventory; build provenance/attestations.
• Design and coding (PW): threat models and attack-surface analyses; design review sign-offs; secure coding standards; build hardening configuration.
• Testing (PW): SAST, SCA, DAST, fuzzing and penetration test reports; secrets-scanning results; secure-by-default baseline and hardening guide.
• Vulnerability response (RV): vulnerability disclosure/CVD policy; PSIRT runbook; vulnerability register with risk scoring and SLAs; security advisories; root-cause analyses and trend reports.
• AI (SP 800-218A, if in scope): data provenance records; model cards and AI-BOM; adversarial/red-team test results; model signing and access controls.
• Attestation artefacts: completed self-attestation form; evidence index; prior assessment reports and remediation status.

Roles and responsibilities

KPIs to track

• Percentage of in-scope products with an approved SBOM published for each release.
• Percentage of releases that are digitally signed with verified integrity (PS.2).
• Percentage of code merges passing mandatory security gates (SAST/SCA/secrets) without exception.
• Mean time to remediate (MTTR) vulnerabilities by severity, against defined SLAs (RV.2).
• Percentage of products with a current threat model reviewed within the release cycle (PW.1, PW.2).
• Density of security defects found pre-release versus post-release (leakage rate).
• Percentage of developers current on role-based secure-development training (PO.2.2).
• Number and age of open critical/high vulnerabilities beyond SLA.
• Percentage of third-party/open-source components with known-vulnerability status tracked (PW.4).
• Recurrence rate of vulnerabilities addressed by root-cause analysis (RV.3).

Readiness checklist

• Security requirements are documented, current and cover legal, regulatory and contractual obligations (PO.1).
• Secure-SDLC roles are assigned with senior management commitment and role-based training in place (PO.2).
• Approved toolchain (SAST, SCA, DAST, secrets, SBOM) is deployed, hardened and integrated (PO.3).
• Objective security gate criteria are defined and enforced at each checkpoint (PO.4).
• Development, build, test and production environments are segregated and endpoints are hardened (PO.5).
• All forms of code are stored under least-privilege access with branch protection (PS.1).
• Releases are digitally signed and integrity verification information is published (PS.2).
• Each release is securely archived and an SBOM is generated and shared (PS.3).
• Threat modelling and independent design review are performed for in-scope products (PW.1, PW.2).
• Third-party and open-source components are vetted, tracked and reused safely (PW.4).
• Secure coding standards, hardened builds and secure-by-default settings are applied (PW.5, PW.6, PW.9).
• Code review/analysis and executable testing are performed with findings triaged (PW.7, PW.8).
• A published vulnerability disclosure policy and PSIRT process operate with defined SLAs (RV.1, RV.2).
• Root-cause analysis feeds SDLC improvements and proactive variant remediation (RV.3).
• AI-specific practices are addressed where SP 800-218A applies.
• The attestation evidence package is assembled and the signing official is briefed.

Common gaps

• Treating the SSDF as a one-off audit rather than a continuous, operating capability across every release.
• Missing or incomplete SBOMs, or SBOMs that do not reflect the actual dependency tree used in the build (PS.3.2).
• Threat modelling performed for flagship products only, leaving smaller products and services unmodelled (PW.1).
• Security gates that are advisory rather than enforced, with unchecked or unapproved exception waivers (PO.4).
• No published, operational vulnerability disclosure policy or PSIRT, so external reports have no route in (RV.1.3).
• Weak protection of signing keys and CI/CD credentials, undermining release integrity (PS.1, PS.2).
• Root-cause analysis stopping at the individual fix without trend analysis or SDLC change (RV.3.2, RV.3.3).
• Supplier security requirements not flowed down or monitored for open-source and commercial components (PO.1.3, PW.4).
• Development environments not segregated from production, or unhardened developer endpoints (PO.5).
• Attestation signed by the wrong scope or without an evidence package to support it.
• AI/ML producers overlooking data provenance and model integrity where SP 800-218A applies.

NIST SSDF mapped to other frameworks

The SSDF is intentionally interoperable. The mapping below helps organisations reuse existing controls and evidence when they operate multiple frameworks.

Frequently asked questions

Need help with NIST SSDF?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.