NIST SP 800-218 (Secure Software Development Framework): NIST SP 800-218 – Tutorial (about 60 minutes)

NIST Special Publication 800-218, the Secure Software Development Framework (SSDF), is a short catalogue of high-level practices that any organisation can add to the way it already builds software, so that fewer vulnerabilities reach customers and the ones that slip through are handled well. It is published by the US National Institute of Standards and Technology (NIST) and is used by software vendors, in-house development teams, security and DevSecOps engineers, and by buyers who want a common language for asking suppliers how their software is made. After this tutorial you will be able to read the SSDF table, explain its four practice groups, plan an adoption project, collect evidence, and describe how the framework connects to attestation, supply-chain security and other standards.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current final edition is NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, published by NIST on 3 February 2022. It replaced the original SSDF Version 1.0, which appeared as a NIST Cybersecurity White Paper (CSWP 13) in April 2020. A revision is in progress: NIST released the initial public draft of SP 800-218 Rev. 1 (SSDF Version 1.2) on 17 December 2025, in response to US Executive Order 14306, and the public comment period closed on 30 January 2026. At the time of checking, NIST still lists Version 1.2 as a draft and Version 1.1 as the final, current publication. This tutorial therefore teaches Version 1.1 and points out clearly where the Version 1.2 draft adds or changes something (mainly two new practices, PO.6 and PS.4). A companion document, SP 800-218A, an SSDF Community Profile for generative AI and dual-use foundation models, was finalised in July 2024. NIST publications are free to download. Verified 2026-10-29 on the NIST Computer Security Resource Center (CSRC).

Who this is for: software engineers, team leads, DevOps and platform engineers, application security specialists, quality and compliance staff, product managers, and procurement or vendor-risk people who have been asked to "align with the SSDF", to answer a customer questionnaire about secure development, or to judge a supplier's answers. No prior security certification is assumed.

Prerequisites: none. A rough idea of how software is built (requirements, code, build, test, release) helps you picture the examples, and every security term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why NIST created the SSDF, what problem it solves and why it is deliberately outcome-based rather than prescriptive.
You will be able to name the four practice groups (PO, PS, PW, RV), describe the practices in each, and read a practice, task, notional implementation example and reference in the SSDF table.
You will be able to plan a risk-based adoption: define a current and target state, choose which tasks apply, integrate them into an existing development life cycle and produce evidence.
You will be able to describe how SSDF conformance is demonstrated to customers, including self-attestation, supporting artefacts and plans of action, and why there is no official "SSDF certificate".
You will be able to apply the framework to a realistic product team, from preparation through vulnerability response.
You will be able to explain how the SSDF relates to OWASP SAMM, BSIMM, IEC 62443-4-1, SLSA and NIST SP 800-53, and what the Version 1.2 draft changes.

Lesson 1 – Origins, purpose and scope

Why a secure development framework was needed

Most software problems that end up in security bulletins are not exotic. They come from missing input validation, outdated third-party libraries, weak defaults, secrets left in code, build systems that anyone on the network can modify, or a vulnerability report that sat unanswered in someone's inbox. Each of these has a well-known fix, and many organisations have written down good practices for years: Microsoft published its Security Development Lifecycle, SAFECode and the Business Software Alliance published secure development guidance, OWASP published verification standards and a maturity model, and industrial-control standards such as IEC 62443-4-1 set requirements for product development. The trouble was that every document used different words and different levels of detail. A buyer asking "do you develop securely?" received answers that could not be compared, and a development team had no simple, neutral checklist of outcomes to aim for.

The SSDF answers this by pulling the common ground out of those existing documents. It does not invent new practices. Instead it describes a core set of fundamental, high-level secure development practices, and then points to the established documents where the detail lives. You can think of it as a table of contents for secure software development that many existing guides agree on.

A short history

NIST first published the framework in April 2020 as a white paper, giving it Version 1.0. In May 2021 US Executive Order 14028, "Improving the Nation's Cybersecurity", asked NIST to issue guidance on practices that would improve the security of the software supply chain. NIST held a workshop in June 2021, received more than 150 position papers, and turned the white paper into a Special Publication. A draft appeared in September 2021, and the final SP 800-218, SSDF Version 1.1, was published in February 2022. Version 1.1 added a practice on securing development environments (PO.5), new tasks such as PS.3.2 on provenance data, moved the task on communicating requirements to third parties into PO.1 (as PO.1.3), added definitions of provenance, artifact and evidence, many more implementation examples and references, and an appendix mapping the executive order's requirements to SSDF tasks.

In 2024 NIST published SP 800-218A, which shows how to extend the SSDF for organisations that develop generative AI and foundation models. In June 2025 Executive Order 14306 asked NIST to update the SSDF with practices on the secure and reliable development and delivery of software and on the security of the software itself, and to work with industry on demonstrating the practices. The result was the Version 1.2 initial public draft of December 2025, discussed in Lesson 3.

Purpose in one sentence

The SSDF exists to reduce the number of vulnerabilities in released software, to reduce the possible impact when an undetected or unfixed vulnerability is exploited, and to find and remove the root causes of vulnerabilities so the same kind does not come back. Those three aims appear throughout the document and are worth remembering, because every practice serves at least one of them.

Scope: what the SSDF is and is not

It applies to any software, whatever the language, platform or delivery model: commercial products, government software, internal applications, firmware, cloud services, operational technology and Internet of Things software.
It applies to any software development life cycle (SDLC) model, whether waterfall, spiral, agile or DevOps. It is meant to be woven into the model you already use, not to replace it.
It describes outcomes, not tools. It never says "use product X" or "run this scanner every night". It says, in effect, "make sure this result is achieved, using whatever methods fit your situation."
It is a subset of what an organisation may need. The detail sits in the referenced documents, and the SSDF assumes you will consult them.
It is not a checklist and not a maturity model. NIST says explicitly that the practices are a starting point to be adapted, that they are not ranked by priority, and that adoption should be risk-based.
It is not a regulation in itself. Whether it is mandatory for you depends on contracts, customer requirements or government policy, which change over time (see Lesson 5).

Two audiences

The SSDF names two primary audiences. Software producers are those who create software: commercial vendors, government developers, contractors and internal teams of every size. Software acquirers are those who buy or obtain software, including government agencies and private companies. The framework gives both sides the same vocabulary: a producer can describe what it does by referring to SSDF practices, and an acquirer can state what it expects by referring to the same identifiers. This shared language is one of the biggest practical benefits of the SSDF and is similar to the way the NIST Cybersecurity Framework gave organisations a common language for describing cyber risk management.

Lesson 2 – Key concepts and vocabulary

The SSDF uses a small set of terms consistently. Learn these and the table becomes easy to read.

Software development life cycle (SDLC) – any formal or informal method for designing, creating and maintaining software, including code built into hardware. The SSDF uses the acronym only for software, not for whole systems.
Software producer – an organisation or team that develops software, whether for sale, for a government or for its own use.
Software acquirer – an organisation that buys or otherwise obtains software and wants confidence that it was developed securely.
Practice group – one of the four top-level families of the SSDF: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV).
Practice – a named outcome with a unique identifier such as PW.4, plus a short explanation of what it is and why it helps.
Task – a specific action that may be needed to achieve a practice, identified with a third number, such as PW.4.1. Tasks are the level at which most organisations assess themselves.
Notional implementation example – an illustration of a tool, process or method that could help perform a task. None is mandatory, and they are not the only valid options.
Reference (informative reference) – a pointer from a task to the matching section of an established secure development document, such as BSIMM, OWASP SAMM, IEC 62443-4-1, ISO/IEC 27034 or NIST SP 800-53.
Shifting left – addressing security as early as possible in the life cycle, because fixing a design flaw before coding costs far less than fixing it in production.
Vulnerability – a weakness that could be exploited. In the SSDF sense this includes coding bugs, but also insecure configuration settings, wrong trust assumptions and outdated risk analysis.
Risk modelling – structured analysis of how software could be attacked, such as threat modelling, attack modelling or attack surface mapping, used to decide which protections the design needs.
Toolchain – the set of tools used to write, build, test, package and deliver software, such as source control, build servers, compilers, scanners and artefact repositories.
Provenance – the recorded history of where a piece of software and its components came from, who and what changed them, and how they were built. NIST takes its definition from SP 800-53.
Software bill of materials (SBOM) – a formal, machine-readable list of the components that make up a piece of software, one common way of sharing provenance data.
Artefact and evidence – an artefact is a piece of evidence; evidence is anything that gives grounds for believing (or doubting) that a practice is really performed, such as a scan report, a signed commit log or a training record.
Secure by default – shipping software whose out-of-the-box settings are the secure ones, so that customers have to take deliberate action to weaken security rather than to achieve it.
Product security incident response team (PSIRT) – the group responsible for receiving, analysing and responding to vulnerability reports about an organisation's products.
Root cause analysis – working out why a vulnerability was introduced and escaped detection, so that the process, not just the code, can be fixed.
Community profile – a version of the SSDF tailored for a particular community or technology, adding or emphasising practices, tasks and examples. SP 800-218A for AI model development is the first one from NIST.

Note one deliberate gap: the SSDF uses words such as "sensitive data", "qualified person" and "well-secured" without defining them. NIST expects each organisation to define them for its own context, and the same applies to environment names such as development, build, test, staging and production. Writing these definitions down is often the first useful output of an SSDF project.

Lesson 3 – Structure of the framework

Four practice groups

Everything in the SSDF hangs from four groups. Their names describe the outcome each group is after.

Prepare the Organization (PO) – make sure people, processes and technology are ready to perform secure development, at the organisation level and, where useful, for individual groups or projects.
Protect the Software (PS) – protect every component of the software from tampering and unauthorised access.
Produce Well-Secured Software (PW) – produce software with as few security vulnerabilities as possible in its releases.
Respond to Vulnerabilities (RV) – find the vulnerabilities that remain in released software, respond appropriately, and prevent similar ones in future.

Figure 1 – The four SSDF practice groups: PO prepares the ground, PS and PW shape each release, RV handles what escapes and feeds lessons back.

Figure 1 shows why the groups are not a strict sequence. Preparation supports everything else; protecting and producing happen together during development; responding begins once software is released, and its findings flow back into preparation and production. This loop is how the SSDF meets its third aim of removing root causes.

How a practice is written

The heart of SP 800-218 is a single large table. Each row of the table has four columns, and understanding them is the key to using the document.

Figure 2 – The SSDF hierarchy: each group contains practices, each practice contains tasks, and each task carries optional examples and informative references.

The practice column gives the name, identifier and purpose. The tasks column lists one or more actions. The notional implementation examples column suggests ways of doing each task. The references column lists the matching sections of other documents. NIST stresses that the order of rows says nothing about the order of implementation or about importance.

The practices in Version 1.1

Version 1.1 contains 19 practices and 42 tasks. The summaries below are paraphrased; read the official table for the exact wording.

Prepare the Organization

PO.1 Define the security requirements for software development – both for the organisation's own infrastructure and processes and for the software it produces, and communicate the relevant requirements to third parties that supply components.
PO.2 Implement roles and responsibilities – create or adjust roles, give people role-based training, and obtain visible commitment from senior management.
PO.3 Implement supporting toolchains – decide which tools to use, operate them securely, and configure them to generate records that show secure practices are happening.
PO.4 Define and use criteria for software security checks – decide what "secure enough" means at each point in the life cycle, and collect the information needed to check it.
PO.5 Implement and maintain secure environments for software development – separate and protect the development, build and other environments, and harden the endpoints that developers and testers use.

Protect the Software

PS.1 Protect all forms of code from unauthorised access and tampering – source code, executables and configuration-as-code, using least privilege.
PS.2 Provide a mechanism for verifying software release integrity – for example published hashes and code signing, so acquirers can confirm that what they received is genuine.
PS.3 Archive and protect each software release – keep the files and supporting data for each release, and collect, protect and share provenance data for its components.

Produce Well-Secured Software

PW.1 Design software to meet security requirements and mitigate security risks – use risk modelling, track requirements and design decisions, and prefer standard, well-proven security features over home-made ones.
PW.2 Review the software design to verify compliance with security requirements and risk information – by a qualified person who did not create the design, or by automated means.
PW.4 Reuse existing, well-secured software when feasible instead of duplicating functionality – acquire and maintain well-secured components, create internal ones where needed, and keep verifying third-party components throughout their life.
PW.5 Create source code by adhering to secure coding practices suited to the languages and environment.
PW.6 Configure the compilation, interpreter and build processes to improve executable security.
PW.7 Review and/or analyse human-readable code to identify vulnerabilities and verify compliance with security requirements.
PW.8 Test executable code to identify vulnerabilities and verify compliance with security requirements.
PW.9 Configure software to have secure settings by default – define a secure baseline and document each setting for administrators.

You will notice there is no PW.3. It existed in Version 1.0 and covered third-party software; its tasks moved to PO.1.3 and PW.4.4. NIST marks moved or deleted identifiers as retired rather than reusing them, so that old mappings stay unambiguous.

Respond to Vulnerabilities

RV.1 Identify and confirm vulnerabilities on an ongoing basis – gather reports from customers, researchers and public sources, keep analysing code, and run a vulnerability disclosure and response policy with clear roles.
RV.2 Assess, prioritise and remediate vulnerabilities – understand the risk of each one and decide on a response, which may be a fix, a workaround or a documented acceptance.
RV.3 Analyse vulnerabilities to identify their root causes – find root causes, look for patterns over time, look for similar flaws elsewhere, and update the development process so the cause does not recur.

What the Version 1.2 draft changes

The December 2025 draft keeps the same four groups and the same identifiers, which protects existing mappings. Its most visible changes are two new practices. PO.6 asks organisations to define and carry out a continuous improvement plan for their secure development processes, for example improving development environments as new threats and tools appear, adopting languages or tools that remove whole classes of errors, and periodically revisiting earlier vulnerability-response decisions. PS.4 focuses on robust and reliable software updates: testing updates in conditions close to real customer installations, using staged or tiered roll-outs such as canary releases, providing safe rollback, and keeping the update delivery infrastructure resilient. The draft also rewords two response tasks, adds implementation examples in several PW and RV tasks (for instance on well-structured input formats and the use of formal methods for high-risk code), refreshes the references to SP 800-53 and SP 800-161, and removes the appendix about Executive Order 14028. With these additions the draft contains 21 practices and 49 tasks. Because it is still a draft, treat these changes as a preview rather than as requirements.

Lesson 4 – How it works in practice

Start with a risk-based mindset

NIST is clear that not every practice applies to every situation and that practices are not equally important everywhere. If your software is never compiled, the tasks about compiler hardening do not apply. If you build a low-risk internal tool, the formality of your design review can be lighter than for software that controls a medical device. The degree to which each task is implemented, and how formally, should depend on risk, cost, feasibility and applicability. Automation also matters: at scale, a practice that cannot be automated tends to decay.

This flexibility is a strength, but it puts a responsibility on you. "We decided this task does not apply" is a legitimate answer only if the decision is reasoned, recorded and revisited.

A typical adoption path

Scope. Decide which products, teams and environments are in scope. Many organisations start with one product line that faces external customers.
Define your terms. Write down what you mean by "sensitive data", "qualified reviewer", "well-secured component" and the names of your environments.
Assess the current state. For each task, record what you do today, how consistently, and what evidence exists. A simple spreadsheet with one row per task is enough to begin.
Define the target state. Decide, task by task, what you need to achieve and to what degree, based on your risk and your customers' expectations. NIST notes that the SSDF can describe both current practices and future target practices, much as the Cybersecurity Framework uses current and target profiles.
Prioritise the gaps. Fix foundational items first. Practices such as access control on repositories and a vulnerability intake process enable many others.
Integrate into the existing life cycle. Put each activity where it naturally belongs in your SDLC or pipeline, rather than adding a separate "security phase".
Generate evidence automatically. Configure tools so that records of reviews, scans, approvals and signatures are created as a by-product of normal work.
Measure and improve. Track the criteria from PO.4 and revisit the target state regularly. The Version 1.2 draft turns this habit into its own practice, PO.6.

Mapping practices to the pipeline

For a team using a modern continuous integration and delivery pipeline, the SSDF maps neatly onto everyday stages. Figure 3 shows one possible mapping. Your mapping will differ, and that is the point: the framework adapts to your process.

Figure 3 – One way to place SSDF practices along a delivery pipeline, with organisation-level practices always active and response feeding back into design.

Roles

The SSDF does not prescribe an organisation chart, but PO.2 expects clear roles. Common roles include an executive sponsor who is accountable for secure development; a product security or application security team that sets standards and supports teams; security champions, developers in each team with extra training who act as the first point of contact; developers and testers who carry out most tasks; platform or DevOps engineers who secure the toolchain and environments; a PSIRT that handles vulnerability reports; and procurement or vendor-risk staff who pass requirements to suppliers. Training should match the role: a build engineer needs different knowledge from a product manager.

Artefacts you will typically produce

A secure development policy and a set of security requirements for software (PO.1).
Role descriptions and training records (PO.2).
A toolchain inventory and its secure configuration (PO.3), plus records the tools generate.
Security criteria, such as "no unresolved critical findings at release" (PO.4).
Threat models and design review notes (PW.1, PW.2).
Component inventories and SBOMs, and records of component vulnerability checks (PW.4, PS.3).
Code analysis and test results with triage decisions (PW.7, PW.8).
Signed releases and published hashes (PS.2), and a release archive (PS.3).
A vulnerability disclosure policy, a PSIRT process, and root cause records (RV.1–RV.3).

Shared responsibility in the cloud

When software runs on infrastructure, platform or software services from other providers, responsibility for some tasks is shared. The organisation consuming those services should agree with each provider which party performs which practice and task, and how the provider will show that it does so. For example, a team using a managed build service still owns the secure configuration of its own pipelines, while the provider owns the hardening of the underlying build hosts.

Handling third-party and open-source components

Modern applications are mostly made of other people's code. The SSDF treats this seriously: PO.1 asks you to communicate your security requirements to suppliers, PW.4 asks you to prefer well-secured components and keep checking them for newly disclosed vulnerabilities throughout their life, and PS.3 asks you to keep provenance data for every component of each release. In practice this means a software composition analysis tool in the pipeline, an approved-component process, and an SBOM generated at every build.

Lesson 5 – Assessment, attestation and compliance

There is no SSDF certification

NIST does not certify organisations against the SSDF, does not accredit SSDF auditors and does not run a conformance programme. Any "SSDF certificate" offered commercially is a private service, not an official NIST credential. What exists instead is a set of ways for producers to demonstrate their practices and for acquirers to evaluate them.

Self-assessment

The simplest form is a self-assessment: the producer goes through each task, records its implementation and evidence, and identifies gaps. Because the SSDF is outcome-based, a good self-assessment explains how the outcome is achieved and points to evidence, rather than simply ticking "yes". Many teams use the official Excel version of the SSDF table published by NIST as the starting template.

Attestation for US federal customers

The framework became widely known because of US federal policy. After Executive Order 14028, the Office of Management and Budget (OMB) issued memorandum M-22-18 in September 2022, later updated by M-23-16, which required federal agencies to obtain a self-attestation from producers of software they use, confirming conformance with secure development practices drawn from NIST guidance, chiefly the SSDF. The Cybersecurity and Infrastructure Security Agency (CISA) and OMB developed the Secure Software Development Attestation Form, often called the Common Form, released in March 2024. It covers a subset of SSDF practices, is signed by a senior official able to bind the company, and can be submitted through CISA's Repository for Software Attestations and Artifacts. Where a producer could not attest to every practice, agencies could accept a plan of action and milestones (POA&M) describing how and when the gaps would be closed. An assessment by a third-party assessment organisation could support the claims.

Policy then changed. On 23 January 2026 OMB issued memorandum M-26-05, which rescinded M-22-18 and M-23-16. Agencies are no longer required to collect the attestation form, but they may still use it, may ask for SBOMs or other artefacts, and must build their own risk-based software assurance approach. The SSDF itself was not withdrawn and remains NIST's reference for secure development. The practical lesson is that the legal or contractual pull to use the SSDF can change, while the framework and the evidence it encourages keep their value.

Figure 4 – A typical acquirer and producer exchange: expectations in SSDF terms, self-assessment, attestation with artefacts, and a remediation plan where gaps exist.

What good evidence looks like

Assessors and customers trust evidence that is specific, current and hard to fake. Compare two answers to PS.1 (protecting code). "We protect our repositories" is a claim. "All repositories use single sign-on with multi-factor authentication, main branches require reviewed pull requests, force pushes are blocked, and here is last month's access review" is evidence. Good evidence is generated by tools as part of normal work (PO.3), is linked to the specific task, and is retained long enough to answer later questions.

Measuring progress without maturity levels

The SSDF has no maturity levels or scores of its own. Organisations that want a maturity view often combine it with OWASP SAMM, which has maturity levels per practice, or with internal metrics defined under PO.4 such as the share of releases that met all security criteria, the age of open critical findings, or the time from vulnerability report to fix. Keep metrics tied to outcomes; the number of scans run says little about security.

Common assessment questions

Is the scope clear: which products, versions and environments does the claim cover?
For each task marked "not applicable", is there a recorded reason?
Is the evidence from the current release, or from a one-off project two years ago?
Are third-party components covered, or only the code the team wrote itself?
Is there a working vulnerability intake channel, and has it ever been tested?

Lesson 6 – Worked example: a payroll software company adopts the SSDF

The situation

Larkfield Payroll (a fictional company) sells a cloud payroll application and a small desktop agent that customers install to import time-sheet data. It has 60 developers in eight teams, uses a hosted Git service, a shared continuous integration system and a container registry. A large public-sector customer and two banks have asked Larkfield to describe its secure development practices "in SSDF terms". The chief technology officer appoints an application security lead, Priya, to run the project and becomes its executive sponsor.

Step 1 – Scope and definitions

Priya scopes the project to the payroll application, the desktop agent and their shared build pipeline. She writes a one-page glossary: "sensitive data" means personal and salary data plus credentials; a "qualified reviewer" is a security champion or member of the security team; the environments are development, build, staging and production. This takes a day and prevents weeks of confused discussion later.

Step 2 – Current-state assessment

She builds a spreadsheet from the NIST Excel table with one row per task and holds short workshops with each team. The results are mixed. Strong areas: code review on every pull request (PW.7), unit and integration tests (PW.8), and container image scanning. Weak areas: no written security requirements (PO.1); no security training beyond an annual video (PO.2); build servers reachable from the office network with shared administrator accounts (PO.5); releases of the desktop agent not signed (PS.2); no SBOM (PS.3); no threat models (PW.1); default administrator password in the desktop agent (PW.9); and vulnerability reports arriving at a general support address with no defined owner (RV.1).

Step 3 – Target state and priorities

With the CTO, Priya sets a target for each task. Not everything is equal. Because the customers' biggest concern is supply-chain tampering and data exposure, she puts the build environment, code signing, provenance and vulnerability intake first. Threat modelling will start with the two highest-risk features (payroll calculation and bank file export) rather than everything at once. Compiler hardening (PW.6) applies to the desktop agent only, since the web application uses an interpreted language; she records that decision with a short reason.

Step 4 – Implementation, quarter by quarter

Quarter 1 – Foundations. A secure development policy and a list of security requirements are approved (PO.1). Each team nominates a security champion who receives deeper training, and every developer completes role-based secure coding training (PO.2). The build servers are moved to an isolated network, shared accounts are removed, and access requires multi-factor authentication (PO.5). Repository settings now block force pushes and require reviews on protected branches (PS.1).
Quarter 2 – Protect and prove. The pipeline signs the desktop agent and container images, and the release page publishes hashes (PS.2). Each build produces an SBOM, which is stored with the release in a read-only archive (PS.3). A software composition analysis tool checks components on every build and nightly, so newly disclosed vulnerabilities in existing releases are noticed (PW.4).
Quarter 3 – Design and defaults. Champions run threat-modelling sessions for the two high-risk features; the models are reviewed by a security team member who was not part of the design (PW.1, PW.2). The desktop agent now forces the customer to set a strong password on first start, and an administrator guide documents every security-relevant setting (PW.9). Static analysis is added to the pipeline with agreed thresholds: a release fails if a high-severity finding is open without an approved exception (PO.4, PW.7).
Quarter 4 – Respond and learn. Larkfield publishes a vulnerability disclosure policy with a dedicated reporting address and a commitment to acknowledge reports quickly. A small PSIRT is formed with an on-call rota (RV.1). A triage procedure rates each report and records the chosen response (RV.2).

Step 5 – A real vulnerability tests the process

In month eleven, a researcher reports that the bank file export can be manipulated to include another customer's records by changing an identifier in the request. The PSIRT confirms the issue the same day, rates it critical and ships a fix within the agreed time (RV.1, RV.2). Root cause analysis finds that the export service trusted an identifier from the client instead of checking it against the user's session (RV.3). The team searches the code for the same pattern and finds two similar endpoints, which they fix before anyone reports them. They then add an authorisation check to the secure coding standard, add an automated test template for object-level access control, and add "authorisation on every object reference" to the threat-model checklist. The single bug has improved PO.1, PW.1, PW.5 and PW.8 for every future release.

Figure 5 – The Respond to Vulnerabilities life cycle used by Larkfield: confirm, prioritise, remediate, analyse the root cause and change the process.

Step 6 – Answering the customers

At the end of the year Priya produces a conformance statement organised by SSDF task. For each task it states what Larkfield does, points to evidence, and lists the few tasks still in progress with target dates, effectively a plan of action and milestones. The public-sector customer accepts it alongside an SBOM for the current release. One bank asks for an independent review, so Larkfield commissions an external assessor to sample the evidence. Because the evidence comes straight from the tools, the review takes days rather than weeks.

What made it work

Clear sponsorship and a single accountable lead.
Risk-based priorities instead of trying to implement 42 tasks at once.
Recorded reasons for every "not applicable" decision.
Evidence generated by the pipeline, not written after the fact.
Root cause analysis that changed the process, not only the code.

Lesson 7 – Relationship to other standards and frameworks

The SSDF was designed to sit on top of existing work, and its references column is a ready-made map to other documents. Knowing the neighbours helps you decide what to use for what.

Framework	Owner	Main purpose	Relationship to the SSDF
OWASP SAMM	OWASP	Prescriptive maturity model for software assurance, with business functions, security practices and maturity levels.	Useful for measuring maturity and planning improvement; SSDF tasks map to SAMM practices. SAMM gives the levels the SSDF lacks.
BSIMM	Black Duck (formerly part of Synopsys)	Descriptive study of the software security activities real organisations perform.	Lets you compare your activities with peers; heavily referenced in the SSDF table.
IEC 62443-4-1	IEC	Secure product development life cycle requirements for industrial automation and control system components.	A formal, certifiable standard for industrial products; its practices are among the SSDF references.
ISO/IEC 27034	ISO/IEC	Multi-part standard on application security within an organisation's management of information security.	Provides a management-oriented view of application security; referenced by several SSDF tasks.
SLSA	OpenSSF	Levels for software supply-chain integrity, focused on build and source provenance.	Gives concrete, testable levels for parts of PO.5, PS.1, PS.2 and PS.3.
NIST SP 800-53	NIST	Catalogue of security and privacy controls for information systems and organisations.	The SSDF maps tasks to controls such as those in the system and services acquisition family, helping federal and regulated organisations link the two.
NIST Cybersecurity Framework 2.0	NIST	Outcome-based framework for managing an organisation's overall cybersecurity risk.	Same style of common language; SSDF outcomes support CSF outcomes but cover a different responsibility, the building of software.

How the pieces fit

A practical way to think about these documents is by question. "What outcomes should secure development achieve?" is answered by the SSDF. "How mature are we and what should we improve next?" is answered by SAMM or BSIMM. "How do we prove the integrity of our builds?" is answered in depth by SLSA. "Which controls must our system have?" is answered by SP 800-53 or ISO/IEC 27001. "What must an industrial product supplier do to be certified?" is answered by IEC 62443-4-1. The SSDF's references let you move between these answers without starting from scratch.

Community profiles and SP 800-218A

NIST invites communities to create profiles that adapt the SSDF to a sector or technology. Its own first profile, SP 800-218A, adds AI-specific considerations to the SSDF for organisations that develop generative AI and dual-use foundation models, such as protecting training data and model weights and evaluating models for vulnerabilities. If you build AI systems, use SP 800-218A together with SP 800-218, not instead of it.

Secure by design

Government agencies in several countries have promoted "secure by design" and "secure by default" principles that ask vendors to take ownership of customer security outcomes. These principles are compatible with the SSDF: PW.9 (secure defaults), the draft PO.6 encouragement to adopt languages and tools that remove whole classes of flaws, and RV.1 (vulnerability disclosure) are concrete ways of acting on them.

Common pitfalls and best practices

Pitfalls

Treating the SSDF as a checklist. Marking every task "yes" without explaining how the outcome is achieved produces paperwork, not security, and does not survive an informed customer's questions.
Buying tools first. Purchasing scanners before defining requirements, criteria and owners leads to thousands of untriaged findings and frustrated developers.
Forgetting the build environment. Teams secure application code but leave build servers, signing keys and pipeline credentials poorly protected, which is exactly where supply-chain attackers aim.
Ignoring third-party code. Assessing only first-party code while most of the shipped software is open-source components.
Silent "not applicable". Excluding tasks without a recorded reason, so nobody can tell later whether it was a decision or an oversight.
Fixing bugs but not causes. Patching a vulnerability and moving on, so the same flaw reappears in the next feature.
One-off evidence. Producing evidence once for a customer questionnaire and never refreshing it.

Best practices

Start with a scoped, risk-based target. Pick one product, define terms, and set a target for each task that reflects your actual risk.
Integrate, don't bolt on. Put each activity in the existing workflow or pipeline stage where it naturally fits, and automate wherever possible.
Make tools produce the evidence. Configure the toolchain so approvals, scans, signatures and SBOMs are recorded automatically and retained.
Invest in people. Senior sponsorship, role-based training and security champions in each team make the practices last.
Protect the pipeline like production. Isolate build environments, use least privilege and multi-factor authentication, and guard signing keys carefully.
Close the loop. Use root cause analysis to update requirements, coding standards, tests and threat-model checklists.
Speak SSDF to suppliers too. Pass your own requirements to the suppliers of components using the same identifiers you use for customers.
Watch the revision. Track the Version 1.2 work, especially continuous improvement (PO.6) and reliable updates (PS.4), and plan for them early.

Summary and key takeaways

NIST SP 800-218 (SSDF Version 1.1, February 2022) is the current final edition; the Version 1.2 revision was released as a public draft in December 2025 and was not yet final when this course was checked.
The SSDF is a set of high-level, outcome-based practices drawn from existing secure development guidance, meant to be integrated into any SDLC model.
It aims to reduce vulnerabilities in releases, limit the impact of those that remain, and remove root causes.
Its four groups are Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities; Version 1.1 has 19 practices and 42 tasks.
Each practice has tasks, optional notional implementation examples and informative references to other standards.
Adoption should be risk-based: define terms, assess current and target states, prioritise, integrate and automate evidence.
There is no NIST certification; producers demonstrate conformance through self-assessment, attestation, artefacts such as SBOMs and, where needed, plans of action, and the policy requirements behind attestation can change.
The SSDF works alongside OWASP SAMM, BSIMM, SLSA, IEC 62443-4-1 and NIST SP 800-53 rather than replacing them.

Reflection questions

Pick one product you work on. Which three SSDF tasks do you think are weakest today, and what evidence would convince a customer that they had been fixed?
Your team marks the compiler-hardening tasks as not applicable. Write the reasoning you would record, and describe what change in the product would make you revisit it.
How would you divide responsibility for SSDF tasks between your team and a cloud provider whose managed build service you use?
Think of a vulnerability your organisation fixed recently. What was its root cause, and what change to requirements, coding standards, tests or tools would stop the same kind from returning?
If a major customer stopped requiring an attestation tomorrow, which SSDF practices would you keep investing in anyway, and why?