An SBOM is not one thing. A CISA facilitated working group describes six types: design, source, build, analyzed, deployed and runtime. They differ in when and how the data is gathered, so they differ in what they can see and what they miss.
The six types
Design. A list of intended components for software that is not built yet. It can include components that do not exist. It is useful for spotting licensing conflicts before you buy or commit, and it is hard to make and short on detail.
Source. Created from the development environment, source files and declared dependencies, usually by software composition analysis. It shows the dependency tree without needing the build. It can list components that never ship, and may miss platform libraries and plugins.
Build. Produced during the build that creates the releasable artifact. Because it sees build data, confidence that it matches the artifact is higher, and the same workflow can sign both. The cost is that you may have to change the build, and dynamically linked dependencies may differ at runtime.
Analyzed. Made by examining finished artifacts such as executables, packages, containers and images. The document says this is sometimes called a third party SBOM. It works without access to the build, and can find hidden dependencies, but it relies on heuristics and can have omissions or approximations.
Deployed. An inventory of software present on a system, often assembled from other SBOMs plus configuration. It shows what is installed, but may not reflect what actually runs.
Runtime. Created by instrumenting a running system to capture what is present and loaded, including dynamically loaded components and external call outs. It needs the system to run, and some detail only appears after the system has exercised its functions.
They overlap
The document says the list is not tightly tied to the software lifecycle, and one SBOM document may combine information from more than one type. A build SBOM can be assembled from intermediate source and build SBOMs, for example.
What this means in practice
No single type answers every question. If you want to fix a vulnerable dependency at its origin, source data helps. If you want to know what a customer received, build or analyzed data is closer. If you are asking what is live right now, you need deployed or runtime data.
The honest move is to label which type you are sending. A buyer who receives a source SBOM and assumes it describes the shipped binary will draw wrong conclusions.
Two cautions
First, the document itself says it was drafted by a community working group and is not an official US government document. Treat it as a shared vocabulary.
Second, the names are about method, not quality. A careful analyzed SBOM can beat a sloppy build SBOM.
Safeguard's SBOM and dependency scanning can build inventories from your repositories and images. You can try a free scan at gold.safeguard.sh/scan.
For a related comparison, see runtime SBOM versus build time SBOM.
Quick check
Which type is also called a third party SBOM?
Analyzed, because it is produced by examining artifacts after the build, often by someone other than the author.
Can one file be more than one type?
Yes. The CISA document says an SBOM document may combine information for multiple types.
Sources
- CISA, Types of Software Bill of Materials (SBOM)
- Types of Software Bill of Material (SBOM) Documents, PDF
Last reviewed: 19 October 2026.
