diff --git a/CVD_Guide/detailed_CVD_guide.md b/CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md similarity index 72% rename from CVD_Guide/detailed_CVD_guide.md rename to CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md index 58c5dbc..df06ade 100644 --- a/CVD_Guide/detailed_CVD_guide.md +++ b/CVD_Guide/CVD-Step-by-Step-Runbook-and-Guide.md @@ -1,217 +1,123 @@ -# OpenJS Project Recommended Coordinated Vulnerability Disclosure (CVD) Runbook Guide and Templates for Medium and Large Teams +# Coordinated Vulnerability Disclosure (CVD) Step-by-Step Runbook Guide for Teams # Purpose and Scope -### When to use this Runbook +### When to use this Guide -This runbook template is a step-by-step guide for use by OpenJS Projects with medium and large maintainer teams when responding to properly and improperly disclosed security vulnerabilities that may be directly or indirectly related to their Project(s). - -This runbook is designed to support OpenJS Projects in mundane and intense CVD scenarios. It assumes limited exposure or experience working with a mature Bug Bounty Team, Product Security Incident Response Team (PSIRT), or Security Advisory Team. - -A modified version of this runbook tailored to Projects with solo maintainers and small teams is also available and can be found [here]. +This step-by-step runbook guide is designed for those with limited exposure and experience working with coordinated vulnerability disclosure. The approach taken with this guide can be quite heavy and is designed for Projects with medium and large maintainer teams responding to external security vulnerability disclosures. ### When this Runbook Should Not be Used -Please be mindful that this runbook IS NOT an incident response plan and that the word incident is found only in the Purpose and Scope section of this document. That said, this runbook does contain guidance on handling scenarios many may call incidents, but avoids using the term as it has become increasingly regulated and legally nuanced. - -This runbook uses the term SEV to describe extreme vulnerability mitigation and remediation scenarios like the one above in order to differentiate them from incidents, which per the [U.S. Federal Incident Notification Guidelines](https://www.cisa.gov/federal-incident-notification-guidelines), would be occurrences when the vulnerability is exploited and potentially compromises the confidentiality, integrity, and availability of a system. - -Thus, unlike an Incident Response Plan, this runbook does not provide guidance on how to handle scenarios when there is concern or evidence of compromise of an OpenJS Project’s infrastructure, tools, source code, communications, or devices (eg: maintainer workstations). +Please be mindful that this runbook IS NOT an incident response plan. Unlike an Incident Response Plan, this runbook does not provide guidance on how to handle scenarios when there is concern or evidence of compromise of an Project’s infrastructure, tools, source code, communications, or maintainer devices. # How to use this Runbook +## Take it Step by Step -## Researcher Communications Primer - -Proactively working to make a good impression in all communications with Reporters/Security Researchers is the key to your success. Each message is an opportunity to establish your Project's reputation in the security community and to potentially gain a recurring reporter that helps improve the security posture of your Project. - -But be mindful of the negotiation-like dynamics that can occur between Bug Bounty and CVD Program operators and the security research community, particularly with high impact vulnerabilities. - -#### Communicate with Empathy - -Hostile and unprofessional behaviors by Program operators are far less common and egregious than they once were. However, disrepectful treatment continues to be a common experience for ethical security researchers working in good faith when disclosing security vulnerabilities. +Recommendation: Folow the steps in order. Steps are written with the assumption of knowledge being available after the completion of previous steps. Steps that can or should happen in parallel to each other are identified and also have supporting guidance. -Be mindful of these experiences and what others may - in good or bad faith - interpret as dismissiveness or a lack of urgency whenever making decisions and communicating those decisions with a security researcher. +## Associated Resources -#### Communicate with Situational Awareness +This guide is meant to be used in conjunction with: -At the same time, Bug Bounty and CVD Program operators unfortunately continue to struggle with erroneous and irrelevant disclosures from hostile and publicity seeking individuals demanding recognition for their research. +* [TEMPLATE Step-by-Step CVD Guide Checklist](https://../TEMPLATE-CVD-Step-by-Step-Runbook-Checklist.md) +* [Researcher Communications Templates](https://../Researcher-Communications.Primer.md) -The best defense against these actors is to explain your decisions clearly and include supporting facts in all communications and professionally requesting the same from them. If there is ever disagreement on the validity, severity/impact, or exploitability of a security vulnerability, leave nothing to assumption and explicitly state (and continue to re-state if mentioned in a previous comm) the data underlying your rationale. +# Roles and Responsibilities -### Understanding Researcher Assertions on Severity and Impact +Besides the On Call Role, this runbook uses the roles defined the GitHub Private Vulnerability Reporting (PVR) [documentation](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory#about-credits-for-repository-security-advisories). -researcher assertions on Impact and Scope often need to be adjusted for reasons beyond their control: +* Finder +* Reporter +* On Call +* Triage Analyst +* Coordinator +* Remediation Developer +* Remediation Reviewer +* Remediation Verifier -#### Researchers Don't Live Your Software Like You Do -Although there are exceptions, one should expect that researchers who submit security vulnerabilities to Bug Bounty and CVD Programs are not as knowledgable on the software they're testing as the software engineers who wrote it. +## Introduced in Phase 0: Report Submission -#### Bug Hunting is a Different Skill Set -The technical skills needed to be a successful bug hunter/pen tester do not fully overlap with those of software engineers building open source and enterprise software. +### Responsibilities: Finder -While it's more common for Reporters to over-state the impact of their vulnerability for the sake of higher bounties and self-promotion, it's also not uncommon for researchers to unknowingly understate and miss the true scope and impact of their vulnerability. +* Identifies the security vulnerability -## Take it Step by Step +### Responsibilities: Reporter -This Runbook is written as a step-by-step checklist with guidance to support you along the way. - -It is recommended that steps be taken in order as certain steps are written with the assumption of knowledge being available after the completion of previous steps. Steps that can or should happen in parallel to each other are identified and also have supporting guidance - -# How to use this Checklist Template - -This checklist lists all of the steps found in the below Runbook and is designed with GitHub's Tasklist feature for when used as a template for a GitHub issue. You can use this template to provide visibility into which Step the Report is currently in and stay aware of the upcoming Steps. - ->[!TIP] ->In several Steps (eg: 2, 5, 11), you'll only use one of the available sub-Steps. Be sure to remove the other sub-steps to shorten the length of the checklist and only see which steps were followed! - -## Phase 0: Report Submission - -- [ ] **1. The Reporter submits a potential security concern or vulnerability** - - [ ] 1a. Optional: Reporter creates a temporary private fork (if they want to) - -## Phase 1: Tier 1 Triage - -- [ ] **2. On Call Performs Tier 1 Triage and Drafts an Initial Acknowledgement** - - [ ] 2a. Security Escalation Criteria - - [ ] 2b. Need More Information? - - [ ] 2c. Not a security vulnerability Report? - - [ ] 2d. Abuse Escalation Criteria - - [ ] 2e. Routine security vulnerability Report -- [ ] **3. On Call Begins Organizing Internal Discussion by Creating a Tracking Discussion for the Vulnerability** -- [ ] **4. On Call Drafts a Tier 1 Summary** -- [ ] **5. On Call Sends the Reporter an Initial Acknowledgement of Receipt** - - [ ] 5a. If the Report meets Security Escalation Criteria - - [ ] 5b. If the Report Appears to be Missing Basic Information - - [ ] 5c. If the Report Appears to be a Valid and Routine - - [ ] 5d. If the Report is not a Security Vulnerability - -## Phase 2: Tier 2 Triage - -- [ ] **6. Assign Tier 2 Triage Roles** -- [ ] **7. Triage Analyst Attempts to Reproduce the Vulnerability as Reported** -- [ ] **8. Coordinator Notifies Reporter of Reproduction Progress** - - [ ] 8a. First Notification: Unable to Reproduce / NMI - - [ ] 8b. Second/Ongoing Comms: Still Unable to Reproduce - - [ ] 8c. Notification: Successful Reproduction -- [ ] **9. Triage Analyst Performs Tier 2 Triage** - - [ ] 9a. Identify and Document True Root Cause(s) - - [ ] 9b. Assess and Document Impact and Exploitability - - [ ] 9c. Document Initial Mitigation/Remediation Options -- [ ] **10. Coordinator Facilitates Consensus Building Discussions** - - [ ] 10a. Reach Technical Consensus on Tier 2 Triage - - [ ] 10b. Agree to Completely Remediate the Vulnerability - - [ ] 10c. Assign Remediation Roles and Agree on Mitigation/Remediation Next Steps -- [ ] **11. Coordinator Notifies the Reporter of Tier 2 Triage Decision** - - [ ] 11a. If the Vulnerability Meets the Security Escalation Criteria - - [ ] 11b. If the Vulnerability is Routine - -## Phase 3: Fix Development - -- [ ] **12. Remediation Developer(s) Gather Information and Validate Tier 2 Triage** - - [ ] 12a. (OPTIONAL) Gather Additional Information - - [ ] 12b. Validate Tier 2 Triage Consensus - - [ ] **13. Remediation Developer(s) Draft Mitigation/Remediation Plans** - - [ ] **14. Coordinator Facilitates Feedback and Consensus on Draft Mitigation/Remediation Plans** - - [ ] **15. Remediation Developer(s) Tentatively Complete and Verify Remediation with Support from Reviewer(s) and Verifiers(s)** - -## Phase 4: Release - -- [ ] **16. Coordinator Prepares the Security Advisory for Publication** - - [ ] 16a. Preparing the Security Advisory - - [ ] 16b. Request a CVE ID from GitHub's CNA -- [ ] **17. Coordinator Updates Reporter to Validate Remediation and Coordinate Public Disclosure** - - [ ] 17a. Request Feedback on the Security Advisory - - [ ] 17b. Request Reporter Verification of Implementation Efficacy and Completeness - - [ ] 17c. Ask to Review or Provide a Statement for their Blog -- [ ] **18. Remediation Developer(s) Release the Patch While Coordinator Publishes Security Adviso**ry +* Submits the vulnerability Report +* Adds othe Finder(s) who discovered the security vulnerability as Collaborators +* Responds to questions and coordination requests from the Project +* Validates the remediation patch -# Roles and Responsibilities +>[!NOTE] +>In most cases the Reporter likely to also be the Finder. The role of Reporter is used throughout this runbook. -Besides the On Call Role, this Runbook uses the roles defined the GitHub Private Vulnerability Reporting (PVR) [documentation](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory#about-credits-for-repository-security-advisories). These tables are also included in the relevent Steps they're first introduced for easy reference. +## Introduced in Phase 1: Tier 1 Triage -## Introduced in Phase 0: Report Submission +### Responsibilities: On Call (credited in GH as Triage Analyst) +* Determine if the Report is a potential Security Vulnerability +* Determine if the Report Needs More Information (NMI) to Triage and Reproduce +* Send the appropriate initial acknowledgement to the Reporter +* Summarize the vulnerability and next steps for others on the team -| Responsibilities: Finder | -| -------- | -| Identifies the security vulnerability | +### Responsibilities: Coordinator -| Responsibilities: Reporter | -| -------- | -| Submits the vulnerability Report | -| Adds othe Finder(s) who discovered the security vulnerability as Collaborators | -| Responds to questions and coordination requests from the Project | -| Validates the remediation patch | +* Assist Triage Analyst w Documentation +* Gather Feedback, Edit and Send NMI Response +* Fasciliate Discussions with Team +* Organize and Track Fix Action Items +* Informs Reporter of Tier 2 Triage Decision +* Send Reporter Regular Updates (as appropriate) +* Drafts and Gathers Feedback on Public Security Advisory +* Propose Updated CVSS v3.1 +* Propose Updated CWE >[!NOTE] ->In most cases the Reporter likely to also be the Finder. The role of Reporter is used throughout this Runbook to simplify phrasing. +>It's possible that the Triage Analyst and Coordinator roles will be performed by the same individual during Tier 1 Triage. In some Projects, the Coordinator role may transition to another person dedicated person during the Tier 2 Triage or Fix Phases. -## Introduced in Phase 1: Tier 1 Triage +## Introduced in Phase 2: Tier 2 Triage -| Responsibilities: On Call (credited as Triage Analyst) | -| -------- | -| Determine if the Report is a potential Security Vulnerability | -| Determine if the Report Needs More Information (NMI) to Triage and Reproduce | -| Send the appropriate initial acknowledgement to the Reporter | -| Summarize the vulnerability and next steps for others on the team | +### Responsibilities: Triage Analyst -| Responsibilities: Coordinator | -| -------- | -| Assist Triage Analyst w Documentation | -| Gather Feedback, Edit and Send NMI Response | -| Fasciliate Discussions with Team | -| Organize and Track Fix Action Items | -| Informs Reporter of Tier 2 Triage Decision -| Send Reporter Regular Updates (as Appropriate) | -| Drafts and Gathers Feedback on Public Security Advisory | -| Propose Updated CVSSv3 | -| Propose Updated CWE | +* Reproduce the Vulnerability +* (if NMI to repro) Document Reproduction Challenges and Steps Taken +* Assess and Document Impact +* Validate and/or Document Erroneous Reporter Assertions +* Assess and Document True Root Cause(s) +* Propose Fix Options (Mitigation and/or Remediation) +* Identify Fix Resourcing and Time Requirements ->[!NOTE] ->For many Projects, it's quite likely that the On Call and Coordinator roles will be performed by the same individual during Tier 1 Triage. In some Projects, the Coordinator role may transition to another person dedicated person during the Tier 2 Triage or Fix Phases. +### Responsibilities: Remediation Developer -## Introduced in Phase 2: Tier 2 Triage +* Reproduce the Vulnerability for Themselves +* Perform Additional Root Cause Analysis (as needed) +* Draft the Technical Portion of the Short-Term Mitigation Plan (as needed) +* Draft the Technical Mitigation/Remediation Plan(s) +* Author Code Changes per the Plan(s) +* Test Repro Steps the Against Patch to Verify Fix Efficacy +* Author Documentation Changes (as needed) -| Responsibilities: Triage Analyst | -| -------- | -| Reproduce the Vulnerability | -| (If NMI to Repro) Document Challenges and Steps Taken | -| Assess and Document Impact | -| Validate and/or Document Erroneous Reporter Assertions | -| Assess and Document True Root Cause(s) | -| Propose Fix Options (Mitigation and/or Remediation) | -| Identify Fix Resourcing and Time Requirements | +### Responsibilities: Remediation Reviewer -| Responsibilities: Remediation Developer | -| -------- | -| Reproduce the Vulnerability for Themselves | -| Perform Additional Root Cause Analysis (as needed) | -| Draft the Technical Portion of the Short-Term Mitigation Plan (as needed) | -| Draft the Technical Mitigation/Remediation Plan(s) | -| Author Code Changes per the Plan(s) | -| Test Repro Steps the Against Patch to Verify Fix Efficacy | -| Author Documentation Changes (as needed) | +* Reproduce the Vulnerability for Themselves +* Review and Provide Inputs to Mitigation/Remediation Plans +* Review Mitigation/Remediation Pull Requests -| Responsibilities: Remediation Reviewer | -| -------- | -| Reproduce the Vulnerability for Themselves | -| Review and Provide Inputs to Mitigation/Remediation Plans | -| Review Mitigation/Remediation Pull Requests | +### Responsibilities: Remediation Reviewer -| Responsibilities: Remediation Verifier | -| -------- | -| Reproduce the Vulnerability for Themselves | -| Review and Provide Input to Mitigation/Remediation Plans | -| Perform Testing to Verify Remediation Efficacy | +* Reproduce the Vulnerability for Themselves +* Review and Provide Input to Mitigation/Remediation Plans +* Perform Testing to Verify Remediation Efficacy # Start of Runbook # 1. The Reporter submits a potential security concern or vulnerability -A Reporter can use [this workflow](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability#privately-reporting-a-security-vulnerability) to create a new Security Advisory. This is the first step of the Coordinated Vulnerability Disclosure process! +A Reporter can use [this workflow in GitHub](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability#privately-reporting-a-security-vulnerability) to create a new Security Advisory. This is the first step of the Coordinated Vulnerability Disclosure process! Once they click ***Submit Report*** on the Report a Vulnerability page, three things happen: -1. A new Security Advisory is created in the repository they chose. +1. A new Security Advisory is created in the repository they reported in. 2. Members of the Repository's Owners group are notified. 3. The Reporter will receive a confirmation email. @@ -229,12 +135,6 @@ This feature cannot be disabled. [Click here](https://docs.github.com/en/code-se # 2. [T1] On Call Performs Tier 1 Triage and Drafts an Initial Acknowledgement ->#### Initial Response SLA: 48 Hours - -| Advisory State | Comms State | Vulnerability | -| -------------- | ------------| ------------- | -| Triage | Initial Ack In Progress | Not Reproduced | - In this Step, it is the On Call's responsibility to to determine which of the following criteria are relevant to the Report in order to determine the best way to proceed with an Initial Acknowledgement. - 2a. Contains any of the Security Escalation Criteria @@ -305,12 +205,6 @@ Our initial acknowledgement should demonstrate that the Report was at least read # 3. [T1] On Call Begins Organizing Internal Discussion by Creating a Tracking Discussion for the Vulnerability ->#### Initial Response SLA: 48 Hours - -| Advisory State | Comms State | Vulnerability | -| -------------- | ------------| ------------- | -| Triage | Initial Ack In Progress | Not Reproduced | - If the Report appears to contain a valid security vulnerability or meets an escalation criteria, the On Call begins documenting the Report and their Tier 1 Triage by creating a new GitHub Discussion in the [Private SecurityWG Repo]. 1. The body of the discussion should be a copy/paste of the initial vulnerability Report. @@ -322,12 +216,6 @@ If the Report appears to contain a valid security vulnerability or meets an esca # 4. [T1] On Call Drafts a Tier 1 Summary ->#### Initial Response SLA: 48 Hours - -| Advisory State | Comms State | Vulnerability | -| -------------- | ------------| ------------- | -| Triage | Inital Ack In Progress | Not Reproduced | - ### Kicking Off Internal Comms with a Tier 1 Summary Filling out a [Security Vulnerability Tier 1 Summary Template] is designed to help the On Call quickly and in a standardized way communicate their perspective and understanding of the reported vulnerability to others. @@ -349,11 +237,7 @@ This Step comes before sending the Initial Acknowledgement to the Reporter so th # 5. [T1] On Call Sends the Reporter an Initial Acknowledgement of Receipt ->#### Initial Response SLA: 48 Hours -| Advisory State | Comms State | Vulnerability | -| ---------------- | ----------------------| ------------- | -| Triage or Closed | Initial Ack Sent | Not Reproduced | This Initial Acknowledgement is probably the first time you have ever communicated with this Reporter/Security Researcher. The first few days after submitting a vulnerability report to a Bug Bounty or CVD Program are the most uncertain for a security researcher, especially if this is the first time they've submitted a vulnerability to your Program. @@ -389,12 +273,6 @@ The most important thing your Initial Acknowledgement should do is: # 6. [T2] Assign Tier 2 Triage Roles ->#### Tier 2 Triage Decision Response SLA: 7 Days - -| Advisory State | Comms State | Vulnerability | -| ---------------- | ----------------------| ------------- | -| Triage | Initial Ack Sent | Not Reproduced | - Depending on the size of the [SecurityWG], a sizable number of individuals can effectively participate in order to distribute the load of effectively handling CVD. During the Tier 2 Triage Phase, the two minimum Roles to assign are: @@ -431,12 +309,6 @@ During the Tier 2 Triage Phase, the two minimum Roles to assign are: # 7. [T2] Triage Analyst Attempts to Reproduce the Vulnerability as Reported ->#### Tier 2 Triage Decision Response SLA: 7 Days - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Triage | Initial Ack Sent | Reproduction In Progress | - During this Step, the Triage Analyst's primary responsibility is to reproduce the vulnerability as described in the Report. The information gathered by this work will be the basis for future decision making. ### Document More Detailed Reproduction Steps @@ -445,7 +317,7 @@ While attempting reproduction, it is common to find omissions and errors in the #### Success: Two Person Verification -This Runbook recommends that once the vulnerability is successfully reproduced by the Triage Analyst, a second team member should validate this using the updated Repro Steps. +This runbook recommends that once the vulnerability is successfully reproduced by the Triage Analyst, a second team member should validate this using the updated Repro Steps. > [!IMPORTANT] > The Reporter should be notified using the [guidance in Step 8b] as soon as the vulnerability in their Report is repeatedly reproducable. The additional root cause and impact analysis work described below in [Step 9] **should not block** this notification. @@ -458,19 +330,13 @@ Despite the inability to reproduce and validate the vulnerability, at this Step #### NMI: Two Person Verification -This Runbook recommends that if the Triage Analyst is unable to reproduce the vulnerability, another member of the team should make an independent attempt in order to control for environmental factors and natural human error. Te Reporter be notified of this only once two team members have independently failed to reproduce the vulnerability. +This runbook recommends that if the Triage Analyst is unable to reproduce the vulnerability, another member of the team should make an independent attempt in order to control for environmental factors and natural human error. Te Reporter be notified of this only once two team members have independently failed to reproduce the vulnerability. > [!TIP] > Guidance on how to optimize for comms success when requesting more information from the Reporter is discussed in [Step 8a]. # 8. [T2] Coordinator Notifies Reporter of Reproduction Progress ->#### Tier 2 Triage Decision Response SLA: 7 Days - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Triage | Repro Success or NMI In Progress | Reproduced or NMI | - This notification is probably the first in-depth communication you've ever had with this Reporter. Be sure to check out the [Researcher Comms Primer] to help set you up for success! ## 8a. First Notification: Unable to Reproduce / NMI @@ -499,18 +365,12 @@ As soon as at least two members of the team have been able to independently repr # 9. [T2] Triage Analyst Determines the True Root Cause(s), Impact, and Severity ->#### Fix Decision Response SLA: 14 Days - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Triage | Repro Notification Sent | Reproduced | - ## 9a. Identify and Document True Root Cause(s) Determining the true root cause(s) allows the Triage Analyst and the team to gain a more thorough understanding of the real vulnerability underlying the Report's behavior. > [!TIP] -> This Runbook recommends that vulnerabilities that have been successfully reproduced should not be considered validated until the true root cause(s) are known. The reason for this is that the behavior demonstrated in the Reporter's Reproduction Steps may only represent one of many ways to exploit the vulnerability. +> This runbook recommends that vulnerabilities that have been successfully reproduced should not be considered validated until the true root cause(s) are known. The reason for this is that the behavior demonstrated in the Reporter's Reproduction Steps may only represent one of many ways to exploit the vulnerability. The true root cause(s) should be documented in simple, short language that does not require extensive context of the product to understand. More complex writing happens when capturing the Impact of the vulnerabilities caused by the root cause(s) and proposing potential mitigations or remediations that address the true root cause(s). @@ -544,7 +404,7 @@ In addition to the detailed description of the vulnerability and its root cause( - First draft of the proposed CWE > [!NOTE] -> It's likely that this description will evolve over time. There are reminders to keep this updated throughout this Runbook to help the [SecurityWG] stay aligned on their understanding of the vulnerability. +> It's likely that this description will evolve over time. There are reminders to keep this updated throughout this runbook to help the [SecurityWG] stay aligned on their understanding of the vulnerability. ## 9c. Document Initial Mitigation/Remediation Options @@ -559,12 +419,6 @@ For each root cause, the Triage Analyst should *briefly* document initial propos # 10. [T2] Coordinator Facilitates Consensus Building Discussions ->#### Fix Decision Response SLA: 14 Days - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Triage | Repro Notification Sent | Root Cause Proposed | - Once data gathering and analysis for Tier 2 Triage is complete, the final step for Tier 2 Triage is for the [SecurityWG] to reach a consensus on: - 10a. Their shared understanding of the draft Tier 2 Triage deliverables @@ -600,7 +454,7 @@ In a perfect world all known security vulnerabilities would be completely remedi However, in practice there are scenarios where it may not be appropriate or possible to immediately prioritize a code change that completely remediates the reported behavior. -This Runbook assumes that the [SecurityWG] will choose to completely remediate the vulnerability whenever possible, even if this choice requires negotiating a longer disclosure timeline with the Reporter due to the effort required for remediation. +This runbook assumes that the [SecurityWG] will choose to completely remediate the vulnerability whenever possible, even if this choice requires negotiating a longer disclosure timeline with the Reporter due to the effort required for remediation. #### Common Won't Fix Scenarios @@ -612,7 +466,7 @@ This Runbook assumes that the [SecurityWG] will choose to completely remediate t - Exploitation is only possible when the target is using antiquated EoL software that should no longer be used due to the absence of modern security protections. > [!NOTE] -> This Runbook makes a binary assumption that a CVD Report is either a security vulnerability or is not a security vulnerability. +> This runbook makes a binary assumption that a CVD Report is either a security vulnerability or is not a security vulnerability. > > However, not all valid Reports from security researchers and pen testers are actually security vulnerabilities. They may actually be describing the absence of a security feature or functionality that has a security-positive impact for which the target is expected to have compensating controls. @@ -696,19 +550,13 @@ The [SecurityWG] should only consider disclosing an unpatched vulnerability if t # 11. [T2] Coordinator Notifies the Reporter of Tier 2 Triage Decision ->#### Fix Decision Response SLA: 14 Days - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Triage | Repro Notification Sent | Remediation Plan In Progress | - As soon as the [SecurityWG] decides to fix the Reported vulnerability, the Coordinator should: - Inform the Reporter and manage their expectations on next steps - Transition the Security Advisory state from `Triage` to `Draft` > [!TIP] -> If you decide to proactively share your Mitigation/Remediation Plan(s) with the Reporter for feedback, the Runbook separates Reporter comms into two events: +> If you decide to proactively share your Mitigation/Remediation Plan(s) with the Reporter for feedback, the runbook separates Reporter comms into two events: > > - Update 1: Tier 2 Triage Complete + Mitigation/Remediation In Progress > - Update 2: Mitigation/Remediation Plan(s) Complete + Feedback Request @@ -738,13 +586,6 @@ Use the [Tier 2 Triage Complete: Routine Template]. Customize your response if y # 12. [FIX] Remediation Developer(s) Gather Information and Validate Tier 2 Triage ->#### Fix Decision Response SLA: 90 Days from Initial Reciept ->#### Reporter Update Comms SLA: 14 Days from Last Comms - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Draft | Fix In Progress Notice Sent | Remediation In Progress | - During this Step it is the Remediation Developer(s) responsibility to: - Gather any additional information needed to draft the Plan(s) @@ -782,13 +623,6 @@ If necessary, the Remediation Developer(s) and Coordinators should also update: # 13. [FIX] Remediation Developer(s) Draft Mitigation/Remediation Plans ->#### Fix Decision Response SLA: 90 Days from Initial Reciept ->#### Reporter Update Comms SLA: 14 Days from Last Comms - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Draft | Fix In Progress Notice Sent | Remediation In Progress | - During this Step, it is the Remediation Developer(s) responsibility to to draft the complete Mitigation and Remediation Plans. The Mitigation and Remediation Plans should be explicitly traced from the Mitigation and Remediation Options discussed at the end of Tier 2 Triage. @@ -815,12 +649,7 @@ The Remediation Reviewer(s) and Fix Approver(s) should be generally aware of and # 14. [FIX] Coordinator Facilitates Feedback and Consensus on Draft Mitigation/Remediation Plans ->#### Fix Decision Response SLA: 90 Days from Initial Reciept ->#### Reporter Update Comms SLA: 14 Days from Last Comms -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Draft | Fix In Progress Notice Sent | Remediation In Progress | Once the draft Mitigation and Remediation Plans are complete, the Coordinator should facilitate feedback and consensus on the proposed plan. @@ -832,13 +661,6 @@ While there should be consensus on the entirity of both Plans, special attention # 15. [FIX] Remediation Developer(s) Tentatively Complete and Verify Remediation with Support from Reviewer(s) and Verifiers(s) ->#### Fix Decision Response SLA: 90 Days from Initial Reciept ->#### Reporter Update Comms SLA: 14 Days from Last Comms - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Draft | Fix In Progress Notice Sent | Remediation Tentatively Complete | - In this Step, responsibilities are: - **Remediation Developer:** Follow the Remediation Plan to complete development and Update the Plan as new information is learned during development @@ -847,20 +669,11 @@ In this Step, responsibilities are: - Execute the Test Plan - **Remediation Verifier:** Execute the Test Plan - - > [!IMPORTANT] > When testing a remediation patch, it's possible the Reporter will identify additional attack vectors they didn't think of when originally performing their research. Before the [SecurityWG] considers a remediation patch complete and ready for release, be sure to ensure that the Reporter agrees that they're unlikely to find workarounds. # 16. [RELEASE] Coordinator Prepares the Security Advisory for Publication ->#### Fix Decision Response SLA: 90 Days from Initial Receipt ->#### Reporter Update Comms SLA: 14 Days from Last Comms - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Draft | Fix In Progress Notice Sent | Remediation Complete | - In this Step, the Coordinator, with Remediation Developer support, is responsible for: - 16a. Preparing the Security Advisory @@ -967,13 +780,6 @@ While not necessary, it's a good practice to have a CVD ID ready to share with t # 17. [RELEASE] Coordinator Updates Reporter to Validate Remediation and Coordinate Public Disclosure ->#### Fix Decision Response SLA: 90 Days from Initial Receipt ->#### Reporter Update Comms SLA: 14 Days from Last Comms - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Draft | Remediation Ready Sent | Remediation Tentatively Complete | - In this Step, the Coordinator, with Remediation Developer support, is responsible for: - 17a: Requesting Reporter feedback on the Security Advisory @@ -1015,13 +821,6 @@ This is a sensitive and potentially contentious request and the Reporter may dec # 18. [RELEASE] Remediation Developer(s) Release the Patch While Coordinator Publishes Security Advisory ->#### Fix Decision Response SLA: 90 Days from Initial Receipt ->#### Reporter Update Comms SLA: 14 Days from Last Comms - -| Advisory State | Comms State | Vulnerability | -| -------- | ------| ---------- | -| Published | Fix In Progress Notice Sent | Remediation Complete | - On the planned disclosure/release date, the Coordinator and Remediation Developer(s) are responsible for: - Releasing the remediation patch diff --git a/CVD_Guide/Researcher-Communications-Primer.md b/CVD_Guide/Researcher-Communications-Primer.md new file mode 100644 index 0000000..abac36f --- /dev/null +++ b/CVD_Guide/Researcher-Communications-Primer.md @@ -0,0 +1,29 @@ +# Researcher Communications Primer + +Proactively working to make a good impression in all communications with Reporters/Security Researchers is the key to your success. Each message is an opportunity to establish your Project's reputation in the security community and to potentially gain a recurring reporter that helps improve the security posture of your Project. + +But be mindful of the negotiation-like dynamics that can occur between Bug Bounty and CVD Program operators and the security research community, particularly with high impact vulnerabilities. + +#### Communicate with Empathy + +Hostile and unprofessional behaviors by Program operators are far less common and egregious than they once were. However, disrepectful treatment continues to be a common experience for ethical security researchers working in good faith when disclosing security vulnerabilities. + +Be mindful of these experiences and what others may - in good or bad faith - interpret as dismissiveness or a lack of urgency whenever making decisions and communicating those decisions with a security researcher. + +#### Communicate with Situational Awareness + +You may recieve with erroneous and irrelevant disclosures from hostile or publicity seeking individuals demanding recognition for their research. + +The best defense against these actors is to explain your decisions clearly and include supporting facts in all communications and professionally requesting the same from them. If there is ever disagreement on the validity, severity/impact, or exploitability of a security vulnerability, leave nothing to assumption and explicitly state (and continue to re-state if mentioned in a previous comm) the data behind your rationale. + +### Understanding Researcher Assertions on Severity and Impact + +Researcher assertions on Impact and Scope may need to be adjusted for reasons beyond their control: + +#### Researchers Don't Live Your Software Like You Do +Although there are exceptions, one should expect that researchers who submit security vulnerabilities to Bug Bounty and CVD Programs are not as knowledgable on the software they're testing as the software engineers who wrote it. + +#### Bug Hunting is a Different Skill Set +The technical skills needed to be a successful bug hunter/pen tester do not fully overlap with those of software engineers building open source and enterprise software. + +While it's more common for Reporters to over-state the impact of their vulnerability for the sake of higher bounties and self-promotion, it's also not uncommon for researchers to unknowingly understate and miss the true scope and impact of their vulnerability. \ No newline at end of file diff --git a/CVD_Guide/TEMPLATE-CVD-Step-by-Step-Runbook-Checklist.md b/CVD_Guide/TEMPLATE-CVD-Step-by-Step-Runbook-Checklist.md new file mode 100644 index 0000000..34c1feb --- /dev/null +++ b/CVD_Guide/TEMPLATE-CVD-Step-by-Step-Runbook-Checklist.md @@ -0,0 +1,74 @@ +# CVD Step-by-Step Runbook Guide Checklist TEMPLATE + +## How to use this Checklist + +This checklist is meant to be used in conjunction with: + +* [CVD Step-by-Step Runbook Guide for Teams](../CVD-Step-by-Step-Runbook-and-Guide.md) +* [Researcher Communications Templates](../Researcher-Communications.Primer.md) + +This checklist uses GitHub's Tasklist feature for when used as a template for a GitHub issue. You can use this template to provide visibility into which Step the Report is currently in and stay aware of the upcoming Steps. + +>[!TIP] +>In several Steps (eg: 2, 5, 11), you'll only use one of the available sub-Steps. Be sure to remove the other sub-steps to shorten the length of the checklist and only see which steps were followed! + +## Phase 0: Report Submission + +- [ ] **1. The Reporter submits a potential security concern or vulnerability** + - [ ] 1a. Optional: Reporter creates a temporary private fork (if they want to) + +## Phase 1: Tier 1 Triage + +- [ ] **2. On Call Performs Tier 1 Triage and Drafts an Initial Acknowledgement** + - [ ] 2a. Security Escalation + - [ ] 2b. Need More Information? + - [ ] 2c. Not a Security Vulnerability Report? + - [ ] 2d. Abuse Escalation + - [ ] 2e. Routine Security Vulnerability Report +- [ ] **3. On Call Begins Organizing Internal Discussion by Creating a Tracking Discussion for the Vulnerability** +- [ ] **4. On Call Drafts a Tier 1 Summary** +- [ ] **5. On Call Sends the Reporter an Initial Acknowledgement of Receipt** + - [ ] 5a. If the Report meets Security Escalation Criteria + - [ ] 5b. If the Report Appears to be Missing Basic Information + - [ ] 5c. If the Report Appears to be a Valid and Routine + - [ ] 5d. If the Report is not a Security Vulnerability + +## Phase 2: Tier 2 Triage + +- [ ] **6. Assign Tier 2 Triage Roles** +- [ ] **7. Triage Analyst Attempts to Reproduce the Vulnerability as Reported** +- [ ] **8. Coordinator Notifies Reporter of Reproduction Progress** + - [ ] 8a. First Notification: Unable to Reproduce / NMI + - [ ] 8b. Second/Ongoing Comms: Still Unable to Reproduce + - [ ] 8c. Notification: Successful Reproduction +- [ ] **9. Triage Analyst Performs Tier 2 Triage** + - [ ] 9a. Identify and Document True Root Cause(s) + - [ ] 9b. Assess and Document Impact and Exploitability + - [ ] 9c. Document Initial Mitigation/Remediation Options +- [ ] **10. Coordinator Facilitates Consensus Building Discussions** + - [ ] 10a. Reach Technical Consensus on Tier 2 Triage + - [ ] 10b. Agree to Completely Remediate the Vulnerability + - [ ] 10c. Assign Remediation Roles and Agree on Mitigation/Remediation Next Steps +- [ ] **11. Coordinator Notifies the Reporter of Tier 2 Triage Decision** + - [ ] 11a. If the Vulnerability Meets the Security Escalation Criteria + - [ ] 11b. If the Vulnerability is Routine + +## Phase 3: Fix Development + +- [ ] **12. Remediation Developer(s) Gather Information and Validate Tier 2 Triage** + - [ ] 12a. (OPTIONAL) Gather Additional Information + - [ ] 12b. Validate Tier 2 Triage Consensus + - [ ] **13. Remediation Developer(s) Draft Mitigation/Remediation Plans** + - [ ] **14. Coordinator Facilitates Feedback and Consensus on Draft Mitigation/Remediation Plans** + - [ ] **15. Remediation Developer(s) Tentatively Complete and Verify Remediation with Support from Reviewer(s) and Verifiers(s)** + +## Phase 4: Release + +- [ ] **16. Coordinator Prepares the Security Advisory for Publication** + - [ ] 16a. Preparing the Security Advisory + - [ ] 16b. Request a CVE ID from GitHub's CNA +- [ ] **17. Coordinator Updates Reporter to Validate Remediation and Coordinate Public Disclosure** + - [ ] 17a. Request Feedback on the Security Advisory + - [ ] 17b. Request Reporter Verification of Implementation Efficacy and Completeness + - [ ] 17c. Ask to Review or Provide a Statement for their Blog +- [ ] **18. Remediation Developer(s) Release the Patch While Coordinator Publishes Security Adviso**ry \ No newline at end of file diff --git a/CVD_Guide/generic_minimal_VDP_policy.md b/CVD_Guide/TEMPLATE-Minimal-VDP-Policy.md similarity index 100% rename from CVD_Guide/generic_minimal_VDP_policy.md rename to CVD_Guide/TEMPLATE-Minimal-VDP-Policy.md diff --git a/CVD_Guide/generic_recommended_vdp_policy.md b/CVD_Guide/TEMPLATE-Recommended-VDP-Policy.md similarity index 69% rename from CVD_Guide/generic_recommended_vdp_policy.md rename to CVD_Guide/TEMPLATE-Recommended-VDP-Policy.md index 46442e0..34f642c 100644 --- a/CVD_Guide/generic_recommended_vdp_policy.md +++ b/CVD_Guide/TEMPLATE-Recommended-VDP-Policy.md @@ -1,14 +1,14 @@ -# OpenJS Project Generic Recommended Coordinated Vulnerability Disclosure (CVD) Policy (VDP) TEMPLATE +# TEMPLATE OpenJS Project Recommended Vulnerability Disclosure Policy (VDP) ## Introduction -[project_name](https://) and [The OpenJS Foundation](https://openjsf.org/) are committed to a safe and secure Internet. We're thankful for and welcome ethical security research contributions to our project(s) and support good faith Coordinated Vulnerability Disclosure (CVD). +[projectName](FILL_IN_THE_BLANK) and the [OpenJS Foundation](https://openjsf.org) are committed to a safe and secure Internet. We're thankful for and welcome ethical security research contributions to our project(s) and support good faith Coordinated Vulnerability Disclosure. This project is within the scope of the [OpenJS Foundation CNA](https://www.openjsf.org/security). -We accept and process all communications regarding potential security vulnerabilities and concerns using [GitHub's Private Security Reporting](https://github.blog/2023-04-19-private-vulnerability-reporting-now-generally-available/) feature. +We accept and process all communications regarding potential security vulnerabilities and concerns using [GitHub's Private Security Reporting](https://github.blog/2023-04-19-private-vulnerability-reporting-now-generally-available) feature. -> *OPTIONAL: For more information about the bugs we're looking for, check out our [Threat Model](https://)!* +> *OPTIONAL: For information about our security model and the way we think about certain vulnerabilties, check out our [Threat Model](FILL_IN_THE_BLANK)!* -> **[Click here to Submit a Security Vulnerability](https://github.com/your_org/your_repo/security/advisories/new)** +> **[Click here to Submit a Security Vulnerability](#How-to-Report-a-Security-Vulnerability)** ## Policy Scope @@ -32,7 +32,7 @@ This Policy does not grant you permission to perform testing or demonstrate the - **Let us Know Immediately:** Once you believe you’ve discovered a potential security concern or vulnerability, immediately submit it to us with as much detail as possible so we may quickly begin our investigation. - **Research Collaborators:** We gladly include all research collaborator(s) who the original submitter agrees should also be credited for the vulnerability during public disclosure. -> For more details, check out **[How to Securely Submit a Security Concern or Vulnerability to [Org/Project]](#How-to-Securely-Report-a-Security-Concern-or-Vulnerability-to-OrgProject)** below. +> For more details, check out **[How to Submit a Vulnerability to Us](#How-to-Report-a-Security-Vulnerability)** below. ### Public Disclosures @@ -41,7 +41,6 @@ This Policy does not grant you permission to perform testing or demonstrate the > For more details, check out **[What to Expect during our CVD Process](#What-to-Expect-During-our-CVD-Process)** below. - ### Expected Behaviors - Do not access user or system accounts and data that do not belong to you. @@ -54,7 +53,7 @@ This Policy does not grant you permission to perform testing or demonstrate the ### Security Advisory and CVE Policy -*`[org/project/repo_name]`* is within the scope of The OpenJS Foundation CNA. We issue GitHub Security Advisories and CVEs for valid, In Scope security vulnerabilities when the root cause and code change to implement the mitigation/remediation is in one of our repositories. +We issue GitHub Security Advisories and CVEs for valid, In Scope security vulnerabilities when the root cause and code change to implement the mitigation/remediation is in one of our repositories. To provide high quality security signals to our downstream users/developers, we do not issue Advisories and CVEs when updating vulnerable third party dependencies unless there is demonstrable proof in the form of a Proof of Concept that the dependency’s vulnerability can be exploited within the context of *`[org/project/repo]`*. @@ -62,50 +61,25 @@ To provide high quality security signals to our downstream users/developers, we - We are an open source project of [The OpenJS Foundation, a U.S. 501(c\)(6) non-profit organization](https://openjsf.org/governance) and unfortunately are unable to offer a bounty award for your discovery. - -### Safe Harbor for Good Faith Security Research - -When conducting security vulnerability research according to this Policy, we consider this research to be: - -- Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this Policy; -- Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls; -- Lawful, helpful to the overall security of the Internet, and conducted in good faith. - -You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy. - -If at any time you have concerns or are uncertain whether your security research is consistent with this Policy, please submit a vulnerability report using *`[H1/Github/Other]`* before going further. - -> Note that this Safe Harbor applies only to legal claims related to assets under our control and that this Policy does not bind independent third parties. - - ## Out of Scope Vulnerabilities -Vulnerabilities meeting the following criteria are Out of Scope for this Policy: - -- Requires on-path (formerly MiTM) or atypical physical access to a target. -- Requires pre-existing compromise or rooting/jailbreaking of a target. -- A target's default security protections must be disabled (eg: `--disable-web-security`) -- A target doesn't not adhere to common best practices (eg: a web server at root). -- Not exploitable when a target is using a recent version of a modern web browser. -- *Optional: Insecure-by-default initial configurations that are discussed in our `[developers_guide/security_guide]`.* - ### Vulnerabilities in Third Party Dependencies -- Please report vulnerabilities in dependencies to their respective owners in accordance with their Vulnerability Disclosure Policies so that the true root cause can be properly mitigated or remediated. - Vulnerabilities in our direct and tertiary dependencies are considered Out of Scope unless once can demonstrate actual exploitation using *`[org/project/repo]`* functionality. +- Please report vulnerabilities in dependencies to their respective owners in accordance with their Vulnerability Disclosure Policies so that the true root cause can be properly mitigated or remediated. In the case of an In Scope vulnerability that also relies on a previously unknown (0day) vulnerability in a third party dependency we will: -1. Ask for proof that you have disclosed the vulnerability per its Vulnerability Disclosure Policy, or +1. Request proof that you have disclosed the vulnerability per its own VDP, or 2. If you haven’t done that already, we will ask that you do so. -# How to Securely Report a Security Concern or Vulnerability to [Org/Project] +# How to Report a Security Vulnerability Only submit potential security concerns or vulnerabilities to us using *`[your_disclosure_platform]`*. Attempts to send this via other channels (public ticket, email, Slack, social media) will be removed. To best help us quickly understand and take action on your submission, be sure to include: ### **[Click here to Submit a Security Vulnerability](https://github.com/your_org/your_repo/security/advisories/new)** -> For more information about the bugs we're looking for, check out our [Threat Model](https://)! +> *OPTIONAL: For more information about the bugs we're looking for, check out our [Threat Model](FILL_IN_THE_BLANK)!* | Section | Information | | -------- | -------- | @@ -114,22 +88,25 @@ To best help us quickly understand and take action on your submission, be sure t | **Reproduction Steps** | Clearly written and detailed reproduction steps, including tools and environment configuration. | | **Location in Source** (if feasible) | The precise location of the vulnerability in source code. | | **Proposed Fix** (if feasible) | Source code for your proposed fix. | -| **Proposed CVSSv3 Base Score** | (Best Effort) [Link to NVD CVSSv3 Calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) | -| **Proposed CWE and/or CAPEC** | (Best Effort) [MITRE CWE](https://cwe.mitre.org/index.html) and [MITRE CAPEC](https://capec.mitre.org/index.html) | +| **Proposed CVSS v3.1 Base Score** | [NVD CVSS v3.1 Calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) | +| **Proposed CWE** | [MITRE CWE](https://cwe.mitre.org/index.html) | | **Collaborators** | A list of all collaborators and their affiliation who should receive credit upon public disclosure. | - # What to Expect During our CVD Process -### **[Click here to Submit a Security Vulnerability](https://github.com/your_org/your_repo/security/advisories/new)** - +### **[Click here to Submit a Security Vulnerability](https://github.com/YOUR_ORG/YOUR_REPO/security/advisories/new)** | Status | Events | | -------- | -------- | | **Acknowledgement** | We will acknowledge receipt of your submission within *`[hours/days]`*. | | **Triage** | We will attempt to reproduce your findings within *`[hours/days]`*. We may ask you for more information if your submission is unclear or missing data we need to understand and reproduce the behavior you observed. | -| **Acceptance** | We will let you know when we have successfully reproduced your vulnerability and accepted it as a valid security vulnerability report. We will also share our initial assessment of your vulnerability as we understand it and our assessed [CWE](https://cwe.mitre.org/index.html), [CAPEC](https://capec.mitre.org/index.html) and [CVSSv3 Base Score](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator), a reserved CVE ID, and what you can expect to happen next regarding mitigation/remediation. | +| **Acceptance** | We will let you know when we have successfully reproduced your vulnerability and accepted it as a valid security vulnerability report. We will also share our initial assessment of your vulnerability as we understand it and our assessed [CWE](https://cwe.mitre.org/index.html), [CAPEC](https://capec.mitre.org/index.html) and [CVSS v3.1 Base Score](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator), a reserved CVE ID, and what you can expect to happen next regarding mitigation/remediation. | | **Ongoing Communications** | We will let you know how things are going periodically and when there is new information regarding our mitigation and/or remediation efforts. | | **Mitigation and/or Remediation** | We endeavor to release patches for security vulnerabilities no later than ninety (90) days of receipt (with most released much earlier). However, if we ask for more time, we will explain the technical reasoning, including the unusual effort and complexity of patch development and downstream user/developer remediation actions. | | **Coordinating Disclosure** | We will inform you once we know the release date and version of the mitigation and/or remediation. If you plan to publish a blog regarding your vulnerability, we would greatly appreciate the opportunity to review your post in advance for technical accuracy and so we can provide an official statement for you to include. | | **Public Disclosure** | This is when the GitHub Advisory is published and the CVE is updated to reflect the Advisory. You may then publish your blog post and tell the world about your awesome hax0r skills. | + +#### FOR MAINTAINERS: Comments on this Policy + +> * If you have suggestions on how this process could be improved please submit a pull request against against the latest version of the policy [in the OpenJS Security Collab Space GitHub](https://github.com/openjs-foundation/security-collab-space/tree/main/CVD_Guide). +> * Don't forget to remove this section! \ No newline at end of file