Apply secure-development practices to the AI model lifecycle, not only the application

NIST's SSDF community profile adds AI-model-specific considerations to the broader secure-development framework. Include data, model, evaluation, release, integration, and response paths in scope.

A controlled technology lifecycle progressing from assessment to approved production.
DSE visual intelligenceManaged IT operationsGuide · 3 min read
Executive summary

What you need to know

NIST's SSDF community profile adds AI-model-specific considerations to the broader secure-development framework. Include data, model, evaluation, release, integration, and response paths in scope.

Potentially affected

Producers, integrators, acquirers, and operators of generative AI or dual-use foundation models and the systems that depend on them.

DSE recommendation

Extend secure-development ownership and evidence across model data, artifacts, evaluations, dependencies, releases, integrations, monitoring, and withdrawal; do not treat the model as an opaque dependency outside change control.

Bottom line: an AI-enabled application can inherit risk from the model and its development lifecycle even when the surrounding application follows conventional secure-development practices. Treat model data, code, weights, evaluations, packaging, release, integration, monitoring, and retirement as governed production assets.

Source fact: what the NIST profile adds

NIST SP 800-218A is a community profile that augments the practices and tasks in SSDF version 1.1 with AI-model-specific practices, tasks, recommendations, considerations, notes, and references. NIST identifies producers of AI models, producers of systems that use those models, and acquirers of those systems as intended audiences. The profile is designed to be used together with SP 800-218, not as a replacement for it.

The publication’s scope is generative AI and dual-use foundation model development across the software development lifecycle. That supports widening normal software-assurance work to include model-specific assets and processes.

What the source does not establish

The profile does not certify a model, declare an AI system safe, or guarantee that an evaluation predicts every production behavior. It does not eliminate the need for use-case risk assessment, privacy review, security architecture, human oversight, supplier diligence, or incident response.

It also does not establish that every AI feature warrants the same controls. Applicability depends on whether the organization develops a model, fine-tunes one, retrieves data for one, integrates an external service, or only consumes a bounded feature—and on what decisions or actions the system can influence.

Applicability questions

  • Which party owns the base model, adaptations, data, evaluation harness, application, and operating service?
  • Which artifacts can change behavior, and how are their versions and provenance recorded?
  • What sensitive, regulated, customer, or licensed material can enter training, tuning, retrieval, prompts, or logs?
  • Which evaluations must pass for the intended use, and what conditions fall outside those tests?
  • How can a model, adapter, tool, data source, or release be disabled or rolled back?

DSE recommendation: extend the evidence chain

The following steps are DSE recommendations based on the cited source.

  1. Draw the complete model-system lifecycle, including data sources, preparation, training or tuning, model registry, evaluations, packaging, external services, retrieval sources, tools, deployment, monitoring, and retirement.
  2. Assign owners and immutable identifiers to consequential artifacts. Record provenance, approvals, dependencies, licenses, integrity checks, and the environment in which an evaluation ran.
  3. Define release criteria tied to the intended use. Include security, privacy, abuse, reliability, and operational tests without presenting any single test as proof of universal safety.
  4. Constrain integrations around the model. Apply current identity and authorization at tool and data boundaries, validate outputs before consequential use, and keep approval outside the model for high-impact actions.
  5. Monitor for changes in behavior, dependencies, provider terms, source permissions, and observed incidents. Give alerts an owner and response path.
  6. Practice withdrawal: revoke access, disable a tool or model version, preserve evidence, restore a prior release, and notify affected owners.

Verification and evidence

Select one production AI feature and trace its model and application versions, data and dependency records, evaluation results, approvals, deployment record, permission tests, monitoring, known limitations, and rollback rehearsal. Record gaps as owned work rather than converting uncertainty into a claim of assurance.

Official references

Primary reference

Review the official source

NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models · Published July 26, 2024

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE