It is ASF Policy that we create a CVE advisory for all vulnerabilities in our released artifacts, including:

  • "low-severity" vulnerabilities
  • vulnerabilities that only affect non-default (but valid) configurations
  • vulnerabilities that were found by ourselves rather than reported by an external party

The goal of an advisory is to give operators the information they need to make an informed decision about the possible urgency to update.

A 'vulnerability' is defined by Mitre as:

An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.

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.

Advisories for documentation or example code

We generally don't issue advisories for errors in the documentation or example code. However, in some cases, when following the old documentation or example would have led to a seriously insecure deployment, the advisory mechanism is used to notify users to check their configurations and verify whether they're affected.

Updates to advisories

It is technically possible to update an already-published advisory: for example, when a published advisory was unclear or incomplete, you can amend the CVE and contact the ASF Security Team at security@apache.org to get your updates published.

However, it is not allowed to use this process to widen the affected version range or increase the issue severity: downstream consumers of the CVE feed may have already made decisions based on the 'old' information, and we cannot assume that they would see updates to the CVE. Because of this, if you discover an issue is more severe or affects more versions than initially assumed, you will have to issue a new CVE to signal this. This new CVE may be similar to the previous one, or focus only on the newly-discovered information.

  • No labels