The NIST Secure Software Development Framework (SSDF), explained

The Secure Software Development Framework (SSDF) is a set of fundamental secure software development practices that the National Institute of Standards and Technology (NIST) publishes as Special Publication (SP) 800-218. Version 1.1 is dated February 2022. In July 2024 NIST added SP 800-218A, a profile for generative artificial intelligence (AI) and dual-use foundation models. From September 2022, Office of Management and Budget (OMB) memorandum M-22-18 required agencies to obtain a producer's attestation to SSDF-based practices before using covered software. OMB rescinded that requirement on January 23, 2026, and a version 1.2 of the framework remains in draft.

The four practice groups

SP 800-218 organizes its practices into four groups, named exactly:

1. Prepare the Organization (PO): people, processes, and technology ready to perform secure development at the organization level.
2. Protect the Software (PS): protect all components of the software from tampering and unauthorized access.
3. Produce Well-Secured Software (PW): produce software with minimal security vulnerabilities in its releases.
4. Respond to Vulnerabilities (RV): identify residual vulnerabilities in releases, respond, and prevent similar ones.

Each practice has a name and identifier, one or more tasks, notional implementation examples, and references to established secure development documents. NIST says no example or combination of examples is required. Appendix A maps the clauses of section 4e of Executive Order (EO) 14028 to SSDF tasks. The clause on giving purchasers a software bill of materials (SBOM), 4e(vii), maps to PS.3.2, which collects and shares provenance data for every component of a release.

What SP 800-218A adds for AI models

SP 800-218A is an SSDF Community Profile written in response to EO 14110, which tasked NIST with a companion resource on secure development for generative AI and dual-use foundation models. The profile is to be used with SP 800-218, not without it. Practices and tasks are unchanged unless tagged "Modified from SSDF 1.1" or "Not part of SSDF 1.1." Each task gets a priority of High, Medium, or Low, and added items are marked as recommendations, considerations, or notes.

The new tasks focus on data and weights:

• PS.1.2 protects training, testing, fine-tuning, and aligning data from unauthorized access and modification.
• PS.1.3 protects model weights and configuration parameters. One recommendation lists risk-proportionate practices such as encryption, cryptographic hashes, digital signatures, multi-party authorization, and air-gapped environments.
• PW.3, Confirm the Integrity of Training, Testing, Fine-Tuning, and Aligning Data Before Use, analyzes data for poisoning, bias, homogeneity, and tampering, tracks provenance where known, and includes adversarial samples in training and testing data.

For PS.2.1, the profile recommends hashes or digital signatures for an AI model and its components, and signatures for model changes.

The attestation: M-22-18 and the common form

M-22-18, dated September 14, 2022, required agencies to obtain a self-attestation from the software producer before using third-party software developed or given a major version change after its effective date. A producer unable to attest to a practice had to identify it, document mitigations, and develop a plan of action and milestones (POA&M). An assessment by a FedRAMP Third Party Assessor Organization (3PAO) could take the place of self-attestation. Agencies could also require an SBOM in solicitations.

The Cybersecurity and Infrastructure Security Agency (CISA) released the form on March 11, 2024. The common form, version 1.0, notes that OMB memorandum M-23-16 updated M-22-18 on June 9, 2023. The form must be signed by the chief executive officer or a designee with authority to bind the company, and it attests to four areas: secure development and build environments, trusted source code supply chains, provenance for internal code and third-party components, and automated vulnerability checks with a vulnerability disclosure program. Out of scope are agency-developed software, open source software an agency obtains freely and directly, third-party components incorporated into the product, and freely available public software. Willfully false information may violate 18 U.S.C. 1001.

Where things stood in October 2026

OMB memorandum M-26-05, dated January 23, 2026, rescinded M-22-18 and M-23-16. Agencies must still keep a complete inventory of software and hardware and set assurance policies that match their risk. They may choose to use the attestation form, may require a current SBOM upon request, and are pointed to SP 800-218. CISA's form page now carries an archive notice.

EO 14306 of June 6, 2025 told NIST to publish a preliminary SSDF update by December 1, 2025 and a final version within 120 days of the preliminary one. NIST posted SP 800-218 Revision 1, SSDF version 1.2, as an initial public draft on December 17, 2025, with comments due January 30, 2026. On October 21, 2026, that CSRC page lists only the draft.

What to check

• Which SSDF version does a claim rest on: version 1.1 of February 2022, or the version 1.2 draft of December 17, 2025?
• For an AI model, does the producer address PS.1.3 on model weights and PW.3 on training data integrity?
• Does this solicitation require an attestation, now that M-26-05 leaves the choice to each agency?
• If a producer offers the common form, who signed it, and which products and versions does it cover?
• How does the producer handle third-party components, which fall outside the form's scope?
• Does the contract require a current SBOM upon request?

Azcuna's ELLMENT, the E-2D Large Language Model Entity, was proposed to NAVAIR PMA-231 under Navy SBIR Phase I topic DON26BZ01-NV010. The prototype, built at private expense on publicly available doctrine, answers with a page-level citation and refuses when the documents do not support an answer. The proposal has been submitted.

Sources

1. 1NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities · National Institute of Standards and Technology, February 2022
2. 2NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile · National Institute of Standards and Technology, July 2024
3. 3NIST SP 800-218 Rev. 1 (Initial Public Draft), SSDF Version 1.2 · NIST Computer Security Resource Center, December 17, 2025
4. 4Executive Order 14306 of June 6, 2025, Sustaining Select Efforts to Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144 · Federal Register, Vol. 90, No. 111 (June 11, 2025), via govinfo.gov
5. 5M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices · Office of Management and Budget, September 14, 2022 (archived White House site)
6. 6Secure Software Development Attestation Form · Cybersecurity and Infrastructure Security Agency
7. 7Secure Software Development Attestation Form, Version 1.0 (common form) · Cybersecurity and Infrastructure Security Agency, OMB Control No. 1670-0052
8. 8M-26-05, Adopting a Risk-based Approach to Software and Hardware Security · Office of Management and Budget, January 23, 2026

Where this shows up in our work

• ELLMENT, the offline LLM for E-2D crews answers a crew's question from the aircraft's own manuals and cites the page, with no network.
• BABEL, offline multilingual translation and search translates and searches foreign-language documents on-device, every fact tied to its source passage.
• TRACE, the offline S1000D and IETM viewer opens S1000D, MIL-STD-3001 and PDF technical manuals on a tablet with every marking intact.