The 5 Most Common Problems in SBOMs
Jan 15, 2024
Interlynk
Software Bill of Materials (SBOM) helps build and communicate software component inventory and associated risks. The regulatory and monitoring needs of SBOM are well understood. However, building a “good” SBOM still requires avoiding several pitfalls, as some popular SBOM builders are still maturing.
Here are the five most common problems we keep running into while handling SBOMs.
1. Specification Mix-ups
The most common show up in tools that support more than one specification. We consistently see the implementation of processing one specification leading to invalid values for the other.
2. Misidentified Identifiers
CPE and PURL are two of the most common ways of globally identifying components, especially in vulnerability management. In addition, both CycloneDX and SPDX require document-specific internal unique identifiers ( bom-refand SPDXID respectively). This helps track additional component information, such as the relationship among components.
But these requirements around the identifiers can lead to two common types of challenges:
2.1 Missing or Invalid CPE/PURL
An SBOM empty for CPE or PURL is not helpful for vulnerability tracking. It can still serve as an ingredient list and license inventory when license information is present.
2.2 Inconsistent Unique Identifier
The other most common problem is SBOM with invalid or duplicate identifiers present in the SBOM. The bom-ref and SPDXID are meant to be unique in the document and have specification-specific restrictions (e.g., SPDXID should not include special characters).
3. License to confuse
Specifying and tracking open-source software licenses was one of the earliest use cases for SPDX specification. Since then, the SPDX license expressions have improved on the list of licenses and the ability to express multiple licenses or specific exceptions to them.
CycloneDX 1.5 and SPDX 2.3 and up support specifying commercial licenses alongside its texts and links to external documents.
Unfortunately, it is all too common to run into invalid license IDs or license expressions in SBOMs.
4. Faceless SBOM
The SBOM exists in the context of a software or hardware component of a system. Therefore, without proper identification of the component itself, the rest of the SBOM becomes an ingredient list for an unknown. NTIA Minimum Elements suggests identifying the component with Name, Version, and Other Unique Identifiers to support specific lookups such as lookup into vulnerability databases.
However, it is common to find SBOMs without that minimum dataset.
An example:
Note that no version is specified in the primary component, and no vulnerability identification is present. This makes the SBOM unusable for tracking vulnerability across versions and collating SBOM in the order of product releases. Deciphering version 6.2.12-rc230906104347 requires product-specific error-prone customizations.
5. SBOM burrito
The most commonly used SBOM specifications, CycloneDX and SPDX, have a fair amount of flexibility. Unfortunately, some SBOM builders take a detour to wrap SBOM content with additional data.
An example:
This does not follow either specification, and a human intervention is required to understand that the actual SBOM starts at the “sbom” node.
The appID, scanId, type, and repo:id are all details not applicable outside the scope of this tool. This makes automating consumption of such SBOM a duct-taping exercise.
Moreover, the burrito wrapper has no versioning and can break any downstream automation without warning.
Interlynk is trying to make security disclosure easy, obvious, and automated. Interlynk’s Open Source tool, sbomqs, can identify the most common issues with the SBOMs and is open for tracking other common errors you might see. Feel free to reach out to us at hello@interlynk.io