SSDF Self-Assessment and Attestation Template (NIST SP 800-218)

SSDF 1.1 self-assessment by task (PO, PS, PW, RV), status scale and scoring, evidence, POA&M, exceptions, v1.2 draft and AI profile supplements, attestation

Sicherheits-EngineeringVollständigNIST SP 800-218 SSDF 1.1; SP 800-218r1 ipd; SP 800-218Assdf practice attestationAktualisiert 24.10.2026

Im Editor öffnen.md herunterladen

Anleitung: Use it when a customer, contract or auditor asks how you build software securely against NIST SP 800-218. Fill the scope and the 42 SSDF 1.1 task rows with evidence first, then the POA&M and only then the optional attestation statement. The main pitfall is claiming conformance to the SSDF 1.2 draft or signing a blanket statement while tasks are open.

Vorschau

SSDF Conformance Self-Assessment and Attestation: [Product or organisation]

Self-assessment of a software producer's development practices against the NIST Secure Software Development Framework (SSDF) Version 1.1, NIST SP 800-218 (final, February 2022). The assessment is recorded task by task for the four practice groups (Prepare the Organization, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities), with evidence, gaps, a plan of action and milestones (POA&M) and an optional attestation statement. Clearly marked supplements cover the SSDF Version 1.2 initial public draft (SP 800-218r1, December 2025) and the generative AI community profile (SP 800-218A, July 2024). Worked examples use Corvid Commerce, a fictional SaaS company. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice: a customer, contract or regulator may require a specific form, scope or wording.

Document control

Field	Value
Document ID	[SSDF-ASSESS-001]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@appsec-lead]
Approvers / reviewers	[@cto], [@head-of-engineering], [@ciso], [@legal-counsel]
Last updated	YYYY-MM-DD
Classification	[Confidential / Shareable with customers under NDA]
Software in scope	[Example: Corvid Storefront SaaS platform, releases 2026.3 to 2026.10]
Framework version assessed	NIST SP 800-218, SSDF Version 1.1 (final)
Supplements recorded	[SP 800-218r1 draft additions (section 10) / SP 800-218A AI profile (section 11) / None]
Assessment period	YYYY-MM-DD to YYYY-MM-DD
Assessment type	[First-party self-assessment / Third-party assessment by [assessor]]
Intended recipients	[Example: Enterprise customers, public-sector buyers, internal risk committee]
Next reassessment	YYYY-MM-DD (at least annually and after a trigger in section 13)

Approvals

Role	Name	Decision	Date
Accountable executive (attestation signatory)	[@name]	[Approved / Changes requested]	YYYY-MM-DD
Chief information security officer	[@name]	[Decision]	YYYY-MM-DD
Head of engineering	[@name]	[Decision]	YYYY-MM-DD
Legal counsel	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	First draft after evidence collection
0.2	YYYY-MM-DD	[@name]	Example: Scores reviewed with practice owners; POA&M agreed
1.0	YYYY-MM-DD	[@name]	Example: Approved; attestation statement signed

Introduction and scope
Assessment method
Summary of results
Prepare the Organization (PO)
Protect the Software (PS)
Produce Well-Secured Software (PW)
Respond to Vulnerabilities (RV)
Plan of action and milestones
Compensating controls and exceptions
SSDF Version 1.2 draft additions (not final)
AI model development supplement (SP 800-218A)
Attestation statement (optional)
Maintenance and reassessment
Traceability
Glossary and references

1. Introduction and scope

1.1 Purpose

This document records how [Organisation] meets each task of the Secure Software Development Framework for the software named below. It serves three uses:

Internal improvement. It gives the security and engineering leads a task-level view of gaps and a funded plan to close them.
Customer assurance. It answers supplier questionnaires and contract clauses that reference SP 800-218, with evidence available on request.
Optional attestation. Where a buyer asks for a signed statement, section 12 provides one that is consistent with the recorded results.

1.2 Software in scope

Item	Value
Product(s)	[Example: Corvid Storefront (multi-tenant commerce SaaS), Corvid Checkout SDK (JavaScript library distributed to customers)]
Versions or release range	[Example: All releases from 2026.3 onwards; SDK 4.x]
Delivery model	[Example: SaaS deployed continuously to production; SDK published to a public package registry]
Development locations and teams	[Example: 9 product teams, 1 platform team, contractors in 2 countries]
Build and release environment	[Example: Hosted Git service, managed CI runners, private artefact registry, Kubernetes production clusters]
Third-party components	[Example: About 1,400 open-source packages, 6 commercial libraries, 3 managed cloud services]
Out of scope	[Example: Internal analytics notebooks, marketing website, acquired product "Corvid Lite" until integration is complete]

1.3 Basis and versions

Source	Version and status	Use in this document
NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1	Final, published 3 February 2022	Normative basis: practices and tasks in sections 4 to 7
NIST SP 800-218r1, SSDF Version 1.2	Initial public draft, 17 December 2025; comment period closed 30 January 2026	Readiness only (section 10); not a basis for conformance claims
NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile	Final, 26 July 2024	Supplement for teams that train or fine-tune AI models (section 11)
OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security	Issued 23 January 2026	Context for federal buyers (section 12.1)
CISA Secure Software Development Attestation Common Form	Released March 2024; use is optional for agencies after M-26-05	Context only (section 12.1)

Check csrc.nist.gov for a final SSDF Version 1.2 before each reassessment. Executive Order 14306 (June 2025) directed NIST to publish a preliminary SSDF update and then a final version, so a final release may appear at any time. When it does, re-baseline this document against it.

1.4 Relationship to other documents

This assessment summarises practices that are specified in more detail elsewhere. Link the evidence, do not duplicate it:

Secure coding rules: Secure Coding Standard (security/secure-coding-standard)
Threat modelling: Threat Model (security/threat-model) and Security Design Review (security/security-review)
Build pipeline controls: CI/CD Pipeline Design (dev/ci-cd-pipeline-design)
Provenance, signing and SLSA levels: Software Supply Chain Security Assessment (security/supply-chain-security)
SBOM and VEX production: SBOM and VEX Policy (security/sbom-vex-policy)
Vulnerability intake and response: Vulnerability Disclosure Policy (security/vulnerability-disclosure-policy) and PSIRT Vulnerability Handling (security/psirt-vulnerability-handling)
Programme maturity view: OWASP SAMM Assessment (security/samm-assessment)

2. Assessment method

2.1 Roles

Activity	AppSec lead	Practice owners	Engineering managers	Internal audit or 3rd-party assessor	Accountable executive
Plan scope and schedule	A/R	C	C	I	I
Collect evidence per task	C	R	R	I	I
Score each task	R	C	C	C	I
Calibrate and challenge scores	A	C	I	R	I
Approve POA&M and funding	C	C	C	I	A
Sign attestation statement	C	I	I	C	A/R

R = Responsible, A = Accountable, C = Consulted, I = Informed.

2.2 Implementation status scale

Status	Code	Criteria	Score
Implemented	I	The task outcome is achieved for all in-scope software, the practice is documented, and current evidence exists (generated within the last 12 months, or within the last release cycle for per-release tasks).	1.0
Partially implemented	P	The outcome is achieved for some products, teams or releases, or the practice exists but evidence is incomplete or stale.	0.5
Not implemented	N	The outcome is not achieved, or there is no evidence.	0
Not applicable	NA	The task cannot apply to the scoped software. Record the reason; the task is removed from the denominator.	n/a
Planned (overlay)	+	Use with P or N when a POA&M item with a funded date exists, for example "N+".	as base

Score formulas.

Task coverage (%) = Implemented tasks / applicable tasks x 100.
Weighted conformance (%) = sum of task scores / applicable tasks x 100.
Group score (%) = weighted conformance computed per practice group.

The weighted score is a management indicator, not a pass mark. The SSDF itself does not define levels or thresholds; buyers usually look at the individual tasks and the plan for gaps.

2.3 Evidence standard

Accept evidence that shows the practice operating, not only a policy that says it should. Prefer, in order:

System records generated by the toolchain (pipeline logs, branch protection settings exports, signed provenance, scan results).
Records of a human control operating (review approvals, training completion records, risk acceptance tickets).
Approved documents (policies, standards, procedures) with an owner and a review date.
Interviews, recorded with date and interviewee role, used only to explain the above.

Record each item as EVD-NNN with location, date and owner in the evidence index (an appendix or a linked register). Sample at least [Example: three] products or repositories per task when the scope covers more than three.

2.4 Assessment flow

The flow below runs once per assessment cycle. Calibration can send a score back for more evidence; only approved results feed the attestation.

3. Summary of results

SSDF 1.1 defines 19 active practices and 42 active tasks. Some IDs from SSDF Version 1.0 are retired and marked "moved" in SP 800-218 (for example PW.3, PW.4.3, PW.4.5 and PW.5.2); they are not assessed.

Practice group	Applicable tasks	I	P	N	Task coverage	Weighted conformance
PO, Prepare the Organization	13	Example: 7	6	0	53.8%	76.9%
PS, Protect the Software	4	Example: 3	1	0	75.0%	87.5%
PW, Produce Well-Secured Software	16	Example: 9	5	2	56.3%	71.9%
RV, Respond to Vulnerabilities	9	Example: 4	3	2	44.4%	61.1%
Total	42	23	15	4	54.8%	72.6%

Example calculation for the total: weighted conformance = (23 x 1.0 + 15 x 0.5 + 4 x 0) / 42 = 30.5 / 42 = 72.6%.

Key messages (Example).

Corvid Commerce protects code and releases well (PS 87.5%): branch protection, signed artefacts and retained provenance are in place.
The weakest group is RV (61.1%): vulnerabilities are fixed, but root causes are not analysed systematically, so the same classes recur.
Four tasks are not implemented (PW.6.2, PW.9.2, RV.3.2, RV.3.4). All four have funded POA&M items due within two quarters.

4. Prepare the Organization (PO)

Columns "Status", "Evidence" and "Gap or note" show Example values for Corvid Commerce. Task text is an original one-line paraphrase; read SP 800-218 for the full wording and implementation examples.

Task	Paraphrase	Status	Evidence	Gap or note	Owner
PO.1	Define security requirements for software development
PO.1.1	Document and maintain the security requirements that apply to development infrastructure and processes	Example: I	EVD-001 Secure development policy v3, reviewed 2026-04	None	[@appsec-lead]
PO.1.2	Document and maintain the security requirements that the organisation's own software must meet	Example: I	EVD-002 Product security requirements baseline; EVD-003 secure coding standard	None	[@appsec-lead]
PO.1.3	Communicate security requirements to third parties that supply commercial components for reuse	Example: P	EVD-004 Supplier clause in 4 of 6 contracts	Two older contracts lack the clause (POAM-001)	[@procurement-lead]
PO.2	Implement roles and responsibilities
PO.2.1	Define and periodically review roles and responsibilities that cover the whole development life cycle	Example: I	EVD-005 RACI in engineering handbook; security champion roster	None	[@head-of-engineering]
PO.2.2	Give role-based secure development training to everyone whose work affects security, and keep it current	Example: P	EVD-006 Training records: 71% of engineers completed	No role-specific track for SRE and QA (POAM-002)	[@security-champions-lead]
PO.2.3	Obtain and communicate leadership commitment to secure development	Example: I	EVD-007 CTO memo; security objectives in engineering OKRs	None	[@cto]
PO.3	Implement supporting toolchains
PO.3.1	Specify which tools or tool types each toolchain must or should include and how they integrate	Example: I	EVD-008 Pipeline reference design	None	[@platform-lead]
PO.3.2	Deploy, operate and maintain tools and toolchains securely	Example: I	EVD-009 Runner hardening baseline; tool patch log	None	[@platform-lead]
PO.3.3	Configure tools to produce artefacts that show secure development practices are followed	Example: P	EVD-010 Scan results retained for 90 days only	Retention shorter than release support period (POAM-003)	[@platform-lead]
PO.4	Define and use criteria for software security checks
PO.4.1	Define criteria for security checks and track them across the life cycle	Example: P	EVD-011 Release gate for critical findings	No defined criteria for design review or threat model completion (POAM-003)	[@appsec-lead]
PO.4.2	Gather and protect the information needed to apply those criteria	Example: P	EVD-012 Dashboard of scan results	Gate decisions not logged for manual overrides (POAM-003)	[@platform-lead]
PO.5	Implement and maintain secure environments for software development
PO.5.1	Separate and protect each environment used in development, build, test and release	Example: I	EVD-013 Network segmentation diagram; separate cloud accounts per environment	None	[@platform-lead]
PO.5.2	Harden and secure development endpoints using a risk-based approach	Example: P	EVD-014 Device management covers employees	Contractor laptops not enrolled (POAM-004)	[@it-security-lead]

5. Protect the Software (PS)

Task	Paraphrase	Status	Evidence	Gap or note	Owner
PS.1	Protect all forms of code from unauthorised access and tampering
PS.1.1	Store source, executable and configuration code with least-privilege access so only authorised people and services can change it	Example: I	EVD-015 Branch protection export; SSO-enforced repository access; quarterly access review	None	[@platform-lead]
PS.2	Provide a mechanism for verifying software release integrity
PS.2.1	Publish integrity verification information (hashes, signatures) that acquirers can use	Example: I	EVD-016 SDK packages signed; container images signed with keyless signing; verification guide	None	[@release-manager]
PS.3	Archive and protect each software release
PS.3.1	Archive release files and supporting data such as integrity and provenance information	Example: I	EVD-017 Immutable artefact registry with 3-year retention	None	[@release-manager]
PS.3.2	Collect, protect, maintain and share provenance data for all components of each release, for example as an SBOM	Example: P	EVD-018 SBOM generated for SDK releases	No SBOM for SaaS runtime images (POAM-005)	[@appsec-lead]

6. Produce Well-Secured Software (PW)

PW.3 is not assessed: in SSDF 1.1 its tasks moved to PO.1.3 and PW.4.4. PW.4.3, PW.4.5 and PW.5.2 are also retired IDs.

Task	Paraphrase	Status	Evidence	Gap or note	Owner
PW.1	Design software to meet security requirements and mitigate security risks
PW.1.1	Use risk modelling, such as threat modelling or attack surface mapping, to assess the software's security risk	Example: I	EVD-019 Threat models for 8 of 8 tier-1 services	None	[@appsec-lead]
PW.1.2	Track and maintain security requirements, risks and design decisions	Example: P	EVD-020 Design docs with security section	Risk decisions not linked to tickets (POAM-006)	[@engineering-managers]
PW.1.3	Build in support for standard security features and services instead of creating bespoke ones	Example: I	EVD-021 Central identity, logging and secrets services used by all services	None	[@platform-lead]
PW.2	Review the software design to verify compliance with security requirements and risk information
PW.2.1	Have a qualified reviewer not involved in the design, or automated checks, confirm the design meets the security requirements	Example: P	EVD-022 Design review records	Independent review only for tier-1 services (POAM-006)	[@appsec-lead]
PW.4	Reuse existing, well-secured software when feasible instead of duplicating functionality
PW.4.1	Acquire and maintain well-secured third-party components for use in the software	Example: I	EVD-023 Dependency intake procedure; approved registry proxy	None	[@platform-lead]
PW.4.2	Build and maintain well-secured shared components in-house where third-party ones do not fit	Example: I	EVD-024 Internal libraries follow the same pipeline and review rules	None	[@platform-lead]
PW.4.4	Verify that acquired components meet the organisation's requirements throughout their life cycle	Example: P	EVD-025 Software composition analysis on merge	No continuous check of deployed versions; no end-of-life check (POAM-001)	[@appsec-lead]
PW.5	Create source code by adhering to secure coding practices
PW.5.1	Follow secure coding practices suited to the languages and environment	Example: I	EVD-026 Secure coding standard; linter rules enforced in CI	None	[@engineering-managers]
PW.6	Configure the compilation, interpreter and build processes to improve executable security
PW.6.1	Use compilers, interpreters and build tools that offer security-improving features	Example: I	EVD-027 Supported toolchain versions list	None	[@platform-lead]
PW.6.2	Decide which security features and settings the build tools should use, then apply and enforce the approved configuration	Example: N	None	No approved hardening flags or strict modes per language (POAM-007)	[@platform-lead]
PW.7	Review and/or analyse human-readable code to identify vulnerabilities and verify compliance with security requirements
PW.7.1	Decide whether to use code review, code analysis or both, based on risk	Example: I	EVD-028 Review policy: two approvals for tier-1, static analysis on all repositories	None	[@appsec-lead]
PW.7.2	Perform the review or analysis against the secure coding standard and record and triage the findings	Example: I	EVD-029 Static analysis findings tracked in issue tracker with triage labels	None	[@engineering-managers]
PW.8	Test executable code to identify vulnerabilities and verify compliance with security requirements
PW.8.1	Decide whether and which kinds of executable testing are needed	Example: I	EVD-030 Test strategy: dynamic scanning, annual penetration test	None	[@qa-lead]
PW.8.2	Scope, design and run the tests, document results and triage findings	Example: P	EVD-031 Penetration test report 2026-05	Dynamic scan results not triaged into backlog (POAM-008)	[@qa-lead]
PW.9	Configure software to have secure settings by default
PW.9.1	Define a secure baseline so that default settings do not weaken security	Example: P	EVD-032 Tenant default settings list	Not reviewed by security; legacy API keys enabled by default (POAM-009)	[@product-security-lead]
PW.9.2	Implement the secure defaults and document each security-relevant setting for administrators	Example: N	None	No administrator hardening guide (POAM-009)	[@product-security-lead]

7. Respond to Vulnerabilities (RV)

Task	Paraphrase	Status	Evidence	Gap or note	Owner
RV.1	Identify and confirm vulnerabilities on an ongoing basis
RV.1.1	Collect vulnerability information from acquirers, users and public sources about the software and its components, and investigate credible reports	Example: I	EVD-033 Security contact and intake queue; advisory feed monitoring	None	[@psirt-lead]
RV.1.2	Review, analyse or test the code to find vulnerabilities not detected before	Example: I	EVD-034 Scheduled full-repository scans; bug bounty reports	None	[@appsec-lead]
RV.1.3	Maintain a vulnerability disclosure and remediation policy, with the roles and processes to support it	Example: I	EVD-035 Published disclosure policy; PSIRT procedure	None	[@psirt-lead]
RV.2	Assess, prioritise and remediate vulnerabilities
RV.2.1	Analyse each vulnerability to understand its risk well enough to plan a response	Example: I	EVD-036 Triage records with severity and exploitability	None	[@psirt-lead]
RV.2.2	Plan and carry out risk responses, such as fixes, mitigations or documented acceptance	Example: P	EVD-037 Remediation SLA report	18% of high findings past SLA; acceptances not time-limited (POAM-010)	[@psirt-lead]
RV.3	Analyse vulnerabilities to identify their root causes
RV.3.1	Determine the root cause of identified vulnerabilities	Example: P	EVD-038 Root cause recorded for critical issues only	Not done for high and medium (POAM-011)	[@appsec-lead]
RV.3.2	Analyse root causes over time to find patterns	Example: N	None	No trend analysis (POAM-011)	[@appsec-lead]
RV.3.3	Search the software for similar vulnerabilities and fix the whole class proactively	Example: P	EVD-039 Variant search after two critical issues	No standard variant analysis step (POAM-012)	[@appsec-lead]
RV.3.4	Update the development process to prevent recurrence of identified root causes	Example: N	None	Lessons not fed into standards or training (POAM-011)	[@appsec-lead]

8. Plan of action and milestones

POA&M ID	Tasks addressed	Action	Owner	Milestones	Due	Status
POAM-001 (Example)	PO.1.3, PW.4.4	Add the supplier security clause at renewal; add continuous component monitoring of deployed versions and an end-of-life check	[@procurement-lead], [@appsec-lead]	Clause approved; monitoring live in production	YYYY-MM-DD	Open
POAM-002 (Example)	PO.2.2	Create role tracks for SRE and QA; target 95% completion	[@security-champions-lead]	Tracks published; completion report	YYYY-MM-DD	Open
POAM-003 (Example)	PO.3.3, PO.4.1, PO.4.2	Define security check criteria per stage; retain tool artefacts for the support period; log gate overrides	[@platform-lead]	Criteria approved; retention changed; override log in place	YYYY-MM-DD	In progress
POAM-004 (Example)	PO.5.2	Enrol contractor endpoints or provide managed virtual desktops	[@it-security-lead]	100% enrolment	YYYY-MM-DD	Open
POAM-005 (Example)	PS.3.2	Generate and archive SBOMs for every runtime image release	[@appsec-lead]	Pipeline step live; SBOM attached to release record	YYYY-MM-DD	In progress
POAM-006 (Example)	PW.1.2, PW.2.1	Link threat model risks to tickets; extend independent design review to tier-2 services	[@appsec-lead]	Template updated; reviewer rota	YYYY-MM-DD	Open
POAM-007 (Example)	PW.6.2	Approve build hardening and strict-mode settings per language and enforce in CI	[@platform-lead]	Settings approved; CI policy enforcing	YYYY-MM-DD	Open
POAM-008 (Example)	PW.8.2	Route dynamic scan findings into team backlogs with triage SLA	[@qa-lead]	Integration live	YYYY-MM-DD	Open
POAM-009 (Example)	PW.9.1, PW.9.2	Security review of tenant defaults; disable legacy API keys by default; publish administrator hardening guide	[@product-security-lead]	Review done; guide published	YYYY-MM-DD	Open
POAM-010 (Example)	RV.2.2	Time-limit risk acceptances; weekly SLA review	[@psirt-lead]	Acceptance workflow updated	YYYY-MM-DD	In progress
POAM-011 (Example)	RV.3.1, RV.3.2, RV.3.4	Root cause analysis for all high and critical findings; quarterly trend review that updates standards and training	[@appsec-lead]	First quarterly review held	YYYY-MM-DD	Open
POAM-012 (Example)	RV.3.3	Add a variant analysis step to the fix procedure	[@appsec-lead]	Procedure updated	YYYY-MM-DD	Open

Check: the 19 tasks scored P or N in sections 4 to 7 each appear in exactly one POA&M item above.

9. Compensating controls and exceptions

Record each exception with its own ID. Exceptions MUST have an expiry date, an accountable approver and a link to the POA&M item that removes them.

Exception ID	Task	Reason	Compensating control	Residual risk	Approved by	Expires
EXC-001 (Example)	PW.6.2	Build hardening settings not yet agreed for the Go services	Static analysis rules for unsafe packages enforced; memory-safe language in use	Low	[@ciso]	YYYY-MM-DD
EXC-002 (Example)	PO.5.2	Contractor endpoints not managed	Contractors work only through browser-based development environments with no local clone	Medium	[@ciso]	YYYY-MM-DD

Rules for exceptions:

An exception never changes the task status in sections 4 to 7.
Exceptions are reviewed at each reassessment and lapse on their expiry date unless renewed with new justification.
Exceptions affecting the attestation statement (section 12) are listed in the statement or its annex.

10. SSDF Version 1.2 draft additions (not final)

Draft notice. NIST SP 800-218r1 (SSDF Version 1.2) was released as an initial public draft on 17 December 2025, with comments closed on 30 January 2026. As of the date of this template, no final version is published. Practice and task IDs below may change. Check csrc.nist.gov/pubs/sp/800/218/r1/ipd and the SSDF project page before use.

The draft adds two practices. The paraphrases below are original summaries of the draft text.

Draft task	Paraphrase	Readiness	Note
PO.6	Define and implement a continuous process improvement plan
PO.6.1	Update and improve development environments as threats change and new tools are adopted	Example: Partial	Tool review happens ad hoc
PO.6.2	Look for new processes, tools and techniques, such as safer languages, that avoid classes of errors	Example: Partial	Links to the memory-safety roadmap in Secure by Design Roadmap (`security/secure-by-design-roadmap`)
PO.6.3	Improve vulnerability response and periodically revisit earlier response decisions	Example: Not started	Overlaps POAM-010
PS.4	Ensure software updates are robust and reliable
PS.4.1	Test updates thoroughly before release, including in representative configurations	Example: Ready	Staging and canary tests in pipeline
PS.4.2	Use tiered release strategies such as canaries, staged roll-outs and test deployments	Example: Ready	Progressive delivery in production
PS.4.3	Provide reliable rollback for updates and protect against rollback to vulnerable versions	Example: Partial	SaaS rollback ready; SDK has no downgrade protection
PS.4.4	Keep update engines and delivery infrastructure robust and reliable	Example: Ready	Registry and CDN have failover

The draft also rewords two existing tasks (RV.1.2 and RV.3.3), adds implementation examples to several tasks and removes the EO 14028 references and appendix. Compare each existing task with the final when it is published, and record changed tasks in the revision history.

11. AI model development supplement (SP 800-218A)

SP 800-218A augments SSDF 1.1 for producers of generative AI and dual-use foundation models. It keeps the SSDF task structure, marks tasks that are modified, and adds tasks that are not part of SSDF 1.1. The added tasks include the following (original paraphrases; check the profile for the full list and the per-task priority).

Profile task	Paraphrase	Status	Note
PO.5.3	Continuously monitor how software behaves in development environments to spot suspicious activity	Example: NA	Corvid Commerce does not train models
PS.1.2	Protect training, testing, fine-tuning and alignment data from unauthorised access and change	Example: NA
PS.1.3	Protect model weights and configuration parameters from unauthorised access and change	Example: NA
PW.3 (PW.3.1 to PW.3.3)	Confirm the integrity of training, testing, fine-tuning and alignment data before use	Example: NA	Practice ID reused by the profile for a new purpose

If any profile task applies, also complete an AI bill of materials (ai-data/ai-bom) for each model and reference it as evidence for PS.3.2.

12. Attestation statement (optional)

12.1 Status of the CISA common form

For US federal buyers, OMB Memorandum M-22-18 and its companion M-23-16 required agencies to collect the CISA Secure Software Development Attestation Common Form from software producers. OMB Memorandum M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16 and asks each agency to set software and hardware assurance requirements based on its own risk assessment. Agencies may still choose to use the government-wide resources developed under M-22-18, including the attestation form, and may require an SBOM by contract. Check the current status of the form and of the CISA repository for attestations at cisa.gov before submitting anything; this template does not reproduce the form.

Other buyers, including regulated industries and enterprise customers, increasingly reference SP 800-218 in contracts. Read the contract clause: it decides the form, signatory and scope.

12.2 Statement

Example wording; adapt with counsel.

Statement of secure software development practices

[Organisation] ("the producer") has assessed the development practices used for [software in scope, versions] against NIST SP 800-218, Secure Software Development Framework Version 1.1, for the period [start] to [end].

The results are recorded in [SSDF-ASSESS-001, version], which lists the status and evidence for each SSDF task.

[23] of [42] applicable tasks are implemented, [15] are partially implemented and [4] are not implemented. Each task not fully implemented is covered by a dated plan of action and milestones ([POAM-001 to POAM-012]).

Compensating controls are in place for the exceptions listed in [EXC-001, EXC-002].

The producer will update this statement if a material change affects the practices described, and at least every [12] months.

Signed: [Name], [Title], [Organisation]. Date: YYYY-MM-DD.

12.3 Independent assessment option

Some buyers ask for third-party verification. If so, record the assessor, the method (interview, inspection, sampling), the sample and the assessor's conclusion as an annex. A third-party report does not replace this document; it tests it.

13. Maintenance and reassessment

Reassess at least every [12] months, and also when any trigger occurs:

Trigger	Action
NIST publishes a final SSDF Version 1.2	Re-baseline against the new version within [two] quarters
Major change to the build or release pipeline	Reassess PO.3, PO.5, PS.1 to PS.3
Acquisition or new product line	Extend scope or create a separate assessment
Security incident involving the development environment	Reassess PO.5, PS.1 and RV.3; update the statement
POA&M item closed	Update the task status with new evidence
Customer or contract requires a new attestation	Confirm the assessment is within its validity period

Metrics tracked quarterly (Example targets).

Metric	Formula	Target
Weighted conformance	Sum of task scores / applicable tasks	Above 85% within 12 months
POA&M on time	POA&M items closed by due date / items due	90%
Evidence freshness	Implemented tasks with evidence under 12 months old / implemented tasks	100%
Exceptions past expiry	Count of exceptions beyond expiry date	0

14. Traceability

SSDF practice	Internal artefact (Example)	Library template	Related OWASP SAMM practice or stream
PO.1	Secure development policy; product security requirements	Secure Coding Standard (`security/secure-coding-standard`)	Governance, Policy and Standards; Design, Software Requirements
PO.2	Engineering handbook RACI; training plan	Security Champions Program (`security/security-champions-program`)	Governance, Education and Guidance
PO.3, PO.4	Pipeline reference design; release gates	CI/CD Pipeline Design (`dev/ci-cd-pipeline-design`)	Implementation, Build Process
PO.5	Environment segmentation; endpoint baseline	Security Architecture (`security/security-architecture`)	Operations, Configuration Hardening
PS.1 to PS.3	Branch protection; signing; artefact retention; SBOM	Software Supply Chain Security Assessment (`security/supply-chain-security`); SBOM and VEX Policy (`security/sbom-vex-policy`)	Implementation, Build Process and Software Dependencies
PW.1, PW.2	Threat models; design reviews	Threat Model (`security/threat-model`); Security Design Review (`security/security-review`)	Design, Threat Modeling; Verification, Architecture Validation
PW.4	Dependency intake; supplier assessment	Supplier Security Assessment (`compliance/supplier-security-assessment`)	Design, Supplier Security; Implementation, Software Dependencies
PW.5 to PW.8	Coding standard; code review; testing	Secure Coding Standard (`security/secure-coding-standard`)	Verification, Security Testing
PW.9	Secure defaults; administrator guide	Secure by Design Roadmap (`security/secure-by-design-roadmap`)	Operations, Configuration Hardening
RV.1 to RV.3	Disclosure policy; PSIRT; root cause reviews	Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`); PSIRT Vulnerability Handling (`security/psirt-vulnerability-handling`)	Implementation, Defect Management; Operations, Incident Management

The SAMM column uses SAMM v2 names and is this template's own mapping. SP 800-218 itself cites SAMM version 1.5 activity codes in its References column (for example PC1-A for PO.1.1); OWASP SAMM Assessment (security/samm-assessment) section 11 translates those codes to SAMM v2 practices.

15. Glossary and references

15.1 Glossary

Term	Meaning in this document
SSDF	Secure Software Development Framework: a set of high-level practices for secure software development published by NIST
Practice	A grouping of tasks that share an outcome, identified as PO.n, PS.n, PW.n or RV.n
Task	An individual action within a practice, identified as, for example, PW.7.2
Notional implementation example	An illustration in SP 800-218 of how a task might be performed; not a requirement
POA&M	Plan of action and milestones: dated actions that close identified gaps
Attestation	A signed statement by an authorised person about the producer's practices
SBOM	Software bill of materials: a formal record of components and their relationships
Provenance	Verifiable information about where, when and how an artefact was produced
Producer	The organisation that develops and supplies the software

15.2 References

Reference	Use
NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, February 2022, doi:10.6028/NIST.SP.800-218 (csrc.nist.gov/pubs/sp/800/218/final)	Practices and tasks (sections 4 to 7)
NIST SP 800-218r1 ipd, SSDF Version 1.2, initial public draft, December 2025 (csrc.nist.gov/pubs/sp/800/218/r1/ipd)	Draft additions (section 10)
NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, July 2024 (csrc.nist.gov/pubs/sp/800/218/a/final)	AI supplement (section 11)
OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, 23 January 2026 (whitehouse.gov)	Federal context (section 12.1)
Executive Order 14306, Sustaining Select Efforts To Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144, signed 6 June 2025 (federalregister.gov)	Direction to update the SSDF
CISA, Secure Software Development Attestation Form (cisa.gov/secure-software-attestation-form)	Context only; check current status
OWASP SAMM Assessment (`security/samm-assessment`)	Maturity view that complements this conformance view
Software Supply Chain Security Assessment (`security/supply-chain-security`)	SLSA levels, signing and provenance detail
AI Bill of Materials (`ai-data/ai-bom`)	Model and dataset inventory for section 11

Standard and licence note

Based on NIST SP 800-218 (SSDF Version 1.1, final, February 2022), the NIST SP 800-218r1 initial public draft (SSDF Version 1.2, December 2025), NIST SP 800-218A (final, July 2024) and OMB Memorandum M-26-05 (January 2026), which are works of the United States Government and not subject to copyright in the United States. Practice and task identifiers and practice names are cited; task descriptions are original one-line paraphrases, and the assessment method, scoring formulas, attestation wording and examples are original. The CISA attestation form is not reproduced. Check the current official versions at csrc.nist.gov, whitehouse.gov and cisa.gov before relying on this document, as a final SSDF Version 1.2 or new federal guidance may have been published. Corvid Commerce is a fictional company. Original text written for this collection. Template licence: MIT.