Conflicting config defaults

[benjaminwilcox]

This blog post from Anchore states to stop matching with CPEs: https://anchore.com/blog/say-goodbye-to-false-positives/

However the default configuration settings set:

    # even if CPE matching is disabled, make an exception when scanning for "stdlib".
    always-use-cpe-for-stdlib: true

and

  stock:
    using-cpes: true

Am I missing something here?

[spiffcs]

👋 Thanks for the issue @benjaminwilcox - This is probably on us to update the documentation to be a bit clearer, but for now here is a quick explanation.

Both of these config values live within the larger match section of the grype config.

The first config value you listed always-use-cpe-for-stdlib: true applies only to the Golang standard library package. This means that when grype encounters the stdlib package picked up by syft's golang cataloger it will use CPEs as the match basis. This is different from the default behavior of grype which as you said uses PURLs when available from the GHSA database. The reason for this is that the golang stdlib vulnerabilities are not reported on GHSA.

The second config value dictates when cpes are being used when a package is not part of a more specific ecosystem

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

The stock section at the bottom of this config section tells grype to use cpe matching as a fallback for the case when a package is not part of a more specific ecosystem. An example of this kind of package would be when syft finds a binary package NOT part of an OS package manager package.

So in short, grype's default behavior is to fallback to cpes for particular packages when there isn't a better upstream datasource.

[benjaminwilcox]

Hi @spiffcs, thanks for the explanation, however my question was more about what the best practice should be. The article states to NOT use cpe matching to prevent false positives, but the default grype configs use cpe matching. I would assume that if Anchore's recommendation is not to use cpe matching, then their product's default settings would reflect that and both flags I mentioned would be set to false. So I was wondering if I was misunderstanding something or if this was an oversight and should really be false?

[spiffcs]

No worries! I think the nuance in the article might be found in "Focusing on the Negative" section.

The headline is: "After experimenting with a number of options for improving vulnerability matching, ultimately one of the simplest solutions proved most effective: stop matching with CPEs."

Given the follow up paragraph below though it could probably say "stop matching with CPEs when better data is available"

Our recommendation is definitely of the more the nuanced variety that's reflected in the paragraph below.

This change doesn’t mean all CPE matching is turned off by default, however. 
There are some types of artifacts that Grype still needs to use CPE matching for. 
Binaries, for example, are not present in the GitHub Advisory Database, 
and Alpine only provides entries for things that are fixed, 
so we need to continue using CPE matching to determine the vulnerabilities before 
querying for fix information there. But, for ecosystems supported by the GitHub Advisory Database, 
we can confidently use this data and prevent the plethora of false positives 
associated with CPE matching.

[benjaminwilcox]

@spiffcs d'oh, thanks! I completely overlooked that paragraph. Thanks for the clarity!