SBOM

Introduction

The term “software supply chain” represents all the tools and bits of code used to build and publish a piece of software. It is important to keep track of this supply chain for security and legal reasons. redpesk participates towards this goal by providing Software Bills of Materials and Vulnerability Exploitability eXchange reports.

SBOMs in redpesk factory

An SBOM lists the components of a software artifact, mainly the other software components it is made of. A couple of different standards exist to write SBOM documents, notably SPDX and CycloneDX.

As of the Armel 1.8 release, the redpesk factory can generate an SPDX SBOM document for each image build (provided that the build was successful) through a new subsystem named Vexmex.

SBOM are of the SPDX 2.3 format, which is thoroughly detailed in The Software Package Data Exchange® (SPDX®) Specification Version 2.3. It is a flexible data format which allows to represent a list of software components and the relationship between them. We have made the choice to list the RPM packages installed in the associated image build, and the RPM repositories they belong to.

The repositories appear first in the packages list of the file (there are usually 4 or 5 of them), followed by all the packages. The relationships list then establishes the link between packages and repositories, each package belonging to one repo.

Sample of an SBOM document describing an image build

VEX reports in redpesk factory

A VEX report lists vulnerabilities (often Common Vulnerabilities and Exposures) affecting software components, and often a solution to fix that vulnerability.

As of the Armel 1.9 release, the redpesk factory can generate a VEX report for each image build (provided that the build was successful) through Vexmex. The data comes from the Red Hat Security Data API, since redpesk OS matches Red Hat Entreprise Linux. This also means that, as of now, we only provide VEX data for packages which we are able to match with RHEL packages. For instance, that does not include the Linux kernel, since the kernel version depends on the Board Support Package and it usually heavily patched.

The JSON report file is of a custom format. It contains the Linux distribution name, the timestamp of the report generation, a list of ignored packages for which we are unable to reliably provide VEX data, and two lists of packages (included in the image) affected by vulnerabilities: one list with known fixes (in the form of a new version to upgrade to), and one list for which we don’t know the fix yet. For each package the list of vulnerabilities affecting it is provided.

Sample of a VEX report describing an image build

Run Vexmex builds

Vexmex builds (SBOM and VEX report generation tasks) are automatically ran at the end of a successful image build. There are three cases where, even though the image build is successful, the files and/or subtasks do not appear in the files list:

  • If the image build predates the update of the redpesk factory instance to Armel 1.8 for SBOM, 1.9 for VEX reports.
  • If the Vexmex feature gate is disabled in the configuration of the redpesk factory.
  • If there was an issue in the SBOM generation process; the image build is considered failed.

In the first case, you can just run the image build again. In the later cases, please contact an IoT.bzh staff member who will assist you.

Ignore a Vexmex build failure

When an image build is successful, an SBOM build is automatically launched. If this SBOM build fails, by default, the whole image build task is considered to have failed (even though the image build subtask has succeeded and you can still download the resulting files).

This behavior can be adjusted so that the SBOM build status is ignored when computing the image build status. In the image settings, under the “Advanced settings” accordion, there is a checkbox that says “Ignore vexmex result” which is unchecked by default. This parameter is also available directly when creating the image.

Screenshots

Vexmex builds appear as subtasks of an image build.

Only one SBOM subtask appears, as the software of a given image build does not change over time. The resulting file is named spdx.json.

There can be multiple VEX subtasks, as vulnerabilities are discovered, investigated and fixed over long periods of time. They are sorted from the most recent to the oldest, and each have two files containing identical information: one HTML report for human readability, and one JSON report for machine consumption. The files are named vex_report_DATE_TIME.xxx.

Image build subtasks and files list with SBOM and VEX subtasks

All result files have a preview in the “LOGS” tab.

Image build SBOM preview in the logs tab

Image build VEX report preview in the logs tab