NIST SP 800-218

Why does it matter?

NIST SP 800-218 matters because the SDLC models organizations already use, waterfall, spiral, agile and agile with DevOps, say little about security, so secure development practices have to be added to each of them (Section 1). The publication gives three reasons: to reduce the number of vulnerabilities in released software, to reduce the impact when an undetected vulnerability is exploited, and to address root causes so vulnerabilities do not recur. It does not introduce new practices or terminology; it describes outcomes drawn from established standards and guidance, which is why acquirers can use it as a common vocabulary with suppliers (abstract).

Key benefits include:

• A shared vocabulary

Practice identifiers such as PO.1, PS.3 or RV.2 and task identifiers such as PW.7.1 let a producer, an acquirer and an assessor refer to the same expectation (Table 1).

• Outcomes, not methods

Section 1 says the SSDF identifies practices but does not prescribe how to implement them, so it fits any SDLC model and toolchain.

• Shift left by design

Section 1 explains that the earlier security is addressed in the SDLC, the less effort and cost the same level of security requires, and the practices start with the organization before any code is written.

• Traceable to the Executive Order

Appendix A Table 2 shows which practices and tasks address each subsection of Section 4e of EO 14028, the basis of the government's secure software work.

• References for each practice

Every practice lists informative references, from BSA and OWASP SAMM to SP 800-161, SP 800-181 and IEC 62443, so an organization can go to the detail it needs.

How does it work?

Section 2 describes the four groups. Prepare the Organization (PO) makes sure people, processes and technology are ready to perform secure development at the organization level; Protect the Software (PS) protects all components of the software from tampering and unauthorized access; Produce Well-Secured Software (PW) produces software with minimal vulnerabilities in its releases; and Respond to Vulnerabilities (RV) identifies residual vulnerabilities, responds to them and prevents similar ones in future. Table 1 holds the 19 practices: five PO, three PS, eight PW and three RV, each with a statement of its purpose, for example PO.1 Define Security Requirements for Software Development or RV.3 Analyze Vulnerabilities to Identify Their Root Causes.

Each practice breaks into tasks, 42 in all, written as the actions an organization takes, such as PO.1.1 on defining security requirements, PS.3.2 on collecting and sharing provenance data for software release components, PW.7.1 on deciding which human-readable code to review and RV.1.1 on gathering vulnerability information from internal and external sources. Beside each task Table 1 gives notional implementation examples and informative references. Where version 1.1 moved a task, the table says so: PW.3.1 moved to PO.1.3, PW.3.2 to PW.4.4, PW.4.3 to PW.1.3, PW.4.5 to PW.4.1 and PW.4.4, and PW.5.2 into PW.5.1 as an example.

Section 2 also explains how to use Table 1. The practices are a subset of what an organization may need, the order implies no sequence or relative importance, and terms such as sensitive data, qualified person and well-secured are deliberately undefined so each organization defines them for its own environment. The same applies to environment names such as development, build, staging, integration, test, production and distribution; the text asks organizations to enumerate their environments, because securing each one is what prevents an attacker moving from one to another. Appendix C records that PO.5 on secure environments, PO.1.2, PS.3.2 and PW.1.2 are new in this version.

Key Elements

• Prepare the Organization (PO)

PO.1 Define Security Requirements for Software Development; PO.2 Implement Roles and Responsibilities; PO.3 Implement Supporting Toolchains; PO.4 Define and Use Criteria for Software Security Checks; PO.5 Implement and Maintain Secure Environments for Software Development.

• Protect the Software (PS)

PS.1 Protect All Forms of Code from Unauthorized Access and Tampering; PS.2 Provide a Mechanism for Verifying Software Release Integrity; PS.3 Archive and Protect Each Software Release.

• Produce Well-Secured Software (PW)

PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks; PW.2 Review the Software Design; PW.4 Reuse Existing, Well-Secured Software; PW.5 Create Source Code by Adhering to Secure Coding Practices; PW.6 Configure the Compilation, Interpreter and Build Processes; PW.7 Review and Analyze Human-Readable Code; PW.8 Test Executable Code; PW.9 Configure Software to Have Secure Settings by Default.

• Respond to Vulnerabilities (RV)

RV.1 Identify and Confirm Vulnerabilities on an Ongoing Basis; RV.2 Assess, Prioritize and Remediate Vulnerabilities; RV.3 Analyze Vulnerabilities to Identify Their Root Causes.

• Table 1 columns

Practices, tasks, notional implementation examples and references, with moved tasks marked so version 1.0 mappings can be carried forward.

• Appendix A, The SSDF and Executive Order 14028

Table 2 maps the subsections of Section 4e of the Order to SSDF practices and tasks.

• Appendices B and C

Acronyms, and the change log from the v1.0 white paper to version 1.1.

What does it cover?

NIST SP 800-218 is written for software producers, including those whose code is built into hardware, and for the acquirers and consumers who buy or integrate software and want a common basis for conversations with suppliers (abstract and Section 1). It applies to any SDLC model, formal or informal, and to every phase from requirements to vulnerability response. The practices are voluntary for all users; federal agencies were directed to require attestation to them by OMB M-22-18, and that direction ended with OMB M-26-05 on January 23, 2026, which instead asks agencies to keep a complete inventory of software and hardware and set assurance policies that match their risk determinations, with the SSDF as a reference.

What are its objectives?

Section 1 and the abstract state what following the practices should achieve:

To reduce the number of vulnerabilities in released software.

To reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities.

To address the root causes of vulnerabilities and prevent recurrences.

To give software producers and acquirers a common vocabulary for secure development in acquisition and management activities.

To integrate security early in every SDLC model, where it costs least, including securing the development environment itself (PO.5).

Framework in Context

NIST SP 800-218 grew out of Section 4 of Executive Order 14028, after a June 2021 workshop and more than 150 position papers, and Appendix A ties it to the Order. OMB M-22-18 and M-23-16 built the federal attestation program on it, and CISA's attestation form states that it is based on SP 800-218 v1.1; OMB M-26-05 rescinded both memoranda on January 23, 2026 and left the form and SBOM contract terms as options. SP 800-218A (July 26, 2024) profiles the SSDF for generative AI and dual-use foundation models, and SP 800-218 Rev. 1 (SSDF v1.2) is in draft since December 17, 2025. The practices cite SP 800-161 Rev. 1 controls such as SA-4, SA-10 and SR-3 among their references.

Common Framework Mappings

NIST SP 800-218 is commonly mapped to the application security standards and control catalogs its informative references cite, so one set of development evidence can answer several reviews.

Mapped frameworks include:

CIS Controls v8.1

ISO 27001:2022

ISO 27002:2022

MITRE ATT&CK

NIST CSF 2.0

NIST SP 800-160 Vol. 1 Rev. 1

NIST 800-53 Rev.5

OWASP ASVS 4.0