# 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.

<!--
Guidance: How to use this template
- Use it when a customer, an auditor or your own security programme asks
  "how do you build software securely?" and you want an answer that maps to
  a recognised framework, task by task, with evidence.
- Assess against SSDF 1.1, the final version. Do not claim conformance to
  the 1.2 draft; record it in section 10 as readiness work only.
- Fill section 1 (scope) first. A conformance claim without a named product,
  version range and build environment is not verifiable.
- Every "Implemented" status needs at least one evidence reference that a
  reviewer outside the team could open. No evidence means "Partially
  implemented" at best.
- The SSDF describes outcomes, not tools. Write what you do and how you know
  it works; tool names belong in the evidence column.
- Keep the task paraphrases in sections 4 to 7. They are original one-line
  summaries; read the full task text and implementation examples in SP
  800-218 before you score.
-->

## Document control

<!-- Guidance: Name the product, the versions covered and the person who can sign the attestation. An attestation signed by someone without authority over the development process has little value. -->

| 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

<!-- Guidance: Record each assessment cycle and each change of scope. Status changes for individual tasks belong in the task tables, not here. -->

| 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 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [Assessment method](#2-assessment-method)
3. [Summary of results](#3-summary-of-results)
4. [Prepare the Organization (PO)](#4-prepare-the-organization-po)
5. [Protect the Software (PS)](#5-protect-the-software-ps)
6. [Produce Well-Secured Software (PW)](#6-produce-well-secured-software-pw)
7. [Respond to Vulnerabilities (RV)](#7-respond-to-vulnerabilities-rv)
8. [Plan of action and milestones](#8-plan-of-action-and-milestones)
9. [Compensating controls and exceptions](#9-compensating-controls-and-exceptions)
10. [SSDF Version 1.2 draft additions (not final)](#10-ssdf-version-12-draft-additions-not-final)
11. [AI model development supplement (SP 800-218A)](#11-ai-model-development-supplement-sp-800-218a)
12. [Attestation statement (optional)](#12-attestation-statement-optional)
13. [Maintenance and reassessment](#13-maintenance-and-reassessment)
14. [Traceability](#14-traceability)
15. [Glossary and references](#15-glossary-and-references)

## 1. Introduction and scope

<!-- Guidance: State why the assessment exists, what it covers and what it does not. Pitfall: scoping "the company" instead of a product line; buyers need to know which software the claims apply to. -->

### 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:

1. **Internal improvement.** It gives the security and engineering leads a
   task-level view of gaps and a funded plan to close them.
2. **Customer assurance.** It answers supplier questionnaires and contract
   clauses that reference SP 800-218, with evidence available on request.
3. **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

<!-- Guidance: Explain how statuses were decided so that a reader can repeat the assessment and reach the same result. Pitfall: letting each team self-score without calibration; scores then measure optimism, not practice. -->

### 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:

1. System records generated by the toolchain (pipeline logs, branch
   protection settings exports, signed provenance, scan results).
2. Records of a human control operating (review approvals, training
   completion records, risk acceptance tickets).
3. Approved documents (policies, standards, procedures) with an owner and a
   review date.
4. 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.

```mermaid
flowchart LR
  A["Define scope and versions"] --> B["Collect evidence per task"]
  B --> C["Score tasks I / P / N / NA"]
  C --> D["Calibration review"]
  D -->|"Score challenged"| B
  D --> E["Gap analysis and POA&M"]
  E --> F["Executive approval"]
  F --> G{"Attestation requested?"}
  G -->|"Yes"| H["Sign statement (section 12)"]
  G -->|"No"| I["Publish internally"]
  H --> J["Track POA&M and reassess"]
  I --> J
```

## 3. Summary of results

<!-- Guidance: Give executives one table and three sentences. Pitfall: reporting only the percentage; a single unaddressed high-impact task (for example no protection of code from tampering) matters more than the average. -->

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 | NA | Task coverage | Weighted conformance |
|---|---|---|---|---|---|---|---|
| PO, Prepare the Organization | 13 | *Example:* 7 | 6 | 0 | 0 | 53.8% | 76.9% |
| PS, Protect the Software | 4 | *Example:* 3 | 1 | 0 | 0 | 75.0% | 87.5% |
| PW, Produce Well-Secured Software | 16 | *Example:* 9 | 5 | 2 | 0 | 56.3% | 71.9% |
| RV, Respond to Vulnerabilities | 9 | *Example:* 4 | 3 | 2 | 0 | 44.4% | 61.1% |
| **Total** | **42** | **23** | **15** | **4** | **0** | **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)

<!-- Guidance: PO tasks are about people, process and environment. Evidence is often a policy plus a record that shows it operating. Pitfall: citing a policy that nobody has reviewed since it was written. -->

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)

<!-- Guidance: PS tasks protect code and releases from tampering. Evidence is usually configuration exports and release records. Pitfall: protecting the main branch but not build definitions, infrastructure code or release tags. -->

| 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)

<!-- Guidance: PW is the largest group and the one buyers question most. Sample real repositories, not the best-run team. Pitfall: confusing "a scanner exists" with "findings are triaged and fixed". -->

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)

<!-- Guidance: RV covers finding, fixing and learning from vulnerabilities after release. Link to the PSIRT procedure rather than restating it. Pitfall: measuring only time to fix and never asking why the class of flaw keeps appearing. -->

| 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

<!-- Guidance: One POA&M item can close several tasks. Every P or N task must map to an item, an owner and a date. Pitfall: dates without funding; record the budget or capacity decision. -->

| 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

<!-- Guidance: Use this section when a task is not implemented but the risk is reduced another way. Pitfall: treating a compensating control as "Implemented"; keep the task status honest and explain the mitigation here. -->

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:

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

## 10. SSDF Version 1.2 draft additions (not final)

<!-- Guidance: Use this section to prepare for the next version, not to claim conformance. Pitfall: copying draft text into contracts; drafts change. -->

> **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)

<!-- Guidance: Complete only if you train, fine-tune or distribute AI models, or build products on them in a way that SP 800-218A covers. Pitfall: applying this profile to a product that only calls a hosted model API; most added tasks then do not apply. -->

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 | Evidence | 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)

<!-- Guidance: Sign only what the evidence supports. The statement is a summary of sections 3 to 9, not a separate claim. Pitfall: a blanket "we comply with SSDF" while tasks are open; disclose exceptions and the POA&M instead. -->

### 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].
>
> 1. The results are recorded in [SSDF-ASSESS-001, version], which lists
>    the status and evidence for each SSDF task.
> 2. [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]).
> 3. Compensating controls are in place for the exceptions listed in
>    [EXC-001, EXC-002].
> 4. 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

<!-- Guidance: An assessment ages quickly. Define what triggers a refresh. Pitfall: a signed statement that outlives the practices it describes. -->

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

<!-- Guidance: Map each practice to the internal document or control that implements it, so that reviewers can follow the trail. Pitfall: mapping every practice to one generic security policy. -->

| 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

<!-- Guidance: Keep definitions short and consistent with SP 800-218 usage. -->

### 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.