draft-security-advisory

GitHub 安全公告撰写指南

将用户提供的漏洞报告转化为可直接发布的 GitHub 安全公告（GHSA）：表单的每个文本字段都应简洁明了，精确性由 GitHub 的结构化字段承载。

描述类别，而非具体实例

公告应从漏洞类别的层面描述问题：漏洞类别（SQL 注入、SSTI、缺少授权）、失效或缺失的控制措施、功能领域、风险类别。所有属于具体实例层面的信息——函数名、文件路径、字段名、端点、配置键、代码片段、负载——都不得出现，以免读者从公告反推出修复的代码路径。发布的公告对漏洞位置的描述不得比“某些端点”“一个配置字段”“某个页面”“少数记录的名称”更具体——请保持这种描述尺度。

标题

选择合适的既定模式；如果该项目之前发布的公告涉及相同类别的问题，则原样沿用其标题——标题重复是既定风格，不是缺陷：

• 注入漏洞：Possibility of {class} due to missing validation
• 授权漏洞：Unauthorised {action} due to missing validation（英式拼写）
• 以结果为导向：{Outcome} via {class} — 例如：Account takeover via Reflected XSS
• 按功能范围命名：{Class} in {feature area} — 仅当前述模式都不适用时才使用；切勿为了让标题显得独特而采用此模式，因为不同公告使用相同标题完全可以接受。将功能范围概括到不会暴露具体功能的程度：命名比漏洞所在位置宽泛一级的上层范围（例如“门户页面”，而不是某个特定门户），切勿提及模块、屏幕或记录类型。

文本字段

GitHub 表单有四个必填文本字段，顺序如下。每个字段都会公开，因此类别与实例的区分规则适用于全部四个字段——包括 Details 和 Proof of concept，不论其占位文本如何提示。

为每个字段分配不同的职责，避免内容重复：

字段	内容
Summary	一行：漏洞类别及其所属的上层范围（“门户页面”“某些端点”）。
Details	一到两句话：失效或缺失的控制措施，以及修复的大致做法（“已添加验证”）。省略前置条件和受影响的版本，因为 Impact 和 Affected products 已包含这些信息。最后附上缓解措施一行：“No workaround available; upgrading is required.” 仅在确实存在可行的缓解措施时才修改此句。
Proof of concept	用概括性措辞描述攻击方式，例如：“具有低权限角色的已认证用户向受影响的端点发送精心构造的请求。”不得包含负载、端点名称或字段名称。
Impact	攻击者能获得什么、哪些人会受到影响，以及所需的最低权限。

当相应漏洞类别有标准句式时，沿用该句式，并将其拆分到 Summary 和 Impact 中：

• SQL 注入：“某些端点可能通过精心构造的请求受到 SQL 注入攻击，攻击者可借此提取敏感信息。”
• 缺少授权：“某些端点未能执行适当的授权检查，导致用户可以修改超出其角色权限范围的数据。”

对于其他类别，采用相同的措辞风格：“{Class} 通过 {vague vector} 允许 {an authenticated user / a malicious user} {capability}。”

结构化字段

在文本字段之后，列出表单其余部分的值：

• **CVE 标识符：**保留为“Request CVE ID later”——GitHub 会在草稿创建后分配编号
• **受影响产品：**每个当前受支持的发布流占一行——如果报告中未说明，请询问用户支持哪些发布流。每行包括：生态系统、包名称、受影响版本 < {first fixed release}、已修复版本 {first fixed release}
• **严重性：**根据下方规则推导 CVSS v3.1 向量和评分，并为每个不明显的指标选择（PR、S、C、I）提供一句理由；然后填写该评分所属的严重性等级，名称须与表单下拉菜单中的名称一致
• **CWE：**填写可用的最具体编号
• **致谢：**将报告中的报告者列为 reporter；将修复作者列为 remediation developer

以上就是完整的安全公告：不提供根因分析过程、有效载荷或逐步复现步骤。报告中的概念验证（PoC）仅用于确定“概念验证”字段中的攻击方式和 CVSS 指标，不作他用。

推导规则

CVSS 指标，根据报告判断：

• AV——如果可通过 Web UI 访问，则为 Network；如果需要 Shell 访问，则为 Local。
• AC——Low，除非报告描述了竞态条件、非默认配置或难以满足的前置条件。
• PR——未认证时为 None；任何已认证用户或常见运维角色为 Low；仅管理员／超级用户可利用时为 High。
• UI——None，除非必须由受害者采取操作。
• S——当漏洞利用可以访问攻击者自身授权范围之外的资源时，选择 Changed（跨租户数据、该角色通常无法访问的文档类型）。
• C——可读取任意敏感记录时为 High；受限时为 Medium；其他情况为 None。
• I——可任意写入或删除时为 High；写入受限或附带发生时为 Low；只读时为 None。
• A——可能导致服务中断时为 High；其他情况为 None。

CWE——选择可用的最具体编号：

• 模板注入 → CWE-1336
• SQL 注入 → CWE-89
• 缺少授权 → CWE-862
• 输入验证不当 → CWE-20
• 代码注入（通用） → CWE-94
• 路径遍历 → CWE-22
• XSS → CWE-79
• SSRF → CWE-918
• XXE → CWE-611

严重性等级，根据 CVSS 基础评分划分：9.0–10.0 Critical · 7.0–8.9 High · 4.0–6.9 Moderate · 0.1–3.9 Low。

如果报告提供了自己的 CVSS 或 CWE，请验证；如果分析结果与其不一致，则采用你的分析，并用一句话说明差异。

最终检查

重新阅读标题和全部四个文本字段，确保其中没有任何实例级标识符。