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 attestation form or certification scheme. The requesting contract, agency, or assurance program controls what must be stated and submitted.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

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 CISA/OMB form 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.

Sources for this answer

NIST SP 800-218 SSDF v1.1

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.

CISA Secure Software Development Attestation Form resource page

CISA hosts the common form and its submission materials. Confirm that the requesting agency currently uses this resource before applying its scope or instructions.

OMB Memorandum M-26-05: Adopting a Risk-based Approach to Software and Hardware Security

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.

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

Check source coverage, ownership, evidence gaps, and next steps before using or publishing the work.

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.

Sources for this answer

NIST SP 800-218 SSDF v1.1

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.

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.

Sources for this answer

NIST SP 800-218 SSDF v1.1

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.

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.

Sources for this answer

CISA Secure Software Development Attestation Form resource page

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.

Primary sources

References and citations

CISA Secure Software Development Attestation Form resource page

cisa.gov

Referenced sections

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.

NIST SP 800-218 SSDF v1.1

doi.org

Referenced sections

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"

OMB Memorandum M-26-05: Adopting a Risk-based Approach to Software and Hardware Security

whitehouse.gov

Referenced sections

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