NIST SSDF and SP 800-218A Crosswalk
Purpose: Let a team that organises secure development around the NIST Secure Software Development Framework (SSDF) find the wiki controls, standards, code and tests that apply each SSDF practice to AI systems and to code written with AI assistants and coding agents.
Audience: Application security, DevSecOps, platform engineering, AI model and AI system producers, software acquirers, GRC.
Using the two together: Use the SSDF for the practices and tasks of a secure development lifecycle, and SP 800-218A for what those practices add for generative AI models and the systems built on them. Use this wiki for the controls, evidence, working code and test cases that show each practice is in place.
About the framework and this page
NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, was published in February 2022. It groups its practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Each practice has tasks, numbered for example PS.1.1.
NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, was published in July 2024. It names three audiences: AI model producers, AI system producers (organisations building software that uses a generative AI or dual-use foundation model) and AI system acquirers. It adds recommendations to the SSDF tasks, modifies some practices, and adds practices that are not part of SSDF 1.1. NIST states that the profile should not be used without SP 800-218.
Two numbering points matter when citing:
- In SSDF 1.1, the former practice PW.3 was moved: its first task became PO.1.3, which the text marks "Formerly PW.3.1".
- SP 800-218A reuses the number PW.3 for a new practice, "Confirm the Integrity of Training, Testing, Fine-Tuning, and Aligning Data Before Use", and adds task PO.5.3 on continuously monitoring software execution performance and behaviour in development environments. Both are marked in the profile as not part of SSDF 1.1.
Verify before use. The publication titles, dates and audiences, the four groups, the titles of PO.1 to PO.5 and PS.1, the new PW.3 practice and task PO.5.3, and the PW.3 renumbering above were read from the NIST publication pages and PDFs on 23 October 2026 [Verified]. The other practice titles below were read from a partial read of the PDFs and checked against memory [Reported]; check them against SP 800-218 before quoting them. On 23 October 2026 the NIST SSDF project page treated SP 800-218 version 1.1 as current and listed no revision; check for a newer version before citing. The mapping is this wiki's own judgement and has not been reviewed by NIST.
Match is Direct when the wiki has a control, evidence and tests for the practice as it applies to AI, and Partial when it covers only part, as the last column explains.
SSDF practices to wiki controls
Prepare the Organization (PO)
| Practice | Title | Main wiki controls | Wiki pages and code | Match | Notes |
|---|---|---|---|---|---|
| PO.1 | Define Security Requirements for Software Development | AI-CTRL-012, AI-CTRL-033 | AI Policy Standards and Acceptable Use, Domain Standards | Direct | SP 800-218A marks PO.1 as modified for AI. The domain standards are the AI security requirements a development team works to. |
| PO.2 | Implement Roles and Responsibilities | AI-CTRL-012, AI-CTRL-044 | AI Governance Operating Model, AI Product Developer Playbook | Direct | Role-based training is in the governance operating model. |
| PO.3 | Implement Supporting Toolchains | AI-CTRL-004, AI-CTRL-030 | AI Coding Assistant and Coding Agent Security Standard, Developer Pipeline Checks | Direct | AI coding assistants and coding agents are now part of the toolchain. The standard governs them; the Builder Track page runs the same checks in the agent, before commit and in CI. |
| PO.4 | Define and Use Criteria for Software Security Checks | AI-CTRL-033, AI-CTRL-034 | CI/CD release stages, pipeline gates | Direct | The two tables say which checks run at each stage and which ones block. |
| PO.5 | Implement and Maintain Secure Environments for Software Development | AI-CTRL-030, AI-CTRL-027, AI-CTRL-016, AI-CTRL-009 | ML pipeline tests, coding agent guardrails | Direct | SP 800-218A adds PO.5.3, monitoring development environments for suspicious activity. AI-CTRL-009 and the L14 audit trail case (TC-L14-019) cover it for pipelines; coding agents on developer machines are covered by TC-L06-036 and TC-L09-026. |
Protect the Software (PS)
| Practice | Title | Main wiki controls | Wiki pages and code | Match | Notes |
|---|---|---|---|---|---|
| PS.1 | Protect All Forms of Code and Data from Unauthorized Access and Tampering | AI-CTRL-028, AI-CTRL-030 | Model layer tests, Prompts and configuration as code | Direct | SP 800-218A extends secure code storage to AI models, model weights, pipelines and reward models. AI-CTRL-028 protects weights; AI-CTRL-030 protects pipelines and the registry. |
| PS.2 | Provide a Mechanism for Verifying Software Release Integrity | AI-CTRL-030, AI-CTRL-031 | CI/CD release stages (signing and signature verification) | Direct | Signing of models, containers and prompt bundles, verified at deployment. |
| PS.3 | Archive and Protect Each Software Release | AI-CTRL-031, AI-CTRL-008 | AI-assisted commit identification, Developer Pipeline Checks | Partial | The AI-BOM records model and dataset provenance, and the AI-Assistance trailer records which changes an assistant or agent made. The wiki has no guidance on archiving releases themselves; that is general SSDF practice. |
Produce Well-Secured Software (PW)
| Practice | Title | Main wiki controls | Wiki pages and code | Match | Notes |
|---|---|---|---|---|---|
| PW.1 | Design Software to Meet Security Requirements and Mitigate Security Risks | AI-CTRL-037, AI-CTRL-033 | Reference Architecture, Agent Architecture Patterns | Direct | Risk assessment and design patterns that contain prompt injection and excessive agency. |
| PW.2 | Review the Software Design to Verify Compliance with Security Requirements and Risk Information | AI-CTRL-033 | Architect's review checklist | Direct | The release gate requires a security review record. |
| PW.3 | Confirm the Integrity of Training, Testing, Fine-Tuning, and Aligning Data Before Use (SP 800-218A only) | AI-CTRL-029, AI-CTRL-019 | Training and fine-tuning tests, Predictive Model Monitoring and Adversarial ML | Direct | Applies to model producers and to teams that fine-tune. Poisoning, provenance and personal data in training data are tested in L13. |
| PW.4 | Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality | AI-CTRL-031, AI-CTRL-014 | Supply chain tests, dependency verification | Direct | Includes verifying that a package an assistant suggests exists and is not typosquatted (TC-L05-019, TC-L16-004). |
| PW.5 | Create Source Code by Adhering to Secure Coding Practices | AI-CTRL-004, AI-CTRL-020 | AI Coding Assistant and Coding Agent Security Standard, Secure Your First Agent | Direct | Generated code is held to the same secure coding rules; LLM output is handled as untrusted input. |
| PW.6 | Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security | AI-CTRL-030 | Pipeline runner least privilege | Partial | The wiki covers pipeline and runner security, not compiler and build hardening, which is the same for AI software as for any other. |
| PW.7 | Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements | AI-CTRL-033, AI-CTRL-031 | Insecure code suggestion detection, Developer Pipeline Checks | Direct | SP 800-218A extends review to scanning models for malicious content; the release stages table includes a model file scan. |
| PW.8 | Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements | AI-CTRL-034 | Test Case Library, payload kit, AI Red Team Playbook | Direct | The 682 test cases are the AI-specific testing; each shows its validation level. |
| PW.9 | Configure Software to Have Secure Settings by Default | AI-CTRL-005, AI-CTRL-032 | Custom AI Application Runtime Security Standard | Partial | Runtime and infrastructure defaults are covered; the wiki has no secure-defaults checklist for AI products shipped to customers. |
Respond to Vulnerabilities (RV)
| Practice | Title | Main wiki controls | Wiki pages and code | Match | Notes |
|---|---|---|---|---|---|
| RV.1 | Identify and Confirm Vulnerabilities on an Ongoing Basis | AI-CTRL-034, AI-CTRL-009 | Monitoring, detection and response tests | Direct | Scheduled re-runs of the evaluation and adversarial suites, and provider model change monitoring (TC-L16-013). |
| RV.2 | Assess, Prioritize, and Remediate Vulnerabilities | AI-CTRL-035, AI-CTRL-037 | AI Risk Methodology, operating defaults | Direct | Severity, response times and exception limits are in the operating defaults. |
| RV.3 | Analyze Vulnerabilities to Identify Their Root Causes | AI-CTRL-035 | Post-incident feedback, AI Security Incident Casebook | Direct | Model behaviour regressions and poisoning have their own forensic cases in the incident domain. |
Of the 20 practices in this table, 17 are a direct match and 3 are partial.
Where the wiki stops
The SSDF is about the whole development lifecycle of any software. This wiki adds what changes when the software is an AI system or is written with AI help. It does not repeat general practice that is the same for every product: compiler and build hardening, release archiving and secure default settings for shipped products. Use the SSDF itself for those.
SP 800-218A adds many recommendations to individual SSDF tasks. This page maps at practice level only. For a statement against SP 800-218A, map at task level from the profile itself.
Attribution
NIST SP 800-218 and SP 800-218A are publications of the US National Institute of Standards and Technology. This page cites practice identifiers and titles only. Read the publications on the SP 800-218 page and the SP 800-218A page, both read on 23 October 2026.