Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026

NIST SP 800-218, SSDF 1.1, has been final since February 2022. SSDF 1.2, SP 800-218 Revision 1, was released as an initial public draft on 17 December 2025, with comments closing on 30 January 2026, and NIST’s publication register still listed it as a draft on 10 October 2026. Pin the edition used for an assessment and track proposed changes separately. A draft can inform preparation but should not be silently substituted for a contractually selected final baseline. SSDF is guidance whose binding force in a particular setting depends on the applicable contract, policy or legal instrument.

The draft responds to Executive Order 14306 of June 2025 and adds two practices: PO.6, improving development environments, tools and vulnerability response over time, and PS.4, making updates reliable through testing, staged rollout, rollback and resilient update infrastructure. NIST also publishes SP 800-218A (July 2024), a community profile that adds tasks for generative AI and dual-use foundation models, such as protecting training data and model weights from unauthorized access and modification.

SSDF organizes practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. The useful unit of application is a product lifecycle with people, releases and evidence. A company policy may describe intent, while one product’s releases reveal operation. The exercise gives a quarter's evidence for the fictional Birch API. The task is to map each item to the practice it actually supports, without treating a branch rule, a signed artifact or a scanner dashboard as proof of every practice.

For what the draft's PS.4 asks in practice (rollout rings and canaries, content validation and tested rollback), see the staged rollout guide: /domains/supply-chain/releases/staged-rollout-rollback/.

The table lists the 19 practices of SSDF 1.1 by group, with examples of evidence from a single release. PW.3 is absent because version 1.1 merged it into PW.4.

Software sold to US federal agencies was tied to SSDF through a self-attestation requirement that OMB rescinded in January 2026. The sequence matters when a customer contract still quotes the old memoranda.

For a supplier, the practical change is that each agency now sets its own assurance terms. Keep the SSDF evidence anyway: it answers a risk-based questionnaire, an SBOM request or a contract clause as well as it answered the form. /frameworks/secure-software-attestation-form/ walks through the form statement by statement, with the SSDF tasks its appendix maps and the evidence for each.

• May 2021: Executive Order 14028 asks NIST for secure development guidance, published as SSDF 1.1 in February 2022.
• September 2022: OMB M-22-18 requires agencies to collect a producer’s self-attestation of SSDF practices; M-23-16 (June 2023) extends the deadlines.
• March 2024: CISA publishes the Secure Software Development Attestation Form.
• June 2025: Executive Order 14306 asks NIST for a preliminary SSDF update by 1 December 2025 and a final version within 120 days of it.
• January 2026: OMB M-26-05 rescinds M-22-18 and M-23-16. Agencies must keep software and hardware inventories, may still use the attestation form, may require an SBOM on request, and are pointed to SP 800-218 and CISA’s SBOM minimum elements.

Preparation turns expectations into roles, criteria and maintained tools. For Birch, the engineering lead owns release readiness, the security adviser reviews threat assumptions, and an incident lead owns intake routing. Release criteria must say what happens when evidence is missing. A policy that requires review but provides no reviewer or escalation path is not operational. Track tool configuration and training relevant to the risks the team actually handles.

Protection addresses the software and its production inputs. Protected source review, release identity, artifact retention and access control contribute different evidence. A branch ruleset export shows that review is required, not that a given change was reviewed: it records what the system would enforce, not what happened. Sampled merged changes with their approvals are the operating record. Likewise a signed artifact supports authenticity under a trust policy, not a conclusion that reviewers assessed the source. Keep implementation evidence and operating-event evidence separate.

Producing safer software requires translating risks into design and verification work. Birch's tenant-export feature creates a cross-tenant disclosure threat, so a design record should state the tenant boundary and the server-side enforcement rule, as in /domains/appsec/threat-modeling/multitenant-design-review/. Tests should exercise both legitimate and unauthorized access paths. A dependency scan may reveal known package issues but cannot answer whether an application query correctly scopes tenant ownership.

Response begins when a report is received, not when someone eventually chooses to fix it. Record intake time, affected versions, triage, containment, remediation, communications responsibility and root-cause analysis, which RV.1 to RV.3 cover between them; /domains/appsec/vulnerability-response/psirt-operating-model/ sets up that intake. If a cross-tenant defect came from code that skipped a tenant-scoped data-access helper, a useful RV.3 prevention action is an owned shared helper and a regression test, not retraining everyone without evidence of why the defect occurred.

Map each selected practice claim to a concrete record, observation and gap. An assessment can distinguish established process, observed operation, partial evidence and missing evidence without inventing a percentage-complete score. A single release does not establish consistent behavior over time. Sample multiple changes or periods when the claim is that a practice operates repeatedly, and document how the sample was chosen.

A useful output is an improvement plan ordered by consequences and dependencies: first close the live exposure, then repair missing release evidence, then generalize the prevention pattern and assess its adoption. Do not postpone urgent remediation until a maturity exercise is complete. The release-evidence lab (/labs/release-evidence/) offers further practice joining artifacts; the self-contained dossier here is enough to apply SSDF's lifecycle view. All roles and observations are fictional, and the assessment is not an attestation of conformance for a real organization.

Keep the matrix machine-readable, one row per claim, as in the example below for a different fictional product. Draft 1.2 practices sit on their own rows with their own baseline, so they never count toward a 1.1 result.

baseline,practice,claim,evidence_id,evidence_kind,artifact,status,owner
SSDF 1.1,PO.1,Security requirements defined,REQ-12,requirements,,operating,Nia
SSDF 1.1,PS.2,Users can verify releases,SIG-C42,signature,client-4.2.0,operating,Nia
SSDF 1.1,PW.7,Tenant-check changes reviewed,,review record,client-4.2.0,missing,Leon
SSDF 1.1,PW.8,Cross-tenant access tested,T-88,test run,client-4.2.0,partial,Leon
SSDF 1.1,RV.2,Reports fixed by priority,R-31,triage timeline,client-4.2.1,operating,Rae
SSDF 1.2 draft,PS.4,Staged updates with rollback,,release plan,,not assessed,Nia

A short script keeps the matrix honest as it grows. It rejects a practice that is not in the stated edition, including the retired PW.3, a status other than the five allowed, an “operating” or “partial” claim without an evidence ID, and a row without an owner. Run it as python3 check_matrix.py ssdf-evidence.csv; it exits non-zero on any problem.

import csv
import sys

SSDF_1_1 = {
    "PO.1",
    "PO.2",
    "PO.3",
    "PO.4",
    "PO.5",
    "PS.1",
    "PS.2",
    "PS.3",
    "PW.1",
    "PW.2",
    "PW.4",
    "PW.5",
    "PW.6",
    "PW.7",
    "PW.8",
    "PW.9",
    "RV.1",
    "RV.2",
    "RV.3",
}
DRAFT_1_2 = {
    "PO.6",
    "PS.4",
}  # added by the December 2025 draft; keep them out of a 1.1 result
STATUSES = {"operating", "partial", "missing", "not applicable", "not assessed"}


def problems(rows):
    found = []
    for n, row in enumerate(rows, start=2):  # line 1 is the header
        known = SSDF_1_1 if row["baseline"] == "SSDF 1.1" else DRAFT_1_2
        if row["practice"] not in known:
            found.append(
                f"line {n}: {row['practice']} is not a practice in {row['baseline']}"
            )
        if row["status"] not in STATUSES:
            found.append(f"line {n}: unknown status {row['status']!r}")
        if row["status"] in {"operating", "partial"} and not row["evidence_id"]:
            found.append(f"line {n}: {row['status']} needs an evidence ID")
        if not row["owner"]:
            found.append(f"line {n}: no owner")
    return found


if __name__ == "__main__":
    with open(sys.argv[1], newline="") as f:
        issues = problems(list(csv.DictReader(f)))
    print("\n".join(issues) or "matrix OK")
    sys.exit(1 if issues else 0)

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. NIST SP 800-218: SSDF 1.1, final. Version 1.1 (February 2022).
2. NIST SP 800-218 Rev. 1 (SSDF 1.2), initial public draft. SP 800-218 Rev. 1 (initial public draft, December 2025).
3. NIST SSDF project: publications
4. OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security (23 January 2026)
5. Executive Order 14306 (Federal Register, 11 June 2025)
6. NIST SP 800-218A: SSDF community profile for generative AI and dual-use foundation models. July 2024.
7. SLSA 1.2 specification. Version 1.2.

Reference information

Tags

Build integrity and provenanceSecure development lifecycleCompliance and assurance evidence

SDLC phase

ReleaseSecurity program

Role

Security leaders

Download this guide as Markdown

Continue exploring