漏洞处理最危险的时刻，往往不是修复代码，而是报告刚到达项目时：维护者不知道由谁回复、讨论转移到公开 Issue、复现材料散落在私人邮箱里，最终让一个可控问题变成仓促发布。
这套流程面向中小型、并非以安全为核心的项目。它的目标不是建立一支完整安全团队，而是让维护者在收到漏洞报告时有一张可以照着执行的“操作卡”。如果项目处理密钥、支付、身份认证、基础设施控制面等高风险能力，则需要更严格的威胁建模、独立审计、值班和事件响应机制，不能只依赖这套轻量流程。
先准备一条私密、明确的报告通道
报告者需要在几分钟内确认三个问题：漏洞应该发到哪里、需要提供什么、多久能收到回应。
可以在仓库根目录添加 SECURITY.md。下面的模板可以直接改造，其中邮箱、支持版本和响应时间必须替换为项目的真实信息：
# Security Policy
## Supported Versions
| Version | Supported |
| --- | --- |
| 3.x | Yes |
| 2.x and earlier | No |
## Reporting a Vulnerability
Please do not open a public issue for an unpatched vulnerability.
Send reports to security@example.org with:
- affected version and environment;
- reproduction steps or a minimal proof of concept;
- expected and observed behavior;
- potential impact;
- whether the report may be publicly disclosed.
We aim to acknowledge reports within 3 business days. An acknowledgment
means that we received the report, not that we confirmed the vulnerability.
We will provide status updates when investigation milestones change.
这里最重要的不是措辞，而是承诺必须可兑现。只有兼职维护者的项目，不应写“24 小时内完成修复”；“3 个工作日内确认收到”通常更容易执行。私密通道也要避免单点故障，建议至少有两名维护者可以读取，并定期检查账号和转发规则是否有效。
收到报告后的六个动作
一份漏洞报告进入邮箱后，可以按固定顺序处理：
- 确认收到：给报告分配内部编号，告诉报告者下一次更新时间。此时不要承诺漏洞成立或指定发布日期。
- 控制信息范围：不要把原始报告复制到公开 Issue、聊天频道或普通项目看板。只让参与判断和修复的人访问复现材料。
- 安全复现：在隔离环境使用测试数据复现，避免运行来源不明的脚本，也不要对生产系统直接验证。
- 判断影响：记录受影响版本、攻击前提、所需权限、数据或系统影响，以及是否已有公开利用方法。
- 开发并验证修复：修复根因，同时加入能够防止回归的测试。检查补丁是否意外暴露漏洞细节。
- 协调发布：准备安全版本、升级说明和公告；与报告者商定合理披露时间，但不要让长期失联阻止必要的用户保护措施。
可以用一个受限访问的 YAML 文件记录状态。以下字段不是行业标准，而是一种适合小团队的实践方式：
id: VULN-2025-001
status: investigating
reported_at: 2025-03-08
next_update_due: 2025-03-11
owners:
triage: alice
fix: bob
confidential: true
affected:
confirmed_versions: []
suspected_versions:
- "3.1.x"
assessment:
attack_prerequisites: unknown
privileges_required: unknown
user_interaction: unknown
impact: under-review
release:
fix_ready: false
advisory_ready: false
target_date: null
不要把包含利用代码、真实用户数据或未公开细节的记录提交到公共仓库。可以把这个文件放在权限受控的私有仓库或事件管理系统中。
把“严重”拆成可验证的问题
中小项目未必需要一开始就计算复杂评分，但不能只凭直觉贴上“高危”标签。至少要回答以下问题：
- 哪些版本和默认配置受影响？
- 攻击者需要登录、特定角色或本地访问吗？
- 是否需要受害者点击链接或导入文件？
- 影响是信息泄露、权限提升、任意代码执行，还是单个进程崩溃？
- 攻击能否跨租户、跨用户或持续存在？
- 临时缓解措施是否真的降低风险，会不会引入新的故障？
证据不足时，应写“尚未确认”，而不是直接关闭报告。反过来，能够触发异常也不自动等于安全漏洞：维护者仍需建立攻击路径和实际影响。
修复交付要覆盖补丁之外的工作
修复应尽量落在所有仍受支持的版本上，并包含回归测试。发布公告至少要说明受影响范围、已修复版本、升级方法、临时缓解措施和致谢方式。概念验证代码是否同步公开，需要根据用户完成升级所需时间和现实攻击风险判断。
发布前可以执行一份轻量检查清单：
#!/usr/bin/env bash
set -euo pipefail
required=(
"regression test passes"
"supported branches reviewed"
"release artifact built"
"upgrade instructions verified"
"advisory reviewed"
"reporter notified"
)
printf 'Security release checklist:\n'
for item in "${required[@]}"; do
printf '[ ] %s\n' "$item"
done
将它保存为 security-release-checklist.sh 后运行 bash security-release-checklist.sh，再由负责人逐项确认。脚本本身不会验证安全性，它的作用是减少发布压力下的遗漏。
采用这套流程时的边界
轻量流程适合报告量低、维护团队较小、系统风险有限的项目。落地时至少确认：仓库中存在清晰的私密报告入口；两个人能够接收报告；每个事件有负责人和下一更新时间；复现发生在隔离环境；补丁带有回归测试；公告与修复版本同步准备。
如果项目保存高价值数据、广泛运行在生产基础设施中，或者一个漏洞可能造成大规模身份、资金或供应链影响，就应升级处理能力，包括专业安全支持、审计、密钥轮换预案、取证保全和正式事件响应。操作卡可以帮助团队开始行动，但不能替代与项目风险相匹配的安全体系。