NIST SP 800-218 SSDF FAQ: practical implementation questions

Use code scanning when the organization's risk-based process selects code analysis under PW.7 or executable testing under PW.8. Define the covered code and release, method, criteria, configuration, and known exclusions.

Record and triage findings and recommended remediations in the team's workflow or issue tracker. Connect material findings to fixes and retests, false-positive rationales, or approved risk responses. SSDF does not mandate a scanner, cadence, or universal blocking severity.

Use PW.4 to evaluate, acquire or create, configure, maintain, and verify commercial, open-source, other third-party, and in-house components. Record the exact version, source, expected use, requirements, approval, maintenance status, and affected releases.

Use PS.3.2 to maintain release-component provenance and RV.1.1 to monitor vulnerability information. A software bill of materials (SBOM) may carry part of the record, but it does not replace evaluation, approval, or vulnerability response.

Connect each release to its protected build environment, source and dependencies, approved build tools and configuration, integrity-verification information, provenance, release decision, and archive.

SSDF has no single build-integrity task. PO.3, PO.5, PW.6, PS.1, PS.2, and PS.3 provide related outcomes. Reproducible builds and attestations can add assurance, but SSDF does not universally require either.

Maintain a disclosure and remediation policy, reporting path, and supporting roles and processes. Investigate credible reports, identify affected products and components, analyze risk, implement the selected response, and communicate useful remediation information to affected acquirers.

Then analyze root causes, look for similar vulnerabilities, and update the software development life cycle (SDLC) when appropriate. SSDF does not set universal acknowledgment, remediation, disclosure, or embargo deadlines.

Define release criteria under PO.4 from the software's security requirements and risk decisions. Review the applicable design, component, code, test, build, vulnerability, integrity, provenance, and archive evidence for the exact release.

Record approvals, rejections, and exceptions in the workflow. A passed gate means the organization's criteria were met or formally excepted; it does not prove the software is vulnerability-free or certify SSDF compliance.

PS.3.2 focuses on provenance for all components of each software release. Record enough origin and change history to identify the component and affected releases, protect the record, share it under policy, and update it when a component changes.

An SBOM is one example of a provenance carrier. It does not by itself prove the build process, artifact integrity, release approval, or implementation of the wider SSDF. Link separate build and release evidence when those questions matter.

Use threat modeling or another form of risk modeling under PW.1.1 to assess software risk. Record scope, assumptions, assets, boundaries, relevant threats or abuse cases, risk criteria, and participants.

Trace material findings to security requirements, design decisions, mitigations, tests, monitoring, or approved risk responses. Review the model when architecture, dependencies, deployment conditions, requirements, threats, or material vulnerabilities change.

Keep evidence showing which secure coding practices applied to the language and environment, whether required review, analysis, and testing occurred, what issues were found, and how each issue was resolved or accepted.

Useful evidence can include the coding standard, role-based training when applicable, code-review records, analysis and test results, issue triage, remediation and retest records, and approved exceptions. SSDF does not mandate one artifact format or retention period.