Enterprise Security in the Agentic AI Era

NIST SP 800-218A — SSDF Community Profile for Generative AI and Dual-Use Foundation Models

11 min read

NIST SP 800-218A — SSDF Community Profile for Generative AI and Dual-Use Foundation Models

NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile — is NIST’s AI-specific extension of SP 800-218 (SSDF v1.1), published July 2024 by Booth, Souppaya, Vassilev, Ogata, Stanley (CISA), and Scarfone. The publication answers Section 4.1.a of Executive Order 14110 (“Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence,” October 2023) which directed NIST to “develop a companion resource to the Secure Software Development Framework to incorporate secure development practices for generative AI and for dual-use foundation models.”

SP 800-218A is the wiki’s federal-anchor citation for secure development practices specific to AI models. It is not standalone — “This Profile supplements what SSDF version 1.1 already includes and is intended to be used in conjunction with it, not on its own.”

What an SSDF Community Profile is

NIST formalizes a Community Profile as a baseline of SSDF practices and tasks that have been enhanced to address a particular use case. The 218A Profile augments the base SSDF with five additions:

  • Recommendations (R) — something the organization should do, AI-specific.
  • Considerations (C) — something the organization should consider doing.
  • Notes (N) — additional contextual information.
  • Priorities — High / Medium / Low indicating relative importance within the AI Profile scope (not present in base SSDF).
  • Informative References — pointers into NIST AI RMF 1.0, OWASP Top 10 for LLM Applications v1.1, and the NIST AI 100-2e2023 Adversarial ML Taxonomy (Vassilev et al.).

Each addition gets a unique identifier appended to the task ID (e.g., PO.1.2.R1 is the first recommendation for task PO.1.2).

Scope and Audience

In-scope: AI model development — data sourcing, designing, training, fine-tuning, and evaluating AI models, plus incorporating AI models into other software.

Out-of-scope: deployment and operation of AI systems with AI models (operational concerns); most parts of the data governance and management life cycle beyond training data security. SP 800-218A is a development-time document, not an operation-time one.

Three audiences:

  • AI model producers — organizations developing their own generative AI or dual-use foundation models.
  • AI system producers — organizations developing software that leverages a generative AI or dual-use foundation model.
  • AI system acquirers — organizations acquiring a product or service that uses one or more AI systems.

A shared-responsibility model is explicit: a single AI capability typically spans all three roles, and acquirer-producer agreements must specify which party owns which practice.

Three new tasks NOT in base SSDF

The Profile introduces three net-new tasks with the explicit tag [Not part of SSDF 1.1]:

Task IDTitlePracticePriority
PO.5.3Continuously monitor software execution performance and behavior in software development environments to identify potential suspicious activity and other issuesPO.5 (Secure Environments)High
PS.1.2Protect all training, testing, fine-tuning, and aligning data from unauthorized access and modificationPS.1 (Protect Code and Data)High
PS.1.3Protect all model weights and configuration parameter data from unauthorized access and modificationPS.1 (Protect Code and Data)High

These three tasks define the wiki’s federal-anchor citation surface for (1) continuous development-environment monitoring as a secure-SDLC practice, (2) training-data integrity as a protected-asset class equivalent to code, and (3) model weights as a protected-asset class equivalent to code.

One new practice NOT in base SSDF — PW.3

PW.3 — Confirm the Integrity of Training, Testing, Fine-Tuning, and Aligning Data Before Use is the Profile’s largest contribution: an entirely new practice within the PW (Produce Well-Secured Software) group. It contains three tasks:

TaskDescriptionPriority
PW.3.1Analyze data for signs of data poisoning, bias, homogeneity, and tampering before using it for AI model training, testing, fine-tuning, or aligning purposes, and mitigate the risks as necessaryHigh
PW.3.2Track the provenance, when known, of all training, testing, fine-tuning, and aligning data used for an AI model, and document which data do not have known provenanceMedium
PW.3.3Include adversarial samples in the training and testing data to improve attack preventionMedium

This is the federal-anchor surface for the entire wiki concept cluster around data poisoning, model-layer attacks, and adversarial-training mitigation. NIST cites OWASP LLM03 (Training Data Poisoning) and the AI 100-2e2023 Adversarial ML Taxonomy as informative references.

High-priority AI-specific recommendations across the rest of the Profile

The Profile attaches High-priority AI-specific recommendations to existing SSDF tasks at multiple points. The wiki-load-bearing additions:

Protect Software (PS) — model weights and AI elements as a protected asset class:

  • PS.1.1.R1 — “Secure code storage should include AI models, model weights, pipelines, reward models, and any other AI model elements that need their confidentiality, integrity, and/or availability protected.”
  • PS.1.1.R3 — “Store reward models separately from AI models and data.”
  • PS.1.1.R4 — “Permit indirect access only to model weights.”
  • PS.1.3.R4 — “Specify and implement additional risk-proportionate cybersecurity practices around model weights, such as encryption, cryptographic hashes, digital signatures, multi-party authorization, and air-gapped environments.”

Protect Software (PS) — provenance for AI models:

  • PS.3.2.R1 — “Track the provenance of an AI model and its components and derivatives, including the training libraries, frameworks, and pipelines used to build the model.”
  • PS.3.2.R2 — “Track AI models that were trained on sensitive data … determine if access to the models should be restricted to individuals who already have access to the sensitive data used for training.” (This is the model-weight-as-PII/sensitive-data inference.)

Produce Well-Secured Software (PW) — AI-specific threat modeling:

  • PW.1.1.R1 — “Incorporate relevant AI model-specific vulnerability and threat types in risk modeling. Examples include poisoning of training data, malicious code or other unwanted content in inputs and outputs, denial-of-service conditions arising from adversarial prompts, supply chain attacks, unauthorized information disclosure, theft of AI model weights, and misconfiguration of data pipelines.”
  • PW.1.1.C2 — “During risk modeling, consider checking that the AI model is not in a critical path to make significant security decisions without a human in the loop.” (Directly anchors the wiki’s human-parity-line argument.)

Produce Well-Secured Software (PW) — input/output handling:

  • PW.5.2 — “Code the handling of inputs (including prompts and user data) and outputs carefully. All inputs and outputs should be logged, analyzed, and validated within the context of the AI model, and those with issues should be sanitized or dropped.” (Federal anchor for prompt-injection-input-validation.)
  • PW.5.3 — “Encode inputs and outputs to prevent the execution of unauthorized code.”

Produce Well-Secured Software (PW) — AI red-teaming named explicitly:

  • PW.8.1.R1 — “Several forms of code testing can be used for AI models, including unit testing, integration testing, penetration testing, red teaming, use case testing, and adversarial testing.” (Federal-anchor citation for AI red-teaming as a recommended SDLC practice.)

Respond to Vulnerabilities (RV) — AI shutdown mechanism:

  • RV.2.2.R2 — “Establish and implement criteria and processes for when to stop using an AI model and when to roll back to a previous version and its components.”
  • RV.2.2.C1 — “Consider being prepared to stop using an AI model at any time and to continue operations through other means until the AI model’s risks are sufficiently addressed.”

These two surface the distributed kill switch concept at federal-policy level — and are the exact analog of one of Microsoft SDL’s six AI focus areas (AI shutdown mechanisms).

Glossary contributions

Appendix A defines several terms that the wiki should treat as canonical anchors for federal-level definitions:

  • artificial intelligence red-teaming — “A structured testing effort to find flaws and vulnerabilities in an AI system, often in a controlled environment and in collaboration with developers of AI.”
  • dual-use foundation model — broad-data training, self-supervised, ≥tens of billions of parameters, applicable across wide range of contexts, exhibits or could be modified to exhibit high performance on tasks that pose serious risk to national security including (i) lowering CBRN-weapon barrier of entry for non-experts, (ii) enabling powerful offensive cyber operations through automated vulnerability discovery and exploitation, or (iii) permitting evasion of human control or oversight through deception/obfuscation.
  • generative artificial intelligence — class of AI models that emulate the structure and characteristics of input data to generate derived synthetic content.
  • model weight — a numerical parameter within an AI model that helps determine the model’s outputs in response to inputs.
  • provenance — metadata pertaining to the origination or source of specified data.

The dual-use foundation model definition is particularly wiki-relevant: criterion (ii) — “enabling powerful offensive cyber operations through automated vulnerability discovery and exploitation” — is the federal-policy frame for the wiki’s Frontier AI for Vulnerability Discovery thesis. The Glasswing concrete-vulnerability disclosures (27-year-old OpenBSD, 16-year-old FFmpeg, autonomous Linux kernel privesc chain) are exactly what this definition anticipated.

Sources of Expertise

The Profile leverages and integrates:

  • NIST research and publications on trustworthy AI: AI RMF 1.0, NIST AI 100-2e2023 Adversarial Machine Learning: A Taxonomy and Terminology (Vassilev et al.), NIST SP 1270 (Bias in AI), Dioptra testbed.
  • NIST SSDF v1.1 itself.
  • NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-161r1 (Cyber Supply Chain Risk Management Practices).
  • NIST AI 600-1 (AI RMF Generative AI Profile).
  • OWASP Top 10 for LLM Applications v1.1.
  • Industry/government experts via NIST’s January 2024 workshop.

Stated Limitations

NIST is explicit about what 218A does not address:

  • “A limitation of the SSDF and this Profile is that they only address cybersecurity risk management.” Other AI risk types — data privacy, intellectual property, bias — need separate frameworks (the Profile points to AI RMF, AI 600-1, NIST SP 1270, Privacy Framework, IR 8286).
  • Model weights and training process tracking is structurally hard. “Source code for defining the model architecture and building model binaries is amenable to secure software engineering practices for versioning, lineage, and reproducibility. However, the final model weights are defined only after the model is trained and fine-tuned; this is where limitations in tracking all aspects of collection, processing, and training data arise.” This is the wiki’s federal-anchored articulation of why model weights need different controls than source code — a load-bearing point for model-layer attacks and the supply chain discussion.
  • Future work: Implementation Examples. The Profile leaves this column empty. NIST signals it “is considering adding a column for Implementation Examples in a future version.”

Adoption Signal

SP 800-218A is federal-mandated under EO 14110. Although the EO 14110 was an executive instrument (subject to revocation), its NIST deliverables — including 218A — remain published as NIST guidance and are referenced in subsequent federal AI procurement guidance. Organizations selling AI models or AI-augmented software to the US federal government are functionally required to demonstrate 218A-aligned practices under the SSDF self-attestation regime (OMB M-22-18 + CISA Secure Software Development Attestation Form).

218A is the federal-anchor analog of Microsoft SDL for AI — but with regulatory teeth

Both documents extend a classical secure-SDLC framework to AI workloads with strikingly convergent scope: training-data integrity, model weights as protected assets, agent identity, observability, threat modeling for AI, and shutdown/rollback mechanisms. The difference is enforcement: Microsoft SDL is a vendor framework; SSDF + 218A is the basis for US federal procurement self-attestation. A vendor publishing to both ecosystems can use Microsoft SDL as the engineering instrument and 218A as the federal-attestation surface.

In the RA / CMM

SP 800-218A is the federal-anchor citation across multiple CMM domains. Specific anchor points:

CMM domain218A anchor
D4 — Threat Modeling & Adversarial DefensePW.1.1.R1 (AI-specific threat modeling); PW.3.3.R1 (adversarial-sample inclusion); PW.5.2/PW.5.3 (input/output handling)
D5 — Data & Memory GovernancePS.1.2 (training data); PS.1.3 (model weights); the PW.3 practice (training-data integrity)
D6 — Supply Chain & Component GovernancePS.3.2.R1/R2 (AI model provenance); PW.4.4.R1 (verify integrity of acquired models)
D7 — Observability & Anomaly DetectionPO.5.3 (continuous monitoring of dev environments); RV.1.1.R1 (log/monitor/analyze inputs and outputs)
D9 — Incident Response & RecoveryRV.2.2.R2/C1 (stop-using-model criteria and rollback)

The CMM’s D8 already cites 218A as the supply-chain reference; this page provides the citation surface for each anchor. The CMM crosswalk should be extended with task-level mappings on the next revision pass.

How this fits the wiki

  • Federal-anchor citation surface for at least 5 CMM domains. Replaces the previous stub that only flagged the gap.
  • First wiki page citing AI red-teaming as a NIST-recommended SDLC practice (PW.8.1.R1). Closes a gap where wiki red-teaming concept pages cited industry sources but not a federal-policy anchor.
  • Documentary support for the wiki’s “model weights ≠ source code” argument — NIST’s explicit acknowledgment that classical secure-development primitives (versioning, lineage, reproducibility) do not cleanly cover model weights is the cleanest federal articulation of the gap.
  • Federal-policy anchor for the Frontier-AI-for-Vuln-Discovery thesis via the dual-use-foundation-model glossary criterion (ii).
  • Anchor for the 2026 framework-stack thesis’s “AI overlay” layer — 218A is precisely what that thesis prescribes as the SSDF-side AI extension.

See also

Graph View

Backlinks