NIST SP 800-218A (generative AI SSDF profile), explained

NIST SP 800-218A, "Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile," is NIST's companion resource adding AI-model-specific practices and tasks on top of its Secure Software Development Framework (SP 800-218). Published July 2024 (DOI 10.6028/NIST.SP.800-218A) and authored by a team spanning NIST's Computer Security and Applied Cybersecurity Divisions, CISA, and Scarfone Cybersecurity, it exists to satisfy a specific legal mandate. Its own Section 1 states: Section 4.1(a) of Executive Order 14110, "Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence," tasked NIST with "developing a companion resource to the Secure Software Development Framework to incorporate secure development practices for generative AI and for dual-use foundation models" — and, in the document's own words, "This document is that companion resource."

A Profile, not a replacement

The document is explicit that it does not stand alone: "This Profile supplements what SSDF version 1.1 already includes... and should not be used without SP 800-218." An SSDF Community Profile, in NIST's terminology, is "a baseline of SSDF practices and tasks that have been enhanced to address a particular use case" — here, AI model development. Concretely, the Profile walks through every one of SP 800-218's existing practices and tasks and tags each row in its Table 1 as one of three states: unchanged from SSDF 1.1 (the majority, where a "No additions to SSDF 1.1" note simply points back to the base framework), "Modified from SSDF 1.1" (the task itself was adjusted), or "Not part of SSDF 1.1" (a wholly new task). Every retained or modified task also carries one of three priority tags — High ("critically important for AI model development security compared to other tasks"), Medium ("directly supports AI model development security"), or Low ("beneficial... but is generally not more important than most other tasks") — meant as "a starting point for organizations to assign their own priorities," not a fixed ranking.

Three audiences, one scope boundary

The Profile names three primary audiences in its own Audience section: AI model producers (organisations developing their own generative AI or dual-use foundation models), AI system producers (organisations building software that leverages such a model), and AI system acquirers (organisations acquiring a product or service built on one or more AI systems). Its Scope section draws a hard line around what that audience should expect to find: "This Profile's scope is AI model development, which includes data sourcing for, designing, training, fine-tuning, and evaluating AI models, as well as incorporating and integrating AI models into other software. Consistent with SSDF version 1.1 and EO 14110, practices for the deployment and operation of AI systems with AI models are out of scope." Runtime risks in a deployed AI system or AI-powered agent — prompt injection, excessive agency, insecure plugin design — sit outside this document; see our MCP server security and OWASP Top 10 for LLM Applications guides for that layer instead. The Profile also notes that "the rest of the data governance and management life cycle is out of scope" beyond the cybersecurity-relevant parts of training-data handling, and that it covers "only... cybersecurity risk management," pointing to NIST's separate AI Risk Management Framework for privacy, bias and other AI risk types.

What's actually new: protecting weights and training data

Most of the Profile's value sits in a small number of genuinely new or materially modified entries layered onto the existing SP 800-218 practice PS.1 ("Protect All Forms of Code From Unauthorized Access and Modification"):

Task	Status	What it requires
PS.1.1	Unchanged task, AI-specific recommendations added	Least-privilege code storage now explicitly extends to "AI models, model weights, pipelines, reward models, and any other AI model elements" needing confidentiality/integrity/availability protection, stored separately from reward models where feasible.
PS.1.2	Not part of SSDF 1.1 — High priority	"Protect all training, testing, fine-tuning, and aligning data from unauthorized access and modification." Recommends continuous monitoring of that data's confidentiality (for non-public data) and integrity.
PS.1.3	Not part of SSDF 1.1 — High priority	"Protect all model weights and configuration parameter data from unauthorized access and modification." Recommends keeping weights separate from training data, continuously monitoring confidentiality of closed-model weights, and applying "risk-proportionate cybersecurity practices around model weights, such as encryption, cryptographic hashes, digital signatures, multi-party authorization, and air-gapped environments."
PW.3	New practice (plus tasks PW.3.1–PW.3.3)	"Confirm the Integrity of Training, Testing, Fine-Tuning, and Aligning Data Before Use." Task PW.3.1: "Analyze data for signs of data poisoning, bias, homogeneity, and tampering before using it for AI model training, testing, fine-tuning, or aligning." PW.3.2 tracks data provenance where known; PW.3.3 includes adversarial samples in training/testing data.

The Profile's own introduction frames why these additions matter: AI development "blurs traditional boundaries between system code and system data," training sets "may be acquired from unknown, untrusted sources," and model weights "can be susceptible to malicious tampering" — risks that a conventional software supply chain checklist doesn't name directly.

The EO 14110 definition that sets the Profile's reach

Because the Profile's audience and mandate both turn on the term, its glossary reproduces the Executive Order's own definition of a dual-use foundation model verbatim: an AI model "trained on broad data," that "generally uses self-supervision," "contains at least tens of billions of parameters," is "applicable across a wide range of contexts," and "exhibits, or could be easily modified to exhibit, high levels of performance at tasks that pose a serious risk to security, national economic security, national public health or safety" — for example by "substantially lowering the barrier of entry for non-experts" to build CBRN weapons, "enabling powerful offensive cyber operations through automated vulnerability discovery and exploitation," or "permitting the evasion of human control or oversight through means of deception or obfuscation." Pointedly, the definition adds that "models meet this definition even if they are provided to end users with technical safeguards that attempt to prevent users from taking advantage of the relevant unsafe capabilities" — scale and latent capability decide scope, not the presence of a safety layer.

Where it draws on other NIST and OWASP work

The Profile cross-references entries to NIST's AI Risk Management Framework and the separate "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations" report for most PW and RV tasks, and its Informative References column maps individual tasks to specific entries in the OWASP Top 10 for LLM Applications (version 1.1) — for example, task RV.2.2 ("Plan and implement risk responses for vulnerabilities") carries a note that AI model risk responses "should consider the time and expenses that may be associated with rebuilding them," a cost dimension that doesn't apply to patching conventional source code.

A workable starting point

1. Read it alongside SP 800-218, not instead of it. The Profile only makes sense layered onto the four base practice groups covered in our NIST SSDF guide; it assumes you already have PO/PS/PW/RV practices and is additive.
2. Prioritise the two new PS.1 tasks and PW.3 first. They are the Profile's High-priority, genuinely new material — protecting training data and model weights, and screening data for poisoning before it is used.
3. Respect the scope boundary. If your risk is a deployed model misbehaving in production — prompt injection, jailbreaks, unsafe tool calls — this Profile explicitly doesn't cover it; pair it with our MCP server security and LLM Top 10 guides for that layer.
4. Use the priority tags as a starting conversation, not a verdict. NIST frames High/Medium/Low as "a starting point for organizations to assign their own priorities" based on their own risk, cost and feasibility factors.
5. Treat "dual-use foundation model" as a scale threshold, not a product category — tens of billions of parameters and broad applicability, regardless of any safety mitigations layered on top.

SoftWSP's device and firmware security reviews can factor AI model components — training pipelines, model weights, fine-tuning data — into the same secure development lifecycle assessment as the rest of a product's firmware: see Device & Firmware Security.

This guide summarises NIST SP 800-218A's own text (abstract, Introduction, Scope, Table 1 and Appendix A glossary, read directly from the published PDF) and its companion SP 800-218; it is not a substitute for the full publication and does not constitute compliance or legal advice.