CISA describes six types of SBOM: design, source, build, analyzed, deployed and runtime. They differ by when and how the list is made. A source SBOM comes from your code, a build SBOM from the build, an analyzed SBOM from the finished file, and a deployed SBOM from what is installed.
TL;DR
- The type tells you where the data came from, and so how far to trust it for a given question.
- No single type is complete. Each has benefits and limits.
- A new minimum element, SBOM Generation Context, asks authors to say which phase their SBOM reflects.
- When you ask a supplier for an SBOM, ask which type it is.
Definition. An SBOM type, in CISA's working group paper, describes the stage and source of the data used to build the list. The paper says an SBOM document may combine information for multiple types.
Why are there different types of SBOM?
Imagine counting the ingredients in a cake. You could read the recipe before baking. You could watch while it is mixed. You could taste the finished cake and guess. You could look at the cake already sitting on someone's table. Each way gives a slightly different list.
SBOMs work the same way. CISA's paper on SBOM types, drafted by a community working group CISA facilitated, explains that "an SBOM may contain different forms of the minimum information sourced from different product artifacts." Tool outputs vary and "provide value in different use cases."
It also says the list of types is "not intended to be tightly tied to the software lifecycle." Some types fit more than one phase.
What are the six types?
Here are the definitions from the paper, shortened into plain words.
| Type | Made from | Plain meaning |
|---|---|---|
| Design | A plan or specification | The parts you intend to use, some of which may not exist yet |
| Source | The development environment, source files and included dependencies | What the code says it needs |
| Build | The build process | What went into the releasable file as it was assembled |
| Analyzed | The finished file, such as a package or container, after the build | What an outside tool finds by inspecting it |
| Deployed | The installed system | What is present on a machine |
| Runtime | The running system, instrumented | What is actually loaded and used right now |
The paper adds that an analyzed SBOM is sometimes called a "3rd party" SBOM, and a runtime SBOM may be called an "instrumented" or "dynamic" one.
What are the strengths and limits of each type?
The paper lists benefits and limitations for each. Here is a summary.
| Type | Benefit | Limit |
|---|---|---|
| Design | Spots incompatible components before you buy or build | Hard to produce, less detail than other types |
| Source | Needs no access to the build; shows the dependency tree; helps fix at the source | Can show components that never run or are compiled out |
| Build | Raises confidence that the list matches the artifact; can be signed with the artifact | May require changing the build; hard to capture indirect or runtime dependencies |
| Analyzed | Works without a development environment, such as for old firmware; can find hidden dependencies; can check other SBOMs | May have omissions or errors if the tool cannot recognize components |
| Deployed | Shows what is installed on a system, including system components | May not match the running environment |
| Runtime | Shows what is in use, including dynamically loaded parts | Needs the system to be running and observed; details appear only after it has been used |
A few of these statements deserve a closer look.
Source SBOMs can overstate. The paper says they "can highlight components (which might have vulnerabilities) that never run or are compiled out in deployed code." This explains why a source SBOM can show more alerts than a deployed one.
Build SBOMs add confidence. They are made at the time of the build, so the paper says they "increase confidence that the SBOM representation of the product artifact is correct." It also notes they allow signing the SBOM and the product by the same build workflow.
Analyzed SBOMs are for when you have no source. A customer who receives a finished file and wants to check it can analyze it. The paper says this can help "verify SBOM data from other sources."
What is SBOM Generation Context?
The 2026 minimum elements guidance, published by CISA with agencies from many countries, adds a new element for exactly this reason. SBOM Generation Context is defined as "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM."
It does not force you to use the six names. General references such as "before build," "build," and "after build" can satisfy it, and so can more specific identifiers. The guidance gives an example: an SBOM generated from source code could be marked "before build," and binary analysis tools can produce an SBOM "after build."
So a reader can look at one field and learn how much weight to give the list.
Which type should I ask for or make?
Match the type to the question.
- "What do we plan to depend on?" Ask for a design SBOM, or review your own approved component list.
- "What does this project's code require?" Use a source SBOM. It is quick and helps developers fix things early.
- "What is in this exact release?" Use a build SBOM, made in the pipeline when the release is created.
- "Can I double check what a supplier sent me?" Make an analyzed SBOM from their finished file and compare.
- "What is installed on our servers today?" Use a deployed SBOM.
- "What is actually loaded when it runs?" Use a runtime SBOM, where tooling allows.
For most software teams, a build SBOM for each release is the most useful starting point. It is tied to the thing you shipped. You can then add an analyzed SBOM of the final container or package as a cross check.
Worked example: one product, three lists
The numbers below are invented to illustrate why the types differ.
A team builds a container based service.
| SBOM type | Invented component count | Why it differs |
|---|---|---|
| Source | 180 | Counts everything the project files ask for, including a test library that never ships |
| Build | 168 | Leaves out the 12 development only packages that were not part of the release |
| Analyzed (the final image) | 231 | Adds 63 operating system packages from the base image |
All three are honest. They answer different questions. If the customer asks, "Which operating system packages are in the container?" only the analyzed list can answer, because the other two do not look at the base image.
If the team had shared only the source list, the customer would have seen 180 entries (about 78 percent of 231) and missed the base image entirely. Marking each with its generation context removes the confusion.
For more on getting the first SBOM out the door, see how to create your first SBOM and how to generate an SBOM from a container image.
Try it yourself
In the demo below, scan a container image and look at what appears: not just your own packages, but the system packages that came with the base image. This is what an analyzed SBOM can reveal that a source SBOM cannot.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning covers project dependencies and can also scan container images, with SBOMs available in SPDX and CycloneDX. Scanning in the pipeline gives you a fresh SBOM for each release. Reachability analysis then separates packages that are present from packages your code can reach.
A free scan at gold.safeguard.sh/scan lets you try this on a real project. The Safeguard CLI can run the same checks locally or in CI, and it can also write code where a fix calls for it.
Quick check
Which SBOM type should I use?
No single type answers every question. Build SBOMs are tied to a release, analyzed SBOMs can check a finished file, and runtime SBOMs show what is in use. Choose by the question you need to answer.
Why does my source SBOM show more packages than my deployed one?
A source SBOM can list components that never run or are compiled out of the final software. CISA's paper names this as a limitation of the source type.
What is an analyzed SBOM?
It is a list made by inspecting a finished artifact, such as a package or container image, after the build. It is sometimes called a third party SBOM.
Sources
- CISA, Types of Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
Last reviewed: 19 October 2026.
