A design SBOM lists the components you intend to include in a new product, before the software exists. CISA's community paper on SBOM types describes it as an SBOM of intended, planned software. It is useful for spotting licensing conflicts and agreeing an approved component list early, but it holds less detail than later types.
Where it sits among SBOM types
Most teams meet SBOMs at the end of the pipeline: a scan of a repository or an image. The design type sits at the other end. It is derived from a design specification, an RFP or an initial concept, and it may name components that have not been written or chosen in final form.
The paper's wording matters. It says the design type may include components "some of which may not yet exist". That is not a flaw. It is the point. You are recording intent so it can be checked.
What the paper says it is good for
The paper lists two main benefits:
- It can highlight incompatible components ahead of licensing, purchase or acquisition.
- It can define an approved or recommended component list for developers to use.
It also states limits. A design SBOM may be very difficult to generate, and it is unlikely to identify as much detail as the other types.
A worked example
Imagine a team planning a small web service. Before any code, they list intended components in a spreadsheet or draft SBOM:
| Planned component | Purpose | Check before commit |
|---|---|---|
| A web framework | Request handling | Is its license compatible with how we distribute? |
| A database driver | Data access | Is it maintained, and by whom? |
| A PDF library | Report export | Does an alternative with a simpler license exist? |
| An open source auth library | Sign in | Does it match our approved list? |
Nothing here is scanned yet. The value is that legal, security and engineering can object before the team has built on a component they later have to rip out.
How a design SBOM becomes useful later
A design SBOM is a baseline. Once code exists, a source SBOM from your repository can be compared against it. Differences are worth a conversation:
- A component appears in source that was never in the design. Was it approved?
- A planned component never shows up. Was the plan dropped, or is it vendored somewhere your scanner does not read?
- A version or license differs from what was agreed.
That comparison is a lightweight governance check. It does not need special tooling to start. A shared document and a review step in the pull request template are enough.
What it cannot do
Because it describes intent, a design SBOM cannot say what actually shipped. It does not replace a build or analyzed SBOM for vulnerability matching, and it should never be handed to a customer as proof of what is in a release. Label it clearly as a plan.
The paper notes that an SBOM document may combine multiple types, so a team may later merge the design list into a fuller document. When it does, mark which entries were planned and which were observed.
Safeguard's SBOM and dependency scanning covers the observed side, so you can compare what you built with what you planned. You can try the free scan at gold.safeguard.sh/scan. For the full set of types, see the six SBOM types.
Quick check
Can a design SBOM be used for vulnerability scanning?
Not reliably. It records planned components, some of which may not exist yet, so use a source, build or analyzed SBOM for matching.
Who benefits from a design SBOM?
Legal and procurement teams checking license compatibility, and developers who need an approved component list.
Sources
Last reviewed: 19 October 2026.
