We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

WorkflowGLOBALNIST SP 800-218 SSDF

NIST SP 800-218 SSDF SSDF Self-Attestation Workflow

Move from an acquirer's request to a signed statement whose producer, software scope, representations, evidence period, qualifications, and signatory authority are explicit.

NIST SP 800-218 is a set of recommended practices, not a universal form or certification scheme. The requesting contract, agency, or assurance program controls what must be stated and submitted.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
4 sections3 primary sources
Overview

First identify the exact request. NIST SP 800-218 supplies a common vocabulary for secure software development, but the requesting authority defines the representations, covered software, signer, recipient, format, timing, and update conditions. For US federal acquisition, the common form from the Cybersecurity and Infrastructure Security Agency (CISA) and the Office of Management and Budget (OMB) remains an available government-wide resource: OMB Memorandum M-26-05 says agencies may choose that form or set assurance policies and processes that match their risk determinations and mission needs.

Section 1

1. Validate the request before collecting evidence

Obtain the controlling form, contract clause, agency instruction, or customer representation. Record whether the request is mandatory for the transaction, optional assurance, or an internal exercise. Do not assume that every SSDF-based request is the CISA form or that every federal agency uses the same assurance path.

Stop and resolve ambiguity about the requester, legal entity, covered software, representations, due date, submission channel, or signer. A large evidence folder cannot cure an unclear statement.

  • Trigger | An acquirer, contract, agency, or assurance program requests an SSDF-based statement.
  • Owner | Procurement or the contract owner, with legal review where the statement creates a legal or contractual representation.
  • Action | Capture the exact form and instructions, authority, recipient, deadline, definitions, required evidence, and permitted qualifications or alternatives.
  • Evidence | Dated request, controlling document and version, correspondence resolving scope, and named submission channel.
  • Branch | If the request is the CISA common form, use its current instructions. If it is not, do not import the form's scope, claims, or signature language.
Recommended next step

Put this NIST SSDF guidance into practice

Confirm the controlling request, define the producer and software boundary, test each representation, and preserve the signed submission with its evidence index.

Assessment workflow
Open Assessment Autopilot for NIST SSDF

Create cited tasks, evidence requests, and review checkpoints for this NIST SSDF scope.

Explore next step
Talk to Sorena
Review this NIST SSDF scope with Sorena

Review the controlling request, producer and software boundary, supporting records, and signatory authority.

Explore next step
Section 2

2. Bound the producer, software, and responsibility

Name the legal producer making the statement and the products, versions, release processes, environments, and applicability period it covers. State exclusions. Avoid broad labels such as 'all products' unless one controlled development process and the evidence genuinely cover that population.

Map each claimed SSDF practice or requested representation to the team that performs it. Cloud services, platforms, contractors, component suppliers, and shared toolchains may divide responsibility. Record what the producer performs, inherits, or depends on and the agreement that supports inherited responsibility.

  • Trigger | The controlling request and its definitions are known.
  • Owner | Product and engineering define the software boundary; software security maps responsibilities; procurement owns supplier commitments.
  • Action | Record producer entity, product family, versions, delivery model, pipelines, environments, components, suppliers, exclusions, and covered period.
  • Evidence | Scope register, architecture and service boundary, pipeline inventory, supplier agreements, and a responsibility matrix.
  • Branch | If another party performs a practice, verify the agreement and available evidence. Do not silently claim inherited work as the producer's own.
Section 3

3. Map and test each representation

Copy each representation exactly into a claim matrix. Map it to the relevant SSDF practices and tasks, but do not treat every notional implementation example as a required control. NIST says those examples are optional, non-exhaustive, and may not apply to every organization.

Test operating evidence for the covered software and period. Policies show intended practice; records from repositories, pipelines, reviews, tests, releases, and vulnerability response show operation. Record the sample, reviewer, result, exceptions, inherited evidence, and unresolved gaps.

  • Trigger | Scope and responsibility boundaries are approved.
  • Owner | Software security maintains the mapping; implementation owners supply records; an assurance reviewer tests them.
  • Action | For each representation, record the SSDF task, expected outcome, owner, evidence, sample and period, exception, and conclusion.
  • Evidence | Requirements and role records, toolchain audit trails, access and release records, design and code reviews, test results, component records, vulnerability handling, and remediation decisions as applicable.
  • Branch | If a gap contradicts the requested representation, remediate it, use an expressly permitted qualification or alternative, or stop the signature. A future plan is not evidence that the practice currently operates.
Section 4

4. Approve, sign, submit, and maintain

Give the authorized signatory the final representation, exact scope, qualifications, evidence conclusion, unresolved gaps, and submission instructions. Preserve the signed version and receipt separately from the working draft. Limit access to sensitive development and vulnerability evidence; submit only what the controlling request requires.

Set reassessment triggers from the request or contract. Product, pipeline, supplier, producer-entity, representation, authority, or material control changes may require a new review, but only the controlling terms determine whether resubmission is required.

  • Trigger | Every representation has a documented conclusion and blocking gaps are resolved.
  • Owner | Engineering and security approve technical accuracy; legal or contract owners review the representation; only an authorized person signs.
  • Action | Freeze the statement and scope, sign through the required method, submit to the named recipient, and preserve the submitted copy and receipt.
  • Evidence | Approval record, signatory authority, signed statement, submission receipt, evidence index, retention rule, and reassessment triggers.
  • Branch | If the covered facts change, reassess the affected representations and follow the requester's update or resubmission rules. Do not overwrite the prior submission.
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org4 citations
Referenced sections
  • Source for SSDF v1.1 scope, risk-based tailoring, shared responsibility, optional notional examples, and task PO.3.3 on secure-development artifacts.
  • SP 800-218 presents recommended practices that producers and acquirers can use as a common language. It calls for risk-based tailoring and does not prescribe a universal attestation form.
  • SP 800-218 says implementation responsibility may be distributed among providers and tenants. It recommends an agreement that identifies responsibility for each practice and task and how each provider will attest to conformance with that agreement.
Show 1 more
  • SP 800-218 explains that notional implementation examples are not required or exhaustive. PO.3.3 addresses tool-generated artifacts, audit trails, review frequency, retention, and responsibility for artifacts.
"core set of high-level secure software development practices"
CISA Secure Software Development Attestation Form resource page
cisa.gov3 citations
Referenced sections
  • CISA resource page for the federal common form and its submission materials. The requesting agency's current direction controls whether and how the form is used.
  • CISA hosts the common form and its submission materials. Confirm that the requesting agency currently uses this resource before applying its scope or instructions.
  • CISA provides the federal common form and identifies it as one government-wide resource that agencies may choose. The linked form supplies its own representations and submission instructions; other requests may differ.
OMB Memorandum M-26-05: Adopting a Risk-based Approach to Software and Hardware Security
whitehouse.gov2 citations
Referenced sections
  • Current federal policy source for rescission of M-22-18 and M-23-16, agency risk-based assurance, and optional continued use of the common attestation form.
  • Rescinds M-22-18 and M-23-16 and states that agencies may choose the common attestation form or develop assurance policies and processes that match their risk determinations and mission needs.

Related guides

NIST SP 800-218 SSDF Evidence Guide

Build a task-level SSDF evidence index for internal assurance, customers, acquirers, and contract reviews without implying NIST certification.

NIST SP 800-218 SSDF FAQ: practical implementation questions

Practical answers on SSDF Version 1.1 code analysis, components, builds, release gates, provenance, threat modeling, coding evidence, and vulnerability response.

NIST SP 800-218 SSDF implementation playbook

Implement final SSDF v1.1 by defining the software boundary, selecting applicable tasks by risk, assigning shared responsibilities, and retaining task-level evidence.

NIST SP 800-218 SSDF PO, PS, PW, and RV Practice Deep Dive

Map all 19 final SSDF v1.1 practices across PO, PS, PW, and RV, including each group's purpose, handoffs, tailoring decisions, and useful evidence.

NIST SP 800-218 SSDF SBOM and Provenance Workflow

Apply SSDF PS.3.2 to collect, protect, maintain, and share release-component provenance, including an SBOM, while keeping release integrity and component approval separate.

NIST SP 800-218 SSDF Secure Development Practices Guide

Place risk-tailored SSDF v1.1 tasks at the points where teams define requirements, design software, govern components, build, test, release, and respond to vulnerabilities.

Show all related guides (17)

NIST SP 800-218 SSDF Self-Attestation Guide

SSDF v1.1 does not require self-attestation. Check the requesting agency or contract: OMB rescinded the former government-wide mandate in January 2026.

NIST SSDF vs NIST SP 800-53 SA controls: practical side-by-side comparison

Map NIST SSDF tasks to SP 800-53 Rev. 5 SA controls without treating references, shared evidence, or partial overlap as full implementation.

NIST SSDF vs SLSA: practical side-by-side comparison

Compare NIST SSDF v1.1 with SLSA v1.2 Source and Build tracks, including scope, levels, evidence, provenance, verification, and limits.

How should teams handle code scanning under NIST SP 800-218 SSDF?

Decide which code review, analysis, and executable testing apply, then retain scope, results, triage, remediation, and exception records.

How should teams handle components under NIST SP 800-218 SSDF?

Evaluate third-party and in-house components, track source, version, provenance, approval, affected releases, maintenance, and known-vulnerability decisions.

How should teams handle release gates under NIST SP 800-218 SSDF?

Define risk-based release criteria, gather protected evidence, record approvals and exceptions, and bind the decision to the shipped artifact.

How should teams handle threat modeling under NIST SP 800-218 SSDF?

Use risk modeling to assess software risk, connect findings to security requirements and design decisions, and revisit the record when its assumptions change.

How should teams handle vulnerability disclosure under NIST SP 800-218 SSDF?

Run a documented path from vulnerability intake and credibility review through risk-based remediation, acquirer communication, and root-cause feedback.

What build-integrity evidence supports NIST SP 800-218 SSDF?

Connect each release to its protected build environment, approved tool configuration, integrity-verification data, provenance, and archived release record.

What secure coding evidence should teams keep for NIST SSDF SP 800-218?

Keep evidence that shows which secure coding practices applied, how code was reviewed or analyzed, what issues were found, and how each issue was handled.

Why does provenance matter in NIST SP 800-218 SSDF implementation?

SSDF provenance records component origin and change history for each release so acquirers, operations, and response teams can identify affected software.