Add a CVE Triage Checklist to the rules

CNA_Rules.md

@@ -20,6 +20,8 @@
 
     1.5 [Other Useful Information](#15-other-useful-information)
 
+    1.6 [CVE Triage Checklist](#16-cve-triage-checklist)
+
 2. [Managing the CNA Operational Rules](#2-managing-the-cna-operational-rules)
 
     2.1 [Changes to the CNA Operational Rules](#21-changes-to-the-cna-operational-rules)
@@ -124,6 +126,37 @@ To successfully interpret and follow the CNA Operational Rules, it is necessary
 * [CVE Record Lifecycle](https://www.cve.org/About/Process)
 * [CVE Program Professional Code of Conduct](https://www.cve.org/ResourcesSupport/AllResources/ProfessionalCodeOfConduct)
 
+### 1.6 CVE Triage Checklist
+
+This checklist is a brief guide for initial triage to answer: “Should this bug get a CVE ID?” This section intentionally removes nuance found in the full CNA Operational Rules throughout this document, and should be used only for quick, first-pass determination for assignment.
+
+##### 1.6.1 A CVE MUST be assigned if it meets all these criteria:
+
+1. **Is it a Vulnerability?** The issue is a weakness in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability or violating a security policy.
+2. **Is it Independently Fixable?** The issue can be fixed separately from other issues (if yes, it generally gets its own CVE).
+3. **Is it Publicly Disclosed?** The vulnerability has been or is expected to be Publicly Disclosed.
+4. **Is it in Scope?** The vulnerability falls within the CNA's established Scope Definition.
+
+##### 1.6.2 When to assign
+
+- The issue is an insecure default configuration setting.
+- The issue is a malicious modification to a Product (like a trojan horse).
+- The issue is residual insecurity left by an incomplete fix for a previous vulnerability.
+- The issue requires action or risk assessment by parties other than the CNA or Supplier.
+
+##### 1.6.3: When not to assign
+
+- The issue is only exploitable by combining with another vulnerability (must have one CVE ID).
+- The issue is not a cybersecurity vulnerability (for example, it requires physical theft or unique physical access to hardware).
+- The issue is in deliberately vulnerable or malicious code (for eample, [DVWA](https://github.com/digininja/DVWA)).
+- The issue is the act of updating a dependency to address a vulnerability in that dependency, and not a new vulnerability in the dependent product.
+- The issue is a documented non-default configuration change made by an authorized user.
+- The issue is a brute-force DoS or resource exhaustion attack (unless a common defense is missing).
+- The issue is in a Product that was never publicly available.
+- End-of-Life (EOL) status, alone, is not sufficient to assign.
+
+There may be unique circumstances when assignment is appropriate despite not neatly fitting in one or more the above criteria, and many of these nuances are addressed in the remainder of this document, especially in section [4 CNA Operational Rules](#4-cna-operational-rules). Generally, if the decision is close, the CNA with the most appropriate Scope should prefer assignment.
+
 ## 2 Managing the CNA Operational Rules
 
 The CNA Operational Rules are managed, maintained, and approved by the CVE Board.