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:
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:
[
{
"appId": "595838775",
"scanId": "f4e300ce-5318-42df-9257-971d93afea74",
"scanDate": "2024-01-11T11:15:09.954Z",
"repo": {
"id": "595838775",
"name": "sbomqs",
"fullName": "interlynk-io/sbomqs",
"description": "SBOM quality score - Quality metrics for your sboms",
"homepage": "",
"createdAt": "2023-01-31T22:59:22Z"
},
"type": "repo",
"sbom": {
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"serialNumber": "urn:uuid:346933e8-7a31-4869-b5d6-04ce7db6a77b",
"version": 1,
"metadata": {
"timestamp": "2024-01-08T08:25:38+00:00",
"tools": [
{
....
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.
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:
{
"$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"serialNumber": "urn:uuid:620c5fea-3744-4e81-9f10-26f7131a57f4",
"version": 1,
"metadata": {
"timestamp": "2023-09-28T03:25:13+00:00",
"component": {
"bom-ref": "edb48d31-6c13-4014-838c-be9b07bd8a63",
"type": "container",
"name": "cp-base-new-6.2.12-rc230906104347-latest.tgz",
},
"tools": [
{
....
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.
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.
Some examples:
PackageLicenseConcluded: UNKNOWN # should be NOASSERTION
PackageLicenseConcluded: BSD-3-Clause AND LicenseRef-MIT/X11 # / is an invalid character in ID
PackageLicenseConcluded: Microsoft .NET Library # Invalid License ID
PackageLicenseConcluded: LGPL-2.1-only AND MIT OR BSD-2-Clause # Ambiguous expression
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:
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.
An example of missing identifiers:
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: SBOM-SPDX-6c0821c7-2cf3-45ef-b97c-0751feee4678
DocumentNamespace: https://spdx.org/spdxdocs/k8s-releng-bom-d01781d9-3a8e-491e-b62d-d9460233b830
Creator: Tool: sigs.k8s.io/bom/pkg/spdx
Created: 2023-12-18T21:22:30Z
##### Package: quay.io/argoproj/argocd:v2.10.0-rc1
PackageName: quay.io/argoproj/argocd:v2.10.0-rc1
SPDXID: SPDXRef-Package-quay.io-argoproj-argocd-v2.10.0-rc1
PackageDownloadLocation: NONE
FilesAnalyzed: false
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
##### Package: quay.io/argoproj/argocd:v2.10.0-rc1 (amd64/linux)
PackageName: quay.io/argoproj/argocd:v2.10.0-rc1 (amd64/linux)
SPDXID: SPDXRef-Package-quay.io-argoproj-argocd-20e7deb6a02398bca33aa9a10c92ce02a02749b9c0d974239d5b70f352870849
PackageDownloadLocation: NONE
FilesAnalyzed: false
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
Examples of invalid identifiers:
PackageName: libp11-kit0
SPDXID: SPDXRef-Package-deb-libp11-kit0-815a24130e241aaf
PackageVersion: 0.24.1-1ubuntu2
PackageOriginator: Person: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageSourceInfo: acquired package info from DPKG DB: /usr/share/doc/libp11-kit0/copyright, /var/lib/dpkg/info/libp11-kit0:amd64.md5sums, /var/lib/dpkg/status
PackageLicenseConcluded: Apache-2.0 AND BSD-3-Clause AND ISC AND LicenseRef-ISC+IBM AND LGPL-2.1-only AND LGPL-2.1-or-later AND LicenseRef-permissive-like-automake-output AND LicenseRef-same-as-rest-of-p11kit
PackageLicenseDeclared: Apache-2.0 AND BSD-3-Clause AND ISC AND LicenseRef-ISC+IBM AND LGPL-2.1-only AND LGPL-2.1-or-later AND LicenseRef-permissive-like-automake-output AND LicenseRef-same-as-rest-of-p11kit
PackageCopyrightText: NOASSERTION
ExternalRef: SECURITY cpe23Type cpe:2.3:a:libp11-kit0:libp11-kit0:0.24.1-1ubuntu2:*:*:*:*:*:*:*
ExternalRef: SECURITY cpe23Type cpe:2.3:a:libp11-kit0:libp11_kit0:0.24.1-1ubuntu2:*:*:*:*:*:*:*
ExternalRef: SECURITY cpe23Type cpe:2.3:a:libp11_kit0:libp11-kit0:0.24.1-1ubuntu2:*:*:*:*:*:*:*
ExternalRef: SECURITY cpe23Type cpe:2.3:a:libp11_kit0:libp11_kit0:0.24.1-1ubuntu2:*:*:*:*:*:*:*
ExternalRef: SECURITY cpe23Type cpe:2.3:a:libp11:libp11-kit0:0.24.1-1ubuntu2:*:*:*:*:*:*:*
ExternalRef: SECURITY cpe23Type cpe:2.3:a:libp11:libp11_kit0:0.24.1-1ubuntu2:*:*:*:*:*:*:*
ExternalRef: PACKAGE-MANAGER purl pkg:deb/ubuntu/libp11-kit0@0.24.1-1ubuntu2?arch=amd64&upstream=p11-kit&distro=ubuntu-22.10
"SPDXID":"SPDXRef-actions-actions/checkout-2",
"downloadLocation":"NOASSERTION",
"externalRefs":[
{
"referenceCategory":"PACKAGE-MANAGER",
"referenceLocator":"pkg:githubactions/actions/checkout@2",
"referenceType":"purl"
}
],
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).
Some examples of invalid identifiers:
PackageName: 4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1.tar.gz
SPDXID: SPDXRef-Package-quay.io-argoproj-argocd-20e7deb6a02398bca33aa9a10c92ce02a02749b9c0d974239d5b70f352870849-4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1.tar.gz
# Other parts of the SPDX
PackageName: 4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1.tar.gz
SPDXID: SPDXRef-Package-quay.io-argoproj-argocd-20e7deb6a02398bca33aa9a10c92ce02a02749b9c0d974239d5b70f352870849-4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1.tar.gz
"SPDXID":"SPDXRef-actions-actions/checkout-2" # SPDXID should not have /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.
Examples:
{
"bomFormat" : "CycloneDX",
"specVersion" : "1.4",
"serialNumber" : "urn:uuid:78b6063a-2897-4926-838f-6a82e514b965",
"version" : 2,
"metadata" : {
"timestamp" : "2023-12-01T18:04:55Z",
"tools" : [ {
"vendor" : "....",
"name" : "....",
"version" : "...."
} ],
"authors" : [ {
"name" : "Organization: Interlynk Inc." # Organization: SPDX
}, {
"name" : "Person: Ritesh Noronha"
} ]
},
"$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"licenses": [
{
"license": {
"name": "NOASSERTION" # NOASSERTION: SPDX reference
}
}
],
"version" : "1.0.0",
"description" : "NONE",
"externalReferences" : [ {
"type" : "website",
"url" : "NONE"
}, {
"type" : "distribution",
"url" : "NONE" # NONE: SPDX reference
} ],
"type" : "library",
"bom-ref" : "SPDXRef-pip-psutil" # A valid but confusing reference
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
