How Does My Scanner See HeroDevs? Snyk Edition

It's important to keep your code secure. But even if your application is secure, there is often another hurdle lurking: your software scanner. If you can't upgrade to the latest OSS versions, HeroDevs Never Ending Support becomes a great option. You're patched, covered, and secure with NES. But you still need your scanner to align with reality.

If your Snyk dashboard is reporting vulnerabilities after installing NES for Spring, you’re still secure. Snyk just doesn’t know it yet. Despite Spring Boot 2.7 reaching end-of-life in November 2023 (meaning no more security patches from the OSS project), there's a way to get that count to zero without upgrading. Here's how to clear those false findings using NES for Spring as a drop-in replacement.

‍

TL;DR

NES for Spring patches the vulnerabilities at the code level. Using a .snyk policy file can clear the false positives that Snyk flags due to version-matching limitations. The end result: zero reported vulnerabilities in your Snyk dashboard with everything suppressed by the .snyk policy file having a clear audit trail to explain why it was suppressed.

‍

Snyk Basics

Snyk is able to scan for vulnerabilities using CLI commands like snyk sbom test (for scanning an SBOM) or snyk monitor (for scanning build files). At the time of writing, snyk sbom test does not support exclusions, so we will use snyk monitor in this blog.

‍

The Problem

For our sample application, let's consider Spring Pet Clinic using the last Boot 2.7 OSS release, Boot 2.7.18. Running snyk monitor against this application produces 15 findings tied directly to Spring Framework and Spring Boot packages - a mix of high, medium, and low severity issues.

These issues aren't trivial, either. They include path traversal, open redirect, incorrect authorization, and input validation vulnerabilities, all disclosed after Spring Boot 2.7 went end-of-life. This means these CVEs have not and will not be patched in your OSS Spring project.

If you can't upgrade to the latest version of Spring Boot right now - whether due to compatibility constraints, budget, or timeline - these findings just sit there. Snyk keeps reporting them. Auditors keep asking about them. You keep having to explain why they aren't patched.

‍

Step 1: Replace OSS Spring with NES for Spring

HeroDevs NES for Spring is a commercially supported secure version of the Spring Boot 2.7.x and Spring Framework 5.3.x line. It provides patched artifacts that are a drop-in replacement with the OSS releases - meaning you swap the dependencies and everything else stays the same. See the NES for Spring setup docs for details on configuring your project.

NES for Spring patches all vulnerabilities at the code level. But even with no vulnerabilities in your code, you still need your scanner to recognize the fact that you're secure.

After switching to NES for Spring and re-scanning, 5 of the 15 Spring CVEs disappear immediately. Snyk recognizes that those vulnerabilities have been resolved in the updated artifacts.

The remaining 10 findings are false positives (findings that Snyk reports as vulnerable even though the underlying code has already been patched). This happens because Snyk's version matching does not currently recognize the NES versioning scheme (e.g., 5.3.39-spring-framework-5.3.48 vs 5.3.39). As far as Snyk is concerned, it's still seeing a Spring Framework 5.3.x artifact, so it flags CVEs that HeroDevs has already fixed.

‍

Step 2: Apply a .snyk Policy File

Snyk supports a policy file (.snyk) that lets you mark specific findings as ignored, with a documented reason for each. This is the mechanism for clearing the false positives from Step 1. One important detail: the .snyk policy is enforced in the Snyk web dashboard when you import your project with snyk monitor (run against your project source, not the SBOM). CLI scans like snyk sbom test will detect the file but still report the false positives in their output. The dashboard is where the suppressed findings are reflected.

Each entry in the .snyk file references the exact HeroDevs release that remediated the CVE, so every suppression is traceable and auditable:

version: v1.5.0
ignore:
  'SNYK-JAVA-ORGSPRINGFRAMEWORK-8230373':
    - '*':
        # CVE-2024-38819
        reason: 'HeroDevs Remediated in 5.3.39-spring-framework-5.3.42'
  'SNYK-JAVA-ORGSPRINGFRAMEWORKBOOT-9804539':
    - '*':
        # CVE-2025-22235
        reason: 'HeroDevs Remediated in 2.7.18-spring-boot-2.7.25'

‍

After importing with snyk monitor, every HeroDevs-remediated CVE moves to Ignored status in the dashboard with a clear reason field.

The result: zero open Spring vulnerabilities - exactly as it should be when you use HeroDevs NES for Spring.

CVE Counts

Why Not Just Ignore Without NES?

You could write a .snyk file against the OSS build and ignore all 15 Spring CVEs. But that would be suppressing real, unpatched vulnerabilities. Snyk would stop flagging them, but all you'd be doing is pretending your project is secure. The .snyk policy only tells Snyk to stop reporting them; it doesn't actually fix anything.

With HeroDevs NES for Spring, the code is actually patched. The .snyk file exists solely to bridge the gap between what HeroDevs has fixed and what Snyk's version matching can detect. That's a meaningful difference when an auditor asks why findings were suppressed.

‍

Scaling This Across Projects

If your organization monitors multiple Spring projects in Snyk that are covered by HeroDevs Never Ending Support, you don't need to manually create a .snyk file for every repository. Snyk provides organization-level policy mechanisms that can help you standardize suppression rules across projects, so your team isn't maintaining these individually.

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

If you're still running Spring Boot 2.7, the vulnerability count isn't just a number. Check out everything that Spring Pet Clinic on Boot 2.7 is vulnerable to:

Summary

With HeroDevs NES for Spring, the code is actually patched and secure. You can use a .snyk file to bridge the gap between what HeroDevs has fixed and what Snyk's version matching can detect. That's a meaningful difference when an auditor asks why findings were suppressed. With the .snyk file and HeroDevs, you have the receipts showing that the fixes have been provided. This makes auditors happy.