From db780aec0606e9ce7dcd951795e982ce3e14e5af Mon Sep 17 00:00:00 2001 From: Reza Hedayat Date: Thu, 13 Aug 2026 18:10:39 +0200 Subject: [PATCH] Formalize Quantum Top 10 entry template --- quantum-top-10/EVIDENCE_CONVENTION.md | 82 ++++++++++++++++++++ quantum-top-10/_template.md | 103 ++++++++++++++++++++++---- 2 files changed, 170 insertions(+), 15 deletions(-) create mode 100644 quantum-top-10/EVIDENCE_CONVENTION.md diff --git a/quantum-top-10/EVIDENCE_CONVENTION.md b/quantum-top-10/EVIDENCE_CONVENTION.md new file mode 100644 index 0000000..6a333ff --- /dev/null +++ b/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. diff --git a/quantum-top-10/_template.md b/quantum-top-10/_template.md index e6ce012..234cec9 100644 --- a/quantum-top-10/_template.md +++ b/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.