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.

Artifact GuideGLOBALNIST SP 800-218 SSDF

NIST SP 800-218 SSDF SSDF Self-Attestation Guide

SP 800-218 does not require a . Before preparing one, confirm that an agency, contract, procurement term, or assurance program currently requests it.

OMB M-26-05 rescinded M-22-18 and M-23-16 on January 23, 2026. Federal agencies may still choose the CISA/OMB Secure Software Development Attestation Form or set other risk-based assurance terms, so the requesting authority now controls the form, scope, signer, submission route, and update trigger.

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

SP 800-218 supplies a vocabulary of secure development practices and tasks. It does not require producers to submit a , prescribe an attestation form, or certify an organization. The former U.S. government-wide attestation policy in Office of Management and Budget (OMB) memoranda M-22-18 and M-23-16 was rescinded on January 23, 2026. An agency or contract may still request the common form from the Cybersecurity and Infrastructure Security Agency (CISA) and OMB or another risk-based assurance statement, so obtain the current request before drafting or reusing an attestation.

Section 1

Separate SSDF guidance from the attestation requirement

Appendix A maps SSDF practices and tasks to Executive Order (EO) 14028 Section 4e topics, and the publication notes related producer-acquirer communication guidance. That mapping does not make every SSDF task a universal federal representation.

OMB M-26-05 replaced the former government-wide attestation direction with an agency risk-based approach. Agencies must maintain software and hardware inventories and assurance processes suited to mission needs; they may choose to use the common Secure Software Development Attestation Form.

Capture the exact source of the request before drafting: the acquiring organization, covered transaction, incorporated policy or contract clause, required form or questionnaire, software boundary, submission recipient, signer authority, and resubmission trigger.

  • SSDF source layer | Which PO, PS, PW, or RV practices and tasks describe the claimed outcome?
  • Authority layer | Which external requirement asks for the representation, and what exact wording and scope does it use?
  • Evidence layer | Which current records support each representation, and which responsibilities are inherited or supplier-performed?
  • Approval layer | Who can make the representation for the producer, and what legal, procurement, security, and engineering review is required?
Section 2

Define the covered software and representation

Scope the statement to named software or product families, versions or release processes, development and build environments, producer entities, and included suppliers. Avoid enterprise-wide language when evidence covers only one pipeline or product.

For each representation, record whether it is fully performed by the producer, inherited from a platform, performed by a supplier, subject to an approved exception, or not applicable under the requesting authority.

  • Use the requesting authority's definitions and date rules rather than inventing an SSDF deadline.
  • Map the representation to SSDF task identifiers without claiming that the mapping is NIST approval.
  • List exclusions, exceptions, compensating measures, and supplier dependencies in language the recipient can evaluate.
  • Reject or qualify a representation when evidence is stale, scope is unknown, or the signer cannot reasonably rely on the supporting record.
Section 3

Build a claim-to-evidence record

Build the record from the requested representation backward. For each statement, identify the covered software, applicable SSDF task, implementation owner, evidence period, exceptions, and reviewer.

Evidence must support the requested wording and scope. A policy or scanner license shows intent or capability, not that a practice operated for the covered software. If the requester uses the CISA/OMB form, compare the evidence with the form's actual representations rather than assuming that a complete mapping to all 42 SSDF tasks is required.

  • Representation text, requesting authority, covered software, producer entity, and submission recipient.
  • Mapped SSDF practice and task identifiers, implementation owner, and supplier or inherited responsibility.
  • Current operating evidence, evidence period, reviewer, known limitations, open exceptions, and remediation commitments.
  • Authorized signer, review approvals, submission date, recipient confirmation, and resubmission or change trigger.
Recommended next step

Put this NIST SSDF guidance into practice

Confirm the current request, define the software and representations, test the evidence, verify signer authority, and follow the requesting agency's submission instructions.

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

Check the current authority, form, product scope, evidence gaps, signer approvals, and submission route.

Explore next step
Section 4

Avoid misleading attestation claims

Broad language, unclear authority, stale evidence, copied product scope, and unsupported signer assumptions can make an attestation inaccurate. Resolve them before treating the record as signable.

A producer statement applies only to its stated scope and authority. Recheck it before using it for a different customer, product, period, form, or assurance program.

  • Do not say "NIST certified," "SSDF certified," or "NIST approved"; SP 800-218 defines no such certification.
  • Do not call an internal checklist a federal or imply EO 14028 alone defines the current form and submission process.
  • Do not copy one product's statement to other software with different pipelines, components, suppliers, or evidence.
  • Do not conceal exceptions, inherited responsibilities, stale evidence, or an inability to support a representation.
Section 5

Practical workflow for supplier or producer attestation evidence

Work backward from the requested representation: validate the current authority, define the covered software, map claims to SSDF tasks, test current evidence, resolve or disclose gaps, obtain authorized approval, and use the requesting agency's submission instructions.

Retain the submitted version, evidence index, approvals, receipt if available, exceptions, and triggers for review. Do not assume the former M-22-18 deadlines or a prior submission route still applies.

  • Step 1 | Verify the request | Obtain the current agency instruction, contract term, form, covered transaction, due date, and submission route.
  • Step 2 | Define the statement | Name the producer entity, software, versions or release process, environments, suppliers, exclusions, and evidence period.
  • Step 3 | Test each representation | Map it to relevant SSDF tasks and current operating evidence; record inherited work, exceptions, gaps, and limitations.
  • Step 4 | Approve and submit | Use the required wording, confirm signer authority, complete legal, procurement, security, and engineering review, and submit through the requesting authority's channel.
  • Step 5 | Maintain | Retain the signed statement and support, then reassess when the software, pipeline, supplier, evidence, representation, contract, or agency direction changes.
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org6 citations
Referenced sections
  • Defines the secure-development practices and tasks that may support a representation; it does not create a universal attestation or certification.
  • Appendix A maps EO 14028 Section 4e topics to SSDF practices and tasks; Sections 1 through 3 describe the framework's audience, outcomes, and risk-based use.
  • Sections 2 and 3 support scoped, risk-based implementation and distributed responsibility across producers, providers, and consuming organizations.
Show 3 more
  • Table 1 provides the task outcomes and implementation examples that can be mapped to a representation; the examples are optional and non-exhaustive.
  • The publication defines recommended practices and tasks, not an SSDF certification or approval program.
  • Provides the SSDF practices and tasks used to analyze the secure-development representations.
CISA Secure Software Development Attestation Form
cisa.gov4 citations
Referenced sections
  • Official resource page for the common form and submission instructions when an agency chooses to use it.
  • Official CISA resource page for the common form and its submission instructions. Under M-26-05, an agency may choose this resource; confirm the agency's current directions before relying on its form or channel.
  • Provides the official common form and instructions used when an agency chooses that resource.
Show 1 more
  • Official common-form resource to use when the requesting agency selects it, subject to that agency's current submission instructions.
OMB Memorandum M-26-05: Adopting a Risk-based Approach to Software and Hardware Security
whitehouse.gov4 citations
Referenced sections
  • Current federal policy source: rescinds M-22-18 and M-23-16 and permits agencies to use the common attestation form as one risk-based assurance resource.
  • Rescinds M-22-18 and M-23-16, directs agencies to use risk-based assurance policies, and permits agencies to keep using resources such as the Secure Software Development Attestation Form.
  • Establishes the current agency risk-based approach and rescinds the former M-22-18 and M-23-16 government-wide requirements.
Show 1 more
  • Controls the current federal policy status: the prior memoranda are rescinded and agencies may choose government-wide resources such as the common form.

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 Workflow

Validate an SSDF-based attestation request, bound the covered software and producer, test each representation against evidence, and retain the signed submission.

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.