PLB-SBOM Or: How to Assemble SBOM for a Group of Products

Software Bill of Materials (SBOM) is becoming essential for most CI/CD pipelines.

‍

SBOM captures an inventory of components that make up the specific project alongside its associated metadata.

‍

However, most complex real-world applications are built as a collection or an assembly of applications — sometimes more than a few layers deep.

‍

For example, A smartphone is a collection of independently built apps on top of an operating system — presumably built as an integration of projects. The third-party apps may invoke functionalities of the first-party apps, which in turn might depend on external services.

‍

There are many choices when it comes to building an SBOM for a complex multi-layer system.

‍

To set best practice guidance on the topic, CISA’s SBOM Tooling and Implementation Working Group just published — Guidance on Assembling a Group of Products”. The two-pager guidance — a must-read — separates REQUIRED and RECOMMENDED guidance and includes a sample of such an assembly.

‍

PLB-SBOM

Given the assembly of independent components is called a software product line, CISA has termed the SBOM Product Line Build SBOM or PLB-SBOM.

PLB-SBOM lists all its components and references individual SBOM for each component using the reference mechanism applicable to the specification ( SPDXRef-for SPDX and bom-ref for CycloneDX).

‍

REQUIRED Information

The guidance focuses on preserving SBOM for each component image and using them as a reference to build the final PLB-SBOM.

A PLB-SBOM must include:

• All components with their version number
• A reference to the build SBOM that generated each component image

‍

RECOMMENDED Information

In addition, the following information is recommended to be included in the final PLB-SBOM

• The hash of the artifact associated with each component image
• Available product identifier for the component (PURL, CPE, SWID)
• Author of the PLB-SBOM : the entity that releases the product line

Hash is recommended to enable cross-checking and may include a common hashing scheme across components.

‍

Challenges

CISA’s PLB-SBOM is a reasonable start to SBOM for assembled software.

‍

First, retaining and referencing SBOM instead of embedding them directly allows the preservation of validating information such as embedded signatures.

‍

Of course, retaining component SBOMs instead of embedding them is, by definition, lossless.

‍

However, there are known challenges in retaining, referencing and distributing.

• Including SBOM by reference implies the collection of SBOMs that must make up the product must be managed as a unit. However, their capabilities will vary if the component SBOM comes in different specifications or has different versions of the specification.
• Along the same lines, assembled SBOM units will require enhancements in tooling to traverse the SBOM references for everyday SBOM actions, such as vulnerability or checksum lookup.
• Finally, to make tooling work, SBOM references require the distribution of all SBOMs in tandem and create the need for a programmatic description of assembly and distribution. None exist today.

‍

sbomasm

sbomasm — Interlynk’s open-source tooling for SBOM assembly focused on embedding SBOM content to avoid the challenges above. However, it will add the ability to build PLB-SBOM with references soon.

‍

Interlynk’s commercial platform is built with both use cases in mind and can produce a PLB-SBOM using references and trigger an auto-generation of SBOM with any changes.

‍

Managing a complex build pipeline without an eye on automation can be error-prone and might seem like a chore. However, with a thoughtful setup, even the most complex software build pipeline can be easily automated for SBOM and associated compliance needs.

‍

Interlynk simplifies security disclosure, makes it straightforward, and automates the process. Feel free to contact us at hello@interlynk.io

‍