NIST released the initial public draft of Special Publication 800-218r1, Secure Software Development Framework (SSDF) Version 1.2, on December 17, 2025, with the public comment period closing January 30, 2026. The draft was authored in response to Executive Order 14306 and reflects NIST's ongoing effort to converge SSDF, the SSDF Generative AI Community Profile (SP 800-218A), and the supply-chain risk practices that have moved from emerging to expected since SSDF 1.1 published in 2022. By late February 2026, the comment-period feedback was visible on the NIST CSRC site and reveals where industry pushed back, where regulators want SSDF to go further, and which practices are likely to land in the final version.
What is materially new in v1.2 compared to v1.1?
Four substantive shifts. The draft expands Practice PO (Prepare the Organization) tasks to explicitly require software-supply-chain risk management as a foundational program element, not an optional add-on. Practice PS (Protect the Software) tasks now reference signed releases, attestations, and provenance generation by name rather than as conceptual recommendations. Practice PW (Produce Well-Secured Software) adds tasks aligned with the OWASP ASVS 5.0 categories and references CycloneDX/SPDX SBOM emission. Practice RV (Respond to Vulnerabilities) tasks now include explicit references to VEX (Vulnerability Exploitability eXchange) emission and SBOM-based vulnerability matching at runtime. The draft also borrows several tasks from SP 800-218A so that mainstream SSDF and AI-specific SSDF stay aligned.
How does v1.2 integrate with the SP 800-218A AI community profile?
The community profile, finalized as 800-218A, augments SSDF for generative AI and dual-use foundation model development. v1.2 references the community profile pattern explicitly and signals that future community profiles will follow the same structure — a baseline of SSDF practices and tasks enhanced with use-case-specific recommendations, considerations, implementation examples, and informative references. Organizations developing or fine-tuning AI models should treat 218A as additive to 1.2 rather than alternative. The draft makes clear that community profiles are intended to multiply: expect profiles for cloud-native, embedded/IoT, and high-assurance contexts within the next few years.
# SSDF 1.2 draft: Practice PS Protect the Software, indicative task evolution
practice: PS.3 Archive and Protect Each Software Release
tasks:
PS.3.1:
text: |
Securely archive the necessary files and supporting data
to be retained for each software release.
examples:
- Build a SLSA-aligned provenance attestation describing how the
release was produced and store it with the release artifacts.
- Emit a CycloneDX or SPDX SBOM for the release and sign it.
PS.3.2:
text: |
Collect, safeguard, maintain, and share provenance data for
all components of each software release.
examples:
- Use signing technologies such as those provided by Sigstore
to produce verifiable, non-repudiable attestations.
- Publish attestations alongside artifacts in a registry that
supports downstream verification by consumers.
What did the comment period highlight?
Three areas of contention based on submitted comments. First, OSS maintainers and small-vendor associations argued that several "examples" read as effectively normative requirements and asked NIST to clarify that examples are non-binding. Second, AI-aligned commenters asked for tighter integration with 218A so that organizations are not maintaining two parallel SSDF programs. Third, large enterprise security teams pushed for more explicit framework mapping — they want SSDF tasks tagged to corresponding 800-53 5.2.0 controls, ISO 27001:2022 controls, and CISA Secure by Design pledge goals so they can demonstrate one implementation effort across multiple compliance requirements.
How does v1.2 handle vulnerability disclosure and CVE quality?
Practice RV (Respond to Vulnerabilities) received some of the most substantive edits in the draft. The tasks now reference VEX (Vulnerability Exploitability eXchange) emission explicitly, asking producers to publish VEX statements alongside SBOMs so that consumers can distinguish "this component appears in the SBOM and has a CVE" from "this CVE actually applies to our use of the component." The draft also addresses CVE quality, aligning with CISA's Secure by Design pledge goal on CVE accuracy: producers are expected to ensure their CVEs include CWE classification, CVSS scoring, and accurate version-range data. Several commenters during the comment period pushed for tighter language around when a producer should publish a CVE versus rely on a vendor advisory, and that distinction is expected to be clarified before final publication. For organizations operating bug-bounty programs and coordinated disclosure workflows, the v1.2 RV updates align well with existing practice; the main lift is structured VEX emission, which most producers had not yet operationalized.
How does v1.2 interact with SP 800-53 Release 5.2.0?
SSDF practices map to 800-53 controls; the mapping appendix is one of the most-consulted parts of the SSDF document. v1.2 updates the mapping to incorporate the 800-53 5.2.0 additions — notably SI-02(07) Root Cause Analysis, SA-15(13) Logging Syntax, and SA-24 Design for Cyber Resiliency. The result is that an organization implementing SSDF 1.2 effectively produces evidence that maps cleanly to the new 800-53 controls without additional documentation effort. For FedRAMP providers, this is significant: SSDF implementation under EO 14028 attestation requirements continues to be the most efficient path to 800-53 control evidence.
What does v1.2 mean for the Self-Attestation Common Form?
The CISA-administered Secure Software Development Attestation Form, mandated by EO 14028 and Memorandum M-23-16, requires producers selling to federal customers to self-attest to specific SSDF practices. v1.2 changes the upstream framework but does not by itself change the attestation form; CISA will update the form in line with the final v1.2 publication. Producers should expect a refresh of the attestation form's task references within 2-3 quarters of v1.2 finalization. Until then, the existing form remains the authoritative artifact for federal procurement.
How does v1.2 address developer training and security culture?
Practice PO (Prepare the Organization) tasks include developer training expectations, and v1.2 refreshes those tasks to address modern realities. The draft language references training on secure coding for AI-augmented development environments (recognizing that copilot-style tools change what developers produce), supply-chain-aware design thinking (recognizing that dependency choices are security decisions), and incident-response familiarity for developers (recognizing that developers are increasingly involved in production incident response). The draft also addresses security culture: practices that quietly reward "shipping fast at the expense of secure" produce outcomes that no checklist of technical practices can fix. The cultural language is softer than the technical tasks — NIST cannot prescribe culture — but acknowledges that mature SSDF implementation requires organizational practice changes that extend beyond any specific control.
What does v1.2 mean for organizations new to SSDF?
For organizations adopting SSDF for the first time — typically because a contract or procurement requirement made it mandatory — v1.2 is actually a better starting point than v1.1 despite being more comprehensive. The reason: v1.2's examples are aligned with the current tooling ecosystem (SLSA, Sigstore, CycloneDX, SBOM emission, signed releases), so a new adopter implementing the practices ends up with a modern toolchain rather than a 2022-era toolchain. Organizations should not delay SSDF adoption while waiting for v1.2 finalization; the v1.1 practices remain the official baseline until v1.2 publishes, and the migration delta between v1.1 and v1.2 is small enough that work done under v1.1 will largely apply directly to v1.2. The practical adoption sequence is: implement v1.1 practices using v1.2-era tooling, document evidence in formats that survive the version transition, and re-tag the evidence to v1.2 task references when the final version publishes. That approach minimizes rework and produces evidence that maps cleanly across both versions.
How Safeguard Helps
Safeguard's SSDF compliance module supports v1.1 today and the v1.2 draft as an opt-in profile. For each SSDF task, the platform identifies the connected evidence — branch protection telemetry, signed-commit enforcement, build provenance, SBOM emission, vulnerability response timelines — and produces a structured implementation record. As v1.2 finalizes, the task references update automatically and existing customer SSDF implementations are re-mapped without losing historic evidence. Griffin AI generates the narrative implementation text required by the Self-Attestation Common Form, populated from tenant data, so producers complete the form in hours rather than weeks. For organizations that also operate under 800-53 5.2.0 and ISO 27001:2022, Safeguard's cross-framework mapping shows where a single SSDF evidence record satisfies multiple framework controls — eliminating the parallel evidence collection most enterprises had been doing under separate compliance programs.