# Private markdown version of the google doc

https://docs.google.com/document/d/132lq47BYxK0nhP4CNzgi3WNlXBhbrdKMjCfV07GUs3M/edit#heading=h.a2jadmbn7smo

# Jupyter Vulnerability Handling Process

This document attempt to sumarize and propose guideline for the Jupyter Project Security handeling process.

Security Issues and Vulnerability handling have inherent expectation and processes that are in opposition to open source:
- Private discussions
- Obfuscation
- Short timeline..

This makes it quite hard to be able to understand, learn, or knwo what to expect from a security point of view. This document will give you a glimpse on what's happening on the inside, and whcih timeline to expect when you report a security vulnerability. It will also serve as a guideline and task list for Jupyter Contributors and Developers on how to handle security relatied issues.

## Scope

This process applies to *all projects* governed by Jupyter, including JupyterLab, Jupyter Notebook, JupyterHub, and Jupyter Server.

## Reporting Vulnerabilities

If you believe you’ve found a security vulnerability in a Jupyter project, please report it to [e-mail]. If you prefer to encrypt your security reports, you can use [this PGP public key](https://jupyter.org/assets/ipython_security.asc). Project Jupyter will respond within 3 days to all new reports.

## Coordinated Disclosures

Project Jupyter follows a [coordinated disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#responsible-or-coordinated-disclosure) model where the initial report and remediation are handled privately, but the completion description is made public once a patch is available. Project Jupyter will disclose known vulnerabilities within 90 days by default, regardless of a patch being available.

## Acknowledgement

Project Jupyter will work to ensure that security researchers, developers, users, or others who identify and report vulnerabilities within Project Jupyter software receive acknowledgement for their contribution.

## Vulnerability Triage & Remediation Process

This section describes the process used by Project Jupyter to track, remediate, and disclose reported vulnerabilities. This description is both a reference for the Jupyter Community and a guideline for contributors.

### Roles

This process defines three roles
- **Reporter** The individual(s) who report the vulnerability
- **Coordinator** A Project Jupyter contributor who facilitates the tracking of the vulnerability through this process
- **Developer** One or more Project Jupyter developers who work on remediating the vulnerability

*TBD:* Should these roles be separate individuals? I.e., could someone do two or all of these roles?
* I don't think it's mandatory that these be separate people. A developer should be allowed to fix a vulnerability they reported, for example. — Jason W

### Process

The role responsible for each step is noted at the beginning.
* Might be good to have an expectation for a communication in response to a report: an initial response within X days/hours and a follow-up within Y days/hours of filing, for example. — Jason W
* Who will own the creation of mechanisms to keep reports on track for our process? — Jason W

- Upon receipt of the initial report:
- **Coordinator**: Respond to the reported and acknowledge receipt of the report
- **Coordinator**: Open an issue in the private GitHub repository used for tracking vulnerabilities across projects
- **Coordinator**: Assign the issue to one or more **Developers** to confirm the report
- **Developer**: Attempt to replicate the reported vulnerability. Request more information from the **Reporter** if necessary. Update the tracking issue with the results.
- If the vulnerability cannot be confirmed
- **Coordinator**: Close the issue
- **Coordinator**: Notify the reporter
- If the vulnerability is confirmed, within the relevant repositories:
- **Coordinator**: Open a draft [GitHub Security Advisory](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#about-github-security-advisories)
- Include relevant but sanitized details in the top level comment, which becomes public
- Sensitive details and reproductions go in the comments on the draft advisory, which are not public
- **Coordinator**: Add relevant people to the advisory - *note* we need an official list of GitHub handles here since teams don't work across orgs
- **Coordinator**: Request a [CVE](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#cve-identification-numbers) from GitHub. This is private until the advisory is published.
- **Developer**: Work on the [vulnerability fix PR](https://docs.github.com/en/code-security/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability#creating-a-temporary-private-fork)
- Once the fix is agreed upon, wait for the CVE number to be issued.
- **Coordinator**: Notify the **Reporter** of the CVE number
- **Developer & Coordinator**: Decide on release and announcement dates and post them the draft advisory. These are typically at least a week apart to allow administrators to deploy fixes.
- **Coordinator**: Post the release and announcement dates on the Jupyter Security [Mailing List]([[e-mail]](mailto:[e-mail]))
- **Developer**: Merge the security fix PR
- **Developer**: Make a release to PyPI and/or npm with no announcement or change log
- **Coordinator**: Publish the security advisory on the announcement date. GitHub will post the CVE to the MITRE database
- **Coordinator**: Notify the **Reporter** of the releases
- **Coordinator**: Close the issue in the tracking repository