HeroDevs Now Publishes VEX Data: Fewer False Positives, Less Noise

HeroDevs now publishes Vulnerability Exploitability eXchange (VEX) data for our Never-Ending Support product catalog. With over 48,000 CVEs published in 2025, security teams are drowning in alerts. VEX lets your scanning tools automatically filter out the noise and surface only what matters.

‍

Getting Started: Accessing HeroDevs VEX Data

The HeroDevs VEX feed is available now via API:

Full VEX document: https://apps.herodevs.com/api/ontology/vex/statements

API documentation: https://docs.herodevs.com/api/ontology-vex

Important: HeroDevs VEX statements apply exclusively to HeroDevs Never-Ending Support products. They are not applicable to upstream open-source versions of the same software.

‍

What Is VEX, and Why Does It Matter?

A VEX document is a machine-readable advisory that declares the status of a specific product with respect to a specific vulnerability. When a vulnerability scanner ingests a VEX statement, it can automatically filter out false positives — alerts for vulnerabilities that are already fixed or simply don't apply to your build.

This is especially valuable for organizations running supported, long-term versions of software. HeroDevs actively patches vulnerabilities in our products as they are disclosed. VEX communicates that work to your scanning tools automatically.

‍

HeroDevs VEX Is Published in OpenVEX

CISA defines minimum requirements for VEX, and several implementations now exist:

• OpenVEX — spec
• CSAF VEX profile — spec
• CycloneDX VEX — spec
• SPDX 3.0 — spec

We chose OpenVEX because it is purpose-built for VEX, lightweight, and gaining broad adoption across the tooling ecosystem. Two of the most widely used open-source vulnerability scanners — Trivy (Aqua Security) and Grype (Anchore) — already accept OpenVEX documents natively. See Trivy's VEX support and Grype's VEX filtering.

‍

A Concrete Example

The following OpenVEX statement declares that CVE-2025-66412 is fixed in HeroDevs' secure fork of the @angular/compiler package:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://openvex.dev/docs/public/vex-0f128284-d5a0-416b-94a8-4e854aae1987",
  "author": "HeroDevs",
  "version": 1,
  "timestamp": "2026-02-03T16:46:19.863905885Z",
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-2025-66412",
        "aliases": ["GHSA-v4hv-rgfq-gp49"]
      },
      "products": [
        {
          "@id": "pkg:npm/%40neverendingsupport/angular-compiler@10.2.5-angular-10.2.14"
        }
      ],
      "status": "fixed"
    }
  ]
}

‍

Note the pkg: product identifier — that's a PackageURL (purl). The OpenVEX spec recommends purls as the standard way to identify packages, and HeroDevs already uses them across our catalog API. See the purl spec for details. That consistency is what makes automated scanning work seamlessly.

‍

Integrating VEX Into Your Scanning Workflow

The most direct way to reduce false positives is to pair HeroDevs VEX data with a scanner that already supports OpenVEX. Both Trivy and Grype support it natively.

To configure either scanner to ingest HeroDevs VEX statements, start with their official docs: Trivy VEX configuration and Grype VEX configuration. If you'd rather see a working example first, our Scanners Workflows Guide includes a full walkthrough scanning Spring PetClinic with HeroDevs VEX statements using both tools.

‍

How This Fits With What You Already Have

HeroDevs already publishes two security resources for every vulnerability we address. The Vulnerability Directory describes each vulnerability in detail, explains how to mitigate it, and in many cases reproduces it. Our release notes list security fixes on a per-product basis.

Both of those stay exactly where they are. The VEX feed is a complement, not a replacement: it's the machine-readable version of that same data, built for scanning tools and DevSecOps pipelines.

‍

‍