Merge openenclave#3709

3709: Update SecurityAdvisoryHandling.md based on feedback r=CodeMonkeyLeet a=CodeMonkeyLeet Incorporate comments from @markg-intel in openenclave#3556 Signed-off-by: Simon Leet <[email protected]> Co-authored-by: Simon Leet <[email protected]>
BRMcLaren · Nov 5, 2020 · 76a5ca5 · 76a5ca5
2 parents 54da837 + cff3e88
commit 76a5ca5
Showing 1 changed file with 10 additions and 3 deletions.
diff --git a/docs/Community/SecurityAdvisoryHandling.md b/docs/Community/SecurityAdvisoryHandling.md
@@ -38,7 +38,7 @@ If OE SDK needs to issue a Security Advisory to address the reported concern, on
 1. [Create](https://docs.github.com/en/github/managing-security-vulnerabilities/creating-a-security-advisory#creating-a-security-advisory)
    a new GitHub [Security Advisory (SA) for OE SDK](https://github.com/openenclave/openenclave/security/advisories).
    1. The description of the SA should accurately capture the nature, severity, and workarounds for the issue.
-      1. It does not need to capture the full technical details of the vulnerability or fix for brevity.
+      1. For brevity, the SA does not need to capture the full technical details of the vulnerability or fix.
 2. [Request a Common Vulnerability Enumeration (CVE)](https://docs.github.com/en/github/managing-security-vulnerabilities/publishing-a-security-advisory#requesting-a-cve-identification-number) through GitHub.
    1. This was previously done through MSRC as a CVE Numbering Authority (CNA), but OE has shifted to using GitHub as the CNA as a Linux Foundation project.
 3. [Assign the appropriate collaborators](https://docs.github.com/en/github/managing-security-vulnerabilities/adding-a-collaborator-to-a-security-advisory) to the SA, which includes:
@@ -49,6 +49,7 @@ If OE SDK needs to issue a Security Advisory to address the reported concern, on
    to implement the code changes as part of the SA.
    1. The assignee should follow the GitHub instructions and create an `advisory-fix` branch for their code changes.
       1. The code changes should include an update to [CHANGELOG.md](/CHANGELOG.md) under the `### Security` subheader describing the issue addressed.
+      2. The description should include a link to the GitHub SA, which includes a pointer to the CVE as well.
    2. Once the changes are ready for review, they should be submitted as a PR to the master branch of the temporary fork.
       1. GitHub does not currently appear to support requiring PR reviews to merge into the master branch of a temporary fork, so maintainers will need to enforce this process manually.
 5. Reach out to the CI/CD maintainers to establish a private CI/CD pipeline for testing code changes.
@@ -74,10 +75,16 @@ The Open Enclave SDK project currently relies on the principles for [Coordinated
 The CVD includes a couple of policies such as:
 
 - acknowledgment of vulnerability reports within 24 hours (via MSRC)
-- supporting public disclosure within 90 days as the baseline, and negotiating that with vulnerability reporters and necessary
+- supporting public disclosure within 90 days as the baseline and negotiating the date with vulnerability reporters and necessary parties, including the engineering teams and affected vendors.
+
+While the primary goal of CVD is to avoid disclosure before a fix is released, the OE SDK security reviewers will also work to
+accommodate the reporter's preferences on the timing for disclosing and fixing the vulnerability. For example, if a researcher
+believes that releasing the fix far ahead of their disclosure publication or presentation diminishes the impact of their work, the
+security reviewers will work with them to determine the best course of action, such as releasing the fix on the same day as their
+planned disclosure event.
 
 > - [ ] TODO: Establish a process and acceptance criteria for registering with OE SDK as a _Trusted Stakeholder_.
->   - A Trusted Stakeholder may not be a committer or maintainer of the SDK, but has a vested interest in the security of the OE SDK.
+>   - A Trusted Stakeholder need not be a committer or maintainer of the SDK but can be anyone with a vested interest in the security of the OE SDK.
 >     - For example, an enterprise with significant production deployments on OE SDK, a TEE-provider, or other software projects with critical integrations with OE SDK.
 >   - The goal is to enable OE SDK to disclose issues material to their interests privately and allow them to participate in testing and provide feedback.
 >   - We would need to figure out the legal concerns around GDPR and NDAs involved in maintaining such a list.