Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: call out that vulnerabilities in non-default configurations are still vulnerabilities.

It is ASF Policy that we create a CVE advisory for all vulnerabilities in our released codeartifacts, including "low-severity" ones or issues that only affect non-default (but valid) configurations. The goal of an advisory is to give operators the information they need to make an informed decision about the possible urgency to update.

...

In other words, what is or isn't a vulnerability may be different across projects: projects have some freedom to describe the expected behavior. In cases where it is not obvious whether a behavior should be considered a vulnerability, this might be something to include in the security policy/model as described in Documenting your security model. In such cases it's generally OK to err on the side of caution and issue a CVE: it is a signal of maturity more than a signal of security problems.

When a report points out a behavior that cannot impact confidentiality, integrity or availability on its own, or only on misconfigured deployments, it might still be good to 'fix' it by improving the default configuration, behavior, or otherwise adding safeguards to protect against those risks. Such 'security hardening' improvements do not require a CVE.

We typically don't create advisories for vulnerabilities in dependencies (see Dealing with security advisories for dependencies), though in cases where the impact is particularly severe or the dependency is difficult to detect a project may choose to publish an advisory anyway as a courtesy.

...