[Docs][Security] Clarify reporter credit and CVE publication timing (#55476)
Signed-off-by: Juan Pérez de Algaba <jperezde@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
co-authored by
Cursor
parent
86aca66191
commit
08426d51ef
+17
@@ -8,6 +8,16 @@ Please report security issues privately using [the vulnerability submission form
|
|||||||
|
|
||||||
Reports will then be triaged by the [vulnerability management team](https://docs.vllm.ai/en/latest/contributing/vulnerability_management.html).
|
Reports will then be triaged by the [vulnerability management team](https://docs.vllm.ai/en/latest/contributing/vulnerability_management.html).
|
||||||
|
|
||||||
|
## Reporter credit
|
||||||
|
|
||||||
|
Credit for a vulnerability is given only to the first reporter. Subsequent
|
||||||
|
reports of the same issue are not credited, including independent
|
||||||
|
rediscoveries.
|
||||||
|
|
||||||
|
We do not credit every submitter. The volume of duplicate and AI-generated
|
||||||
|
reports would otherwise create unsustainable workload for the vulnerability
|
||||||
|
management team.
|
||||||
|
|
||||||
## Threat model
|
## Threat model
|
||||||
|
|
||||||
Please see the [Security Guide in the vLLM documentation](https://docs.vllm.ai/en/latest/usage/security.html) for more information on vLLM's security assumptions and recommendations.
|
Please see the [Security Guide in the vLLM documentation](https://docs.vllm.ai/en/latest/usage/security.html) for more information on vLLM's security assumptions and recommendations.
|
||||||
@@ -43,6 +53,13 @@ When a security report is accepted, the fix process depends on the severity:
|
|||||||
|
|
||||||
The vulnerability management team reserves the right to adjust the disclosure approach on a case-by-case basis, taking into account factors such as active exploitation, unusual attack surface, or coordination requirements with downstream vendors.
|
The vulnerability management team reserves the right to adjust the disclosure approach on a case-by-case basis, taking into account factors such as active exploitation, unusual attack surface, or coordination requirements with downstream vendors.
|
||||||
|
|
||||||
|
## CVE assignment and advisory publication
|
||||||
|
|
||||||
|
After a security advisory has been accepted:
|
||||||
|
|
||||||
|
* A CVE is requested when a patch for the advisory is merged.
|
||||||
|
* The advisory is published when the fix lands in a vLLM release.
|
||||||
|
|
||||||
## Prenotification policy
|
## Prenotification policy
|
||||||
|
|
||||||
For certain security issues of CRITICAL, HIGH, or MODERATE severity level, we may prenotify certain organizations or vendors that ship vLLM. The purpose of this prenotification is to allow for a coordinated release of fixes for severe issues.
|
For certain security issues of CRITICAL, HIGH, or MODERATE severity level, we may prenotify certain organizations or vendors that ship vLLM. The purpose of this prenotification is to allow for a coordinated release of fixes for severe issues.
|
||||||
|
|||||||
@@ -44,6 +44,13 @@ to discuss security-related topics. However, please do not disclose any
|
|||||||
vulnerabilities in this channel. If you need to report a vulnerability, please
|
vulnerabilities in this channel. If you need to report a vulnerability, please
|
||||||
use the GitHub security advisory system or contact a VMT member privately.
|
use the GitHub security advisory system or contact a VMT member privately.
|
||||||
|
|
||||||
|
## Reporter Credit
|
||||||
|
|
||||||
|
Credit for a vulnerability is given only to the first reporter. Subsequent
|
||||||
|
reports of the same issue are not credited, including independent
|
||||||
|
rediscoveries. Duplicate and AI-generated submissions are common enough that
|
||||||
|
crediting every submitter is not practical.
|
||||||
|
|
||||||
## Vulnerability Disclosure
|
## Vulnerability Disclosure
|
||||||
|
|
||||||
The process for disclosing vulnerabilities is the following:
|
The process for disclosing vulnerabilities is the following:
|
||||||
@@ -52,10 +59,10 @@ The process for disclosing vulnerabilities is the following:
|
|||||||
vulnerability.
|
vulnerability.
|
||||||
- The VMT will coordinate with the reporter and project maintainers to prepare a
|
- The VMT will coordinate with the reporter and project maintainers to prepare a
|
||||||
security advisory that adequately describes the vulnerability and its impact.
|
security advisory that adequately describes the vulnerability and its impact.
|
||||||
- The VMT will coordinate with the project maintainers to publish a fix and
|
- After the advisory has been accepted, a CVE is requested when a patch for the
|
||||||
release an update that includes that fix.
|
issue is merged.
|
||||||
- The VMT will publish the security advisory on GitHub. Release notes will be
|
- The advisory is published on GitHub when the fix lands in a vLLM release.
|
||||||
updated to include a reference to the security advisory.
|
Release notes will be updated to include a reference to the security advisory.
|
||||||
|
|
||||||
The VMT and project maintainers will work to minimize the amount of time in
|
The VMT and project maintainers will work to minimize the amount of time in
|
||||||
between disclosing any public information about the vulnerability and making a
|
between disclosing any public information about the vulnerability and making a
|
||||||
|
|||||||
Reference in New Issue
Block a user