For what issues to create advisories

It is ASF Policy that we create a CVE advisory for all vulnerabilities in our released code, including "low-severity" ones. 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.

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.

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.