NIST SSDF (SP 800-218): the four practice groups, explained

NIST's SSDF project page organises every practice under four groups, each with its own stated purpose:

Read in order, the groups form a lifecycle: PO prepares the organisation, PS keeps the source and build pipeline trustworthy, PW holds the day-to-day secure-coding, design and testing practices, and RV closes the loop once a vulnerability is found after release.

The SP 800-218 version 1.1 document defines 19 practices, broken down into 42 tasks. Each task comes with notional implementation examples and a reference column that points to other frameworks, including IEC 62443-4-1. The right-hand column is our reading for a firmware team, not NIST text.

The numbering skips PW.3: in version 1.1, "Verify Third-Party Software Complies with Security Requirements (PW.3)" was moved into PW.4, and its tasks now live under PW.4.4 and PO.1.3.

NIST's SSDF project page states that SP 800-218 includes explicit mappings from Executive Order 14028, "Improving the Nation's Cybersecurity," Section 4(e) clauses, to the SSDF practices and tasks that address each provision. That mapping is what ties a voluntary NIST framework to US federal software procurement in practice: agencies and the vendors that sell software to them use the SSDF as the reference point for the secure-development practices EO 14028 calls for.

The attestation layer on top has changed. OMB memorandum M-22-18 required agencies to "obtain a self-attestation from the software producer before using the software," which led to CISA's common form (see our guide to the Secure Software Development Attestation Form). On 23 January 2026, OMB memorandum M-26-05 rescinded M-22-18 and its companion M-23-16. Under M-26-05, agencies "may choose to use" the attestation form, may require a current SBOM by contract, and can reference SP 800-218 among other resources. For a supplier, SSDF stays the shared vocabulary; whether a signed attestation is needed now depends on the individual contract.

NIST published SP 800-218 Revision 1, the initial public draft of SSDF version 1.2, on 17 December 2025; its comment period closed on 30 January 2026. NIST's announcement describes "new and improved practices, tasks, and examples for the secure and reliable development, delivery, and improvement of software," and the page lists Executive Order 14306 under laws and regulations. As of this update, version 1.1 remains the final publication, so cite v1.1 task IDs in evidence and contracts, and re-check them when the final Revision 1 is published: a revision can move tasks, as version 1.1 did with PW.3.

In July 2024, NIST published SP 800-218A, "Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile." It is a companion, not a replacement: NIST states it "should be used in conjunction with" SP 800-218, adding practices and tasks specific to the development lifecycle of AI models. It matters to device makers only if they train or ship such models.

SSDF is tool-neutral, so each task needs translating into your build system. The table maps the build-relevant tasks to mechanisms Yocto (BitBake) and Buildroot already provide. The task column condenses SP 800-218 wording; the mechanism and evidence columns are SoftWSP's interpretation, not NIST guidance.

Sources: NIST SP 800-218 v1.1 task table; Yocto Project and Buildroot manuals, read 2026-11-10.

Two BitBake settings cover a lot of PW.4 and PS.3 cheaply. According to the BitBake fetcher documentation, BB_STRICT_CHECKSUM turns any download without a checksum into an error, and BB_NO_NETWORK makes any network access fatal, which is useful for checking that a source mirror is complete. Buildroot's equivalent is the per-package .hash file: the Buildroot manual says it must be added whenever hash checking is possible, and it validates both the downloaded sources and the licence files. make source downloads everything first so the build itself can run offline.

SBOMs appear in SSDF by name. Task PS.3.2 asks producers to "collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM])", and its first example is making that data available to acquirers "preferably using standards-based formats." PW.4.4's examples include regularly checking components for publicly known vulnerabilities, and RV.1.1 starts with monitoring vulnerability databases. All three need a component list that matches what actually shipped.

For firmware, that list comes from the build system, from the finished binary, or ideally both, since the binary also shows prebuilt vendor libraries the recipes never describe. Our guide to Yocto and Buildroot SBOMs vs firmware image scanning compares the two, and firmware SBOM: building one when you don't have the source covers the binary side. The release-integrity tasks, PS.2.1 and PS.3.1, are where build provenance comes in: see SLSA supply-chain levels and the in-toto attestation framework.

SSDF is NIST's named set of practices and tasks (PO, PS, PW, RV) that a team maps its lifecycle against, with a direct line to EO 14028. Secure by Design is CISA-led guidance built around three principles and a voluntary pledge to seven measurable goals, with no PO/PS/PW/RV structure; see CISA Secure by Design: principles and the pledge, explained. The two are complementary: SSDF for lifecycle practices, Secure by Design for principles and a public commitment.

SP 800-218's reference column already cites IEC 62443-4-1 requirement IDs for many tasks: PS.1.1 points to SM-6, SM-7 and SM-8; PS.2.1 to SM-6, SM-8 and SUM-4; RV.1.3 to DM-1 through DM-5. A device maker already assessed against IEC 62443-4-1 can reuse much of that evidence for an SSDF mapping, and the reverse.

The EU Cyber Resilience Act does not name SSDF. Its essential requirements in Annex I are what a product with digital elements must meet, and SSDF evidence can feed the technical documentation that shows it. Any SSDF-to-CRA mapping is the manufacturer's own analysis, not an official crosswalk.

• Treating SSDF as a certificate. SP 800-218 is a set of recommendations, and NIST does not certify conformance.
• Policies without artifacts. PO.3.3 asks for tools that generate artifacts. If the build leaves no log, SBOM or signature per release, the practice exists only on paper.
• An SBOM from the build tree only. Prebuilt vendor libraries, bootloaders and modem blobs often bypass the recipes; compare against an image-derived SBOM.
• A signing key the build can read. If any build step can reach the key, a compromised dependency can sign its own payload. Keep signing in a separate service.
• An archive without sources. Rebuilding a five-year-old release for a security fix needs the exact source tarballs and layer commits, not only the image (PS.3.1).
• One SBOM per product instead of per release. PS.3.2 says "each software release"; an SBOM for 4.1 tells you nothing about 4.2.