Coordinated vulnerability disclosure

协同漏洞披露（CVD）

如何报告、接收和协调安全漏洞，并附有政策示例。

协同漏洞披露（Coordinated vulnerability disclosure，CVD）是计算机安全领域的术语，描述人们如何分享有关安全问题的报告，例如缺陷报告、入侵风险、黑客攻击预警、数据泄露、网站被攻破等。

翻译： العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

目录：

政策：

简介

本文说明什么是协同漏洞披露，希望能帮助人们更好地协作。

本文的目标：

  1. 帮助发现安全问题并希望报告的人。

  2. 帮助企业代表理解负责任披露的需求、目标、做法和特殊情形。

  3. 在仓库文件夹中收录协同漏洞披露政策的示例。

欢迎提交拉取请求（pull request）、GitHub 议题（issue），或发送电子邮件至 security@joelparkerhenderson.com。

什么是协同漏洞披露？

当有人发现安全问题（例如软件缺陷），并希望向生产者（例如开发该软件的公司）报告时，协同漏洞披露包含三个步骤。

步骤：

  1. 发现者本着善意，私下向生产者报告该问题。

  2. 生产者本着善意，努力保护用户并设法解决该问题。

  3. 经过约定的一段时间后，该安全问题被公开。

步骤一：报告问题

步骤一由发现者完成：本着善意私下报告问题。

  • 好的做法：发现者把相关信息发送给生产者，例如发送到生产者的安全电子邮件地址（通常为 "security@example.com"），或通过生产者网站上的网页表单提交（通常位于 "https://www.example.com/security"）。

  • 不好的做法：把报告发布在公开博客上、通知媒体、威胁对方，或试图把该安全问题卖给黑客等。

  • 提示：发现者可以选择匿名；生产者也可以选择匿名。

如果愿意，请持续关注该问题。

  • 好的做法：保持沟通渠道畅通、提供后续信息，或持续关注事态发展。

  • 不好的做法：把这个问题忘在脑后。

  • 提示：发现者可以选择是否提供帮助，也可以选择是否保持联系，并且在情况发生变化时可以调整双方的安排。

如果愿意，可以向他人披露该问题。

  • 好的做法：等待约定的时间后再公开，例如把相关信息发布到安全新闻网站、联系相关的第三方安全研究人员，或在任何公开的社交平台上公布该问题等。

  • 不好的做法：不向他人披露该问题，除非你认为这样做会给你自己或他人带来更大的风险。

  • 提示：如果情况发生变化，例如发现风险更高，或发现该漏洞已在现实中被利用，发现者可以更早地向他人披露。

步骤二：确保联系渠道

步骤二由生产者完成：确保联系渠道可用。

确保员工具备相应能力。

  • 好的做法：生产者培训支持人员，让他们知道收到安全咨询时该怎么做，例如如何回复联系信息，或如何把咨询转交给正确的内部团队。

  • 好的做法：生产者定期验证员工的这些能力是否有效。

  • 不好的做法：生产者不培训，或不验证。

在约定的时限内回复发现者。

  • 如果发现者没有指定时限，则使用一个工作日，因为这是行业标准，也是当前行业的最佳实践。

  • 如果发现者提出问题，请予以解答。当发现者请求测试许可时，这一点尤其重要。请确保所有答复清晰而直接。

通过获得授权的安全联系人和/或获得授权的安全流程回复发现者。

  • 好的做法：使用安全专用的电子邮件地址回复，例如 "security@example.com"。

  • 不好的做法，例如：使用通用的电子邮件地址（如 "help@example.com"）回复，或由并非获得授权的安全专业人员回复。

向发现者确认该问题已被视为安全报告。

  • 好的做法：使用安全专用的措辞，例如“我们的安全团队已收到您的负责任披露报告”，或“我们的安全流程有以下后续步骤”，或“您的信息已录入我们的安全追踪系统，编号为 XYZ”等。

  • 不好的做法：使用通用的措辞，例如“感谢您的惠顾”，或“我们高度重视安全”；或推卸责任式的措辞，例如“我们已把您的邮件转给了另一个部门”等。

步骤三：本着善意合作

步骤三由发现者和生产者共同完成：本着善意合作。

要明白，协同漏洞披露描述的是一个善意的过程。

  • 第一目标：本着善意，帮助用户保护自己免受安全风险。

  • 第二目标：本着善意，解决该安全问题。

  • 发现者和/或生产者可以本着善意选择让其他安全人员参与，例如联系其他相关的安全研究人员来协助处理该问题。

要明白，协同漏洞披露不产生任何义务。

  • 发现者和/或生产者可以在任何时候以任何理由退出，无论是否事先告知。及时让所有相关人员了解最新情况是一种礼貌，但这并不总是可行、切实或理想的。

  • 协同漏洞披露不构成任何法律协议。如果发现者和生产者之间已有法律协议，我们建议所有相关方咨询合适的律师；请勿把本文当作法律建议。

要明白，协同漏洞披露旨在进行良好的沟通，并拒绝威胁。

  • 当所有相关方都明白第一目标是帮助用户保护自己免受安全风险、第二目标是解决安全问题时，协同漏洞披露的效果最好。

  • 协同漏洞披露拒绝任何形式的报复威胁、恐吓、封停、撤销、勒索、后续跟进负担或指责受害者。

要明白，协同漏洞披露对不同的人可能意味着不同的事情。

  • 发现者和生产者对协同漏洞披露可能有不同的理解，这些理解未必一致。善意包括所有相关方都理解这一点。

  • 一些生产者发布了协同漏洞披露政策，这些政策可以作为有益的指引。如果发现者选择采用另一种协同漏洞披露方式，或对负责任披露有不同的理解，这完全没有问题。

要明白，发现者通常是在帮发布者的忙。

  • 发现者通常不需要任何人的许可就可以公布漏洞。

  • 发现者提供的信息通常对发布者有帮助。

验证成功

问题解决后，生产者必须验证是否成功。

  • 所有人员和流程是否成功地处理了此次披露？如果是，很好。如果不是，则考虑开展事后研究，例如根本原因分析（RCA）、事后复盘报告、石川图（鱼骨图），或基于系统理论的因果分析（CAST）。

  • 是否对尚未解决的问题进行了分类和跟踪？

  • 生产者和发现者是否都清楚后续步骤该做什么？这一点尤其重要，因为之后可能还会有后续的协同漏洞披露。

指引

协同漏洞披露的指引可以来自许多方面，例如伦理专家、法律倡导者、公众的合理期待等。

如果你在寻求指引，可能会对下面描述的三个方面感兴趣。

  • 好撒玛利亚人

  • 救助义务

  • 注意义务

好撒玛利亚人

维基百科：好撒玛利亚人法

好撒玛利亚人法为那些向受伤、患病、处于危险或丧失行为能力（或被认为如此）的人提供合理帮助的人提供法律保护。这类保护旨在减少旁观者因担心被起诉或被追究而不敢施救的顾虑。

救助义务

维基百科：救助义务

救助义务这一概念描述了这样一种情形：一方因未能救助处于危险中的另一方而可能被追究责任。救助义务可能涉及道德层面和/或法律层面。

注意义务

维基百科：注意义务

注意义务是指在实施任何可预见会伤害他人的行为时，应当达到合理注意标准的义务。注意义务可能涉及道德层面和/或法律层面。需要考虑的方面包括：伤害或损害的可预见性、潜在伤害或损害的可能严重程度、被告所从事活动的重要性或社会价值、该行为对被告的有用性、替代行为的可行性、与替代行为相关的成本和负担、替代行为的相对有用性，以及替代行为的相对安全性。

特殊情形

我们的安全团队见过各种各样的特殊情形。

我们在此描述这些情形，是为了帮助人们了解：对于什么可以接受、什么不可以接受，存在着广泛的不同意见。我们建议所有相关方就这些问题本着善意进行沟通。

访问其他用户的信息

示例：你发现某个网址中含有你的用户 ID，并暴露出一个缺陷，你认为可以通过修改网址，把你的用户 ID 改成另一个用户 ID。

  • 发现者这样做是否可以？例如，唯一的目的是查明是否也影响了其他用户。

  • 迅速弄清对所有用户的风险范围，是否比保护几位其信息可能已被黑客看到的用户更重要？

  • 发现者想试多少个用户都可以吗？

  • 发现者是否可以尝试联系用户，让他们知道自己受到了影响？是否可以提供缓解建议？

拒绝服务

示例：你发现一个缺陷意外地导致你的账户被暂停，例如触发了密码锁定。

  • 这是否算作拒绝服务攻击？

未经请求的电子邮件

示例：你试图向公司内你认为相关的人员报告安全问题，这些人员是你通过在领英（LinkedIn）、脸书（Facebook）等平台上调查找到的，或者是你借助命名惯例（例如 "webmaster@example.com" 或 "security@example.com"）推测出来的。

  • 这样做是否可以？

  • 这是否算作未经请求的电子邮件？

  • 这是否算作未经授权的电子邮件？

被排除的群体

示例：你属于被排除的群体，例如未成年人，或在制裁名单上，或身处制裁名单上的国家。

  • 你是否可以提交报告？

  • 是否可以匿名报告？

  • 为了摆脱被排除的身份，并且为了让披露能够送达正确的人，故意更改可能识别身份的信息，是否可以？

第三方

示例：你发现某公司的软件存在涉及第三方的缺陷，例如与另一款软件或另一个网站的集成。

  • 你是否可以把发现的所有信息报告给双方？

  • 是否有必要进行两次不同的负责任披露，例如向一家公司报告一份，向第三方公司报告另一份，以限制发送给每家公司的信息？

  • 发现者是否可以让这两家公司互相联系？

破坏性软件

示例：你的技术足以编写一种病毒，你相信它很可能帮助用户保护自己免受安全风险，或识别自己是否面临风险，或修复该安全风险。

  • 这样做是否可以？

  • 发现者是否可以把用户引向此类软件，和/或引向介绍如何创建此类软件的指南或教程？

协同漏洞披露与负责任披露

“协同漏洞披露”是首选术语。

  • 最重要的是发现者与生产者之间的协调。

“负责任披露”是已被弃用的术语。

  • 人们对什么才算负责任有不同的看法。例如，有些人主张：无论与生产者的互动如何，发现者立即通知公众才是负责任的；而进行协同漏洞披露则是不负责任的，因为这会向公众隐瞒信息。

追踪信息