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.

FAQGLOBALNIST SP 800-218 SSDF

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

A standalone answer for teams deciding how threat modeling should be scoped, evidenced, assigned, and reviewed under NIST SP 800-218 SSDF.

SSDF Version 1.1 names threat modeling, attack modeling, and attack-surface mapping as options. It does not prescribe one method or template.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Questions
2

Structured answer sets in this page tree.

Primary sources
1

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Use as a risk-based design activity. PW.1.1 recommends forms of risk modeling, including threat modeling, attack modeling, and attack-surface mapping. PW.1.2 calls for tracking security requirements, risks, responses, design decisions, and approved exceptions. SSDF Version 1.1 does not prescribe one modeling method, diagram, or cadence.

Search this module

Find a question or answer quickly

2 of 2 questions
Question 1

Use threat modeling to assess software risk

Define the software and release scope, assets and sensitive data, operating assumptions, trust boundaries, external dependencies, entry points, threat actors or abuse cases relevant to the product, and the risk criteria used. Apply more rigorous assessment to higher-risk areas when the organization's analysis calls for it.

Convert material findings into security requirements, design changes, tests, monitoring, or another documented risk response. Record the rationale for mitigations and approved exceptions. PW.2.1 recommends review by a qualified person not involved in the design and/or by automated processes in the toolchain.

Review the model when architecture, data flows, dependencies, deployment conditions, security requirements, threat information, or material vulnerabilities change. A calendar can support that process, but SP 800-218 does not set a universal review interval.

  • Product and engineering owners: define the software, release, environment, and assumptions covered by the model.
  • Design and security participants: identify relevant risks and connect them to requirements, mitigations, tests, and owners.
  • Independent or automated reviewer: check whether the design meets its security requirements and addresses the modeled risks.
  • Decision authority: approve any exception with its rationale, scope, owner, and reassessment trigger.
  • Model owner: update the record when a material input or design decision changes.
Citations
NIST SP 800-218 SSDF v1.1

PW.1.1 addresses risk modeling. PW.1.2 covers security requirements, risks, responses, design decisions, and approved exceptions. PW.2.1 covers review of the design and risk models and recording the findings.

Question 2

What evidence should support threat modeling under NIST SP 800-218 SSDF?

The evidence should show the model's scope and assumptions, identified risks, security requirements, chosen responses, design-review findings, owners, exceptions, and update history. A diagram without decisions or follow-through is incomplete evidence.

  • Identify the software, release, architecture, data flows, deployment context, dependencies, and assumptions in scope.
  • Record the method, participants, date, inputs, risk criteria, identified threats or abuse cases, and affected assets or boundaries.
  • Trace each material risk to a security requirement, mitigation, test, monitoring action, or approved risk response.
  • Record design-review findings, corrections, unresolved gaps, and the authority for each approved exception.
  • Assign an owner and update trigger for architecture, dependency, environment, requirement, threat, and vulnerability changes.

Does NIST SP 800-218 require one threat-modeling method?

No. PW.1.1 recommends forms of risk modeling such as , attack modeling, or attack-surface mapping, but NIST SP 800-218 does not prescribe one method, diagram, template, or cadence. Choose a method and level of rigor that fit the software, release, operating context, and risk, and record the scope and assumptions so another reviewer can understand the result.

What should a threat-modeling record contain?

Identify the software and release, architecture and data flows, deployment context, dependencies, assets, assumptions, trust boundaries, entry points, relevant threats or abuse cases, participants, date, method, and risk criteria. Trace each material risk to a security requirement, design change, test, monitoring action, or other risk response, and record owners, review findings, unresolved gaps, and approved exceptions.

When should a threat model be updated under NIST SSDF?

Update or reassess the model when architecture, data flows, dependencies, deployment conditions, security requirements, operating assumptions, threat information, or material vulnerabilities change. A calendar review can supplement those triggers, but NIST SP 800-218 does not set a universal interval. Keep the prior decisions and the reason for each change in the model's history.

Citations
NIST SP 800-218 SSDF v1.1

PW.1.1 and PW.1.2 support the scope, risk, response, decision, and exception record. PW.2.1 supports independent or automated design review and recorded review findings.

Recommended next step

Put this NIST SSDF guidance into practice

Use the cited SSDF tasks to define the scope, assign owners, list the required records, and set the decision or review point.

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 the decision.

Explore next step
Primary sources

References and citations

NIST SP 800-218 SSDF v1.1
doi.org
Referenced sections
  • PW.1.1 and PW.1.2 support the scope, risk, response, decision, and exception record. PW.2.1 supports independent or automated design review and recorded review findings.
Related guides

Explore more topics

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 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.
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.
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 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.
NIST SSDF vs SP 800-53 SA controls: practice-to-control mapping table
Compare NIST SSDF and NIST SP 800-53 SA controls with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
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.