NIST SSDF Practices

## What the SSDF is NIST Special Publication 800-218, the Secure Software Development Framework (SSDF), is a compact catalogue of secure-software-development *outcomes*. It is deliberately not a methodology, not a tool list and not a maturity model: it is a common vocabulary that a producer, a customer and an assessor can all point at when they argue about whether software was built responsibly. It matters far beyond NIST readers because government software-acquisition attestation requirements are written against SSDF practices, and because customers now quote practice IDs directly in questionnaires. The catalogue is arranged in four groups, and the split itself is the thing to understand: two of the groups are about the organisation and the artifact, one is about the code, and one is about life after release. ## PO - Prepare the Organization PO answers the question 'is this company set up to build software securely at all?' Its practices cover: - **PO.1** define security requirements for software development, and keep them current. - **PO.2** implement roles and responsibilities - somebody is named, trained and accountable. - **PO.3** implement supporting toolchains, and secure the toolchains themselves. - **PO.4** define and use criteria for software security checks - what has to pass, what evidence is gathered. - **PO.5** implement and maintain secure environments for software development, which is where build and development environment integrity lives. PO is the group teams most often leave blank, because none of it is visible in a repository. A team can be doing excellent engineering with no PO at all, and that is a real gap: nothing about it is defined, owned or repeatable across teams. ## PS - Protect the Software PS is about the artifact and the code as objects that can be tampered with: - **PS.1** protect all forms of code from unauthorised access and tampering. - **PS.2** provide a mechanism for verifying software release integrity - the outcome that artifact signing exists to serve. - **PS.3** archive and protect each software release, so that what you shipped can be produced again and inspected later. Note the direction of PS.2: it is about giving the *consumer* a way to check that what they received is what you released. SSDF states the outcome; how you achieve it is your choice. ## PW - Produce Well-Secured Software PW is the engineering group and the largest one. It covers designing software to meet its security requirements, reviewing that design, reusing existing well-secured software rather than writing risky code yourself (PW.4, which is where third-party component acquisition sits), writing source code to secure coding practices, configuring the compilation and build process to improve executable security (PW.6), reviewing or analysing human-readable code (PW.7), testing executable code, and shipping with secure settings by default. This is the group an engineer intuitively recognises, and the reason many people wrongly believe SSDF is 'a secure coding standard'. PW is one quarter of it. ## RV - Respond to Vulnerabilities RV covers what happens after the software is in someone else's hands: - **RV.1** identify and confirm vulnerabilities on an ongoing basis - including reports arriving from outside. - **RV.2** assess, prioritise and remediate them. - **RV.3** analyse vulnerabilities to identify root causes, and feed those back into PO and PW. RV is an organisational capability, not a code property. A team can score green on everything it can see in its own repository and blank on RV simply because there is no channel through which an outside finder can reach an engineer. ## How the document is structured Each practice has a name, an ID and a short explanation of why it matters. Under it are numbered **tasks** (PO.5.1, RV.2.1, and so on), each stating an action or outcome. Alongside the tasks the document gives **notional implementation examples** - illustrations, not requirements - and **references** into other published documents that describe the same expectation in more detail. When somebody cites 'PW.7.2' at you, they mean a specific task, and the task ID is the unit that a gap assessment and an attestation are both written against. ## Common confusions The groups are not sequential phases; PO and RV are continuous, and PS spans the whole life of a release. There are no levels, tiers or scores - SSDF says nothing about how mature you are, only whether an outcome is achieved and evidenced. And the framework is intentionally silent on tooling: two organisations can satisfy the same task in completely different ways, which is exactly why assessment turns on evidence rather than on a tool inventory.