Torizon Vulnerability Manager Overview (Beta)

Introduction

The Torizon Vulnerability Manager (VM) is a security management feature integrated into Torizon Cloud. It enables developers and product teams to identify, assess, and remediate software vulnerabilities throughout the entire lifecycle of their embedded Linux products.

Key Capabilities

• Automated Scanning: Continuously checks Toradex OS builds against upstream Common Vulnerabilities and Exposures (CVE) databases;

• Centralized Dashboard: A visual interface in Torizon Cloud presents a breakdown of currently-known vulnerabilities for published releases;

• Expert Analysis: For every high- or critical-severity vulnerability in any component, Torizon security experts triage and analyze the vulnerability so you don't have to;

• Seamless Workflow: Torizon security patches and Secure Updates helps you stay vulnerability-free;

• Compliance Support: Facilitates adherence to regulations such as the EU Cyber Resilience Act (CRA).

Introduction to Vulnerability Management

The EU Cyber Resilience Act mandates that manufacturers:

"identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format"

and

"address and remediate vulnerabilities without delay".

This means that manufacturers now have the legal obligation to stay on top of potential vulnerabilities, and have appropriate internal processes for dealing with them.

The process usually unfolds in six key steps:

• Step 1: Identify all of the software components in your product, for example by drawing up an accurate and actionable SBOM.
• Step 2: Check public vulnerability databases for vulnerabilities in each component.
• Step 3: For each vulnerability found, determine whether the vulnerability report is accurate.
• Step 4: For each accurate report, determine if it actually presents a risk to the security model of your product.
• Step 5: For each vulnerability that presents a risk to the security model of your product, address and remediate the vulnerability.
• Step 6: Issue a software update with the mitigation applied.

Torizon's Vulnerability Manager provides tools to make each of those steps easier. Continue reading for step by step details.

Step 1: Accurate, actionable SBOM

An accurate SBOM is a critical prerequisite to any vulnerability management process. You can find the auto-generated SBOM for every release on artifactory for free.

With a Torizon Cloud repository, you also get access to Torizon enriched SBOM with its associated VEX information, formatted as a NIST SP 800-161 Vulnerability Attestation Report. This SBOM has every component that went into the Torizon OS build, generated at build time, with full knowledge of which patches were applied.

Click the Known CVEs in Torizon Cloud tab to see the list of packages with available vulnerability reports, and find your Torizon OS version.

tip

You can also cross-reference all of the information in the CycloneDX SBOM with the SPDX SBOM for that release, and verify the complete build process with Torizon in-toto attestations.

Step 2: Scan for vulnerabilities

Torizon Cloud scans for new vulnerabilities in all releases, every day, so you don't have to worry about scanning your dependencies in the base OS. You can check the release page, and count on newly-disclosed vulnerabilities being reported as soon as they appear in the vulnerability databases.

You can simplify vulnerability analysis using the Torizon Vulnerability Manager CVE report filters.

Step 3: Verify accuracy of reports

Torizon Vulnerability Manager helps by eliminating up-front all of those complete false positives and inaccuracies. If Torizon security team knows, with absolute certainty, that the vulnerability can't affect Torizon users, the vulnerability is marked as such. This usually removes 50–70% of the total vulnerabilities detected.¹

For this, Torizon security team uses the VEX standard. Anything that the team can definitively rule out gets marked as false_positive or not_affected, with the correct justification selected and a detail field populated with a human-written, expert explanation of why the Torizon security team made this categorization.

Step 4: Determine if it's a risk to your product

Once the scanner has reported that you have a vulnerability, and you've determined that it's not a false positive, the next thing you need to do is analyze and understand the vulnerability. ²

Here, Torizon's Vulnerability Manager also can save a large amount of effort. Torizon security team can't know what the security model and field configuration of your product is. But, they do know a lot about what is typical of Toradex customers and their products, and what issues tend to be problems in the real world.

That's why Torizon Vulnerability Manage reports provide the Mitigation Available category. Vulnerabilities that are included in this category might be of concern for some products, but only under very specific or unusual threat models. Just like the Not Affected category, Torizon Vulnerability Manager reports provide a justification for why a typical product would not be affected, and a human-written, expert explanation of why Torizon security team made this categorization.

Rather than spending time deeply researching the vulnerability, most users can simply review the summary to quickly see whether it applies to them. If it doesn't, you can just change the status to not_affected in your own vulnerability management tool, and usually keep the pre-populated justification and detail fields.

Step 5: Address and remediate

If you have a vulnerability, you have an obligation to address and remediate it "without delay". Whenever a vulnerability is discovered that Torizon security team think is likely to affect Torizon customers, it is provided a patch and a new release on a rapid schedule. For example, when there was a vulnerability discovered in sudo in June 2025, Torizon had fully-supported releases of both Torizon 6 (LTS) and Torizon 7 out in less than one month, and it was patched in Torizon nightly builds in just over a week.

Additionally, every quarterly release includes thousands of patches from the upstream Linux kernel, tested for compatibility with every Toradex module. In almost all cases, Torizon customers don't need to worry at all about issuing their own patches as long as they keep up to date with a supported Torizon release.

Building your product using Torizon Containers means that you can update the base OS with confidence, knowing your containerized application's dependencies won't change, and everything will continue working. It also means you can have decoupled, faster and lighter release cycles for application, operating system and subsystems.

Step 6: Release an update

Having a secure software update system is a critical link in the vulnerability management chain.

Torizon provides easy image generation workflows that helps you get security patches integrated and available for updates faster for the whole stack - bootloader, operating system, application and subsystems.

Having Torizon Cloud reporting on which devices in your fleet actually need the update means you can know for sure which devices need attention. And being able to count on Torizon Cloud Updates to deliver updates both online and offline with reliable, safe rollback protections means that you can get your updates out fast.

Footnotes

1. The majority of vulnerabilities reported by any scanning tool are going to be inapplicable, or false positives. For example, a vulnerability scanner will generally list every single Linux kernel vulnerability known to affect your kernel version since it doesn't consider what options your kernel was compiled with, or the architecture you're using. Scanners err on the side of caution, so they report everything, and leave it to you to sort out the details. There are also sometimes complete false positives reported: the vulnerability databases aren't always perfectly accurate about which versions of a package are vulnerable and which aren't. ↩

2. There might be a vulnerability in a software library that is shipped in your system, but you don't have the necessary preconditions for an attack to be executed - for example, it might only be certain specific configurations that are affected, and your product doesn't have that configuration. ↩