Page History

...

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.

...