How Does My Scanner See HeroDevs? Trivy Edition

Keeping your application secure is only half the battle. The other half is getting your scanner to agree. When you can't upgrade to the latest OSS versions, HeroDevs Never Ending Support delivers patched, secure artifacts as a drop-in replacement. But scanners don't always keep up - and that gap between "actually secure" and "reported as vulnerable" creates real friction with auditors and compliance teams.

Last time, in our series on how different scanners handle HeroDevs NES, we explained how Snyk sees HeroDevs. This time we're looking at Trivy. If Trivy is still flagging Spring vulnerabilities after you've moved to NES for Spring, the code is secure - Trivy's advisory database just hasn't caught up. The good news: Trivy gives us two ways to close that gap, including a standards-based approach using VEX that goes beyond simple suppression.

‍

NES for Spring fixes vulnerabilities in the actual code. HeroDevs-provided VEX statements (or Trivy's native .trivyignore.yaml) handle the remaining scanner noise - false positives caused by version-matching limitations. Either way, you end up with zero reported Spring vulnerabilities and a documented reason behind every suppression.

‍

Trivy Basics

Trivy is an open-source vulnerability scanner for the command line by Aqua Security. It supports container images, filesystems, git repositories, and SBOMs (Software Bills of Materials - a standardized inventory of every component in your application). For this post, we'll be using trivy sbom to scan an SBOM in CycloneDX format, which is the same workflow you'd use in CI/CD.

trivy sbom <your-sbom>.cdx.json

‍

At the time of this writing, the most current Trivy version is 0.69.3 with Vulnerability DB version 2.

‍

The Problem

We'll use Spring Pet Clinic, a common sample application, using the final OSS release of Spring Boot 2.7 (2.7.18) as our test case. Scanning its CycloneDX SBOM with trivy sbom surfaces 17 unique Spring-related CVEs - path traversal, open redirect, authorization bypass, authentication bypass, deserialization, information disclosure, and denial-of-service vulnerabilities spread across critical, high, medium, and low severities.

All but one of these CVEs were disclosed after Spring Boot 2.7 reached end-of-life in November 2023. The OSS project will never patch them. If you're stuck on 2.7 - whether for compatibility, budget, or timeline reasons - these findings accumulate. Each scan produces the same list. Each audit cycle demands the same explanation.

‍

Step 1: Replace OSS Spring with NES for Spring

HeroDevs NES for Spring provides commercially supported, security-patched builds of Spring Boot 2.7.x and Spring Framework 5.3.x. The artifacts are a drop-in replacement - swap your dependencies, keep everything else. See the NES for Spring setup docs for configuration details.

Under the hood, every vulnerability is patched in the source code. The challenge is getting Trivy to see that. After switching to NES and re-scanning, 11 of the 17 Spring CVEs disappear on their own - Trivy's advisory database recognizes those fixes in the updated artifacts.

That leaves 6 CVEs still flagged. These are false positives: Trivy still flags them because its version matching doesn't understand the NES versioning scheme. A NES artifact like 5.3.39-spring-framework-5.3.48 looks like plain 5.3.39 to Trivy, so it reports CVEs that HeroDevs has already resolved. 

‍

Step 2: Apply HeroDevs VEX Statements

VEX (Vulnerability Exploitability eXchange) is a standards-based format for communicating vulnerability status. Rather than telling your scanner to ignore findings, VEX provides machine-readable proof that a vulnerability has been addressed - including who fixed it and when.

Think of VEX as a certificate from your vendor proving each vulnerability was addressed. When you hand that certificate to Trivy, it automatically clears the false positives from your report with no manual suppression required.

HeroDevs provides OpenVEX documents with "fixed" status for NES-remediated CVEs. Each statement identifies the exact package, version, and CVE, giving Trivy the information it needs to clear the false positives automatically. These can be found in the release notes for each version of Spring and Spring Boot on the HeroDevs Docs site.

Here's a sample entry from a HeroDevs VEX document:

{
  "vulnerability": {
    "name": "CVE-2025-22235"
  },
  "products": [
    {
      "@id": "pkg:maven/org.springframework.boot/spring-boot@2.7.18-spring-boot-2.7.27"
    },
    {
      "@id": "pkg:maven/org.springframework.boot/spring-boot@2.7.18-spring-boot-2.7.30"
    }
  ],
  "status": "fixed"
}

‍

To apply the VEX document during a scan, pass it with the --vex flag:

trivy sbom <your-nes-sbom>.cdx.json --vex herodevs-vex.json

‍

After applying the VEX statements, every HeroDevs-remediated CVE is recognized as fixed with a clear, standards-based audit trail.

The result: zero open Spring vulnerabilities reported, with every suppression backed by a documented fix and no false positives.

VEX is the recommended approach because it communicates fixed status in a vendor-neutral, machine-readable format. HeroDevs publishes VEX data that can be used to create VEX statements today.

‍

Step 3: Alternative - .trivyignore.yaml

If your workflow doesn't support VEX yet, Trivy's native .trivyignore.yaml offers an alternative. You list CVE IDs to suppress along with a statement documenting why:

vulnerabilities:
  - id: "CVE-2025-22235"
    statement: "HeroDevs Remediated in 2.7.18-spring-boot-2.7.25"
  - id: "CVE-2024-38820"
    statement: "HeroDevs Remediated in 5.3.39-spring-framework-5.3.42"
  # ... remaining NES-remediated CVEs

‍

Then pass the file during your scan:

trivy sbom <your-nes-sbom>.cdx.json --ignorefile .trivyignore.yaml

‍

Both approaches get you to zero false positives. The difference is that VEX communicates why the vulnerability is no longer present in a standardized, machine-readable format, while .trivyignore.yaml is a local policy decision. For vendor-provided fixes like NES, VEX is the better fit.

‍

CVE Counts

‍

Why Not Just Ignore Without NES?

Nothing stops you from adding all 17 CVEs to a .trivyignore.yaml on the OSS build. Trivy would go quiet. But quiet isn't the same as secure. Those vulnerabilities would still be present in your running application, and the ignore file would be papering over real risk.

The distinction matters: with NES, the vulnerabilities are fixed in the code. VEX statements and .trivyignore.yaml entries exist only to reconcile what HeroDevs has already patched with what Trivy's version matching can see. When an auditor asks "why were these suppressed?", you can point to the actual fix, not a policy decision to look the other way.

‍

Scaling This Across Projects

VEX (recommended): HeroDevs distributes VEX documents that teams can consume directly across many NES-covered projects. As HeroDevs builds out its end-of-life dataset, VEX generation can be automated. This means your organization gets up-to-date fix status for every NES-supported artifact without maintaining exclusion files manually. This scales naturally across teams and scanners, since VEX is a vendor-neutral standard.

.trivyignore.yaml (alternative): If your organization uses Trivy across multiple Spring projects covered by NES, you can maintain a shared .trivyignore.yaml in a central repository or monorepo template and reference it across projects.

Important: Only apply these exclusions to projects built with NES for Spring. The suppressions are specific to HeroDevs-remediated CVEs and should not be used with OSS Spring builds.

‍

CVE Details

Here's the full list of unique Spring and Spring Boot CVEs affecting Pet Clinic on Boot 2.7 as of April 20, 2026. These are the CVEs that NES for Spring resolves:

‍

Note: CVE-2024-38820 appears across multiple Spring packages (spring-context, spring-web) in Trivy's output but is counted once above as a single unique CVE.

‍

Summary

HeroDevs NES for Spring patches the vulnerabilities where it counts - in the code. VEX statements give Trivy (and any other VEX-aware scanner) machine-readable proof that those fixes exist. The result is a clean scan backed by real remediation, not just suppressed alerts. When compliance asks for evidence, you have it: the fix, the VEX document, and the audit trail connecting the two.