|
| 1 | +# conda-forge vulnerability handling process |
| 2 | + |
| 3 | +This document summarizes and proposes guidelines for handling vulnerabilities reported in |
| 4 | +conda-forge's infrastructure. |
| 5 | + |
| 6 | +Security issues and vulnerabilities have expectations and processes that are differ from typical |
| 7 | +open source practices: |
| 8 | + |
| 9 | +- Private discussions |
| 10 | +- Obfuscation |
| 11 | +- Short timeline |
| 12 | + |
| 13 | +This makes it quite hard to be able to understand, learn, or know what to expect from a security |
| 14 | +point of view. This document will give you a glimpse on what's happening on the inside, and what |
| 15 | +timeline to expect when you report a security vulnerability. It will also serve as a guideline and |
| 16 | +task list for conda-forge members on how to handle security related issues. |
| 17 | + |
| 18 | +## Scope |
| 19 | + |
| 20 | +This process applies to *all projects* governed by conda-forge. This includes: |
| 21 | + |
| 22 | +- conda-forge feedstock machinery |
| 23 | +- conda-forge infrastructure and bots |
| 24 | +- conda-forge website and documentation |
| 25 | + |
| 26 | +Conversely, this process does NOT apply to the software packaged by conda-forge itself. Please contact the upstream maintainers directly. |
| 27 | + |
| 28 | +## Reporting Vulnerabilities |
| 29 | + |
| 30 | +If you believe you’ve found a security vulnerability in a conda-forge project, please responsibly report it to [email protected]. conda-forge will try to will respond within 7 days to all new reports. |
| 31 | + |
| 32 | +We are also testing GitHub Private vulnerability reporting, you can try to submit a security advisory on [conda-forge/conda-forge.github.io using this link](https://github.com/conda-forge/conda-forge.github.io/security/advisories/new). |
| 33 | + |
| 34 | +## Coordinated Disclosures |
| 35 | + |
| 36 | +conda-forge follows a [coordinated disclosure][coordinated-disclosure] model where the initial |
| 37 | +report and remediation are handled privately, but the completion description is made public once a |
| 38 | +patch is available. conda-forge will disclose known vulnerabilities within 90 days by default, |
| 39 | +whether a patch is available or not. |
| 40 | + |
| 41 | +## Acknowledgement |
| 42 | + |
| 43 | +conda-forge will work to ensure that security researchers, developers, users, or others who |
| 44 | +identify and report vulnerabilities within conda-forge projects receive acknowledgement for their |
| 45 | +contribution. |
| 46 | + |
| 47 | +## Vulnerability Triage & Remediation Process |
| 48 | + |
| 49 | +This section describes an example process used by conda-forge to track, remediate, and disclose a |
| 50 | +reported vulnerability. This description is both a reference for the conda-forge community and a |
| 51 | +guideline for contributors. The actual process may vary depending on the nature of the |
| 52 | +vulnerability. |
| 53 | + |
| 54 | +### Roles |
| 55 | + |
| 56 | +This process defines these roles: |
| 57 | +- **Reporter** The individual(s) who report the vulnerability |
| 58 | +- **Coordinator** A conda-forge core member who facilitates the tracking of the vulnerability |
| 59 | + through this process |
| 60 | +- **Developer** One or more developers who work on remediating the vulnerability |
| 61 | + |
| 62 | +For the purpose of this document these roles are distinct, in practice, some of these roles may be handled by the same individual. However, the roles should be covered by a minimum of two separate individuals. For example, a Reporter may also fill the Developer role and create the remediation, in this case the Coordinator should be a separate individual. |
| 63 | + |
| 64 | +### Process |
| 65 | + |
| 66 | +The role responsible for each step is noted at the beginning. |
| 67 | + |
| 68 | +- Upon receipt of the initial report: |
| 69 | + - **Coordinator**: Respond to the reported and acknowledge receipt of the report in the timeframe |
| 70 | + given in the "Reporting Vulnerabilities" section. |
| 71 | + - **Coordinator**: Open an issue in the private GitHub repository used for tracking |
| 72 | + vulnerabilities across projects |
| 73 | + - **Coordinator**: Review the issue for completeness and suitability (triage). If more |
| 74 | + information is needed, follow up with the Reporter. |
| 75 | +- If the vulnerability is not accepted: |
| 76 | + - **Coordinator**: Close the issue |
| 77 | + - **Coordinator**: Notify the reporter |
| 78 | +- If the vulnerability is accepted, within the relevant repositories: |
| 79 | + - **Coordinator**: Open a draft [GitHub Security |
| 80 | + Advisory](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#about-github-security-advisories) |
| 81 | + - Include relevant but sanitized details in the top level comment, which will become public |
| 82 | + - Sensitive details and reproductions go in the comments on the draft advisory, which are not |
| 83 | + public |
| 84 | + - **Coordinator**: Add relevant people to the advisory |
| 85 | + - **Developer**: Attempt to replicate the reported vulnerability. Request more information from |
| 86 | + the **Reporter** if necessary. |
| 87 | + - **Developer**: Work on the [vulnerability fix |
| 88 | + 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). |
| 89 | + - **Coordinator**/**Developer**: If appliccable, request a |
| 90 | + [CVE](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#cve-identification-numbers) |
| 91 | + from GitHub. The CVE Number will be private until the advisory is published. |
| 92 | + - **Developer & Coordinator**: Decide on release and announcement dates and post them the draft |
| 93 | + advisory. |
| 94 | + - **Coordinator**: Post the release and announcement dates on the conda-forge core chat room and |
| 95 | + mailing list. |
| 96 | + - **Developer**: Merge the security fix PR |
| 97 | + - **Developer**: Release the package and/or deploy the fix as appropriate |
| 98 | + - **Developer & Coordinator**: Draft a [blog post](https://github.com/conda-forge/blog) and other |
| 99 | + announcement texts. This can be done in parallel with the previous steps, but consider using a |
| 100 | + [private advisory](https://github.com/conda-forge/blog/security/advisories) for the text. |
| 101 | + - **Coordinator**: Publish the security advisory on the announcement date. If applicable, GitHub |
| 102 | + will post the CVE to the MITRE database. |
| 103 | + - **Coordinator**: Publish the blog post and other announcements (Element chat room, Twitter, |
| 104 | + etc) as necessary. |
| 105 | +- **Coordinator**: Notify the **Reporter** of the releases |
| 106 | +- **Coordinator**: Close the issue in the tracking repository |
| 107 | + |
| 108 | +> Notes to Developers |
| 109 | +> |
| 110 | +> - Be aware that GitHub CI workflows won't run on security forks, so reviewers must test manually |
| 111 | +> to avoid a broken CI when the patch is merged to the public repo. |
| 112 | +> - Also, vulnerabilities may involve multiple private security forks across different GitHub |
| 113 | +> organizations. |
| 114 | +> - This may require additional manual steps to include those private forks. |
| 115 | +
|
| 116 | +[coordinated-disclosure]: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#responsible-or-coordinated-disclosure |
| 117 | + |
| 118 | +--- |
| 119 | + |
| 120 | +> This document is based on the excellent [write-up](https://github.com/jupyter/security/blob/86ec517/docs/vulnerability-handling.md) used by the Jupyter community, [BSD-3 licensed](https://github.com/jupyter/security/blob/86ec517/LICENSE). |
| 121 | +
|
| 122 | + |
| 123 | + |
0 commit comments