| 1 | # Vulnerability Management |
| 2 | |
| 3 | ## Reporting Vulnerabilities |
| 4 | |
| 5 | As mentioned in the [security |
| 6 | policy](https://github.com/vllm-project/vllm/tree/main/SECURITY.md), security |
| 7 | vulnerabilities may be reported privately to the project via |
| 8 | [GitHub](https://github.com/vllm-project/vllm/security/advisories/new). |
| 9 | |
| 10 | ## Vulnerability Management Team |
| 11 | |
| 12 | Once a vulnerability has been reported to the project, the Vulnerability |
| 13 | Management Team (VMT) is responsible for managing the vulnerability. The VMT is |
| 14 | responsible for: |
| 15 | |
| 16 | - Triaging the vulnerability. |
| 17 | - Coordinating with reporters and project maintainers on vulnerability analysis |
| 18 | and resolution. |
| 19 | - Drafting of security advisories for confirmed vulnerabilities, as appropriate. |
| 20 | - Coordination with project maintainers on a coordinated release of the fix and |
| 21 | security advisory. |
| 22 | |
| 23 | ### Security Advisories |
| 24 | |
| 25 | Advisories are published via GitHub through the same system used to report |
| 26 | vulnerabilities. More information on the process can be found in the [GitHub |
| 27 | documentation](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories). |
| 28 | |
| 29 | ### Team Members |
| 30 | |
| 31 | We prefer to keep all vulnerability-related communication on the security report |
| 32 | on GitHub. However, if you need to contact the VMT directly for an urgent issue, |
| 33 | you may contact the following individuals: |
| 34 | |
| 35 | - Simon Mo - <simon.mo@hey.com> |
| 36 | - Juan Pérez de Algaba - <jperezde@redhat.com> |
| 37 | |
| 38 | ## Slack Discussion |
| 39 | |
| 40 | You may use the `#security` channel in the [vLLM Slack](https://slack.vllm.ai) |
| 41 | to discuss security-related topics. However, please do not disclose any |
| 42 | vulnerabilities in this channel. If you need to report a vulnerability, please |
| 43 | use the GitHub security advisory system or contact a VMT member privately. |
| 44 | |
| 45 | ## Reporter Credit |
| 46 | |
| 47 | Credit for a vulnerability is given only to the first reporter. Subsequent |
| 48 | reports of the same issue are not credited, including independent |
| 49 | rediscoveries. Duplicate and AI-generated submissions are common enough that |
| 50 | crediting every submitter is not practical. |
| 51 | |
| 52 | ## Vulnerability Disclosure |
| 53 | |
| 54 | The process for disclosing vulnerabilities is the following: |
| 55 | |
| 56 | - The VMT will work with the project maintainers to develop a fix for the |
| 57 | vulnerability. |
| 58 | - The VMT will coordinate with the reporter and project maintainers to prepare a |
| 59 | security advisory that adequately describes the vulnerability and its impact. |
| 60 | - After the advisory has been accepted, a CVE is requested when a patch for the |
| 61 | issue is merged. |
| 62 | - The advisory is published on GitHub when the fix lands in a vLLM release. |
| 63 | Release notes will be updated to include a reference to the security advisory. |
| 64 | |
| 65 | The VMT and project maintainers will work to minimize the amount of time in |
| 66 | between disclosing any public information about the vulnerability and making a |
| 67 | release and advisory available. |