├── CNA_Rules.md ├── CVE_Board_Charter.md ├── CVE_Dispute_Policy.md ├── CVE_EOL_Policy.md ├── CVE_Inactive_CNA_Policy.md ├── Glossary.md ├── README.md ├── archive ├── Board_Charter_v3.4.pdf ├── Board_Charter_v3.5.pdf ├── CNA_Rules_v1.1.pdf ├── CNA_Rules_v2.0.pdf ├── CNA_Rules_v3.0.pdf ├── CNA_Rules_v4.0.pdf ├── CNA_Rules_v4.1.0.pdf └── CVE-Record-Dispute-Policy.pdf └── assets └── dispute_flowchart.png /CNA_Rules.md: -------------------------------------------------------------------------------- 1 | # CVE Numbering Authority Operational Rules 2 | 3 | | Status | Final | 4 | | ---: | :--- | 5 | | Version | 4.1.0 | 6 | | Approved | 2025-05-14 | 7 | | Effective | 2025-05-14 | 8 | 9 | ## Table of Contents 10 | 11 | 1. [Introduction](#1-introduction) 12 | 13 | 1.1 [Background](#11-background) 14 | 15 | 1.2 [Adherence to CVE Program Policies and Rules](#12-adherence-to-cve-program-policies-and-rules) 16 | 17 | 1.3 [Document Purpose](#13-document-purpose) 18 | 19 | 1.4 [Terms and Definitions](#14-terms-and-definitions) 20 | 21 | 1.5 [Other Useful Information](#15-other-useful-information) 22 | 23 | 2. [Managing the CNA Operational Rules](#2-managing-the-cna-operational-rules) 24 | 25 | 2.1 [Changes to the CNA Operational Rules](#21-changes-to-the-cna-operational-rules) 26 | 27 | 2.2 [Root Additions to the CNA Operational Rules](#22-root-additions-to-the-cna-operational-rules) 28 | 29 | 2.3 [Exceptions to the CNA Operational Rules](#23-exceptions-to-the-cna-operational-rules) 30 | 31 | 2.4 [CNA-LR Operational Rules](#24-cna-lr-operational-rules) 32 | 33 | 3. [CNA Administration](#3-cna-administration) 34 | 35 | 3.1 [CNA Scope Definition](#31-cna-scope-definition) 36 | 37 | 3.2 [CNA Administration](#32-cna-administration) 38 | 39 | 4. [CNA Operational Rules](#4-cna-operational-rules) 40 | 41 | 4.1 [Vulnerability Determination](#41-vulnerability-determination) 42 | 43 | 4.2 [CVE ID Assignment](#42-cve-id-assignment) 44 | 45 | 4.3 [Notification](#43-notification) 46 | 47 | 4.4 [CNA Judgment](#44-cna-judgment) 48 | 49 | 4.5 [CVE Record Management](#45-cve-record-management) 50 | 51 | 4.6 [Dispute Resolution](#46-dispute-resolution) 52 | 53 | 5. [CVE Record Content](#5-cve-record-content) 54 | 55 | 5.1 [Required CVE Record Content](#51-required-cve-record-content) 56 | 57 | 5.2 [Description](#52-description) 58 | 59 | 5.3 [Public References](#53-public-references) 60 | 61 | 5.4 [Example or Test CVE IDs](#54-example-or-test-cve-ids) 62 | 63 | ## 1 Introduction 64 | 65 | ### 1.1 Background 66 | 67 | The [Common Vulnerabilities and Exposures (CVE)](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryProgram) Program is a voluntary, international, community-driven effort to identify, define, catalog, and share information about [Publicly Disclosed](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryPubliclyDisclosed) cybersecurity [Vulnerabilities](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryVulnerability). A [CVE Identifier](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCVEID) (CVE ID) and corresponding [CVE Record](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryRecord) enable multiple parties to discuss and share information with confidence that they are referencing the appropriate Vulnerability. This Vulnerability identification capability is fundamental to global Vulnerability management. 68 | 69 | Within the CVE Program, a [CVE Numbering Authority](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCNA) (CNA) is an organization authorized to assign CVE IDs and publish CVE Records, ideally as part of the initial Public Disclosure of a Vulnerability. Benefits of participating in the CVE Program as a CNA include the ability to Publicly Disclose Vulnerabilities with pre-assigned CVE IDs and the first opportunity to assign CVE IDs for Vulnerabilities within the CNA’s [Scope](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryScope) Definition. In addition to assigning CVE IDs, CNAs also create and publish information about the identified Vulnerability in its associated CVE Record. 70 | 71 | Many CNAs are [Suppliers](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossarySupplier) who assign CVE IDs to and publish CVE Records for Vulnerabilities affecting [Products](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryProduct) owned, developed, or maintained by the Supplier. Examples of CNAs include: 72 | 73 | * Software and hardware Suppliers, including product security incident response teams (PSIRTs) 74 | * Open source software projects, maintainers, and foundations 75 | * Service providers 76 | * Vulnerability researchers 77 | * National computer security incident response teams (CSIRTs) 78 | * Vulnerability coordinators 79 | * Vulnerability databases 80 | * Bug bounty providers 81 | 82 | ### 1.2 Adherence to CVE Program Policies and Rules 83 | 84 | To participate in the CVE Program, CNAs: 85 | 86 | 1.2.1 MUST agree and adhere to program policies, guidance, responsibilities, and rules, which are listed in the Rules & Policies section of the [Resources page](https://www.cve.org/ResourcesSupport/Resources), and 87 | 88 | 1.2.2 MUST operate under the [CVE Terms of Use License](https://www.cve.org/Legal/TermsOfUse), and 89 | 90 | 1.2.3 MUST comply with the CNA Operational Rules defined in this document. 91 | 92 | 1.2.3.1 Serious or repeated failure to adhere to these rules MUST be reviewed by an appropriate [Root](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryRoot). The [CVE Board](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryBoard) MAY revoke CNA status. 93 | 94 | 1.2.3.2 An appropriate Root MUST notify a CNA of any infractions that initiate a review. 95 | 96 | ### 1.3 Document Purpose 97 | 98 | The purpose of this document is to define the rules and practices CNAs, [CNA-LRs](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCNALR), and Roots are expected to follow. This document defines operational rules for: 99 | 100 | * Administering CNAs 101 | * Defining CNA scope 102 | * Identifying and determining Vulnerabilities 103 | * Assigning CVE IDs 104 | * Managing and publishing CVE Records 105 | 106 | ### 1.4 Terms and Definitions 107 | 108 | Specific terms are defined in the [CVE Program Glossary](https://www.cve.org/ResourcesSupport/Glossary) and are capitalized when used in this document. The following fully-capitalized key words explain the requirement levels used in this document: 109 | 110 | * MUST: Mandatory 111 | * MUST NOT: Prohibited 112 | * SHOULD: Recommended 113 | * SHOULD NOT: Not recommended 114 | * MAY: Discretionary 115 | 116 | ### 1.5 Other Useful Information 117 | 118 | To successfully interpret and follow the CNA Operational Rules, it is necessary to read the entire document comprehensively. The correct interpretation of an individual rule may require context provided by other rules. It may be necessary or useful to consult other sources of information, including but not limited to: 119 | 120 | * [CVE Program Glossary](https://www.cve.org/ResourcesSupport/Glossary) 121 | * [CVE Program Policy and Procedure for Disputing a CVE Record](https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf) 122 | * [End of Life Vulnerability Assignment Process](https://www.cve.org/Resources/General/End-of-Life-EOL-Assignment-Process.pdf) 123 | * [CVE Program Policy and Procedure for Inactive CNAs](https://www.cve.org/Resources/General/Policies/Inactive-CNA-Policy.pdf) 124 | * [CVE Record Lifecycle](https://www.cve.org/About/Process) 125 | * [CVE Program Professional Code of Conduct](https://www.cve.org/ResourcesSupport/AllResources/ProfessionalCodeOfConduct) 126 | 127 | ## 2 Managing the CNA Operational Rules 128 | 129 | The CNA Operational Rules are managed, maintained, and approved by the CVE Board. 130 | 131 | ### 2.1 Changes to the CNA Operational Rules 132 | 133 | 2.1.1 Changes to the CNA Operational Rules are subject to approval by the CVE Board. 134 | 135 | 2.1.2 Changes MAY be proposed by CVE Program participants (CNAs, CNA-LRs, Roots, [TL-Roots](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryTLRoot), the [Secretariat](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossarySecretariat), the Board, working groups) to the Secretariat who MUST present them to the Board. 136 | 137 | 2.1.3 When processing changes, the CVE Board MUST consider input from and impact to CVE Program participants, MUST provide advance notice, and MUST provide the opportunity to review and comment. 138 | 139 | 2.1.4 Changes MUST be considered, decided, and documented in a transparent process. 140 | 141 | 2.1.5 Changes MUST NOT be applied retroactively to existing CVE ID assignments and published CVE Records. 142 | 143 | ### 2.2 Root Additions to the CNA Operational Rules 144 | 145 | 2.2.1 A Root MAY make additions to the CNA Rules. The additions MUST only apply to CNAs within the Root’s hierarchy. The additions MUST NOT conflict with the primary CNA Operational Rules described in this document. 146 | 147 | 2.2.2 The Root MUST obtain approval for any such additions from the appropriate TL-Root. 148 | 149 | ### 2.3 Exceptions to the CNA Operational Rules 150 | 151 | 2.3.1 A CNA MAY request an exception to the CNA Operational Rules from the CVE Board. The CNA MUST provide justification for the exception. 152 | 153 | 2.3.2 Only the CVE Board has authority to approve exceptions to the CNA Rules on a case-by-case basis. 154 | 155 | 2.3.3 The Secretariat MUST document any exceptions approved by the CVE Board. 156 | 157 | ### 2.4 CNA-LR Operational Rules 158 | 159 | CNA-LRs typically have broader scopes than CNAs. This can contribute to high rates and volumes of CVE ID assignment requests to a CNA-LR. CNA-LRs: 160 | 161 | 2.4.1 MUST follow the CNA Operational Rules, and 162 | 163 | 2.4.2 MUST follow any additional rules specified by their TL-Root (see [2.2](#22-root-additions-to-the-cna-operational-rules)), and 164 | 165 | 2.4.3 MAY limit effort to optimize service given resource constraints, for example, by not notifying Suppliers who are not CNAs (4.3.2) and by not publishing advisories or other information about vulnerabilities (4.5.2.1) for assigned CVE IDs. 166 | 167 | ## 3 CNA Administration 168 | 169 | ### 3.1 CNA Scope Definition 170 | 171 | CNAs describe which Vulnerabilities they assign CVE IDs and publish CVE Records for using a Scope Definition. For Supplier CNAs, scope is often defined in terms of Products owned, developed, or maintained by the CNA. For Vulnerability research or coordination CNAs, scope is often defined in terms of Vulnerabilities that are researched or coordinated by the CNA. In all cases, the CNA with the most appropriate scope should have the first opportunity to assign (see 4.2.1). The CNA with the most appropriate scope is often, but not always, the Supplier of the Product in question. It is important to define scopes and manage scope overlap in order to minimize duplicate assignments and other confusion. 172 | 173 | 3.1.1 CNAs MUST develop, document, and operate within a Scope Definition that describes the types of Vulnerabilities for which the CNA will assign CVE IDs. 174 | 175 | 3.1.1.1 The Scope Definition is initially established during the CNA on-boarding process and MUST be completed and approved prior to a new CNA being authorized. 176 | 177 | 3.1.1.2 The CNA MUST obtain approval for the Scope Definition from their Root or TL-Root. The Scope Definition is subject to review and final approval by the Secretariat. Approved Scope Definitions MUST be published in the [List of Partners](https://www.cve.org/PartnerInformation/ListofPartners). 178 | 179 | 3.1.2 A CNA MAY change their Scope Definition. Changes are subject to approval as specified in 3.1.1.2. 180 | 181 | 3.1.3 Supplier CNAs SHOULD define Scope in reasonably broad terms, such as: 182 | 183 | * All of a Supplier’s Products: 184 | 185 | Example: “Supplier X’s products only" 186 | 187 | * A list of specific Products: 188 | 189 | Example: "Supplier Y's Remote Desktop Manager and Server products only" 190 | 191 | * A list of covered and not covered Products: 192 | 193 | Example: “All of Supplier Z's Products except for Remote Desktop Manager and Server products" 194 | 195 | * Specifying scope for [End-of-Life](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryEOL) (EOL) Products: 196 | 197 | Example: “Supplier A's supported Products and End-of-Life products” 198 | 199 | 3.1.4 For Scope Definitions based on Products, the Scope Definition MUST include a covered set of Products and MUST NOT only list non-covered items. 200 | 201 | 3.1.5 Scope Definitions SHOULD be general enough to cover the evolving set of Products while being specific enough to understand the assignment boundaries for the CNA. 202 | 203 | 3.1.6 When appropriate, Scope Definitions SHOULD include Product and brand names that are supported during and shortly after mergers and acquisitions, for example: "All XYZ (formerly A and B) Products." 204 | 205 | 3.1.7 CNAs SHOULD update Scope Definitions for significant changes in coverage, for example, the introduction of new Products, Product lines, brands, mergers, or acquisitions that are not covered by an existing Scope Definition. CNAs MAY also change Scope Definitions due to process changes in, for example, EOL handling or Vulnerability reporting. 206 | 207 | 3.1.7.1 CNAs SHOULD NOT update Scope Definitions for minor changes in coverage, for example, new Products or Product versions that are already covered by an existing, sufficiently broad Scope Definition. 208 | 209 | 3.1.8 Research or coordination CNAs SHOULD define Scope in terms of Vulnerabilities that are researched or coordinated by the CNA, unless the Vulnerabilities are covered by a CNA with more specific scope. 210 | 211 | * Example: "…and for Vulnerabilities discovered by Organization Y, if the Product is not in another CNA's scope.” 212 | * Example: "We will assign CVE IDs for Products that we are researching or coordinating unless they are in another CNA’s scope.” 213 | 214 | 3.1.9 When appropriate and clarifying, and subject to scope approval as specified in 3.1.1, a CNA MAY link to additional information to support its Scope Definition. For example: 215 | 216 | * “Supplier Z’s Products listed on https://supplier.example.com/security/cvescope" 217 | 218 | 3.1.10 CNA Scope Definition disputes MUST initially be handled at the Root, TL-Root, or [Council of Roots](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCouncil) level. If the dispute cannot be resolved at these levels, then the dispute MUST be brought to the Secretariat who MUST inform the CVE Board. The CVE Board then makes the final decision. 219 | 220 | 3.1.11 Scope Definitions for End-of-Life (EOL) Products 221 | 222 | 3.1.11.1 A CNA MAY specify in its Scope Definition whether and how the CNA assigns CVE IDs for EOL Products. See 4.2.17.5. 223 | 224 | 3.1.12 Multiple Program Roles 225 | 226 | 3.1.12.1 Multiple roles exist in the CVE Program. Organizations with multiple CNAs or CNA-LRs MUST specify individual Scope Definitions for each CNA or CNA-LR. CVE Program roles are documented in the List of Partners. For example, [MITRE](https://www.cve.org/PartnerInformation/ListofPartners/partner/mitre) currently acts as the Secretariat, a TL-Root, and a CNA-LR. 227 | 228 | ### 3.2 CNA Administration 229 | 230 | 3.2.1 Administration Interfaces 231 | 232 | 3.2.1.1 CNAs MUST use services and mechanisms specified by the CVE Program to manage CNA accounts and other organizational information. 233 | 234 | 3.2.1.2 CNAs MUST disable or deactivate or otherwise manage inactive user accounts in a timely manner, which the Secretariat MAY determine. 235 | 236 | 3.2.2 Administrative Point of Contact 237 | 238 | 3.2.2.1 CNAs MUST provide administrative point of contact (POC) information to their Root, TL-Root, and the Secretariat. The administrative POC will be used to contact the CNA for administrative, governance, and operational reasons, including important or urgent issues requiring escalation. 239 | 240 | 3.2.2.2 The administrative POC MUST include both email addresses and phone numbers and MAY include additional contact methods. 241 | 242 | 3.2.2.3 The administrative POC MAY be shared with CVE Program participants when needed. The administrative POC information MUST not be made available to the general public and MUST NOT be shared outside of CVE Program without prior approval by the CNA. 243 | 244 | 3.2.2.4 CNAs MUST maintain current administrative POC information in the event of changes in personnel or availability. CNAs SHOULD provide at least two individuals or addresses for the administrative POC. 245 | 246 | 3.2.2.5 The administrative POC MUST respond in a timely manner. Automated responses do not qualify as “a timely manner.” 247 | 248 | 3.2.3 Public Point of Contact 249 | 250 | 3.2.3.1 CNAs MUST provide public POC information that is published in the [List of Partners](https://www.cve.org/PartnerInformation/ListofPartners). The public POC is used for requests related to CVE ID assignment, CVE Record content, and other CVE-related issues. 251 | 252 | 3.2.3.2 CNAs MUST inform their Root, TL-Root, and the Secretariat when public POC information changes. 253 | 254 | 3.2.4 Availability and Responsiveness 255 | 256 | 3.2.4.1 Subject to their respective CNA Scope Definitions, CNAs MUST respond in a timely manner to CVE ID assignment requests submitted through the CNA's public POC. 257 | 258 | 3.2.4.2 CNAs SHOULD document their expected response times, including those for the public POC. 259 | 260 | 3.2.4.3 CNAs are subject to the [CVE Program Policy and Procedure for Inactive CNAs](https://www.cve.org/Resources/General/Policies/Inactive-CNA-Policy.pdf). 261 | 262 | 3.2.4.4 CNAs MUST be aware of CVE Program communications through official mechanisms defined by the Program, currently, the CVE CNA Discussion mailing list. 263 | 264 | 3.2.5 Changes to CNA Status 265 | 266 | 3.2.5.1 When a merger, acquisition, or other organizational change materially affects a CNA, the CNA's Root SHOULD review the CNA's Scope Definition and capabilities. The Root MAY decide to re-train or re-qualify the CNA and the CNA may request assistance from the Root. 267 | 268 | 3.2.5.2 As noted in 1.2.3.1, serious or repeated failure to adhere to the CNA Operational Rules MUST be reviewed by the appropriate Root. The CVE Board MAY revoke CNA status. 269 | 270 | 3.2.6 CVE ID Assignment and Vulnerability Disclosure 271 | 272 | The CVE Program itself does not follow or require a specific Vulnerability disclosure policy. CNAs and other CVE Program participants operate under a variety of Vulnerability disclosure policies. Some CNAs do not directly participate in Vulnerability disclosure. Common elements of a Vulnerability disclosure policy include: 273 | 274 | * Making reasonable attempts to notify Suppliers 275 | * Providing good-quality Vulnerability reports 276 | * Describing Vulnerability report intake processes 277 | * Describing bug bounty policies and processes, if applicable 278 | * Setting expectations for response times 279 | * Providing an embargo period during which the Vulnerability will not be Publicly Disclosed while the Supplier develops a [Fix](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryFix) or mitigation 280 | * Coordinating the Public Disclosure date 281 | * Publishing Vulnerability advisories 282 | 283 | 3.2.6.1 CNAs MUST publish guidance that describes how the CNA assigns CVE IDs and publishes CVE Records within the context of Vulnerability disclosure. 284 | 285 | 3.2.6.2 CNAs MUST provide a URL to their CVE ID assignment and Vulnerability disclosure policies that will be included in the List of Partners. 286 | 287 | 3.2.6.3 CNAs MAY require CVE ID assignment to be made using specific processes or mechanisms. Such processes or mechanisms MUST NOT conflict with the CNA Operational Rules. 288 | 289 | 3.2.6.4 A CNA’s Vulnerability disclosure policy MUST NOT prevent the CNA from following the CNA Operational Rules. 290 | 291 | ## 4 CNA Operational Rules 292 | 293 | ### 4.1 Vulnerability Determination 294 | 295 | CVE identifies technical, cybersecurity Vulnerabilities. The [CVE Program Glossary](https://www.cve.org/ResourcesSupport/Glossary) defines a Vulnerability as: 296 | 297 | > 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. 298 | 299 | Vulnerability reports sometimes confuse or conflate multiple Vulnerabilities or "Vulnerability-like" issues. Consistent Vulnerability determination reduces the likelihood of missing or duplicate CVE ID assignments. CNAs are expected, when necessary, to use experience and judgment ([4.4](#44-cna-judgment)) to determine the existence of one or more Vulnerabilities. Roots and TL-Roots may provide additional guidance to their CNAs to supplement the Vulnerability determination ([4.1](#41-vulnerability-determination)) and CVE ID assignment rules ([4.2](#42-cve-id-assignment)) specified in this document. This allows the CVE Program to adapt to definitions used in different industries, technologies, legal regimes, and cultures. Prior to assigning CVE IDs, CNAs MUST follow the rules and guidance in this section to determine the existence, scope, and extent of Vulnerabilities. 300 | 301 | 4.1.1 If a Supplier determines that a Vulnerability exists in a Product, then CNAs SHOULD agree with this determination. 302 | 303 | 4.1.2 Conditions or behaviors that do not lead to a security impact SHOULD NOT be determined to be Vulnerabilities. Examples of security impacts include an increase in access for an attacker, a decrease in availability of a target, or another violation of security policy. 304 | 305 | 4.1.3 Well-documented or commonly-understood non-default configuration or runtime changes made by an authorized user SHOULD NOT be determined to be Vulnerabilities. 306 | 307 | 4.1.4 Insecure default configuration settings SHOULD be determined to be Vulnerabilities. 308 | 309 | 4.1.5 Physical attacks SHOULD NOT be determined to be Vulnerabilities unless there is a specific security feature, supported claim, or policy that defends the Product against the physical attack. 310 | 311 | 4.1.5.1 A Vulnerability SHOULD be determined to exist if, for example, a Product deletes user data after a number of failed login attempts or only boots with known good components, and such defenses can be reduced or bypassed. 312 | 313 | 4.1.5.2 Physical theft, damage, or destruction are not by themselves cybersecurity Vulnerabilities. CNAs SHOULD NOT determine physical access to a processor, memory, bus, or other hardware component to be a cybersecurity Vulnerability. 314 | 315 | 4.1.6 Brute-force denial-of-service and brute-force resource exhaustion attacks, for example, high-rate or high-bandwidth denial-of-service attacks or jamming radio frequency spectrum, SHOULD NOT be determined to be Vulnerabilities. Failure to implement common defenses against such attacks MAY be determined to be a Vulnerability (for example, an instance of [CWE-770](https://cwe.mitre.org/data/definitions/770.html)). 316 | 317 | 4.1.7 Detection bypass attacks SHOULD NOT be determined to be Vulnerabilities unless, for example, a Product explicitly claims to detect a specific pattern and fails to do so. 318 | 319 | 4.1.8 General purpose deliberately malicious code MUST NOT be determined to be a Vulnerability. 320 | 321 | 4.1.9 Products that have been modified to become malicious, for example, trojan horses, backdoors, or similar supply chain compromises, MAY be determined to be a Vulnerability. 322 | 323 | 4.1.10 To help determine whether separate Vulnerabilities exist, CNAs SHOULD consider whether the Vulnerabilities are [Independently Fixable](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryIndependentlyFixable). 324 | 325 | 4.1.11 Interdependent conditions that cause a Vulnerability SHOULD be determined to be one Vulnerability. For example, if a buffer overflow occurs only when an integer overflow occurs, CNAs SHOULD determine these two conditions to be one Vulnerability. 326 | 327 | 4.1.12 The act of updating Product dependencies MUST NOT be determined to be a Vulnerability, regardless of whether the dependencies have Vulnerabilities. For example, updating a library to address a Vulnerability in that library MUST NOT be determined to be a new Vulnerability in a Product that uses the library, and a Vulnerability advisory for the Product SHOULD reference the CVE ID for the Vulnerability in the library. See 4.2.14. 328 | 329 | 4.1.13 The state of a Product being EOL, by itself, MUST NOT be determined to be a Vulnerability. 330 | 331 | 4.1.14 Sociotechnical and other changes over time MAY be determined to be new Vulnerabilities or types of Vulnerabilities. Examples include advancements in computing power that make existing cryptographic algorithms insecure (such as [CVE-2004-2761](https://www.cve.org/CVERecord?id=CVE-2004-2761), [CVE-2020-5229](https://www.cve.org/CVERecord?id=CVE-2020-5229), instances of [CWE-328](https://cwe.mitre.org/data/definitions/328.html)) and changes in attitudes about the use of plain-text protocols (such as [CVE-2020-29380](https://www.cve.org/CVERecord?id=CVE-2020-29380), an instance of [CWE-319](https://cwe.mitre.org/data/definitions/319.html)). CNAs are expected to exercise judgment as described in [4.4](#44-cna-judgment). See also 4.2.8 and 4.4.4. 332 | 333 | 4.1.15 When useful or necessary to clarify Vulnerability determination decisions and CVE ID assignments, CNAs SHOULD explain relationships between CVE IDs and Fixes, Vulnerability determination decisions, and CVE ID assignment decisions. CNAs MAY explain these relationships using CVE Record descriptions and references. Note that CNAs are expected and required to exercise judgment ([4.4](#44-cna-judgment)), which is often necessary for complicated CVE ID assignments. 334 | 335 | ## 4.2 CVE ID Assignment 336 | 337 | After determining that one or more Vulnerabilities exist, CNAs should follow the guidance in this section to assign CVE IDs. 338 | 339 | 4.2.1 First Refusal 340 | 341 | CVE ID assignment follows a “right of first refusal” model. 342 | 343 | 4.2.1.1 The CNA with the most appropriate scope MUST be contacted and given the first opportunity to assign. In many cases, this CNA is the Supplier of the Product in question. 344 | 345 | 4.2.1.2 For Publicly Disclosed Vulnerabilities, if the CNA with the most appropriate scope: 346 | 347 | 1. preemptively documents that it will not assign, or 348 | 2. responds within 72 hours that it will not assign, or 349 | 3. does not respond within 72 hours, 350 | 351 | then an appropriate Root MUST make a Vulnerability determination. If the Root determines that one or more Vulnerabilities exist, the Root MUST direct a CNA-LR or another CNA with appropriate scope to assign as quickly as possible and no later than 72 hours after becoming aware of the first refusal. Ownership of the CVE Record MAY be transferred. 352 | 353 | 4.2.1.3 For Vulnerabilities that are not yet Publicly Disclosed, if the CNA with the most appropriate scope decides not to assign, the party requesting assignment MUST follow the dispute resolution guidance in [4.6](#46-dispute-resolution). 354 | 355 | 4.2.2 Primary Assignment 356 | 357 | 4.2.2.1 CNAs SHOULD assign a CVE ID if: 358 | 359 | 1. the CNA has reasonable evidence to determine the existence of a Vulnerability ([4.1](#41-vulnerability-determination)), and 360 | 2. the Vulnerability has been or is expected to be Publicly Disclosed, and 361 | 3. the CNA has appropriate scope ([3.1](#31-cna-scope-definition)). 362 | 363 | 4.2.2.2 CNAs SHOULD Publicly Disclose and assign a CVE ID if the Vulnerability: 364 | 365 | 1. has the potential to cause significant harm, or 366 | 2. requires action or risk assessment by parties other than the CNA or Supplier. 367 | 368 | 4.2.2.3 CNAs MAY Publicly Disclose Vulnerabilities for other reasons. 369 | 370 | 4.2.3 CNAs MUST NOT consider the type of technology (e.g., cloud, on-premises, artificial intelligence, machine learning) as the sole basis for determining assignment. 371 | 372 | 4.2.4 If a CNA assigns a CVE ID, the Vulnerability MUST be Publicly Disclosed by the CNA or another party, or the CNA MUST reject the CVE ID. 373 | 374 | 4.2.5 CNAs MUST NOT assign CVE IDs for Vulnerabilities the CNA does not intend to Publicly Disclose unless the Vulnerabilities are already or are expected to be Publicly Disclosed. 375 | 376 | 4.2.6 CNAs SHOULD assign different CVE IDs to separate Vulnerabilities, as determined using the guidance in [4.1](#41-vulnerability-determination). 377 | 378 | 4.2.7 CNAs SHOULD assign CVE IDs to Vulnerabilities, not Fixes for Vulnerabilities. CNAs SHOULD assign CVE IDs whether or not a Fix is available. 379 | 380 | 4.2.8 CNAs MAY determine that residual insecurity left by an incomplete Fix is a new Vulnerability and MAY assign a new CVE ID or MAY use an existing CVE ID. 381 | 382 | 4.2.9 When useful or necessary to clarify CVE ID assignments, CNAs SHOULD follow the guidance in 4.1.15. 383 | 384 | 4.2.10 CNAs SHOULD NOT assign CVE IDs to Vulnerabilities in Products that are not and were never publicly available. 385 | 386 | 4.2.11 CNAs SHOULD assign different CVE IDs to different, Independently Fixable Vulnerabilities. 387 | 388 | 4.2.12 If a CNA is uncertain whether two issues are Independently Fixable, then the CNA SHOULD assign a single CVE ID. 389 | 390 | 4.2.13 If multiple Products are affected by the same Independently Fixable Vulnerability, then the CNA: 391 | 392 | 1. MUST NOT assign more than one CVE ID if the Products are vulnerable because they share the vulnerable code. The assigned CVE ID will be shared by the vulnerable Products. 393 | 2. SHOULD assign different CVE IDs if the Products do not share vulnerable code. 394 | 3. SHOULD assign different CVE IDs if the CNA is uncertain whether the Products share vulnerable code. 395 | 396 | 4.2.14 If a Product is affected by a Vulnerability because it uses the functionality or specification of another Product, then a CNA: 397 | 398 | 1. MUST assign a CVE ID to each known vulnerable implementation if there is a secure way of using the functionality or specification. 399 | 2. MUST assign a single CVE ID if there is no option to use the functionality or specification in a secure way. 400 | 3. SHOULD assign different CVE IDs to each known vulnerable implementation if the CNA is uncertain whether there is a secure way. 401 | 402 | 4.2.15 CNAs MUST NOT assign a different CVE ID to a Vulnerability that is fully interdependent with another Vulnerability. The Vulnerabilities are effectively the same single Vulnerability and MUST have one CVE ID. 403 | 404 | 4.2.16 Multiple CNAs With Overlapping Scopes 405 | 406 | CNAs are constrained to assigning CVE IDs to Vulnerabilities within their Scope Definitions. Sometimes, Scope Definitions overlap. Examples include research CNAs who discover the same Vulnerability at the same time and Supplier CNAs whose Products use the same vulnerable library and may be involved in a multi-party coordinated Vulnerability disclosure process. In cases like these, the rules below clarify which CNA assigns the CVE ID. Scope Definition is discussed in [3.1](#31-cna-scope-definition). 407 | 408 | 4.2.16.1 CNAs MUST NOT assign CVE IDs to Vulnerabilities outside of their scope. 409 | 410 | 4.2.16.2 CNAs SHOULD assign CVE IDs within their scope. 411 | 412 | 4.2.16.3 If a Vulnerability that has not yet been Publicly Disclosed falls within the scope of multiple CNAs, then the CNAs who are aware of the Vulnerability SHOULD work together to assign CVE IDs. 413 | 414 | 4.2.16.4 If multiple CNAs with overlapping scopes are coordinating the Public Disclosure of a Vulnerability, those CNAs SHOULD work together to assign CVE IDs. 415 | 416 | 4.2.16.5 If a Vulnerability falls within the scope of multiple CNAs, and the CNAs cannot resolve the assignment decision themselves, the decision about which CNA assigns the ID MUST be made by the lowest level organization (Root, TL-Root, Council of Roots) that is shared by the CNAs. 417 | 418 | 4.2.16.6 If a Supplier CNA becomes aware of a Vulnerability in an upstream dependency used by the Supplier CNA, they MUST notify and defer first-refusal CVE ID assignment to the upstream Supplier of the dependency, if the upstream Supplier is a CNA. 419 | 420 | 4.2.17 End-of Life (EOL) Products 421 | 422 | 4.2.17.1 CNAs SHOULD assign CVE IDs for EOL Products that no longer receive Fixes. CNAs MUST tag CVE Records that only cover Products that no longer receive Fixes as "[unsupported-when-assigned](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryTags)." See also 5.1.11. 423 | 424 | 4.2.17.2 TL-Roots MAY define CVE ID assignment process for EOL Products within the TL-Root’s hierarchy. Such processes MUST NOT conflict with the CNA Operational Rules and the [End of Life Vulnerability Assignment Process](https://www.cve.org/Resources/General/End-of-Life-EOL-Assignment-Process.pdf) unless the CVE Board approves an exception. 425 | 426 | 4.2.17.3 CNAs MUST follow their TL-Root’s documented process. If one does not exist, CNAs MUST follow the guidance in the End of Life Vulnerability Assignment Process. 427 | 428 | 4.2.17.4 Subject to TL-Root EOL processes and the End of Life Vulnerability Assignment Process, if a CNA specifies that it does not assign CVE IDs for Vulnerabilities in EOL Products, then other CNAs with appropriate scope MAY assign. To minimize duplicate assignments for Publicly Disclosed Vulnerabilities, CNAs SHOULD defer assignment to Roots and Roots SHOULD direct CNA-LRs to assign. See also 4.2.1. 429 | 430 | 4.2.17.5 CNAs SHOULD publicly document how they assign CVE ID for EOL Products. CNAs MAY do this in their Scope Definition (see 3.1.11). 431 | 432 | 4.2.17.6 If a CNA does not publicly document how they assign CVE IDs for EOL Products, then it should be assumed that the CNA will handle assignment similarly for EOL Products and non-EOL Products. 433 | 434 | 4.2.17.7 CNAs MUST NOT assign CVE IDs for the sole reason that a Product is or has become EOL. See 4.1.13. 435 | 436 | 4.2.17.8 If a CNA assigns a CVE ID for a Vulnerability in a supported Product or version, and the same Vulnerability exists in an EOL Product or version, CNAs MUST NOT assign a separate CVE ID for the same Vulnerability in the EOL Product or version. Similar to 4.2.15, there is only one Vulnerability which MUST have one CVE ID. 437 | 438 | 4.2.18 CNAs MUST NOT assign CVE IDs for Vulnerabilities that have been deliberately implemented for educational and research purposes, for example, in Products such as OWASP WebGoat. 439 | 440 | 4.2.19 As part of handling CVE ID assignment requests, CNAs SHOULD ask requesters if they have already requested an assignment from another CNA with appropriate scope. If so, the CNA SHOULD defer assignment to the initial CNA, refer the requester back to the initial CNA, or otherwise coordinate with the initial CNA. 441 | 442 | 4.2.20 To help minimize duplicate assignments, CNAs SHOULD consider coordinating with an appropriate Root or CNA-LR before assigning CVE IDs for Publicly Disclosed Vulnerabilities. See 4.2.1.2 for more specific guidance. 443 | 444 | 4.2.21 CNAs SHOULD assign the year part of a CVE ID based on the calendar year in which the vulnerability was first Publicly Disclosed, the CVE Record was first published, or the CVE ID was reserved for the vulnerability in question. CNAs MUST NOT, based on this rule, change CVE IDs that have already been published. CNAs MAY assign CVE IDs in one calendar year and publish the corresponding CVE Record in the next calendar year. 445 | 446 | ### 4.3 Notification 447 | 448 | 4.3.1 When a CNA becomes aware of a non-public Vulnerability report, CVE ID request, or CVE ID assignment that is only covered by the Scope Definition of a different CNA, the first CNA SHOULD either refer the reporter or requester to or attempt to notify the appropriate CNA. 449 | 450 | 4.3.2 If a CNA is considering an assignment, and the CNA is not the Supplier of the vulnerable Product, then the CNA SHOULD make a reasonable and good faith effort to notify the Supplier. For example, if an operating system Supplier discovers a Vulnerability in a library from an upstream Supplier, in addition to assigning the CVE ID to the upstream Vulnerability, the operating system Supplier SHOULD attempt to notify the upstream library Supplier. This reduces duplicate CVE ID assignments and helps alert others that may be affected by the Vulnerability. 451 | 452 | 4.3.3 When a Vulnerability is reported to a CNA and the CNA assigns a CVE ID to the Vulnerability, the CNA MUST provide the CVE ID to the reporter. 453 | 454 | ### 4.4 CNA Judgment 455 | 456 | Within the context of these rules, CNAs are expected to exercise discretion and judgment, especially when making complicated Vulnerability determination ([4.1](#41-vulnerability-determination)) and CVE ID assignment ([4.2](#42-cve-id-assignment)) decisions. Specific examples include: 457 | 458 | * Sufficient and reasonable evidence of Vulnerability 459 | * Vulnerability abstraction, including the interpretation of Independently Fixable 460 | * Number of Vulnerabilities and CVE ID assignments 461 | * Rejecting CVE IDs or making other abstraction or assignment changes 462 | * Violation of an explicit or implicit security policy or claim 463 | * Potential for a Vulnerability to cause significant harm 464 | * Requirement for action or risk assessment by parties other than the CNA 465 | * How to resolve disputes and when to escalate 466 | 467 | 4.4.1 Disagreements with a CNA's decision or judgment, including whether and how to assign CVE IDs, MUST follow the [CVE Program Policy and Procedure for Disputing a CVE Record](https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf). 468 | 469 | 4.4.2 CNAs SHOULD consult others (such as peer CNAs, CNA-LRs, Roots, and parties with knowledge of the Vulnerability) when making a decision involving significant or unusual judgment. 470 | 471 | 4.4.3 If, after a reasonable good faith effort, the CNA cannot make a clear decision, the CNA SHOULD err on the side of assignment and SHOULD assign CVE IDs. Doing so allows CVE users to identify and discuss the “Vulnerability-like” issue. 472 | 473 | 4.4.4 If consensus around a “Vulnerability-like” issue develops, the CVE Program MUST consider whether and how to update these rules and other guidance. 474 | 475 | ### 4.5 CVE Record Management 476 | 477 | This section specifies actions related to publishing and managing CVE Records. 478 | 479 | 4.5.1 Publishing CVE Records 480 | 481 | 4.5.1.1 CNAs MUST provide CVE Record content that meets the requirements listed in section 5. 482 | 483 | 4.5.1.2 CNAs MUST publish CVE Records to the [CVE List](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCVEList) through the process designated by the CVE Program. 484 | 485 | 4.5.1.3 CNAs SHOULD publish a CVE Record to the CVE List within 24 hours of Publicly Disclosing a CVE ID assigned by the CNA. CNAs MAY publish or update CVE Records as part of the CNA’s processes to manage Vulnerability advisories or other public information that references the CVE ID. 486 | 487 | 4.5.1.4 CNAs MUST publish a CVE Record to the CVE List within 72 hours of Publicly Disclosing a CVE ID assigned by the CNA. If the CNA does not publish within 72 hours, then the CNA’s Root MAY direct the appropriate CNA-LR to publish a CVE Record for the assigned CVE ID. Ownership of the CVE Record MAY be transferred. See also 4.2.1.2. 488 | 489 | 4.5.1.5 In exigent circumstances, for Publicly Disclosed Vulnerabilities, when a CNA with appropriate scope has not published a CVE Record, an appropriate TL-Root MAY direct an appropriate CNA-LR to publish a CVE Record. Ownership of the CVE Record SHOULD be transferred. 490 | 491 | 4.5.1.6 CNAs SHOULD publish CVE Records within 72 hours of becoming aware that a CVE ID assigned by the CNA has been Publicly Disclosed by a party other than the CNA. 492 | 493 | 4.5.1.7 The Secretariat MAY publicly identify the CNA who reserved the CVE ID 24 hours after a CVE ID has been Publicly Disclosed. Otherwise, the Secretariat SHOULD NOT publicly identify the CNA until the CVE Record has been published. 494 | 495 | 4.5.2 Publishing Vulnerability Information 496 | 497 | 4.5.2.1 CNAs SHOULD publish Vulnerability advisories or other information about Vulnerabilities for which the CNA has assigned CVE IDs and published CVE Records. Such information SHOULD meet the public references requirements in [5.3](#53-public-references) and MAY be used as a public reference (see 5.3.1.1). 498 | 499 | 4.5.2.2 Supplier CNAs MUST have at least one distribution point, such as a web site, where the CNA publishes Vulnerability advisories or other information about Vulnerabilities for which the CNA has assigned CVE IDs and published CVE Records. This Vulnerability information MUST reference appropriate CVE IDs. 500 | 501 | 4.5.2.3 The Vulnerability information described in 4.5.2.1 MUST generally support and MUST NOT contradict information published by the CNA in corresponding CVE Records. 502 | 503 | 4.5.2.4 The distribution point and Vulnerability information MUST be publicly accessible, MUST NOT require registration or login, and MUST NOT impose terms of use that restrict general-purpose use of the information or contradict the CVE Program [Terms of Use](https://www.cve.org/Legal/TermsOfUse). 504 | 505 | 4.5.2.5 CNAs MAY provide additional information under more restrictive terms of use or access controls. 506 | 507 | 4.5.2.6 CNAs SHOULD consider the long-term availability of Vulnerability information, especially when used as public references in CVE Records. CNAs SHOULD maintain URL availability through techniques such as URL redirects or by submitting references to archival services such as the [Internet Archive](https://archive.org/) or other mechanisms determined by the CVE Program. 508 | 509 | 4.5.2.7 Supplier CNAs MUST inform the Secretariat about the CNA’s distribution point(s). This information will be published in the List of Partners. 510 | 511 | 4.5.3 Changes to CVE Records 512 | 513 | As new information becomes available, CNAs can make changes to the content of published CVE Records and the number of CVE IDs assigned to one or more Vulnerabilities. 514 | 515 | 4.5.3.1 CNAs SHOULD update published CVE Records when information material to the Record changes, for example, when a Fix becomes available. 516 | 517 | 4.5.3.2 CNAs SHOULD update materially incorrect information in published or rejected CVE Records. 518 | 519 | 4.5.3.3 CNAs MAY update published CVE Records and SHOULD consider the cost of updates, the age of the CVE Record, and the value of the new information. 520 | 521 | 4.5.3.4 In exigent circumstances, when the CNA has not updated the CVE Record with a critical change or correction, and at the discretion of an appropriate TL-Root, the TL-Root MAY request that the Secretariat update the CVE Record. 522 | 523 | 4.5.3.5 CNAs MUST reject unused or unpublished CVE IDs. 524 | 525 | 4.5.3.6 CNAs MAY reject published CVE Records. Common reasons to do so include determining that no Vulnerability exists, using an incorrect CVE ID, duplicate assignment, or the combination or merging of multiple CVE IDs. 526 | 527 | 4.5.3.7 When deciding to reject a published CVE Record, CNAs MUST use the formats and mechanisms specified by the CVE Program and MUST provide an explanation. 528 | 529 | 4.5.3.8 CNAs MAY combine or merge CVE ID assignments. CNAs MUST reject published CVE IDs and CVE Records that become redundant after the change. When deciding which CVE IDs and CVE Records to reject, CNAs SHOULD consider factors such as the time of publication and the extent of public use and awareness. 530 | 531 | 4.5.3.9 CNAs MAY separate or split CVE ID assignments, assigning new CVE IDs and publishing corresponding CVE Records as necessary. 532 | 533 | 4.5.3.10 When marking a published CVE Record as disputed, CNAs and the Secretariat MUST use the formats and mechanisms specified by the CVE Program, MUST use the "disputed" tag, and MUST provide an explanation in the CVE Record. See also 5.1.11. 534 | 535 | 4.5.3.11 CVE Program members MUST indicate “disputed” status and present the explanation when rendering and displaying CVE Record data. 536 | 537 | 4.5.4 CVE ID Ownership and Transfers 538 | 539 | 4.5.4.1 The ownership of a CVE ID and the corresponding CVE Record SHOULD NOT be transferred except in specific circumstances, primarily related to issues with scope or delays in assignment or publication, as determined by the appropriate Root. For example, if a CNA assigns a CVE ID and publishes a corresponding CVE Record, and at the time of assignment a different CNA had more appropriate scope, then the appropriate Root SHOULD transfer ownership of the CVE ID to the CNA with more appropriate scope. 540 | 541 | 4.5.5 CVE Record Formatting and Interfaces 542 | 543 | 4.5.5.1 CNAs MUST submit CVE Records in the formats and through the mechanisms specified by the CVE Program. 544 | 545 | 4.5.5.2 The CVE Program MUST provide a non-production environment and reasonable time periods during which CNAs can test changes to formats and mechanisms. 546 | 547 | 4.5.5.3 CNAs MUST handle changes to formats and mechanisms within test periods. 548 | 549 | ### 4.6 Dispute Resolution 550 | 551 | It is expected that there will be disagreement about Vulnerability determination, CVE ID assignment decisions, and the content of CVE Records. 552 | 553 | 4.6.1 CNAs or other parties who disagree with a Vulnerability determination, CVE ID assignment, or the content of a CVE Record MAY dispute the determination, assignment, or content. 554 | 555 | 4.6.2 CNAs SHOULD work with relevant parties to attempt to resolve disputes before initiating the [CVE Program Policy and Procedure for Disputing a CVE Record](https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf). 556 | 557 | 4.6.3 Disputes MUST follow the process described in CVE Program Policy and Procedure for Disputing a CVE Record. 558 | 559 | ## 5 CVE Record Content 560 | 561 | This section specifies what information is in a CVE Record. 562 | 563 | ### 5.1 Required CVE Record Content 564 | 565 | This section defines the minimum content required in a CVE Record. A CVE Record: 566 | 567 | 5.1.1 SHOULD contain sufficient information to uniquely identify the Vulnerability and distinguish it from similar Vulnerabilities. 568 | 569 | 5.1.2 SHOULD identify the vulnerable Products, versions, dates, components, sub-components, features, modules, APIs, functions, function calls, commands, utilities, or programs, to the degree necessary to uniquely identify the Vulnerability. 570 | 571 | 5.1.3 MUST identify at least one affected Product using information such as Supplier and Product names, versions, and dates. 572 | 573 | 5.1.4 MUST identify at least one Product as “affected” or “unknown” (with the possibility of being affected). 574 | 575 | 5.1.5 SHOULD identify Fixed versions of Products. 576 | 577 | 5.1.6 SHOULD resolve “Unknown” status (to “affected” or “unaffected”) within a reasonable timeframe. A permanent “Unknown” status MAY be appropriate if, for example, a Product is suspected of being affected but has not been investigated. 578 | 579 | 5.1.7 MUST identify the type of Vulnerability. The CVE record SHOULD use the [Common Weakness Enumeration](https://cwe.mitre.org/) (CWE) to classify the type or cause of the Vulnerability. A CVE Record MAY contain multiple types or causes of the Vulnerability. 580 | 581 | 5.1.8 MUST NOT only contain Products with “unaffected” status. This would not be a Vulnerability. 582 | 583 | 5.1.9 MUST contain a prose description (see [5.2](#52-description)). 584 | 585 | 5.1.10 MUST contain at least one public reference (see [5.3](#53-public-references)) that MUST NOT be a reference to the CVE Record itself. 586 | 587 | 5.1.11 MUST include the appropriate and approved [CNA tag(s)](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryTags), if applicable. CVE Program members SHOULD present the information provided by tags, including relevant explanations, when rendering and displaying CVE Record data. 588 | 589 | 5.1.11.1 MUST use the "exclusively-hosted-service" tag when all known Products listed in the CVE Record exist only as fully hosted services. If the Vulnerability affects both hosted services and on-premises Products, then this tag MUST NOT be used. 590 | 591 | 5.1.12 MUST meet any requirements set by any approved formats or submission mechanisms, for example, the CVE Record Format and the Record Submission and Upload Service (RSUS). Such requirements will be integrated into this document on a periodic basis. 592 | 593 | 5.1.13 MAY contain optional elements supported by the CVE Record Format. 594 | 595 | ### 5.2 Description 596 | 597 | Through automation efforts such as the CVE Record Format and CVE Services, the content of the prose description in a CVE record is becoming less important. The prose description is still useful in providing sufficient information to uniquely identify the Vulnerability and distinguish it from similar Vulnerabilities. The description: 598 | 599 | 5.2.1 MUST summarize the Vulnerability, using, for example, information from 5.1.1 through 5.1.7. 600 | 601 | 5.2.2 MUST include any information required by [5.1](#51-required-cve-record-content) that is not provided by a more specific part of the CVE Record Format. 602 | 603 | 5.2.3 MUST NOT contradict information provided elsewhere in the CVE Record. 604 | 605 | 5.2.4 MUST NOT credit people, organizations, or tools. CNAs MAY credit or acknowledge people, organizations, or tools in their own Vulnerability advisories or other information about Vulnerabilities or using the optional “credits” or “source” elements of the CVE Record Format. 606 | 607 | 5.2.5 MUST include one description in English and MAY include descriptions in other languages. 608 | 609 | 5.2.6 MUST NOT contain information that is not relevant to identifying and describing the Vulnerability, for example, inappropriate language or advertising. 610 | 611 | 5.2.7 SHOULD NOT only describe one CVE Record as being different than another CVE Record. Different CVE IDs MUST identify different Vulnerabilities. 612 | 613 | 5.2.8 MAY follow examples found in [Key Details Phrasing](https://www.cve.org/Resources/General/Key-Details-Phrasing.pdf). 614 | 615 | 5.2.9 MAY duplicate information provided elsewhere in the CVE Record. 616 | 617 | 5.2.10 MAY be automatically generated from elements of the CVE Record. 618 | 619 | 5.2.11 SHOULD NOT contain Vulnerability identifiers that are not CVE IDs unless the Vulnerability identifiers are necessary to specifically describe or identify the Vulnerability. CNAs MAY include Vulnerability IDs using public references or other elements of the CVE Record Format. 620 | 621 | ### 5.3 Public References 622 | 623 | Public references support the information contained in CVE Records. 624 | 625 | 5.3.1 CNAs MUST ensure that a public reference exists on the internet before or concurrently with the publication of the corresponding CVE Record. A CVE Record MUST NOT be the first Public Disclosure of a Vulnerability. 626 | 627 | 5.3.1.1 If a CNA publishes advisories or other information about Vulnerabilities as described in 4.5.2, that information SHOULD also meet the public references requirements in [5.3](#53-public-references) and MAY be used as a public reference (see 4.5.2.1). 628 | 629 | 5.3.1.2 If multiple public references exist, CNAs MUST include the most freely available public reference in the CVE Record. 630 | 631 | 5.3.2 CNAs SHOULD consider the long-term availability of public references, for example, by submitting references to archival services such as the [Internet Archive](https://archive.org/) or other mechanisms determined by the CVE Program. 632 | 633 | 5.3.3 A CVE Record MUST have at least one public reference that: 634 | 635 | 5.3.3.1 SHOULD NOT require registration or login. 636 | 637 | 5.3.3.2 SHOULD NOT impose terms of use or service that restrict general-purpose use of the information or contradict the CVE Program [Terms of Use](https://www.cve.org/Legal/TermsOfUse). 638 | 639 | 5.3.3.3 MUST contain information about the specific Vulnerability. 640 | 641 | 5.3.3.4 MUST provide the minimum information required to support the content of the CVE Record (see [5.1](#51-required-cve-record-content)). 642 | 643 | 5.3.3.5 MUST NOT be a reference to the CVE Record itself. 644 | 645 | ### 5.4 Example or Test CVE IDs 646 | 647 | 5.4.1 For example, documentation, and testing purposes, CVE Program participants SHOULD use CVE IDs with the prefix 'CVE-1900-' that otherwise conform to the current CVE ID specification. 648 | 649 | 5.4.2 CVE Program participants MUST treat CVE IDs and CVE Records using the 'CVE-1900-' prefix as test or example information and MUST NOT treat them as correct, live, or production information. The CVE Services do not support CVE IDs with this prefix. 650 | -------------------------------------------------------------------------------- /CVE_Board_Charter.md: -------------------------------------------------------------------------------- 1 | # CVE Board Charter 2 | 3 | | Status | Final | 4 | | ---: | :--- | 5 | | Version | 3.5.0 | 6 | | Approved | 2024-07-02 | 7 | | Effective | 2024-07-02 | 8 | 9 | ## Table of Contents 10 | 11 | 1. [Board Overview and Member Responsibilities](#1-board-overview-and-member-responsibilities) 12 | 13 | 1.1 [CVE Program Board Overview](#11-cve-program-board-overview) 14 | 15 | 1.2 [Board Member Categories](#12-board-member-categories) 16 | 17 | 1.3 [Board Member Types](#13-board-member-types) 18 | 19 | 1.4 [Minimum Board Member Responsibilities](#14-minimum-board-member-responsibilities) 20 | 21 | 1.5 [Organizational Voting Members and other considerations](#15-organizational-voting-members-and-other-considerations) 22 | 23 | 1.6 [CVE Program Terms of Use](#16-cve-program-terms-of-use) 24 | 25 | 1.7 [Board Member Compensation](#17-board-member-compensation) 26 | 27 | 1.8 [Size of the Board](#18-size-of-the-board) 28 | 29 | 2. [Board Membership and Operations](#2-board-membership-and-operations) 30 | 31 | 2.1 [Selection of Full Board Members](#21-selection-of-full-board-members) 32 | 33 | 2.2 [Selection of CNA Liaison Members](#22-selection-of-cna-liaison-members) 34 | 35 | 2.3 [Selection of Organizational Liaison Members](#23-selection-of-organizational-liaison-members) 36 | 37 | 2.4 [Membership Approval](#24-membership-approval) 38 | 39 | 2.5 [Resignation from the Board](#25-resignation-from-the-board) 40 | 41 | 2.6 [Change in Member’s Affiliation](#26-change-in-members-affiliation) 42 | 43 | 2.7 [Board Member Professional Conduct Guidance](#27-board-member-professional-conduct-guidance) 44 | 45 | 2.8 [Removing Full Board Members](#28-removing-full-board-members) 46 | 47 | 2.9 [CNA Liaison Removal or Resignation](#29-cna-liaison-removal-or-resignation) 48 | 49 | 2.10 [Organizational Liaison Removal or Resignation](#210-organizational-liaison-removal-or-resignation) 50 | 51 | 2.11 [Recognition of Former Members](#211-recognition-of-former-members) 52 | 53 | 2.12 [Term Limits](#212-term-limits) 54 | 55 | 2.13 [Voting Mechanics](#213-voting-mechanics) 56 | 57 | 2.14 [Policy Document Changes](#214-policy-document-changes) 58 | 59 | 2.15 [Board Meetings](#215-board-meetings) 60 | 61 | 2.16 [Working Groups](#216-working-groups) 62 | 63 | 2.17 [Charter Exceptions](#217-charter-exceptions) 64 | 65 | 3. [Board Charter Review](#3-board-charter-review) 66 | 67 | 3.1 [Steps for Charter Review and Update](#31-steps-for-charter-review-and-update) 68 | 69 | ## 1 Board Overview and Member Responsibilities 70 | 71 | ### 1.1 CVE Program Board Overview 72 | 73 | The CVE Program Board is essential for ensuring CVE meets the vulnerability identification needs of the global cybersecurity and technology community. The Board’s primary responsibilities are to work with each other and the community to oversee the program, provide strategic direction, and advocate for the CVE Program. 74 | 75 | Board members represent numerous global cybersecurity-related organizations, including commercial security tool vendors, academia, research institutions, government departments and agencies, other prominent security experts, and end-users of vulnerability information. Through open and collaborative discussions, the Board provides critical input regarding the data sources, product coverage, coverage goals, operating structure, and the strategic direction of CVE. 76 | 77 | ### 1.2 Board Member Categories 78 | 79 | Board members are not limited to, but traditionally fit into one or more of the following categories: 80 | 81 | * Technical Implementers provide input and guidance regarding the creation, design, review, maintenance, and application of CVE List records (CVE Records). This may include individuals who integrate CVE Records into products, such as content and development engineers working for product vendors, and others who consume CVE Records. 82 | * Subject Matter Experts (SMEs) represent a significant constituency related to, or affected by, CVE, and are domain experts in the vulnerability management and reporting field. These members may include individuals from product vendors who represent the needs of their company, such as Product Security Incident Response Team (PSIRT) members, or product managers and product strategists who represent customers. 83 | * Advocates actively support or promote CVE in a highly visible fashion. These individuals are respected leaders within the security community who help bring credibility to CVE and give it a wider reach outside of the security community. 84 | 85 | ### 1.3 Board Member Types 86 | 87 | #### 1.3.1 Full Members 88 | 89 | The CVE Board is primarily comprised of individuals, not the organization where they are currently employed. A full Board member’s change in employment or affiliations does not affect their membership on the Board, and they will remain a member of the Board, if they so choose. 90 | 91 | Full members of the Board have voting privileges and are not subject to term limits. 92 | 93 | #### 1.3.2 CNA Liaison 94 | 95 | A single seat on the Board is reserved for a CNA Liaison who represents the CNA community, and ensures CNAs are updated with various status and activity-related information. The liaison is a voting member of the Board, with a one-year term, and can serve more than one consecutive term if the CNA community desires. This position is a two-way conduit for CNAs to bring things to and from the Board in a more official and structured way. 96 | 97 | #### 1.3.3 Organizational Liaison 98 | 99 | An Organizational Liaison position allows for tighter partnerships with targeted organizations. This type of role provides the Board with greater flexibility for how external organizations work with the Board and CVE program governance. There can be one or more organization(s) designated to have a liaison relationship with the Board at any one time. Each Organization with a Liaison position will have a single seat on the Board reserved for the Organizational Liaison representing them. This allows the Board representation from specific organizations as needed. 100 | 101 | This is a term-limited seat that must be reconfirmed by the Secretariat when the term set expires. The default term, unless specified by the Board during the establishment of the organization’s liaison role, is one year. The Secretariat assures the Organization wishes to continue the Board relationship and that the designated individual is the proper person to fill the role for the organization for the upcoming term. The Organization’s liaison is a voting member of the Board and can serve more than one consecutive term if the Organization desires. This position is a two-way conduit for the Organization to bring things to and from the Board in an official and structured way. 102 | 103 | #### 1.3.4 Board Moderator / Secretariat 104 | 105 | The MITRE Corporation (MITRE) initially established the Board in 1999, and currently serves as the CVE Board Moderator and CVE Program Secretariat (a.k.a Secretariat). The Secretariat provides programmatic support to the Board and its Working Groups, to include: 106 | 107 | 1. Maintaining the structure of the Board through an approved Board Charter (Charter), management of Board mailing lists and Board meetings, to include meeting moderation, logistics of Board membership, and overseeing additional Board activities, such as voting and other coordinating logistics. 108 | 2. Intellectual Property (IP) Protection: As the support for the CVE Program, the Secretariat is responsible for protecting IP contributed and transferred to CVE, while ensuring CVE is publicly available and free for use in accordance with the CVE [Terms of Use](https://www.cve.org/Legal/TermsOfUse). 109 | 3. Other: The Secretariat also provides strategic, technical, and programmatic expertise to the Board and other CVE Program participants. 110 | 111 | #### 1.3.5 Emeritus Members 112 | 113 | Emeritus members are formerly active Board members who made significant contributions to CVE. The decision as to what are significant contributions is made via consensus of the Board. Emeritus members are non-voting members and may be consulted for their expertise. 114 | 115 | ### 1.4 Minimum Board Member Responsibilities 116 | 117 | The CVE Board has the reasonable expectation that all Board members are engaged and actively participate in the CVE Program. Board members are responsible for collaborating effectively with each other, and the community, relative to all aspects of CVE governance, operation, and future direction. 118 | 119 | Members’ primary responsibilities are to actively promote CVE goals and adoption and participate in decision-making processes through established Board mechanisms. Additional forms of participation include Board calls, Board email list discussions, Working Groups, Working Group list discussions, and Board votes. 120 | 121 | Board members are volunteers. Therefore, members do not have to participate in every Working Group or every list discussion. However, participation should be enough such that all Board members have confidence in each other that everyone is doing their part to drive the program forward in a positive direction. In this regard, should a Board member lose the confidence of a majority of other Board members, a removal action may be taken. Prior to this step, individual Board members may contact the member of concern directly or may choose to voice their concerns through the Secretariat, so that issues are effectively communicated to the member of concern, and an understanding of the situation is developed to arrive at a fair outcome. Whether done by individual Board members or the Secretariat, the entire Board will be briefed on the situation so that each Board member may form their own opinion about the member of concern. 122 | 123 | Voting is particularly important for the CVE Board because it is how the Board makes decisions about the strategic direction of the program, and how the program will be governed and operated. Therefore, Board members have a responsibility to participate by voting as often possible. Votes to abstain count toward participation and toward a quorum. Members may vote to abstain as they choose, and for any issue being voted on. 124 | 125 | ### 1.5 Organizational Voting Members and other considerations 126 | 127 | A single organization may have multiple full members on the CVE Board. In these cases, only a single vote is allowed from the organization for issues that require a Board vote. This prevents a single organization from having undue influence on the outcome of a vote. See section 2.10, Voting Mechanics, for more information. 128 | 129 | Mergers and acquisitions (M&A) may affect Board membership. If two or more organizations with members on the Board merge, the merged organizations are considered a single organization. Therefore, as a single organization with more than one Board member, only one of the Board members may vote unless an exception is granted by the Board (2.13 Charter Exceptions). 130 | 131 | Similar to M&A, when Board members change organizations and become employed or affiliated with an organization that has current Board membership, they must share their single vote with the other Board members represented by their organization once the change occurs. 132 | 133 | No Board member is allowed to nominate candidate Board members from the organization where they are currently employed or affiliated. 134 | 135 | ### 1.6 CVE Program Terms of Use 136 | 137 | The CVE Program Secretariat is responsible for protecting intellectual property (IP) contributed and transferred to CVE, while making sure IP is publicly available and free for use in accordance with the CVE [Terms of Use](https://www.cve.org/Legal/TermsOfUse). 138 | 139 | ### 1.7 Board Member Compensation 140 | 141 | Board members are not compensated by the CVE Program. 142 | 143 | ### 1.8 Size of the Board 144 | 145 | There is no cap on the number of members who may join the Board, though this practice may be revisited if the Board size increases to the point that it negatively impacts the ability of the Board to make decisions or act. It is up to the Board to determine when action must be taken to resize the Board. 146 | 147 | ## 2 Board Membership and Operations 148 | 149 | ### 2.1 Selection of Full Board Members 150 | 151 | Prospective full Board members (prospects) are those people, either at-large (i.e., independent), or representing an organization in industry, academia, or government, who have potential to add value to CVE. Prospects may be identified by anyone; however, a prospect must be nominated by a full Board member. 152 | 153 | #### 2.1.1 Full Board Member Prospect Evaluation 154 | 155 | The information required to effectively evaluate a prospect is collected by the nominating Board member, using the [Board Member nomination form (Word 32K)](https://www.cve.org/Resources/Roles/Board/General/Board-Nomination-Form.docx). Once completed, the form is distributed to all Board members, using the Board’s private mailing list. Either the nominating Board member or the Secretariat distributes the completed form. In cases when the Secretariat distributes the completed form, the Secretariat will identify the nominating Board member. 156 | 157 | Prospect information includes, but is not limited to, biographical information that details the prospect’s skills and experience in the security community and CVE specifically, and the prospect’s expected value to the CVE Program. The prospect should provide a narrative as to why they want to be a member of the Board. The statement should include their background with CVE and describe their potential value to the CVE Program. 158 | 159 | #### 2.1.2 Full Board Member Review and Vote 160 | 161 | When a new prospective full Board member is nominated, an interview is conducted during an agreed-to Board call. After the interview, the Secretariat establishes the start and end of the voting period in a posting to the private Board mailing list. Board members are provided at least two weeks to review and vote on a new Board member prospect. If a nominee does not gain approval, they may be re-nominated after a 12-month waiting period. 162 | 163 | ### 2.2 Selection of CNA Liaison Members 164 | 165 | This is an elected position which CVE Numbering Authorities (CNAs) vote on annually. The Secretariat conducts the yearly nomination and voting process with all coordination and communications done through the CNA Mailing list. The Board is notified of the voting results at the successful completion of the process. 166 | 167 | ### 2.3 Selection of Organizational Liaison Members 168 | 169 | The Board can authorize establishing a Liaison relationship with a specific organization if the Board deems the relationship beneficial to the CVE Program. Once approved through a Board vote, it is the organization’s responsibility to determine who the individual Organizational Liaison will be. The Board strongly suggests the selected individual have a cybersecurity background and be well versed in CVE and related efforts. 170 | 171 | ### 2.4 Membership Approval 172 | 173 | When a Board prospect is approved by the Board, elected as the CNA Liaison, or added as an Organizational Liaison, the Secretariat announces the new Board member using the public Board mailing list, on the CVE website, in the CVE Announce e-newsletter, and appropriate CVE social media outlets, such as X & Mastodon. The announcement will include the new member’s name, role (if appropriate), organization affiliation, and biographical information of interest to the Program. 174 | 175 | The new Board member is expected to immediately begin participating with the responsibilities of a CVE Board member. 176 | 177 | ### 2.5 Resignation from the Board 178 | 179 | Any Board member may resign at any time by giving notice in writing, such as by email, to the Secretariat. The Secretariat confirms with the Board member that the notice is legitimate. A resignation takes effect upon confirmation the notice is legitimate, or at a later time specified in the written notice. No formal acceptance of a resignation is necessary to make it effective. 180 | 181 | ### 2.6 Change in Member’s Affiliation 182 | 183 | In the event a full Board member or the CNA Liaison has a change in organizational affiliation, they must notify the Secretariat of the change. Once received, the Secretariat updates the CVE website to reflect the member’s change in affiliation. 184 | 185 | If an individual serving as an Organizational Liaison changes roles significantly or leaves the Organization, the Secretariat must contact the Organization to either appoint a new individual to represent them or reconfirm the existing liaison still represents the Organization appropriately. If a new Organizational Liaison is appointed, the Secretariat updates the CVE website to reflect the new Organizational Liaison. 186 | 187 | If a Board member’s parent organization does not want to be listed as affiliated with a Board member, the Secretariat will change the member’s affiliation to “Independent.” Organizational Liaisons must list the organization that they represent on the Board. 188 | 189 | ### 2.7 Board Member Professional Conduct Guidance 190 | 191 | All Board members must follow the [CVE Program Professional Code of Conduct](https://www.cve.org/ResourcesSupport/AllResources/ProfessionalCodeOfConduct). 192 | 193 | ### 2.8 Removing Full Board Members 194 | 195 | Full Board members are considered for removal if: 196 | 197 | The Board member does not respond to the annual poll from the Secretariat on whether they would like to continue to be a Board member. 198 | 199 | The Board member asks to be removed. 200 | 201 | * A current Board member nominates the member for forced removal, due to, e.g., lack of participation, lack of collegiality or professional conduct, or failure to follow Board conventions as established in this Charter. The process for forced removal is: 202 | * A Board member nominates the member for removal through the private Board mailing list, finds another member to second the nomination, and provides the reason to the Secretariat via email. 203 | * The Secretariat submits the removal nomination to the entire Board for deliberation and voting through the private Board mailing list. 204 | * Board members have two weeks to vote and will receive a reminder from the Secretariat one week into the voting period through the private Board mailing list. 205 | * For forced removal, at least half of the Board must cast a vote and two thirds of the votes cast must be in favor of the removal. 206 | 207 | ### 2.9 CNA Liaison Removal or Resignation 208 | 209 | In the event a CNA Liaison either resigns or is removed, the Secretariat will ask for nominations on the CNA mailing list. The Board selects a CNA Liaison from the nominated pool to finish out the term of the departed Liaison. The selected CNA Liaison cannot be an existing Board member. 210 | 211 | ### 2.10 Organizational Liaison Removal or Resignation 212 | 213 | In the event an Organizational Liaison either resigns or is removed, the Secretariat will ask the organization to identify another individual to finish out the term of the departed Liaison. 214 | 215 | In the event of serious personnel conflicts detrimental to the Board’s operations, the CVE Board must vote to replace the Liaison. If the vote passes, the Secretariat must ask the Organization to replace the designated individual. If the Organization refuses, the Board has the right to terminate the Liaison relationship. 216 | 217 | ### 2.11 Recognition of Former Members 218 | 219 | When Members leave the Board, they are recognized in one of two ways: 220 | 221 | * If the person qualifies for Emeritus status, then the member is identified as Emeritus. 222 | * If the person does not qualify for Emeritus status, then the Board member is identified as a former Contributing member. Board members identified as Contributing Members have none of the participation opportunities granted to an Emeritus member. 223 | 224 | The Secretariat is responsible for determining the initial recognition status of a departing Board member. The Secretariat informs the Board of the status. If there is disagreement on the Board with the recognition status being proposed, the Board can call for a vote to determine whether the departing Board member is to be listed as Emeritus or as a Contributing member. 225 | 226 | The Secretariat is responsible for updating the related CVE website pages to reflect the new status of the departed Board member. 227 | 228 | ### 2.12 Term Limits 229 | 230 | There are no term limits placed on Board service for full members, excluding the CNA Liaison and any Organizational Liaisons, who serve a specific time-limited term. There is no limit on the number of one-year terms a CNA Liaison may serve if they are re-elected by the CNA community each year. There is no limit on the number of terms an Organizational Liaison may serve if they are reconfirmed as the Organizational representative on their Organization’s specified term basis. 231 | 232 | ### 2.13 Voting Mechanics 233 | 234 | All voting occurs in one or two ways, on the Board’s private mailing list through a full Board vote, or as a snap vote on a Board call where there is a documented quorum. The one exception pertains to the CNA Liaison position which is voted on through the CNA mailing list. 235 | 236 | #### 2.13.1 Snap Votes 237 | 238 | Snap votes can be used for deciding consensus on Board calls but cannot be used for approving policy documentation initial approvals or subsequent updates. A required quorum is defined as ‘one more than half the membership of the Board must be on the call’. Unanimous consent is required for passage of a snap vote. 239 | 240 | #### 2.13.2 Full Board Votes 241 | 242 | Full Board votes occur on the CVE Board’s private mailing list. 243 | 244 | Board members cast a single vote per issue. Any organization with multiple Board members must coordinate and cast a single unified vote per issue, unless an exception applies (2.13 Charter Exceptions). In the event an organization with two or more Board members casts more than one vote, the votes will not be considered. Board members from the same organization are expected to coordinate among their organizational colleagues to determine who is authorized to cast the vote. 245 | 246 | Time frames for full Board votes to cast a vote may vary as circumstances require, but generally must be at least one-week long. Two weeks is the recommended time frame for most votes but is not required. The Board may determine that unique and urgent circumstances require a voting time frame of less than one-week. This determination can be made if a majority of Board members agree. In such cases, the Secretariat will document the unique circumstances and tally the votes for and against reducing the standard voting time frame. 247 | 248 | Unless otherwise indicated in this Charter or by the Secretariat prior to a specific vote, a simple majority is needed to either accept or reject the item or issue being voted on. Votes from at least a simple majority of the eligible Board members are required for the overall vote to be declared valid. Board members may not change their votes once cast. Board members are encouraged to take as much time as necessary, within the prescribed voting time frame, to consider the issue being voted on prior to casting their vote. Once a majority decision is reached, the Board will direct the implementation of the results of the vote, even if the voting time frame has not concluded. However, the Secretariat will continue to accept votes from eligible Board members until the prescribed voting time frame has expired. Voting is a core responsibility of Board members. Votes will be accepted throughout the originally prescribed voting time frame so that Board members who were unable to vote prior to a majority being reached can still make their opinion known to the rest of the Board. 249 | 250 | In the case of a vote being declared invalid, or in the case of a tie, the Secretariat will send the issue back to the Board for further deliberation. 251 | 252 | #### 2.13.3 Proxy Voting 253 | 254 | Proxy voting is meant for short-term absences. In the event a voting Board member will be absent and unable to participate in a Board vote(s), that member is expected to coordinate with another member of the Board to cast a proxy vote on their behalf during the absence. Prior to the absence, the voting member must provide the following to the Board: 255 | 256 | * The anticipated time frame of his/her absence 257 | * The name of the Board member acting as the voting proxy 258 | 259 | At the time of voting, the proxy voting member must identify when they are voting for him/herself and when they are proxy voting for the absent member. When the absent member returns, they must notify the Board they will be voting on their own behalf going forward. 260 | 261 | If an organization has multiple voting members on the Board, and one or more members will be absent from a vote(s), the absent member(s) is expected to coordinate with and designate a proxy voter from their organization to cast the organization’s single vote. If all members from the same organization will be absent from a vote at the same time, the members are expected to coordinate with and designate a proxy voter from outside their organization to cast the organization’s single vote. In this case, each member must send a notification to the Board identifying the proxy member. 262 | 263 | The Secretariat is responsible for documenting the name of an absent Board voting member and the designated proxy voter on a per vote basis. 264 | 265 | ### 2.14 Policy Document Changes 266 | 267 | Policy documents are the foundation by which the CVE Program is run. Any modifications to these documents need to have transparent change control mechanisms and be approved by the CVE Board through a full Board vote. Examples of policy documents include the CVE Program Glossary, CVE CNA Rules, CVE Record Dispute Policy, EOL Assignment Policy, and the Inactive CNA Policy. While it is understood that additional policy documents are going to be developed, all documents recognized by the Board as a policy document cannot be changed and posted without a Board mailing list approval vote on the updates. 268 | 269 | ### 2.15 Board Meetings 270 | 271 | Board meetings are held periodically, with a goal of every two weeks or more frequently, as required. The Secretariat establishes the agenda for each meeting after obtaining input from the Board members. Board members are free to raise subjects during meetings that are not on the agenda for that particular meeting. The agenda, and any supporting documents, are provided to the Board members prior to each meeting, and should be reviewed in advance. Action items carried over or identified during the previous Board meeting should be included in the agenda sent to Board members. 272 | 273 | #### 2.15.1 Executive Sessions 274 | 275 | A Board meeting commonly allows Secretariat staff members and others to attend for the purpose of providing status or taking notes. However, there are times when the Board members want to have a private discussion, called an Executive Session, with only official Board members involved. Executive Sessions are needed when discussing sensitive Board topics such as deliberations surrounding nominations, member removals, departing Board member status, or other areas that need to have a bit more anonymity to them. By default, no Board notes are allowed in an Executive Session. If notes are needed, Board participants must agree before starting the conversations. No attribution as to who said what or held a specific point of view is allowed outside the Executive Session. A Board member can call for an Executive Session for any reason they deem appropriate. If called during a scheduled Board meeting, non-Board members are required to immediately disconnect from the call or virtual meeting or leave the room if sharing with an official Board member. Failure to do so will result in a permanent ban from future Board meetings. Board members can also request an Executive session be scheduled by the Secretariat to be run by the Secretariat’s Board representative. 276 | 277 | ### 2.16 Working Groups 278 | 279 | Working groups (WGs) are established and overseen by the Board. They are advisory in nature and intended to effectively address specific areas or issues of interest to the program. They are forums better suited for the detailed work necessary to achieve the objectives of the CVE Program. All WGs must have documented objectives and outcomes defined in their charter. 280 | 281 | Any Board member may recommend a new WG, and establishment of a WG requires an approval vote of the full Board. The WG charter indicates the participation model. If the charter does not restrict participation, then the WG is considered open to participation from the public at large. WGs should use Secretariat-supplied email facilities. 282 | 283 | WG progress must be reported back to the Board on an ad hoc, Board requested, or routine basis, either through the Board meetings, or through the Board email lists, as appropriate. Activities coming out of the WGs should be an extension of the Board activities. The WGs need Board approval before making changes or decisions that can either adversely or favorably affect CVE. The WG should notify the appropriate Board email list (public or private) whenever the WG requires this kind of change or decision. 284 | 285 | The WGs need to keep the Board apprised of what they are doing and decisions they are making. The WGs need to provide a report-out to the Board list, ensuring any WG decisions made are clearly identified as “recommendations” to the Board. The Board then has an opportunity, for a time frame specified in the report-out, to review the recommendations. If Board members have issues or questions, they are expected to ask for clarification and have the discussions needed to come to a consensus. In many cases, there may be no need for clarification or discussions. If no Board members respond within the specified time frame, acceptance of the change, decision, or the recommendation(s) is considered approved. Silence begets acceptance. 286 | 287 | #### 2.16.1 Disbanding or Pausing Working Groups 288 | 289 | When the purpose of a WG no longer exists, whether because it achieved its objectives or demonstrated that it cannot, it is either disbanded or paused. This is the case because CVE Program stakeholders are primarily volunteers, whose time is best spent working towards objectives that can realistically be achieved over a time frame. 290 | 291 | Disbanding a WG is a permanent decision that is made by the Board. 292 | 293 | Pausing a WG may be done because there are other activities that must be completed before a WG can reasonably be expected to accomplish its objectives. A pause is only initiated if, in the Board’s judgement, the WG cannot make progress toward objectives for at least six months until other activities are completed. The expectation is that the pause will end after the six-month time frame. If a WG is waiting on other activities to be completed and reasonably expects that to occur in fewer than six months, the WG chair(s) has the prerogative to adjust the WG meeting frequency until such related activities are complete. 294 | 295 | #### 2.16.2 Guidelines 296 | 297 | All WGs have a chair(s). At any time, a WG chair may report to the Board, in writing, that the WG has served its useful purpose and is either no longer necessary or should temporarily discontinue work until other, related activities are completed. For WGs that have co-chairs, both must agree prior to reporting to the Board that the WG served its useful purpose and should be disbanded or paused. Should co-chairs disagree, the reasons for and against disbanding or pausing the WG shall be communicated in writing to the Board. The chair is encouraged to communicate with all members of the WG prior to reporting to the Board to best ensure there is not more that can be done by the WG to achieve its objectives. The chair(s) is encouraged to undertake a vote within the WG as to whether the WG should be disbanded or paused. This facilitates better understanding by the chair(s) and the Board as to how strongly WG participants agree with the judgement that the WG be disbanded or paused. Should a pause be recommended, the chair(s) will identify in writing the related activities that must be completed prior to the resumption of the WG. 298 | 299 | The Board may at any time disband or pause a WG, for any reason, by majority vote of the Board. The Board will not conduct such a vote prior to discussing the reasons for disbanding or pausing the WG with the WG chair(s), and individual WG members (if necessary). In all cases, the Board makes the final determination to disband, pause, or continue a WG. Any result will be communicated to the chair(s) of the WG in a manner that best serves the interests of the CVE Program. 300 | 301 | Should a WG be disbanded, the Board may ask the WG to accomplish close-out activities to ensure knowledge capture within the program. Activities may include archiving WG work products and decisions, assigning related activities to other WGs, completing final tasking, and any other activity that maximizes the value of the WG to the CVE Program. The Board may ask the WG to undertake similar activities in the event of a pause. The Secretariat may assist the WG with close-out activities upon request of either the Board or WG chair(s). 302 | 303 | A disbanded WG may be reconstituted by the Board at any time, should circumstances dictate that course of action. However, disbanding a WG is undertaken with the expectation that the WG is no longer necessary and will not be reconstituted in the future. 304 | 305 | ### 2.17 Charter Exceptions 306 | 307 | In the event there is a needed or desired exception to the existing Board Charter, a Board member may bring the request for the exception up to the Board and request the Board vote on the requested exception. The request can be made either on the Board’s private mailing list or on a Board Member call. The Secretariat then conducts a vote on the proposed exception. This vote is handled using the regular Board voting process. If the vote passes, the exception is allowed. 308 | 309 | After the vote, the Board considers if the exception should be addressed and updated in the Board Charter. Not all exceptions need to be addressed in the Charter. 310 | 311 | ## 3 Board Charter Review 312 | 313 | The Board reviews the Charter when a significant change or issue is identified. If the Board determines that a revision is necessary, the updated language is incorporated into a draft for review by the Board. **Any change to the Charter requires a vote.** 314 | 315 | All email communications concerning CVE Board Charter changes occur on the **private** CVE Board list. 316 | 317 | ### 3.1 Steps for Charter Review and Update 318 | 319 | If a revision to the charter is called for, the following steps are taken: 320 | 321 | 1. The Charter may go through several revision/review cycles, based on the complexity of modifications needed. 322 | 2. When the revised Charter appears near final, the Secretariat issues a final call for edits/comments via email. The email includes the due date for final edits/comments (sent to the Secretariat). 323 | 3. Final edits are incorporated. 324 | 4. Several days prior to the tentative start date of the voting period, the Secretariat sends a message to the Board list that contains: 325 | * A clean copy of the proposed Charter for the Board to review 326 | * A notice indicating the clean copy is the proposed Charter update 327 | * A request for Board members to respond via email indicating whether they believe the proposed update is ready to be voted on 328 | * The tentative date the vote is proposed to begin and end 329 | 5. If the Board members indicate further Charter updates are necessary and provide reasonable justification, another revision cycle begins. In this case, the Secretariat sends a message to the Board indicating such. 330 | 6. If the majority of respondents believe the Charter is ready for a vote, the Secretariat sends a message to the Board list with the date the vote is scheduled to begin and end, and any special instructions, as needed. 331 | 7. On the day the vote begins, the Secretariat resends the updated Charter to the Board list, along with any special instructions, and request to vote. 332 | 8. Board members who vote against the Charter are expected to provide a reason(s) why they are doing so as a part of their vote. This allows other Board members to understand the reason and will assist in improving a future version of the Charter in the event it is voted down by the Board. 333 | 9. The Secretariat posts the results of the vote to the Board list. 334 | 10. If the Board votes down the new Charter, then it will be sent back to the Board for discussions and further revisions. 335 | 11. If the vote indicates the Board’s acceptance, the new Charter will immediately take effect and the Secretariat will update the related CVE website pages to reflect the new Charter. 336 | -------------------------------------------------------------------------------- /CVE_Dispute_Policy.md: -------------------------------------------------------------------------------- 1 | | Status | Final | 2 | | ---: | --- | 3 | | Version | 1.0 | 4 | | Adopted | 2022-09-22 | 5 | | Effective | 2022-09-22 | 6 | 7 | # CVE Program Policy and Procedure for Disputing a CVE Record 8 | 9 | This policy and procedure is enforced by [Roots](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryRoot), [Top-Level Roots (TLR)](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryTLRoot), and the Council of Roots (CoR). 10 | 11 | ## Definitions 12 | 13 | * **Disputes:** Disagreements with the accuracy or completeness of a [CVE Record](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryRecord), or the validity of a vulnerability upon which a CVE Record is based. 14 | 15 | * **Escalation:** The process by which disputes are evaluated and resolved. 16 | 17 | ## Policy 18 | 19 | It is the policy of the [CVE Program](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryProgram) that all disputes be initiated and escalated through the appropriate Root hierarchy, starting with the CVE Numbering Authority (CNA) within the hierarchy that owns the scope for which the record applies. Should any party in a dispute not accept the decision of the Root or TLR within a hierarchy, the CoR may decide to get involved and make the decision. All CoR decisions are final. 20 | 21 | CVE Records may be disputed for a variety of reasons by various stakeholders participating in the CVE Program. Examples include: 22 | 23 | * **Record accuracy:** A published CVE Record may contain information that a program stakeholder believes is inaccurate. For example, a [CNA of Last Resort (CNA-LR)](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCNALR) may publish a CVE Record to the [CVE List](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCVEList) based on a claim-based vulnerability report submitted by a third party (e.g., an independent researcher). In this example, the developer of the technology (i.e., a vendor or maintainer), may believe the technology is behaving as intended and no vulnerability exists. When both a claim-based vulnerability report and vendor or maintainer assertion of technology behavior are in conflict, and there is insufficient information to demonstrably prove one point of view over another, the CVE Record may be disputed by the technology vendor or maintainer. Third parties may also dispute a CVE Record if they can put forth a valid point of view. 24 | 25 | * **Incomplete information:** A Published CVE Record may lack sufficient information for the vulnerability to be re-created by a CVE Program stakeholder. In this case, the technology vendor, maintainer, or third party may dispute the CVE Record. 26 | 27 | * **Disputed upon CVE Record creation:** While infrequent, some CVE Records are created in disputed status. This occurs when the original reference for the record indicates that a bug exists, but there are differences of opinion about whether the bug is a vulnerability based on the CVE Program’s definition. The existence of a patch for a bug does not demonstrably prove that a vulnerability exists. In this case, a CNA-LR may assign a [CVE ID](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryCVEID) and publish a CVE Record with a DISPUTED tag. 28 | 29 | CNAs, Roots, and TLRs must have a publicly facing way for CVE Program stakeholders to initiate dispute and escalation processes. They must also include a URL to this policy or include this policy on their public-facing website so that CVE Program stakeholders understand that disputes can be made, and that a process exists for both initiating and escalating a dispute. 30 | 31 | CNAs, Roots, and TLRs may coordinate the dispute and escalation process, consistent with this policy, by whatever means work best for them. Dispute and escalation processes must be timely, effective, and based on the application of CVE Program rules. Each party in a dispute must document their rationale regarding a dispute. Such documentation must be in a common text format such as a text entry box in a web form, or a Markdown document. This is necessary to effectively orchestrate the dispute escalation procedure described below. The final arbiter of a dispute is the CoR, should the CoR decide to consider the dispute. CoR decisions are final and may not be appealed. This includes determining that the TLR decision is appropriate, and no further discussion is required. 32 | 33 | It is expected that very few disputes will require adjudication by the CoR. The CoR will determine what cases require its intervention. However, the CoR may not intervene until the escalation process is complete within a TLR hierarchy. Should the CoR decide not to intervene, the decision of the TLR will be final, with no recourse for appeal. Cases where the CoR chooses to intervene typically represent a set of uncommon circumstances. In these cases, the [CVE Board](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryBoard) must be informed so the circumstances driving the dispute can be considered in terms of potential enhancements to this policy or other program policies and rules. 34 | 35 | If the technology vendor or maintainer is a CNA, a CNA-LR must not assign a CVE ID and publish a CVE Record without first conferring with that CNA, to minimize cascades of disputes and maximize record quality. 36 | 37 | ## Procedure 38 | 39 | ![CVE Dispute Process Flowchart](assets/dispute_flowchart.png) 40 | 41 | 1. The party initiating the dispute must document their rationale for the dispute and submit the rationale to the CNA. The disputing party should provide evidence and rationale as a basis for the dispute (e.g., issue trackers, application security policy, findings). 42 | 43 | 2. The CNA will acknowledge receipt of the dispute, in writing, within three business days. 44 | 45 | 3. The CNA will review the rationale and engage the appropriate stakeholders, as necessary, to develop an understanding of the basis for the dispute. 46 | 47 | 4. The CNA will apply the CNA Operational Rules against the dispute rationale and will decide within five business days regarding the validity of the dispute. The five-day period will begin after the 72-hour receipt and acknowledgment period ends. Should the fiveday period be an inadequate span of time, the CNA will inform the parties in the dispute that more time is needed. Should any extension of time exceed 15 business days, the dispute may be escalated to the Root. In this case, the Root will confer with the CNA to determine an appropriate time frame. 48 | 49 | a) *Valid dispute:* The CNA will notify the parties of concern in writing of the decision and will modify the CVE Record. Should this be the outcome, provided the disputing party agrees with the modification, no escalation is required. The disputing party may escalate the issue should they disagree with the record modification. 50 | 51 | b) *Invalid dispute:* The CNA will notify the disputing party of the decision in writing, indicating that no record modification will be made. The disputing party may escalate the issue in this case. 52 | 53 | Should the escalation process be initiated, the Root, TLR, and CoR will follow the same procedure. Regardless of the outcome of a dispute, the Root, TLR, or CoR, will inform the parties in a dispute of the dispute escalation process. This can be done by pointing to this policy. 54 | 55 | In cases where the dispute is valid, but the CNA will not modify the CVE Record, the appropriate CNA-LR will tag the CVE Record with the DISPUTED tag and will provide the rationale for the validity of the dispute. This step will be taken after the dispute escalation process has run its course. 56 | -------------------------------------------------------------------------------- /CVE_EOL_Policy.md: -------------------------------------------------------------------------------- 1 | # CVE End of Life Vulnerability Assignment Process 2 | 3 | | Status | Final | 4 | | ---: | --- | 5 | | Version | 1.2.0 | 6 | | Approved | 2023-02-14 | 7 | | Effective | 2023-02-14 | 8 | 9 | ## Table of Contents 10 | 11 | 1. [Introduction](#1-introduction) 12 | 13 | 2. [Background](#2-background) 14 | 15 | 3. [Temporary CNA Rules Inconsistency](#3-temporary-cna-rules-inconsistency) 16 | 17 | 4. [CVE Program Principles](#4-cve-program-principles) 18 | 19 | 5. [CVE Program EOL Assignment Process](#5-cve-program-eol-assignment-process) 20 | 21 | 6. [EOL CVE ID Tagging](#6-eol-cve-id-tagging) 22 | 23 | 6.1 [Tagging Use and Considerations](#61-tagging-use-and-considerations) 24 | 25 | 6.2 [What an Unsupported When Assigned CVE Record Looks Like](#62-what-an-unsupported-when-assigned-cve-record-looks-like) 26 | 27 | 6.3 [JSON Schema unsupported-when-assigned Attribute Tag](#63-json-schema-unsupported-when-assigned-attribute-tag) 28 | 29 | 7. [Controlling the Messaging](#7-controlling-the-messaging) 30 | 31 | 8. [CVE Program EOL Process Benefits](#8-cve-program-eol-process-benefits) 32 | 33 | ## 1 Introduction 34 | 35 | The mission of the CVE Program is to identify and define publicly disclosed security vulnerabilities for consumption by the computing community. Significant debate has occurred within the CVE Program regarding whether [CVE Records](https://www.cve.org/ResourcesSupport/FAQs#pc_cve_recordswhat_is_cve_record) should be assigned for End-of-Life (EOL) products. This document is the result of those conversations. The purpose of this document is to establish a policy and detail a process by which the equities of all program participants can be aligned, consistent with the CVE Program’s mission. 36 | 37 | ## 2 Background 38 | 39 | A Vendor [CVE Numbering Authority (CNA)](https://www.cve.org/ProgramOrganization/CNAs) assigns [CVE IDs](https://www.cve.org/ResourcesSupport/FAQs#pc_cve_id_requestswhat_is_cve_id) and publishes CVE Records for products within their distinct, agreed upon program scope. Many Vendor CNAs treat CVE IDs as part of product vulnerability response and remediation processes, i.e., CVE IDs are assigned as product vulnerability fixes are published. Vendors do not typically produce fixes for products that they no longer support. Vendor CNAs may choose not to investigate or attempt to reproduce vulnerabilities reported in EOL products. Such an investigation may be cost-prohibitive, if not impossible. Vendor CNAs can declare that products listed in a CVE Record are EOL and take no further action. The CVE Program facilitates this declaration through the use of the CVE EOL tag and educational documentation on the [CVE website](https://www.cve.org/). 40 | 41 | There has been an ongoing, robust discussion within the CVE Program as to whether or not EOL products should be assigned CVE IDs. 42 | 43 | Vendor CNAs contend that it is unnecessarily costly for them to deal with vulnerability inquiries regarding EOL products, especially if it requires them to spin up teams to validate a reported vulnerability in an EOL product customers should not be running. The problem is, to verify that a vulnerability exists, the vendor would have to test and validate it. Many vendors do not see any value in spending time, effort and resources on a discontinued product that should be removed from operational use. Vendors would prefer customers upgrade to newer versions of the product which are supported, rather than continue using outdated and officially unsupported EOL products. 44 | 45 | Other CVE Program participants, however, believe vulnerabilities in EOL products should be assigned because the vulnerabilities exist and users of EOL products should have knowledge of how they are vulnerable, regardless of the efficacy of using EOL products. 46 | 47 | Since legitimate vulnerabilities are sometimes discovered in EOL products still being fielded, it is necessary for the CVE Program to have a documented and transparent process for dealing with these types of reported EOL vulnerabilities. 48 | 49 | While there has not been unanimous consensus among the [CVE Board](https://www.cve.org/ProgramOrganization/Board) members or the CNAs themselves, there was agreement that the mission of the CVE Program is to identify, catalog, and assign IDs to publicly known security vulnerabilities and that CVE IDs may be assigned for EOL product vulnerabilities that meet the requirements outlined in the CVE assignment rules (which are listed in the [CNA Rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules)). 50 | 51 | ## 3 Temporary CNA Rules Inconsistency 52 | 53 | The [CVE Rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules) v3.0, effective March 5, 2020, states: 54 | 55 | > A CNA should list in their scope whether they want to handle CVE assignments for end-of-life components according to the end-of-life rules or whether other CNAs should assume that responsibility if they have a need to reference such vulnerabilities. If a CNA specifies that it will not assign for end-of-life components, other CNAs may assign for those components. 56 | 57 | It should be noted that this is not required to be incorporated into the CNA’s scope statement at this time. 58 | 59 | The CNA Rules for EOL must be re-addressed, as the wording of the current rules conflict with the agreed to process for handling EOL vulnerability reports. Below is suggested wording to correct the existing shortcomings: 60 | 61 | > A CNA may list, in its scope, whether it does or does not want to handle CVE assignments for end-of-life components or products. If a CNA does not specify end-of-life handling in its scope, then all EOL vulnerabilities should be reported through the CNA’s official processes. If a CNA specifies that it will not assign for end-of-life components, then the documented applicable CVE EOL process should be followed. Top Level Roots (TLR) will define how the EOL process is to be used within their hierarchy. 62 | 63 | ## 4 CVE Program Principles 64 | 65 | The following is a list of fundamental principles that should be understood by all parties participating in the CVE Program, including CNAs, vulnerability reporters, and CVE consumers: 66 | 67 | * CVE IDs may be assigned for vulnerabilities in EOL products. 68 | * There are no expectations of vendors to either investigate or correct vulnerabilities reported in EOL products. 69 | * Vendor CNAs have the first “right-of-refusal” in issuing CVE IDs for their products, but cannot stop the assignment of a CVE ID if deemed appropriate by the program. 70 | * If a Vendor CNA does not assign, the CNA of Last Resort (CNA-LR) will work with both parties (Vendor CNA and the Reporter) to determine whether or not to assign a CVE ID to a vulnerability in an EOL product. 71 | * CVE IDs assigned for EOL products are to be tagged with a *Unsupported When Assigned* [tag](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_8_cve_record_requirements). 72 | 73 | ## 5 CVE Program EOL Assignment Process 74 | 75 | The following section documents the CVE Program’s Default EOL Assignment process. 76 | 77 | When a reporter believes they have found a vulnerability in an EOL product, they must follow the process below to have a CVE ID assigned to it: 78 | 79 | 1. The Reporter locates the appropriate CNA’s contact and scope information. 80 | 81 | CNA contact information can be found in the [List of Partners](https://www.cve.org/PartnerInformation/ListofPartners) section the CVE website. If the documented Vendor CNA scope states they are supporting EOL assignments, or does not specify, the Reporter must contact the appropriate Vendor CNA using the published official contact information. If the scope states the Vendor CNA does not support issuing CVE IDs for its EOL products, the Reporter will not need to contact the Vendor CNA and instead should contact the appropriate CNA-LR for the hierarchy. 82 | 83 | 2. Reporter contacts the Vendor 84 | 85 | CNA When the Reporter contacts the Vendor CNA regarding a vulnerability in an EOL product, the Reporter is required to provide some means of depicting how the issue was discovered and proof of the vulnerability’s existence to the Vendor CNA. It is up to the Vendor CNA to make the decision as to how to proceed. Depending on the product and circumstances, the Vendor CNA decides whether or not to assign a CVE ID for the discovered issue. If they do assign a CVE ID, the process is complete. 86 | 87 | 3. Vendor decides not to assign 88 | 89 | If the Vendor CNA decides not to assign a CVE ID, the Vendor CNA must notify the Reporter of their decision and provide a reason why the decision was made not to assign. In such cases where the Vendor CNA chooses not to assign CVE IDs and publish CVE Records for EOL products, the product falls out of the Vendor CNA’s scope for the purpose of CVE ID assignment and CVE Record publication. If the Reporter believes there is a need for this vulnerability to have a CVE ID assigned, the Reporter can then escalate the request to the CNA-LR to request the CVE ID. In these cases, the CNA-LR is empowered to assign and publish if deemed appropriate. 90 | 91 | 4. The Reporter escalates the issue to the CNA-LR at the same hierarchy level 92 | 93 | When the Reporter contacts the CNA-LR regarding a vulnerability in an EOL product, the Reporter is required to provide some means of depicting how the issue was discovered and proof of the vulnerability’s existence to the CNA-LR. 94 | 95 | 5. CNA-LR verifies the Reporter has contacted the Vendor CNA 96 | 97 | Before a CNA-LR can take up the issue, and providing the Vendor CNA’s scope does not preclude assigning for EOL products, the CNA-LR must verify the Reporter has contacted the Vendor CNA. If they have not, the CNA-LR instructs the Reporter to do so before the CNA-LR can proceed. The CNA-LR will request the email thread that included the Vendor CNA’s response and their reasons for declining the initial request for a CVE ID. 98 | 99 | 6. CNA-LR confirms the Vendor CNA is not going to assign 100 | 101 | If the Vendor CNA’s scope does not preclude assigning for EOL products, the CNA-LR must contact the Vendor CNA to ensure the CNA-LR has a true picture of the situation. Initial contacts must go through official channels; however, alternate contacts may be used if initial contacts prove unresponsive. The response must come from an authorized point of contact, through the CNA’s official channel. If the Vendor CNA has decided to assign a CVE ID, the CNA-LR will redirect the Reporter back to the Vendor CNA and the CNA-LR’s role is complete. If the CNA is not responsive in a reasonable timeframe, the CNA-LR should proceed with the process documented below. 102 | 103 | 7. Determining the validity 104 | 105 | If the CNA-LR confirms that the Vendor CNA is not going to assign, either by specified scope or by communication with the Vendor CNA, the CNA-LR needs to determine whether there is a valid reason a CVE ID should be assigned. There can be valid reasons for a CVE-ID not to be assigned. Before the decision can be made, the CNA-LR needs to obtain as much information about the issue as possible. The CNA-LR, as appropriate, needs to take both the Vendor CNA’s, and the Reporter’s reasoning into account and give each an opportunity to respond to the other’s reasoning. The CNA-LR will use the information supplied by both parties in determining if a CVE ID should be assigned for an unvalidated vulnerability. The CNA-LR will use the information supplied by both parties in making its decision. 106 | 107 | 8. The CNA-LR’s Assignment Decision 108 | 109 | The CNA-LR determines if there is a need for an assignment. The CNA-LR must apply the [assignment rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_7_assignment_rules). However, in these situations, 7.1.3 must not be used when determining whether the issue should be considered a vulnerability. If the CNA-LR determines there is a need for a CVE ID to be assigned, then the CNA-LR will assign the CVE ID, and publish the CVE Record with the appropriate information. The CVE Record must include the Unsupported When Assigned tag. 110 | 111 | 9. Vendor CNA Notification 112 | 113 | The CNA-LR will notify the Vendor CNA and the Reporter of what decision was made, why it was made, and what actions were taken based on the decision. 114 | 115 | ## 6 EOL CVE ID Tagging 116 | 117 | The *Unsupported When Assigned* tag (i.e., End-of-Life or EOL tag) is added to the description by the assigning CNA to indicate that when a request for a CVE ID was received, the product was already EOL. It indicates the CVE Record tagged with an EOL tag was requested and assigned after a product or specific product line was deemed not to be supported by the vendor. The vendor is under no obligation or responsibility to test, validate, or fix a vulnerability found in a product that is no longer supported by the vendor. For the CVE Program’s purposes, the EOL status for a product or version line is when it will no longer receive security fixes, regardless of what term the maintainer uses to designate this status. Users are encouraged to upgrade to a supported version (if there is one), replacing the product, or implement some other mitigation. 118 | 119 | ## 6.1 Tagging Use and Considerations 120 | 121 | While the Unsupported When Assigned tag describes the product ID (not the CVE ID), it is applied to the CVE ID due to the manner in which CVE ID assignments are made. The Unsupported When Assigned tag should only be applied to a CVE Record when all affected products or version lines referenced in the CVE ID are EOL. If some of the affected products or versions have reached EOL but others have not, then the tag must not be used. If the CVE Record has both non-EOL and EOL products, the maintainers are not required to list the EOL products in the CVE Record. 122 | 123 | CVE Records that existed prior to the product becoming EOL will not be marked with the Unsupported When Assigned tag when the product transitions to EOL. The purpose of the tag is to notify the community that a vulnerability report was received when the product was already EOL and the Vendor has no responsibility to validate or fix the reported issue. 124 | 125 | The data publisher (Vendor CNA or CNA-LR) must provide a reference to the CNA-specific EOL information, which typically informs customers how to upgrade to a currently supported product. 126 | 127 | Regardless of who assigns an EOL CVE ID, it is important to ensure the record is tagged appropriately. An EOL tag is included in the description which is beneficial for the downstream uses and consumers of CVE. Additionally, an EOL tag is indicated in the CVE Record tag attribute in order to facilitate filtering and metrics. 128 | 129 | ## 6.2 What an Unsupported When Assigned CVE Record Looks Like 130 | 131 | **UNSUPPORTED WHEN ASSIGNED** [VULN INFO HERE] NOTE: This vulnerability only affects products that are no longer supported by the maintainer. 132 | 133 | ## 6.3 JSON Schema unsupported-when-assigned Attribute Tag 134 | 135 | A “tags” property is a part of the CNA and ADP containers in the JSON schema. The value of this property will be an array of string values. The “unsupported-when-assigned” tag will be used when appropriate as documented above. 136 | 137 | For example: 138 | 139 | ```json 140 | { 141 | "data_format": "MITRE", 142 | "data_type": "CVE", 143 | "data_version": "5.0", 144 | "CVE_data_meta": { 145 | "ASSIGNER": "cve@mitre.org", 146 | "ID": "CVE-YYYY-NNNNN", 147 | "STATE": "PUBLIC", 148 | "DATE_ASSIGNED":"2019-01-01 23:45:00+0500", 149 | "DATE_PUBLIC":"2019-12-13 08:45:00+0500" 150 | }, 151 | "containers": { 152 | "CNA": { 153 | "provider_data_meta": { 154 | "ID": "cve@mitre.org", 155 | "UPDATED": "2019-01-01T23:45:00Z" 156 | }, 157 | "descriptions": [ 158 | { 159 | "lang": "EN", 160 | "value": "ACME Spy Be Gone 6.6 below have Incorrect Access Control." 161 | } 162 | ], 163 | "tags": [ "exclusively-hosted-service", "unsupported-when-assigned" ] 164 | }, 165 | "ADPs": [ 166 | { 167 | "provider_data_meta": { 168 | "ID": "user@example.com", 169 | "UPDATED": "2019-01-01T23:45:00Z" 170 | }, 171 | "description": [ 172 | { 173 | "lang": "FR", 174 | "value": "ACME Spy Be Gone 6.6 ci-dessous a un contrôle d'accès incorrect." 175 | } 176 | ], 177 | "tags": [ "other-tag-1" ] 178 | } 179 | ] 180 | ``` 181 | 182 | The unsupported-when-assigned tag is only allowed to be used in the CNA container. For EOL tagging, this ensures that the CNA making the CVE ID assignment and publishing the CVE Record is clearly identified. 183 | 184 | ## 7 Controlling the Messaging 185 | 186 | CNAs have expressed concern that the EOL process takes the assignment of certain vulnerabilities out of their hands. They contend that since the affected EOL products are their products, the CVE Program should not allow assignments for possible vulnerabilities that are not verifiable. Vendor CNAs who have been reluctant to assign CVE IDs for EOL products may want to reconsider. While it can be difficult to prove there is a vulnerability, using the EOL process to make assignments gives the Vendor CNA an opportunity to communicate, to the community and their customers, that the product is EOL and gives them another vehicle for reaching those who need to be aware they should upgrade their fielded products. An example of a possible message template is included below. 187 | 188 | > ** UNSUPPORTED WHEN ASSIGNED ** [VULN INFO HERE] We cannot prove this vulnerability exists. Out of an abundance of caution, this CVE ID is being assigned to better serve our customers and ensure all who are still running this product understand that the product is end of life and should be removed or upgraded. For more information on this, and how to upgrade, refer to the CVE Record’s reference information. 189 | 190 | Using this approach, a vendor could justify assigning CVE IDs for all reported EOL vulnerabilities, thus modeling proactive, customer-focused behavior. Externally, the company looks proactive and customer focused. If the CVE ID assigned to an EOL product is later discovered in a vulnerability scan, the description will reinforce that the product is no longer supported, and the customer may need to take action. This approach also has the potential to discourage the unethical practice of someone hunting for vulnerabilities in EOL products for the purpose of boosting their professional reputation. 191 | 192 | ## 8 CVE Program EOL Process Benefits 193 | 194 | The EOL process outlined in this document serves all CVE Program stakeholders to the degree possible (i.e., vulnerabilities are not hidden, but consumers are made aware they should not expect any mitigations or patches). The CVE EOL process provides another mechanism for Vendor CNAs to communicate to customers that EOL products are not supported and customers should upgrade to the latest version. And finally, the process is consistent with the CVE Program’s mission to assign CVE IDs and publish CVE Records for publicly known vulnerabilities. 195 | 196 | ## Appendix A Definitions 197 | 198 | **CVE Participants:** Anyone who is an active participant in the CVE Program, including CVE Board members, CNAs, Authorized Data Publishers (ADPs), and the CVE Program Secretariat. 199 | 200 | **CNA-LR:** The CNA-LR function must exist within each TLR hierarchy. Within that hierarchy, the CNA-LR function assigns CVE IDs and publishes CVE Records not covered by another CNA’s distinct, agreed upon scope. 201 | 202 | **EOL:** For the purpose of this document, End of Life (EOL) and End of Support (EOS) are being treated as the same, even though various vendors may use these terms differently. EOL essentially means the vendor has decided the product in question has reached the end of its “useful lifespan.” After this particular date, the manufacturer no longer markets, sells, provides technical support, sustains, enhances, or fixes the product. 203 | 204 | **Reporter:** The Reporter is the person that discovers and reports the vulnerability. It could be a security researcher, a corporate partner, an end-user, etc. 205 | 206 | **Top Level Root (TLR):** The highest level Root of a specific CNA hierarchy. 207 | 208 | **Vendor:** A vendor is anyone that creates, distributes, and maintains products, regardless of whether the product is an open source project deliverable or a commercial product. 209 | -------------------------------------------------------------------------------- /CVE_Inactive_CNA_Policy.md: -------------------------------------------------------------------------------- 1 | # CVE Program Policy and Procedure for Inactive CNAs 2 | 3 | | Status | Final | 4 | | ---: | --- | 5 | | Version | 1.2.0 | 6 | | Approved | 2021-01-14 | 7 | | Effective | 2021-01-14 | 8 | 9 | ## Policy for Inactive CNAs 10 | 11 | This policy and procedure is enforceable by Roots and the Secretariat. 12 | 13 | Active CNA participation is critical for the CVE Program to achieve its adoption, coverage, and time-to-populate goals. Active CNAs assign CVE IDs and publish CVE Records within a distinct, agreed upon, and documented scope (hereafter referred to as scope). By assigning CVE IDs and publishing CVE Records, CNAs expand CVE Program coverage and adoption, and are critical actors in federating CVE Program operations. Active CNAs may also participate in various working groups and discussions to advance CVE Program objectives. 14 | 15 | Inactive CNAs may be problematic for the CVE Program because adoption and coverage may not be achieved within a scope, even though such a scope is assigned to a CNA. However, inactive CNAs may be inactive for legitimate reasons, such as no new vulnerabilities are identified within a scope and, once identified, normal assignment and publication activities are resumed. There are also illegitimate reasons for CNA inactivity, such as the CNA is no longer interested, properly resourced, or competent to participate in the CVE Program as a CNA. CNAs that are inactive for legitimate reasons may continue to participate in the CVE Program. CNAs that are inactive for illegitimate reasons may not continue to participate in the CVE Program, unless the reasons for inactivity are satisfactorily remediated. 16 | 17 | Inactive CNAs are identified as those CNAs, over the preceding six-month period, that have not assigned CVE IDs or published CVE Records within a scope, and have not participated in any of the various working groups and discussions to advance CVE Program objectives. 18 | 19 | Inactive CNAs must be identified by their Root CNA so that: 1) the reason(s) for inactivity are determined; and 2) appropriate next steps are taken. 20 | 21 | ## Procedure for Contacting Inactive CNAs 22 | 23 | 1. Attempt to contact the CNA using all available contact information to determine the reason(s) for the inactivity and appropriate next steps; use the following message: 24 | 25 | > Active participation in the CVE Program is necessary to retain CNA status. Our records indicate that is currently inactive (i.e., over the preceding six-month period, CNA has not assigned CVE IDs or publish CVE Records within a scope, and/or has not participated in various working groups and discussions to advance CVE Program objectives). Please let us know the reasons for the inactivity by . 26 | 27 | If contact is made within two weeks, follow the [Reason for Inactivity](https://www.cve.org/Resources/General/Policies/Inactive-CNA-Policy.pdf#page=3&zoom=100,92,580) instructions. If contact is not made, proceed to step 2. 28 | 2. Two weeks after taking step 1, attempt to contact the CNA again (replying to the email submission from step 1) using the following message: 29 | 30 | > The CVE Program contacted you on to determine the reason for inactivity. Active participation in the CVE Program is necessary to maintain CNA status. Please let us know the reasons for the inactivity by . We look forward to hearing from you soon. 31 | 32 | If contact is made within two weeks, follow the Reason for Inactivity instructions. If contact is not made, proceed to step 3. 33 | 34 | 3. If contact is not made within two weeks of the step 2 communication, warn the CNA that it will be removed from the CVE Program within two weeks if they do not respond (replying to the email string from step 2); use the following statement: 35 | 36 | > The CVE Program contacted you on to determine the reason for inactivity. Our records indicate that is currently inactive because . Active participation in the CVE Program is necessary to maintain CNA status. If the CVE Program does not hear from you by , your CNA status will be revoked, which means that will no longer be authorized to assign CVE IDs or populate CVE Records and will be removed from the CNA roster, CNA-specific communication, and applicable working groups. 37 | > 38 | > Should your CNA status be revoked, you are eligible to reapply to become a CNA in the future, provided you complete the CNA onboarding process. 39 | > 40 | > We look forward to hearing from you soon. 41 | 42 | If contact is made within two weeks, follow the Reason for Inactivity instructions. If contact is not made, proceed to step 4 43 | 44 | 4. Two weeks after step 3, if contact is not made with the CNA, inform the CNA that its CNA status is hereby revoked respond (replying to the email string from step 3), using the following statement: 45 | 46 | > The CVE Program contacted on to determine why is inactive within the CVE Program. Responses to those communications were not received. Per the last communication, sent on CNA status is hereby revoked. This means that is no longer authorized to assign CVE IDs or publish CVE Records and has been removed from the CNA roster, CNA-specific communication, and applicable working groups. 47 | > 48 | > \ is eligible to reapply to become a CNA should the organization’s circumstances change. Should want to be a CNA in the future, please contact . 49 | > 50 | > Thank you for past service to the CVE Program. 51 | 52 | 6. The next step is to follow the CVE Program’s CNA Removal Process to remove the organization as a CNA. 53 | 54 | ## Reason for Inactivity 55 | 56 | 1. No longer wants to participate: Follow the [CNA Removal Process](https://www.cve.org/Resources/General/Policies/Inactive-CNA-Policy.pdf#page=3&zoom=100,92,712). 57 | 58 | 2. Legitimate: Document the reason(s) for inactivity and notify the Secretariat, the other Roots, and the CVE Board. 59 | 60 | 3. Illegitimate: Document the reason(s) for inactivity and any corrective action that may be required. Notify the Secretariat, the other Roots, and the CVE Board. 61 | 62 | ## Secretariat-specific CNA Removal Process 63 | 64 | 1. Announce the revocation of the CNA’s status: 65 | 66 | a. Send an email to the private CVE Board list. 67 | 68 | 2. Notify Web Admin so that the CNA is removed from the CNA list on the website (). 69 | 70 | 3. Mark the CNA as inactive in the CVE Wiki. 71 | 72 | 4. Transition the CNA’s CVE IDs to another CNA: 73 | 74 | a. Reject all of the CNA’s reserved but not public IDs. 75 | 76 | b. Transfer responsibility to the appropriate CNA(s) for the remaining CVE IDs. 77 | 78 | 5. Revoke the CNA’s privileges to all systems. 79 | 80 | a. Ask Content Team to mark CNA as inactive in the CPS. 81 | 82 | b. Remove CNA from the CNA mailing list (Only do this after the revocation message is sent). 83 | 84 | c. Ask the Content Team to remove the CNA from the authorized GitHub contributors. 85 | -------------------------------------------------------------------------------- /Glossary.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | | Status | | 4 | | ---: | :--- | 5 | | Version | 1.1.0 | 6 | | Approved | 2024-07-11 | 7 | | Effective | 2024-07-11 | 8 | 9 | ## Overview 10 | 11 | This is the source text for the CVE Program [Glossary](https://www.cve.org/ResourcesSupport/Glossary). 12 | 13 | ## Terms 14 | 15 | Authorized Data Publisher (ADP): An authorized entity with specific scope and responsibility to enrich the content of CVE Records published by CVE Numbering Authorities (CNAs) with additional, pertinent information (e.g., risk scores, references, vulnerability characteristics, translations). 16 | 17 | Council of Roots (CoR): The group of TL-Roots responsible for governance and administration of their respective hierarchies. 18 | 19 | CVE: The CVE registered trademark and the name Common Vulnerabilities and Exposures. 20 | 21 | CVE Board: The organization responsible for the strategic direction, governance, operational structure, policies, and rules of the CVE Program. 22 | 23 | CVE Identifier (CVE ID): An alphanumeric string that identifies a Publicly Disclosed vulnerability. The format of the CVE ID is defined in the CVE Record Format. 24 | 25 | CVE List: The catalog of all published CVE Records. 26 | 27 | CVE Numbering Authority (CNA): An authorized entity with specific scope and responsibility to regularly assign CVE IDs and publish corresponding CVE Records. 28 | 29 | CVE Numbering Authority of Last Resort (CNA-LR): A CNA authorized by a Root to assign CVE IDs and to publish corresponding CVE Records within that Root’s scope for vulnerabilities not covered by the Scope of another CNA. 30 | 31 | CVE Program: An international, community-driven effort to identify and catalog publicly disclosed vulnerabilities. 32 | 33 | CVE Program Participants: Anyone who is an active participant in the CVE Program, including CVE Board members, CNAs, Authorized Data Publishers (ADPs), and the CVE Program Secretariat. 34 | 35 | CVE Record: Structured data about a Vulnerability associated with a CVE ID. CVE Records are authored by CNAs. A CVE Record can be in one of the following states: 36 | 37 | * Reserved: A CNA has reserved a CVE ID. This is the initial state of a CVE ID. 38 | 39 | * Published: A CNA has populated the data associated with the CVE ID and published the CVE Record. 40 | 41 | * Rejected: The CVE ID and the associated CVE Record should no longer be used. A Rejected CVE Record remains on the CVE List so that users know that the CVE ID and CVE Record are invalid. 42 | 43 | CVE Working Group: An organization created and administered by the CVE Board to accomplish specific objectives through collaboration with CVE stakeholders and the general public where appropriate. 44 | 45 | End of Life (EOL): The CVE Program treats End of Life (EOL) and End of Support (EOS) as the same, even though various Suppliers may not. EOL essentially means the Supplier has decided the product in question has reached the end of its “useful lifespan.” After this date, the manufacturer no longer markets, sells, provides security fixes, technical support, sustains, enhances, or fixes bugs in the product. 46 | 47 | Fix: A change to software to remediate, mitigate, or otherwise address a vulnerability. “Fix” is used broadly and includes terms such as patch, fix, hotfix, update, and upgrade. 48 | 49 | Independently Fixable: A vulnerability is independently fixable when it can be fixed without fixing a separate vulnerability. 50 | 51 | Product: A unit of software or hardware or both. “Product” is used broadly and includes services, open source projects, specifications, and other common terms such as: system, appliance, device, component, library, package, archive, and collection. 52 | 53 | Publicly Disclosed: The state in which non-trivial information about a vulnerability is publicly available. The publication of most vulnerability advisories, software updates, proof-of-concept exploit code, or other detailed information makes the vulnerability “Publicly Disclosed.” 54 | 55 | Reporter: The entity that reports a vulnerability to a CNA. It could be a security researcher, a corporate partner, an end-user, etc. 56 | 57 | Reserved but Public (RBP): A CVE ID in the “Reserved” state that is referenced in one or more public sources but for which a CVE Record has not been published. 58 | 59 | Root: An organization authorized within the CVE Program that is responsible, within a specific Scope, for the recruitment, training, and governance of one or more entities that are a CNA, CNA-LR, or another Root. 60 | 61 | Scope (Scope Definition): A defined set of products, vulnerabilities, or both for which a CNA has authority and responsibility. 62 | 63 | Secretariat: An organization authorized by the CVE Program to develop, host, and maintain the Program’s infrastructure and to provide administrative and logistical support for the CVE Board, CVE Working Groups, and other parts of the Program. 64 | 65 | Tags: Labels used to indicate defined characteristics of CVE IDs: 66 | 67 | * exclusively-hosted-service: All known Products affected by the CVE ID exist only as fully hosted services. If the vulnerability affects both hosted services and on-premises Products, then this tag should not be used. 68 | 69 | * unsupported-when-assigned: At the time of CVE ID assignment, all known Products affected by the CVE ID no longer receive security Fixes. Typically the Products are no longer supported and are considered to be End of Life (EOL). 70 | 71 | * disputed: A CVE ID assignment or CVE Record content have been disputed. 72 | 73 | [Supplier](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossarySupplier): The entity that develops, maintains, or provides a product regardless of whether the product is an open-source project or a proprietary product. A supplier is typically responsible for and capable of investigating vulnerability reports and developing fixes or mitigations for vulnerabilities. “Supplier” is used broadly and includes common terms such as vendor, producer, developer, maintainer, author, owner, manufacturer, and provider. 74 | 75 | [Top-Level Root (TL-Root)](https://www.cve.org/ResourcesSupport/Glossary#glossaryTLRoot): The highest-level Root responsible for the governance and administration of a specified hierarchy, including Roots and CNAs within that hierarchy. 76 | 77 | Vulnerability: 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. 78 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CVE Policy Documents 2 | 3 | This repository tracks source text for CVE Program policy, process, guidance, terminology, and rules documents. Changes to these documents [require approval](https://github.com/CVEProject/cve-documents/blob/master/CVE_Board_Charter.md#214-policy-document-changes) by the CVE Board. Officially published versions of these documents can be found on the CVE Program [Resources](https://www.cve.org/ResourcesSupport/Resources) and [Glossary](https://www.cve.org/ResourcesSupport/Glossary) pages. 4 | -------------------------------------------------------------------------------- /archive/Board_Charter_v3.4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/Board_Charter_v3.4.pdf -------------------------------------------------------------------------------- /archive/Board_Charter_v3.5.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/Board_Charter_v3.5.pdf -------------------------------------------------------------------------------- /archive/CNA_Rules_v1.1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/CNA_Rules_v1.1.pdf -------------------------------------------------------------------------------- /archive/CNA_Rules_v2.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/CNA_Rules_v2.0.pdf -------------------------------------------------------------------------------- /archive/CNA_Rules_v3.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/CNA_Rules_v3.0.pdf -------------------------------------------------------------------------------- /archive/CNA_Rules_v4.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/CNA_Rules_v4.0.pdf -------------------------------------------------------------------------------- /archive/CNA_Rules_v4.1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/CNA_Rules_v4.1.0.pdf -------------------------------------------------------------------------------- /archive/CVE-Record-Dispute-Policy.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/archive/CVE-Record-Dispute-Policy.pdf -------------------------------------------------------------------------------- /assets/dispute_flowchart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CVEProject/cve-documents/8853a00446586357657292e0d42e42e774b5c738/assets/dispute_flowchart.png --------------------------------------------------------------------------------