From ab3a4be453e22e7aeff22f3377d79710c0f80a21 Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Mon, 27 Jul 2026 23:35:53 +0100 Subject: [PATCH] Add proposals directory, evidence convention and CONTRIBUTING Implements two Pre-Sprint 0 activities from the sprint plan that do not yet exist in the repository: the proposals directory that new entries are routed to, and the published evidence and anchor convention behind the "evidence over speculation" working principle. CONTRIBUTING.md consolidates the contribution routes already described across the README and sprint plan. No existing file is modified. --- CONTRIBUTING.md | 75 ++++++++++++++++++++++++++ proposals/README.md | 45 ++++++++++++++++ quantum-top-10/_evidence-convention.md | 63 ++++++++++++++++++++++ 3 files changed, 183 insertions(+) create mode 100644 CONTRIBUTING.md create mode 100644 proposals/README.md create mode 100644 quantum-top-10/_evidence-convention.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..43d4f83 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,75 @@ +# Contributing + +Feedback and contributions are welcome. The OWASP Top 10 for Quantum Security +Risks is at draft v0.1 and is explicitly opened for discussion - the v0.1 entries +hold no incumbency and may be revised, merged, or dropped. + +The route from v0.1 to a community-validated v1 is set out in the +[sprint plan](plans/sprint-plan-quantum-top10-2026.md). Contributors do not need +to be entry leads or working group members to submit. + +## Where your contribution goes + +| You want to | Do this | +|---|---| +| Propose a new risk entry | Pull request adding a file to [`proposals/`](proposals/) | +| Give structured feedback on an existing entry | Pull request against that entry in [`quantum-top-10/`](quantum-top-10/) | +| Raise a question, flag an error, or discuss scope and ordering | Open an [issue](https://github.com/OWASP/quantum-security-project/issues) | +| Contribute without using GitHub | Use the [candidate risks and feedback form](https://forms.gle/8NbEEX6mmiKdUXxXA) or the [work areas and proposals form](https://forms.gle/n7BicJJpQJFQ8eRz7) | + +Issues are the right place for feedback that is not yet a concrete edit. A pull +request is the right place for feedback that is. + +## Making a change + +```bash +git clone https://github.com/OWASP/quantum-security-project.git +cd quantum-security-project +git checkout -b my-contribution +# edit or add entries; start from quantum-top-10/_template.md for new risks +git commit -am "Describe your change" +git push -u origin my-contribution +``` + +Then open a pull request against `main`. If you do not have write access, fork +the repository first and open the pull request from your fork. + +Please keep a pull request to one entry or one concern where you can. It makes +review tractable and keeps discussion of a disputed scope boundary separate from +discussion of a citation fix. + +## What contributions need to satisfy + +- **Grounded in evidence.** Ground new or revised content in published + standards, regulation, or peer-reviewed research. See the + [evidence and anchor convention](quantum-top-10/_evidence-convention.md) for + the tags and the anchor hierarchy, and cite primary sources rather than + secondary summaries. +- **Vendor-neutral.** Naming a product is fine where it is the evidence - a + library's default configuration, a documented vulnerability - but the project + does not endorse or recommend vendors. +- **Practical.** The success criteria for v1 are that it is useful to defenders + today, actionable, and linked to existing guidance. Mitigations should say + what to do, not that a problem should be addressed. + +Contributions on the **platform surface** (QS08-QS10: QPU tenant isolation, +toolchain and compiler security, side-channel and control-plane exposure) are +particularly sought, since the practitioner community there is smaller. + +## Community + +- **OWASP Slack:** `#project-quantum-security` - [join the OWASP Slack](https://owasp.org/slack/invite) +- **Biweekly community call:** Mondays 17:30-18:30 London, every two weeks from + 3 August 2026. Zoom link, meeting ID, and an ICS invite are in the + [README](README.md#community-and-contact); decks are published in [`calls/`](calls/). +- **Email:** contribute@quantum-owasp.org + +The project follows the OWASP Code of Conduct and OWASP's vendor-neutrality +requirements. + +## License + +Contributions are made under the +[Creative Commons Attribution-ShareAlike 4.0](LICENSE) license (CC BY-SA 4.0). +By opening a pull request you agree that your contribution is licensed on those +terms. diff --git a/proposals/README.md b/proposals/README.md new file mode 100644 index 0000000..0302122 --- /dev/null +++ b/proposals/README.md @@ -0,0 +1,45 @@ +# Proposals + +This directory holds proposed new entries for the OWASP Top 10 for Quantum +Security Risks while they are under consideration. It exists because the +[sprint plan](../plans/sprint-plan-quantum-top10-2026.md) routes new entries +here: *"Open submission of new entries via pull request to the proposals +directory."* + +Proposals live here rather than in [`quantum-top-10/`](../quantum-top-10/) so +that the draft list and the candidate pool stay visibly separate. Nothing in +this directory is part of the Top 10. + +## Submitting a proposal + +1. Copy [`../quantum-top-10/_template.md`](../quantum-top-10/_template.md) to + `proposals/PROPOSAL_Short-Name.md`. +2. Fill in the template sections. Ground the content in published standards, + regulation, or peer-reviewed research, and keep it vendor-neutral. +3. Tag the evidence for each attack class you describe, following + [the evidence and anchor convention](../quantum-top-10/_evidence-convention.md). +4. Open a pull request against `main`. + +Proposals do not carry a QS number. Numbering is assigned if and when an entry +is selected for the list. + +## What happens to a proposal + +Per the sprint plan, the generative sprint (to 3 August 2026) collects +proposals; Sprint 1 (3-17 August) ranks them by community vote alongside +internal review of evidence quality, scope overlap, and coverage across the +migration and platform surfaces. The v0.1 entries hold no incumbency and +compete on the same terms, so a proposal may displace an existing entry rather +than only be added alongside one. + +Selected proposals move into `quantum-top-10/` with a QS number. Proposals that +are not selected stay here as a record of what was considered. + +## Other kinds of contribution + +- **Structured feedback on an existing entry:** open a pull request against that + entry in `quantum-top-10/`, not a proposal here. +- **Less formed feedback, questions, or a discussion about scope:** open an + [issue](https://github.com/OWASP/quantum-security-project/issues). + +See [CONTRIBUTING.md](../CONTRIBUTING.md) for the full picture. diff --git a/quantum-top-10/_evidence-convention.md b/quantum-top-10/_evidence-convention.md new file mode 100644 index 0000000..48e2821 --- /dev/null +++ b/quantum-top-10/_evidence-convention.md @@ -0,0 +1,63 @@ +# Evidence and anchor convention + +The [sprint plan](../plans/sprint-plan-quantum-top10-2026.md) sets out the +working principle this document implements: + +> **Evidence over speculation.** Proposals are tagged as demonstrated, emerging +> or theoretical, so that the evidence base of the final list is visible rather +> than implied. + +Tagging makes the strength of each claim explicit in the artefact itself. A +theoretical risk is not disqualified by being theoretical - a list that only +admitted demonstrated attacks would miss most of the migration surface, where +the defining risk is that the attack is not yet possible. What matters is that +the reader can see which is which without reconstructing it from the references. + +## Evidence tags + +Tags apply per attack class, not per entry. An entry may carry more than one +tag where it describes several failure modes. + +| Tag | Meaning | +|---|---| +| **demonstrated** | Shown against real systems: a published exploit or proof-of-concept on production or production-representative systems, or an assigned CVE. | +| **emerging** | Shown under laboratory conditions, typically in peer-reviewed research, or documented as a near-miss - but not yet observed against systems in production use. | +| **theoretical** | A sound analysis of a plausible failure mode, following from published cryptographic or architectural results, with no demonstration yet. | + +A useful boundary case: an attack that depends on a cryptographically relevant +quantum computer (CRQC) is tagged by the state of everything *except* the CRQC. +Harvest-now-decrypt-later collection is demonstrated as collection; the +decryption step is not. Where an entry turns on this distinction, say so in the +text rather than resolving it in the tag alone. + +## Anchor hierarchy + +Every claim should rest on the strongest anchor available to it. Where a +stronger anchor exists, prefer it: + +1. **Standards and regulation** - NIST FIPS and IR publications, IETF RFCs, UK + NCSC guidance, EU regulation and roadmaps, NSA CNSA. +2. **Peer-reviewed research** - papers at recognised venues; cite the venue and + a DOI or the publisher's page. +3. **CVEs and demonstrated proofs-of-concept** - cite the CVE record. +4. **Preprints and working drafts** - acceptable where nothing stronger exists, + but mark the status in the citation. + +Two practices keep the anchors trustworthy over the life of the list: + +- **Cite the primary source.** Link the standard, the RFC, the CVE record, or + the paper itself, not a secondary summary of it. Secondary sources have + already introduced errors into this repository's citations. +- **Record verification.** Entries carry an HTML comment above the reference + list noting the date the references were verified and any corrections made. + Keep it current when you touch the references, and note when an anchor has + been superseded - drafts become RFCs, and draft names change on working-group + adoption. + +## Applying a tag + +State the tag inline where the attack class is described, or in the pull request +where an entry's overall evidence base is under discussion. If the template +gains a dedicated field for this - as proposed in +[issue #15](https://github.com/OWASP/quantum-security-project/issues/15) - that +field takes precedence over any convention here.