NIST SP 800-218 SSDF

United States

4 domains

42 controls

NIST SP 800-218 Secure Software Development Framework v1.1.

Verified

Framework summaries on this platform are AI-assisted interpretations for educational and compliance planning purposes. They do not reproduce or replace the official standards. Refer to the authoritative source for the definitive text. Framework names and trademarks belong to their respective organisations.

Framework Domains (4)

PO - Prepare the Organization

13 controls

Controls in the PO - Prepare the Organization domain of NIST SP 800-218 SSDF — 13 controls
Code	Title	Description
PO.1.1	Identify and document security requirements for software development infrastructure and processes	Define security requirements for development infrastructure, tooling, and processes; maintain them and communicate to al...
PO.1.2	Identify and document security requirements for organization-developed software	Establish, document, and maintain security requirements applicable to the software the organization develops, including...
PO.1.3	Communicate requirements to third parties providing commercial software components	Convey applicable security requirements to suppliers of commercial, open source, and other third-party software componen...
PO.2.1	Create roles and responsibilities for SDLC personnel	Define security roles and responsibilities for everyone involved in the SDLC and periodically review them.
PO.2.2	Provide role-based training for SDLC personnel	Deliver role-specific training on secure development, periodically refresh it, and document completion.
PO.2.3	Foster a security-focused culture and management commitment	Obtain leadership commitment to secure development and embed security culture across teams.
PO.3.1	Specify which tools or tool types must be included in the toolchain	Define mandatory toolchain components (SCA, SAST, DAST, secrets scanning, etc.) and document selection criteria.
PO.3.2	Deploy and maintain a secure toolchain	Implement, harden, configure, and maintain the security tooling integrated into the SDLC.
PO.3.3	Configure tools to generate artifacts of provenance for audit	Ensure tools produce audit-ready artifacts (logs, attestations, build provenance) for compliance and forensic use.
PO.4.1	Define criteria for software security checks	Establish acceptance criteria and pass/fail thresholds for security testing before release.
PO.4.2	Implement processes, mechanisms, etc. to collect and analyze information for criteria	Operationalize the collection and analysis of evidence demonstrating that release criteria are met.
PO.5.1	Separate and protect each environment involved in software development	Logically and physically segregate dev, build, test, and prod environments and protect each per its sensitivity.
PO.5.2	Secure and harden development endpoints	Harden developer workstations, build agents, and other endpoints participating in the SDLC.

PS - Protect the Software

4 controls

Controls in the PS - Protect the Software domain of NIST SP 800-218 SSDF — 4 controls
Code	Title	Description
PS.1.1	Store all forms of code based on least privilege, integrity, and provenance	Store source, build scripts, and configuration in repositories with least-privilege access and integrity protections.
PS.2.1	Make software integrity verification information available to acquirers	Provide cryptographic hashes, signatures, or attestations so consumers can verify the integrity of released software.
PS.3.1	Archive the necessary files and supporting data for each release	Securely retain release artifacts, build logs, and dependency info to support patches, audits, and incident response.
PS.3.2	Collect, safeguard, maintain, and share provenance data for components	Maintain an SBOM and provenance metadata for all components in each release and share with consumers as required.

PW - Produce Well-Secured Software

16 controls

Controls in the PW - Produce Well-Secured Software domain of NIST SP 800-218 SSDF — 16 controls
Code	Title	Description
PW.1.1	Use forms of risk modeling (e.g., threat modeling, attack modeling) to design	Apply threat modeling or equivalent risk analysis during design to identify and mitigate weaknesses before coding.
PW.1.2	Track and maintain the software's security requirements, risks, and design decisions	Maintain traceability between security requirements, risks identified, design choices, and implementation.
PW.1.3	Reuse existing, well-secured software when feasible	Prefer vetted internal or external secure components over building new code, with documented evaluation.
PW.2.1	Have a qualified person review the software design to confirm compliance	Have an independent qualified reviewer confirm the design meets security requirements and risk decisions.
PW.4.1	Acquire and maintain well-secured software components from commercial, open-source, and other third-party developers	Source third-party components only from vetted suppliers and keep them current and patched.
PW.4.2	Create well-secured software components in-house following SDLC processes	When building components internally, follow the SDLC fully so they meet the same security bar as acquired ones.
PW.4.4	Verify acquired commercial, open-source, and other third-party software components	Verify integrity and security of third-party components before integration (signatures, scans, provenance).
PW.5.1	Follow all secure coding practices appropriate to the development languages and environment	Adopt language-specific secure coding standards (e.g., CERT, OWASP) and enforce them in development.
PW.6.1	Use compiler, interpreter, and build tools that offer features to improve security	Enable security-relevant compiler and build flags (stack protectors, ASLR, hardened runtimes).
PW.6.2	Determine which compiler, interpreter, and build tool features should be used and how each should be configured	Document and enforce required configuration of compilers, interpreters, and build tooling for security.
PW.7.1	Determine whether code review and/or code analysis should be used	Decide what mix of manual review and automated analysis applies to each code path based on risk.
PW.7.2	Perform the code review and/or code analysis based on the organization's secure coding practices	Execute code review and SAST per the documented practice and record results and remediation.
PW.8.1	Determine whether executable code testing should be performed to find vulnerabilities	Decide what runtime/dynamic testing (DAST, IAST, fuzzing) applies to each release based on risk.
PW.8.2	Scope the testing, design the tests, perform the testing, and document the results	Plan, execute, and record dynamic testing including penetration tests, fuzzing, and DAST scans.
PW.9.1	Define a secure baseline by determining how to configure each setting that has an effect on security	Establish secure default configurations for each release of the software the organization produces.
PW.9.2	Implement the default settings (or groups of default settings) and document them	Ship secure defaults out-of-the-box and document the rationale and any tradeoffs.

RV - Respond to Vulnerabilities

9 controls

Controls in the RV - Respond to Vulnerabilities domain of NIST SP 800-218 SSDF — 9 controls
Code	Title	Description
RV.1.1	Gather information from purchasers, consumers, and public sources on potential vulnerabilities	Continuously collect vulnerability intel from customers, researchers, vendors, CVE feeds, and other sources.
RV.1.2	Review, analyze, and/or test the software's code to identify or confirm vulnerabilities	Validate reported issues by reviewing or testing code to confirm exploitability and scope.
RV.1.3	Have a policy that addresses vulnerability disclosure and remediation	Maintain a coordinated vulnerability disclosure policy aligned to ISO 29147 and remediation per ISO 30111.
RV.2.1	Analyze each vulnerability to gather sufficient information to plan its remediation	For each confirmed issue capture root cause, severity (CVSS), affected versions, and remediation options.
RV.2.2	Develop and implement a remediation plan for each vulnerability	Plan and execute the fix (patch, mitigation, or accepted risk) per severity-driven SLAs.
RV.3.1	Analyze identified vulnerabilities to determine their root causes	Perform root-cause analysis to identify systemic weaknesses behind individual vulnerabilities.
RV.3.2	Analyze the root causes over time to identify patterns	Look for recurring weakness patterns (CWEs) across releases to drive systemic improvements.
RV.3.3	Review the SDLC to identify changes that could prevent root causes recurring	Feed RCA findings back into the SDLC (tooling, standards, training) to prevent recurrence.
RV.3.4	Inform stakeholders about vulnerabilities, mitigations, and lessons learned	Communicate confirmed vulnerabilities, mitigations, and lessons learned to internal stakeholders and customers.

Frequently Asked Questions

What is NIST SP 800-218 SSDF?

NIST SP 800-218 SSDF is a compliance framework from United States with 4 domains and 42 controls. NIST SP 800-218 Secure Software Development Framework v1.1. It is used by organisations to establish and maintain compliance with industry standards and regulatory requirements.

How many controls does NIST SP 800-218 SSDF have?

NIST SP 800-218 SSDF has 42 controls organised across 4 domains. The largest domains are PW - Produce Well-Secured Software (16 controls), PO - Prepare the Organization (13 controls), RV - Respond to Vulnerabilities (9 controls). Each control defines specific requirements that organisations must implement to achieve compliance.

What frameworks does NIST SP 800-218 SSDF map to?

NIST SP 800-218 SSDF does not currently have cross-framework mappings in our system. Check back as we continuously expand our mapping database.

How do I get started with NIST SP 800-218 SSDF compliance?

Start your NIST SP 800-218 SSDF compliance journey by running a self-assessment on our platform to identify your current compliance posture. Our AI advisory can answer specific questions about NIST SP 800-218 SSDF requirements, and cross-framework mapping helps you leverage existing controls from other frameworks you may already comply with. Create a free account to access all 42 controls and track your progress.

Start Your Compliance Journey

Create a free account to run self-assessments, get AI advisory, and track your compliance progress across 769 frameworks.

Get Started Free →

Free forever — no credit card required