#55476 [Docs][Security] Clarify reporter credit and CVE publication timing

原始 PR 作者 jperezdealgaba 合并时间 2026-09-10 18:19 文件变更 2 提交数 7 评论 7 代码增减 +28 / -4

执行摘要

文档明确仅首位报告者获致谢，并澄清 CVE 与公告时间线

PR body 直接给出了动机：一方面，重复提交与 AI 生成提交的数量已经让「给每位提交者都致谢」变得不可行——原文表述为 “Duplicate and AI-generated submissions make crediting every submitter impractical.”；另一方面，此前的文档没有说明 advisory 被接受后的 CVE 申请时点与公告发布时点，外部研究者无法据此判断披露节奏。作者还额外声明该变更不是重复工作：对 reporter credit、CVE assignment 与安全政策更新的开放 PR 检索均未发现已有改动覆盖。

值得一读，但只需快速通读：如果你负责安全响应、社区贡献者关系或发布流程，应重点看两条规则的措辞与判定口径——「首位报告者」的判定依据、以及公告发布绑定 release 后是否存在时限兜底。若你只关注推理性能与模型支持，本 PR 可以跳过。设计决策上值得留意的是：vLLM 选择用「工作量不可持续」作为不逐一致谢的公开理由，并把披露时点从 VMT 主动发布改为随版本发布，这两点都会进入外部研究者对项目的预期模型。

讨论亮点

本次变更几乎没有实质技术争论：review_comments_count 为 0，唯一的 approve 来自维护者 russellb，评论为 “lgtm, thanks!”。

可提炼的三点：

维护者快速放行：russellb 以 APPROVED 状态直接通过，说明致谢口径与时序澄清在维护者层面属于既有共识的文档化，而非新政策引入。
自动化评审缺位：claude[bot] 明确表示 “This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.”，且无人触发，等于该 PR 只有一轮人工快速浏览。CodeRabbit 也给出 “No actionable comments were generated in the recent review.”
作者主动补 CI：作者连续发出 /ci 与 /ci run，由 github-actions[bot] 触发 Buildkite CI #88102，属于文档 PR 的常规流程动作，未产生讨论。

未解决的疑虑：讨论中没有出现对「首发致谢」政策可能打击独立重复发现积极性的回应，也没有说明如何判定「首位」（提交时间还是 triage 认定时间）。

实现拆解

在 SECURITY.md 新增 Reporter credit 小节：规定漏洞致谢只给首位报告者，后续报告同一问题（含独立重复发现）不予致谢，并解释原因——重复与 AI 生成报告的量级会让漏洞管理团队（VMT）承担不可持续的工作量。该小节位于报告方式说明与 Threat model 之间，属于对外的第一手政策入口。
在 SECURITY.md 新增 CVE assignment and advisory publication 小节：把披露时序拆成两条可核对的规则——advisory 被接受后，补丁合并时申请 CVE；修复进入 vLLM 发行版时发布公告。该小节插在「按严重级别处理修复流程」与 Prenotification policy 之间，明确保留 case-by-case 调整权。
在 docs/contributing/vulnerability_management.md 新增 Reporter Credit 小节：与 SECURITY.md 表达同一政策，措辞略有差异（“Duplicate and AI-generated submissions are common enough that crediting every submitter is not practical”）。这意味着同一条政策在仓库中有两处落点，后续修改需要同步。
重写 Vulnerability Disclosure 流程条目：把原先「VMT 与维护者协调发布修复并发布包含该修复的更新」和「VMT 在 GitHub 发布安全公告」两条，改为「advisory 被接受后，补丁合并时申请 CVE」和「修复进入 vLLM release 时在 GitHub 发布公告」，即把公告发布时点从「VMT 主动发布」改为「绑定 vLLM 发行节奏」。
测试、配置与部署配套：无。文档预览由 mergify bot 的 Read the Docs 构建提供（https://vllm--55476.org.readthedocs.build/en/55476/），CI 由作者手动以 /ci、/ci run 触发。

文件	变更	目的
`SECURITY.md`	+17/-0，新增两节	对外明确致谢口径与 CVE/公告时序
`docs/contributing/vulnerability_management.md`	+11/-4，新增一节并重写两条流程项	与 `SECURITY.md` 对齐，细化披露步骤

文件	模块	状态	重要度
`SECURITY.md`	安全政策	modified	2.75
`docs/contributing/vulnerability_management.md`	贡献指南	modified	2.71

分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。

评论区精华

只致谢首位报告者的政策是否会被接受 设计

PR body 说明重复提交与 AI 生成提交使逐一致谢不可行；CodeRabbit 未给出可执行意见；维护者 russellb 直接 APPROVED 并评论 “lgtm, thanks!”，未提出反对或修改要求。

结论：政策按原样合入，视为对既有实践的文档化确认。 · 已解决

CVE 申请与 advisory 发布时点的澄清 documentation

原文档只写 VMT 会协调发布修复并发布公告，未区分 CVE 申请与公告公开两个事件。本次改为「advisory 被接受后，补丁合并时申请 CVE」与「修复进入 vLLM release 时发布公告」。

结论：披露时序被绑定到补丁合并与版本发布两个可观测节点，讨论中无人质疑该绑定会推迟披露。 · 已解决

fork PR 的自动化评审与 CI 触发 other

claude[bot] 声明来自 fork 的 PR 自动评审被禁用，需要维护者手动触发；CodeRabbit 声称无 actionable comments；作者自行发出 `/ci` 与 `/ci run` 触发 Buildkite CI #88102。

结论：该 PR 实质只经过一轮人工快速浏览，未产生额外审查意见。 · 已解决

风险与影响

流程风险（对外预期管理）：SECURITY.md 与 docs/contributing/vulnerability_management.md 的「只致谢首位报告者」条款，可能降低研究者在发现已知漏洞后仍愿意补报细节、PoC 或修复建议的意愿，进而损失情报而非减少工作量。政策本身是权衡结果（PR body 已说明重复与 AI 报告的压力），但缺少对「非首报但有增量信息」情形的兜底说明。
判定口径不清：文档只定义「首位报告者」，未定义判定依据（表单提交时间、VMT triage 结论、抑或 advisory 创建时间），在同时提交或重复提交场景下可能产生争议。
披露时序风险：新表述把公告发布绑定到「修复进入 vLLM release」，若 release 周期拉长，advisory 公开时间可能被推迟，与业界常见的披露时限预期（如 90 天）产生张力；文档没有给出最长等待时间的承诺。
一致性维护成本：同一政策在两个文件中以不同措辞重复描述，未来修改容易只改一处。
回归/性能/安全实现风险：无。变更不涉及任何源码路径、内核、调度或量化逻辑，不存在运行时回归面。

对用户与下游厂商：公告发布时点与 vLLM 发行节奏绑定后，下游厂商可以按 release 时间表预判安全公告窗口；Prenotification policy 未变，高强度漏洞的提前通知流程不受影响。
对社区贡献者与安全研究者：致谢规则收紧，属于直接影响贡献激励的政策变更；影响面是心理与流程层面，而非功能层面。
对漏洞管理团队（VMT）：明确了拒绝重复致谢的书面依据，降低逐案沟通成本，是本次变更最直接的收益方。
对工程系统：无影响——不改变任何推理路径、API 行为、性能或兼容性。
对团队协作：文档 PR 由 6 次 Merge branch 'main' 与 1 次内容提交构成，反映该分支存活时间较长、需要反复同步主线，但流程上无异常。

纯文档变更双文档需同步维护致谢政策争议风险披露时点绑定发布节奏评审强度较低

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。

完整报告

[Docs][Security] Clarify reporter credit and CVE publication timing

1. 执行摘要

这是一次纯文档变更（2 个文件、+28/-4），在 SECURITY.md 和 docs/contributing/vulnerability_management.md 中固化两条安全流程规则：漏洞致谢只给首位报告者（独立重复发现亦不予致谢），以及 CVE 在补丁合并时申请、安全公告随修复进入 vLLM 发行版时发布。变更不触及任何代码路径，但会直接影响外部安全研究者与下游厂商对 vLLM 漏洞流程的预期。重要度属于常规维护（3/10），洞察价值中等（4/10）——真正值得关注的是政策口径而非实现细节。

2. 功能与动机

PR body 给出了两个明确动机：

Credit for a vulnerability is given only to the first reporter. Subsequent reports of the same issue, including independent rediscoveries, are not credited. Duplicate and AI-generated submissions make crediting every submitter impractical.

致谢口径模糊：原文档未说明重复提交或独立重复发现是否致谢，VMT 需要逐案解释，沟通成本随重复报告增长。
披露时序模糊：原流程只写「VMT 协调发布修复并发布公告」，没有区分 CVE 申请 与 advisory 公开 两个事件，外部研究者无法判断何时能看到 CVE 与公告。

作者还声明这不是重复劳动：对 reporter credit、CVE assignment 与漏洞管理政策更新的开放 PR 检索均未发现已有改动覆盖。

3. 实现拆解

SECURITY.md 新增 Reporter credit 小节（+17 行中的前半）：位于报告方式说明与 Threat model 之间，是面向外部的第一手政策入口。明确「只致谢首位报告者、独立重复发现不予致谢」，并把理由写明为重复与 AI 生成报告会让漏洞管理团队承担不可持续的工作量。
SECURITY.md 新增 CVE assignment and advisory publication 小节：紧接着修复流程与「VMT 保留 case-by-case 调整权」段落，规定 advisory 被接受后，补丁合并时申请 CVE，修复进入 vLLM release 时发布公告。
docs/contributing/vulnerability_management.md 新增 Reporter Credit 小节：与 SECURITY.md 表达同一政策，措辞略有差异（“Duplicate and AI-generated submissions are common enough that crediting every submitter is not practical”）。同一条政策存在两处落点，后续修改必须同步。
重写 Vulnerability Disclosure 流程条目：原先两条为「VMT 与维护者协调发布修复及包含该修复的更新」和「VMT 在 GitHub 发布安全公告」，现改为「advisory 被接受后，补丁合并时申请 CVE」和「修复进入 vLLM release 时在 GitHub 发布公告」——公告发布时点从 VMT 主动发布改为绑定 vLLM 发行节奏。
测试、配置与部署配套：无。文档预览由 mergify bot 的 Read the Docs 构建提供（https://vllm--55476.org.readthedocs.build/en/55476/），CI 由作者手动以 /ci、/ci run 触发 Buildkite CI #88102。

文件	变更量	关键动作
`SECURITY.md`	+17/-0	新增 Reporter credit、CVE assignment and advisory publication 两节
`docs/contributing/vulnerability_management.md`	+11/-4	新增 Reporter Credit 节，重写 Vulnerability Disclosure 的两条步骤

本 PR 为纯文档变更，预处理阶段未提供任何关键源码片段（源码/测试联动信号为空），因此不展示代码。以下引用为合入后政策条款的语义还原，供理解规则边界：

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.

CVE assignment and advisory publication：After a security advisory has been accepted, a CVE is requested when a patch for the advisory is merged, and the advisory is published when the fix lands in a vLLM release.

Vulnerability Disclosure 重写后的两条步骤：After the advisory has been accepted, a CVE is requested when a patch for the issue is merged / The advisory is published on GitHub when the fix lands in a vLLM release. Release notes will be updated to include a reference to the security advisory.

5. 评论区精华

“lgtm, thanks!” —— russellb（APPROVED）

维护者一轮快速放行，没有 review comment，说明该政策在维护者层面属于既有共识的文档化，而非新政策引入。

“This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.” —— claude[bot]

来自 fork 的 PR 自动评审被跳过，且无人手动触发，故本 PR 实质只有一轮人工浏览；CodeRabbit 也仅回复 “No actionable comments were generated in the recent review.”。作者随后自行发出 /ci、/ci run 触发 CI，属文档 PR 常规动作，未引发讨论。

讨论中没有出现对以下问题的回应：如何判定「首位」（表单提交时间、triage 结论还是 advisory 创建时间）；公告发布绑定 release 后是否存在最长披露时限兜底。

6. 风险与影响

社区激励风险：只致谢首位报告者可能降低研究者在已知漏洞上补报 PoC 与修复建议的意愿，损失的是情报而非仅仅是工作量；文档没有为「非首报但有增量信息」留兜底条款。
判定口径缺口：文档未定义「首位」的判定依据，在并发提交或近同时提交场景下可能产生争议。
披露时序风险：公告发布绑定「修复进入 vLLM release」，若发行周期拉长，公开时间可能被推迟，与业界常见披露时限预期存在张力；SECURITY.md 保留了 VMT 的 case-by-case 调整权，但没有给出最长等待承诺。
一致性维护成本：同一政策在 SECURITY.md 与 docs/contributing/vulnerability_management.md 中以不同措辞重复描述，未来容易只改一处。
无运行时风险：不涉及内核、调度、量化、KV 传输或前端代码，没有性能、兼容性回归面。

影响面上，VMT 是直接受益方（获得拒绝重复致谢的书面依据）；下游厂商可依据 release 时间表预判公告窗口；普通用户与推理系统的行为完全不变。

7. 关联脉络

与仓库历史 PR 的关系：本 PR 与 PR#56058（Rust 前端 HTTP 指标方法标签归一化的安全修复）分属安全响应链条的制度面与修复面——后者是被处理的具体漏洞，前者定义了这类问题从报告、致谢到 CVE 与公告的规则。近期历史 PR 中没有任何改动触及 SECURITY.md 或 docs/contributing/vulnerability_management.md，因此本 PR 是这两份文件在可观察窗口内的独立演进。
更大的演进方向：vLLM 正把安全流程从「隐式实践」转为「显式书面契约」——致谢口径、CVE 申请时点、公告发布时点都被绑定到可观测事件（补丁合并、版本发布）。结合近期 PR#56141、PR#56018 对解析器容错与选择逻辑的持续加固，可以看到项目在对外契约（安全、解析、协议）上倾向于先定义清楚规则，再在实现层补齐。
提交结构：7 次提交中 6 次是 Merge branch 'main'（作者与 mergify bot 交替执行），仅 e96a2e2 为内容提交，说明分支存活期较长但改动本身很小。