NIST SSDF and SBOMs: Meeting SP 800-218 Software Supply-Chain Expectations
The NIST Secure Software Development Framework turns secure development into a checklist, and an SBOM is a named part of it. Here is where SP 800-218 asks for an SBOM and how to deliver it.
- NIST SP 800-218 (SSDF v1.1) organises secure development into four practice groups: prepare, protect, produce and respond.
- Practice PS.3.2 asks organisations to collect and share provenance data for every component, for example as an SBOM.
- The SSDF underpins US federal secure-software attestation, so SBOMs matter for selling to the US government.
- A companion profile, SP 800-218A, extends the SSDF to generative AI.
What the SSDF is
NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, is a set of software-development practices for reducing vulnerabilities in released software [1]. It is organised into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). It is widely referenced in procurement and underpins US federal secure-software attestation.
Where the SBOM appears
The SBOM is named directly in practice PS.3.2: collect, safeguard, maintain and share provenance data for all components of each software release, for example in a software bill of materials [1]. In plain terms, the SSDF expects you to know and be able to share what your software is made of, which is precisely what an SBOM delivers.
| SSDF practice | SBOM contribution |
|---|---|
| PS.3.2 provenance | A per-release SBOM of all components |
| PW.4 reuse secure components | Visibility of third-party components and their risk |
| RV.1 identify vulnerabilities | SBOM correlated with CVEs to find affected releases |
SSDF and US federal attestation
Under US federal policy, software producers selling to the government attest to following SSDF-aligned practices. An SBOM programme is a practical way to evidence PS.3.2 and to answer the vulnerability questions that follow a disclosure. Even outside US public-sector sales, the SSDF is a well-regarded baseline that aligns closely with the EU CRA SBOM expectations.
Generative AI: SP 800-218A
NIST published SP 800-218A, an SSDF community profile for generative AI, extending these practices to AI models and the data and pipelines around them [2]. For AI builders, an AI BOM is the natural companion to the SBOM under that profile.
How IntelliXBOM helps
IntelliXBOM generates and ingests SBOMs in CycloneDX and SPDX, keeps a dated SBOM for every release to evidence PS.3.2, and correlates components with vulnerabilities for RV practices. It supplies evidence aligned to the SSDF; it does not issue the attestation, which remains the producer's responsibility.
Frequently asked questions
Does NIST SP 800-218 require an SBOM?
The SSDF names the SBOM in practice PS.3.2 as a way to collect and share component provenance. It is framed as an example of meeting the provenance practice rather than a standalone mandate, but in practice an SBOM is how organisations satisfy it.
How does the SSDF relate to US federal attestation?
US federal policy requires software producers to attest to SSDF-aligned secure-development practices when selling to the government. SBOMs help evidence the provenance and vulnerability-response practices.
Is there an SSDF profile for AI?
Yes. NIST SP 800-218A is a community profile that extends the SSDF to generative AI development, where an AI BOM complements the SBOM.
Sources
- SP 800-218: Secure Software Development Framework (SSDF) v1.1NISTcsrc.nist.gov/pubs/sp/800/218/final
- SP 800-218A: SSDF Community Profile for Generative AINISTcsrc.nist.gov/pubs/sp/800/218/a/final
- Software Bill of Materials (SBOM)CISAwww.cisa.gov/sbom
- CycloneDX Bill of Materials standardOWASP CycloneDXcyclonedx.org/
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.