Torizon OS SBOM validation not passing

Technical Support
, , , ,
1

We are interested in getting VEX-enriched SBOMs with CVE analysis from Toradex for Torizon OS releases. By downloading one from the Torizon Cloud and putting it into an SBOM checker (for example, sbomaudit, but I’ve also tried NTIA SBOM Validator), the SBOM does not pass some of them.

For us, the must-pass check is the NTIA minimal elements one. But the SBOM itself must be a valid one as well.

My question/request is: does Toradex plan to validate their SBOMs for Torizon Cloud users?

Sample validation output of Torizon OS 7.6.1+build.38 for am62 is attached. There are various errors there, not only the NTIA minimal elements one.

foo.out (25.4 KB)

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Based on the information sources, Torizon provides both complete and actionable SBOMs for every Torizon OS release. Toradex publishes SBOMs in two formats: a complete SBOM in SPDX format and an actionable SBOM in CycloneDX format(1).

SBOM Formats and Standards

Torizon provides different SBOM formats for different purposes(1):

  • SPDX SBOM: Generated by Yocto’s create-spdx class, listing Yocto package names and versions based on the PN and PV variables, including every file in the filesystem with its hash(1)
  • CycloneDX SBOM: Makes use of extra data from Yocto’s cve-check class, enriching the SBOM with information about security patches applied to each package and correcting package names and versions to match vulnerability database formats(1)

VEX-Enriched SBOMs

The CycloneDX SBOM is specifically designed to be much better suited for vulnerability management(1). Torizon Vulnerability Manager provides all of its data in standards-compliant VEX format, allowing you to download files with Torizon analysis and import them into your own tools(2).

Current SBOM Availability

You can download both SBOMs from Toradex’s Artifactory instance at specific paths for your System On Module (SoM) and Torizon release(1). The documentation shows the exact file paths and provides examples using standardized tooling like cve-bin-tool(1).

Regarding your specific question about NTIA minimal elements validation and whether Toradex plans to validate their SBOMs for compliance with these standards - this specific validation information isn’t covered in the available documentation sources.

For detailed information about SBOM validation compliance plans and addressing the specific validation errors you encountered with Torizon OS 7.6.1+build.38, I’d recommend reaching out through the Toradex Community where you can get direct support from the Torizon team regarding SBOM validation standards and any planned improvements.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

I’ve noticed based on the SBOM article that there are two SBOMs, one referential and one for VEX annotations. The merged SPDX one doesn’t validate either, you can try e.g. this one and the SPDX validator.

4

Based on the information sources, I can confirm that Torizon publishes SBOMs in two different formats for different purposes (1):

SBOM Generation and Formats

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

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 (1). 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 (1).

SBOM File Locations

For each build of Torizon OS, both SBOMs are published to Toradex’s Artifactory instance (1). The file paths are structured as follows:

# 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

(1)

Validation Tools

The documentation mentions that you can download and parse these documents using standardized tooling for each format, such as cve-bin-tool (1):

$ 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

(1)

However, the documentation doesn’t specifically address SPDX validation compliance with external validators like the SPDX validator tool you mentioned. The validation issues you’re encountering with the SPDX SBOM files appear to be a technical matter that would benefit from direct engagement with the Torizon development team.

For specific validation compliance issues and potential improvements to SBOM generation to meet SPDX validation standards, I’d recommend discussing this directly on the Toradex Community where the development team can address the technical aspects of SBOM validation compliance.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Hello @vilchanskyio,

Thanks for the additional information and for testing both the SPDX and merged VEX-enriched SBOMs with external validation tools.

We have started an internal investigation to better understand the reported validation issues, including the NTIA Minimal Elements checks and the SPDX validator findings. At the moment, we are reviewing the SBOM generation process and the reported validation output to determine whether these are limitations of the current tooling, gaps in our generation pipeline, or issues that can be addressed through post-processing.

We’ll follow up here once we have more information from the team.

Thanks for bringing this to our attention.

6

Hello @vilchanskyio,

Quick follow-up on the internal investigation. Your findings are valid, and the response below focuses on CycloneDX since that is what you tested.

Two items are on our side to address. First, the top-level metadata: metadata.component is not populated with Torizon OS as the root, and our supplier information is missing. This is responsible for most of the NTIA validator errors and is a reasonable fix. Second, orphan packages: adding a root-level torizon-os component that depends on the package set should clear the dependency-relationship warnings.

The supplier field for upstream OSS components is a separate matter. There is no reliable automated way to attribute a supplier to every OSS component across Yocto recipes, and this is not specific to our pipeline. PURL and CPE give us a starting point, but full coverage across thousands of upstream packages is not realistic in the short term.

On the broader question of NTIA conformance: Torizon OS sits inside a finished product, and NTIA validation is typically performed at the final product level, where the integrator aggregates our OS SBOM with their own application, hardware BOM, and supplier metadata. We will still close the validation gaps we can close on our side, but full NTIA conformance for the OS image in isolation is not the natural target for this kind of SBOM.

We will report back here once the metadata and root-component changes are merged.

1 Like