From 7f5745d6018617865ff201f69ef284b37261683d Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Thu, 19 Dec 2024 14:09:58 -0500
Subject: [PATCH 01/18] Add post-mortem report template

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/reports/YYYYMMDD-template.md | 72 +++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 security/reports/YYYYMMDD-template.md

diff --git a/security/reports/YYYYMMDD-template.md b/security/reports/YYYYMMDD-template.md
new file mode 100644
index 0000000..785f53a
--- /dev/null
+++ b/security/reports/YYYYMMDD-template.md
@@ -0,0 +1,72 @@
+# OQS Vulnerability Response Report
+
+<!--
+Copy this template and rename the file following the format YYYYMMDD-vulnerability-name.md format.
+The date should be the date that the report was created.
+
+The intent of these reports is to help streamline the vulnerability response process.
+No technical details about the vulnerability need to be provided here; those are contained in the security advisories.
+
+For a completed example, see the report 20241220-hqc-decaps.md in this same directory.
+-->
+
+## Information
+
+<!--
+Provide links to any associated published GitHub Security Advisories.
+If there are none, provide (or link to) information about the reported vulnerability.
+-->
+
+## Process
+
+### 1. Intake
+
+<!--
+Briefly summarize how the vulnerability report was received.
+Be sure to include the following information:
+- intake method (e.g., security@openquantumsafe.org, GitHub security report, internal meeting)
+- date of report
+- initial response time
+- initial responder
+-->
+
+### 2. Assessment
+
+<!--
+Briefly summarize the assessment process.
+Technical details about the vulnerability are not necessary.
+Instead, focus on which projects were impacted and 
+Be sure to include the following information:
+- OQS subprojects affected by the vulnerability
+- upstream sources notified
+- team members identified and assigned to work on a fix
+-->
+
+### 3. Patching
+
+<!--
+Briefly summarize the patch development process.
+Be sure to highlight any friction points.
+-->
+
+### 4. CVE assignment
+
+<!--
+Was a CVE assigned?
+If not, provide rationale.
+-->
+
+### 5. Public disclosure
+
+<!--
+Provide details about public disclosures (e.g., release notes, emails) other than the GitHub Security Advisories already included in the "Information" section.
+-->
+
+### 6. Feedback
+
+<!--
+Highlight any friction points in the response process.
+Feel free to provide suggestions to improve the process.
+Additionally, mention any follow-up work related to the vulnerability.
+-->
+

From 9549681c926fb921de8ac4f2f8e3f92ed4a08834 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Thu, 19 Dec 2024 14:42:56 -0500
Subject: [PATCH 02/18] Add security report for CVE-2024-54137

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/reports/20241220-hqc-decaps.md | 106 ++++++++++++++++++++++++
 1 file changed, 106 insertions(+)
 create mode 100644 security/reports/20241220-hqc-decaps.md

diff --git a/security/reports/20241220-hqc-decaps.md b/security/reports/20241220-hqc-decaps.md
new file mode 100644
index 0000000..5949096
--- /dev/null
+++ b/security/reports/20241220-hqc-decaps.md
@@ -0,0 +1,106 @@
+# OQS Vulnerability Response Report
+
+<!--
+Copy this template and rename the file following the format YYYYMMDD-vulnerability-name.md format.
+The date should be the date that the report was created.
+
+The intent of these reports is to help streamline the vulnerability response process.
+No technical details about the vulnerability need to be provided here; those are contained in the security advisories.
+
+For a completed example, see the report 20241220-hqc-decaps.md in this same directory.
+-->
+
+## Information
+
+<!--
+Provide links to any associated published GitHub Security Advisories.
+If there are none, provide (or link to) information about the reported vulnerability.
+-->
+
+See https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-gpf4-vrrw-r8v7
+
+## Process
+
+### 1. Intake
+
+<!--
+Briefly summarize how the vulnerability report was received.
+Be sure to include the following information:
+- intake method (e.g., security@openquantumsafe.org, GitHub security report, internal meeting)
+- date of report
+- initial response time
+- initial responder
+-->
+
+We received an initial report from Quarkslab researchers Célian Glénaz and Dahmun Goudarzi via GitHub on 17 September 2024.
+Due to GitHub configuration issues, we were unaware of the report until 24 October, when the reporters left a follow-up comment.
+We did not respond to the reporters until completing the Assessment phase.
+
+### 2. Assessment
+
+<!--
+Briefly summarize the assessment process.
+Technical details about the vulnerability are not necessary.
+Instead, focus on which projects were impacted and 
+Be sure to include the following information:
+- OQS subprojects affected by the vulnerability
+- upstream sources notified
+- team members identified and assigned to work on a fix
+-->
+
+Douglas shared the report with Spencer, who was the team member most familiar with the affected code (the HQC implementation).
+Spencer confirmed the report's findings and responded to the reporters on GitHub on 6 November.
+The vulnerability was present in upstream code (https://pqc-hqc.org) and pulled into the library via PQClean.
+Spencer notified the "main" and "backup" contacts listed on the upstream source's website after coordinating with the reporters.
+The only subproject directly affected (by including vulnerable code) was liboqs.
+It was believed that liboqs-rust was also affected; however, this turned out not to be the case.
+
+Douglas and Spencer consulted and decided not to create a dedicated security release for two reasons:
+1. The 0.12.0 release of liboqs was imminent, so a patch could be included there.
+2. HQC was still an experimental algorithm.
+
+### 3. Patching
+
+<!--
+Briefly summarize the patch development process.
+Be sure to highlight any friction points.
+-->
+Spencer created a temporary private fork via the draft GitHub advisory and developed a PR with a fix using the `copy_from_upstream` patch mechanism.
+One of the reporters reviewed and approved the PR.
+The fix was merged into liboqs main branch on 21 November.
+Due to liboqs GitHub settings, the PR from the private fork could not be merged directly.
+It was necessary for an administrator (in this case, Ry Jones) to override these settings and commit to main.
+
+### 4. CVE assignment
+
+<!--
+Was a CVE assigned?
+If not, provide rationale.
+-->
+GitHub assigned CVE-2024-54137.
+
+### 5. Public disclosure
+
+<!--
+Provide details about public disclosures (e.g., release notes, emails) other than the GitHub Security Advisories already included in the "Information" section.
+-->
+The security advisory was published on 6 December.
+Version 0.12.0 of liboqs was released on 9 December, with a note about the vulnerability in its release notes: https://github.com/open-quantum-safe/liboqs/releases/tag/0.12.0
+
+Spencer submitted the fix to PQClean (https://github.com/PQClean/PQClean/pull/578) on 10 December.
+This led to a related security advisory being published for the pqcrypto Rust crate: https://github.com/PQClean/PQClean/security/advisories/GHSA-753p-wrj5-g8fj
+
+### 6. Feedback
+
+<!--
+Highlight any friction points in the response process.
+Feel free to provide suggestions to improve the process.
+Additionally, mention any follow-up work related to the vulnerability.
+-->
+
+We observed the following obstacles throughout the process:
+- Our initial response was very slow due to misconfiguration of GitHub notifications.
+  This has hopefully been amended.
+- Merging the patch required "admin"-level access on GitHub.
+  Based on GitHub logs, this seems to be due to liboqs settings requiring a pull request for all commits.
+  Apparently, a PR from a private fork does not count.

From 746fb6e38bb4f3a136dfca008c4c6025f3b3a348 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Fri, 3 Jan 2025 11:48:17 -0500
Subject: [PATCH 03/18] Add security response process

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 README.md                               |   4 +
 security/reports/20241220-hqc-decaps.md |   2 +-
 security/reports/YYYYMMDD-template.md   |   2 +-
 security/response-process.md            | 249 ++++++++++++++++++++++++
 4 files changed, 255 insertions(+), 2 deletions(-)
 create mode 100644 security/response-process.md

diff --git a/README.md b/README.md
index 48e6f4a..43096d1 100644
--- a/README.md
+++ b/README.md
@@ -57,3 +57,7 @@ Subscribe and access list archives at [https://lists.pqca.org/g/oqs-tsc](https:/
 ### Discord
 
 Join the [PQCA Discord server](https://discord.gg/gv8YN5bb) and reach us on the [#oqs-general](https://discordapp.com/channels/1202723482224295936/1203395992003678238) channel.
+
+## Security
+
+OQS responds to security reports following a [coordinated vulnerability disclosure process](security/response-process.md), informed by current Open Source Software Foundation [guidelines](https://github.com/ossf/oss-vulnerability-guide).
diff --git a/security/reports/20241220-hqc-decaps.md b/security/reports/20241220-hqc-decaps.md
index 5949096..f11ab07 100644
--- a/security/reports/20241220-hqc-decaps.md
+++ b/security/reports/20241220-hqc-decaps.md
@@ -1,4 +1,4 @@
-# OQS Vulnerability Response Report
+# OQS Vulnerability Response Report: 20241220-hqc-decaps
 
 <!--
 Copy this template and rename the file following the format YYYYMMDD-vulnerability-name.md format.
diff --git a/security/reports/YYYYMMDD-template.md b/security/reports/YYYYMMDD-template.md
index 785f53a..b031339 100644
--- a/security/reports/YYYYMMDD-template.md
+++ b/security/reports/YYYYMMDD-template.md
@@ -1,4 +1,4 @@
-# OQS Vulnerability Response Report
+# OQS Vulnerability Response Report: YYYY-MM-DD-vulnerability-name
 
 <!--
 Copy this template and rename the file following the format YYYYMMDD-vulnerability-name.md format.
diff --git a/security/response-process.md b/security/response-process.md
new file mode 100644
index 0000000..0c4f100
--- /dev/null
+++ b/security/response-process.md
@@ -0,0 +1,249 @@
+# Coordinated vulnerability disclosure process
+
+This document follows the framework and terminology from the OpenSSF's [`oss-vulnerability-guide`](https://github.com/ossf/oss-vulnerability-guide), with one additional step ("Feedback") added.
+
+## Vulnerability Management Team
+
+The Vulnerability Management Team (VMT) is responsible for responding to reports of security vulnerabilities in OQS software.
+
+### Members
+
+- Michael Baentsch (@baentsch, info@baentsch.ch)
+- Basil Hess (@bhess, BHE@zurich.ibm.com)
+- Brian Jarvis (@brian-jarvis-aws, brianjar@amazon.com)
+- Pravek Sharma (@praveksharma, pravek.sharma@uwaterloo.ca)
+- Douglas Stebila (@dstebila, dstebila@uwaterloo.ca)
+- Spencer Wilson (@SWilson4, spencer.wilson@uwaterloo.ca)
+
+This team is codified as `security-managers` in the [config.yaml](../config.yaml) file.
+
+### Coverage
+
+Members of the VMT take it in turns on to acknowledge and triage reports on a next-person-up basis, in the order listed here (which also happens to be alphabetical by last name).
+his ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
+Members of the VMT should inform the team when they will be unresponsive (e.g., on vacation or at a conference) for a week or more.
+
+> Example:
+Basil is the VMT member who most recently responded to a report.
+This means that Brian is "up next" and will be responsible for acknowledging the next report received.
+
+The member who acknowledges a report takes on the role of "[Quarterback](https://en.wikipedia.org/wiki/Quarterback)" for the issue.
+They will be responsible for managing the OQS response to the vulnerability report, as described below.
+
+COMMENT:
+Feel free to suggest an alternative to the American/Canadian football term "[quarterback](https://en.wikipedia.org/wiki/Quarterback)."
+
+COMMENT:
+As the supervisor/manager of two other members of the VMT (Pravek and Spencer), Douglas will be overseeing (directly or indirectly) half of the security reports received.
+Should he be exempt from rotating duty?
+
+## 1. Intake
+
+This phase begins when a vulnerability report is received.
+It ends when the report is acknowledged by a member of the VMT, who assumes the role of Quarterback for the issue.
+
+### External reports
+
+OQS provides reporters with three methods for reporting a vulnerability:
+1. Email to security@openquantumsafe.org.
+This email is an alias for the members of the VMT.
+2. GitHub security advisories (for liboqs and oqs-provider).
+These are submitted similarly to GitHub issues but are private.
+3. Encrypted email to dstebila@uwaterloo.ca.
+
+COMMENT:
+We should confirm that all of the members of the VMT
+(1) receive some sort of notification when a GitHub security advisory is filed on any OQS repo and (2) have the necessary permissions to view security advisories.
+
+COMMENT:
+Since liboqs-rust is published to crates.io, it should probably have security reporting switched on as well.
+
+When a report is received via one of the first two methods, the "up next" member of the VMT is responsible for acknowledging it promptly (the OSSF recommends within 1-2 days).
+- For email, this means responding to the reporter, cc'ing security@openquantumsafe.org.
+- For a GitHub security advisory (which will be in the "Triage" state), this means leaving a comment on the security advisory.
+
+No assessment of the report is necessary at this time.
+The purpose of the acknowledgement is to let the reporter(s) and the rest of the VMT know that the issue is being looked at.
+
+The responding VMT member assumes the role of Quarterback for the issue.
+
+Reports received via encrypted email may be more sensitive and will be handled on a case-by-case basis.
+
+> Example 1:
+A vulnerability report is received via email.
+Brian is "up next."
+He replies to the reporter(s) the next day, cc'ing security@openquantumsafe.org.
+Brian is now the Quarterback for the report.
+
+> Example 2:
+A GitHub security advisory is received.
+Pravek is "up next."
+He leaves a comment on the advisory the next day to acknowledge receipt of the report.
+Pravek is now the Quarterback for the report.
+
+COMMENT:
+Do we want to commit to a reponse timeline?
+
+### Internal reports
+
+Vulnerabilities may also be discovered internally by members of the OQS development team or regular contributors.
+For these reports, the Intake and Assessment phases may be streamlined at the discretion of the VMT.
+
+> Example 3:
+Michael receives an email from a former OQS developer advising him of a security issue in oqs-provider, including a patch.
+Michael immediately recognizes the issue as a vulnerability.
+Michael responds to the report, cc'ing security@openquantumsafe.org, and proceeds directly to the Patching phase.
+
+### Reports from other channels
+
+Reporters may not always follow instructions, and it is possible that security reports are received through other, non-endorsed channels (for example, email sent directly to a member of the VMT or a direct message on the PQCA discord).
+Such a report should be funnelled into one of the provided channels as the member of the VMT who first becomes aware of it sees fit.
+The focus should be on addressing the vulnerability report, not forcing the reporter(s) to resubmit via another channel.
+
+## 2. Assessment
+
+This phase begins when a vulnerability report is acknowledged by the VMT.
+It ends when the VMT responds to the reporter(s) with an assessment of the report.
+
+### Appointing a domain expert
+
+The Quarterback identifies the person or people who are most qualified to assess the report and, if necessary, develop a fix.
+The Quarterback provides them with all necessary information.
+These domain experts may not be members of the VMT, but they should be people whom the VMT trusts to handle security-related information.
+It is possible that the Quarterback will also be the team member who is most qualified to assess the issue. In this case, the Quarterback may request that the "up next" member of the VMT assume the role of Quarterback, allowing the original Quarterback to focus on the technical aspects of the response process.
+
+### Assessing the report
+
+The domain expert(s) assess the report and determine what action, if any, is required from OQS.
+If more information from the reporter(s) is needed, the Quarterback facilitates communication.
+The below table, indicating possible assessment outcomes, is copied from the [OSSF's vulnerability guide](https://github.com/ossf/oss-vulnerability-guide/blob/da8a22a1b09636c20a93fed58c1ba179557358d0/maintainer-guide.md), with the exception of the "Out of scope" lines, which are unique to OQS.
+
+| Assessment          | Response                                                                                                                                                                                                                                                                                                                                                               |
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Working as intended | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue. When responding with this assessment, you should explain why you arrived at this conclusion, in case the original report was unclear and the VMT has unintentionally misunderstood the original report. |
+| Bug                 | Let the reporter know this is unwanted behavior but not a security issue, and ask them to refile this as a bug. Close the security issue.                                                                                                                                                                                                                              |
+| Feature request     | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue.                                                                                                                                                                                                         |
+| Vulnerability       | Let the reporter know that you have confirmed this unwanted behavior creates a security issue. Proceed with the process.                                                                                                                                                                                                                                               |
+| Out of scope        | Let the reporter know that the issue lies in upstream code packaged by OQS. Assist them in refiling the report upstream. See the following section for further actions.                                                                                                                                                                                                  |
+
+#### "Out of scope" assessments
+
+OQS packages cryptographic algorithm implementations from a variety of upstream sources.
+These vary widely in level of support and software development expertise.
+OQS assumes no obligation to fix vulnerabilities in upstream code, but it may choose to do so on a best-effort basis.
+
+For all "out of scope" assessments, the vulnerability report should be passed on to the relevant upstream(s).
+Depending on the nature of the issue, additional action may be required.
+
+| "Out of scope" assessment | Description | Additional action |
+|------------------|----------|-|
+| Unable to assess | Assessing the issue requires domain knowledge about the upstream beyond that of the OQS VMT. | Monitor the upstream for resolution. |
+| Vulnerability: can patch  | The issue is indeed a vulnerability and can be simply and easily patched within OQS. | Decide whether or not to develop a patch. Coordinate disclosure with the upstream. |
+| Vulnerability: can't patch | The issue is indeed a vulnerability but cannot be simply and easily patched within OQS. | Coordinate disclosure with the upstream. Monitor the upstream for resolution. Depending on severity, consider dropping the upstream. |
+
+Decisions on whether or not to proceed with a possible patch should be made taking into account specifics of the upstream source.
+These include responsiveness to vulnerability reports and ability of the upstream maintainers to develop a patch.
+It is also important to consider the impact on end-users.
+A longer response time can be tolerated for an experimental algorithm than for a standardized or standard-track algorithm.
+For severe vulnerabilities which the upstream is unlikely to patch in a reasonable time frame, OQS may opt to drop support---temporarily or not---for algorithms affected by the vulnerability and publish a security advisory immediately.
+
+COMMENT:
+As a next step, we should compile a list of upstream contacts.
+
+#### Determining affected subprojects
+
+Part of the assessment should involve determining which subprojects are affected by the issue and how to fix the vulnerability throughout the OQS suite.
+
+### Responding to the reporter
+
+Once the evaluation process is complete, the Quarterback responds to the reporter(s) with the OQS assessment of the vulnerability.
+Regardless of the assessment outcome, the response should be courteous and thank the reporter(s) for filing the issue.
+If a patch is to be made, the reporter(s) should be offered the opportunity to review and/or contribute to the fix.
+
+COMMENT:
+Would a response template be helpful (and worth the time/effort to create)?
+
+### Assembling a response team
+
+If the reported issue is assessed as a vulnerability to be patched, the Quarterback will assemble a team to develop the fix.
+In addition to the patch developer(s), the team should involve at least two OQS developers with "write" permissions.
+This corresponds to the minimum approval requirements for liboqs PR merge.
+Additionally, the Quarterback should ensure that at least one person with GitHub admin privileges is aware of the issue and available, in order to resolve expediently any friction that may arise during the development process.
+
+Assembling the team can be done concurrently with the other steps in the Assessment phase.
+
+## 3. Patching
+
+This phase after the VMT has responded to the reporter(s) with an assessment of the report.
+It ends once a patch has been approved by the response team.
+
+This document deliberately does not refer to specific GitHub UI features in order to stay current in the event of a redesign.
+For these details, please see [GitHub's security advisory documentation](https://docs.github.com/en/code-security/security-advisories).
+
+### Preparing the security advisory
+
+The Quarterback creates a draft GitHub security advisory.
+If the vulnerability report was filed as a GitHub security advisory, this will involve simply changing the state of the advisory from "Triage" to "Draft."
+If the report was received via another source, a fresh security advisory will need to be created.
+All members of the response team should be added to the advisory as collaborators.
+The reporter(s) should also be added if they wish to be involved with patch development.
+
+### Patch development
+
+From the patch, the Quarterback creates a private fork specific to the security advisory.
+All members of the response team should be added to the fork, as well as the reporter(s) if they wish to be involved.
+From the private fork, the response team can create a pull request to fix the vulnerability.
+
+Development on the private fork proceeds more or less as on public OQS GitHub repos, with one notable exception:
+Due to current limitations on GitHub security advisories, the private fork will not have access to OQS CI.
+Therefore, thorough testing of the patch should be performed offline.
+The PR should be approved by
+- at least two members of the response team with write permissions for the affected repo and
+- if applicable, the reporter.
+
+After approval, commits on the PR should be squashed into one, as the "squash and merge" option is not currently available for security advisories.
+
+### Finalizing the security advisory
+
+Concurrently with patch development, the domain expert appointed by the Quarterback should finalize the text of the security advisory.
+This includes evaluating the vulnerability using the Common Vulnerability Scoring System.
+
+COMMENT:
+Would a security advisory template be helpful?
+
+## 4. CVE assignment
+
+This phase begins when the patch is approved and ends when a CVE is assigned by GitHub.
+
+Once the patch is ready for merge and the security advisory text is finalized, the Quarterback requests a CVE from GitHub.
+This can be done from within the draft security advisory.
+
+## 5. Public disclosure
+
+This phase begins after a CVE has been assigned by GitHub and ends when the security advisory has been published.
+
+Once a CVE has been assigned by GitHub, the following steps should be performed:
+- Merge the security advisory.
+Currently, this must be done by somebody with GitHub admin privileges.
+It may be necessary to override branch protections.
+- If necessary, prepare and publish a security release.
+- Add specifics about the patch to the security advisory text (commit hash and version information).
+- Publish the security advisory.
+
+The security advisory should be published only after the patch has been merged and, if applicable, a security release has been published.
+Whether or not a security release is required is left to the discretion of the VMT.
+
+COMMENT:
+Apart from publishing the security advisory, should we publicize the fix in any other way?
+
+## 6. Feedback
+
+COMMENT:
+This step is additional to the ones outlined by OSSF guidance.
+I thought it would help us to continuously revise the security process.
+
+This phase begins after the security advisory is published and ends when a security report is filed in the OQS TSC repository.
+
+The Quarterback files a report for the issue following the [Vulnerability Response Report Template](reports/YYYYMMDD-template.md).
+The report should highlight any friction or unexpected issues that arose in the response process.
+This step is optional if the work did not proceed past the "Assessment" phase.

From 108556131825cdb41f079104e786527bc1e7eed9 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Fri, 3 Jan 2025 16:12:21 -0500
Subject: [PATCH 04/18] Fix typo

Co-authored-by: Douglas Stebila <dstebila@users.noreply.github.com>
Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/response-process.md b/security/response-process.md
index 0c4f100..51b8381 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -20,7 +20,7 @@ This team is codified as `security-managers` in the [config.yaml](../config.yaml
 ### Coverage
 
 Members of the VMT take it in turns on to acknowledge and triage reports on a next-person-up basis, in the order listed here (which also happens to be alphabetical by last name).
-his ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
+This ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
 Members of the VMT should inform the team when they will be unresponsive (e.g., on vacation or at a conference) for a week or more.
 
 > Example:

From feed4620cf2c5a5473cf192b6608f1a536b7aa2e Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Fri, 3 Jan 2025 16:17:50 -0500
Subject: [PATCH 05/18] Remove comment

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index 51b8381..867a46d 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -33,10 +33,6 @@ They will be responsible for managing the OQS response to the vulnerability repo
 COMMENT:
 Feel free to suggest an alternative to the American/Canadian football term "[quarterback](https://en.wikipedia.org/wiki/Quarterback)."
 
-COMMENT:
-As the supervisor/manager of two other members of the VMT (Pravek and Spencer), Douglas will be overseeing (directly or indirectly) half of the security reports received.
-Should he be exempt from rotating duty?
-
 ## 1. Intake
 
 This phase begins when a vulnerability report is received.

From 72fd11efa70dfb2fa2a563512ca375b47c3a20bd Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Mon, 20 Jan 2025 15:05:01 -0500
Subject: [PATCH 06/18] Remove comments

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index 867a46d..e55e8dc 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -156,9 +156,6 @@ Once the evaluation process is complete, the Quarterback responds to the reporte
 Regardless of the assessment outcome, the response should be courteous and thank the reporter(s) for filing the issue.
 If a patch is to be made, the reporter(s) should be offered the opportunity to review and/or contribute to the fix.
 
-COMMENT:
-Would a response template be helpful (and worth the time/effort to create)?
-
 ### Assembling a response team
 
 If the reported issue is assessed as a vulnerability to be patched, the Quarterback will assemble a team to develop the fix.
@@ -204,9 +201,6 @@ After approval, commits on the PR should be squashed into one, as the "squash an
 Concurrently with patch development, the domain expert appointed by the Quarterback should finalize the text of the security advisory.
 This includes evaluating the vulnerability using the Common Vulnerability Scoring System.
 
-COMMENT:
-Would a security advisory template be helpful?
-
 ## 4. CVE assignment
 
 This phase begins when the patch is approved and ends when a CVE is assigned by GitHub.
@@ -234,10 +228,6 @@ Apart from publishing the security advisory, should we publicize the fix in any
 
 ## 6. Feedback
 
-COMMENT:
-This step is additional to the ones outlined by OSSF guidance.
-I thought it would help us to continuously revise the security process.
-
 This phase begins after the security advisory is published and ends when a security report is filed in the OQS TSC repository.
 
 The Quarterback files a report for the issue following the [Vulnerability Response Report Template](reports/YYYYMMDD-template.md).

From 93191dcc543c9bb8f7db4817b8e6e96b06d9a395 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Tue, 21 Jan 2025 10:36:46 -0500
Subject: [PATCH 07/18] Switch to five-week cadence

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index e55e8dc..90f2a22 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -19,20 +19,14 @@ This team is codified as `security-managers` in the [config.yaml](../config.yaml
 
 ### Coverage
 
-Members of the VMT take it in turns on to acknowledge and triage reports on a next-person-up basis, in the order listed here (which also happens to be alphabetical by last name).
-This ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
-Members of the VMT should inform the team when they will be unresponsive (e.g., on vacation or at a conference) for a week or more.
+Members of the VMT take it in turns to acknowledge and triage reports, rotating at each OQS Technical Steering Committee meeting, in the order listed here (which also happens to be alphabetical by last name).
+The "on-call" member of the VMT shall be confirmed and communicated at each TSC meeting.
+The above ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
+Members of the VMT agree to be available to support each other on short notice if the need arises (e.g., because of overload).
 
-> Example:
-Basil is the VMT member who most recently responded to a report.
-This means that Brian is "up next" and will be responsible for acknowledging the next report received.
-
-The member who acknowledges a report takes on the role of "[Quarterback](https://en.wikipedia.org/wiki/Quarterback)" for the issue.
+When acknowledging a report, the on-call VMT member takes on the role of "[Quarterback](https://en.wikipedia.org/wiki/Quarterback)" for the issue.
 They will be responsible for managing the OQS response to the vulnerability report, as described below.
 
-COMMENT:
-Feel free to suggest an alternative to the American/Canadian football term "[quarterback](https://en.wikipedia.org/wiki/Quarterback)."
-
 ## 1. Intake
 
 This phase begins when a vulnerability report is received.
@@ -54,7 +48,7 @@ We should confirm that all of the members of the VMT
 COMMENT:
 Since liboqs-rust is published to crates.io, it should probably have security reporting switched on as well.
 
-When a report is received via one of the first two methods, the "up next" member of the VMT is responsible for acknowledging it promptly (the OSSF recommends within 1-2 days).
+When a report is received via one of the first two methods, the "on call" member of the VMT is responsible for acknowledging it promptly (the OSSF recommends within 1-2 days).
 - For email, this means responding to the reporter, cc'ing security@openquantumsafe.org.
 - For a GitHub security advisory (which will be in the "Triage" state), this means leaving a comment on the security advisory.
 
@@ -67,13 +61,13 @@ Reports received via encrypted email may be more sensitive and will be handled o
 
 > Example 1:
 A vulnerability report is received via email.
-Brian is "up next."
+Brian is on call.
 He replies to the reporter(s) the next day, cc'ing security@openquantumsafe.org.
 Brian is now the Quarterback for the report.
 
 > Example 2:
 A GitHub security advisory is received.
-Pravek is "up next."
+Pravek is on call.
 He leaves a comment on the advisory the next day to acknowledge receipt of the report.
 Pravek is now the Quarterback for the report.
 
@@ -106,7 +100,7 @@ It ends when the VMT responds to the reporter(s) with an assessment of the repor
 The Quarterback identifies the person or people who are most qualified to assess the report and, if necessary, develop a fix.
 The Quarterback provides them with all necessary information.
 These domain experts may not be members of the VMT, but they should be people whom the VMT trusts to handle security-related information.
-It is possible that the Quarterback will also be the team member who is most qualified to assess the issue. In this case, the Quarterback may request that the "up next" member of the VMT assume the role of Quarterback, allowing the original Quarterback to focus on the technical aspects of the response process.
+It is possible that the Quarterback will also be the team member who is most qualified to assess the issue.
 
 ### Assessing the report
 

From 7b38c423277b4f5b09ef426c9fc5b53d74706e94 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Mon, 27 Jan 2025 14:27:22 -0500
Subject: [PATCH 08/18] Expand scope of "out of scope"

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/response-process.md b/security/response-process.md
index 90f2a22..385066f 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -114,7 +114,7 @@ The below table, indicating possible assessment outcomes, is copied from the [OS
 | Bug                 | Let the reporter know this is unwanted behavior but not a security issue, and ask them to refile this as a bug. Close the security issue.                                                                                                                                                                                                                              |
 | Feature request     | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue.                                                                                                                                                                                                         |
 | Vulnerability       | Let the reporter know that you have confirmed this unwanted behavior creates a security issue. Proceed with the process.                                                                                                                                                                                                                                               |
-| Out of scope        | Let the reporter know that the issue lies in upstream code packaged by OQS. Assist them in refiling the report upstream. See the following section for further actions.                                                                                                                                                                                                  |
+| Out of scope        | Let the reporter know that the issue is out of scope for OQS. If applicable, assist them in refiling the report upstream. See the following section for further actions.                                                                                                                                                                                                  |
 
 #### "Out of scope" assessments
 
@@ -127,6 +127,7 @@ Depending on the nature of the issue, additional action may be required.
 
 | "Out of scope" assessment | Description | Additional action |
 |------------------|----------|-|
+| Outside threat model | The issue lies outside the threat model of OQS. | Decide whether or not the severity of the issue warrants developing a patch irrespective of scope. |
 | Unable to assess | Assessing the issue requires domain knowledge about the upstream beyond that of the OQS VMT. | Monitor the upstream for resolution. |
 | Vulnerability: can patch  | The issue is indeed a vulnerability and can be simply and easily patched within OQS. | Decide whether or not to develop a patch. Coordinate disclosure with the upstream. |
 | Vulnerability: can't patch | The issue is indeed a vulnerability but cannot be simply and easily patched within OQS. | Coordinate disclosure with the upstream. Monitor the upstream for resolution. Depending on severity, consider dropping the upstream. |

From d833ed6c2735665a5a9db3484aec510a7066126e Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Mon, 27 Jan 2025 16:20:01 -0500
Subject: [PATCH 09/18] Proposed list of supported subprojects

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/security/response-process.md b/security/response-process.md
index 385066f..fb08686 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -2,6 +2,20 @@
 
 This document follows the framework and terminology from the OpenSSF's [`oss-vulnerability-guide`](https://github.com/ossf/oss-vulnerability-guide), with one additional step ("Feedback") added.
 
+## Scope
+
+This document applies to the following OQS subprojects:
+- liboqs,
+- liboqs-cpp,
+- liboqs-go,
+- liboqs-java,
+- liboqs-python,
+- liboqs-rust, and
+- oqs-provider.
+
+Other technical subprojects, such as the OQS fork of OpenSSH, are not considered to have security support.
+Subprojects may be added to or removed from this list in the future.
+
 ## Vulnerability Management Team
 
 The Vulnerability Management Team (VMT) is responsible for responding to reports of security vulnerabilities in OQS software.
@@ -143,7 +157,10 @@ As a next step, we should compile a list of upstream contacts.
 
 #### Determining affected subprojects
 
-Part of the assessment should involve determining which subprojects are affected by the issue and how to fix the vulnerability throughout the OQS suite.
+Part of the assessment should involve determining which subprojects are affected by the issue and how to fix the vulnerability throughout the OQS suite of [security-supported projects](#scope).
+Issues within liboqs, in particular, will impact almost every subproject.
+For every liboqs security advisory, advisories with the same CVE should be published on oqs-provider and the liboqs language wrappers instructing users to update the liboqs dependency.
+Additionally, since the [oqs Rust crate](https://crates.io/crates/oqs) installs a specific version of liboqs as part of its build process, every liboqs security release should have a corresponding liboqs-rust security release.
 
 ### Responding to the reporter
 

From 38eba8c8ad3d5dbac6645eb8ed894a7e3e605bd7 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Tue, 4 Feb 2025 08:28:18 -0500
Subject: [PATCH 10/18] * Remove remaining COMMENT blocks * Add security
 announcement mailing list

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index fb08686..feff94f 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -55,13 +55,6 @@ This email is an alias for the members of the VMT.
 These are submitted similarly to GitHub issues but are private.
 3. Encrypted email to dstebila@uwaterloo.ca.
 
-COMMENT:
-We should confirm that all of the members of the VMT
-(1) receive some sort of notification when a GitHub security advisory is filed on any OQS repo and (2) have the necessary permissions to view security advisories.
-
-COMMENT:
-Since liboqs-rust is published to crates.io, it should probably have security reporting switched on as well.
-
 When a report is received via one of the first two methods, the "on call" member of the VMT is responsible for acknowledging it promptly (the OSSF recommends within 1-2 days).
 - For email, this means responding to the reporter, cc'ing security@openquantumsafe.org.
 - For a GitHub security advisory (which will be in the "Triage" state), this means leaving a comment on the security advisory.
@@ -85,9 +78,6 @@ Pravek is on call.
 He leaves a comment on the advisory the next day to acknowledge receipt of the report.
 Pravek is now the Quarterback for the report.
 
-COMMENT:
-Do we want to commit to a reponse timeline?
-
 ### Internal reports
 
 Vulnerabilities may also be discovered internally by members of the OQS development team or regular contributors.
@@ -152,9 +142,6 @@ It is also important to consider the impact on end-users.
 A longer response time can be tolerated for an experimental algorithm than for a standardized or standard-track algorithm.
 For severe vulnerabilities which the upstream is unlikely to patch in a reasonable time frame, OQS may opt to drop support---temporarily or not---for algorithms affected by the vulnerability and publish a security advisory immediately.
 
-COMMENT:
-As a next step, we should compile a list of upstream contacts.
-
 #### Determining affected subprojects
 
 Part of the assessment should involve determining which subprojects are affected by the issue and how to fix the vulnerability throughout the OQS suite of [security-supported projects](#scope).
@@ -231,13 +218,11 @@ It may be necessary to override branch protections.
 - If necessary, prepare and publish a security release.
 - Add specifics about the patch to the security advisory text (commit hash and version information).
 - Publish the security advisory.
+- Publicize the security advisory via the oqs-security-announce@lists.pqca.org mailing list.
 
 The security advisory should be published only after the patch has been merged and, if applicable, a security release has been published.
 Whether or not a security release is required is left to the discretion of the VMT.
 
-COMMENT:
-Apart from publishing the security advisory, should we publicize the fix in any other way?
-
 ## 6. Feedback
 
 This phase begins after the security advisory is published and ends when a security report is filed in the OQS TSC repository.

From c86d39aff53bb08d3003272adf546baf34a31d2d Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Thu, 6 Feb 2025 12:07:19 -0500
Subject: [PATCH 11/18] Document addition/removal/absence processes

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/security/response-process.md b/security/response-process.md
index feff94f..0674d18 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -31,9 +31,14 @@ The Vulnerability Management Team (VMT) is responsible for responding to reports
 
 This team is codified as `security-managers` in the [config.yaml](../config.yaml) file.
 
+VMT members may be added or removed by the OQS TSC via its standard voting procedures.
+Members may voluntarily remove themselves from the VMT.
+Members may additionally declare absence for a period of time not exceeding one year, to be documented in this file.
+If a member's absence extends beyond one year, then that member shall be removed from the VMT.
+
 ### Coverage
 
-Members of the VMT take it in turns to acknowledge and triage reports, rotating at each OQS Technical Steering Committee meeting, in the order listed here (which also happens to be alphabetical by last name).
+Non-absent members of the VMT take it in turns to acknowledge and triage reports, rotating at each OQS Technical Steering Committee meeting, in the order listed here (which also happens to be alphabetical by last name).
 The "on-call" member of the VMT shall be confirmed and communicated at each TSC meeting.
 The above ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
 Members of the VMT agree to be available to support each other on short notice if the need arises (e.g., because of overload).

From 8e4e6beaec9b36eaae2ad9a4d623edfec521d9fa Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Thu, 13 Feb 2025 11:16:57 -0500
Subject: [PATCH 12/18] Refine scope

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index 0674d18..a001406 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -4,8 +4,11 @@ This document follows the framework and terminology from the OpenSSF's [`oss-vul
 
 ## Scope
 
-This document applies to the following OQS subprojects:
-- liboqs,
+This document applies **only** to vulnerabilities found in liboqs.
+Other OQS subprojects are not considered to have security support, although vulnerabilities may still be addressed on a best-effort basis.
+
+The OQS OpenSSL 3 provider and the liboqs language wrappers will be kept up to date with liboqs security releases.
+Concretely, these consist of
 - liboqs-cpp,
 - liboqs-go,
 - liboqs-java,
@@ -13,8 +16,10 @@ This document applies to the following OQS subprojects:
 - liboqs-rust, and
 - oqs-provider.
 
-Other technical subprojects, such as the OQS fork of OpenSSH, are not considered to have security support.
-Subprojects may be added to or removed from this list in the future.
+Other technical subprojects, such as the OQS fork of OpenSSH, do not have security support and will only be updated on a best-effort basis.
+
+This document was initially accepted on *TODO: add date before merge*.
+It does not apply to versions of OQS projects released before this date.
 
 ## Vulnerability Management Team
 
@@ -56,7 +61,7 @@ It ends when the report is acknowledged by a member of the VMT, who assumes the
 OQS provides reporters with three methods for reporting a vulnerability:
 1. Email to security@openquantumsafe.org.
 This email is an alias for the members of the VMT.
-2. GitHub security advisories (for liboqs and oqs-provider).
+2. GitHub security advisories.
 These are submitted similarly to GitHub issues but are private.
 3. Encrypted email to dstebila@uwaterloo.ca.
 
@@ -129,14 +134,16 @@ The below table, indicating possible assessment outcomes, is copied from the [OS
 
 OQS packages cryptographic algorithm implementations from a variety of upstream sources.
 These vary widely in level of support and software development expertise.
-OQS assumes no obligation to fix vulnerabilities in upstream code, but it may choose to do so on a best-effort basis.
+OQS assumes no obligation to fix vulnerabilities in upstream code, but may choose to do so on a best-effort basis.
+Similarly, OQS may fix vulnerabilties in its own projects without security support on a best-effort basis.
 
-For all "out of scope" assessments, the vulnerability report should be passed on to the relevant upstream(s).
+For all "out of scope" assessments involving upstream code, the vulnerability report should be passed on to the relevant upstream(s).
 Depending on the nature of the issue, additional action may be required.
 
 | "Out of scope" assessment | Description | Additional action |
 |------------------|----------|-|
 | Outside threat model | The issue lies outside the threat model of OQS. | Decide whether or not the severity of the issue warrants developing a patch irrespective of scope. |
+| Unsupported project | The issue lies in an OQS subproject that does not have security support. | Decide whether or not the issue warrants developing a patch irrespective of scope. If not, document the issue in the affected subproject. |
 | Unable to assess | Assessing the issue requires domain knowledge about the upstream beyond that of the OQS VMT. | Monitor the upstream for resolution. |
 | Vulnerability: can patch  | The issue is indeed a vulnerability and can be simply and easily patched within OQS. | Decide whether or not to develop a patch. Coordinate disclosure with the upstream. |
 | Vulnerability: can't patch | The issue is indeed a vulnerability but cannot be simply and easily patched within OQS. | Coordinate disclosure with the upstream. Monitor the upstream for resolution. Depending on severity, consider dropping the upstream. |
@@ -147,13 +154,6 @@ It is also important to consider the impact on end-users.
 A longer response time can be tolerated for an experimental algorithm than for a standardized or standard-track algorithm.
 For severe vulnerabilities which the upstream is unlikely to patch in a reasonable time frame, OQS may opt to drop support---temporarily or not---for algorithms affected by the vulnerability and publish a security advisory immediately.
 
-#### Determining affected subprojects
-
-Part of the assessment should involve determining which subprojects are affected by the issue and how to fix the vulnerability throughout the OQS suite of [security-supported projects](#scope).
-Issues within liboqs, in particular, will impact almost every subproject.
-For every liboqs security advisory, advisories with the same CVE should be published on oqs-provider and the liboqs language wrappers instructing users to update the liboqs dependency.
-Additionally, since the [oqs Rust crate](https://crates.io/crates/oqs) installs a specific version of liboqs as part of its build process, every liboqs security release should have a corresponding liboqs-rust security release.
-
 ### Responding to the reporter
 
 Once the evaluation process is complete, the Quarterback responds to the reporter(s) with the OQS assessment of the vulnerability.
@@ -228,6 +228,9 @@ It may be necessary to override branch protections.
 The security advisory should be published only after the patch has been merged and, if applicable, a security release has been published.
 Whether or not a security release is required is left to the discretion of the VMT.
 
+For every liboqs security advisory and release, advisories and releases using the same CVE should be published on oqs-provider and the liboqs language wrappers.
+Additionally, since the [oqs Rust crate](https://crates.io/crates/oqs) installs a specific version of liboqs as part of its build process, a new version should be pushed to Crates.io whenever a security release of liboqs is made.
+
 ## 6. Feedback
 
 This phase begins after the security advisory is published and ends when a security report is filed in the OQS TSC repository.

From 55fd07d7d67fd0e39b73242a5157a441b4912dfc Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Fri, 14 Feb 2025 16:48:19 -0500
Subject: [PATCH 13/18] Add detail about offline testing

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/security/response-process.md b/security/response-process.md
index a001406..d8ed8fb 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -194,6 +194,8 @@ From the private fork, the response team can create a pull request to fix the vu
 Development on the private fork proceeds more or less as on public OQS GitHub repos, with one notable exception:
 Due to current limitations on GitHub security advisories, the private fork will not have access to OQS CI.
 Therefore, thorough testing of the patch should be performed offline.
+The patch has to pass all CI tests for [Tier 1 platforms](https://github.com/open-quantum-safe/liboqs/blob/main/PLATFORMS.md#tier-1-1) and lower-tier platforms explicitly affected by the issue in local execution.
+If possible, a new test demonstrating absence of the faulty behaviour fixed by the patch should be added.
 The PR should be approved by
 - at least two members of the response team with write permissions for the affected repo and
 - if applicable, the reporter.

From 2fd2869641a7af6f46d36a2f4a8dc77c4cac95d7 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Fri, 14 Feb 2025 16:52:19 -0500
Subject: [PATCH 14/18] References to SECURITY.md and README

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/security/response-process.md b/security/response-process.md
index d8ed8fb..b6a9522 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -21,6 +21,9 @@ Other technical subprojects, such as the OQS fork of OpenSSH, do not have securi
 This document was initially accepted on *TODO: add date before merge*.
 It does not apply to versions of OQS projects released before this date.
 
+In the future, the scope of this document may be expanded to include other OQS subprojects.
+All subprojects included in its scope should reference this document in a SECURITY.md file, which in turn should file should be referenced in the subproject README.
+
 ## Vulnerability Management Team
 
 The Vulnerability Management Team (VMT) is responsible for responding to reports of security vulnerabilities in OQS software.

From 34daaa943caabda3e17c514f6875b1a4cc660769 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Thu, 20 Feb 2025 16:21:38 -0500
Subject: [PATCH 15/18] Include platform support details

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/security/response-process.md b/security/response-process.md
index b6a9522..a14053b 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -22,7 +22,8 @@ This document was initially accepted on *TODO: add date before merge*.
 It does not apply to versions of OQS projects released before this date.
 
 In the future, the scope of this document may be expanded to include other OQS subprojects.
-All subprojects included in its scope should reference this document in a SECURITY.md file, which in turn should file should be referenced in the subproject README.
+All subprojects included in its scope should reference this document in a SECURITY.md file, which in turn should be referenced in the subproject README.
+They should include platform support documentation following the model of the liboqs [PLATFORMS.md](https://github.com/open-quantum-safe/liboqs/blob/main/PLATFORMS.md) file, which should include details about platform-specific security support priorities.
 
 ## Vulnerability Management Team
 
@@ -205,6 +206,9 @@ The PR should be approved by
 
 After approval, commits on the PR should be squashed into one, as the "squash and merge" option is not currently available for security advisories.
 
+In the event that tests do not pass for a lower-tier platform, the VMT may decide to drop support for the platform, temporarily or not, in the interest of an expedient security release for Tier 1 platforms.
+This decision should take into account the severity of the issue as well as the estimated time and effort to fix the patch for the lower-tier platform.
+
 ### Finalizing the security advisory
 
 Concurrently with patch development, the domain expert appointed by the Quarterback should finalize the text of the security advisory.

From 4f55b31296f802ad9418c30b4aea74f4179b6967 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Tue, 25 Feb 2025 09:29:32 -0500
Subject: [PATCH 16/18] Expand on security releases for downstream subprojects

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index a14053b..2a0220f 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -7,8 +7,13 @@ This document follows the framework and terminology from the OpenSSF's [`oss-vul
 This document applies **only** to vulnerabilities found in liboqs.
 Other OQS subprojects are not considered to have security support, although vulnerabilities may still be addressed on a best-effort basis.
 
-The OQS OpenSSL 3 provider and the liboqs language wrappers will be kept up to date with liboqs security releases.
-Concretely, these consist of
+The OQS OpenSSL 3 provider and the liboqs language wrappers will retain build support against liboqs versions tagged as being "Supported" in the [liboqs SECURITY.md](https://github.com/open-quantum-safe/liboqs/blob/main/SECURITY.md).
+This is to facilitate potentially required consequent security release of those sub projects against those downlevel liboqs codebases receiving a security update.
+In addition, all "main" branches of all sub projects listed below also will be kept up to date with the "main" branch of liboqs such as to ensure security updates landing there can immediately be used in those sub projects, also allowing a release in lock-step with a liboqs (security) release.
+Therefore, if a security release of any or all of the sub projects listed below is deemed required, it can be done by anybody with the required GH permissions, not requiring any development effort.
+Therefore, such "consequent" releases can and will be done at the same time as the liboqs security release.
+
+Concretely, the OQS OpenSSL 3 provider and the liboqs language wrappers consist of
 - liboqs-cpp,
 - liboqs-go,
 - liboqs-java,

From 6f9a01be5c5e8359d02d76ba4f72747e9f2d25fd Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Tue, 25 Feb 2025 10:58:49 -0500
Subject: [PATCH 17/18] Address comments

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index 2a0220f..cff9e49 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -103,7 +103,7 @@ Vulnerabilities may also be discovered internally by members of the OQS developm
 For these reports, the Intake and Assessment phases may be streamlined at the discretion of the VMT.
 
 > Example 3:
-Michael receives an email from a former OQS developer advising him of a security issue in oqs-provider, including a patch.
+Michael receives an email from a former OQS developer advising him of a security issue in liboqs, including a patch.
 Michael immediately recognizes the issue as a vulnerability.
 Michael responds to the report, cc'ing security@openquantumsafe.org, and proceeds directly to the Patching phase.
 
@@ -122,7 +122,7 @@ It ends when the VMT responds to the reporter(s) with an assessment of the repor
 
 The Quarterback identifies the person or people who are most qualified to assess the report and, if necessary, develop a fix.
 The Quarterback provides them with all necessary information.
-These domain experts may not be members of the VMT, but they should be people whom the VMT trusts to handle security-related information.
+These domain experts may or may not be members of the VMT, but they should be people whom the VMT trusts to handle security-related information.
 It is possible that the Quarterback will also be the team member who is most qualified to assess the issue.
 
 ### Assessing the report
@@ -133,10 +133,10 @@ The below table, indicating possible assessment outcomes, is copied from the [OS
 
 | Assessment          | Response                                                                                                                                                                                                                                                                                                                                                               |
 | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Working as intended | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue. When responding with this assessment, you should explain why you arrived at this conclusion, in case the original report was unclear and the VMT has unintentionally misunderstood the original report. |
+| Working as intended | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue. When responding with this assessment, the VMT responder should explain why this conclusion was reached, in case the original report was unclear and the VMT has unintentionally misunderstood the original report. |
 | Bug                 | Let the reporter know this is unwanted behavior but not a security issue, and ask them to refile this as a bug. Close the security issue.                                                                                                                                                                                                                              |
 | Feature request     | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue.                                                                                                                                                                                                         |
-| Vulnerability       | Let the reporter know that you have confirmed this unwanted behavior creates a security issue. Proceed with the process.                                                                                                                                                                                                                                               |
+| Vulnerability       | Let the reporter know that the VMT has confirmed this unwanted behavior creates a security issue. Proceed with the process.                                                                                                                                                                                                                                               |
 | Out of scope        | Let the reporter know that the issue is out of scope for OQS. If applicable, assist them in refiling the report upstream. See the following section for further actions.                                                                                                                                                                                                  |
 
 #### "Out of scope" assessments
@@ -180,7 +180,7 @@ Assembling the team can be done concurrently with the other steps in the Assessm
 
 ## 3. Patching
 
-This phase after the VMT has responded to the reporter(s) with an assessment of the report.
+This phase begins after the VMT has responded to the reporter(s) with an assessment of the report.
 It ends once a patch has been approved by the response team.
 
 This document deliberately does not refer to specific GitHub UI features in order to stay current in the event of a redesign.

From 3b616165bab37c49915280abeb947642c81f7324 Mon Sep 17 00:00:00 2001
From: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Date: Thu, 27 Feb 2025 12:55:45 -0500
Subject: [PATCH 18/18] Address feedback from Basil, Brian, and Michael

Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
---
 security/response-process.md | 29 +++++++++++------------------
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/security/response-process.md b/security/response-process.md
index cff9e49..b50faab 100644
--- a/security/response-process.md
+++ b/security/response-process.md
@@ -36,23 +36,16 @@ The Vulnerability Management Team (VMT) is responsible for responding to reports
 
 ### Members
 
-- Michael Baentsch (@baentsch, info@baentsch.ch)
-- Basil Hess (@bhess, BHE@zurich.ibm.com)
-- Brian Jarvis (@brian-jarvis-aws, brianjar@amazon.com)
-- Pravek Sharma (@praveksharma, pravek.sharma@uwaterloo.ca)
-- Douglas Stebila (@dstebila, dstebila@uwaterloo.ca)
-- Spencer Wilson (@SWilson4, spencer.wilson@uwaterloo.ca)
-
-This team is codified as `security-managers` in the [config.yaml](../config.yaml) file.
+VMT membership is codified as `security-managers` in the [config.yaml](../config.yaml) file.
 
 VMT members may be added or removed by the OQS TSC via its standard voting procedures.
 Members may voluntarily remove themselves from the VMT.
-Members may additionally declare absence for a period of time not exceeding one year, to be documented in this file.
+Members may additionally declare absence for a period of time not exceeding one year.
 If a member's absence extends beyond one year, then that member shall be removed from the VMT.
 
 ### Coverage
 
-Non-absent members of the VMT take it in turns to acknowledge and triage reports, rotating at each OQS Technical Steering Committee meeting, in the order listed here (which also happens to be alphabetical by last name).
+Active members of the VMT take it in turns to acknowledge and triage reports, rotating at each OQS Technical Steering Committee meeting, in the order listed here (which also happens to be alphabetical by last name).
 The "on-call" member of the VMT shall be confirmed and communicated at each TSC meeting.
 The above ordering is intended as an aid in staying organized but may be adjusted by the VMT as circumstances dictate---the important thing is to ensure coverage at all times.
 Members of the VMT agree to be available to support each other on short notice if the need arises (e.g., because of overload).
@@ -67,22 +60,19 @@ It ends when the report is acknowledged by a member of the VMT, who assumes the
 
 ### External reports
 
-OQS provides reporters with three methods for reporting a vulnerability:
+OQS provides reporters with two methods for reporting a vulnerability:
 1. Email to security@openquantumsafe.org.
 This email is an alias for the members of the VMT.
 2. GitHub security advisories.
 These are submitted similarly to GitHub issues but are private.
-3. Encrypted email to dstebila@uwaterloo.ca.
 
-When a report is received via one of the first two methods, the "on call" member of the VMT is responsible for acknowledging it promptly (the OSSF recommends within 1-2 days).
+When a report is received, the "on call" member of the VMT is responsible for acknowledging it promptly (the OSSF recommends within 1-2 days).
 - For email, this means responding to the reporter, cc'ing security@openquantumsafe.org.
 - For a GitHub security advisory (which will be in the "Triage" state), this means leaving a comment on the security advisory.
 
 No assessment of the report is necessary at this time.
 The purpose of the acknowledgement is to let the reporter(s) and the rest of the VMT know that the issue is being looked at.
 
-The responding VMT member assumes the role of Quarterback for the issue.
-
 Reports received via encrypted email may be more sensitive and will be handled on a case-by-case basis.
 
 > Example 1:
@@ -133,7 +123,7 @@ The below table, indicating possible assessment outcomes, is copied from the [OS
 
 | Assessment          | Response                                                                                                                                                                                                                                                                                                                                                               |
 | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Working as intended | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue. When responding with this assessment, the VMT responder should explain why this conclusion was reached, in case the original report was unclear and the VMT has unintentionally misunderstood the original report. |
+| Working as intended | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue. When responding with this assessment, the Quarterback should explain why this conclusion was reached, in case the original report was unclear and the VMT has unintentionally misunderstood the original report. |
 | Bug                 | Let the reporter know this is unwanted behavior but not a security issue, and ask them to refile this as a bug. Close the security issue.                                                                                                                                                                                                                              |
 | Feature request     | Let the reporter know this is the intended behavior. If they think this behavior could be improved, they can file a feature request. Close the security issue.                                                                                                                                                                                                         |
 | Vulnerability       | Let the reporter know that the VMT has confirmed this unwanted behavior creates a security issue. Proceed with the process.                                                                                                                                                                                                                                               |
@@ -149,6 +139,8 @@ Similarly, OQS may fix vulnerabilties in its own projects without security suppo
 For all "out of scope" assessments involving upstream code, the vulnerability report should be passed on to the relevant upstream(s).
 Depending on the nature of the issue, additional action may be required.
 
+In the event that OQS patches code sources from an upstream but the upstream itself remains unfixed, the published security advisory should include a warning to this effect.
+
 | "Out of scope" assessment | Description | Additional action |
 |------------------|----------|-|
 | Outside threat model | The issue lies outside the threat model of OQS. | Decide whether or not the severity of the issue warrants developing a patch irrespective of scope. |
@@ -242,8 +234,9 @@ It may be necessary to override branch protections.
 The security advisory should be published only after the patch has been merged and, if applicable, a security release has been published.
 Whether or not a security release is required is left to the discretion of the VMT.
 
-For every liboqs security advisory and release, advisories and releases using the same CVE should be published on oqs-provider and the liboqs language wrappers.
-Additionally, since the [oqs Rust crate](https://crates.io/crates/oqs) installs a specific version of liboqs as part of its build process, a new version should be pushed to Crates.io whenever a security release of liboqs is made.
+For every liboqs security advisory and release, advisories using the same CVE should be published on oqs-provider and the liboqs language wrappers.
+Whether or not security releases are warranted for oqs-provider and the language wrappers is at the discretion of the VMT, with one exception:
+Since the oqs Rust crate installs a specific version of liboqs as part of its build process, a new version of liboqs-rust must be released and published to Crates.io.
 
 ## 6. Feedback