CVE fallback for other ecosystems

Grype
1

I am curious about CPE fallback matching. The docs linked here list 5 specific package types that rely on CPE matching (binary executables, Homebrew, Jenkins, Conda, WordPress). Is that list exhaustive, or should we expect other vulnerabilities in NVD to be available for matching?

Here is an example Julia vulnerability that I would hope to see in the grype db and is motivating the question.

Screenshot 2026-01-29 at 12.25.37 PM
Screenshot 2026-01-29 at 12.25.37 PM769Ă—197 15.6 KB

Aside from Julia, the same question would apply to other ecosystems that are not covered by GHSA such as R/CRAN. I was glad to see R packages are supported when generating an SBOM from Syft, and it would be great to be able to scan those SBOMs for vulnerabilities as well. Thanks!

2

Hi, any language package ecosystems not currently covered by a more authoritative source will fall back to only CPE matching against NVD. We have some vunnel issues filed to add some additional sources that are not covered by GHSA, but have not had capacity to implement them yet, therefore all of them will currently fall back to CPE matching.

You can see the currently available matchers in your version of grype by running grype config and looking at the match section. So, for instance, with v0.106.0 we get this:

match:
  java:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_JAVA_USING_CPES)
    using-cpes: false

  jvm:
    # (env: GRYPE_MATCH_JVM_USING_CPES)
    using-cpes: true

  dotnet:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_DOTNET_USING_CPES)
    using-cpes: false

  golang:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_GOLANG_USING_CPES)
    using-cpes: false

    # use CPE matching to find vulnerabilities for the Go standard library (env: GRYPE_MATCH_GOLANG_ALWAYS_USE_CPE_FOR_STDLIB)
    always-use-cpe-for-stdlib: true

    # allow comparison between main module pseudo-versions (e.g. v0.0.0-20240413-2b432cf643...) (env: GRYPE_MATCH_GOLANG_ALLOW_MAIN_MODULE_PSEUDO_VERSION_COMPARISON)
    allow-main-module-pseudo-version-comparison: false

  javascript:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_JAVASCRIPT_USING_CPES)
    using-cpes: false

  python:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_PYTHON_USING_CPES)
    using-cpes: false

  ruby:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_RUBY_USING_CPES)
    using-cpes: false

  rust:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_RUST_USING_CPES)
    using-cpes: false

  stock:
    # use CPE matching to find vulnerabilities (env: GRYPE_MATCH_STOCK_USING_CPES)
    using-cpes: true

  dpkg:
    # (env: GRYPE_MATCH_DPKG_USING_CPES)
    using-cpes: false

    # strategy for handling missing epochs in dpkg package versions during matching (options: zero, auto) (env: GRYPE_MATCH_DPKG_MISSING_EPOCH_STRATEGY)
    missing-epoch-strategy: 'zero'

    # use CPE matching for packages from end-of-life distributions (env: GRYPE_MATCH_DPKG_USE_CPES_FOR_EOL)
    use-cpes-for-eol: false

  rpm:
    # (env: GRYPE_MATCH_RPM_USING_CPES)
    using-cpes: false

    # strategy for handling missing epochs in RPM package versions during matching (options: zero, auto) (env: GRYPE_MATCH_RPM_MISSING_EPOCH_STRATEGY)
    missing-epoch-strategy: 'auto'

    # use CPE matching for packages from end-of-life distributions (env: GRYPE_MATCH_RPM_USE_CPES_FOR_EOL)
    use-cpes-for-eol: false

Essentially any ecosystem lacking a specific matcher will fall into the stock matcher and will only attempt CPE matches against the NVD dataset at this time

3

I guess it isn’t strictly true that all of the available matchers are raised by grype config though as some matchers currently don’t expose any config options and therefore are not included in that output, you can see the full list of matchers in the code for instance grype/grype/matcher at main · anchore/grype · GitHub

It might be worth exposing commands to list the available matchers like we do catalogers for syft at some point.

4

And I also agree that the docs around this could be improved, thanks for raising it!

5

Hi @bhogan, I just wanted to add an answer to a small question here:

Why doesn’t CVE-2025-52561 show up in grype’s database?

$ grype db search --vuln CVE-2025-52561
No results found

The reason is that the CVE is “awaiting analysis” by NVD: NVD - CVE-2025-52561

That means that NVD has not assigned any CPEs to it, which means that we have nothing to match against.

As @westonsteimel pointed out, we hope to pull in Julia-specific security data, which, based on a quick look at their data would allow us to surface that vulnerability ahead of NVD’s reviewing it.

Great question! Please let us know if there’s anything else we can help with.

6

A belated thank you both for the details responses! I understand now that the grype database is only going to include NVD CVE’s if they have been assigned a CPE. i.e. you’re not populating the database with records that have no chance of matching anything.

I’m glad to see that adding Julia/perl/R were on your radar already with existing github issues. I’ll take a look at vunnel and see if I could help with a PR there. It looks like there are nice docs and examples for contibuting. Thanks again!

1 Like