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

{
  "name": "ImageRPI4 software bill of materials",
  "documentNamespace": "http://factory-app-preprod.lorient.iot/image_build_sbom/ImageRPI4/7",
  "SPDXID": "SPDXRef-ImageBuild-ImageRPI4",
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "documentDescribes": ["SPDXRef-1188.my-image-7e9906a0--redpesk-lts-batz-2.0-update-build"],
  "creationInfo": {"created": "2025-10-27T09:29:18Z", "creators": ["Organization: IoT.bzh"],},
  "packages": [
    {
      "name": "1214.redpesk-lts-batz-2.0-update-build",
      "SPDXID": "SPDXRef-1214.redpesk-lts-batz-2.0-update-build",
      "versionInfo": "batz-2.0-update",
      "supplier": "Organization: IoT.bzh",
      "downloadLocation": "http://factory-app-preprod.lorient.iot/kbuild//repos/my-image-7e9906a0--redpesk-lts-batz-2.0-update-build/164710/x86_64",
      "filesAnalyzed": false
    },
    {
      "name": "NetworkManager",
      "SPDXID": "SPDXRef-NetworkManager",
      "licenseDeclared": "GPL-2.0-or-later AND LGPL-2.1-or-later",
      "licenseComments": "",
      "versionInfo": "1:1.42.2-1.apps.rpbatz.x86_64",
      "supplier": "Organization: IoT.BZH",
      "packageFileName": "NetworkManager-1:1.42.2-1.apps.rpbatz.x86_64.rpm",
      "downloadLocation": "http://factory-app-preprod.lorient.iot/download/redpesk/redpesk-lts/batz-2.0-update/packages/baseos/x86_64/os/Packages/n/NetworkManager-1.24.2-1.apps.rpbatz.x86_64.rpm"
    },
    // ...
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-NetworkManager",
      "relationshipType": "PACKAGE_OF",
      "relatedSpdxElement": "SPDXRef-1214.redpesk-lts-batz-2.0-update-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.

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, and from the CVE Project from which we extract kernel-specific vulnerabilities data. That means that packages not having a RHEL equivalent and which are not the kernel currently have no VEX/CVE information.

For kernel vulnerabilities, matching is done using the version of the kernel installed in an image, then the results are filtered by the list of source files used to build that kernel in order to reduce false positives. We cannot take vendor-specific patches into account since these vendors currently do not have CVE programs and do not publish vulnerability advisories.

A VEX report is made of three files, two JSONs and one HTML. The JSON files are of a custom format. The first one is about OS packages in general. 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;
• a list of packages with known fixes (in the form of a new version to upgrade to); and
• a list of packages for which we don’t know the fix yet.

For each package the list of vulnerabilities affecting it is provided.

The second JSON file is just about the kernel vulnerabilities, since there are quite a lot of them. It contains:

• the kernel Name-Version-Release-Architecture identifier, the timestamp of the report generation;
• one list of vulnerabilities which currently affect the kernel and the list of versions to upgrade to which include a fix;
• a second list of vulnerabilities without known versions with fixes yet; and
• a third list of vulnerabilities which were filtered out, accompanied with the reason of exclusion.

There is also a human-readable HTML report made of a summary of the kernel vulnerabilities, and two tables listing the OS packages vulnerabilities. The tables can be ordered and filtered by severity interactively.

Sample of a VEX report describing OS packages of an image build

{
  "distro_name": "batz-2.1-update",
  "time_of_run": "2025-10-27T10:32:51.654049",
  "ignored": [
    "libgcc",
    "crypto-policies",
    "vim-filesystem",
    // ...
  ],
  "to_fix": [
    {
      "cves": [
        {
          "vuln_id": "CVE-2024-28834",
          "severity": "MEDIUM",
          "int_severity": 1,
          "status": "Fixed",
          "upgrade_to": "0:3.8.3-4.el9_4"
        },
        // ...
      ],
      "upgrade_to": "0:3.8.3-6.el9",
      "max_fixed_severity": "MEDIUM",
      "int_max_fixed_severity": 1,
      "int_max_affected_severity": -1,
      "component": "gnutls",
      "version": "0:3.7.6-21.baseos.rpbatz.2.x86_64"
    },
    // ...
  ],
  "known_affected": [
    // same as to_fix without the "upgrade_to" field
  ]
}

Sample of a VEX report describing the kernel of an image build

{
  "kernel": "kernel-5.14.0-65.dev.vex_c318edda.rpbatz_1_1.x86_64",
  "time_of_run": "2025-10-27T10:32:51.654049",
  "to_fix": [
    {
      "vuln_id": "CVE-2024-35966",
      "upgrade_to": ["5.15.178", "6.1.107", "6.6.47", "6.8.7", "6.9"]
    },
    // ...
  ],
  "known_affected": [
    "CVE-2022-26365",
    "CVE-2022-3643",
    "CVE-2022-42328",
    // ...
  ],
  "known_not_affected": [
    {
      "vuln_id": "CVE-2024-58011",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "Source files drivers/platform/x86/intel/int3472/discrete.c, drivers/platform/x86/intel/int3472/tps68470.c not used to build this kernel"
    },
  ]
}

Screenshot of the human-readable VEX report

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 sbom.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.

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