Add OWASP Top 10 for Quantum Security entries (QS01-QS10)

quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md

@@ -0,0 +1,41 @@
+## QS01:2026 - Harvest-Now-Decrypt-Later Exposure
+
+**Description:**
+
+Adversaries are already capturing encrypted traffic and stored ciphertext today, retaining it for future decryption once a cryptographically relevant quantum computer (CRQC) exists. The relevant operation is typically a key-establishment step protected by RSA, finite-field Diffie-Hellman, or elliptic-curve Diffie-Hellman - all broken in polynomial time by Shor's algorithm. Once the session key is recovered, the symmetric ciphertext follows. Any organisation whose data has meaningful confidentiality lifetime - financial records, health data, source code, intelligence material, contractual or commercial secrets - must treat current TLS, VPN, and at-rest encryption based on these primitives as future-readable. The risk is concrete now, not contingent on quantum hardware availability.
+
+**Common Examples of Vulnerability:**
+
+1. Data sets whose confidentiality requirement extends beyond 2030 - health records, intellectual property, regulated personal data with long retention, government and defence data - protected only by classical public-key cryptography.
+2. Transport and channel protection using vulnerable key establishment: TLS endpoints, VPN tunnels, encrypted backup channels, archival storage encryption, and satellite or microwave links relying on RSA, ECDH, or finite-field DH.
+3. Encrypted traffic transiting an untrusted boundary where it can be passively recorded and retained for later decryption.
+4. Session encryption migrated to PQC while long-validity certificates and key-wrapping keys are left on classical algorithms.
+
+**How to Prevent:**
+
+1. Migrate vulnerable channels to hybrid post-quantum TLS using ML-KEM (FIPS 203) where the platform supports it.
+2. For data at rest, layer a PQC-protected encryption envelope over existing classical encryption for the highest-sensitivity datasets.
+3. Rotate symmetric data keys protected by quantum-vulnerable wrapping more frequently to reduce the volume exposed by any single recovered key.
+4. Reduce data retention where the business case allows - data not retained cannot be decrypted later.
+
+**Example Attack Scenarios:**
+
+Scenario #1: An adversary passively records TLS-protected traffic as it crosses an untrusted network boundary today. The handshake used RSA or ECDH key establishment. The captured ciphertext is archived. Once a CRQC becomes available, the adversary recovers the session key via Shor's algorithm and decrypts years of previously confidential traffic retroactively.
+
+Scenario #2: An organisation encrypts long-retention backups at rest with AES-256, but the AES data key is wrapped with RSA. An attacker exfiltrates the encrypted backups and the wrapped keys. Because the quantum-vulnerable layer is the RSA key-wrapping - not the symmetric cipher - the attacker recovers the wrapping key with a future CRQC and unwraps the AES keys, exposing the entire archive.
+
+**Reference Links:**
+
+<!-- References verified 2026-07-13 against authoritative canonical sources. -->
+
+1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final): Key-establishment standard for post-quantum migration.
+2. [UK NCSC - Timelines for migration to post-quantum cryptography (March 2025)](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): Migration timelines calling out long-lived sensitive data as a priority class.
+3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 deadline prohibiting standalone quantum-vulnerable PKC for high-risk use cases.
+4. [White House National Security Memorandum 10 (NSM-10)](https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/) and [OMB M-23-02](https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf): Cite HNDL as the primary driver of US migration urgency.
+
+**Standards and Regulatory Mapping:**
+
+> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation.
+
+NIST FIPS 203 (ML-KEM) for key establishment. NCSC Timelines for migration to post-quantum cryptography (March 2025). EU Coordinated Implementation Roadmap (June 2025), end-2030 high-risk deadline. NSA CNSA 2.0 prioritises network encryption and long-lived secrets. NIS2 Article 21(2)(h) cryptographic policy obligation; DORA Article 9 confidentiality and integrity at rest, in use and in transit. NSM-10 and OMB M-23-02 cite HNDL as the migration driver.
+

quantum-top-10/QS02_Long-Lived-Sensitive-Data.md

@@ -0,0 +1,42 @@
+## QS02:2026 - Long-Lived Sensitive Data
+
+**Description:**
+
+Data with a confidentiality requirement that extends past the projected arrival of a CRQC cannot be protected by today's public-key primitives alone. Mosca's inequality is the operative planning frame: if the time to migrate to quantum-safe cryptography (X) plus the required confidentiality lifetime of the data (Y) exceeds the time until a CRQC exists (Z), the organisation is already exposed. For data with multi-decade confidentiality requirements - archives, backups, regulated personal data, identity records, intellectual property, signed material whose integrity must hold for years - current public-key protection is insufficient regardless of exactly when a CRQC arrives. This is distinct from QS01: it focuses on stored data and signed artefacts whose protection requirements outlast any reasonable migration window, rather than in-flight traffic.
+
+**Common Examples of Vulnerability:**
+
+1. Major data categories where confidentiality lifetime plus migration lead time exceeds published government CRQC planning horizons (2030-2035 for most regulators).
+2. Archives and backups that pre-date current crypto policy and may contain quantum-vulnerable encryption under long retention requirements.
+3. Signed artefacts whose validity must persist for years: contracts, regulatory filings, evidentiary records, signed software releases, blockchain transactions.
+4. Identity and credential records with multi-year lifetimes: government identity issuance, professional credentials, root certificates.
+5. Data-at-rest encrypted with AES-256 but wrapped with an RSA or ECC key - the quantum-vulnerable layer sits above the symmetric key.
+
+**How to Prevent:**
+
+1. Establish data classification by confidentiality lifetime, not just sensitivity - a medium-sensitivity record with a 30-year retention requirement may outrank a high-sensitivity record retained for two years.
+2. Plan re-encryption programmes for high-priority archives, sequenced against migration capacity.
+3. For long-lived signed artefacts, plan re-signing or counter-signing with PQC schemes (ML-DSA, SLH-DSA) before classical signature schemes are deprecated.
+4. Where re-encryption is not feasible, reduce retention to the minimum legally and operationally required.
+
+**Example Attack Scenarios:**
+
+Scenario #1: A regulated entity retains personal records for a statutory 30-year period, encrypted with an RSA-wrapped AES key. An adversary harvests the encrypted store today. Applying Mosca's inequality, the confidentiality lifetime far exceeds the CRQC horizon, so the records are effectively already compromised: the attacker recovers the wrapping key once a CRQC exists and decrypts the full archive, well within its required protection window.
+
+Scenario #2: A vendor issues software releases signed with ECDSA, with signatures expected to remain valid for the product's decade-long support lifetime. An attacker records the signed artefacts and, after a CRQC becomes available, forges signatures on malicious updates that still validate against the long-lived, un-rotated trust anchor.
+
+**Reference Links:**
+
+<!-- References verified 2026-07-13 against authoritative canonical sources. -->
+
+1. [NIST IR 8547 (Draft) - Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Transition planning guidance referencing Mosca's inequality.
+2. [UK NCSC - Next steps in preparing for post-quantum cryptography](https://www.ncsc.gov.uk/paper/next-steps-in-preparing-for-post-quantum-cryptography): Long-lived data prioritisation for PQC migration.
+3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 high-risk deadline and standalone-PKC prohibition.
+4. [EU Cyber Resilience Act - Regulation (EU) 2024/2847, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art protection required through the product support period.
+
+**Standards and Regulatory Mapping:**
+
+> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation.
+
+NIST IR 8547 (Draft) on transition planning. NCSC migration guidance on long-lived data prioritisation. EU Coordinated Implementation Roadmap end-2030 high-risk deadline; explicit prohibition on standalone quantum-vulnerable PKC for high-risk cases after 2030. CRA Annex I requires state-of-the-art protection through the support period, which for many products extends past 2030.
+

quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md

@@ -0,0 +1,43 @@
+## QS03:2026 - Vulnerable Signatures and Code-Signing
+
+**Description:**
+
+Public-key signatures underpin code signing, supply-chain integrity, document validity, identity certificates, transactions, and long-term non-repudiation. RSA, DSA, ECDSA, and EdDSA are all broken by Shor's algorithm, so any system that verifies these signatures to establish trust - software updates, container images, firmware, package managers, TLS certificate hierarchies, SBOM attestations, signed documents, blockchain transactions - is at risk once a CRQC exists. Unlike confidentiality breaches, signature forgery enables active attacks: malicious updates, fake identities, fraudulent transactions, supply-chain compromise. The post-quantum signature standards (ML-DSA / FIPS 204 and SLH-DSA / FIPS 205) have larger keys and signatures and different operational profiles, with non-trivial impact on hardware roots of trust, constrained devices, and certificate ecosystems.
+
+**Common Examples of Vulnerability:**
+
+1. Certification authority hierarchies (root, intermediate, issuing CA) signing with RSA-2048 or ECDSA P-256 over multi-year validity periods.
+2. Code-signing keys: OS update signing, firmware signing, container image signing (Sigstore, cosign, Notary), package signing, mobile app signing, CI/CD signing.
+3. Other long-lived signature trust anchors: UEFI Secure Boot keys, TPM endorsement keys, JWT/SAML issuer keys, document-signing certificates, blockchain wallet keys.
+4. Large verifier populations - devices, services, or artefacts - that trust a classical key and cannot easily be upgraded.
+
+**How to Prevent:**
+
+1. Migrate code-signing and CA hierarchies before broader estate migration - they have the longest blast radius and lead time.
+2. Adopt hybrid signing during transition: produce both a classical and a PQC signature on the same artefact so non-PQC verifiers keep working while PQC-aware verifiers gain forward security.
+3. Use ML-DSA (FIPS 204) for general digital signatures; use SLH-DSA (FIPS 205) for very long-lived, high-assurance signatures where stateless hash-based security is preferred.
+4. Plan for shorter certificate lifetimes during transition (e.g. the CA/Browser Forum 47-day TLS maximum effective 2029) to reduce the exposure window.
+5. Engage PKI, code-signing, and certificate-authority vendors on PQC roadmaps - failure here is a supply-chain blocker.
+
+**Example Attack Scenarios:**
+
+Scenario #1: An attacker with a future CRQC recovers the private key of a code-signing certificate still on ECDSA P-256. They sign malware that passes verification on every device trusting that anchor, distributing a malicious "update" through the legitimate update channel.
+
+Scenario #2: An organisation migrates its leaf TLS certificates to PQC but leaves the root and intermediate CAs on RSA. An attacker forges an intermediate CA signature with a CRQC and issues trusted certificates for arbitrary domains - the chain is only as strong as its weakest classical link.
+
+**Reference Links:**
+
+<!-- References verified 2026-07-13 against authoritative canonical sources. -->
+
+1. [NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Module-lattice digital signature standard.
+2. [NIST FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final): Stateless hash-based signature standard for high-assurance, long-lived use.
+3. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/): Software and firmware signing exclusively CNSA 2.0 by 2030.
+4. [IETF LAMPS Working Group](https://datatracker.ietf.org/wg/lamps/about/): PQC X.509 and CMS extensions.
+5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art integrity and authenticity requirements.
+
+**Standards and Regulatory Mapping:**
+
+> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation.
+
+NIST FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). NSA CNSA 2.0: software and firmware signing exclusively CNSA 2.0 by 2030. NCSC recommends ML-DSA-65 for most use cases. EU CRA Annex I requires state-of-the-art mechanisms for integrity and authenticity. IETF LAMPS working group on PQC X.509 and CMS extensions. DORA Articles 28-44 on third-party risk management apply to PKI and signing service vendors.
+

quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md

@@ -0,0 +1,44 @@
+## QS04:2026 - Absent Cryptographic Inventory and CBOM
+
+**Description:**
+
+Organisations cannot migrate cryptography they have not catalogued. Cryptographic inventory means a documented record of every place cryptography is used - applications, services, certificates, signing keys, protocols, libraries, hardware roots of trust, third-party components, and embedded keys in firmware or silicon - with algorithm, key length, key custody, lifecycle, and system owner recorded for each. Without it, scope is unknowable, prioritisation is impossible, and a controlled migration cannot be executed. Long-lived signing keys, embedded device keys, root and intermediate CA keys, code-signing keys, hardware-bound keys in HSMs and TPMs, and keys baked into firmware or silicon are all on the critical path and are most often where inventories fail. The absence of a structured cryptographic bill of materials (CBOM) is the single most common blocker to PQC migration in 2026.
+
+**Common Examples of Vulnerability:**
+
+1. No structured, current record of cryptographic usage across the estate - or one that exists only as unstructured prose rather than a CBOM-compatible format.
+2. Inventories that omit whole classes: HSM and TPM contents, embedded devices, third-party components, and SaaS dependencies.
+3. One-off inventories with no automated or scheduled process to keep them current, so they age out within months.
+4. Records that capture algorithm and key length but not key custody, generation, or rotation procedures.
+5. Keys baked into firmware, silicon, or sealed devices that cannot be enumerated through software discovery.
+
+**How to Prevent:**
+
+1. Adopt CBOM (Cryptography Bill of Materials) as the inventory format, aligning with CycloneDX or SPDX cryptographic extensions.
+2. Use cryptographic discovery tooling to bootstrap the inventory: TLS scanners, certificate transparency logs, code-scanning for crypto-library usage, dependency scanners for SBOMs.
+3. Assign named owners for each asset class: applications, certificates, signing infrastructure, embedded systems, third-party.
+4. Make the inventory a living document - integrate updates into change management, procurement, and CI/CD pipelines.
+5. Extend inventory to cover key generation, custody, rotation, and revocation, not just static algorithm and key-length data.
+
+**Example Attack Scenarios:**
+
+Scenario #1: An organisation begins PQC migration but has no CBOM. A forgotten intermediate CA and a set of firmware-embedded signing keys are never catalogued, so they are never migrated. After a CRQC exists, an attacker targets exactly these un-inventoried classical anchors, which remain trusted across the estate.
+
+Scenario #2: A SaaS dependency terminates TLS with a quantum-vulnerable configuration the organisation never recorded because inventory covered only owned-and-operated systems. The unmanaged dependency becomes the harvest point for an HNDL adversary, invisible to the migration programme.
+
+**Reference Links:**
+
+<!-- References verified 2026-07-13 against authoritative canonical sources. -->
+
+1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): 2028 discovery-and-assessment milestone.
+2. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2026 inventory and dependency-map requirement.
+3. [CISA, NSA, NIST - Quantum-Readiness: Migration to PQC fact sheet (August 2023)](https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography): Cryptographic inventory recommendation.
+4. [CycloneDX CBOM specification](https://cyclonedx.org/capabilities/cbom/): Cryptography Bill of Materials schema.
+5. [NIST IR 8547 (Draft)](https://csrc.nist.gov/pubs/ir/8547/ipd): Lifecycle management for transition planning.
+
+**Standards and Regulatory Mapping:**
+
+> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation.
+
+NCSC Timelines for migration to post-quantum cryptography (2028 discovery milestone). EU Coordinated Implementation Roadmap end-2026 inventory and dependency-map requirement. CISA, NSA, NIST Quantum-Readiness fact sheet (August 2023) cryptographic inventory recommendation. NIST IR 8547 on lifecycle management. NIS2 Article 21(2)(h). DORA Article 9 ICT risk management obligation. CycloneDX and SPDX CBOM specifications.
+