Skip to main content
Version: Torizon OS 7.x.y

SBOM

Introduction

This article provides information about the different types of Software Bill of Materials (SBOMs), what to use each type for, and how the SBOMs Toradex publishes for Torizon OS can be leveraged for compliance and traceability.

SBOMs are used in context of vulnerability management. You will benefit from reading the Torizon Vulnerability Manager article to learn more about the subject.

What are SBOMs?

SBOMs are important records of information within software supply chains, similar to a parts list for software. In general, their purpose is to provide insights into the composition of a software product. At a basic level, an SBOM is just a list of all the components and dependencies that are part of a software system. But within that basic definition, there are different types.

In cybersecurity circles, it's becoming more and more common to talk about two general categories of SBOM: the Actionable SBOM and the Complete SBOM.

  • An actionable SBOM is one where the software components and dependencies can be uniquely identified as a particular piece of software, with a standardized identifier. This means that each component and its specific version will be identified by its Common Platform Identifier (CPE) or Package URL (PURL). Actionable SBOMs should have all the data required for doing software composition analysis, vulnerability scans, and vulnerability analysis. An actionable SBOM is a bit like a patient's chart or medical records in a hospital: it has all the information needed for diagnosis and understanding the condition of the patient.
  • A complete SBOM is a listing of every constituent part of a shipped software artifact. It has information about everything included in a piece of software: every file and its hash, or in the case of a complete build SBOM every source file that went into the build process. It is possible for a complete SBOM to also be actionable, but this is often not the case. Complete SBOMs can be huge and unwieldy, and it is not always the case that the elements of a complete SBOM are well mapped to understandable, standardized CPEs or PURLs. If an actionable SBOM is like a patient's chart, a complete SBOM is like the patient's sequenced DNA: it is very useful in certain specialized circumstances, but isn't what you would necessarily consult on a day-to-day basis.

Toradex now publishes both a complete SBOM and an actionable SBOM for every Torizon release.

Contact Us if you need help with SBOMs and Common Vulnerabilities and Exposures (CVEs).

SBOM Files and Formats

There are a few different standards for SBOM file formats, but the two most common ones are SPDX and CycloneDX. Today, the latest versions of the two standards are equally capable; each format can in principle be converted into the other without loss of information. But historically, they have been used for different purposes: SPDX has traditionally served the needs of license compliance and legal departments, while CycloneDX is a bit more lightweight and was developed to meet the needs of cybersecurity teams.

Torizon provides a complete SBOM in SPDX format, and an actionable SBOM in CycloneDX format.

Why do we use two different formats?

The SPDX SBOM is generated by Yocto's create-spdx class. It lists Yocto package names and versions, based on the PN and PV variables, but does not give a CPE or PURL. It also lists every file in the filesystem, and its hash.

The CycloneDX SBOM makes use of extra data from Yocto's cve-check class, which adds critical information that isn't easily discoverable from the SPDX SBOM. For example, it enriches the SBOM with information about the security patches that were applied to each package, and corrects many package names and versions to match the format that vulnerability databases expect. As such, it is much better suited for vulnerability management.

How to Find SBOMs for Torizon OS Builds?

You can download the SBOM for Torizon OS Quarterly Releases directly from the package detail view: 'Dashboard > Packages > <package name>'.

Learn how to download SBOM CycloneDX + VEX by checking the images below (click and slide or use the arrows):

View CVE Analysis

Download SBOM CycloneDX + VEX from Torizon Cloud

(Double-Click to Zoom)

For each build of Torizon OS, we publish the both SBOMs to Toradex's Artifactory instance. The SPDX SBOM file for your specific System On Module (SoM) and Torizon release is located at the following path:

# SPDX SBOM
torizoncore-oe-prerelease-frankfurt/<bsp-release>/<release-period>/<release-build-number>/<som>/<torizon-distro>/<torizon-image>/oedeploy/<torizon-image-som-release_code>.spdx
# CycloneDX SBOM
torizoncore-oe-prerelease-frankfurt/<bsp-release>/<release-period>/<release-build-number>/<som>/<torizon-distro>/<torizon-image>/oedeploy/bom.json

You can download and parse this document using standardized tooling for each format. For example, cve-bin-tool:

$ wget "https://artifacts.toradex.com:443/artifactory/<sbom-file-path>" -O sbom.spdx
$ cve-bin-tool --sbom spdx --sbom-file sbom.spdx
$ wget "https://artifacts.toradex.com:443/artifactory/<sbom-file-path>" -O bom.json
$ cve-bin-tool --sbom cyclonedx --sbom-file bom.json

For more information on vulnerability scanning and management, we have an in-depth article on Torizon's detailed, expert-produced vulnerability reports.

How to find SBOM for Official Torizon Containers?

The container ecosystem has its own tooling for SBOM generation and distribution, and the SBOMs for all official Torizon containers are published on Docker Hub alongside the container itself in line with industry best practices. To get these SBOMs, use the imagetools command from buildx:

$ docker buildx imagetools inspect torizon/<image-name>:<image-tag> --format '{{ json (index .SBOM "<arch>").SPDX}}'

For example, to get the SBOM in the SPDX format for the debian base image, run

$ docker buildx imagetools inspect torizon/debian:4 --format '{{ json (index .SBOM "linux/arm64").SPDX}}'

More detailed reports can be obtained using different Go Templates with the --format flag, as described in the official format command documentation, for example, to list all the installed packages in a given container image and their respective versions:

$ docker buildx imagetools inspect torizon/debian:4 --format '{{ range (index .SBOM "linux/arm64").SPDX.packages}}{{println .name .versionInfo}}{{end}}' | sort
Send Feedback!