The six types of SBOM
There is no such thing as “the” SBOM. There are several, produced at different points in the life cycle, and they do not say the same thing. Confusing two types is a recurring source of unexplained discrepancies between teams.
| Type | Produced when | Answers | Reliability |
|---|---|---|---|
| Design | Before development | What you plan to use | Intent |
| Source | From code and manifests | What is declared | Misses the undeclared |
| Build | During the build | What is actually assembled | The most faithful for the CRA |
| Analysed | After the fact, on the artefact | What you find in the binary or image | Depends on the quality of the analysis |
| Deployed | On the target environment | What is installed, configuration included | Includes the environment |
| Runtime | During execution | What is actually loaded | Cuts noise, misses unexercised paths |
What each one brings
Design. Useful upstream to run diligence before adopting a component, and to catch a prohibited licence early. No evidential value.
Source. Fast, produced from dependency manifests. Its blind spot is structural: it does not see what is not declared — vendored code, copied libraries, system dependencies.
Build. Produced by the build chain, it sees the real resolution graph, with the versions actually selected after constraint arbitration. This is the one that must be filed with the technical documentation.
Analysed. Obtained by analysing the finished artefact — binary, container image, firmware image. It catches what the build missed: statically linked libraries, base image packages, copied files. Serves as a cross-check on the build.
Deployed. Adds the runtime environment: host system, configuration, variables. Useful for operational security, less so for product compliance.
Runtime. What is actually loaded. Allows noise reduction: a component present but never loaded does not carry the same criticality as one on the execution path. Handle with care: a path not exercised during observation is still a reachable path.
The doctrine adopted
- The build SBOM is the reference SBOM: signed, archived and filed with the technical documentation.
- The analysed SBOM is produced systematically as a cross-check. Any significant gap between the two is a defect to investigate, not a curiosity: it usually reveals vendored code or an undeclared dependency.
- The runtime SBOM serves prioritisation, never compliance.
- Design and deployed types are produced case by case, as needed.
The build / analysed gap
This is the most revealing quality indicator in the whole arrangement. Typical causes:
- static linking: a C library compiled into the binary does not appear in the manifest;
- vendored code: third-party sources copied into your repository;
- base image: the container’s system packages, absent from application manifests;
- multi-language artefacts: a Python component calling a native library;
- code generation: code produced at build time, carrying dependencies.
Each of these causes is addressed in Quality and completeness.