Share

Finding a vulnerability is only the beginning.

Modern applications depend on hundreds or even thousands of software components, and vulnerability scanners are essential for identifying known security issues across those dependencies.

But there is a problem: the presence of a vulnerable dependency does not always mean your application is actually exploitable.

A scanner may identify a CVE in a dependency bundled with your runtime, but it often cannot answer the next—and arguably more important—question:

Does this vulnerability actually affect my application or runtime?

That missing context can lead to noisy security reports, unnecessary investigations, and engineering teams spending time triaging vulnerabilities that may never be reachable in their environment.

This is where VEX — Vulnerability Exploitability eXchange — comes in.

And N|Solid now includes OpenVEX information to provide additional context around vulnerabilities affecting components distributed with the runtime.

---

Running an EOL Version of Node.js?

An unsupported runtime may continue working today while security, dependency compatibility, and operational risk accumulate around it.

Understand your application's upgrade risk and build a clear path to a supported Node.js release with the NodeSource Upgrade Program.

Assess Your Node.js Upgrade Risk →

---

What is VEX?

VEX is a standardized way for software producers to communicate whether a known vulnerability actually affects a specific product.

Instead of simply saying:

Dependency X contains CVE-XXXX

VEX adds another layer of information:

Dependency X contains CVE-XXXX

Status: NOT AFFECTED
Reason: Vulnerable code is not in the execution path

Or:

Status: FIXED
Action: Upstream fix has been backported

In other words, vulnerability databases tell us that a vulnerability exists.

VEX helps explain whether that vulnerability is relevant to a specific product.

OpenVEX is an open implementation of the Vulnerability Exploitability eXchange specification. It represents this information using minimal, interoperable JSON-LD documents that can be generated and consumed by security tooling.

Why vulnerability detection alone isn't enough

Imagine a vulnerability scanner analyzes a Node.js runtime and discovers a package associated with a known CVE.

The immediate result might look something like this:

N|Solid
    └── npm
           └── dependency
                  └── CVE detected      🚨

Without additional information, a security team now needs to investigate:

• Is the vulnerable functionality actually used?
• Is the vulnerable code reachable?
• Does the runtime configuration expose the vulnerable behavior?
• Has the issue already been mitigated?
• Has a fix been backported?

These are not questions a package version alone can answer.

A dependency can technically contain vulnerable code while the product consuming that dependency never executes the affected path.

That distinction matters—especially for organizations managing large fleets of applications where every vulnerability alert may create operational work.

How N|Solid uses OpenVEX

OpenVEX support was introduced into the N|Solid 6.x runtime release line with N|Solid 6.3.7, released on September 24, 2026.

The release includes support for packaging OpenVEX information, N|Solid-specific OpenVEX exceptions, versioned VEX statements, and vulnerability assessments for specific CVEs.

N|Solid publishes this information in an OpenVEX document maintained by N|Solid Security.

The OpenVEX file is available in two places:

• In distributed N|Solid packages at share/doc/nsolid/nsolid.openvex.json
• In the N|Solid repository at tools/vex/nsolid.openvex.json

This makes the vulnerability exploitability data available both as part of the distributed runtime and directly from the N|Solid source repository.

The document connects three important pieces of information:

Vulnerability
     ↓
Affected software component
     ↓
N|Solid exploitability assessment

That assessment can include a status, a technical justification, and an impact statement explaining why the vulnerability does—or does not—affect N|Solid.

A real example: CVE-2026-48815

The current N|Solid OpenVEX document includes an assessment for CVE-2026-48815, associated with sigstore@3.1.0.

A vulnerability scanner looking only at package versions could identify the component and report the CVE.

N|Solid's VEX assessment adds the missing context.

The vulnerability is classified as:

status: not_affected

justification:
vulnerable_code_not_in_execute_path

The accompanying impact assessment explains that the vulnerable behavior is not exploitable through the supported npm CLI workflows used by the runtime.

That changes the security conversation considerably.

Instead of:

🚨 Vulnerability detected

→ Investigation required

security tooling and teams can work with additional information:

Vulnerability detected
          ↓
OpenVEX assessment
          ↓
NOT AFFECTED
          ↓
Technical justification available

The vulnerability still exists upstream.

But N|Solid can communicate that the specific way the affected component is used does not expose the vulnerable behavior.

VEX can communicate fixes too

VEX is not limited to declaring that a product is unaffected.

The N|Solid OpenVEX document also contains CVE-2026-9496, which is marked:

status: fixed

In this case, the accompanying action statement explains that the upstream fix was backported and the vulnerable logic was replaced.

This gives security teams more useful information than a binary vulnerable/not-vulnerable result.

The product can communicate not only that a vulnerability was identified, but also what happened to it.

SBOM tells you what's there. VEX tells you what it means.

VEX becomes particularly useful when combined with a Software Bill of Materials (SBOM).

An SBOM answers:

What components are inside this software?

For example:

Application
 ├── Component A
 ├── Component B
 ├── Component C
 └── Component D

A vulnerability scanner can then correlate those components with known CVEs.

VEX adds another layer:

SBOM
"What is inside the software?"
          ↓
Vulnerability Scanner
"Which components have known CVEs?"
          ↓
VEX
"Do those vulnerabilities actually affect this product?"

Together, these technologies give security teams a much clearer view of software supply chain risk.

Less vulnerability noise, better prioritization

The goal isn't to hide vulnerabilities.

It's the opposite.

The goal is to provide better information about them.

A long list of CVEs without product-specific context forces security teams to spend time determining which findings actually require action.

Exploitability information can help teams distinguish between:

A vulnerability exists

and:

This vulnerability creates exploitable risk in this product.

That means teams can spend less time investigating irrelevant findings and focus attention on vulnerabilities that actually require remediation.

For organizations running Node.js at scale, that context can become increasingly valuable as dependency trees, security requirements, and vulnerability feeds continue to grow.

Security needs context, not just more alerts

Identifying vulnerable dependencies is essential.

But detection alone does not provide the full security picture.

Teams also need to understand whether vulnerable code is reachable, whether mitigations already exist, whether a vulnerability has been fixed, and how the affected component is actually used.

By publishing OpenVEX assessments alongside N|Solid, NodeSource can provide that additional layer of vulnerability intelligence directly from the team maintaining the runtime.

Because knowing that a CVE exists is useful.

Knowing whether it can actually affect your runtime is better.

Explore the N|Solid OpenVEX data on GitHub and learn more about how N|Solid helps teams run secure, production Node.js applications.