Introduction

This page provides guidance on what constitutes a vulnerability eligible for CVE assignment by our CNA. It is based on official CVE Program definitions, industry best practices, and ecosystem-specific considerations.

The CVE program deliberately avoids strict rules for many edge cases—CVE assignment involves CNA judgement. This document outlines our approach.

What is a Vulnerability?

The official CVE Program definition from the CVE Glossary:

Vulnerability: A weakness in the computational logic found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.

This definition is the core citation used when determining whether an issue qualifies for CVE assignment.

When We Assign a CVE

We assign a CVE when all of the following conditions are met:

  1. The issue exists in a released product — The vulnerability must be present in publicly released software, not just in development branches.

  2. It can be triggered by an attacker — There must be a realistic attack vector where an external party can exploit the issue.

  3. It causes confidentiality, integrity, or availability impact — The exploitation must result in a meaningful security impact.

  4. It violates the intended security model — The issue causes the system to violate a security property it is designed to enforce.

CNA Heuristic Checklist

This practical checklist summarizes common considerations CNAs use when deciding whether an issue warrants a CVE:

  • Is there a security property being violated? The issue must allow an attacker to bypass access controls, authentication, or other security mechanisms.

  • Is the issue reachable in realistic deployment? The vulnerability must be exploitable in a normal, supported configuration—not just in contrived or unsupported setups.

  • Does the attacker gain something they shouldn’t have access to? There must be a concrete impact: unauthorized data access, privilege escalation, denial of service, or code execution.

  • Is the issue independently fixable? It must be addressable through a change in the affected product itself, not dependent on external factors.

  • Does it affect users who follow documented practices? If exploitation requires ignoring warnings, disabling security features, or misconfiguring the application, it may not qualify.

What is NOT a Vulnerability

General Cases

We do not assign CVEs for issues that:

  • Are misuse of internal or private interfaces — If the issue requires directly calling functions or APIs that are not part of the public interface, it is not a vulnerability.

  • Are only possible after modifying the source — If exploitation requires changing the source code, it is not a vulnerability in the released product.

  • Do not cross a security boundary — If there is no security mechanism being bypassed, there is no vulnerability. For example, a function that crashes when given invalid input is a bug, not a vulnerability, unless that crash can be triggered across a trust boundary.

Ecosystem-Specific: Internal Modules

Modules marked as internal in this ecosystem are not part of the public interface and not part of the security boundary of a project. Vulnerabilities that can only be exploited by calling internal functions directly are not considered vulnerabilities.

Elixir

In Elixir, internal modules and functions are marked as follows:

  • Modules with @moduledoc false — These modules are considered internal and must not be directly invoked as part of the supported security boundary of the product.
  • Functions with @doc false — These functions are considered internal and must not be directly invoked as part of the supported security boundary of the product.

Erlang

In Erlang (OTP 27+), internal modules and functions are marked as follows:

  • Modules with -moduledoc false. — These modules are considered internal and must not be directly invoked as part of the supported security boundary of the product.
  • Functions with -doc false. — These functions are considered internal and must not be directly invoked as part of the supported security boundary of the product.

Gleam

In Gleam, internal code is identified by:

  • Internal modules — Modules configured as internal in gleam.toml are considered internal and must not be directly invoked as part of the supported security boundary of the product. By default, this includes $PACKAGE_NAME/internal.gleam and $PACKAGE_NAME/internal/**/*.gleam.
  • Functions with @internal — Functions marked with the @internal attribute are considered internal and must not be directly invoked as part of the supported security boundary of the product.

Official References

These are the authoritative sources for CVE assignment decisions:

  • CVE CNA Rules — The official policy document defining CNA responsibilities and when CVEs should be assigned.

  • CVE Glossary — Official definitions including the core “vulnerability” definition.

  • NVD CNA Counting Rules — Practical guidance on counting and grouping vulnerabilities, including what does not constitute a security vulnerability.

  • MITRE Root CNA Guidance — Supplemental guidance on vulnerability determination, disputed issues, and scope boundaries.