Formalize Quantum Top 10 entry template

quantum-top-10/EVIDENCE_CONVENTION.md

@@ -0,0 +1,82 @@
+# Evidence Convention
+
+## Purpose
+
+The Evidence classification communicates the maturity of the **attack class** described by a Top 10 entry.
+
+It does **not** describe:
+
+- likelihood
+- impact
+- overall risk
+- priority
+
+Those are assessed independently.
+
+---
+
+## Evidence Classifications
+
+### Demonstrated
+
+The attack class has been demonstrated against real systems or realistic prototypes and is supported by publicly available evidence.
+
+Acceptable evidence includes one or more of:
+
+- peer-reviewed experimental research
+- public proof-of-concept
+- CVE or security advisory
+- vendor acknowledgement
+- publicly documented real-world incident
+
+### Emerging
+
+The attack class is technically credible and supported by research or early demonstrations, but has not yet been broadly demonstrated in operational environments.
+
+Typical evidence includes:
+
+- laboratory demonstrations
+- prototype implementations
+- peer-reviewed research
+- credible engineering analyses
+
+### Theoretical
+
+The attack class is supported by accepted theory or security analysis but has not yet been experimentally demonstrated.
+
+Evidence typically consists of:
+
+- mathematical analysis
+- security proofs
+- theoretical models
+
+---
+
+## Classification Guidance
+
+The classification applies to the **attack class**, not to every step required for successful exploitation.
+
+Example:
+
+Harvest Now, Decrypt Later (HNDL)
+
+- Harvesting encrypted data: Demonstrated
+- Future decryption using a CRQC: Future dependency
+
+Overall classification:
+
+**Demonstrated**, with the note that successful decryption depends on the availability of a Cryptographically Relevant Quantum Computer (CRQC).
+
+---
+
+## Author Guidance
+
+Every Top 10 entry should include:
+
+**Evidence**
+
+- **Classification:** Demonstrated | Emerging | Theoretical
+- **Justification:** One or two sentences explaining the classification.
+- **Primary Evidence:** The strongest supporting references should also appear in the Reference section.
+
+The objective is transparency and consistency rather than precise scientific scoring.

quantum-top-10/_template.md

@@ -1,28 +1,101 @@
-## Vulnerability Name
+# Top 10 Entry Template
 
-**Description:**
+## QSXX:2026 - Risk Name
 
-A brief description of the vulnerability that includes its potential effects such as system compromises, data breaches, or other security concerns.
+**Description**
 
-**Common Examples of Vulnerability:**
+Describe the risk, the affected assets, the relevant threat or failure condition, and the potential impact.
 
-1. Example 1: Specific instance or type of this vulnerability.
-2. Example 2: Another instance or type of this vulnerability.
-3. Example 3: Yet another instance or type of this vulnerability.
+**Scope**
 
-**How to Prevent:**
+Clearly define what this entry covers and, where useful, what it explicitly does **not** cover. Use this section to distinguish the risk from adjacent Top 10 entries.
 
-1. Prevention Step 1: A step or strategy that can be used to prevent the vulnerability or mitigate its effects.
-2. Prevention Step 2: Another prevention step or strategy.
-3. Prevention Step 3: Yet another prevention step or strategy.
+**Evidence**
 
-**Example Attack Scenarios:**
+**Classification:** Demonstrated | Emerging | Theoretical
+
+Provide a short justification and reference the supporting evidence.
+
+See `EVIDENCE_CONVENTION.md` for the evidence convention.
+
+**Common Examples**
+
+Representative examples of the conditions, weaknesses, exposures, or implementation patterns associated with this risk.
+
+1. Example
+2. Example
+3. Example
+
+**Detection**
+
+Describe practical ways an organisation can determine whether it is exposed to this risk.
+
+Examples include:
+
+- architecture reviews
+- cryptographic inventories / CBOMs
+- configuration analysis
+- software composition analysis
+- runtime monitoring
+- infrastructure assessments
+
+**How to Prevent**
+
+Describe practical mitigations.
+
+Where practical, recommendations should be:
+
+- **Actionable** – clearly state what should be implemented.
+- **Measurable** – allow objective assessment of implementation.
+- **Verifiable** – capable of being independently assessed through testing, automation, review or audit.
+
+Detailed verification procedures belong in supporting guidance rather than in the Top 10 itself.
+
+**Example Attack Scenarios**
 
 Scenario #1: A detailed scenario illustrating how an attacker could potentially exploit this vulnerability, including the attacker's actions and the potential outcomes.
 
 Scenario #2: Another example of an attack scenario showing a different way the vulnerability could be exploited.
 
-**Reference Links:**
+**Standards & Regulatory Mapping**
+
+Identify the authoritative documents that define, recommend, or influence security practice for this risk.
+
+Include relevant:
+
+- standards;
+- regulations;
+- government guidance;
+- recognised industry guidance.
+
+Briefly describe how each document relates to the risk.
+
+If no authoritative mapping currently exists, state this explicitly.
+
+**Related Risks**
+
+Reference other Quantum Security Top 10 entries where relevant and briefly explain the relationship.
+
+- QSXX – Relationship
+- QSYY – Relationship
+
+Examples for QS01:
+- **QS04 – Absent Cryptographic Inventory:** A cryptographic inventory is required to identify quantum-vulnerable encryption and prioritise HNDL exposure.
+- **QS05 – Crypto-Agility Failures:** Poor crypto agility increases migration time, extending HNDL exposure.
+- **QS06 – Insecure Migration and Hybrid Misuse:** Migration failures may leave HNDL exposure unresolved even after migration has begun.
+
+**Reference Links**
+
+Provide the primary references supporting the technical content of this entry.
+
+Examples include:
+
+- peer-reviewed research;
+- technical reports;
+- RFCs;
+- vendor documentation;
+- security advisories;
+- CVEs;
+- publicly available proof-of-concepts.
 
-1. [Link Title](URL): Brief description of the reference link.
-2. [Link Title](URL): Brief description of the reference link.
+These references should support the statements, attack scenarios, mitigations, or evidence classification described in the entry.