Building the Software Bill of Materials, or “SBOM” — alongside the software itself — is a good practice for monitoring zero-day vulnerabilities or meeting regulatory and compliance needs.
SBOM is also ready for the software transparency requirements emerging in well-regulated areas such as Financial, Healthcare, and Federal Agencies.
Commercial and open-source tools exist for building SBOM for software projects in most software ecosystems and from application binaries and firmware.
However, a typical commercially available software product or connected device is built as a collection of software and hardware projects assembled from multiple hardware components, libraries, services, or even the direct distribution of executables.
For examples:
- A mobile App includes third-party libraries for marketing, authentication, or advertising purposes — all from third-party vendors.
- A medical device might include programmable components from various vendors, each with its own versions and upgrade cycles.
- A desktop application can with some third-party executables that it calls into for specific functionalities.
In these cases, SBOM for projects and libraries can be built with the project but combining them into the final product SBOM requires a deeper understanding of SBOM formats and limitations.
Building a final product SBOM by combining the project SBOM solves several problems, including:
- Delivering a single product SBOM instead of many project SBOM
- Tracking product version against specific project versions
- Tracking the final product with a single SKU in SBOM management systems
-Mapping newly disclosed vulnerabilities to specific projects
Interlynk’s free and open-source tool - sombasm is the solution to this SBOM assembly problem.
sbomasm is a command line utility built to run on modern versions of Windows, Mac, and Linux. It is the simplest way to combine SBOM from multiple projects into a product SBOM with the product’s commercial name, version, license, and other metadata.
sbomasm has configurable input that can be used in most CI/CD pipelines to automate this process with each product release.
sbomasmtakes care of multiple intricacies, such as preserving component relationships and checksums for tracking component vulnerabilities, managing duplication of components or sub-components, and enabling multi-format specifications.
sbomasm supports:
- CycloneDX and SPDX input and output formats
- command line interface and config file as input
- available on most modern versions of Windows, Linux, and Mac
- flat merging (no hierarchy) or hierarchical merging
- final product use indicator (SBOM primary package declaration)
- options for automating the product SOBM generation
In its simplest, sbomasm can be used to combine SBOM from two different projects into a final product:
- Docker Engine — v24.0.2: SBOM File: engine.spdx.tv
- Docker Compose — v2.19.1: SBOM File: compose.spdx.tv
- Docker Desktop — v4.21.2: Desired SBOM File desktop.spdx.tv
$sbomasm assemble -n "Docker Desktop" -v "v4.21.2" -t "application" \
engine.spdx.tv compose.spdx.tv \
-o desktop.spdx.tv
That’s it!
Once completed, the SBOM file desktop.spdx.tv will describe a product named Docker Desktop of version v4.21.2 and type application that is made of three parts — docker engine v24.0.2 , docker compose v2.19.1
All components preserve their original licenses and checksum, ensuring future verifications meet requirements.
Any zero-day vulnerability against any component of Docker Engine v24.0.1will show up in Docker Desktop v4.21.2 as well as under the component name — Docker Engine v24.0.1 (relationship preservation)
sbomasm supports the most common configuration from the configuration file as well. The template for such a file can be generated with
$sbomasm generate > docker-desktop-config.yml app: name: 'Docker Desktop' \
version: 'v4.21.2' \
description: 'Docker Desktop helps you build and share containerized applications and microservices.' \
author: - name: 'Docker Inc.' \
email: 'support@docker.com' \
primary_purpose: 'application' \
purl: '[OPTIONAL]' \
cpe: 'cpe:2.3:a:docker:desktop:-:*:*:*:windows:*:*:*' \
license: id: 'Custom' \
supplier: name: 'Docker Inc.' email: 'support@docker.com' \
checksum: - algorithm: '[OPTIONAL]' value: '[OPTIONAL]' \
copyright: '[OPTIONAL]' \
output: spec: spdx \
file_format: jsonassemble: \
include_dependency_graph: true \
include_components: true \
flat_merge: false hierarchical_merge: trueThe configuration file can be edited to customize several options and can be used with a simple command for any number of project SBOM:
$sbomasm assemble -c docker-desktop-config.yml input/desktop/project-sboms/* \
-o desktop.spdx.tv
sbomasm functionalities are included in Interlynk’s SBOM platform. It can be upgraded to a commercial version for other features, such as:
sbomasm is one of the growing list of open source tools under Interlynk’s open source toolset initiative.
Our mission is to make it easy for all CI/CD systems to produce SBOM and make it useful for consumers.
We are continuously evolving all tools. Feel free to contact us at hello@interlynk.io if you want to use sbomasm or any other tools,
sbomqs for SBOM Quality Assessment,sbomgr for SBOM searching orsbomex for an exploration of SBOM formats and specifications,
We are eager to help and expand the functionalities of these tools.
