Vulnerability Exploitability Exchange (VEX)

Introduction

This article introduces VEX (Vulnerability Exploitability eXchange) and shows how Torizon Vulnerability Manager feature uses it to simplify vulnerability reporting for Torizon OS. You’ll learn what VEX is, how its statuses and justifications work, and how Torizon delivers this information in a machine-readable format that integrates seamlessly with your own tools.

Visit the Torizon Vulnerability Manager article to learn more about the feature.

Why use VEX

Regulations like the EU's CRA (Cyber Resilience Act), the US FDA's medical device cybersecurity compliance rules, the NIST directive on software supply chain security require manufacturers to have vulnerability management processes, and communicate information about vulnerabilities in a standardized, machine-readable format.

VEX is the standard that defines what properties these vulnerability reports must have. Learning how VEX works sheds light into how vulnerability management should be done. Finally, getting VEX information from your suppliers saves a lot of time and effort.

Goals and Expected Outcomes

VEX was created to cut through the noise of endless vulnerability reports by focusing on exploitability in context. Instead of treating every CVE as a universal risk, each supplier in the software supply chain provides precise information about how (or if) a vulnerability affects their product. This shifts responsibility to those with the best knowledge of the software, enabling downstream users to make faster, more accurate decisions while avoiding unnecessary remediation work.¹

So, to summarize, VEX:

• Looks at vulnerabilities in context
• Has a standard, machine-readable format
• Reduces unnecessary remediation effort by focusing on vulnerabilities that are actually exploitable
• Reduces downtime and disruptions that could result from patching non-critical vulnerabilities

VEX Structure

VEX centers on the notion of a statement. A statement is an assertion that communicates information about a product, a vulnerability, and an impact status:

   statement = product(s)             + vulnerability              + status
               │                        │                            │
               └ The software product   └ Typically a CVE related    └ One of the impact
                 we are talking about     to one of the product's      statuses as identified
                                          components                   by the VEX working group.

So, to make a VEX statement you need to have an identifiable software component (usually identified by SBOM identifiers like CPE or PURL), an identifiable vulnerability (usually identified by a CVE ID), and a status.

Status must be one of the following:

• In Triage
• Resolved
• False Positive
• Not Affected
• Exploitable

If the status is "Not Affected", there must be a justification for why the vulnerability does not affect the software product. That justification must be one of the following:

• Code not present
• Code not reachable
• Requires configuration
• Requires dependency
• Requires environment
• Protected by compiler
• Protected at runtime
• Protected at perimeter
• Protected by mitigating control

There are, other fields in a VEX document, like UUIDs and cross-references to SBOMs. For understanding the structure of a VEX document, the most important fields are the Status and, in the case of the Not Affected status, the Justification.

How Torizon Vulnerability Manager uses VEX

Torizon Vulnerability Manager provides all of its data in standards-compliant VEX format. This way, you can download the files with Torizon analysis and import them into your own tool.

The following explains how each VEX status and justification is used, and how the official VEX categories are mapped to the categories shown on the CVE charts on Torizon Cloud.

Statuses

Torizon Vulnerability Manager uses the five standard VEX statuses to categorize vulnerabilities based on their impact on Torizon OS. Here's what each status means in Torizons context:

Resolved

Vulnerabilities that have been completely fixed, typically through a specific patch or update. These vulnerabilities no longer pose a threat to Torizon OS and require no further action from you.

Exploitable

Vulnerabilities that are confirmed to be exploitable in Torizon OS under default, hardened configurations. These represent real security risks that should be addressed promptly. This status is used conservatively - vulnerabilities are marked as exploitable only when there is clear evidence they can be exploited in a typical Torizon OS deployment.

In Triage

This is a common status in Torizon VEX documents. It indicates vulnerabilities that are not exploitable in most typical Torizon OS deployments, but which could potentially be a problem depending on your specific use case, configuration, threat model, and risk assessment. They have been analyzed in detail by the Torizon security team, and include concise explanations of the issue and, in most cases, a draft justififcation for why the vulnerability wouldn't affect a typical Torizon OS deployment. These vulnerabilities do still require your attention, to determine if they affect your particular deployment.

In Triage vulnerabilities fall into two categories:

• With justification: These are unlikely to affect most deployments but could become relevant under specific conditions (like enabling certain configuration options or using particular tools). There's generally a mitigation already built into Torizon OS that greatly reduces the impact or exploitability; that's why this status is refered in the Vulnerability Manager as "Mitigation available". In many cases, it's simply a matter of accepting the justification by changing the status to "Not Affected".
• Without justification: These are vulnerabilities that require closer analysis to determine their relevance to your specific use case. they're judged to be typically not exploitable or relevant for most users, but there is no specific justification to recommend.

False Positive

Vulnerabilities that appeared in Torizon security scans but don't actually apply to Torizon OS. This typically happens when vulnerability scanners incorrectly identify components or when CVE databases contain inaccurate information. These can be safely ignored.

Not Affected

Vulnerabilities that definitively do not affect Torizon OS. This status always includes a justification explaining why the vulnerability doesn't apply.

Justifications

Justifications are used both in the Not Affected status and the In Triage (a.k.a. Mitigation Available) status. The meaning of the justification can be slightly different, depending on which status it is used with, but it always comes with a human-written explanation in the Details field.

Code Not Present

Official definition: The code has been removed or tree-shaken.

Torizon usage: this is used primarily for kernel vulnerabilities where the vulnerable code is not actually compiled into Torizon OS kernel, as evidenced by Torizon kernel configuration. This is a definitive "Not Affected" status.

Code Not Reachable

Official definition: The vulnerable code is not invoked at runtime.

Torizon usage:

• Not Affected: When the vulnerability exists in a library or package, but no components in Torizon OS actually use the affected code path
• In Triage: When the vulnerable code exists but is unlikely to be reached in typical deployments (e.g., vulnerabilities in tracing subsystems that require explicit user code to invoke, or vulnerabilities in tools like nano that aren't executed by default)

Requires Configuration

Official definition: Exploitability requires a configurable option to be set/unset.

Torizon usage:

• Not Affected: Rarely used, as this typically relates to runtime configuration options
• In Triage: Very common - vulnerabilities that only become exploitable when specific configuration options are enabled (e.g., OpenSSH vulnerabilities that only affect password-based authentication, which Torizon doesn't enable by default)

Requires Dependency

Official definition: Exploitability requires a dependency that is not present.

Torizon usage: Used exactly as defined - when a vulnerability requires a specific dependency that Torizon OS doesn't include.

Requires Environment

Official definition: Exploitability requires a certain environment which is not present.

Torizon usage: Rarely used, but when applicable, it's explained in detail.

Protected by Compiler

Official definition: Exploitability requires a compiler flag to be set/unset.

Torizon usage:

• Not Affected: Torizon enables comprehensive hardening options in its Yocto builds, so many vulnerabilities are rendered unexploitable by compiler protections
• In Triage: When a specific compiler option provides strong mitigation but not complete protection

Protected at Runtime

Official definition: Exploits are prevented at runtime.

Torizon usage:

• Not Affected: Rarely used by us, as this typically requires full product context
• In Triage: Frequently used for vulnerabilities that would typically be protected in normal embedded device deployments (e.g., kernel CVEs requiring root access or CVEs only exploitable in interactive shell sessions)

Protected at Perimeter

Official definition: Attacks are blocked at physical, logical, or network perimeter.

Torizon usage: Similar to "Protected at Runtime" - rarely used for Not Affected, but may be used for In Triage when perimeter protections are relevant.

Protected by Mitigating Control

Official definition: Preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability.

Torizon usage:

• Not Affected: Rarely used by us, as this typically requires full product context
• In Triage: Frequently used when Torizon OS has mitigations that greatly reduce but don't completely eliminate exploitability. The specific mitigation is documented in the Details field, and it's up to you to decide if the mitigation is sufficient for your threat model and risk assessment.

How to use Torizon VEX files

You can download Torizon SBOM with integrated VEX and import it into the vulnerability management tool of your choice. The OWASP Dependency Track as recommended and excellent open source option. If there is a tool you're using, and you're having trouble with compatibility or import, please reach out on Toradex Community.

Footnotes

1. VEX was developed to address a common challenge in cybersecurity: vulnerabilities are everywhere. The US National Vulnerability Database of CVEs alone adds tens of thousands of new ones every year. Software supply chains are complex, with multi-level dependencies, and any software product of reasonable complexity is going to have hundreds or even thousands of CVE reports about components in its dependency tree every year.

   Most vulnerability reports do not actually impact every finished product that depends on the affected component. Many CVEs are borderline-hypothetical, even. Some are obscure edge cases of memory corruption caught by coverage-guided fuzzers or static analysis tools, with no known way to actually exploit them in a real-world system.

   The idea of VEX is that each actor in a software supply chain should be responsible for providing information about the exploitability of vulnerabilities in the specific context of their own product/component. That way, consumers further down the chain will be able to make faster, more informed decisions, and the people best-equipped to understand the full context of a vulnerability will be the ones responsible for its remediation. ↩