Artifact GuideGLOBALNIST SP 800-218 SSDF

NIST SP 800-218 SSDF implementation playbook

Use SSDF v1.1 as an outcome-focused secure development framework: define the software and SDLC scope, tailor applicable practices by risk, assign responsibilities, and preserve evidence.

SSDF is normally voluntary NIST guidance, not a certification scheme or universal legal requirement. Contracts, procurement rules, agency policy, or other authorities can make selected outcomes or attestations binding in a particular context.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

Overview

NIST SP 800-218 SSDF v1.1 is a core set of high-level practices that a can integrate into any software development life cycle (SDLC). Software acquirers can use the same vocabulary to state expectations and discuss evidence with suppliers. This playbook turns the four practice groups - Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV) - into a practical implementation sequence. The sequence is Sorena's synthesis; NIST does not prescribe an implementation order.

Section 1

Decide the scope, audience, and source of authority first

A useful SSDF scope names the producer, software or service, release family, development and build environments, third-party components, supporting suppliers, and the acquirer or customer expectations being addressed. Do not start from a claim that the whole organization is "SSDF compliant."

NIST says nongovernmental organizations may use SP 800-218 voluntarily. If a federal procurement rule, contract, policy, or customer questionnaire calls for an SSDF-based statement, record that separate authority and its exact scope; the SSDF publication itself does not create a universal certification or self-attestation program.

Producer: integrates applicable SSDF tasks into its SDLC and can explain how the outcomes are achieved.
Acquirer: expresses required or desired secure-development characteristics and evaluates supplier representations in the acquisition context.
Supplier: may provide components, tools, development services, or finished software; its obligations come from the applicable agreement or authority, not from the label alone.
Authority record: identifies whether the work is voluntary improvement, internal policy, contractual assurance, or a specific public-sector requirement.

Sources for this answer

NIST SP 800-218 SSDF v1.1

Sections 1 and 2 identify software producers and acquirers as target audiences, allow nongovernmental voluntary use, and describe distributed responsibility across providers and tenants.

Section 2

Tailor the 19 practices and 42 tasks by risk

SSDF does not prescribe one implementation method. It defines outcomes, tasks, notional examples, and references that teams can integrate into Agile, DevOps, waterfall, or other SDLC models.

Not every practice applies identically to every use case. NIST says selection and implementation can depend on risk, cost, feasibility, applicability, and automatability. A practical tailoring record classifies each task as applicable, not applicable, inherited, supplier-performed, or deferred and explains the decision.

PO | Establish requirements, roles, training, toolchains, check criteria, and protected development environments.
PS | Protect code and other software forms, make release-integrity verification available, and preserve release and provenance records.
PW | Address design risk, verify components, follow secure coding, configure builds, review and test code, and ship secure defaults.
RV | Receive and investigate vulnerability information, assess and remediate vulnerabilities, communicate fixes, and analyze root causes.
Tailoring record | Capture scope, task disposition, rationale, owner, evidence, open gap, approver, and review trigger.

Sources for this answer

NIST SP 800-218 SSDF v1.1

Sections 1 and 2 explain that practices are risk-based, not prioritized, and may vary in degree and formality; Table 1 supplies the 19 practices, 42 tasks, optional examples, and references.

Section 3

Connect tasks to operating evidence

Tie each claim to a named practice, task, software scope, owner, evidence period, and record location. That makes the claim reviewable without suggesting that one artifact proves all of SSDF.

Evidence varies by task. Examples include security requirements, role assignments, training records, toolchain and environment controls, design decisions, code-review and test results, release-integrity information, provenance or component records, vulnerability tickets, advisories, remediations, and root-cause analyses.

Accountable owner and deputy for each SSDF practice group or decision.
Evidence location, record type, version, reviewer, review date, and next review trigger.
Decision rationale showing why the selected depth is appropriate to risk and stakeholder expectations.
Open gaps with target state, priority, due date, and acceptance criteria.
Evidence of monitoring and response for vulnerabilities discovered after release.

Sources for this answer

NIST SP 800-218 SSDF v1.1

Table 1 ties each task to outcomes and notional examples, including records and artifacts that can support implementation claims; the examples are optional rather than a universal evidence list.

Recommended next step

Put this NIST SSDF guidance into practice

Define the software scope, disposition each relevant task, assign owners, and identify the evidence and review trigger for each decision.

Assessment workflow

Open Assessment Autopilot for NIST SSDF

Create cited tasks, evidence requests, and review checkpoints for this NIST SSDF scope.

Explore next step

Talk to Sorena

Review this NIST SSDF scope with Sorena

Check the authority, scope, tailoring decisions, owners, evidence gaps, and next steps.

Explore next step

Section 4

Claims the evidence should not make

An organization-wide label hides the framework's task-level tailoring. Preserve the software boundary, task disposition, responsibility, evidence period, and limitations behind every representation.

Use SSDF identifiers to make representations precise. A statement such as "PW.8.2 is performed for releases in product family A" can be checked against a defined scope. SP 800-218 does not establish a NIST certification program, so do not label an internal mapping "NIST certified" or "NIST approved."

Do not turn NIST guidance or its February 2022 publication date into a statutory deadline.
Do not imply that Appendix A makes EO 14028 requirements universally applicable; it maps SSDF practices to Section 4e topics.
Do not describe an internal mapping as NIST certification or approval.
Do not map controls without documenting the expected outcome and evidence standard.
Do not use one generic assessment result for systems, suppliers, and releases with different risk profiles.

Sources for this answer

NIST SP 800-218 SSDF v1.1

Sections 1 and 2 state that SSDF focuses on outcomes, does not prescribe implementation, and uses risk-based tailoring; Appendix A maps EO 14028 Section 4e topics to SSDF practices and tasks.

Section 5

Run implementation as a release-aware lifecycle

Tie SSDF work to software and releases: tailor tasks at intake, collect evidence in the SDLC, make release decisions, feed vulnerability findings back into development, and reassess after a material change.

Keep a scope and tailoring record, an evidence index, and owned remediation items. These are practical management records, not NIST-issued forms.

Step 1 | Authority and scope | Record why SSDF is being used and identify the producer, software, SDLC, release, environments, components, suppliers, and acquirer needs.
Step 2 | Tailor | Disposition each relevant PO, PS, PW, and RV task with a risk rationale and accountable owner.
Step 3 | Integrate | Put the selected tasks into engineering, build, release, procurement, disclosure, and vulnerability workflows.
Step 4 | Evidence | Link each claim to current operating records and identify inherited or supplier-provided evidence explicitly.
Step 5 | Review | Reassess after material architecture, toolchain, component, supplier, threat, vulnerability, or contractual change.

Sources for this answer

NIST SP 800-218 SSDF v1.1

Sections 1 and 2 support risk-based tailoring, distributed responsibility, integration throughout the SDLC, and feedback across the four practice groups.

Primary sources

References and citations

NIST SP 800-218 SSDF v1.1

doi.org

Referenced sections

Sections 1 and 2 support risk-based tailoring, distributed responsibility, integration throughout the SDLC, and feedback across the four practice groups.

Related guides