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.