NIST SSDF
Secure Software Development Framework on one operating record

NIST SSDF (SP 800-218) explained

The NIST Secure Software Development Framework, published as NIST Special Publication 800-218 v1.1 in February 2022, is the consensus reference for the practices a software producer is expected to operate against. SSDF is not a maturity model and not a control catalogue; it is a named set of practices, broken into tasks, that a producer either implements or documents why a task does not apply. The framework reads as 19 practices and 42 tasks organised into four practice groups: PO (Prepare the Organization), PS (Protect the Software), PW (Produce Well-Secured Software), and RV (Respond to Vulnerabilities).

For internal AppSec teams, product security teams, GRC owners, security engineering teams, vulnerability management functions, and CISOs, SSDF is the vocabulary that lets a software producer communicate consistently across federal procurement reviews, the CISA Secure Software Development Attestation, audit committees, and enterprise customer security questionnaires. Producers already operating against ISO 27001, SOC 2, or NIST SP 800-53 do not migrate to SSDF; the framework reads as the software-producer-side practice catalogue the underlying control sets evidence.

The four practice groups: PO, PS, PW, RV

SSDF v1.1 organises the practice catalogue into four groups. Each group describes the operating intent rather than prescribing tooling, which is why the same reference reads against a producer using GitHub plus Semgrep, a producer using GitLab plus a different SAST, and a producer building on a self-hosted stack. The groups are sequential in dependency, not in calendar time: PO is the foundation, PS protects what the engineering work produces, PW is the engineering work, and RV closes the loop.

Example practices and tasks

SSDF practices decompose into tasks. The task is the unit the framework expects a producer to either implement, with documented evidence, or to explicitly document why the task does not apply. The sample below shows the level of specificity SSDF reads against; the full catalogue is in SP 800-218 Appendix A and reads similarly across the four groups.

EO 14028, OMB Memoranda, and the CISA SSDA

SSDF acquired federal-grade weight through Executive Order 14028 and the implementing OMB memoranda. The timeline below names the milestones that turned SSDF from a recommended reference into the practice catalogue federal software producers attest against. Producers outside the federal market still read this timeline because enterprise buyers increasingly ask vendors for SSDF-aligned evidence regardless of federal-sales status.

The CISA Secure Software Development Attestation guide covers the SSDA form itself, the scope, the signature, and the evidence the form expects. The NIST SSDF implementation guide covers the practitioner-side rollout of the framework, including a four-phase sequence for adopting SSDF without rebuilding the engineering organisation. This page is the framework reference both of those guides read against.

Scope notes on the CISA SSDA

The CISA SSDA reads against SSDF, but the form has a specific scope that producers need to understand before signing. The notes below capture the recurring questions that arise when a producer first reads the form.

NIST SP 800-218A: the Generative AI Profile

NIST SP 800-218A, published April 2024, extends SSDF with practices specific to producers of generative AI systems. The profile keeps the PO, PS, PW, RV structure and adds AI-system tasks across the four groups. Producers of generative AI software read SP 800-218 v1.1 plus SP 800-218A together rather than as a substitute, with the same operating record carrying both.

SSDF against SAMM, BSIMM, SLSA, and SBOM expectations

SSDF is the practice catalogue. OWASP SAMM and BSIMM are the software security maturity models that read against similar practice areas but score the maturity rather than attest the practice. SLSA is the build-integrity framework PS.2 and PS.3 read against in the build pipeline. SBOM is the artefact PS.3 expects a producer to archive per release, and VEX is the assertion layer RV.1 uses when communicating component-level exploitability to downstream consumers. A mature programme runs SSDF as the practice baseline, SAMM or BSIMM for maturity tracking, SLSA for the build-integrity discipline behind PS, and SBOM and VEX as the artefact set behind PS.3 and RV. For the test-side depth behind PW.7 and PW.8, the OWASP ASVS and OWASP WSTG are the verification standard and the testing manual most producers cite.

Failure modes the framework is designed to surface

SSDF is forgiving on tooling, on team structure, and on the choice of supplementary maturity model. It is unforgiving about a small number of patterns that erode the integrity of the programme and leave a producer with the appearance of SSDF alignment rather than the operating posture. The patterns below are the recurring ones across early and mid-stage adoptions.

Evidence the framework expects to see

A defensible SSDF programme produces the evidence pack as a side effect of the engineering work rather than reconstructing it at attestation time. The minimum set below maps to the artefacts the CISA SSDA defence, the ISO 27001 Annex A 8.25 to 8.34 audit response, the SOC 2 CC7 and CC8 examinations, the NIST SP 800-53 SA family review, the PCI DSS 6 controls read, and the enterprise procurement questionnaire response all read against.

How SSDF relates to ISO 27001, SOC 2, NIST SP 800-53, and adjacent regimes

SSDF is the practice catalogue for software producers. The control catalogues most enterprises operate against carry the underlying control evidence the framework reads against. The relationships below are the ones producers most often need to read together.

• The ISO 27001 framework page covers the certifiable Information Security Management System. ISO 27001:2022 Annex A controls 8.25 (secure development life cycle) through 8.34 (protection of test information) carry the underlying evidence SSDF reads against, so an ISO 27001 ISMS already produces most of the artefact set the SSDF evidence pack expects.
• The SOC 2 framework page covers the AICPA Trust Services Criteria. SOC 2 examinations read against the same development-lifecycle, change-management, and vulnerability-management evidence SSDF expects; producers operating SOC 2 already hold most of the CC7 (System Operations) and CC8 (Change Management) artefacts the SSDA defence reads against.
• The NIST SP 800-53 framework page covers the control catalogue federal systems operate against. The SA (System and Services Acquisition), SI (System and Information Integrity), CM (Configuration Management), and RA (Risk Assessment) families carry the control evidence SSDF reads against; federal systems and federal customers typically run SSDF and SP 800-53 together rather than as a substitute.
• The NIST CSF 2.0 framework page covers the outcome framework SSDF reads against. The PR (Protect) function maps to the PS and PW work; the ID (Identify) function aligns with the PO toolchain inventory and role definitions; the RS (Respond) function reads against RV. CSF 2.0 is the leadership-side read; SSDF is the producer-side practice catalogue underneath.
• The CISA Secure by Design framework page covers the principles and pledge for software manufacturers. Secure by Design and SSDF share the operating premise that defaults must be safe and that producer accountability for security is non-delegable; software produced under Secure by Design produces most of the PW.5, PW.6, and PW.9 evidence SSDF reads against.
• The EU Cyber Resilience Act framework page covers the European-side product-cybersecurity regulation. CRA Annex I essential requirements read against the same producer-side discipline SSDF describes; producers shipping into the EU run CRA and SSDF together on the same record so the evidence pack carries both reads.
• The CMMC framework page covers the Cybersecurity Maturity Model Certification for the US defence industrial base. CMMC Level 2 and Level 3 read against NIST SP 800-171 controls that overlap with SSDF producer-side expectations; producers shipping to the defence industrial base run CMMC and SSDF together.
• The CISA Secure Software Development Attestation guide covers the SSDA form, the scope rules, the signature requirements, and the evidence the form expects. The guide pairs with this framework page as the operational companion when the federal-side attestation cycle is on the calendar.
• The NIST SSDF implementation guide covers the four-phase practitioner rollout: baseline, gap analysis, evidence build, and continuous run. The implementation guide pairs with this framework page as the rollout-side companion.

Audience reads of SSDF

SSDF is read differently by different functions inside the producer. The framework is the same; the lens shifts. The audience reads below cover the recurring roles that consume SSDF inside the producer and the work each one carries on the operating record.

Where SecPortal fits in an SSDF programme

SecPortal is the operating layer for the SSDF evidence record, not a SAST scanner, a build system, a secrets vault, or a vulnerability disclosure intake portal. The platform handles the engagement record per release, the per-finding lifecycle from intake to closure across PW.7, PW.8, RV.1, and RV.2, the document archive PS.3 and PO.3 read against, the activity log every state change accumulates against, the cross-framework compliance reads, and the producer-side AI report generation. SSDF is the practice catalogue; SecPortal is the record the catalogue reads from.

For the producer-side workflows SSDF reads against, the SDLC vulnerability handoff workflow carries the per-finding handoff from PW.7 and PW.8 into the engineering remediation queue that RV.2 cites. The SBOM and VEX publishing workflow holds the PS.3 release-archive record and the RV.1 disclosure response evidence on one operating record. The dependency vulnerability triage workflow carries the PW.4 third-party component review and the RV.2 remediation evidence on the same record. The vulnerability finding intake workflow carries the RV.1 disclosure-and-scanner intake discipline so the entry-point to the framework is a recorded queue rather than an ad-hoc inbox. The security onboarding for new applications workflow carries the PO foundation work each new product line inherits before PW work starts. The control mapping cross-framework crosswalks workflow reads the same SSDF evidence into the parallel ISO 27001, SOC 2, NIST SP 800-53, PCI DSS, and CISA SSDA records so the producer answers each framework from one record rather than rebuilding the artefact set per audit.

For internal teams running the programme, the internal security teams workspace bundles the platform with the engagement structure SSDF expects across the producer-side cycle. For the AppSec function that owns the PW.5, PW.7, and PW.8 evidence, the AppSec teams workspace covers the development-adjacent angle. For the product security function carrying the cross-team PO foundation and the per-release PS discipline, the product security teams workspace covers the producer-side discipline. For the GRC and compliance function that holds the CISA SSDA defence, the ISO 27001 surveillance audit response, and the SOC 2 examination evidence, the GRC and compliance teams workspace carries the cross-framework reconciliation. For security leaders carrying the SSDF programme accountability, the CISOs and security leaders workspace covers the programme-level reporting model. For the application security programme leads running SSDF as the producer-wide baseline, the application security programme leads workspace covers the cross-team operating layer.

For the capability set SSDF reads against, the code scanning capability produces the PW.7 review-and-analysis evidence, repository connections carry the PS.1 access control and the PW.5 enforcement record, and document management holds the PO.3 toolchain inventory and the PS.3 per-release archive. For analytical context on how the evidence accumulates across releases, the vulnerability evidence reuse across audits research covers the artefact discipline a multi-framework producer keeps, and the multi-framework control crosswalk economics research covers the budget-side ledger an SSDF producer reads against when running multiple framework reads off the same evidence pack.