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 components under NIST SP 800-218 SSDF

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

SSDF Version 1.1 covers acquired and in-house components across their life cycles. The organization defines its requirements, approval criteria, and risk responses.

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

Treat components as release-specific dependencies with life-cycle records. PW.4 covers acquiring, creating, maintaining, and verifying commercial, open-source, other third-party, and in-house components. PS.3.2 covers provenance for every release's components, and RV.1.1 covers ongoing vulnerability information. In SSDF Version 1.1, PW.3 is retired and its acquired-software work is incorporated into PW.4.

Search this module

Find a question or answer quickly

2 of 2 questions
Question 1

How to decide whether a component belongs in scope under NIST SP 800-218 SSDF

Include a software library, module, middleware, framework, service, reusable in-house module, or other dependency when it is part of the covered software or its operation and falls under the organization's component requirements. Distinguish shipped components from build-only dependencies and hosted or platform services, then document who performs each applicable SSDF task under the delivery model.

For each governed component, record its source and supplier, exact version or other identifier, expected use, applicable requirements, integrity and provenance information, evaluation result, secure configuration, approval or exception, maintenance status, known-vulnerability status, and the releases that use it. An SBOM can carry part of this inventory and provenance, but it does not replace evaluation, approval, or vulnerability response.

Re-evaluate a component when its expected use changes materially. Continue checking whether it is maintained, whether known vulnerabilities remain unaddressed, and whether integrity can still be confirmed. Record an update, replacement, mitigation, or other risk response for unsupported or vulnerable components.

  • Requirements or acquisition owner: define security requirements for supplied components and communicate them to relevant third parties.
  • Engineering owner: select the component for its expected use, apply the approved secure configuration, and map it to affected releases.
  • Security or component reviewer: evaluate provenance, integrity, maintenance, known vulnerabilities, and compliance with organization-defined requirements.
  • Release decision-maker: approve the version or record an exception and risk response for the affected release.
  • Operations or response owner: monitor new vulnerability information and coordinate update, mitigation, replacement, or communication.
Citations
NIST SP 800-218 SSDF v1.1

PO.1.3 addresses requirements for third-party components. PW.4.1, PW.4.2, and PW.4.4 cover acquired and in-house components, provenance, approved versions, secure configuration, maintenance, integrity, known vulnerabilities, and life-cycle verification.

Question 2

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

Evidence should let a reviewer trace the component from source and approval to each affected release and later vulnerability decision. Keep supplier representations and inherited platform or service evidence separate from work performed by the software producer.

For a component that cannot meet a requirement, record the gap, affected software, decision authority, chosen risk response, compensating action, owner, and reassessment trigger. SSDF does not make every component defect an automatic release block; the organization's documented criteria and risk decision control.

  • Identify the component, exact version, source or supplier, expected use, applicable configuration, and every affected release.
  • Retain the applicable requirements, evaluation result, integrity and provenance checks, known-vulnerability review, maintenance status, and approval.
  • Identify which evidence comes from a supplier or service provider and which checks the producer performed.
  • Record unresolved gaps, approved exceptions, update or replacement plans, and the responsible decision authority.
  • Update provenance data whenever a release component changes and make it available to the teams that need it for operations and response.
  • Reassess after a new version, changed use, end-of-life notice, supplier change, integrity concern, or new vulnerability information.

Which software components belong in an NIST SSDF review?

Include commercial, open-source, other third-party, and in-house reusable components that are part of the covered software or its operation and fall under the organization's component requirements. Identify shipped libraries and frameworks, build-only dependencies, and hosted or platform services separately because the producer, supplier, and service provider may perform different tasks. The expected use and delivery model determine the applicable checks.

What evidence should be kept for each ?

Keep the component's exact identity and version, source or supplier, expected use, applicable requirements and configuration, integrity and provenance information, evaluation result, approval or exception, maintenance status, known-vulnerability review, and every affected release. Mark which evidence the supplier provided and which checks the software producer performed. An SBOM can carry part of the inventory but does not replace evaluation or risk decisions.

When should a component decision be reassessed?

Reassess after a new version, changed expected use, supplier or source change, end-of-life or maintenance notice, integrity concern, new vulnerability information, changed release scope, or a material requirement change. If a component cannot meet a requirement, record the gap, affected software, decision authority, risk response, compensating action, owner, and next reassessment trigger.

Citations
NIST SP 800-218 SSDF v1.1

PW.4.4 covers life-cycle verification, known vulnerabilities, maintenance, integrity, and action for unsupported components. PS.3.2 covers release-component provenance. RV.1.1 covers ongoing vulnerability information for third-party components.

Recommended next step

Apply the component decision under NIST SP 800-218 SSDF

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.4.4 covers life-cycle verification, known vulnerabilities, maintenance, integrity, and action for unsupported components. PS.3.2 covers release-component provenance. RV.1.1 covers ongoing vulnerability information for third-party components.
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 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.
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.