[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>
Juan Pérez de Algaba committed
Sep 10, 2026 at 12:19 UTC
08426d51ef1dd2b86921b9810e9d8b966f97a63a
2 files changed
+28
-4
SECURITY.md
+17
@@ -8,6 +8,16 @@ Please report security issues privately using [the vulnerability submission form
8
9
Reports will then be triaged by the [vulnerability management team](https://docs.vllm.ai/en/latest/contributing/vulnerability_management.html).
10
11
+## Reporter credit
12
+
13
+Credit for a vulnerability is given only to the first reporter. Subsequent
14
+reports of the same issue are not credited, including independent
15
+rediscoveries.
16
+
17
+We do not credit every submitter. The volume of duplicate and AI-generated
18
+reports would otherwise create unsustainable workload for the vulnerability
19
+management team.
20
+
21
## Threat model
22
23
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:
53
54
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.
55
56
+## CVE assignment and advisory publication
57
+
58
+After a security advisory has been accepted:
59
+
60
+* A CVE is requested when a patch for the advisory is merged.
61
+* The advisory is published when the fix lands in a vLLM release.
62
+
63
## Prenotification policy
64
65
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.
docs/contributing/vulnerability_management.md
+11
-4
@@ -44,6 +44,13 @@ to discuss security-related topics. However, please do not disclose any
44
vulnerabilities in this channel. If you need to report a vulnerability, please
45
use the GitHub security advisory system or contact a VMT member privately.
46
47
+## Reporter Credit
48
+
49
+Credit for a vulnerability is given only to the first reporter. Subsequent
50
+reports of the same issue are not credited, including independent
51
+rediscoveries. Duplicate and AI-generated submissions are common enough that
52
+crediting every submitter is not practical.
53
+
54
## Vulnerability Disclosure
55
56
The process for disclosing vulnerabilities is the following:
@@ -52,10 +59,10 @@ The process for disclosing vulnerabilities is the following:
59
vulnerability.
60
- The VMT will coordinate with the reporter and project maintainers to prepare a
61
security advisory that adequately describes the vulnerability and its impact.
55
-- The VMT will coordinate with the project maintainers to publish a fix and
56
- release an update that includes that fix.
57
-- The VMT will publish the security advisory on GitHub. Release notes will be
58
- updated to include a reference to the security advisory.
62
+- After the advisory has been accepted, a CVE is requested when a patch for the
63
+ issue is merged.
64
+- The advisory is published on GitHub when the fix lands in a vLLM release.
65
+ Release notes will be updated to include a reference to the security advisory.
66
67
The VMT and project maintainers will work to minimize the amount of time in
68
between disclosing any public information about the vulnerability and making a