NIST SP 800-218 SSDF How should teams handle components 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. A software bill of materials (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.

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.