本文目录导读：
负责任披露时间”（Responsible Disclosure Timeline），这是一个在网络安全、漏洞挖掘和软件工程领域非常重要的概念，它指的是安全研究人员在发现一个安全漏洞后，遵循的一种职业道德和行业标准流程——先私下通知受影响的厂商或开发团队，给予他们合理的修复时间，之后才公开该漏洞的细节。
虽然具体的“时间”没有全球统一的硬性法律，但行业内存在公认的最佳实践标准，以下是主流的负责任披露时间框架：
最普遍的披露时间线：90天规则
由 Google 的 Project Zero（谷歌零日项目）团队推广，现已成为许多大型科技公司接受的标准。
- 0天（发现日）： 安全研究员发现漏洞。
- 第0-1天： 研究员将漏洞细节（POC概念验证代码）以保密方式提交给厂商的漏洞响应团队（PSIRT）。
- 第1-90天： 修复期，厂商分析漏洞、开发补丁、进行测试、分发给用户，在此期间，信息披露是保密的。
- 第90天（截止日）： 如果厂商在90天内发布了修复补丁，研究员会公开漏洞细节（有时会与补丁发布同步）。
- 第90天以后（强制公开）： 如果厂商未能在90天内修复漏洞，安全研究员通常会强制公开漏洞细节（代码、技术分析），以督促厂商加快修复，并警告用户风险。
注意： 如果漏洞已被野外利用，或发现厂商正在秘密利用，研究员可能会立即公开（打破保密期）。
不同的时间框架变体
| 组织/公司 | 标准时间 | 备注 |
|---|---|---|
| Google Project Zero | 90天 | 最严格的“硬截止”期限，到期自动公开。 |
| CERT/CC（美国计算机应急响应中心） | 45天 | 从通知到首次联系后的45天，对于关键基础设施可能更短。 |
| ZDI（零日计划） | 120天 | 在收购漏洞后，给予厂商120天修复时间，可以延期。 |
| HackerOne / Bugcrowd（众测平台） | 90天 | 通常是平台上的标准时间，部分VDP（漏洞披露政策）允许更长。 |
| ISO 29147准则 | 建议1-2周确认，2-3个月修复 | 国际标准，更灵活，强调沟通。 |
负责任披露时间的关键原则（不只是看天数）
- 先通知，后公开： 这是核心，绝不能在发现后直接公开发布（这叫“全面披露”或“直接披露”），这会给用户带来巨大风险。
- 给予合理的修复时间： 时间取决于漏洞的严重程度、修复难度以及受影响系统的广泛性。
- 严重远程代码执行漏洞： 可能只给 7天，如果已遭利用可能更短。
- 低危信息泄露： 可能给 180天。
- 持续沟通： 研究员和厂商之间需要定期沟通（每15-20天确认进度），如果双方保持透明，期限可以适当延长。
- 例外情况（可以缩短或立即公开）：
- 已遭大规模野外利用： 需要立刻警告用户。
- 厂商完全失联或拒绝修复： 研究员可能提前公开。
- 漏洞危及生命或关键基础设施： 时间会大幅缩短。
如果你是安全研究人员或企业
- 对于研究者： 默认采用 90天 时间线，但保持灵活性，先通过官方渠道（安全邮箱）发送PGP加密邮件，如果厂商响应迅速，可以适当延长；如果厂商怠慢，严守90天截止日期。
- 对于企业/厂商： 建立官方的漏洞奖励计划（VDP）和响应流程，理想情况下，在90天内 发布一个可用的补丁，如果无法完成，主动与研究员沟通，请求延期（并提供详细计划和理由），而不是失联。
一句话总结： 负责任披露的“最佳实践”通常指 90天 的保密修复宽限期，之后公开，但这并非死板的规定，根据漏洞严重性和双方沟通情况，时间可能缩短至15天或延长至180天。
