Framework

NIST SP 800-218A
SSDF Community Profile for generative AI on one operating record

NIST SP 800-218A, published April 2024, extends the NIST Secure Software Development Framework (SP 800-218) to generative AI and dual-use foundation models. The Community Profile preserves the PO, PS, PW, RV practice-group structure of the baseline SSDF and adds AI-specific tasks underneath each group, so producers of generative AI software operate the baseline SSDF and SP 800-218A together on the same operating record. This page covers the practice-group extensions, the evidence the profile expects, where SP 800-218A sits next to ISO/IEC 42001, NIST AI RMF, OWASP AISVS, the OWASP LLM Top 10, the EU AI Act, and the CISA SSDA, the recurring adoption pitfalls, the procurement read, and how a workspace-driven approach turns SP 800-218A into a defensible record rather than a marketing claim.

Get Started Free

No credit card required. Free plan available forever.

NIST SP 800-218A: the SSDF Community Profile for generative AI and dual-use foundation models

NIST Special Publication 800-218A, published in April 2024 as a Community Profile alongside the baseline NIST Secure Software Development Framework (SP 800-218), extends the SSDF practice catalogue to cover generative AI and dual-use foundation models. The profile keeps the SSDF structure (PO, PS, PW, RV across 19 practices and 42 baseline tasks) and adds AI-specific tasks underneath the existing practices, so producers of generative AI software read the baseline SSDF and SP 800-218A together rather than as a substitute. The profile is the NIST-issued secure-development companion for the producer side of the broader AI standards stack that includes ISO/IEC 42001 for the AI management system, NIST AI RMF for the framework-level outcomes, OWASP AISVS for the application-tier verification standard, and the OWASP Top 10 for LLM Applications for the headline risk inventory.

For internal AppSec teams shipping generative-AI features, product security teams owning an AI product surface, AI engineering and AI/ML platform teams operating production models, AI safety and red-team functions running the evaluation pack, GRC and compliance teams mapping the producer side of the AI programme to ISO/IEC 42001 and NIST AI RMF, AI governance committees, and CISOs carrying the audit-committee read against the AI estate, SP 800-218A is the practice catalogue the producer-side engineering evidence reads against. The profile is short relative to the baseline SSDF and is best read once in full; the value over time is the task-level traceability that turns AI secure development from a marketing claim into a defensible operating record.

This page covers the SP 800-218A scope, the practice-group extensions across PO, PS, PW, and RV, the relationship between the profile and the baseline SSDF, the audit evidence the profile expects, where SP 800-218A sits next to ISO/IEC 42001, NIST AI RMF, OWASP AISVS, the OWASP LLM Top 10, the EU AI Act, the CISA SSDA, and CISA Secure by Design, the recurring adoption pitfalls, the procurement read against an AI producer claim, the role-by-role operating model, and how SecPortal carries the operating record without claiming the work the producer organisation owns.

The four practice-group extensions: PO, PS, PW, RV for generative AI

SP 800-218A keeps the baseline SSDF practice-group structure (PO, PS, PW, RV) and extends each group with tasks specific to generative AI and dual-use foundation models. The extensions read against the same identifier shape the baseline uses, so the producer evidence reads against one operating record rather than two. The summary below covers the practitioner-level read of each extension; the full task catalogue and the cross-reference detail is in SP 800-218A Appendix A.

PO extensions: Prepare the AI-producing organisation

SP 800-218A keeps the PO group anchored on people, process, and technology preconditions but extends the inventory and roles to the AI side. The profile expects the producer to name the generative-AI surfaces in scope, the responsible AI engineering and AI safety roles, the foundation-model and dataset acquisition policy, the model-evaluation toolchain, the documented criteria for accepting a third-party model into the production stack, and the documented retention and provenance expectations for training data and model artefacts. The PO extensions are how the rest of the profile becomes operable: PS, PW, and RV all read against the PO baseline the producer commits to.

PS extensions: Protect the AI software and its artefacts

PS reads against source code and release artefacts in baseline SSDF; SP 800-218A extends PS to cover the AI-specific artefacts the producer ships or holds internally. PS.1 protects the source code, the prompt templates, the agent-action definitions, and the model-evaluation harness as integrity-controlled artefacts. PS.2 extends release verification to cover the model artefact integrity, the fine-tuning dataset identity, and the prompt-template version. PS.3 archives the release artefact set per shipped model version so the producer can reproduce, analyse, and respond to issues that arise after release. The PS extensions are the artefact-side discipline downstream consumers, federal buyers, and procurement teams read against when an AI feature ships.

PW extensions: Produce well-secured AI software

PW is the largest group in baseline SSDF and remains the largest in SP 800-218A. The profile extends PW.1 to cover AI-specific design risks (training data poisoning, model adversarial robustness, prompt-injection attack surface, agent-action boundary design, RAG isolation, output-handling rules). PW.4 extends third-party component verification to cover foundation models, fine-tuned model variants, model SDKs, embedding libraries, vector databases, agent frameworks, and any inference-provider relationships. PW.7 extends code review to cover prompt templates, agent-action definitions, retrieval pipelines, and the model-evaluation harness as artefacts the code review reads alongside the application code. PW.8 extends testing to cover prompt-injection coverage, indirect-prompt-injection coverage, output handling, agent-action boundary tests, and the model-evaluation harness as a test workstream. PW.9 extends secure-by-default configuration to the inference endpoint, the safety filter, the rate-limit posture, and the abuse-detection signal.

RV extensions: Respond to AI-specific vulnerabilities

RV reads against the vulnerability response discipline in baseline SSDF; SP 800-218A extends RV to cover AI-specific failure modes. RV.1 extends vulnerability identification to cover prompt-injection reports, safety-evaluation regressions, model-output abuse reports, and inference-provider advisories. RV.2 extends severity assessment, prioritisation, and remediation to cover the model-side fix path (retrain, fine-tune, prompt-template change, safety-filter update) alongside the conventional code path. RV.3 extends root-cause analysis to cover the AI-specific root causes (training data drift, model regression, fine-tuning side effect, agent-action boundary failure, RAG isolation failure, system-prompt leakage) and feeds the result back into PO and PW so the next model version inherits the lesson. RV is where the deployed AI system reconnects to the AI engineering organisation.

Profile vs baseline: what SP 800-218A changes and what it preserves

SP 800-218A is a Community Profile of SSDF, not a stand-alone framework. The points below name what the profile changes relative to the baseline SSDF and what it preserves, so the operating decision (read both together; do not run them as parallel programmes) is unambiguous.

  • SP 800-218A is a Community Profile of SSDF, not a replacement. Producers of generative AI software operate SP 800-218 v1.1 plus SP 800-218A together on the same operating record. The same finding, override, and retest discipline carries both surface types.
  • The profile preserves the PO, PS, PW, RV practice-group structure and the task-level decomposition. The tasks SP 800-218A adds are addressed against the same identifier shape (for example PW.4 with an AI-specific task underneath) rather than introducing a parallel taxonomy.
  • Each SP 800-218A task is paired with a documented rationale: why the task matters for generative AI specifically, what the failure mode looks like, and what evidence type the producer is expected to produce. Producers either implement the task with evidence or document why it does not apply, the same operating rule the baseline SSDF reads against.
  • The profile reads against generative AI and dual-use foundation models as the named scope. Discriminative classifiers, conventional ML pipelines, and analytics models are outside the explicit SP 800-218A scope unless the producer voluntarily extends the profile. The producer makes the scope decision and documents it in the engagement record.
  • SP 800-218A reads alongside the broader AI regulatory and standards stack. ISO/IEC 42001 covers the management system around the AI programme, NIST AI RMF covers the framework-level outcome model, OWASP AISVS covers the application-tier verification standard, OWASP Top 10 for LLM Applications ranks the headline risks, and the EU AI Act sets the regulatory floor for high-risk AI in the EU. SP 800-218A is the secure-development companion for the producer side of those regimes.

Evidence the profile expects to see

A defensible SP 800-218A programme produces a stable AI-specific evidence set as a side effect of the engineering work rather than reconstructed at attestation time. The expectations below cover the producer-side artefacts the profile expects to read against, organised by practice group so the audit and procurement reads can trace a requirement to an artefact.

  • PO baseline evidence: the documented inventory of generative-AI surfaces in scope, the named accountable roles (AI engineering lead, AI safety lead, product security lead, AI governance owner), the foundation-model acquisition policy, the documented criteria for accepting a foundation model into the production stack, the training-data acquisition and retention policy, the model-evaluation toolchain inventory, and the role-based training records for the engineers who write, review, and operate the AI software.
  • PS evidence per release: the source-code repository access policy and integrity verification approach for the AI codebase and the prompt-template repository, the model artefact integrity record (model hash, signed manifest, model card, fine-tuning dataset identity, prompt-template version), the release archive per shipped model version including the model card, the system card, the safety policy, the prompt-template inventory, the evaluation result set, and the AI bill of materials.
  • PW design and threat-modelling evidence: the per-AI-feature design record naming the inference surface, the training and fine-tuning data sources, the RAG isolation boundary, the agent action allow-list, the output-handling rules, the safety-filter posture, and the rate-limit and abuse-detection posture. Each design record reads against the matching PW.1 task identifier so the audit can trace the requirement to the artefact.
  • PW supply-chain evidence: the foundation-model provenance record, the fine-tuning dataset provenance, the AI SDK and library inventory with version, the vector database and embedding-library inventory, the agent framework inventory, the inference-provider relationship inventory, and the SCA evidence for the AI codebase, captured against PW.4 task identifiers.
  • PW review and testing evidence: the code-review evidence per AI-code change (PW.7), the prompt-injection test coverage (direct and indirect via retrieval, tool output, file upload), the indirect-prompt-injection-via-RAG coverage, the agent-action-boundary test coverage, the output-handling test coverage, the safety-evaluation pack (refusal rate, jailbreak resistance, hallucination rate, bias and fairness, safety regression), and the application-tier authenticated DAST and external scanning evidence against the backend the AI sits inside.
  • PW build and configuration evidence: the build configuration for the AI codebase, the secure-by-default inference endpoint configuration, the safety-filter configuration, the rate-limit and abuse-detection configuration, and the deployment provenance record, captured against PW.6 and PW.9 task identifiers.
  • RV intake and response evidence: the AI vulnerability disclosure intake record (prompt injection, output-handling, agent boundary, system-prompt leakage, safety-eval regression, inference-provider advisory), the severity calibration record per finding, the remediation SLA evidence, the retest record on a clean build with the safety regression result, the override record where a finding is deferred or accepted with a named approver and a hard expiry, and the root-cause analysis record feeding back into PO and PW for the next model version.

The same evidence pack reads cleanly under ISO 27001 Annex A 8.25 through 8.34, SOC 2 CC7 and CC8, ISO/IEC 42001 Annex A controls referencing secure development of AI, NIST AI RMF MEASURE function, NIST SP 800-53 SA family, the OWASP AISVS verification chapters at the producer side, and the EU AI Act Article 15 cybersecurity obligation. For the broader artefact discipline around the AI supply chain, the AI bill of materials guide covers the AI BOM artefact PW.4 and PS.3 read against. For the federal attestation read, the CISA Secure Software Development Attestation guide covers the SSDA form, the scope, the signature, and how the SP 800-218A evidence sits under the baseline SSDA submission.

How SP 800-218A sits next to ISO/IEC 42001, NIST AI RMF, AISVS, the EU AI Act, and the CISA SSDA

SP 800-218A is rarely operated in isolation. The profile is the producer-side secure-development practice catalogue that other AI regimes cite, run against, or wrap. The pairings below are a working view, not a buyer comparison: the practitioner question is which standards to operate SP 800-218A alongside, not which to pick instead of it.

SP 800-218A and the baseline NIST SSDF (SP 800-218)

The baseline SSDF is the practice catalogue producers of any software read against. SP 800-218A is the Community Profile that extends the catalogue to generative AI and dual-use foundation models. A producer shipping a non-AI product reads SSDF baseline. A producer shipping a generative AI feature reads SSDF baseline plus SP 800-218A together. A producer with a mixed estate reads both on the same operating record, with the engagement scope declaring which side each piece of work falls on.

SP 800-218A and the CISA Secure Software Development Attestation

The CISA Secure Software Development Attestation (CISA SSDA) is the federal attestation instrument software producers selling into federal civilian agencies sign against the SSDF practices. The SSDA reads against a subset of the full SSDF practice set. Producers of generative AI software shipping into federal buyers carry the baseline SSDA evidence plus the SP 800-218A practice extensions on the same operating record so the SSDA submission is supported by the underlying engineering evidence rather than a parallel claim.

SP 800-218A and ISO/IEC 42001

ISO/IEC 42001 is the AI management system standard for the organisation that builds, deploys, or operates AI. SP 800-218A is the secure-development practice catalogue the producer side of that organisation operates against. The two compose: ISO/IEC 42001 says how the AI programme is governed at the management-system level (policy, leadership commitment, risk management, performance evaluation, continual improvement); SP 800-218A says how the AI software is developed under that governance. Programmes certifying against ISO/IEC 42001 typically use SP 800-218A as the secure-development companion the Annex A controls reference reads against.

SP 800-218A and the NIST AI Risk Management Framework

NIST AI RMF (the AI Risk Management Framework with GOVERN, MAP, MEASURE, MANAGE functions) is the framework-level outcome model for AI risk management. SP 800-218A reads beneath as the secure-development practice catalogue that supplies the developer-side operating depth the AI RMF MAP and MEASURE functions expect. Programmes operating against the AI RMF use SP 800-218A as the implementation companion that names the producer-side practices the framework-level outcomes are evidenced through.

SP 800-218A and OWASP AISVS

OWASP AISVS is the verification standard for AI applications, control by control across training-data governance, model governance, input handling, output handling, RAG, agent boundaries, memory and privacy, and so on. SP 800-218A is the producer-side practice catalogue that builds the software AISVS verifies. The two compose: SP 800-218A says how the producer engineers the AI software; AISVS says how a verification engagement reads the resulting AI application against control-level requirements. Most programmes operate SSDF and SP 800-218A on the producer side and AISVS on the verification side, with the same finding ledger carrying both.

SP 800-218A and the OWASP Top 10 for LLM Applications

The OWASP Top 10 for LLM Applications is a ranked list of the most common LLM-specific risks (prompt injection, insecure output handling, supply chain, data and model poisoning, inadequate monitoring, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, unbounded consumption). SP 800-218A is the secure-development practice catalogue that builds the software where those risks live. A producer reads the LLM Top 10 as the risk inventory and SP 800-218A as the practice catalogue the engineering work executes against to address those risks at production grade.

SP 800-218A and the EU AI Act

The EU AI Act is the EU regulation that classifies AI systems by risk and imposes obligations proportionate to the classification. SP 800-218A reads as the producer-side secure-development practice catalogue that helps a producer evidence the technical obligations the high-risk classification entails. Article 9 (risk-management system), Article 10 (data and data governance), Article 12 (record-keeping), Article 14 (human oversight), and Article 15 (accuracy, robustness, cybersecurity) all read against producer-side engineering evidence SP 800-218A names.

SP 800-218A and CISA Secure by Design

CISA Secure by Design is the voluntary pledge framework for software producers committing to default-secure software products. CISA has extended the secure-by-design principles into AI-specific guidance for AI software producers. SP 800-218A reads alongside as the NIST-issued secure-development practice catalogue that gives the secure-by-design AI commitments their practitioner-side practice depth.

Common adoption pitfalls

The pitfalls below come from the failure modes that recur across producers adopting SP 800-218A for the first time. Each one is recoverable, but each one costs measurable evidence-pack rework when discovered late in the cycle.

  • Reading SP 800-218A as a parallel programme. The profile extends SSDF; it does not replace it. Producers that hold the baseline SSDF evidence in one tool and the SP 800-218A evidence in another rebuild the same operating record twice and lose the cross-citation the audit reads against.
  • Scoping SP 800-218A only to the generative-AI codebase. The profile reads against the full production stack the AI feature ships inside, including the backend the inference endpoint sits behind, the data sources the model can read or write, the tools the agent can call, and the third-party inference provider. A scope that excludes the surrounding stack produces a partial profile and a partial evidence pack.
  • Treating model evaluation as a one-off. SP 800-218A expects the safety-evaluation pack to be a repeatable workstream that runs per model version, per fine-tune, and on a documented cadence. A one-time evaluation at launch satisfies neither RV.2 retest expectations nor the model-version regression discipline the profile reads against.
  • Ignoring the supply-chain identity of the foundation model. PW.4 in SP 800-218A reads heavily against the foundation-model provenance and the inference-provider relationship. Producers that treat the foundation model as a black-box dependency without documented provenance, integrity attestation, or supplier-side security posture leave a measurable evidence gap.
  • Holding the AI-specific findings in a separate ledger from the conventional vulnerabilities. SP 800-218A reads against the same RV practice as the baseline SSDF. Prompt-injection findings, indirect-prompt-injection findings, agent-action boundary findings, and output-handling findings sit on the same findings ledger as SQL injection, broken access control, and dependency CVEs, with the AI-specific category fields and the AI-specific evidence types.
  • Skipping the operating-record discipline at the boundary between the AI engineering team and the AppSec or product security team. SP 800-218A explicitly expects PO to name the responsible roles and the handoff discipline. Producers that run the AI side as a separate function with informal handoffs accumulate audit gaps at the boundary.
  • Citing the profile in marketing material without the underlying operating record. Procurement and federal buyers increasingly ask for SP 800-218A evidence at task-identifier level. A producer claiming SP 800-218A alignment without the operating evidence to back the claim fails the procurement read.
  • Treating SP 800-218A as an AppSec-only concern. The profile pulls in AI engineering, AI safety, data engineering, product security, AppSec, GRC, AI governance, and the executive AI accountable owner. Programmes that run SP 800-218A as an AppSec-only initiative miss the named cross-function roles PO expects.

The procurement read: what a buyer should ask an AI producer

Enterprise buyers, federal civilian agencies, downstream platform integrators, and supply-chain risk teams increasingly read AI producers against SP 800-218A. The criteria below are the practitioner-grade questions a procurement or third-party security review reads against, beyond a general statement of SSDF alignment.

  • Does the producer name SP 800-218A in the secure-development claim, with task-level evidence available on request rather than as a general statement of alignment.
  • Does the producer name the generative-AI surfaces in scope and the surfaces explicitly out of scope, so the claim is bounded and verifiable.
  • Does the producer hold the model artefact integrity record per shipped model version, including model hash, signed manifest, model card, fine-tuning dataset identity, and prompt-template version.
  • Does the producer hold the foundation-model provenance, the inference-provider relationship, the AI SDK and library inventory, and the AI bill of materials as named PW.4 evidence.
  • Does the producer hold the safety-evaluation pack (refusal rate, jailbreak resistance, hallucination rate, bias and fairness, safety regression) per model version with a documented cadence.
  • Does the producer hold the prompt-injection and indirect-prompt-injection test coverage, the agent-action boundary test coverage, and the output-handling test coverage as named PW.8 evidence.
  • Does the producer hold the AI vulnerability disclosure intake record, the AI-specific severity calibration, the retest record on a clean build with safety regression, and the root-cause analysis feeding back into PO and PW.
  • Does the producer hold the baseline SSDF evidence pack alongside the SP 800-218A profile evidence, so the SSDA submission and the procurement read are supported by one operating record rather than a parallel claim.
  • Does the producer hold the cross-framework crosswalk evidence so the SP 800-218A operating record reads cleanly under ISO 27001 Annex A 8.25 through 8.34, SOC 2 CC7 and CC8, ISO/IEC 42001 Annex A, NIST AI RMF MEASURE function, OWASP AISVS verification chapters, and CIS Controls v8.1 Control 16.

Role-by-role operating model

SP 800-218A is a cross-functional programme. The practice extensions name the producer side as the accountable layer, but the operating record reads against AppSec, product security, AI engineering, AI safety, GRC, AI governance, and the security leadership read in coordinated roles. The role-level entry points below name how each function reads the same operating record.

AppSec and product security teams

Own the SP 800-218A practice extensions on the AI feature surface alongside the baseline SSDF programme on the wider application estate. Run the engagement against the inference endpoint, the agent action boundaries, the RAG isolation, the output handling, and the safety-filter posture on the same operating record as the rest of the AppSec work.

AI engineering and AI/ML platform teams

Implement the PW practice extensions during model and prompt development. Carry the model-card, the system card, the foundation-model provenance, the fine-tuning dataset identity, the prompt-template version, the agent-action allow-list, and the RAG isolation evidence on the engagement record so the design and supply-chain evidence is produced by the engineering work rather than reconstructed at attestation time.

AI safety and AI red-team functions

Run the safety-evaluation pack (refusal-rate, jailbreak-resistance, hallucination, bias and fairness, safety regression) on the documented cadence the profile expects. Carry the evaluation outputs as bulk-import-ready CSV finding records on the same workspace so the PW.8 evidence reads alongside the rest of the testing evidence.

GRC and compliance teams

Hold the SP 800-218A practice and task evidence as the producer-side companion to ISO/IEC 42001 Annex A, NIST AI RMF MEASURE function, ISO 27001 Annex A 8.25 through 8.34, SOC 2 CC7 and CC8, and the EU AI Act Article 15 cybersecurity obligation. Run the cross-framework crosswalk against the same operating record so the AI compliance read is reconcilable across regimes.

AI governance committees and accountable AI owners

Read the SP 800-218A operating record as the producer-side technical evidence layer behind the AI governance decision impact tier, the high-risk AI classification, and the executive AI accountability commitment. The committee approves the scope, the level of evidence, and the residual position against the documented operating record rather than against an attestation statement alone.

CISOs and security program owners

Carry the SP 800-218A audit-committee read alongside the baseline SSDF read, so the leadership picture of AI software risk is comparable to the picture of the rest of the software estate, with the same finding ledger, the same SLA discipline, the same override register, and the same audit-evidence pack.

Persona-specific entry points are SecPortal for AppSec teams, SecPortal for product security teams, SecPortal for application security programme leads, SecPortal for security engineering teams, and SecPortal for GRC and compliance teams. CISOs and security program owners read the same operating record through SecPortal for CISOs. For firms specialising in AI and ML security engagements rather than running AI as one of several practices, the AI and ML security consultancies workspace covers the operating model that fits a specialist AI security practice.

Where SecPortal fits in an SP 800-218A operating programme

SecPortal is the operating record for the SP 800-218A producer-side programme. The platform carries the engagement scope, the AI-feature inventory, the model and version in scope, the findings ledger with AI-specific category fields, the override and exception register, the retest record on a clean build, the safety-evaluation pack as bulk-imported finding records, the SAST and SCA evidence on the AI codebase, the authenticated and external scanning evidence against the surrounding stack, the activity log, and the AI-generated leadership summaries, so the engineering work and the operating evidence sit on the same surface rather than across disconnected systems. The capability alignment below names the verified SecPortal capabilities the operating record reads against.

  • Engagement management captures the AI feature in scope, the model and version in scope, the inference endpoint, the retrieval index, the tool set, the foundation-model provider, the rules of engagement, the testing window, and the agreed retest scope as a structured record so the SP 800-218A engagement scaffold is the workflow rather than a contract attachment.
  • Findings management stores each finding with a CVSS 3.1 vector, severity, evidence, owner, and a free-text mapping field for the SP 800-218A task identifier and the OWASP LLM Top 10 category, so the operating record cites the practice the finding evidences.
  • Bulk finding import accepts the prompt-injection evaluation results, the indirect-prompt-injection results, the jailbreak-resistance evaluation results, the bias and fairness evaluation results, and the model-evaluation harness output files as CSV intake with column mapping, so the safety evaluation pack reads against the same finding ledger as the security findings.
  • Code scanning runs Semgrep SAST and dependency analysis against the AI application codebase via the Git provider connection (GitHub, GitLab, Bitbucket), so the PW.4 supply chain evidence (AI SDK dependency hygiene, model-library inventory) is captured against the same engagement as the runtime testing.
  • Repository connections via OAuth for GitHub, GitLab, and Bitbucket carry the source-of-record citation for the PS.1 source-code repository discipline, the PS.2 release verification, and the PW.7 code review evidence on AI-side commits.
  • Authenticated scanning runs DAST modules against the backend the AI application sits inside, with credentials stored encrypted at rest under AES-256-GCM scoped to a verified domain, so the AppSec evidence around the AI feature reads against the same workspace.
  • External scanning covers the public-facing inference endpoint and the public surfaces the AI feature exposes, so the PW.9 secure-by-default configuration evidence and the PW.8 testing evidence around the public surface reads against the same engagement record.
  • Encrypted credential storage (AES-256-GCM scoped to verified domains, with workspace-level rotation through CREDENTIAL_ENCRYPTION_KEY_PREVIOUS) holds the scan credentials used against AI-feature backends and authenticated AI surfaces so the credential lifecycle reads against the PS source-code-protection and PW.4 supply-chain disciplines without leaking secrets into the engagement record.
  • Compliance tracking lets one SP 800-218A engagement satisfy framework mappings to ISO 27001 Annex A 8.25 to 8.34, SOC 2 CC7 and CC8, ISO/IEC 42001 Annex A, NIST AI RMF MEASURE function, NIST SP 800-53 SA family, NIST CSF 2.0 PR.PS and DE.AE, OWASP AISVS verification chapters, OWASP LLM Top 10 mapping, the EU Cyber Resilience Act for products with digital elements, and CIS Controls v8.1 Control 16.
  • AI-assisted report generation composes the executive summary, the technical body, the safety-evaluation summary, and the remediation roadmap from the live engagement and findings, citing the SP 800-218A practice and task identifiers exercised rather than starting from a blank template.
  • Retesting workflows pair each finding to a verification step on a clean build, with the safety-evaluation regression record attached, so the RV.2 closure record carries the full evidence chain.
  • Activity log with CSV export captures every state change to the engagement, the findings, the override decisions, and the retests, so the auditor or federal buyer can reconstruct the SP 800-218A operating record without a multi-team excavation. Retention follows the workspace plan (30, 90, or 365 days) with CSV export for longer-cycle audit retention.
  • Document management for the AI application model card, the system card, the safety policy, the prompt-template inventory, the tool inventory, the AI bill of materials, the DPIA (where required), and the safety-evaluation pack, with version history per artefact and a named custodian per file.
  • Finding overrides for the residual gaps that cannot be closed within one engagement (named approver, scope, cited reason, hard expiry, compensating control, refresh trigger) so the deferral against a PW or RV task is evidenced rather than silent.
  • Continuous monitoring (daily, weekly, biweekly, or monthly cadence per target) keeps the public surfaces around the AI feature under recurring scan coverage so the operating record reads as ongoing rather than as a point-in-time claim.
  • Team management with role-based access (owner, admin, member, viewer, billing) and MFA enforcement at workspace level keeps AI engineering, AI safety, AppSec, product security, GRC, and the AI governance committee on the same operating record with appropriate scoping per surface.

What SecPortal does not do

SP 800-218A is a secure-development practice catalogue for producers of generative AI and dual-use foundation models, and depends on the producer operating AI engineering, AI safety, AppSec, product security, GRC and compliance, and AI governance as coordinated functions. SecPortal is the operating record for the producer-side programme, not the AI development platform, not the model-evaluation harness, not the AI safety service, and not the third-party certification body. The honest scope below reads against the SP 800-218A boundary so the platform commitment is unambiguous.

  • SecPortal is not an AI development platform. The platform does not train models, does not fine-tune models, does not host inference, does not connect to OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure OpenAI Service, Hugging Face Inference Endpoints, Cohere, Mistral, or any other inference provider, and does not serve as an LLM gateway, proxy, or runtime guardrail. The model lifecycle runs where the AI engineering organisation runs it; SecPortal carries the operating record that lifecycle produces.
  • SecPortal is not a model-evaluation harness. The platform does not run lm-evaluation-harness, HELM, BIG-bench, MLPerf, Inspect AI, AI Verify, AISI Inspect, or any other model-evaluation framework. The evaluation runs where the eval infrastructure runs; SecPortal accepts the evaluation result file via bulk finding import as structured records on the workspace so the PW.8 safety-evaluation evidence lands on the same finding ledger as the security findings.
  • SecPortal is not an MLOps platform. The platform does not connect to MLflow, Weights & Biases, Comet, ClearML, Neptune, DVC, Kubeflow, SageMaker, Vertex AI, Azure Machine Learning, or any other MLOps platform. The ML lifecycle is operated where the training and serving infrastructure is; SecPortal carries the SP 800-218A operating record alongside the MLOps record rather than replacing it.
  • SecPortal is not an AI red team service. The platform does not author the prompt-injection corpus, the indirect-prompt-injection corpus, the jailbreak attack scripts, the agent-action attack chains, or the multi-turn safety eval prompts. The red-team workstream is run by the AI safety team or by an external AI red-team provider; SecPortal carries the engagement record, the findings, the retests, and the closure evidence the red team produces.
  • SecPortal does not replace the AI governance committee, the accountable AI owner, the AI safety lead, or the data protection officer. The platform carries the operating record so the programme is durable rather than tribal; the named owner runs the programme, the safety lead authors the safety policy, the AI governance committee approves the decision-impact tier, and the DPO signs off the DPIA.
  • SecPortal does not issue or verify SP 800-218A attestations, ISO/IEC 42001 certifications, EU AI Act conformity assessments, CISA SSDA submissions, or any other third-party certification. Attestation is signed by the producer; certification is performed by an accredited body. SecPortal carries the operating record the attestation reads against and the auditors and assessors review continuously rather than reconstructed at examination time.
  • SecPortal does not ship packaged push connectors into Jira, ServiceNow, Slack, Microsoft Teams, SIEM, SOAR, GRC platforms, or AI-governance platforms. The SP 800-218A findings live on the SecPortal workspace and the wider operational ticketing remains in the systems where the rest of the work is tracked.
  • SecPortal does not provide enterprise SSO, SCIM provisioning, SAML, automated approval routing, or automated risk-acceptance routing. Identity assurance is provided by MFA TOTP enforcement at workspace level and the role-based access model (owner, admin, member, viewer, billing).

Use cases the SP 800-218A operating record reads against

The operational workstreams the SP 800-218A programme reads against already exist as named use cases on SecPortal. The cross-references below name how the producer-side SP 800-218A evidence lands on the existing workspace workflows rather than on a parallel AI-only track.

  • The security onboarding for new applications workflow covers the per-AI-feature onboarding that the SP 800-218A engagement attaches to, naming the PO baseline and the PS, PW, RV deliverables expected from launch.
  • The code review use case covers the SAST and SCA evidence the PW.4 supply chain extension and the PW.7 code review extension read against on AI-side commits, including prompt-template changes and agent-action-definition changes.
  • The dependency vulnerability triage workflow covers the AI SDK, embedding library, vector database, and agent framework supply-chain triage that PW.4 reads against, alongside the conventional dependency triage.
  • The SBOM management and VEX publishing workflow covers the AI bill of materials, the foundation-model provenance, and the inference-provider relationship inventory that PS.3 and PW.4 read against, alongside the conventional SBOM and VEX evidence.
  • The SDLC vulnerability handoff workflow covers the boundary between the AI engineering team, AppSec, and product security that the PO accountable roles name, with the per-finding handoff discipline reading against the same record as the rest of the SDLC.
  • The cross-framework control mapping workflow reads the same SP 800-218A evidence pack across ISO/IEC 42001, NIST AI RMF, ISO 27001, SOC 2, OWASP AISVS, OWASP LLM Top 10, and the EU AI Act so the cross-regime read is reconcilable rather than reconciled per audit.
  • The vulnerability acceptance and exception management workflow covers the override register the RV.2 deferred-risk position reads against, with the named-approver, rationale, hard-expiry, compensating-control, and refresh-trigger fields the profile expects evidence to carry.
  • The security leadership reporting workflow covers the CISO and audit-committee read against the SP 800-218A operating record, with the AI-feature inventory, the AI-specific finding-class breakdown, the safety-evaluation summary, and the override-register summary surfaced alongside the rest of the leadership picture.

Where SP 800-218A sits next to other framework pages

SP 800-218A is the producer-side secure-development profile for generative AI; the adjacent framework pages cover the regimes the SP 800-218A operating record reads alongside. The pages below are the ones AI producer programmes most often read together.

  • The NIST SSDF (SP 800-218) framework page covers the baseline secure-development practice catalogue SP 800-218A extends. Producers of AI software read the baseline plus the profile together on one operating record.
  • The ISO/IEC 42001 framework page covers the AI management system standard. SP 800-218A reads as the producer-side secure-development companion the Annex A controls reference.
  • The NIST AI RMF framework page covers the AI Risk Management Framework. SP 800-218A reads beneath the MAP and MEASURE functions as the producer-side practice catalogue.
  • The OWASP AISVS framework page covers the AI application verification standard. SP 800-218A reads on the producer side; AISVS reads on the verification side; the two compose on the same operating record.
  • The OWASP Top 10 for LLM Applications framework page covers the ranked LLM risk inventory. SP 800-218A reads as the producer-side practice catalogue the engineering work executes against to address those risks at production grade.
  • The CISA Secure by Design framework page covers the default-secure software commitment. SP 800-218A reads alongside as the NIST-issued secure-development practice catalogue that gives the secure-by-design AI commitments their practitioner-side practice depth.
  • The EU Cyber Resilience Act framework page covers the EU product cybersecurity regulation for products with digital elements. SP 800-218A reads as the producer-side secure-development companion for AI features inside CRA-in-scope products.
  • The NIST CSF 2.0 framework page covers the outcome-oriented function model. The PR.PS and DE.AE outcomes read against the producer-side AI evidence SP 800-218A names.

For deeper reading on the disciplines this profile reads against, the NIST SSDF implementation guide covers the practitioner-side rollout of the baseline framework that SP 800-218A sits inside. The AI bill of materials guide covers the supply-chain artefact PW.4 and PS.3 expect for AI software. The secure code review for AI-generated code guide covers the developer-facing review discipline that flows into PW.7 evidence on the AI code path. The MLSecOps implementation guide covers the operating model around the AI security programme the profile fits inside. The AI security posture management explainer covers the consolidated AI-feature finding picture the operating record produces.

Key control areas

SecPortal helps you track and manage compliance across these domains.

PO extensions: Prepare the AI-producing organisation

Name the generative-AI surfaces in scope, the AI engineering and AI safety roles, the foundation-model and dataset acquisition policy, the model-evaluation toolchain, the documented criteria for accepting a third-party model into the production stack, and the training-data retention and provenance expectations. PO is the foundation PS, PW, and RV read against.

PS extensions: Protect the AI software and its artefacts

Extend PS to cover prompt templates, agent-action definitions, the model-evaluation harness, the per-release model card, the system card, the safety policy, the prompt-template inventory, the fine-tuning dataset identity, and the AI bill of materials, with integrity-controlled storage, release-time verification, and per-release archival.

PW extensions: Produce well-secured AI software

Extend PW.1 design to cover AI-specific risks (training data poisoning, prompt-injection attack surface, agent-action boundary design, RAG isolation, output-handling rules). Extend PW.4 supply-chain to cover foundation models, fine-tuned variants, model SDKs, embedding libraries, vector databases, agent frameworks, and inference-provider relationships. Extend PW.7 review and PW.8 testing to cover prompt-injection coverage, indirect-prompt-injection coverage, agent-action boundary tests, and the safety-evaluation pack.

RV extensions: Respond to AI-specific vulnerabilities

Extend RV.1 intake to cover prompt-injection reports, safety-evaluation regressions, model-output abuse reports, and inference-provider advisories. Extend RV.2 to cover the model-side fix path (retrain, fine-tune, prompt-template change, safety-filter update) alongside the conventional code path. Extend RV.3 root-cause analysis to cover AI-specific causes and feed back into PO and PW.

Profile vs baseline: read SSDF and 218A together

SP 800-218A is a Community Profile of SSDF, not a substitute. Producers of generative AI software operate SP 800-218 v1.1 plus SP 800-218A on the same operating record. The profile preserves the task identifier shape and adds AI-specific tasks underneath the existing practice identifiers so the audit and procurement reads cite one operating record rather than two.

Evidence the profile expects

PO baseline records, per-release PS artefacts (model card, system card, AI BOM, prompt-template inventory), PW design and threat-modelling records per AI feature, PW supply-chain records for foundation models and AI dependencies, PW review and testing records including the safety-evaluation pack, PW build and configuration records for the inference endpoint, and RV intake, severity, retest, and root-cause records on the AI-specific finding classes. The same evidence reads cleanly under ISO 27001, SOC 2, ISO/IEC 42001, NIST AI RMF, and the EU AI Act.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Find vulnerabilities before they ship

Repository connections for SAST and SCA

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Encrypted credential storage for authenticated scans

Bulk finding import bring your scanner data with you

Document management for every security engagement

Every action recorded across the workspace

Compliance tracking without a full GRC platform

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Monitor continuously catch regressions early

Run an SP 800-218A programme on one operating record

Carry the PO baseline, the per-release PS artefacts (model card, system card, AI BOM, prompt-template inventory), the PW design and testing evidence (prompt injection, indirect prompt injection, agent action boundary, output handling, safety evaluation), and the RV response record on the same workspace as the baseline SSDF programme, then read it across the CISA SSDA, ISO/IEC 42001, NIST AI RMF, OWASP AISVS, the OWASP LLM Top 10, and the EU AI Act without rebuilding the evidence pack per audit. Start free.

Get Started Free

No credit card required. Free plan available forever.