An analyzed SBOM is generated by inspecting a finished artifact, such as an executable, package, container or virtual machine image, after it was built. You need one when you lack source code or build access, for example with a supplier binary or legacy firmware. Expect useful coverage with some omissions.
Definition
CISA's community paper on SBOM types defines the analyzed type as an SBOM produced through analysis of artifacts after the build, and notes that this generally requires a variety of heuristics. In some contexts it may be called a third party SBOM. It is typically generated by third party tooling.
When it is the right choice
The paper lists these benefits:
- It gives visibility without an active development environment, such as for legacy firmware.
- It does not need access to the build process.
- It can help verify SBOM data from other sources.
- It may find hidden dependencies other creation tools missed.
Three common situations fit:
- A supplier gives you a binary and no SBOM.
- An acquired product has no surviving build pipeline.
- You want to cross check a supplier SBOM against what is actually in the artifact.
Limits to plan for
The paper is direct that an analyzed SBOM may be prone to omissions, errors or approximations if the tool cannot decompose or recognize components precisely, and that it may depend on heuristics or context specific factors. Practically, that means:
| Risk | What it looks like | What to do |
|---|---|---|
| Missed component | A statically linked library is not reported | Compare against a supplier SBOM if one exists |
| Wrong version | A version is guessed from a string in the binary | Treat low confidence entries as leads, not facts |
| Duplicates or noise | The same library appears under two names | Normalize identifiers before matching |
| Unknown supplier | Supplier field is blank | Record it as unknown rather than guessing |
A simple review routine
Run these steps when you receive or create an analyzed SBOM:
- Note the type in your records: analyzed, produced by which tool, on which date.
- Spot check five components by hand. Open the artifact, find the library, and confirm the version.
- Flag entries with low confidence or missing identifiers.
- Match against vulnerability data, then treat findings as candidates until confirmed.
- Ask the supplier for a build SBOM and compare the two. Differences tell you where heuristics fell short.
Step 5 is the most valuable. A build SBOM is made during the build and is typically more accurate for what went into the artifact, while an analyzed one shows what remains in the finished result. When they disagree, you learn something either way.
Do not overclaim it
When you pass an analyzed SBOM to a customer or auditor, say how it was made. Calling it complete invites a claim you cannot support. A short note such as "generated by analysis of the released artifact on this date; may contain omissions" is honest and still useful.
For a wider view of the other types, see the six SBOM types.
Safeguard scans dependencies and container images and builds SBOMs, which gives you an analyzed view of artifacts you cannot rebuild. The free scan is at gold.safeguard.sh/scan.
Quick check
Is an analyzed SBOM as accurate as a build SBOM?
Not necessarily. The paper says analysis relies on heuristics and may have omissions or approximations. A build SBOM uses data available during the build.
Can an analyzed SBOM find things a source SBOM missed?
Yes. The paper notes it may find hidden dependencies that other creation tools missed.
Sources
Last reviewed: 19 October 2026.
