Skip to content
返回维护与 LTS

漏洞响应

漏洞被报或发现时的端到端流程 — 从分诊到修复到披露。

为什么

漏洞报告是定时炸弹 — 每小时未修是攻击者可利用的一小时，且若你处理不当（忽略报告、静默修、补丁前披露）你使更糟。定义的响应流程把恐慌变清单：24 小时内确认、分诊严重度、私分支开发修复、与报告者协调披露、发补丁、然后发 CVE/公告。流程还防两失败模式：忽略报告（漏洞坐数月直到有人利用）和恐慌（仓促修复坏生产造更大事件）。排练过的流程是使中位响应时间 2 天而非 2 月的方式。

何时使用

漏洞被报（security@、Huntr、GitHub Security Advisory）或内部发现时。

如何做

1. 24 小时内确认报告（自动回复 + 48 小时内人工跟进）
2. 分诊：确认真漏洞、赋严重度（CVSS）、定影响版本 + 利用条件
3. 私分支开发修复（security/vuln-<id>）；就绪前勿推 main
4. 写复现漏洞的回归测试，然后修到测试过
5. 与报告者协调披露：定披露日期（通常 90 天，或被利用时更早）
6. 作为补丁发布到所有影响版本（当前 + 活跃 LTS）
7. 发安全公告（GHSA/CVE）含：描述、影响版本、修复版本、CVSS、变通
8. 复盘：如何发现、能否更早抓（模糊测试、SAST、依赖审计）？

示例

# 漏洞响应（GitHub Security Advisory）
# 1. 确认（自动 + 人工）
# security@ 自动回复："已收，48 小时内分诊。参考：VULN-2024-042"

# 2. 分诊（私有公告）
# .github/advisories/vuln-2024-042.yml
summary: "merge() 原型污染"
severity: high           # CVSS 7.5
affected: ">=1.0.0 <1.2.3"
cvss: 7.5

# 3. 私分支修
git checkout -b security/vuln-2024-042
# 加回归测试，修，提交
git commit -m "fix(security): 防 merge() 原型污染 [VULN-2024-042]"

# 4. 协调披露（邮件报告者）
"我们计划 2024-04-15 发公告（90 天窗口）。
补丁将在 v1.2.3。可否？"

# 5. 发 + 披露
git tag v1.2.3  # 补丁发布
# 发 GHSA + CVE-2024-12345
# 公告：https://github.com/ez4code/app/security/advisories/GHSA-xxxx

常见问题

  • ⚠因报告来自未知研究者而忽略 — 多数真漏洞是你从未听过的研究者发现。
  • ⚠静默修无披露 — 漏洞补了但用户不知升故留脆弱。
  • ⚠补丁前披露 — 你给攻击者利用而用户无防御。

最佳实践

  • ✓24 小时内确认每报告并 48 小时内分诊 — 沉默是保证最坏结果的响应。
  • ✓与报告者用协调披露（90 天窗口）— 这在告知攻击者前修用户。
  • ✓每修漏洞发安全公告 — 用户不知修复存在则无法升。