# CVE fallback for other ecosystems **URL:** \ **Category:** Grype\ **Created:** [January 29, 2026, 5:35pm UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597 "2026-01-29T17:35:01Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![bhogan](https://avatars.discourse-cdn.com/v4/letter/b/ed8c4c/32.png) [@bhogan](https://anchorecommunity.discourse.group/u/bhogan)\ **Post date:** [January 29, 2026, 5:35pm UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597/1 "2026-01-29T17:35:01Z")
I am curious about CPE fallback matching. The [docs linked here](https://oss.anchore.com/docs/guides/vulnerability/ecosystems/#other-packages) 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. > **[NVD - CVE-2025-52561](https://nvd.nist.gov/vuln/detail/CVE-2025-52561)** ![Screenshot 2026-01-29 at 12.25.37 PM](https://global.discourse-cdn.com/free1/uploads/anchorecommunity/original/1X/14a024426d19817a9eec1ce364194ee1731afb61.png) 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! ---
**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\ **Post date:** [January 30, 2026, 10:46am UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597/2 "2026-01-30T10:46:38Z")
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. - [Create a provider for Julia advisories · Issue #966 · anchore/vunnel · GitHub](https://github.com/anchore/vunnel/issues/966) - [Create a provider for perl CPAN advisories · Issue #967 · anchore/vunnel · GitHub](https://github.com/anchore/vunnel/issues/967) - [Create a provider for R advisory data · Issue #969 · anchore/vunnel · GitHub](https://github.com/anchore/vunnel/issues/969) 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: ```yaml 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 ---
**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\ **Post date:** [January 30, 2026, 10:51am UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597/3 "2026-01-30T10:51:46Z")
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](https://github.com/anchore/grype/tree/main/grype/matcher) It might be worth exposing commands to list the available matchers like we do catalogers for syft at some point. ---
**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\ **Post date:** [January 30, 2026, 10:58am UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597/4 "2026-01-30T10:58:29Z")
And I also agree that the docs around this could be improved, thanks for raising it! ---
**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\ **Post date:** [January 30, 2026, 1:33pm UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597/5 "2026-01-30T13:33:40Z")
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? ```sh $ 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](https://nvd.nist.gov/vuln/detail/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](https://github.com/JuliaLang/SecurityAdvisories.jl/blob/ebb3a5153bb775b4a3aa1ebab247e904827b54d6/advisories/published/2025/JLSEC-2025-39.md?plain=1#L9) 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. ---
**Author:** ![bhogan](https://avatars.discourse-cdn.com/v4/letter/b/ed8c4c/32.png) [@bhogan](https://anchorecommunity.discourse.group/u/bhogan)\ **Post date:** [February 4, 2026, 4:03am UTC](https://anchorecommunity.discourse.group/t/cve-fallback-for-other-ecosystems/597/6 "2026-02-04T04:03:36Z")
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!