├── .devcontainer └── devcontainer.json ├── .github ├── linters │ └── .markdown-lint.yml ├── settings.yml └── workflows │ └── linter.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── README.md ├── finder-guide.md ├── maintainer-guide.md ├── package-lock.json ├── package.json ├── runbook.md └── templates ├── notifications ├── disclosure.md └── embargo.md └── security_policies ├── email_intake.md ├── github_security_policy.md └── other_intake_systems.md /.devcontainer/devcontainer.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Markdown Linting", 3 | "image": "mcr.microsoft.com/devcontainers/javascript-node:16-bullseye", 4 | // Features to add to the dev container. More info: https://containers.dev/implementors/features. 5 | // "features": {}, 6 | // Configure tool-specific properties. 7 | "customizations": { 8 | // Configure properties specific to VS Code. 9 | "vscode": { 10 | // Add the IDs of extensions you want installed when the container is created. 11 | "extensions": [ 12 | "yzhang.markdown-all-in-one", 13 | "DavidAnson.vscode-markdownlint", 14 | "shd101wyy.markdown-preview-enhanced", 15 | "bierner.github-markdown-preview" 16 | ] 17 | } 18 | } 19 | // Use 'forwardPorts' to make a list of ports inside the container available locally. 20 | // "forwardPorts": [], 21 | // Use 'postCreateCommand' to run commands after the container is created. 22 | // "postCreateCommand": "uname -a", 23 | // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root. 24 | // "remoteUser": "root" 25 | } 26 | -------------------------------------------------------------------------------- /.github/linters/.markdown-lint.yml: -------------------------------------------------------------------------------- 1 | # Default state for all rules 2 | default: true 3 | # Line length 4 | "MD013": false 5 | # Multiple headings with the same content 6 | "MD024": false 7 | # Emphasis used instead of a heading 8 | "MD036": false 9 | -------------------------------------------------------------------------------- /.github/settings.yml: -------------------------------------------------------------------------------- 1 | repository: 2 | # See https://developer.github.com/v3/repos/#edit for all available settings. 3 | 4 | # The name of the repository. Changing this will rename the repository 5 | name: wg-vulnerability-disclosures 6 | 7 | # A short description of the repository that will show up on GitHub 8 | description: The OpenSSF Vulnerability Disclosures Working Group seeks to help improve the overall security of the open source software ecosystem by helping mature and advocate well-managed vulnerability reporting and communication. 9 | 10 | # A URL with more information about the repository 11 | homepage: https://openssf.org 12 | 13 | # Collaborators: give specific users access to this repository. 14 | # see /governance/roles.md for details on write access policy 15 | # note that the permissions below may provide wider access than needed for 16 | # a specific role, and we trust these individuals to act according to their 17 | # role. If there are questions, please contact one of the chairs. 18 | collaborators: 19 | # Chairs and Admin Help 20 | - username: MarcinHoppe 21 | permission: admin 22 | - username: RedHatCRob 23 | permission: admin 24 | - username: mdressman 25 | permission: admin 26 | 27 | # Contributors 28 | # all permissions except admin 29 | 30 | - username: caniszczyk 31 | permission: push 32 | - username: infin8x 33 | permission: push 34 | - username: esarafianou 35 | permission: push 36 | 37 | labels: 38 | - name: helpwanted 39 | color: ffff54 40 | - name: good first issue 41 | color: ff8c00 42 | - name: meeting 43 | color: 00ff00 44 | # additional colors in this palette: 45 | # 7f0000 , 1e90ff, ffdab9, ff69b4 46 | -------------------------------------------------------------------------------- /.github/workflows/linter.yml: -------------------------------------------------------------------------------- 1 | --- 2 | ################################# 3 | ################################# 4 | ## Super Linter GitHub Actions ## 5 | ################################# 6 | ################################# 7 | name: Lint Code Base 8 | 9 | ############################# 10 | # Start the job on all push # 11 | ############################# 12 | on: 13 | push: 14 | branches: [main] 15 | pull_request: 16 | branches: [main] 17 | 18 | ############### 19 | # Set the Job # 20 | ############### 21 | jobs: 22 | build: 23 | # Name the Job 24 | name: Lint Markdown 25 | # Set the agent to run on 26 | runs-on: ubuntu-latest 27 | 28 | ################## 29 | # Load all steps # 30 | ################## 31 | steps: 32 | ########################## 33 | # Checkout the code base # 34 | ########################## 35 | - name: Checkout Code 36 | uses: actions/checkout@v3 37 | with: 38 | # Full git history is needed to get a proper 39 | # list of changed files within `super-linter` 40 | fetch-depth: 0 41 | 42 | ############################################ 43 | # Run Linter against Markdown in code base # 44 | ############################################ 45 | - name: Lint Markdown 46 | uses: github/super-linter@v4 47 | env: 48 | VALIDATE_ALL_CODEBASE: false 49 | DEFAULT_BRANCH: main 50 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 51 | VALIDATE_MARKDOWN: true 52 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | lerna-debug.log* 8 | .pnpm-debug.log* 9 | 10 | # Diagnostic reports (https://nodejs.org/api/report.html) 11 | report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json 12 | 13 | # Dependency directories 14 | node_modules/ 15 | jspm_packages/ 16 | 17 | # Optional npm cache directory 18 | .npm 19 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. 6 | 7 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. 8 | 9 | ## Our Standards 10 | 11 | Examples of behavior that contributes to a positive environment for our community include: 12 | 13 | - Demonstrating empathy and kindness toward other people 14 | - Being respectful of differing opinions, viewpoints, and experiences 15 | - Giving and gracefully accepting constructive feedback 16 | - Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience 17 | - Focusing on what is best not just for us as individuals, but for the overall community 18 | 19 | Examples of unacceptable behavior include: 20 | 21 | - The use of sexualized language or imagery and unwelcome sexual attention or 22 | advances 23 | - Trolling, insulting/derogatory comments, and personal or political attacks 24 | - Public or private harassment 25 | - Publishing others' private information, such as a physical or electronic 26 | address, without explicit permission 27 | - Other conduct which could reasonably be considered inappropriate in a 28 | professional setting 29 | 30 | ## Enforcement Responsibilities 31 | 32 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. 33 | 34 | Project maintainers have the right and responsibility to remove, edit, or reject 35 | comments, commits, code, wiki edits, issues, and other contributions that are 36 | not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. 37 | 38 | ## Scope 39 | 40 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. 41 | 42 | ## Enforcement 43 | 44 | ### Enforcement Guidelines 45 | 46 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: 47 | 48 | 1. Correction 49 | 50 | **Community Impact:** Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. 51 | 52 | **Consequence:** A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. 53 | 54 | 2. Warning 55 | 56 | **Community Impact:** A violation through a single incident or series of actions. 57 | 58 | **Consequence:** A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. 59 | 60 | 3. Temporary Ban 61 | 62 | **Community Impact:** A serious violation of community standards, including sustained inappropriate behavior. 63 | 64 | **Consequence:** A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. 65 | 66 | 4. Permanent Ban 67 | 68 | **Community Impact:** Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. 69 | 70 | **Consequence:** A permanent ban from any sort of public interaction within the community. 71 | 72 | ## Attribution 73 | 74 | This Code of Conduct is adapted from the Contributor Covenant, version 2.0, available at . 75 | 76 | Community Impact Guidelines were inspired by [Mozilla’s code of conduct enforcement ladder.](https://github.com/mozilla/inclusion) 77 | 78 | For answers to common questions about this code of conduct, see the FAQ at . Translations are available at . 79 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | We'd love to accept your patches and contributions to this project. There are 4 | just a few small guidelines you need to follow. 5 | 6 | ## Code of Conduct 7 | 8 | This is a project of the [Open Source Security Foundation](https://github.com/ossf/) and follows its [Code of Conduct](https://github.com/ossf/oss-vulnerability-guide/CODE_OF_CONDUCT.md). 9 | 10 | ## Accepted Contributions 11 | 12 | This guide is reference material for open source maintainers. We encourage you to open issues and pull requests for typos, broken links, and other changes for readability and comprehension. 13 | 14 | For more substantial changes to the material, such as changing a recommendation, we encourage you to open an issue for discussion and to also engage with the [OpenSSF Vulnerability Working Group](https://github.com/ossf/wg-vulnerability-disclosures/) about the proposed change. 15 | 16 | ## Code Reviews 17 | 18 | All submissions, including submissions by project members, require review. We 19 | use GitHub pull requests for this purpose. Consult 20 | [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more 21 | information on using pull requests. 22 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | Attribution 4.0 International 4 | 5 | ======================================================================= 6 | 7 | Creative Commons Corporation ("Creative Commons") is not a law firm and 8 | does not provide legal services or legal advice. Distribution of 9 | Creative Commons public licenses does not create a lawyer-client or 10 | other relationship. Creative Commons makes its licenses and related 11 | information available on an "as-is" basis. Creative Commons gives no 12 | warranties regarding its licenses, any material licensed under their 13 | terms and conditions, or any related information. Creative Commons 14 | disclaims all liability for damages resulting from their use to the 15 | fullest extent possible. 16 | 17 | Using Creative Commons Public Licenses 18 | 19 | Creative Commons public licenses provide a standard set of terms and 20 | conditions that creators and other rights holders may use to share 21 | original works of authorship and other material subject to copyright 22 | and certain other rights specified in the public license below. The 23 | following considerations are for informational purposes only, are not 24 | exhaustive, and do not form part of our licenses. 25 | 26 | Considerations for licensors: Our public licenses are 27 | intended for use by those authorized to give the public 28 | permission to use material in ways otherwise restricted by 29 | copyright and certain other rights. Our licenses are 30 | irrevocable. Licensors should read and understand the terms 31 | and conditions of the license they choose before applying it. 32 | Licensors should also secure all rights necessary before 33 | applying our licenses so that the public can reuse the 34 | material as expected. Licensors should clearly mark any 35 | material not subject to the license. This includes other CC- 36 | licensed material, or material used under an exception or 37 | limitation to copyright. More considerations for licensors: 38 | wiki.creativecommons.org/Considerations_for_licensors 39 | 40 | Considerations for the public: By using one of our public 41 | licenses, a licensor grants the public permission to use the 42 | licensed material under specified terms and conditions. If 43 | the licensor's permission is not necessary for any reason--for 44 | example, because of any applicable exception or limitation to 45 | copyright--then that use is not regulated by the license. Our 46 | licenses grant only permissions under copyright and certain 47 | other rights that a licensor has authority to grant. Use of 48 | the licensed material may still be restricted for other 49 | reasons, including because others have copyright or other 50 | rights in the material. A licensor may make special requests, 51 | such as asking that all changes be marked or described. 52 | Although not required by our licenses, you are encouraged to 53 | respect those requests where reasonable. More_considerations 54 | for the public: 55 | wiki.creativecommons.org/Considerations_for_licensees 56 | 57 | ======================================================================= 58 | 59 | Creative Commons Attribution 4.0 International Public License 60 | 61 | By exercising the Licensed Rights (defined below), You accept and agree 62 | to be bound by the terms and conditions of this Creative Commons 63 | Attribution 4.0 International Public License ("Public License"). To the 64 | extent this Public License may be interpreted as a contract, You are 65 | granted the Licensed Rights in consideration of Your acceptance of 66 | these terms and conditions, and the Licensor grants You such rights in 67 | consideration of benefits the Licensor receives from making the 68 | Licensed Material available under these terms and conditions. 69 | 70 | Section 1 -- Definitions. 71 | 72 | a. Adapted Material means material subject to Copyright and Similar 73 | Rights that is derived from or based upon the Licensed Material 74 | and in which the Licensed Material is translated, altered, 75 | arranged, transformed, or otherwise modified in a manner requiring 76 | permission under the Copyright and Similar Rights held by the 77 | Licensor. For purposes of this Public License, where the Licensed 78 | Material is a musical work, performance, or sound recording, 79 | Adapted Material is always produced where the Licensed Material is 80 | synched in timed relation with a moving image. 81 | 82 | b. Adapter's License means the license You apply to Your Copyright 83 | and Similar Rights in Your contributions to Adapted Material in 84 | accordance with the terms and conditions of this Public License. 85 | 86 | c. Copyright and Similar Rights means copyright and/or similar rights 87 | closely related to copyright including, without limitation, 88 | performance, broadcast, sound recording, and Sui Generis Database 89 | Rights, without regard to how the rights are labeled or 90 | categorized. For purposes of this Public License, the rights 91 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 92 | Rights. 93 | 94 | d. Effective Technological Measures means those measures that, in the 95 | absence of proper authority, may not be circumvented under laws 96 | fulfilling obligations under Article 11 of the WIPO Copyright 97 | Treaty adopted on December 20, 1996, and/or similar international 98 | agreements. 99 | 100 | e. Exceptions and Limitations means fair use, fair dealing, and/or 101 | any other exception or limitation to Copyright and Similar Rights 102 | that applies to Your use of the Licensed Material. 103 | 104 | f. Licensed Material means the artistic or literary work, database, 105 | or other material to which the Licensor applied this Public 106 | License. 107 | 108 | g. Licensed Rights means the rights granted to You subject to the 109 | terms and conditions of this Public License, which are limited to 110 | all Copyright and Similar Rights that apply to Your use of the 111 | Licensed Material and that the Licensor has authority to license. 112 | 113 | h. Licensor means the individual(s) or entity(ies) granting rights 114 | under this Public License. 115 | 116 | i. Share means to provide material to the public by any means or 117 | process that requires permission under the Licensed Rights, such 118 | as reproduction, public display, public performance, distribution, 119 | dissemination, communication, or importation, and to make material 120 | available to the public including in ways that members of the 121 | public may access the material from a place and at a time 122 | individually chosen by them. 123 | 124 | j. Sui Generis Database Rights means rights other than copyright 125 | resulting from Directive 96/9/EC of the European Parliament and of 126 | the Council of 11 March 1996 on the legal protection of databases, 127 | as amended and/or succeeded, as well as other essentially 128 | equivalent rights anywhere in the world. 129 | 130 | k. You means the individual or entity exercising the Licensed Rights 131 | under this Public License. Your has a corresponding meaning. 132 | 133 | Section 2 -- Scope. 134 | 135 | a. License grant. 136 | 137 | 1. Subject to the terms and conditions of this Public License, 138 | the Licensor hereby grants You a worldwide, royalty-free, 139 | non-sublicensable, non-exclusive, irrevocable license to 140 | exercise the Licensed Rights in the Licensed Material to: 141 | 142 | a. reproduce and Share the Licensed Material, in whole or 143 | in part; and 144 | 145 | b. produce, reproduce, and Share Adapted Material. 146 | 147 | 2. Exceptions and Limitations. For the avoidance of doubt, where 148 | Exceptions and Limitations apply to Your use, this Public 149 | License does not apply, and You do not need to comply with 150 | its terms and conditions. 151 | 152 | 3. Term. The term of this Public License is specified in Section 153 | 6(a). 154 | 155 | 4. Media and formats; technical modifications allowed. The 156 | Licensor authorizes You to exercise the Licensed Rights in 157 | all media and formats whether now known or hereafter created, 158 | and to make technical modifications necessary to do so. The 159 | Licensor waives and/or agrees not to assert any right or 160 | authority to forbid You from making technical modifications 161 | necessary to exercise the Licensed Rights, including 162 | technical modifications necessary to circumvent Effective 163 | Technological Measures. For purposes of this Public License, 164 | simply making modifications authorized by this Section 2(a) 165 | (4) never produces Adapted Material. 166 | 167 | 5. Downstream recipients. 168 | 169 | a. Offer from the Licensor -- Licensed Material. Every 170 | recipient of the Licensed Material automatically 171 | receives an offer from the Licensor to exercise the 172 | Licensed Rights under the terms and conditions of this 173 | Public License. 174 | 175 | b. No downstream restrictions. You may not offer or impose 176 | any additional or different terms or conditions on, or 177 | apply any Effective Technological Measures to, the 178 | Licensed Material if doing so restricts exercise of the 179 | Licensed Rights by any recipient of the Licensed 180 | Material. 181 | 182 | 6. No endorsement. Nothing in this Public License constitutes or 183 | may be construed as permission to assert or imply that You 184 | are, or that Your use of the Licensed Material is, connected 185 | with, or sponsored, endorsed, or granted official status by, 186 | the Licensor or others designated to receive attribution as 187 | provided in Section 3(a)(1)(A)(i). 188 | 189 | b. Other rights. 190 | 191 | 1. Moral rights, such as the right of integrity, are not 192 | licensed under this Public License, nor are publicity, 193 | privacy, and/or other similar personality rights; however, to 194 | the extent possible, the Licensor waives and/or agrees not to 195 | assert any such rights held by the Licensor to the limited 196 | extent necessary to allow You to exercise the Licensed 197 | Rights, but not otherwise. 198 | 199 | 2. Patent and trademark rights are not licensed under this 200 | Public License. 201 | 202 | 3. To the extent possible, the Licensor waives any right to 203 | collect royalties from You for the exercise of the Licensed 204 | Rights, whether directly or through a collecting society 205 | under any voluntary or waivable statutory or compulsory 206 | licensing scheme. In all other cases the Licensor expressly 207 | reserves any right to collect such royalties. 208 | 209 | Section 3 -- License Conditions. 210 | 211 | Your exercise of the Licensed Rights is expressly made subject to the 212 | following conditions. 213 | 214 | a. Attribution. 215 | 216 | 1. If You Share the Licensed Material (including in modified 217 | form), You must: 218 | 219 | a. retain the following if it is supplied by the Licensor 220 | with the Licensed Material: 221 | 222 | i. identification of the creator(s) of the Licensed 223 | Material and any others designated to receive 224 | attribution, in any reasonable manner requested by 225 | the Licensor (including by pseudonym if 226 | designated); 227 | 228 | ii. a copyright notice; 229 | 230 | iii. a notice that refers to this Public License; 231 | 232 | iv. a notice that refers to the disclaimer of 233 | warranties; 234 | 235 | v. a URI or hyperlink to the Licensed Material to the 236 | extent reasonably practicable; 237 | 238 | b. indicate if You modified the Licensed Material and 239 | retain an indication of any previous modifications; and 240 | 241 | c. indicate the Licensed Material is licensed under this 242 | Public License, and include the text of, or the URI or 243 | hyperlink to, this Public License. 244 | 245 | 2. You may satisfy the conditions in Section 3(a)(1) in any 246 | reasonable manner based on the medium, means, and context in 247 | which You Share the Licensed Material. For example, it may be 248 | reasonable to satisfy the conditions by providing a URI or 249 | hyperlink to a resource that includes the required 250 | information. 251 | 252 | 3. If requested by the Licensor, You must remove any of the 253 | information required by Section 3(a)(1)(A) to the extent 254 | reasonably practicable. 255 | 256 | 4. If You Share Adapted Material You produce, the Adapter's 257 | License You apply must not prevent recipients of the Adapted 258 | Material from complying with this Public License. 259 | 260 | Section 4 -- Sui Generis Database Rights. 261 | 262 | Where the Licensed Rights include Sui Generis Database Rights that 263 | apply to Your use of the Licensed Material: 264 | 265 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 266 | to extract, reuse, reproduce, and Share all or a substantial 267 | portion of the contents of the database; 268 | 269 | b. if You include all or a substantial portion of the database 270 | contents in a database in which You have Sui Generis Database 271 | Rights, then the database in which You have Sui Generis Database 272 | Rights (but not its individual contents) is Adapted Material; and 273 | 274 | c. You must comply with the conditions in Section 3(a) if You Share 275 | all or a substantial portion of the contents of the database. 276 | 277 | For the avoidance of doubt, this Section 4 supplements and does not 278 | replace Your obligations under this Public License where the Licensed 279 | Rights include other Copyright and Similar Rights. 280 | 281 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 282 | 283 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 284 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 285 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 286 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 287 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 288 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 289 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 290 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 291 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 292 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 293 | 294 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 295 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 296 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 297 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 298 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 299 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 300 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 301 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 302 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 303 | 304 | c. The disclaimer of warranties and limitation of liability provided 305 | above shall be interpreted in a manner that, to the extent 306 | possible, most closely approximates an absolute disclaimer and 307 | waiver of all liability. 308 | 309 | Section 6 -- Term and Termination. 310 | 311 | a. This Public License applies for the term of the Copyright and 312 | Similar Rights licensed here. However, if You fail to comply with 313 | this Public License, then Your rights under this Public License 314 | terminate automatically. 315 | 316 | b. Where Your right to use the Licensed Material has terminated under 317 | Section 6(a), it reinstates: 318 | 319 | 1. automatically as of the date the violation is cured, provided 320 | it is cured within 30 days of Your discovery of the 321 | violation; or 322 | 323 | 2. upon express reinstatement by the Licensor. 324 | 325 | For the avoidance of doubt, this Section 6(b) does not affect any 326 | right the Licensor may have to seek remedies for Your violations 327 | of this Public License. 328 | 329 | c. For the avoidance of doubt, the Licensor may also offer the 330 | Licensed Material under separate terms or conditions or stop 331 | distributing the Licensed Material at any time; however, doing so 332 | will not terminate this Public License. 333 | 334 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 335 | License. 336 | 337 | Section 7 -- Other Terms and Conditions. 338 | 339 | a. The Licensor shall not be bound by any additional or different 340 | terms or conditions communicated by You unless expressly agreed. 341 | 342 | b. Any arrangements, understandings, or agreements regarding the 343 | Licensed Material not stated herein are separate from and 344 | independent of the terms and conditions of this Public License. 345 | 346 | Section 8 -- Interpretation. 347 | 348 | a. For the avoidance of doubt, this Public License does not, and 349 | shall not be interpreted to, reduce, limit, restrict, or impose 350 | conditions on any use of the Licensed Material that could lawfully 351 | be made without permission under this Public License. 352 | 353 | b. To the extent possible, if any provision of this Public License is 354 | deemed unenforceable, it shall be automatically reformed to the 355 | minimum extent necessary to make it enforceable. If the provision 356 | cannot be reformed, it shall be severed from this Public License 357 | without affecting the enforceability of the remaining terms and 358 | conditions. 359 | 360 | c. No term or condition of this Public License will be waived and no 361 | failure to comply consented to unless expressly agreed to by the 362 | Licensor. 363 | 364 | d. Nothing in this Public License constitutes or may be interpreted 365 | as a limitation upon, or waiver of, any privileges and immunities 366 | that apply to the Licensor or You, including from the legal 367 | processes of any jurisdiction or authority. 368 | 369 | ======================================================================= 370 | 371 | Creative Commons is not a party to its public 372 | licenses. Notwithstanding, Creative Commons may elect to apply one of 373 | its public licenses to material it publishes and in those instances 374 | will be considered the “Licensor.” The text of the Creative Commons 375 | public licenses is dedicated to the public domain under the CC0 Public 376 | Domain Dedication. Except for the limited purpose of indicating that 377 | material is shared under a Creative Commons public license or as 378 | otherwise permitted by the Creative Commons policies published at 379 | creativecommons.org/policies, Creative Commons does not authorize the 380 | use of the trademark "Creative Commons" or any other trademark or logo 381 | of Creative Commons without its prior written consent including, 382 | without limitation, in connection with any unauthorized modifications 383 | to any of its public licenses or any other arrangements, 384 | understandings, or agreements concerning use of licensed material. For 385 | the avoidance of doubt, this paragraph does not form part of the 386 | public licenses. 387 | 388 | Creative Commons may be contacted at creativecommons.org. 389 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Guide to coordinated vulnerability disclosure for open source software projects 2 | 3 | [![GitHub Super-Linter](https://github.com/ossf/oss-vulnerability-guide/workflows/Lint%20Code%20Base/badge.svg)](https://github.com/marketplace/actions/super-linter) 4 | 5 | This repository is a set of resources and reference materials to help open source projects perform coordinated vulnerability disclosure (CVD). 6 | 7 | ## This repository contains: 8 | 9 | * **[Guide to coordinated vulnerability disclosure for open source software projects](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md):** This contains background material on vulnerability disclosure, the steps to the CVD process, considerations for the decision points of the process, and "troubleshooting" for common scenarios. 10 | * **[Guide to coordinated vulnerability disclosure for Finders working with open source software projects](https://github.com/ossf/oss-vulnerability-guide/blob/main/finder-guide.md):** Focused on security researchers (aka "Finders"), this contains background material on vulnerability disclosure, the steps to the CVD process, considerations for the decision points of the process, and "troubleshooting" for common scenarios. 11 | * **[Templates](https://github.com/ossf/oss-vulnerability-guide/tree/main/templates):** These will help you get started with the communication components of CVD. This includes [`SECURITY.md` templates](https://github.com/ossf/oss-vulnerability-guide/tree/main/templates/security_policies), [embargoed notification](https://github.com/ossf/oss-vulnerability-guide/blob/main/templates/notifications/embargo.md) and [vulnerability disclosure](https://github.com/ossf/oss-vulnerability-guide/blob/main/templates/notifications/disclosure.md). 12 | * **[Runbook](https://github.com/ossf/oss-vulnerability-guide/blob/main/runbook.md):** A step-by-step list for the CVD process. For additional information on these steps, refer to the [Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md). 13 | 14 | ## Getting Started 15 | 16 | If you are new to coordinated vulnerability disclosure, it is recommended you start with the [Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md). While it is dense, you will want to be familiar with this information and the concepts presented *before* you need to address a vulnerability report. 17 | 18 | If you are familiar with coordinated vulnerability disclosure, you can get a refresher by skipping to the [Response Process](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#response-process) section of the Guide, or go straight to the [Runbook](https://github.com/ossf/oss-vulnerability-guide/blob/main/runbook.md). 19 | 20 | ## Feedback 21 | 22 | We welcome feedback from OSS project maintainers and security researchers on this guide. Opening a [GitHub Issue](https://github.com/ossf/oss-vulnerability-guide/issues) is the best way to send feedback (see [CONTRIBUTING.md](https://github.com/ossf/oss-vulnerability-guide/blob/main/CONTRIBUTING.md) for directions on submitting PRs). 23 | -------------------------------------------------------------------------------- /finder-guide.md: -------------------------------------------------------------------------------- 1 | # Guidance for Security Researchers to Coordinate Vulnerability Disclosures with Open Source Software Projects 2 | 3 | ## Congratulations! You found a security vulnerability 4 | 5 | Now what? This guide is intended to help security researchers (aka “[Finders](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md)”) engage with open source software (OSS) project maintainers to kick off and participate in the coordinated vulnerability response process. 6 | 7 | ## Before you begin 8 | 9 | While engaging in the vulnerability disclosure process, please keep this in mind: _no software is perfect_. Software is written by people (at least today), and people sometimes make mistakes. This is true for closed-source (proprietary) software as well as open source software (OSS). This problem can be more challenging for open source software due to the factors that make OSS so powerful: highly distributed development by multiple contributors. At some point in the project lifecycle, someone – a user, a contributor, a security researcher, and likely the reader of this guide – will find a vulnerability that affects the security and usefulness of the project. Applying this guide will help everyone involved to be prepared to respond quickly and effectively. 10 | 11 | ### About this guide 12 | 13 | This guide was produced by the contributions of individuals and the Open Source Security Foundation (OpenSSF) [Vulnerability Disclosure Working Group](https://github.com/ossf/wg-vulnerability-disclosures). This group is comprised of individuals with experience in vulnerability disclosure who have learned from common pitfalls and have developed this guide as a best-effort starting/reference point for the community. Disclosure can mean many things to different people based on their context within the process. Ultimately, security defects should be responsibly reported to software maintainers to evaluate and correct them with patches and some form of notification to downstream consumers. This group encourages [coordinated vulnerability disclosure](#what-is-coordinated-vulnerability-disclosure) (CVD) as the appropriate model for most open source projects, so the advice in this guide follows that model. The following information should be treated precisely for what it is – a set of _guidelines_ that gives Finders a high-level view of the many options available before, during, and after a coordinated vulnerability disclosure. Those involved in the disclosure should also be aware that not all advice here will apply to every open source project or every vulnerability disclosure event. Recommendations should be adjusted to fit the needs of each particular project and disclosure. The Working Group has previously released a [guide](https://github.com/ossf/oss-vulnerability-guide) focused on helping open source maintainers prepare for the CVD process and be able to intake vulnerability reports. 14 | 15 | ### What are your goals in reporting the vulnerability you discovered? 16 | 17 | The following framework was developed by [I Am The Cavalry](https://iamthecavalry.org/2016/12/11/motivations/) and aims to cover the major categories of motivations for researching security vulnerabilities. While the below framework is not comprehensive, it gives a basic understanding of why a researcher may have found the issue. The same motivations often apply to their motivations for reporting the vulnerability. 18 | 19 | 1. **Protect** – make the world a safer place. These researchers are drawn to problems where they feel they can make a difference. 20 | 2. **Puzzle** – tinker out of curiosity. This type of researcher is typically a hobbyist driven to understand how things work. 21 | 3. **Prestige** – seek pride and notability. These researchers often want to be the best or well-known for their work. 22 | 4. **Profit** – to earn money. These researchers trade on their skills as a primary or secondary income. 23 | 5. **Protest/Patriotism** – ideological and principled. These researchers, whether patriots or protestors, strongly support or oppose causes. 24 | 25 | ### Who is an open source maintainer? 26 | 27 | An **open source maintainer** is often a software engineer and contributor to an open source project. They typically have elevated permissions to code repositories that allow them to manage the repository’s settings and have write access to the main branch. They’re usually the ones to merge pull requests and patches to the main branch and control what’s included in a release, including security patches. OSS projects can have one to many maintainers depending on their size, maturity, and interests. Larger open source projects can even have dedicated individuals or teams that solely conduct security-related tasks for that community. Not all open source projects are organized or developed exactly the same way. The majority of open source code out there is developed by one or two-person groups. As they gain external interest and contributions, many of these projects will grow into a bigger community, perhaps even growing to the size of having a whole foundation to support the developers and community. Some OSS projects are created by commercial vendors, but most are not. Some projects are bundled within a “distro” or distribution that collects and curates the content provided by that group and ideally provides security support. Still, as many of these communities are made up of volunteers or professionals donating their time to a passion project or as a hobby, there is no guarantee of security support. As the Finder interacts with the software maintainer, it will be important to understand the level of organization the project has and its capabilities and tailor the interactions with them accordingly. For example, a two-person maintained project may not have the testing infrastructure or tooling to perform security scanning and validation. In contrast, something with a distro or commercial support might have a dedicated team of trained application security engineers. While reporting a security flaw to either is the start of a good interaction, the former may require more involvement to see through to completion. At the same time, the latter may introduce concepts like long embargoes or the need to involve more individuals to complete the creation and testing of remediation steps. 28 | 29 | ### What are open source maintainers' motivations? 30 | 31 | Much like finders and security researchers, open source maintainers have a variety of motivations driving them to maintain a project that includes: 32 | 33 | - They are solving a problem or writing an academic project 34 | - They are having fun and/or learning something new skill/technology 35 | - They started this project as a hobby and aren't paid to maintain it 36 | - They are seeking recognition from their peers or feel maintaining the project will further their careers 37 | - They use open source as part of their jobs and feel strongly about giving back to the community 38 | - They started this project because they’re paid to do so 39 | - They use a library, and were the only ones to step up as a maintainer 40 | 41 | It’s important to emphasize the volunteer capacity of open source maintainers/projects. Expectations for interactions should be set with the understanding that timelines may be longer than when working with a commercial entity. The human interaction during the submission/triage/remediation process will also likely differ. Open source maintainers may have a more direct and technical communication style. Researchers should remember that maintainers are not taking this approach out of malice or disrespect. Instead, the interaction should always be perceived through positive intentions and understanding that the maintainer is working hard, often in a volunteer capacity, to keep their project supported and healthy. 42 | 43 | To read more about open source contributors, the Linux Foundation published a [report](https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf) that details many aspects of FOSS maintainers and contributors. 44 | 45 | ### What is Coordinated Vulnerability Disclosure? 46 | 47 | Coordinated vulnerability disclosure (CVD) is the process of sharing vulnerability details with the person or group who has the ability to respond and fix, and/or remediate the vulnerability. This is typically the open project maintainer, but could include project developers, collaborators, administrators, or other invested parties. 48 | 49 | The CVD process involves privately disclosing the vulnerability details, creating and testing a fix for the vulnerability, and then disclosing the fix and details with all downstream consumers simultaneously. This coordination ensures that all required parties are prepared with fixes, communications, updates at the same time. The benefits of disclosing a vulnerability through this method is that there is a fix available to all consumers at the same time, and no one group is put more at risk than others. 50 | 51 | Maintaining an information embargo during the mitigation and patching phase is key to protecting the users here. 52 | 53 | ### Understanding how the project handles vulnerabilities (aka “Security Policy”) 54 | 55 | Open source projects should share the expectations for contributors and finders on how it handles defect reports, both from the operational/quality perspective as well as when security vulnerabilities are discovered. This is typically communicated through a stated policy on how the project triages and addresses reports. A security policy should outline a project's handling expectations for vulnerability-related information. This policy typically includes: 56 | 57 | - Information about how vulnerability information should be reported to the project (email, issue tracker, etc.) 58 | - How sensitive information should be handled (encryption, [TLP markers](https://www.first.org/tlp/)) 59 | - What a reporter can expect after submitting a vulnerability report (response timelines, potential handling decisions, aka “Bug Bar”) 60 | - Legal safe harbor (an explicit statement that promises no legal action will be taken against vulnerability reports made in good faith) 61 | 62 | A security policy can look like a [SECURITY.md](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) file in a repository or a [SECURITY.txt](https://securitytxt.org/) file on the project’s website or information on company’s/project’s website itself. These files typically include contact information for the project’s security team as well as the information included above. 63 | 64 | While a security policy should explain how a report should be submitted and how the project will handle it, there are many report intake methods through which a vulnerability report can be submitted. This detail should be included explicitly within the security policy. Vulnerability submission intakes can range from simply listing a security-related email address (where the reporter submits a new/potential vulnerability via the security@ email alias), a defect/issue tracker, or submission through a third-party VDP or bug bounty platform. Following a project's publicly available handling expectations will show that you’re open to collaborating on this issue and increases the chance that your issue will be addressed quickly. 65 | 66 | Another component of a security policy is the clarification around rewards. A Vulnerability Disclosure Program (VDP) typically does not implicitly include a reward structure for vulnerabilities reported. Coordinating the timing of any public disclosure is an essential practice to be followed. When a program offers financial rewards, it is often called a Bug Bounty Program (BBP). At their core, BBPs serve the same purpose/goal as a VDP, facilitating a channel to report vulnerabilities to the project maintainers. They will have a clearly communicated Security Policy containing the same components as a VDP, with the possible inclusion of a clearly defined asset scope. 67 | 68 | No matter the type of intake method the project chooses, it is critical to thoroughly read the security policy when reporting vulnerabilities. Some policies include non-disclosure policies (ie. NDA) that may prevent you from disclosing the details of the vulnerability to the public or a 3rd party without permission from the maintainer or maintainer organization. While exceptionally rare for BBPs covering open source, you may encounter this type of agreement when working with a commercial entity that supports an open source project and runs a private or invitation-only BBP. These may occasionally be subject to stricter disclosure requirements. As with any agreement, it's recommended that you read the terms carefully. 69 | 70 | When you’re attempting to locate the vulnerability reporting method or security policy for a specific project, open source databases like [disclose.io](https://disclose.io/programs/) are another possible source to reference. If the project is a part of the CVE program as a CVE Naming Authority (CNA), then their contact information and security policy are included in the CVE Program’s [List of Partners](https://www.cve.org/PartnerInformation/ListofPartners). 71 | 72 | #### Additional Sources for Finding the CVD Channel of a project 73 | 74 | If you cannot find any clearly defined security contact information, try these solutions: 75 | 76 | 1. Publicly request a security contact using an issue tracker 77 | 2. Reach out to the project maintainer, owner, or most active contributors via email, social media, or the project’s real-time chat system 78 | 3. Understand if the project is part of a larger community or a Foundation that may have contacts or even a dedicated security team 79 | 4. Reach out to commercial vendors that may embed or support the project 80 | 5. Contact relevant mailing lists, such as [oss-security](https://www.openwall.com/lists/oss-security/), and state you have a private issue you wish to disclose to the project 81 | 6. Reach out to 3rd party organizations like MITRE/CVE or CERT/CC for assistance in coordination 82 | 83 | When using any of these solutions, avoid sharing sensitive information until you’ve set up an appropriate communication channel with the right people. 84 | 85 | ### Set up your Report for Easy Intake & Disclosure 86 | 87 | _Suggestion: Write your initial disclosure for **public consumption** as well as for the maintainer you are contacting. This will prevent you from needing to rewrite your report for public consumption at the end of the vulnerability handling process._ 88 | 89 | ### Provide Useful Information 90 | 91 | Your vulnerability report should have enough vulnerability details in it so that the maintainer can reproduce the issue themselves. Be sure to include any public references as well. Some questions you should answer in your report include: 92 | 93 | - What problem did you find? 94 | - What versions do you believe are vulnerable? 95 | - What is the vulnerable product, package, or project? 96 | - What steps did you take to find the vulnerability? 97 | - Include any specific software and hardware requirements needed to reproduce the vulnerability. 98 | - If you have a proof-of-concept (POC) or example exploit, include it after you have established a secure channel to the maintainer or project security members. 99 | - What lines in the source code of the project are vulnerable? 100 | - Are you able to identify the root cause? 101 | - Can you identify when this was introduced? 102 | - What is the impact if exploited? 103 | - Can you estimate the severity ([CVSSv3.1](https://www.first.org/cvss/v3.1/specification-document)) score? Be aware that the maintainer/project may revise your scoring since they are experts in the code. This is an opportunity to educate them on how the flaw works and talk through impacts with them. 104 | - What [CWE](https://cwe.mitre.org/) does the vulnerability fall under? CWE information helps categorize the attack - physical, memory (buffer overflow), ROP, etc. This will help see where the issues falls under and provides information for the maintainer to potentially find any other related vulnerabilities. 105 | - Are you aware if this is actively being exploited? 106 | - Can you suggest any remediation or mitigation steps? This will almost always help speed the resolution of the vulnerability. Patches are always welcome. 107 | - Do you have any time constraints that affect this disclosure (submitted to a conference, existing expected date of disclosure, personal disclosure policy)? 108 | - Has this information been shared with anyone else, and if so, when and how? 109 | - Are you willing to meet virtually with the maintainer to demonstrate what you’ve found? 110 | 111 | An example/template vulnerability report [template](https://github.com/ossf/oss-vulnerability-guide/blob/main/templates/notifications/disclosure.md) is included in the [appendix](#templatesexamples) below. 112 | 113 | ## Disclosure 114 | 115 | Although vulnerability disclosure has been normalized significantly over the past decade, there are still some parties who may resist disclosure of the vulnerabilities in their software. This may be because they are new to the process or do not have the correct capabilities or resources to manage a vulnerability disclosure process. Always assume positive intent when reporting to open source maintainers, especially in the light that they may be unpaid volunteers or just someone that loves writing code and may not have the training and background to understand what is being reported to them. 116 | 117 | ### Properly setting expectations for the disclosure 118 | 119 | When going into vulnerability disclosure, it’s advisable to declare your own goals and expectations **early** so that all parties understand the boundaries of the engagement. 120 | 121 | While most vulnerability disclosures go well, sometimes maintainers are unresponsive, there are disagreements about the vulnerability's impact, or the maintainers may prioritize other work over fixing a vulnerability. Stating an up-front vulnerability disclosure timeline can set clear expectations around how and when disclosure will occur. These clear deadlines will help ensure that the maintainer has a reasonable amount of time to fix the vulnerability, that users aren’t left unaware for an extended period of time, and that a fix is released as soon as possible. 122 | 123 | #### A note about software development 124 | 125 | Typically, software developers will follow a Software Development Life-cycle ([SDL](https://snyk.io/learn/secure-sdlc/)) model, consisting of at least some of the following phases that lead from one to the other. The process is usually iterative and cycles back from the bottom to the top ([more info in this article](https://opensource.com/article/18/8/visualizing-devops-essentials-mindset)): 126 | 127 | - **Gathering requirements** - identify the problem(s) and prioritize. 128 | - **Design** - Analyze the gathered requirements and understand how to fulfill them. 129 | - **Development** - Write the code that implements the design, review and approve it. 130 | - **Verification** - Verify that the code solves the problem without creating new issues or regressing existing functionality. 131 | - **Release** - Build and package the new code so users can leverage the solution to their goals. 132 | - **Maintenance/ Monitoring/ Collect feedback** - Maintain the solution over time while collecting feedback that forms the basis for the next iteration’s requirements. 133 | 134 | In general, collaborating externally as a vulnerability finder with an open source project team will occur during the final maintenance/collecting feedback phase, and the intent is that the vulnerability is prioritized high so that the next cycle will include the fix for it. 135 | 136 | ### Disclosure Options 137 | 138 | We have listed some of the most common disclosure methods below. These are not exclusive of one another and can sometimes overlap or daisy chain in some fashion. Whichever route you adopt is up to you, but the OpenSSF also takes the liberty of offering its guidance here. At a high level, this guidance is that any form of vulnerability disclosure is done in a coordinated fashion, following the CVD guidelines throughout this document. Below is a list of disclosure options that explain what that disclosure may look like. Unless specifically noted, each of these should be done as a joint effort between the finder and the project. 139 | 140 | Coordinating vulnerability disclosures generally involves a healthy collaboration between the finder and the project maintainers. Many details need to be agreed upon for a smooth disclosure, so we suggest discussing those early in every CVD instance between both parties. 141 | 142 | A small note about the disclosure text here; we recommend researchers consider the content of their report to be as complete as possible early in the process. A complete analysis and report saves considerable time and effort as it can be re-used as a security advisory, disclosure note, blog post, and initial report. 143 | 144 | 145 | 146 | 147 | 149 | 151 | 153 | 155 | 156 | 157 | 159 | 161 | 163 | 165 | 166 | 167 | 169 | 175 | 177 | 179 | 180 | 181 | 183 | 185 | 187 | 189 | 190 | 191 | 193 | 195 | 197 | 199 | 200 | 201 | 203 | 207 | 209 | 211 | 212 |
Disclosure Option 148 | Description 150 | Example Scenarios 152 | OpenSSF preferred 154 |
No Disclosure 158 | The finder keeps the information to themselves and does not share it with the maintainer, the public, or with others in private. 160 | Corporate Situation 162 | 164 |
Coordinated 168 | CVD (Coordinated Vuln Disclosure) involves “gathering information from vulnerability finders, coordinating the sharing of that information between relevant stakeholders, and disclosing 170 |

171 | the existence of software vulnerabilities and their mitigations to various stakeholders, including 172 |

173 | the public” - Definition from CERT/CC 174 |

176 | X 178 |
Limited 182 | Publicly disclosing part of the information around the vulnerability, but keeping some information private (i.e. not releasing a POC) 184 | Non-Disclosure Agreement (NDA) in place, trusted partners, … 186 | X 188 |
Full 192 | Publicly announcing the full details (research, finding results and proof of concepts in some cases) of the vulnerability 194 | Full disclosure on a third party platform 196 | X 198 |
0-day 202 | Not for money / Full Disclosure: Researchers sometimes do not wish to get money for their work, and fully disclose vulnerabilities and proofs of concept, leaving products impacted vulnerable until fixed and patched. 204 |

205 | Selling: For-Profit in general, this generally means the researcher sells their findings with private firms offering bounty for undisclosed vulnerabilities. 206 |

208 | 210 |
213 | 214 | 215 | #### Getting a CVE ID 216 | 217 | A [CVE ID](https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryRecord#) is a unique identifier for a vulnerability. If a vulnerability exists in software that is, in any way, shipped to an end user, it should receive a CVE. Having a CVE identifier for your vulnerability helps ensure that it is not confused with another vulnerability and increases the likelihood that end-users and the security community will see and address the issue. Many vulnerability response processes rely on a CVE being assigned to a vulnerability to review and remediate it. CVEs help users learn about security risks in specific systems versions so they can choose to update to patched versions. 218 | 219 | A reporter can obtain a [CVE identifier](https://www.cve.org/ResourcesSupport/Glossary) from the CVE program at any point during the disclosure process. This can and should be done _after_ reporting it to the maintainer, but ideally, before public disclosure so the identifier can be included. [To get a CVE,](https://cve.mitre.org/CVEIDsAndHowToGetThem.pdf) the reporter or maintainer should reach out to the appropriate CVE Numbering Authority ([CNA](https://www.cve.org/PartnerInformation/ListofPartners)). CNAs are organizations that are authorized to assign CVE identifiers to new vulnerabilities. [CNAs](https://cve.mitre.org/cve/cna/resources.html)have various scopes and do not issue CVEs outside of their [scope](https://cve.mitre.org/cve/cna/CNA_Rules_v3.0.pdf). The project maintainers may have already established a relationship with one CNA whose scope covers the project and to whom they will go first for a CVE assignment. Reporters should collaborate with the maintainer to get a CVE whenever possible. [MITRE](https://www.cve.org/PartnerInformation/ListofPartners/partner/mitre), the organization that manages CVE administration, is also a [“CNA of Last Resort” for open source projects](https://cveform.mitre.org/) and can be used if no more appropriately scoped CNA is available. 220 | 221 | **Alternative Vulnerability Identifiers. Formats, and Databases** 222 | 223 | In addition to CVE, many other vulnerability identifiers, formats, and databases exist that you may see used across the security industry. CVE exists as a vulnerability identifier, and the program also [hosts a database of this information](https://www.cve.org/Downloads). Vulnerabilities can be assigned different or complimentary identifiers depending on where the information has been shared: 224 | 225 | - [GitHub Security Advisory (GHSA) ID](https://github.com/advisories) - vulnerability advisories published by [repository administrators](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories) receive a GHSA ID associated with it 226 | - [Open Source Vulnerability (OSV) Database](https://osv.dev/list) and [OSV Schema](https://ossf.github.io/osv-schema/) 227 | - [Global Security Database (GSD)](https://gsd.id/) - and the [GSD request form](https://requests.globalsecuritydatabase.org/) 228 | - [National Vulnerability Database (NVD)](https://nvd.nist.gov/) - the U.S. government repository of standards based vulnerability management data (like CVE) represented using the Security Content Automation Protocol (SCAP) 229 | 230 | ## Troubleshooting common challenges to Coordinated Vulnerability Disclosure 231 | 232 | Sometimes, the coordinated vulnerability disclosure process does not go smoothly. In this section, we offer advice for a few potential challenges you may encounter. 233 | 234 | **_The project maintainers did not consider my report a security issue_** 235 | 236 | If your vulnerability report was not considered a security issue by the maintainers, you could ask direct questions behind that decision to gain a better understanding of the rationale. Check if the maintainer engaged with domain experts to gather additional views and opinions. Ask if any aspects of the report were unclear, and make sure the following components were included in your original report and/or any follow-up communications: 237 | 238 | - In which lines of code is the vulnerability located? 239 | - How specifically does this vulnerability create a security risk? 240 | - If the project leaves the code as it is, what could an attacker ultimately do? 241 | - How can the project replicate the issue? / Do you have a working proof-of-concept that you would be willing to show the team? 242 | - What would the project have to do to fix the issue? 243 | 244 | If you are willing to invest additional time to help the project better understand the issue so that they can fix it, make this clear to the maintainer. If they accept this extra help, be respectful of their time and collaborative and straightforward in your approach so that you can work together to remediate the vulnerability. 245 | 246 | **_Notes on 0-day Vulnerabilities_** 247 | 248 | According to Trendmicro, a zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched. An exploit that attacks a zero-day vulnerability is called a zero-day exploit. ([source](https://www.trendmicro.com/vinfo/us/security/definition/zero-day-vulnerability)) 249 | 250 | 0-day vulnerabilities can be released via a public blog, mailing list, or shared via channels like Twitter and/or the [Seclist Full Disclosure Mailing List](https://seclists.org/fulldisclosure/). When using this disclosure path, you should still attempt to get a CVE ID and include that in your initial disclosure. If the assisting CNA is unwilling to issue you a CVE ID, for whatever reason, the CVE system has a formal [appeals process](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_9_appeals_process). 251 | 252 | ## **Acknowledgements** 253 | 254 | Thank you to the wider security and open source communities whose work informed this guide, including the [Google Open Source Programs Office and Google security teams](https://github.com/google/oss-vulnerability-guide), the [OpenStack Vulnerability Management Process](https://security.openstack.org/vmt-process.html), [Project Zero's disclosure process](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html), and the [Kubernetes security and disclosure process](https://kubernetes.io/docs/reference/issues-security/security/). We also would like to highlight the many resources we leveraged from [MITRE](https://www.mitre.org/) on the creation of this paper. 255 | 256 | ## Appendices 257 | 258 | ### Glossary 259 | 260 | For a Glossary of terms and their definitions, please refer to the OpenSSF’s Education SIG’s [Terminology repository](https://github.com/ossf/education/tree/main/terminology). 261 | 262 | ### Bibliography 263 | 264 | You can also find this bibliography—along with webpage snapshots—in [this Zotero group](https://www.zotero.org/groups/4751027/openssf_researcher_cvd_guide). 265 | 266 | - A. D. Householder, G. Wassermann, A. Manion, and C. King, “The CERT Guide to Coordinated Vulnerability Disclosure,” Special Report CMU/SEI-2017-SR-022, Aug. 2017. [Online]. Available: [https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) 267 | - Cloud Security Alliance, “Global Security Database (GSD),” [https://github.com/cloudsecurityalliance/gsd-database](https://github.com/cloudsecurityalliance/gsd-database) 268 | - disclose.io Community, “The disclose.io Project,” [https://disclose.io/programs/](https://disclose.io/programs/) 269 | - EdOverflow and Y. Shafranovich, “security.txt,” security.txt. [https://securitytxt.org/](https://securitytxt.org/) 270 | - FIRST.org, “CVSS v3.1 Specification Document,” _FIRST — Forum of Incident Response and Security Teams_. [https://www.first.org/cvss/v3.1/specification-document](https://www.first.org/cvss/v3.1/specification-document) 271 | - FIRST - Forum of Incident Response and Security Teams, "Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure - Version 1.1," Spring 2020. [https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1](https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1) 272 | - FIRST — Forum of Incident Response and Security Teams, “Traffic Light Protocol (TLP): FIRST Standards Definitions and Usage Guidance — Version 2.0,” Aug. 2022. [https://www.first.org/tlp](https://www.first.org/tlp) 273 | - GitHub, “About GitHub Security Advisories for repositories.” [https://ghdocs-prod.azurewebsites.net/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories](https://ghdocs-prod.azurewebsites.net/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories) 274 | - GitHub, “Adding a security policy to your repository,” GitHub Docs. [https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) 275 | - GitHub, “GitHub Advisory Database.” [https://github.com/advisories](https://github.com/advisories) 276 | - Google, “Guide to coordinated vulnerability disclosure for open source projects,” [https://github.com/google/oss-vulnerability-guide](https://github.com/google/oss-vulnerability-guide) 277 | - Google, “Project Zero: Vulnerability Disclosure FAQ,” Project Zero Blog. [https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html) 278 | - Google, “Vulnerability Database - OSV.” [https://osv.dev/list](https://osv.dev/list) 279 | - I am the Cavalry, “5 Motivations of Security Researchers,” I Am The Cavalry, Dec. 12, 2016. [https://iamthecavalry.org/2016/12/11/motivations/](https://iamthecavalry.org/2016/12/11/motivations/) 280 | - Kubernetes Community, “Kubernetes Security and Disclosure Information.” [https://kubernetes.io/docs/reference/issues-security/security/](https://kubernetes.io/docs/reference/issues-security/security/) 281 | - Linux Foundation & The Laboratory for Innovation Science at Harvard, “Report on the 2020 FOSS Contributor Survey,” Dec. 2020. [https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf](https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf) 282 | - MITRE, “CNA Rules: CNA of Last Resort (CNA-LR).” [https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4_cna_of_last_resort_cna-lr](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4_cna_of_last_resort_cna-lr) 283 | - MITRE, “CVE Glossary.” [https://www.cve.org/ResourcesSupport/Glossary](https://www.cve.org/ResourcesSupport/Glossary) 284 | - MITRE, “List Of Partners | CVE.” [https://www.cve.org/PartnerInformation/ListofPartners](https://www.cve.org/PartnerInformation/ListofPartners) 285 | - MITRE, “Submit a CVE Request.” [https://cveform.mitre.org/](https://cveform.mitre.org/) 286 | - MITRE and the CWE Community, “CWE - Common Weakness Enumeration.” [https://cwe.mitre.org/](https://cwe.mitre.org/) 287 | - OpenSSF Vulnerability Disclosures Working Group, “Guide to coordinated vulnerability disclosure for open source software projects,” [https://github.com/ossf/oss-vulnerability-guide](https://github.com/ossf/oss-vulnerability-guide) 288 | - OpenSSF Vulnerability Disclosures Working Group, “Vulnerability Disclosures Working Group repository,” [https://github.com/ossf/wg-vulnerability-disclosures](https://github.com/ossf/wg-vulnerability-disclosures) 289 | - OpenStack, “Vulnerability Management Process.” [https://security.openstack.org/vmt-process.html](https://security.openstack.org/vmt-process.html) 290 | - seclists.org, “Full Disclosure Mailing List.” [https://seclists.org/fulldisclosure/](https://seclists.org/fulldisclosure/) 291 | - Vulnerability Disclosures Working Group, “Open source vulnerability disclosure personas.” [https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md) 292 | 293 | ### Templates/Examples 294 | 295 | - [Disclosure template](https://github.com/ossf/oss-vulnerability-guide/blob/main/templates/notifications/disclosure.md) (from maintainer guide) 296 | - [Embargo template](https://github.com/ossf/oss-vulnerability-guide/blob/main/templates/notifications/embargo.md) (from maintainer guide) 297 | - Personal vulnerability disclosure policy example 298 | - Vulnerability report submission example 299 | - Bug report example 300 | - [https://github.com/ossf/wg-vulnerability-disclosures/pulls](https://github.com/ossf/wg-vulnerability-disclosures/pulls) 301 | -------------------------------------------------------------------------------- /maintainer-guide.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # Guide to implementing a coordinated vulnerability disclosure process for open source projects 4 | 5 | **Table of Contents** 6 | 7 | - **[Before you begin](#before-you-begin)** 8 | - [About this guide](#about-this-guide) 9 | - [Who's a vulnerability reporter?](#whos-a-vulnerability-reporter-aka-finder) 10 | - [What does the vulnerability reporter want?](#what-does-the-vulnerability-reporter-want) 11 | - **[Set up the vulnerability management _infrastructure_](#set-up-the-vulnerability-management-infrastructure)** 12 | - [Create a vulnerability management team (VMT)](#create-a-vulnerability-management-team-vmt) 13 | - [Set up report intake](#set-up-report-intake) 14 | - [Enable private patch development](#enable-private-patch-development) 15 | - [Establish a CNA contact](#establish-a-cna-contact) 16 | - [Create an embargo list](#create-an-embargo-list) 17 | - [Select communication templates](#select-communication-templates) 18 | - **[Publish your vulnerability management process](#publish-your-vulnerability-management-process)** 19 | - **[Apply the vulnerability response process](#apply-the-vulnerability-response-process)** 20 | - [Runbook](#runbook) 21 | - [Response process](#response-process) 22 | - **[Troubleshooting common challenges to Coordinated Vulnerability Disclosure](#troubleshooting-common-challenges-to-coordinated-vulnerability-disclosure)** 23 | - **[Acknowledgements](#acknowledgements)** 24 | 25 | ## Before you begin 26 | 27 | This guide is intended to help open source project maintainers create and maintain a coordinated vulnerability response process. 28 | 29 | No software is perfect. Software is written by people or artificial intelligence, and both sometimes make mistakes. 30 | This is true for closed source as well as open source software. For open source software (OSS), this problem can be more challenging due to the very factors that make OSS so powerful - 31 | highly distributed development by multiple contributors. 32 | At some point in the life of your project, someone--a user, a contributor, or a security researcher--will find a vulnerability that affects the safety and usefulness of your project. 33 | Applying this guide will help you be ready. 34 | 35 | ### About this guide 36 | 37 | This guide was produced by the contributions of individuals and the Open Source Security Foundation Vulnerability Disclosure Working Group. 38 | The OpenSSF Vulnerability Disclosure Working Group believes coordinated vulnerability disclosure (sometimes called "responsible disclosure") is the appropriate model for most open source projects. The advice in this guide follows that model. Not all advice in this guide applies to all open source projects; projects may need to modify the recommendations and materials to fit their project. 39 | 40 | ### Who's a vulnerability reporter (aka "finder")? 41 | 42 | A vulnerability reporter, aka finder, is someone who reports a vulnerability to a project. There's no single example of how security issues are reported or why people report them. That's one of the things that can make vulnerability management and disclosure tricky: the human on the other side is, well, a human who has their own wants, needs, and interests out of vulnerability disclosure. This is one reason why the phrase "coordinated vulnerability disclosure" (CVD) is now preferred over "responsible disclosure." There are, in general, at least two parties involved, the reporter(s) and project representative(s), and you need to _coordinate and work together!_ 43 | 44 | The OpenSSF Vulnerability Disclosure working group uses [personas]() to describe persons/roles that interact within the CVD process. A vulnerability reporter is one of those personas and is often called a [finder](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md#finder) within the security community. This reporter persona represents many different diverse and divergent desires around reporting a security vulnerability to a developer. 45 | 46 | _Very_ broadly, reporters fall into two camps: those with a direct connection to the project and those with an indirect connection. Direct reporters are active users of the project or were hired to do work on behalf of a direct user. Because they are direct users, or work for one, direct reporters are strongly motivated to ensure that an issue is patched and smoothly rolled out. They might _want_ to help develop and test a patch—they have a reason to see the problem through to a fix. 47 | 48 | Indirect reporters may be security researchers, people doing penetration testing or security audits, or may stumble across an issue in your project due to chasing a problem in a dependent project. They may want to be highly involved in the patching and disclosure process, including coordinating publicity for their work, or just want to send over the issue and not be involved further. 49 | 50 | Note that in some cases the reporter might actually be a contributor or even a maintainer of the project. In such cases coordination should be easy but the same process should basically be followed. In particular, proper public disclosure should still be done so that all interested parties are made aware and can take proper corrective action. 51 | 52 | **Reporters have done your project a favor by telling you about a vulnerability.** 53 | Reporters will have many possibly complex motivations and desires in reporting a potential vulnerability to a project. 54 | Unfortunately, there are incentives not to report vulnerabilities, sometimes including cash. 55 | Having clearly established expectations around vulnerability reporting and the project's triage and handling practices will help eliminate friction as the issue moves towards resolution. 56 | Ultimately the goal of using CVD is to reduce the risk to [Consumers](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md#consumer) of that software. 57 | 58 | It is important to thank reporters for taking the time to find the developer and go through the project's process. One of the ways to do that is to make sure the project's process of issue intake is as discoverable, smooth, and low-friction as possible. Additional methods to thank reporters will be shared later in the [Response Process](#response-process)). 59 | 60 | ### What does the vulnerability reporter want? 61 | 62 | When someone finds a security vulnerability and reports it to your project, their main goal is to get you to **fix the vulnerability to help make your project more secure**. Thus, they are looking for a project maintainer or contributor to patch the vulnerability so that when users update to the most recent version of the software, they are no longer vulnerable to the software flaw that was reported. 63 | 64 | Often, vulnerability reporters may want other ancillary things to happen. Examples of normal, reasonable things a finder may ask for include: 65 | 66 | - **CVE issuance**: Security flaws in specific commercial or OSS products or projects are often issued CVE numbers to refer to a specific vulnerability in a specific version of a product. CVE numbers help users of systems learn about security risks in specific versions of those systems so that they can choose to update to patched versions instead. Security researchers may seek to obtain a CVE ID for their reported vulnerability from a recognized [CNA](https://cve.mitre.org/cve/cna.html). This is normal and safe to do and will not cost you anything or harm your project. If you want, you can [learn more about the CVE program here](https://cve.mitre.org/about/faqs.html#what_is_cve) or on the [Common Vulnerabilities and Exposures wikipedia page](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures). 67 | - **Acknowledgment**: Giving vulnerability researchers credit for their contributions is a typical way to acknowledge the value they have offered to your project. Typically, this is included in the patch notes when an update is issued. 68 | - **Ability to issue a Technical Advisory**: Sometimes security researchers will seek to publish a Technical Advisory on their (or their employer's) website on the day on which you release the patch which fixes the reported security flaw(s). A Technical Advisory serves to both improve user awareness of the security updates to encourage them to patch and mitigate risk, as well as to profile the researcher's finding. Co-issuance of Advisories on the release date of fixes for security flaws is common practice across both open-source and commercial software. A typical Technical Advisory will include a summary of the report, the impact of the vulnerability, details about the vulnerability, recommendations to the developer and/or end users, and a timeline of communication milestones between the vendor/affected project and the vulnerability reporter. 69 | 70 | Security researchers who report vulnerabilities to your project unsolicited (unless as part of an official bug bounty program that you may choose to run) should never ask you for money in exchange for details about security findings that they are reporting to you. 71 | 72 | ## Set up the vulnerability management infrastructure 73 | 74 | It's important to be ready for a vulnerability report _before_ you get a report. [Preparing to receive a vulnerability report is required to get a CII Best Practices badge](https://bestpractices.coreinfrastructure.org/criteria/0##vulnerability_report_process). This section explains how to get ready; the following sections will walk through how actually to handle a vulnerability report. 75 | 76 | ### Establish project's vulnerability handling expectations (aka "Security Policy") 77 | 78 | Every project has different goals, capabilities, and norms. A critical first step to addressing security vulnerabilities is to share with downstream consumers or collaborators how the project will take in vulnerability reports and what a reporter's expectations of communication and response should be. Larger, more experienced projects will possibly have a dedicated team (see VMT below) of security specialists that have experience within open source of fixing security bugs. Small-to-medium-sized projects most likely will not have access to these trained professionals, or that type of work is simply out of their scope. It is important to understand that all software will have defects; some of those defects will have security-impacting aspects (impacting data's confidentiality, integrity, availability, or auditability). A small bit of preparation at the start of a project can ensure the team talks about and documents what they will do when these types of reports arise. 79 | 80 | Processes and tooling do not need to be complex and burdensome to the maintainers and contributors, but the following should be clearly documented by the project to ensure a reporter can get the bug report to the responsible developers: 81 | 82 | - How to contact the team about a potential security vulnerability 83 | - The vulnerability report can be kept private until such time the project decides to share more broadly 84 | - The reporter's expectations on communication/collaboration around the issue are properly set 85 | 86 | An example template for open source projects for a basic security policy can be found within this OpenSSF repository. Projects can reuse it with a few minimal changes or borrow any elements useful in their existing documentation. 87 | 88 | This guide will address these topics and other options that more experienced teams could follow in this section. 89 | 90 | ### Create a vulnerability management team (VMT) 91 | 92 | To keep security issues on a "need to know" basis while they're being resolved, you need a small team who can be available to respond to issues and can be trusted to keep them confidential while they're being addressed. 93 | This small team that manages vulnerability reports is your vulnerability management team (VMT). 94 | 95 | The VMT's primary responsibility is coordination: they will be the reporters' point of contact throughout the process, keep the reporters informed (if they'd like to be), and keep the security issue moving through the process. 96 | You will want some team members to be familiar with the project's release mechanisms and security, but that does not need to be everyone. Part of "coordinating" is knowing when and who to bring in when you need help beyond your team's knowledge. 97 | 98 | If you have a small project (1-5 maintainers), its maintainers may be the VMT. In a larger project, you may want to split this work amongst your maintainers or a subset of them. 99 | 100 | _Recommendation:_ For larger projects, select 3-7 team members with experience in security, engineering, and program management. For smaller projects, select trusted maintainers (this may be all maintainers). Where practical, you’ll want to divide the responsibilities among maintainers. Make sure at least 2 team members have the correct permissions to generate security issues/advisories on your development platform (i.e., Admin on GitHub for Security Advisory). 101 | 102 | Create an email alias for these team members to privately collaborate on the issue. Ensure this is distinct from your report intake alias. 103 | Never make this team coordination alias "security@[yourdomain]," since that is a convention for intake. 104 | 105 | ### Set up report intake 106 | 107 | #### Location of information on how to report vulnerabilities 108 | 109 | You'll need an easy, obvious way that vulnerability reporters can contact your project (specifically: your project's VMT) to report security flaws that they have found in your code, and you need to _tell reporters what that is_. Typically, how to report a security vulnerability is described in a project's security policy or SECURITY.md file on GitHub, and/or on an easy-to-find page on the project's website. The goal here is: "make it obvious." 110 | 111 | In this section, we explain _where you should put the instructions_ for how vulnerability finders can contact your project to report security vulns. In the [next section](#intake-method), we explain _what mechanisms or communications methods you may wish to use to actually receive vulnerability reports_. 112 | 113 | ##### If you are using GitHub 114 | 115 | On GitHub, you can write a Security Policy that includes instructions for how you want researchers to report discovered security vulnerabilities to your project. [GitHub Security Advisory](https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/about-github-security-advisories) is the feature that displays the "Security Policy" and "Security Advisory" information in the top-level security tab on a GitHub repository. To populate the "Security Policy" field, you will want to create a [`SECURITY.md`](https://github.com/ossf/oss-vulnerability-guide/tree/main/templates/security_policies) file in your root, docs, or .github folder. ([GitHub documentation: Creating a Security Policy](https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository)) Whatever you decide, our recommendation is to also put a link to the `SECURITY.md` in your `README`. The Security tab isn't obvious to everyone; the `README` puts this information front and center. (Just putting disclosure information in the `README` will not populate the Security tab.) 116 | 117 | ##### If you are using another service 118 | 119 | On your project's website or similar, you can write a Security Policy that includes instructions for how you want researchers to report discovered security vulnerabilities to your project, or you can simply include clear and specific contact information to "report a security vulnerability". We recommend that you put your security policy in the same place where you document how to report issues, with a distinct callout for "Reporting a security issue." If this page is not a top-level page, we recommend also adding a link to this documentation on a landing page, a security features page, a contact page, or other prominent, heavily-trafficked page. If you have site search, "vulnerability," "report security," and "security issue" are common keywords that you'll want to incorporate. If you have a `README.md` or `SECURITY.md` page, put it there (and if you don't, consider adding them). 120 | 121 | #### Intake Method 122 | 123 | Your intake method for vulnerability reports will depend on how you plan to develop and test your patch privately. Whatever method you pick, clear documentation and consistency across the vulnerability management team (VMT) will help you stay organized and responsive. (E.g., if half your reports come in via email and half come in through Launchpad security issues, that is a recipe for miscommunication.) Inevitably you'll receive a report through the "wrong" method; just kindly help the report get into your standard workflow and keep going. 124 | 125 | The vulnerability reporter is doing you a favor; don't add more steps than absolutely necessary. In the spirit of this balance, **our recommendation is that using email for intake is okay**, and should at least be provided as an alternative. 126 | 127 | ##### If you are using GitHub 128 | 129 | If your project is on GitHub, we recommend [enabling privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability). This is an easy-to-use mechanism, and ease of use is key. 130 | 131 | We recommend that you also follow the directions for [another service](#if-you-are-using-another-service). In particular, include email address(es) people can use for reporting instead of the GitHub private reporting mechanism. 132 | 133 | You may choose to use GitHub Security Advisories for disclosure without enabling private reporting, but if you don't explicitly enable private reporting, users will be unable to report to you privately on GitHub. 134 | 135 | If you choose to use GitHub Security Advisory for private patch development, here's how we recommend supplementing it. 136 | Your Security Policy should instruct reporters to email the VMT with a vulnerability report ([see `SECURITY.md` templates](https://github.com/ossf/oss-vulnerability-guide/tree/main/templates/security_policies)). The VMT will then open a Security Advisory and add the reporter as a collaborator ([see GitHub documentation on GitHub Security Advisory](https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/about-github-security-advisories)). It is also appropriate to email that alias for questions about the vulnerability disclosure process. 137 | 138 | ##### If you are using another service 139 | 140 | If you are using an issue tracker to track security vulnerabilities (e.g., [Launchpad](https://launchpad.net/), Buganizer, or [Bugzilla](https://www.bugzilla.org/)), your Security Policy should instruct reporters to open a security issue in that tracker. It is also appropriate to email the VMT alias for questions about the vulnerability disclosure process or if there are problems opening a security issue. 141 | 142 | If you do not have an issue tracker with a security issue feature, you need an alternative method for intake. Your intake solution should restrict access to the content of the messages to verified identities (or at least verified email addresses), to counter being overwhelmed with spam. However, this solution also has to be accessible and have low friction. Typically this will be an email address. 143 | 144 | Even if you have an issue tracker, state an email address available as an alternative intake method so you [can help make sure issues get to you](https://googleprojectzero.blogspot.com/2018/08/adventures-in-vulnerability-reporting.html). 145 | 146 | ##### Accepting vulnerability reports via email with hop-to-hop encryption 147 | 148 | We recommend using an email service for accepting vulnerability reports (such as security@PROJECTNAME) that supports hop-to-hop encryption. In addition, encourage users to use email systems that support hop-to-hop encryption, and to use HTTPS if using a web-based email client. Widely-used email services already support hop-to-hop encryption, including Gmail, Outlook.com, Oath, and runbox.com. 149 | 150 | The preferred standard for hop-to-hop encryption is Mail Transfer Agent Strict Transport Security (MTA-STS). MTA-STS requires encryption. An alternative is STARTTLS. STARTTLS attempts to switch to encrypted communication, and thus counters passive monitoring, but because it is opportunistic it is weak against active attacks. Use at least one; don't allow vulnerability reports to go unencrypted across the Internet. 151 | 152 | Hop-to-hop encryption isn't as strong as end-to-end encryption, but many users find it too difficult today to use end-to-end encryption when using email. Organizations are welcome to also support end-to-end encryption with email (e.g., OpenPGP), and if they do support it, researchers are welcome to use them. We believe it's more important to _get_ the vulnerability report. 153 | 154 | ### Enable private patch development 155 | 156 | Later sections will cover how to determine if something is a security issue, a regular issue, and something that you will patch privately and then disclose. If it is a security issue and you will be issuing a patch, you will need a way to develop and test your work privately. If you test a particular patch in public, an observant attacker may see and exploit the vulnerability before you're able to issue a patch. 157 | 158 | #### If you are using GitHub 159 | 160 | You have a decision to make: Will you use the GitHub Security Advisory feature for private patch development? Based on the feature set of GitHub Security Advisory at the time of writing, **our recommendation is that you typically use the private development features to generate your patch there if you are a project using GitHub.** 161 | 162 | **Pros:** Keeps all development within one platform, easy to add external contributors (e.g., the reporter or other experts who can help with patching), when the vulnerability is disclosed, it is easy to flip the work from "private" to "public." 163 | 164 | **Cons:** One problem with private development is that you will not be able to get widespread feedback on your change; as a result, the fix may not truly fix the problem or have bad unintended consequences. In particular, it can be a challenge to share the proposed changes with many people without making them public using this approach. 165 | 166 | If the vulnerability is _already_ publicly known and widely exploited, there's no advantage to trying to keep things private. If the vulnerability is already widely known publicly, it is probably better to develop the fix in public as well (where you may get more people to help and more feedback). 167 | 168 | Also, at the time of writing, private forks created as part of GitHub Security Advisory do not have access to integration like CI systems ([see documentation](https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability#creating-a-temporary-private-fork)), so you will need to run tests locally. 169 | 170 | If you need to test against hardware or systems not already included in your testing suite but available somewhere else (for example, internally at your company), it may be faster to fork the project, develop, and test outside of GitHub's private branches. However, this does introduce the challenge of keeping your internal fork up with main while you develop a patch and restrictions on who can help. 171 | 172 | Running private mirrors can be done, but we do not recommend this as the default. If you run a private mirror for developing and testing security patches, you will want to have this set up and operational before you have a vulnerability report. 173 | 174 | #### If you are using another service 175 | 176 | Many issue trackers can separate security issues from regular issues. Whatever tracker you select, the following features are strongly recommended for your vulnerability reporting system: 177 | 178 | - A changelog is available for each ticket 179 | - Membership can be restricted, and member identity is compatible with multi-factor authentication 180 | - Private issues/tickets can be made public after disclosure 181 | - Issues and coordination communication are not ephemeral 182 | - The reporting process does not require the user to make an account with a service that is not already used in the corresponding project or is not a commonly used developer tool 183 | 184 | ### Establish a CNA contact 185 | 186 | CNAs ([CVE Numbering Authorities](https://cve.mitre.org/cve/request_id.html)) are organizations that can assign CVE numbers to new vulnerabilities. CNAs have various scopes and do not issue CVEs outside of their scopes. (e.g., While the (fictitious) SpeakerCompany uses open source software in their products, their scope could be restricted to vulnerabilities only found in SpeakerCompany software, and they would not handle a CVE request for an upstream issue.) There are many CNAs; the only "pre-work" for the VMT is to know of at least one CNA whose scope covers your project and who you will go to first for a CVE assignment. MITRE, the organization that manages CVE administration, is also a ["CNA of Last Resort" for open source projects](https://cveform.mitre.org/) and can be used if no better scope is available. 187 | 188 | ### Create an embargo list 189 | 190 | **TL;DR:** Embargoed notification requires careful administration and management, adds additional responsibility for the VMT, and adds time to the disclosure process. Unless your project has a significant vendor ecosystem, embargoed notification is probably not necessary. 191 | 192 | When companies offer your project as a managed service or your project is critical to their infrastructure, and their infrastructure has the potential to expose users, it is probably appropriate to have an "embargo list." An embargo list is a read-only announcement list whose membership is restricted to particular users. Depending on the nature of your project and the vulnerability, a user of a managed service might be dependent on their provider to take action to reduce that user's exposure. Before the public disclosure, a notification under embargo gives service providers time to prepare so they can patch quickly after the public disclosure and reduce the time their users are exposed. 193 | 194 | Embargoed notification is _not_ about avoiding PR issues or providing high-profile users with preferential treatment; it is about protecting users from damaging exploits by giving preparation time to the distributors and providers that control those users' systems. It can also allow distributors to test and qualify the patch across diverse environments and report problems that can be fixed before public release. This extra testing validation can be valuable for complex patches. Make sure someone on the VMT is monitoring for replies to the embargo announcement. 195 | 196 | Using an embargoed notification is not without risk. An embargoed notification expands the number of people with early awareness and adds extra time between when the vulnerability is discovered and when it's patched. As the [Project Zero team states](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html), _"We have observed several unintended outcomes from vulnerability sharing under embargo arrangements, such as the increased risk of leaks, slower patch release cycles, and inconsistent criteria for inclusion."_ When deciding to use an embargoed notification, consider the severity and exploitability of your vulnerability, the patching complexity (does the provider actually need the time to prepare, or this is an easily rolled out patch?), the resource cost in running and managing an embargoed notification cycle, and the breadth of your embargo list. For every vulnerability (irrespective of its severity), not all users are equally affected. For instance, if the vulnerability exploit is on network vector and some users have strong network security controls in place, they might not be affected by it. So the notifications can include some details on the code path that is being exploited and in which security settings it is affected. 197 | 198 | If an embargo list is relevant to your project, you will want to create a restricted, read-only announcement list that your VMT administers. The VMT is responsible for approving access requests and maintaining an accurate list (e.g., removing outdated members), but it is the provider's responsibility to request access to your list. List the requirements and directions for requesting access in your security documentation. 199 | 200 | ### Select communication templates 201 | 202 | The more you have pre-written, the less there is to do when you have an issue to respond to. [See the `Templates` directory](https://github.com/ossf/oss-vulnerability-guide/tree/main/templates) for security policy (`SECURITY.md`), embargoed notification, and public disclosure templates. 203 | 204 | ## Publish your vulnerability management process 205 | 206 | It can be beneficial to both reporters and users to publish what your project does when it receives a security issue and if you have a time-based disclosure deadline along with the usual time. This helps reporters follow the process along and helps users understand how an issue was handled when they see a disclosure. If you follow this process, just link to this document! Users and reporters may also want to know if a VMT is active; a regular status update can help with this. 207 | 208 | ## Apply the vulnerability response process 209 | 210 | ### Runbook 211 | 212 | See [`Runbook.md`](https://github.com/ossf/oss-vulnerability-guide/blob/main/runbook.md) for step-by-step directions on the vulnerability response and disclosure process 213 | 214 | ### Response process 215 | 216 | 1 **Immediately acknowledge receipt of the issue** 217 | 218 | Quickly acknowledge that you have received their issue. At this point, you likely haven't assessed the issue; you're just letting them know that you're on it. This should be done quickly, say within 1-2 days. 219 | 220 | 2 **Assess the issue** 221 | 222 | To assess if an issue is a vulnerability, you will need: 223 | 224 | - Documented steps the reporter took that created the behavior 225 | - Any relevant information about systems, versions, or packages involved 226 | 227 | Not everything reported as a vulnerability is a vulnerability. Generally, something is a vulnerability if it compromises data confidentiality, integrity, or availability. This may happen by enabling remote code execution, elevated permissions, or unintended access, but what separates a vulnerability from other unwanted behavior (a non-security bug) is a compromise in one or more of those areas. 228 | 229 | Intentional design decisions that do not have "optimized" security are typically not vulnerabilities. A suggestion for better security is not the same as a vulnerability. For example, it is good to harden software so that defects are less likely to lead to a vulnerability or reduce its impact. Still, suggestions on how to harden software are not themselves vulnerability reports. Vulnerabilities create a situation where something is not working as intended and creates unintended access or lack of service to data, systems, or resources. 230 | 231 | | Assessment | Response | 232 | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 233 | | 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. | 234 | | 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. | 235 | | 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. | 236 | | Vulnerability | Let the reporter know that you have confirmed this unwanted behavior creates a security issue. Proceed with the process. | 237 | 238 | 3 **Discuss embargo period with vulnerability reporter** 239 | 240 | Vulnerability reporters will typically state the embargo period they're willing to accept. The "embargo period" is when the vulnerability report is kept from the public, enabling the project to respond, fix, and publicly disclose the vulnerability themselves. This may or may not be the embargo period requested by the project. There are different recommendations and norms about embargo periods among different groups: 241 | 242 | - The [distros mailing list](https://oss-security.openwall.org/wiki/mailing-lists/distros) prefers less than 7 days, with an absolute maximum period of 14 days. 243 | - [CERT/CC discloses vulnerabilities to the public 45 days after the report](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy), even if no fix is available, with a few exceptions. 244 | - [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) (August 2017) says that "an acknowledgement timeframe of 24-48 hours is common for vendors and coordinators, while 45-90 days seems to be the normal range for disclosures these days." 245 | - [Google's application security policy uses a 90-day deadline](https://www.google.com/about/appsecurity/) 246 | 247 | Note that 90 days is the _longest_ embargo period entertained by various groups as a default; many default embargo periods are shorter. More or less time may be appropriate depending on the issue's complexity, whether or not the issue is being actively exploited, or problems in patch rollout. If you believe the vulnerability reporter has not given your project enough time, now is the time to make the case to the vulnerability reporter about _why_ a longer embargo time is needed. [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) recommends that both suppliers and reporters "treat policy-declared disclosure timeframes as the starting point of a negotiation process rather than a hard deadline." 248 | 249 | What's critical is that the embargo time is agreed on by all parties (if possible). It's also essential that there be ongoing communication with the vulnerability reporters. Most vulnerability reporters are happy to provide some extra time if there is clear ongoing evidence of effort, continuous communication, and a good rationale for that extra time. 250 | 251 | Embargo periods (aka "days of risk") represent a trade-off. Every day in embargo is another day where attackers may discover the vulnerability and exploit users of the software. In contrast, the users and public remain unaware of the dangers of the vulnerability. However, once the embargo ends, attackers who might not have learned of the vulnerability can now quickly learn of the vulnerability and exploit it. The shorter the time between the vulnerability discovery and a proper fix, the better. Past bitter experience has shown that many suppliers simply leave their users exposed to dangerous vulnerabilities without a deadline, so having no deadline suggests to many vulnerability reporters that the project is actively opposed to securing the software they supply. 252 | 253 | 4 **Create a patch for the issue** 254 | 255 | Let the reporter know you have confirmed the issue, begin developing a patch, and request a [CVE entry](https://cve.mitre.org/about/index.html) if they have not. **Ask the reporter if they would like to be involved in the patch development process.** Using your private development and testing tooling, develop a patch and prepare (but do not cut) a release. 256 | 257 | In your assessment process, you should have identified what versions are affected. As you prepare your patch, note backward compatibility and upgrade requirements (for example, v1.0.0 is affected, but the patch is not compatible, and users will need to upgrade to v1.7.0 or above to apply the patch). You will need to communicate these details in your disclosure announcements. 258 | 259 | When creating a patch, it is _vital_ that it be _easy_ to users to update (at least for the users who are using the most recent release of the software). Your change should not require the users to use a different API, or eliminate user functionality unless that is _absolutely_ necessary. Where practical, the change should involve a simple update. If such changes are _absolutely_ necessary to fix the vulnerability fully, minimize the user impact, and look for ways to mitigate the vulnerability without applying the change (since many users will be unable to install such changes in a timely way). 260 | 261 | For issues in patching, see the [Troubleshooting](#troubleshooting-the-process) section of the guide. 262 | 263 | 5 **Get a CVE for the issue** 264 | 265 | **Ask the reporter if they would like to be involved in writing the CVE entry and if they would like to be credited in the entry.** Recognition is one of the many ways we thank reporters! It is _inappropriate_ to omit credit to vulnerability reporters unless the reporter does not want the credit. 266 | 267 | Go through your [identified CNA](#establish-a-cna-contact) to have a CVE number reserved and submit a description. Let your CNA know you are working on a patch and, if applicable, will be doing embargoed notifications before public disclosure. Keep your CNA up to date on your public disclosure date so they can coordinate listing your CVE entry. 268 | 269 | 6 **Decide the date of public release** 270 | 271 | The advantage of getting a CVE for a vulnerability is that it provides a path to notify users of the vulnerability and verify that it is fixed. Many organizations specifically track CVEs, so that even if they don't see your vulnerability announcement, they'll see the CVE report. 272 | 273 | We also recommend creating a JSON entry using the [OSV schema](https://ossf.github.io/osv-schema/) and publishing this somewhere accessible over HTTP. This schema enables encoding machine readable version information that makes it easier for users to match the vulnerability to their versions of your project. 274 | 275 | 7 # **(If applicable) Notify providers under embargo** 276 | 277 | In many countries people often have days off on Fridays, Saturdays, and/or Sundays. So if the vulnerability is not publicly known (e.g., it's not being exploited), it's often better to make the public release on Monday, Tuesday, or Wednesday. In addition, try to avoid releasing a vulnerability fix on a widely-observed holiday. This gives people some time to do the update during their workday. 278 | 279 | 8 **(If applicable) Notify providers under embargo** 280 | 281 | Embargo notifications are sent anywhere from 1-30 workdays before the intended date of public disclosure. This timeframe depends on the severity and exploitability of the issue, the complexity of the patch, and the type of providers your project is used by (can the providers feasibly qualify and patch in 5 days? 10 days?). Also consider holidays and significant events that could impact the provider's ability to prepare and adjust your dates accordingly (e.g., if retailers heavily use your project, don't expect them to be able to prepare over the [US Black Friday shopping days]()). 282 | 283 | Your notification should include the CVE id, issue description, reporter credit (if applicable), affected versions, how the patch will be made available, and the public disclosure date. See corresponding [template](#communication-templates) examples in the guide. 284 | 285 | 9 **Cut a release and publicly disclose the issue** 286 | 287 | On the day of public disclosure, publish your disclosure announcement ([see templates](#communication-templates)). If using GitHub Security Advisories, "publishing" your private Security Advisory will add it to the "Security" tab. If you are not using GitHub Security Advisories, publish the announcement to your release notes or security bulletins. If you have CVE ids for the vulnerabilities fixed, include the CVE id(s) of the vulnerabilities that were fixed in this release. 288 | 289 | It's also recommended to send the announcement to appropriate mailing lists for your community (i.e., a security-announce@ list and even a general mailing list for high-impact vulnerabilities). 290 | 291 | 10 **Disclose quickly** 292 | 293 | You might choose to briefly withhold details about how the vulnerability can be exploited, hoping that this will give users a little more time to update before attackers begin exploiting the vulnerability. This only makes sense if it's not obvious to attackers how the vulnerability can be exploited, and in most cases, attackers will find it obvious. In addition, attackers can usually review changes made to software (in source or executable form) and easily determine an attack. Thus, withholding detailed information can only be helpful for a few days at most, even in the few cases where it helps at all. 294 | 295 | ## Troubleshooting common challenges to Coordinated Vulnerability Disclosure 296 | 297 | Sometimes, the coordinated vulnerability disclosure process does not go smoothly. In this section, we offer advice for a few potential challenges you may encounter. 298 | 299 | **_We're not sure if this is actually a security issue_** 300 | 301 | If you receive a vulnerability report but do not understand whether it is a security issue, you should ask domain experts in your VMT, or you can try to ask additional questions of the person who reported the vulnerability. If their report is too brief or unclear, you may wish to ask things like: 302 | 303 | - In which lines of code is the vulnerability located? 304 | - How specifically does this vulnerability create a security risk? 305 | - If we leave the code as it is, what could an attacker ultimately do? 306 | - How can we replicate the issue? / Do you have a working proof-of-concept that you would be willing to show us? 307 | - What would we have to do to fix the issue? (_Note: You should still do your best to validate the security of every contributed patch - regardless of its' source - to seek to prevent both accidentially insecure or intentionally malicious commits_). 308 | 309 | Sometimes, vulnerability researchers will be willing to invest additional time to help you better understand the issue so that you can fix it. If they do this, be respectful of their time and collaborative and straightforward in your approach so that you can work together to get the vulnerability remediated. 310 | 311 | **_Our reporter isn't very responsive_** 312 | 313 | After the initial report, your reporter will choose how responsive to be (that's the "coordination" part of Coordinated Vulnerability Disclosure). If you receive a report that you cannot reproduce and have tried multiple times to reach the reporter, send them a polite, final note that you were not able to reproduce the issue and will not be issuing a security advisory. Encourage them to reopen the issue if they can reproduce it in the future. 314 | 315 | **_Patch development isn't going well_** 316 | 317 | If you're struggling to develop a patch that fully resolves the issue, you have a couple of options: 318 | 319 | - **Get more help.** 320 | It is okay to expand the people working on an issue beyond the VMT when you struggle to create a fix. Is there a project contributor who has particular knowledge of the affected area? Do you know someone who specializes in this security area? (e.g., networking security, container security, etc.) Do VMT members have resources at their company (e.g., vuln response teams) who can help? 321 | 322 | - **Patch partially (break the exploitation chain).** 323 | If you've gotten more help, the embargo period is about to end, and you don't have a complete fix yet, a patch that breaks the exploitation chain before the public disclosure time is preferable to no patch. This does not mean you stop working on a complete fix after disclosure, but that you release the solution you do have. 324 | In this context, "break the exploitation chain" means creating a partial fix that makes the exploit much more difficult. 325 | In this option, you must communicate and document that this patch does not resolve the issue entirely. Users must understand their exposure level even after patching. When you have a comprehensive fix, remember to add updates to past announcements to point users to the latest information. (For example, your release notes for the comprehensive fix could say, "Further security improvements addressing $CVEID.") 326 | 327 | - **Disclose without a patch and document it well.** 328 | If an issue is unresolvable, it is better that users know than not know. "Security through obscurity" is a weak defense in vulnerability management. Any existing vulnerability can be found and exploited by bad actors. Document the issue well, including any related workarounds for common environments, and continue to work on it in public. 329 | 330 | **_Someone publicly disclosed a vulnerability without working with us_** 331 | 332 | Whether it is found in a research paper, a media article, a security conference preesentation, or on social media, if someone publicly discloses a vulnerability in your project that you had no prior awareness of, the best thing to do is treat it as a regular project issue (it is, after all, already public) but assign it high priority and communicate with your users, particularly if it's a publicized or critical issue. Let them know you're aware of the issue, how it's being handled, and where they should watch for updates. Addressing an issue of this type publicly removes a significant part of the communication burden, as it allows others to find this information and not have to contact the VMT. 333 | 334 | **_We believe the vulnerability is being actively exploited in the wild_** 335 | 336 | Open source software is powerful, and unmitigated security flaws in OSS projects can have real-world impact on people and organizations around the world. The exploitation of security vulnerabilities in open source (and closed source!) projects can lead to the compromise of downstream dependents and both direct and indirect users of your software. Examples of these so-called "supply chain" attacks have been well-documented in recent years in mainstream media. 337 | 338 | If you have reason to believe that a vulnerability in your code is being actively exploited by threat actors, it is important to quickly notify users and issue patches that remediate the security risks. We aim to update a future version of this guide with additional resources for OSS project maintainers facing this challenge. 339 | 340 | ## Acknowledgements 341 | 342 | Thank you to the wider security and open source communities whose work informed this guide, including the [Google Open Source Programs Office and Google security teams](https://github.com/google/oss-vulnerability-guide), the [OpenStack Vulnerability Management Process](https://security.openstack.org/vmt-process.html), [Project Zero's disclosure process](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html), and the [Kubernetes security and disclosure process](https://kubernetes.io/docs/reference/issues-security/security/). 343 | -------------------------------------------------------------------------------- /package-lock.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "wg-vulnerability-disclosures", 3 | "version": "1.0.0", 4 | "lockfileVersion": 2, 5 | "requires": true, 6 | "packages": { 7 | "": { 8 | "name": "wg-vulnerability-disclosures", 9 | "version": "1.0.0", 10 | "license": "Apache-2.0", 11 | "devDependencies": { 12 | "markdownlint-cli": "^0.32.2", 13 | "prettier": "^2.7.1" 14 | } 15 | }, 16 | "node_modules/argparse": { 17 | "version": "2.0.1", 18 | "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", 19 | "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==", 20 | "dev": true 21 | }, 22 | "node_modules/balanced-match": { 23 | "version": "1.0.2", 24 | "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", 25 | "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", 26 | "dev": true 27 | }, 28 | "node_modules/brace-expansion": { 29 | "version": "2.0.1", 30 | "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", 31 | "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", 32 | "dev": true, 33 | "dependencies": { 34 | "balanced-match": "^1.0.0" 35 | } 36 | }, 37 | "node_modules/commander": { 38 | "version": "9.4.1", 39 | "resolved": "https://registry.npmjs.org/commander/-/commander-9.4.1.tgz", 40 | "integrity": "sha512-5EEkTNyHNGFPD2H+c/dXXfQZYa/scCKasxWcXJaWnNJ99pnQN9Vnmqow+p+PlFPE63Q6mThaZws1T+HxfpgtPw==", 41 | "dev": true, 42 | "engines": { 43 | "node": "^12.20.0 || >=14" 44 | } 45 | }, 46 | "node_modules/deep-extend": { 47 | "version": "0.6.0", 48 | "resolved": "https://registry.npmjs.org/deep-extend/-/deep-extend-0.6.0.tgz", 49 | "integrity": "sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==", 50 | "dev": true, 51 | "engines": { 52 | "node": ">=4.0.0" 53 | } 54 | }, 55 | "node_modules/entities": { 56 | "version": "3.0.1", 57 | "resolved": "https://registry.npmjs.org/entities/-/entities-3.0.1.tgz", 58 | "integrity": "sha512-WiyBqoomrwMdFG1e0kqvASYfnlb0lp8M5o5Fw2OFq1hNZxxcNk8Ik0Xm7LxzBhuidnZB/UtBqVCgUz3kBOP51Q==", 59 | "dev": true, 60 | "engines": { 61 | "node": ">=0.12" 62 | }, 63 | "funding": { 64 | "url": "https://github.com/fb55/entities?sponsor=1" 65 | } 66 | }, 67 | "node_modules/fs.realpath": { 68 | "version": "1.0.0", 69 | "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz", 70 | "integrity": "sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==", 71 | "dev": true 72 | }, 73 | "node_modules/get-stdin": { 74 | "version": "9.0.0", 75 | "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-9.0.0.tgz", 76 | "integrity": "sha512-dVKBjfWisLAicarI2Sf+JuBE/DghV4UzNAVe9yhEJuzeREd3JhOTE9cUaJTeSa77fsbQUK3pcOpJfM59+VKZaA==", 77 | "dev": true, 78 | "engines": { 79 | "node": ">=12" 80 | }, 81 | "funding": { 82 | "url": "https://github.com/sponsors/sindresorhus" 83 | } 84 | }, 85 | "node_modules/glob": { 86 | "version": "8.0.3", 87 | "resolved": "https://registry.npmjs.org/glob/-/glob-8.0.3.tgz", 88 | "integrity": "sha512-ull455NHSHI/Y1FqGaaYFaLGkNMMJbavMrEGFXG/PGrg6y7sutWHUHrz6gy6WEBH6akM1M414dWKCNs+IhKdiQ==", 89 | "dev": true, 90 | "dependencies": { 91 | "fs.realpath": "^1.0.0", 92 | "inflight": "^1.0.4", 93 | "inherits": "2", 94 | "minimatch": "^5.0.1", 95 | "once": "^1.3.0" 96 | }, 97 | "engines": { 98 | "node": ">=12" 99 | }, 100 | "funding": { 101 | "url": "https://github.com/sponsors/isaacs" 102 | } 103 | }, 104 | "node_modules/ignore": { 105 | "version": "5.2.0", 106 | "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.2.0.tgz", 107 | "integrity": "sha512-CmxgYGiEPCLhfLnpPp1MoRmifwEIOgjcHXxOBjv7mY96c+eWScsOP9c112ZyLdWHi0FxHjI+4uVhKYp/gcdRmQ==", 108 | "dev": true, 109 | "engines": { 110 | "node": ">= 4" 111 | } 112 | }, 113 | "node_modules/inflight": { 114 | "version": "1.0.6", 115 | "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz", 116 | "integrity": "sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==", 117 | "dev": true, 118 | "dependencies": { 119 | "once": "^1.3.0", 120 | "wrappy": "1" 121 | } 122 | }, 123 | "node_modules/inherits": { 124 | "version": "2.0.4", 125 | "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", 126 | "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==", 127 | "dev": true 128 | }, 129 | "node_modules/ini": { 130 | "version": "3.0.1", 131 | "resolved": "https://registry.npmjs.org/ini/-/ini-3.0.1.tgz", 132 | "integrity": "sha512-it4HyVAUTKBc6m8e1iXWvXSTdndF7HbdN713+kvLrymxTaU4AUBWrJ4vEooP+V7fexnVD3LKcBshjGGPefSMUQ==", 133 | "dev": true, 134 | "engines": { 135 | "node": "^12.13.0 || ^14.15.0 || >=16.0.0" 136 | } 137 | }, 138 | "node_modules/js-yaml": { 139 | "version": "4.1.0", 140 | "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz", 141 | "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==", 142 | "dev": true, 143 | "dependencies": { 144 | "argparse": "^2.0.1" 145 | }, 146 | "bin": { 147 | "js-yaml": "bin/js-yaml.js" 148 | } 149 | }, 150 | "node_modules/jsonc-parser": { 151 | "version": "3.1.0", 152 | "resolved": "https://registry.npmjs.org/jsonc-parser/-/jsonc-parser-3.1.0.tgz", 153 | "integrity": "sha512-DRf0QjnNeCUds3xTjKlQQ3DpJD51GvDjJfnxUVWg6PZTo2otSm+slzNAxU/35hF8/oJIKoG9slq30JYOsF2azg==", 154 | "dev": true 155 | }, 156 | "node_modules/linkify-it": { 157 | "version": "4.0.1", 158 | "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz", 159 | "integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==", 160 | "dev": true, 161 | "dependencies": { 162 | "uc.micro": "^1.0.1" 163 | } 164 | }, 165 | "node_modules/markdown-it": { 166 | "version": "13.0.1", 167 | "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz", 168 | "integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==", 169 | "dev": true, 170 | "dependencies": { 171 | "argparse": "^2.0.1", 172 | "entities": "~3.0.1", 173 | "linkify-it": "^4.0.1", 174 | "mdurl": "^1.0.1", 175 | "uc.micro": "^1.0.5" 176 | }, 177 | "bin": { 178 | "markdown-it": "bin/markdown-it.js" 179 | } 180 | }, 181 | "node_modules/markdownlint": { 182 | "version": "0.26.2", 183 | "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz", 184 | "integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==", 185 | "dev": true, 186 | "dependencies": { 187 | "markdown-it": "13.0.1" 188 | }, 189 | "engines": { 190 | "node": ">=14" 191 | } 192 | }, 193 | "node_modules/markdownlint-cli": { 194 | "version": "0.32.2", 195 | "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.32.2.tgz", 196 | "integrity": "sha512-xmJT1rGueUgT4yGNwk6D0oqQr90UJ7nMyakXtqjgswAkEhYYqjHew9RY8wDbOmh2R270IWjuKSeZzHDEGPAUkQ==", 197 | "dev": true, 198 | "dependencies": { 199 | "commander": "~9.4.0", 200 | "get-stdin": "~9.0.0", 201 | "glob": "~8.0.3", 202 | "ignore": "~5.2.0", 203 | "js-yaml": "^4.1.0", 204 | "jsonc-parser": "~3.1.0", 205 | "markdownlint": "~0.26.2", 206 | "markdownlint-rule-helpers": "~0.17.2", 207 | "minimatch": "~5.1.0", 208 | "run-con": "~1.2.11" 209 | }, 210 | "bin": { 211 | "markdownlint": "markdownlint.js" 212 | }, 213 | "engines": { 214 | "node": ">=14" 215 | } 216 | }, 217 | "node_modules/markdownlint-rule-helpers": { 218 | "version": "0.17.2", 219 | "resolved": "https://registry.npmjs.org/markdownlint-rule-helpers/-/markdownlint-rule-helpers-0.17.2.tgz", 220 | "integrity": "sha512-XaeoW2NYSlWxMCZM2B3H7YTG6nlaLfkEZWMBhr4hSPlq9MuY2sy83+Xr89jXOqZMZYjvi5nBCGoFh7hHoPKZmA==", 221 | "dev": true, 222 | "engines": { 223 | "node": ">=12" 224 | } 225 | }, 226 | "node_modules/mdurl": { 227 | "version": "1.0.1", 228 | "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz", 229 | "integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==", 230 | "dev": true 231 | }, 232 | "node_modules/minimatch": { 233 | "version": "5.1.0", 234 | "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.0.tgz", 235 | "integrity": "sha512-9TPBGGak4nHfGZsPBohm9AWg6NoT7QTCehS3BIJABslyZbzxfV78QM2Y6+i741OPZIafFAaiiEMh5OyIrJPgtg==", 236 | "dev": true, 237 | "dependencies": { 238 | "brace-expansion": "^2.0.1" 239 | }, 240 | "engines": { 241 | "node": ">=10" 242 | } 243 | }, 244 | "node_modules/minimist": { 245 | "version": "1.2.7", 246 | "resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.7.tgz", 247 | "integrity": "sha512-bzfL1YUZsP41gmu/qjrEk0Q6i2ix/cVeAhbCbqH9u3zYutS1cLg00qhrD0M2MVdCcx4Sc0UpP2eBWo9rotpq6g==", 248 | "dev": true, 249 | "funding": { 250 | "url": "https://github.com/sponsors/ljharb" 251 | } 252 | }, 253 | "node_modules/once": { 254 | "version": "1.4.0", 255 | "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz", 256 | "integrity": "sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==", 257 | "dev": true, 258 | "dependencies": { 259 | "wrappy": "1" 260 | } 261 | }, 262 | "node_modules/prettier": { 263 | "version": "2.7.1", 264 | "resolved": "https://registry.npmjs.org/prettier/-/prettier-2.7.1.tgz", 265 | "integrity": "sha512-ujppO+MkdPqoVINuDFDRLClm7D78qbDt0/NR+wp5FqEZOoTNAjPHWj17QRhu7geIHJfcNhRk1XVQmF8Bp3ye+g==", 266 | "dev": true, 267 | "bin": { 268 | "prettier": "bin-prettier.js" 269 | }, 270 | "engines": { 271 | "node": ">=10.13.0" 272 | }, 273 | "funding": { 274 | "url": "https://github.com/prettier/prettier?sponsor=1" 275 | } 276 | }, 277 | "node_modules/run-con": { 278 | "version": "1.2.11", 279 | "resolved": "https://registry.npmjs.org/run-con/-/run-con-1.2.11.tgz", 280 | "integrity": "sha512-NEMGsUT+cglWkzEr4IFK21P4Jca45HqiAbIIZIBdX5+UZTB24Mb/21iNGgz9xZa8tL6vbW7CXmq7MFN42+VjNQ==", 281 | "dev": true, 282 | "dependencies": { 283 | "deep-extend": "^0.6.0", 284 | "ini": "~3.0.0", 285 | "minimist": "^1.2.6", 286 | "strip-json-comments": "~3.1.1" 287 | }, 288 | "bin": { 289 | "run-con": "cli.js" 290 | } 291 | }, 292 | "node_modules/strip-json-comments": { 293 | "version": "3.1.1", 294 | "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz", 295 | "integrity": "sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==", 296 | "dev": true, 297 | "engines": { 298 | "node": ">=8" 299 | }, 300 | "funding": { 301 | "url": "https://github.com/sponsors/sindresorhus" 302 | } 303 | }, 304 | "node_modules/uc.micro": { 305 | "version": "1.0.6", 306 | "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz", 307 | "integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==", 308 | "dev": true 309 | }, 310 | "node_modules/wrappy": { 311 | "version": "1.0.2", 312 | "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz", 313 | "integrity": "sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==", 314 | "dev": true 315 | } 316 | }, 317 | "dependencies": { 318 | "argparse": { 319 | "version": "2.0.1", 320 | "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", 321 | "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==", 322 | "dev": true 323 | }, 324 | "balanced-match": { 325 | "version": "1.0.2", 326 | "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", 327 | "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", 328 | "dev": true 329 | }, 330 | "brace-expansion": { 331 | "version": "2.0.1", 332 | "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", 333 | "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", 334 | "dev": true, 335 | "requires": { 336 | "balanced-match": "^1.0.0" 337 | } 338 | }, 339 | "commander": { 340 | "version": "9.4.1", 341 | "resolved": "https://registry.npmjs.org/commander/-/commander-9.4.1.tgz", 342 | "integrity": "sha512-5EEkTNyHNGFPD2H+c/dXXfQZYa/scCKasxWcXJaWnNJ99pnQN9Vnmqow+p+PlFPE63Q6mThaZws1T+HxfpgtPw==", 343 | "dev": true 344 | }, 345 | "deep-extend": { 346 | "version": "0.6.0", 347 | "resolved": "https://registry.npmjs.org/deep-extend/-/deep-extend-0.6.0.tgz", 348 | "integrity": "sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==", 349 | "dev": true 350 | }, 351 | "entities": { 352 | "version": "3.0.1", 353 | "resolved": "https://registry.npmjs.org/entities/-/entities-3.0.1.tgz", 354 | "integrity": "sha512-WiyBqoomrwMdFG1e0kqvASYfnlb0lp8M5o5Fw2OFq1hNZxxcNk8Ik0Xm7LxzBhuidnZB/UtBqVCgUz3kBOP51Q==", 355 | "dev": true 356 | }, 357 | "fs.realpath": { 358 | "version": "1.0.0", 359 | "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz", 360 | "integrity": "sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==", 361 | "dev": true 362 | }, 363 | "get-stdin": { 364 | "version": "9.0.0", 365 | "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-9.0.0.tgz", 366 | "integrity": "sha512-dVKBjfWisLAicarI2Sf+JuBE/DghV4UzNAVe9yhEJuzeREd3JhOTE9cUaJTeSa77fsbQUK3pcOpJfM59+VKZaA==", 367 | "dev": true 368 | }, 369 | "glob": { 370 | "version": "8.0.3", 371 | "resolved": "https://registry.npmjs.org/glob/-/glob-8.0.3.tgz", 372 | "integrity": "sha512-ull455NHSHI/Y1FqGaaYFaLGkNMMJbavMrEGFXG/PGrg6y7sutWHUHrz6gy6WEBH6akM1M414dWKCNs+IhKdiQ==", 373 | "dev": true, 374 | "requires": { 375 | "fs.realpath": "^1.0.0", 376 | "inflight": "^1.0.4", 377 | "inherits": "2", 378 | "minimatch": "^5.0.1", 379 | "once": "^1.3.0" 380 | } 381 | }, 382 | "ignore": { 383 | "version": "5.2.0", 384 | "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.2.0.tgz", 385 | "integrity": "sha512-CmxgYGiEPCLhfLnpPp1MoRmifwEIOgjcHXxOBjv7mY96c+eWScsOP9c112ZyLdWHi0FxHjI+4uVhKYp/gcdRmQ==", 386 | "dev": true 387 | }, 388 | "inflight": { 389 | "version": "1.0.6", 390 | "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz", 391 | "integrity": "sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==", 392 | "dev": true, 393 | "requires": { 394 | "once": "^1.3.0", 395 | "wrappy": "1" 396 | } 397 | }, 398 | "inherits": { 399 | "version": "2.0.4", 400 | "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", 401 | "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==", 402 | "dev": true 403 | }, 404 | "ini": { 405 | "version": "3.0.1", 406 | "resolved": "https://registry.npmjs.org/ini/-/ini-3.0.1.tgz", 407 | "integrity": "sha512-it4HyVAUTKBc6m8e1iXWvXSTdndF7HbdN713+kvLrymxTaU4AUBWrJ4vEooP+V7fexnVD3LKcBshjGGPefSMUQ==", 408 | "dev": true 409 | }, 410 | "js-yaml": { 411 | "version": "4.1.0", 412 | "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz", 413 | "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==", 414 | "dev": true, 415 | "requires": { 416 | "argparse": "^2.0.1" 417 | } 418 | }, 419 | "jsonc-parser": { 420 | "version": "3.1.0", 421 | "resolved": "https://registry.npmjs.org/jsonc-parser/-/jsonc-parser-3.1.0.tgz", 422 | "integrity": "sha512-DRf0QjnNeCUds3xTjKlQQ3DpJD51GvDjJfnxUVWg6PZTo2otSm+slzNAxU/35hF8/oJIKoG9slq30JYOsF2azg==", 423 | "dev": true 424 | }, 425 | "linkify-it": { 426 | "version": "4.0.1", 427 | "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz", 428 | "integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==", 429 | "dev": true, 430 | "requires": { 431 | "uc.micro": "^1.0.1" 432 | } 433 | }, 434 | "markdown-it": { 435 | "version": "13.0.1", 436 | "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz", 437 | "integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==", 438 | "dev": true, 439 | "requires": { 440 | "argparse": "^2.0.1", 441 | "entities": "~3.0.1", 442 | "linkify-it": "^4.0.1", 443 | "mdurl": "^1.0.1", 444 | "uc.micro": "^1.0.5" 445 | } 446 | }, 447 | "markdownlint": { 448 | "version": "0.26.2", 449 | "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz", 450 | "integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==", 451 | "dev": true, 452 | "requires": { 453 | "markdown-it": "13.0.1" 454 | } 455 | }, 456 | "markdownlint-cli": { 457 | "version": "0.32.2", 458 | "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.32.2.tgz", 459 | "integrity": "sha512-xmJT1rGueUgT4yGNwk6D0oqQr90UJ7nMyakXtqjgswAkEhYYqjHew9RY8wDbOmh2R270IWjuKSeZzHDEGPAUkQ==", 460 | "dev": true, 461 | "requires": { 462 | "commander": "~9.4.0", 463 | "get-stdin": "~9.0.0", 464 | "glob": "~8.0.3", 465 | "ignore": "~5.2.0", 466 | "js-yaml": "^4.1.0", 467 | "jsonc-parser": "~3.1.0", 468 | "markdownlint": "~0.26.2", 469 | "markdownlint-rule-helpers": "~0.17.2", 470 | "minimatch": "~5.1.0", 471 | "run-con": "~1.2.11" 472 | } 473 | }, 474 | "markdownlint-rule-helpers": { 475 | "version": "0.17.2", 476 | "resolved": "https://registry.npmjs.org/markdownlint-rule-helpers/-/markdownlint-rule-helpers-0.17.2.tgz", 477 | "integrity": "sha512-XaeoW2NYSlWxMCZM2B3H7YTG6nlaLfkEZWMBhr4hSPlq9MuY2sy83+Xr89jXOqZMZYjvi5nBCGoFh7hHoPKZmA==", 478 | "dev": true 479 | }, 480 | "mdurl": { 481 | "version": "1.0.1", 482 | "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz", 483 | "integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==", 484 | "dev": true 485 | }, 486 | "minimatch": { 487 | "version": "5.1.0", 488 | "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.0.tgz", 489 | "integrity": "sha512-9TPBGGak4nHfGZsPBohm9AWg6NoT7QTCehS3BIJABslyZbzxfV78QM2Y6+i741OPZIafFAaiiEMh5OyIrJPgtg==", 490 | "dev": true, 491 | "requires": { 492 | "brace-expansion": "^2.0.1" 493 | } 494 | }, 495 | "minimist": { 496 | "version": "1.2.7", 497 | "resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.7.tgz", 498 | "integrity": "sha512-bzfL1YUZsP41gmu/qjrEk0Q6i2ix/cVeAhbCbqH9u3zYutS1cLg00qhrD0M2MVdCcx4Sc0UpP2eBWo9rotpq6g==", 499 | "dev": true 500 | }, 501 | "once": { 502 | "version": "1.4.0", 503 | "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz", 504 | "integrity": "sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==", 505 | "dev": true, 506 | "requires": { 507 | "wrappy": "1" 508 | } 509 | }, 510 | "prettier": { 511 | "version": "2.7.1", 512 | "resolved": "https://registry.npmjs.org/prettier/-/prettier-2.7.1.tgz", 513 | "integrity": "sha512-ujppO+MkdPqoVINuDFDRLClm7D78qbDt0/NR+wp5FqEZOoTNAjPHWj17QRhu7geIHJfcNhRk1XVQmF8Bp3ye+g==", 514 | "dev": true 515 | }, 516 | "run-con": { 517 | "version": "1.2.11", 518 | "resolved": "https://registry.npmjs.org/run-con/-/run-con-1.2.11.tgz", 519 | "integrity": "sha512-NEMGsUT+cglWkzEr4IFK21P4Jca45HqiAbIIZIBdX5+UZTB24Mb/21iNGgz9xZa8tL6vbW7CXmq7MFN42+VjNQ==", 520 | "dev": true, 521 | "requires": { 522 | "deep-extend": "^0.6.0", 523 | "ini": "~3.0.0", 524 | "minimist": "^1.2.6", 525 | "strip-json-comments": "~3.1.1" 526 | } 527 | }, 528 | "strip-json-comments": { 529 | "version": "3.1.1", 530 | "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz", 531 | "integrity": "sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==", 532 | "dev": true 533 | }, 534 | "uc.micro": { 535 | "version": "1.0.6", 536 | "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz", 537 | "integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==", 538 | "dev": true 539 | }, 540 | "wrappy": { 541 | "version": "1.0.2", 542 | "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz", 543 | "integrity": "sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==", 544 | "dev": true 545 | } 546 | } 547 | } 548 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "oss-vulnerability-guide", 3 | "version": "1.0.0", 4 | "description": "A guide on coordinated vulnerability disclosure for open source projects. Includes templates for security policies (security.md) and disclosure notifications.", 5 | "scripts": { 6 | "format": "npx prettier --write . && npx markdownlint --fix '**/*.md' --ignore node_modules --config .github/linters/.markdown-lint.yml" 7 | }, 8 | "repository": { 9 | "type": "git", 10 | "url": "git+https://github.com/ossf/oss-vulnerability-guide.git" 11 | }, 12 | "author": "", 13 | "license": "CC-BY-4.0", 14 | "bugs": { 15 | "url": "https://github.com/ossf/oss-vulnerability-guide/issues" 16 | }, 17 | "homepage": "https://github.com/ossf/oss-vulnerability-guide#readme", 18 | "devDependencies": { 19 | "markdownlint-cli": "^0.32.2", 20 | "prettier": "^2.7.1" 21 | } 22 | } 23 | -------------------------------------------------------------------------------- /runbook.md: -------------------------------------------------------------------------------- 1 | # Runbook 2 | 3 | Read more details about each step in the [Response process](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#apply-the-vulnerability-response-process) section of the [full maintainer guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md). 4 | 5 | 1. **Intake** 6 | 7 | - The VMT receives an email or security issue detailing the issue, steps taken to create it, versions, and known mitigations. 8 | - The VMT replies acknowledging issue receipt. 9 | 10 | 2. **Assessment** 11 | 12 | - The VMT decides if the issue is working-as-intended, a bug, a feature request, or a security issue. 13 | - The VMT responds to the reporter with their assessment. 14 | - If it is a vulnerability and the project is using GitHub for coordination, the VMT opens a Security Advisory and adds the reporter as a collaborator. 15 | 16 | 3. **Patching** 17 | 18 | - The VMT (and if applicable the reporter and other necessary project maintainers) develop and test a patch on a private branch. The patch is prepared for release. 19 | 20 | 4. **CVE assignment** 21 | 22 | - The VMT uses a CNA to request a CVE entry and credits the reporter according to the reporter’s preference. 23 | 24 | 5. **(If applicable) Embargoed notification** 25 | 26 | - Embargoed notification with CVE number, issue description, reporter credit, affected versions, mitigation, and timeline for public disclosure. 27 | 28 | 6. **Public disclosure** 29 | - Vulnerability publicly disclosed. Lists CVE number, issue description, reporter credit, affected versions, and mitigation. 30 | - Private branches for patch development are made public. 31 | -------------------------------------------------------------------------------- /templates/notifications/disclosure.md: -------------------------------------------------------------------------------- 1 | # Security advisory for $CVEID 2 | 3 | _Note: If you are using GitHub Security Advisories, the CVE ID and date will be included in the header. For channels other than GitHub Security Advisories, including mailing list announcements, begin your public disclosure notice with the following: Security advisory for $CVEID_ 4 | 5 | ## Summary 6 | 7 | _A brief (as short as possible, about a paragraph) summary of the vulnerability using technical details. The goal of this is to allow the vendor to do a quick assessment of what the bug is about._ 8 | 9 | ### CVE: $CVE-NUMBER 10 | 11 | ### Affected versions: $VERSION 12 | 13 | ### Reporter: $NAME $AFFILIATION 14 | 15 | ## Severity 16 | 17 | _[Low, Medium, HIGH, **CRITICAL**] - Accompany your assessment with a motivation, and even a good attack scenario to explain the risk associated with the vulnerability. Including CVSS scoring is optional, but if you include the score, also include the vector phrase._ 18 | 19 | ## Proof of Concept 20 | 21 | _CODE or Command Lines. We want to offer a concrete, usable, and repeatable way for the vendor to reproduce the issue you are raising so they can test fixes and mitigations._ 22 | 23 | ## Remediation and Mitigation 24 | 25 | _Known remediations. If one is a software update, note the version(s) that fix it._ 26 | 27 | ## Further Analysis 28 | 29 | _If you wish to add more context or information, we recommend adding it after the critical sections mentioned here. If you know the vulnerability has been exploited in the wild, add that here._ 30 | 31 | ## Timeline 32 | 33 | **Date reported**: 34 | 35 | **Date fixed**: 36 | 37 | **Date disclosed**: 38 | 39 | _(Optional - communication and updates summary)_ 40 | -------------------------------------------------------------------------------- /templates/notifications/embargo.md: -------------------------------------------------------------------------------- 1 | # Embargoed Notification 2 | 3 | This is embargoed notification of a vulnerability discovered in $PROJECT. This notification is sent to let distributors and service providers plan for applying patches to reduce the time of user exposure. Information below should be kept confidential until the listed embargo date. Please do not forward this information to other parties. 4 | 5 | ## Summary 6 | 7 | _A brief (as short as possible, about a paragraph) summary of the vulnerability using technical details. The goal of this is to allow the vendor to do a quick assessment of what the bug is about._ 8 | 9 | ### CVE: $CVE-NUMBER 10 | 11 | ### Affected versions: $VERSION 12 | 13 | ### Reporter: $NAME $AFFILIATION 14 | 15 | ## Severity 16 | 17 | _[Low, Medium, HIGH, **CRITICAL**] - Accompany your assessment with a motivation, and even a good attack scenario to explain the risk associated. Including CVSS scoring is optional, but if you include the score, also include the vector phrase_ 18 | 19 | ## Proof of Concept 20 | 21 | _CODE or Command Lines. We want to offer a concrete, usable, and repeatable way for the vendor to reproduce the issue you are raising so they can test fixes and mitigations._ 22 | 23 | ## Remediation and Mitigation 24 | 25 | _Known remediation or planned patch. Include when patch will be available OR links to where the patch is/will be available, or reference attached patch._ 26 | 27 | ## Further Analysis 28 | 29 | _If you wish to add more context or information, we recommend adding it after the critical sections mentioned here._ 30 | 31 | ## Timeline 32 | 33 | **Date reported**: 34 | 35 | **Date fixed**: 36 | 37 | **Date to be disclosed**: 38 | 39 | _(Optional - communication and updates summary)_ 40 | 41 | **_Public disclosure date: $DATE $TIME $TIMEZONE_** 42 | 43 | Please do not make the issue public, issue user communications, share this information with others, or issue public patches before the disclosure date. We will notify this list immediately if the disclosure date is at risk or changes. 44 | -------------------------------------------------------------------------------- /templates/security_policies/email_intake.md: -------------------------------------------------------------------------------- 1 | # SECURITY.md for email intake 2 | 3 | To report a security issue, please email $VMTalias with a description of the issue, the steps you took to create the 4 | issue, affected versions, and if known, mitigations for the issue. Our vulnerability management team will acknowledge receiving your email within 3 working days. This project follows a 90 day disclosure timeline. 5 | -------------------------------------------------------------------------------- /templates/security_policies/github_security_policy.md: -------------------------------------------------------------------------------- 1 | # SECURITY.MD for GitHub Security Policy 2 | 3 | To report a security issue, please email $VMTalias with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline. 4 | -------------------------------------------------------------------------------- /templates/security_policies/other_intake_systems.md: -------------------------------------------------------------------------------- 1 | # Security policy for other intake systems 2 | 3 | To report a security issue, please visit $LINK and $DIRECTIONS. 4 | 5 | If you have questions about reporting security issues, email the vulnerability management team: $VMTalias. 6 | 7 | This project follows a 90 day disclosure timeline. 8 | --------------------------------------------------------------------------------