Why is SBOM quality important?
Two SBOMs in the same format can differ in how useful they are
That an SBOM follows CycloneDX or SPDX only says that the file has the right structure. It does not say that the information in it is complete. Two tools can create entirely different SBOMs for the same project, and both can be valid according to the format.
Quality decides what the SBOM can be used for. A vulnerability analysis can only find vulnerabilities in components that are included and can be identified.
Common gaps
| Gap | Consequence |
|---|---|
| Version missing | It cannot be decided whether a vulnerability applies to the component |
| Unique identifier (purl or CPE) missing | The component cannot be matched reliably against vulnerability databases |
| Only direct dependencies | Vulnerabilities in transitive dependencies are not visible |
| Relationships between components missing | You cannot see why a component is included or what to update |
| Supplier missing | It is unclear who is behind the component |
| Licence missing or free text | Licence checks cannot be automated |
| A whole ecosystem missing | The tool read npm, for example, but not Python in the same project |
What to measure an SBOM against
- SBOM Minimum Elements. The baseline from NTIA: supplier, name, version, unique identifier, dependency relationships, author and timestamp.
- BSI TR-03183-2. The German guideline for SBOMs under the CRA, which sets more detailed requirements.
- Your own requirements. For example that licences are stated as valid SPDX expressions.
Check automatically
The check should be done by a tool, every time an SBOM is created or received. This applies especially to SBOMs from suppliers. That a supplier "has an SBOM" says nothing about what it contains.
Write the quality requirements into the contract and check every delivery against them. SBOM in public procurement gives examples of how requirements can be worded.