Grype is reporting a high number of vulnerabilities in one instance, while the other scan returns zero findings.

Grype
1

Dear Anchore,

I apologize for the interruption, but I am encountering a technical issue and would greatly appreciate your expert opinion.

Our initial image scans were completely clean and remain so to this day. However, when our customer performed a scan using Grype, it generated a massive number of vulnerabilities. More importantly, we found several highly suspicious points in the report:

  • First: As shown in the attached image (underlined in red), I have never seen Grype express versions in this format: 2.4.58-150600.5.32.2. This naming convention is more typical of Trivy rather than Grype.

  • Second: If they were using Trivy but somehow exported it using a Grype template, the CVE ID format CVE-2020-9490 is consistent with Grype’s style, whereas Trivy usually outputs formats like SUSE-SU-2025:02684-1.

  • Third: When I click on CVE-2020-9490, it redirects me to: https://security-tracker.debian.org/tracker/CVE-2020-9490. While I understand Grype pulls data from multiple sources, does it seem unusual that nearly a thousand errors all point to this single source?

For your reference, here is the command we used that yielded no errors:

Bash

syft customer-registry.example.com/abc/xzy_prod:latest \
  -o cyclonedx-json \
  --scope squashed \
  > xzy_prod.cyclonedx.json

grype sbom:./xzy_prod.cyclonedx.json \
  --add-cpes-if-none \
  --show-suppressed \
  --output template \
  --template /root/html_Grype.tmpl \
  --distro auto \
  --verbose \
  > report_xzy_prod.cyclonedx.json.cyclonedx_sbom.html

Additionally, I would like to ask: is there any official way or existing integration to combine Trivy and Grype together in a single workflow?

We are trying to determine if these results are legitimate or if there is a configuration error/template mismatch occurring. I look forward to hearing your insights on this matter.

Best regards,

image
image640Ă—684 53.6 KB

2

This looks like an RPM version with a very high number in the middle. I’ve seen these sometimes, typically in SUSE Linux fixed versions. Grype gets its versions from the upstream data provider and there is no “usual format” for Grype to express versions.

I don’t know much about Trivy. Grype uses vulnerability IDs from the upstream data source. So for example if a package was affected by a GitHub Security Advisory you would see a GHSA ID. Many upstream data sources normalize their IDs to be the same as NVD CVE IDs, so that’s probably why you’re used to seeing those in Grype.

It’s definitely surprising for there to be a thousand findings in one SBOM about the same CVE. The issue could be that the SBOM contains the same package many, many times. Grype considers each package separately. It looks like you’re using a template to render Grype’s output as HTML? I recommend having a look at the JSON output - that would eliminate a bug in the template itself, which is always possible.

There is not.

Some suggestions:

  1. Grype works best on a Syft SBOM, but in your example, you are saving a CycloneDX SBOM and then pointing Grype at it. Try pointing it at a Syft SBOM. (-o json from Syft).
  2. Run Grype with JSON format (-o json) and take a look at the JSON to see if the duplicated data exists there.

Without more context on what’s actually being scanned, it’s hard to give more insight than that. If Grype is making links to the Debian issue tracker, than the matching packages are Debian packages (dpkg type) on a Debian distro. So you might take a look at the dpkgs that Syft is finding. However, the match you’ve highlighted in the picture looks to me like a vulnerability on a SUSE Linux RPM that was only fixed in one of SUSE’s various extended support / special distros (hence the very high segment in the version number).

I hope this helps!

1 Like
3

Thank you very much for the information you shared. I truly appreciate your support, as it has been very helpful.