Why does the NIST SSDF state outcomes instead of prescribing tools or maturity levels?

## The design constraint SSDF is aimed at every software producer: a two-person firmware shop, a bank with four hundred internal services, an open-source maintainer, a vendor selling into government. It has to hold across languages, build systems, deployment targets and development methodologies, and it has to stay true as tooling churns. A framework that named tools would be simultaneously too prescriptive for the small shop, too shallow for the bank, and out of date almost immediately. So it states outcomes. ## What a task actually contains Each practice in the document has an ID, a name and a short rationale. Under it are numbered **tasks**, each phrased as something to be done or achieved. Beside the tasks sit two supporting columns: - **Notional implementation examples** - concrete illustrations of one way an organisation might reach the outcome. The word *notional* is doing real work: these are not a checklist and not a minimum. You can satisfy a task with none of them. - **References** - pointers into other published bodies of guidance that describe the same expectation in more depth. SSDF positions itself as a hub over existing material rather than a replacement for it. So the unit of conformance is the task, the target is the outcome, and the method is yours. ## No levels, no certification This is the point candidates most often get wrong, because so many neighbouring frameworks are tiered. SSDF has no maturity levels, no tiers, no scores and no accrediting body. Nobody issues an SSDF certificate. If a supplier tells you they are `SSDF Level 2`, they have either confused SSDF with a maturity model or they are inventing reassurance. The honest formulations are: *self-attested as aligned with SSDF practices*, *assessed against SSDF by a named party on a named date*, or *we have a gap assessment covering these task IDs and here are the open gaps*. What exists instead is attestation. Government software-acquisition attestation requirements are written against SSDF practices, which is how a voluntary framework acquired contractual teeth: a producer signs a statement that certain practices are followed, and the signature - not a certificate - is the thing that carries consequence. ## Risk-based application SSDF expects you to decide which practices apply and how rigorously, based on the risk of the software in question. Internal tooling used by five engineers and firmware controlling a physical process do not warrant the same depth on every task. What the framework does expect is that the decision was *made*, by someone accountable, and recorded - a scoped-out task with a documented rationale is a defensible position; a scoped-out task nobody can explain is a gap wearing a disguise. ## What this changes for an assessment Three consequences follow directly from outcome phrasing: 1. **You cannot assess conformance from a tool inventory.** Two teams satisfy the same code-review task, one by mandatory human review of every change and one by automated analysis with human review of flagged changes. Both may be fine. The assessor has to ask what the outcome is and what shows it happened. 2. **Evidence is the currency.** For each task the useful record is: what is done, what artifact proves it, who owns it, and where it does not happen. That record survives a tool migration, which a tool-named policy does not. 3. **A gap is not a failure grade.** Since there is no score, an assessment output is a set of per-task states and open gaps with owners, not a number. That makes SSDF good at driving improvement and bad at producing a single reassuring figure - which frustrates people who want the figure. ## The trap on the other side Outcome phrasing is also SSDF's weakness, and a strong candidate names it. Because tasks are broad, an organisation can convince itself that a thin practice satisfies one - a linter run nobody reads, a design review that is a calendar invite. Nothing in the framework catches that; only an assessor asking for evidence does. Outcome-based frameworks reward honest self-assessment and are trivially easy to fool when self-assessment is a formality, which is precisely why the attestation regime attached a signature to it.