漏洞披露备忘录¶

简介¶

本备忘录旨在为安全研究人员和组织提供关于漏洞披露过程的指导。这是一个协作极其重要，但双方之间也常常发生冲突的领域。

研究人员应

确保所有测试均合法且经过授权。
尊重他人的隐私。
尽合理努力联系组织的安全团队。
提供足够详细的信息，以便验证和复现漏洞。
在既定的漏洞赏金计划之外，不应要求为报告漏洞支付报酬或奖励。

组织应

提供明确的方法供研究人员安全地报告漏洞。
明确规定任何漏洞赏金计划的范围和条款。
在合理的时间范围内回复报告。
与研究人员公开沟通。
不威胁对研究人员采取法律行动。
在适当时请求 CVE。
发布清晰的安全公告和变更日志。
提供奖励和致谢。

披露方式¶

披露漏洞时可以遵循多种不同的模式，这些模式列于以下部分。

私下披露¶

在私下披露模式中，漏洞被私下报告给组织。组织可以选择发布漏洞详情，但这由组织自行决定，而非研究人员，这意味着许多漏洞可能永远不会公开。大多数漏洞赏金计划要求研究人员遵循此模式。

这种模式的主要问题是，如果供应商不响应或决定不修复漏洞，则详细信息可能永远不会公开。历史上，这导致研究人员对公司忽视并试图隐藏漏洞的行为感到厌倦，从而促使他们采取完全披露的方法。

完全披露¶

采用完全披露方法，漏洞的完整细节一旦被识别即刻公开。这意味着完整细节（有时包括漏洞利用代码）可供攻击者获取，通常在补丁可用之前。完全披露方法主要用于应对组织忽视已报告漏洞的情况，以对其施加压力，促使其开发并发布修复。

这使得完全披露方法极具争议，并被许多人视为不负责任。通常，它只应作为最后手段，在所有其他方法都已失败或漏洞利用代码已公开可用时才应考虑。

负责任或协调披露¶

负责任披露试图在这两种方法之间找到一个合理的中间点。在负责任披露中，初始报告是私下进行的，但一旦补丁可用（有时会延迟发布以留出更多时间安装补丁），则会发布完整的详细信息。

在许多情况下，研究人员还会为组织设定一个回复报告或提供补丁的截止日期。如果未能达到此截止日期，研究人员可能会采用完全披露方法，并发布完整详细信息。

Google 的 Project Zero 采取类似的方法，无论组织是否发布了补丁，漏洞的完整详细信息都会在 90 天后发布。

报告漏洞¶

本节旨在为安全研究人员提供如何向组织报告漏洞的指导。

警告与合法性¶

在进行任何安全研究或报告漏洞之前，请确保您了解并理解您所在司法管辖区的法律。本备忘录不构成法律建议，不应被视为法律建议。

以下几点强调了需要考虑的几个方面：

如果您正在根据漏洞赏金或类似计划进行测试，组织可能已制定安全港政策，允许您合法进行测试，只要您遵守其计划的范围和规则。请务必仔细阅读范围——超出范围和规则可能构成刑事犯罪。
一些国家有法律限制逆向工程，因此可能不允许对本地安装的软件进行测试。
不要以提供安全漏洞信息为条件，或以不发布详细信息或不向行业监管机构报告为交换条件，要求付款或其他奖励，因为这可能构成敲诈勒索。
如果您收到漏洞赏金付款，这些通常被视为收入，这意味着它们可能需要缴税。报告此收入并确保您支付相应的税款是您的责任。
如果您在工作中发现漏洞，或在雇主拥有的设备上发现漏洞，您的雇主可能会阻止您报告这些漏洞或申请漏洞赏金。在这样做之前，请仔细阅读您的合同并考虑寻求法律建议。

查找联系方式¶

报告漏洞的第一步是找到合适的联系人。尽管有些组织明确发布了披露政策，但许多组织没有，因此可能很难找到正确的报告途径。

如果没有明确的披露政策，以下方面可能提供联系方式：

漏洞赏金计划，例如 BugCrowd、HackerOne、huntr.dev、Open Bug Bounty 或 Standoff。
网站上 /.well-known/security.txt 处的 security.txt 文件，根据 RFC 9116。
现有的问题跟踪系统。
通用电子邮件地址，例如 security@ 或 abuse@。
网站上的通用“联系我们”页面。
社交媒体平台。
致电组织。
向社区求助。

在联系非专门安全联系人时，请请求相关工作人员的详细信息，而不是向最初接受联系的人（尤其是在社交媒体上）披露漏洞详细信息。

如果无法直接联系组织，国家或行业层面的 CERT 可能会提供帮助。

初始报告¶

一旦确定了安全联系人，就应提交漏洞详细信息的初始报告。理想情况下，这应该通过加密通道（例如使用 PGP 密钥）完成，尽管许多组织不支持此方式。

初始报告应包括：

足够详细的漏洞信息，以便理解和复现。
HTTP 请求和响应、HTML 片段、屏幕截图或任何其他支持证据。
- 报告前编辑所有个人数据。
- 一些组织可能会试图声称漏洞从未存在，因此请确保您有足够的证据证明它们确实存在。
概念验证代码（如果可用）。
漏洞的影响。
任何可能适用的参考文献或延伸阅读。

在许多情况下，尤其是在较小的组织中，安全报告可能由没有安全背景的开发人员或 IT 人员处理。这意味着他们可能不熟悉许多安全概念或术语，因此报告应以清晰简单的语言编写。

提供关于如何缓解或解决问题的建议也可能有所帮助。然而，除非已知系统或应用程序的详细信息，或者您对建议非常有信心，否则最好引导开发人员参考一些更通用的指南（例如 OWASP 备忘录）。

如果您计划在一段时间后发布漏洞详细信息（根据某些负责任披露政策），则应在初始电子邮件中明确传达这一点——但请尝试以一种听起来不威胁收件人的语气进行传达。

如果组织没有既定的漏洞赏金计划，那么在初始联系时避免询问付款或奖励——等到问题得到确认（或理想情况下已修复）后再提及。特别是，在透露漏洞详细信息之前，请勿要求付款。这往好听了说是试图诈骗公司，往坏了说是可能构成敲诈勒索。

持续沟通¶

虽然较简单的漏洞可能仅通过初始报告就能解决，但在许多情况下，研究人员和组织之间会有多次邮件往来。特别是对于更复杂的漏洞，开发人员或管理员可能会要求提供额外信息或关于如何解决问题的建议。他们还可能在修复实施后请求协助重新测试问题。尽管没有义务进行此重新测试，但只要请求合理，并提供修复反馈是非常有益的。

如果组织变得不响应，或者公开披露漏洞的既定截止日期临近，可能还需要催促组织。确保这种沟通保持专业和积极——如果披露过程变得敌对，那么双方都不会受益。

如果问题需要一段时间才能解决，请耐心等待。开发人员可能面临组织内部不同人员的巨大压力，并且可能无法完全开放地进行沟通。在企业环境中对修复进行分类、开发、审查、测试和部署所需的时间比大多数研究人员预期的要显著得多，不断地催促更新只会给开发人员增加额外的压力。

何时放弃¶

尽管您付出了所有努力，但有些组织对安全不感兴趣，无法联系，或者可能对披露漏洞的研究人员抱有积极敌意。在某些情况下，他们甚至可能威胁对研究人员采取法律行动。发生这种情况时，研究人员会感到非常沮丧——重要的是不要往心里去。发生这种情况时，可以采取多种选择。

公开披露漏洞，并处理任何负面反应，甚至可能是诉讼。他们是否有充分的法律依据并不重要——他们有昂贵的律师，对抗任何形式的法律行动都是昂贵且耗时的。在走这条路之前，问问自己真的值得吗？
匿名披露漏洞。但是，如果您已经与组织取得联系并尝试向他们报告漏洞，那么谁是披露幕后的人可能就很明显了。如果您要采取这种方法，请确保您已采取足够的运营安全措施来保护自己。
向第三方报告漏洞，例如行业监管机构或数据保护机构。
继续前进。

有许多组织对安全抱有真正的兴趣，并且与安全研究人员非常开放和合作。除非漏洞极其严重，否则不值得为了一个不关心的组织而耗尽心力，或冒着职业和生计的风险。

发布¶

漏洞被修复（或未修复）后，需要决定是否发布详细信息。理想情况下，这应该通过与供应商讨论来完成，并且至少应通知供应商您打算发布，并提供已发布详细信息的链接。披露通常会包括：

漏洞及其影响的概要。
哪些版本存在漏洞以及哪些版本已修复的详细信息。
技术细节或潜在的概念验证代码。
缓解措施或变通方法。
供应商已发布公告的链接。
发现、供应商沟通和发布的时间线。

一些组织可能会要求您完全不发布详细信息，或者延迟发布以给用户更多时间安装安全补丁。为了与组织保持积极关系，值得尝试在这方面找到一个折衷方案。

是否发布可用的概念验证（或功能性漏洞利用代码）是一个争议话题。一些人会认为这是一种不道德的行为，并辩称这样做是直接帮助犯罪分子入侵其用户。另一方面，该代码可用于系统管理员和渗透测试人员测试其系统，如果漏洞足够有价值，攻击者也能够开发或逆向工程出可用的漏洞利用代码。

如果您在敌对环境下（例如组织不响应，或在规定时间已过之后）发布详细信息，则可能会面临威胁甚至法律诉讼。这是否有任何法律依据将取决于您的司法管辖区，以及您是否与组织签署了任何形式的保密协议。在这样做之前，请确保您了解自己的法律立场。

请注意，许多漏洞赏金计划禁止研究人员未经组织同意发布详细信息。如果您选择这样做，您可能会失去赏金或被平台禁止——因此在发布之前请阅读计划规则。

接收漏洞报告¶

本节旨在为组织提供如何接受和接收漏洞报告的指导。

漏洞赏金计划¶

漏洞赏金计划通过提供奖励来激励研究人员向组织识别和报告漏洞。这些奖励通常是金钱形式的，但也可以是实物（赠品）。该过程通常通过第三方管理，例如 BugCrowd 或 HackerOne，它们在研究人员和组织之间提供调解。

实施漏洞赏金计划时，需要明确定义以下方面：

哪些系统和应用程序在范围内。
- 是生产系统还是预发布/UAT 环境？
- 排除由第三方管理或拥有的系统。
哪些类型的漏洞符合赏金资格（SSL/TLS 问题？缺失 HTTP 安全头？版本披露？）。
法律条款，例如安全港政策。
- disclose.io 项目提供了一些示例政策。
- 请向律师寻求法律建议，而不是本备忘录。
赏金金额以及如何做出决定。
- 如果发现大量漏洞，该计划可能会变得非常昂贵。
- 太少的话，研究人员可能不屑于参与该计划。
初始响应、确认、付款和问题解决的时间线。

何时实施漏洞赏金计划¶

漏洞赏金已被许多大型组织（如微软）采用，并开始在商业领域之外使用，包括美国国防部。然而，对于较小的组织而言，它们可能会带来重大挑战，并需要大量的时间和资源投入。这些挑战包括：

有足够的时间和资源来响应报告。
有足够熟练的员工来有效地分类报告。
- 报告可能包含大量垃圾或误报。
- 托管式漏洞赏金计划可以通过执行初始分类来提供帮助（需付费）。
处理大量的误报和垃圾报告。
个人测试生产系统（包括不熟练的攻击者运行他们不理解的自动化工具）的影响。
无法区分合法测试流量和恶意攻击。
研究人员超出范围测试不应测试的系统。
运行该计划的财务成本（一些公司每年支付数十万美元的赏金）。
处理对计划运行方式不满意的研究人员（例如，对赏金金额有异议，或者在报告的问题是重复或超出范围时感到生气）。

尽管存在这些潜在问题，但漏洞赏金计划是识别应用程序和系统中漏洞的绝佳方式。然而，它们只能由已经拥有成熟的漏洞披露流程、并有强大内部流程支持来解决漏洞的组织使用。

发布联系方式¶

该过程中最重要的一步是提供安全研究人员联系您组织的方式。他们越容易联系，您收到安全报告的可能性就越大。以下列表包含一些常用的机制——您可以实施的越多越好：

“联系我们”页面上的专用安全联系人。
在缺陷跟踪器上报告安全问题的专用说明。
常用的 security@ 电子邮件地址。
网站上 /.well-known/security.txt 处的 security.txt 文件，根据 RFC 9116。
使用第三方漏洞赏金计划。

确保一线员工（例如负责监控主要联系地址、网络聊天和电话线的人员）了解如何处理安全问题报告，以及向组织内部的哪些人员上报这些报告，这一点也很重要。

提供报告指南¶

除了联系方式，最好还为研究人员提供一些在报告漏洞时应遵循的指南。这些指南可以包括：

请求可能有助于确认和解决问题的特定信息。
在缺陷跟踪器上使用特定类别或将问题标记为机密。
提供 PGP 密钥用于加密通信。
建立初始响应和分类的时间线。
建立安全港条款。

与研究人员沟通¶

研究人员与组织之间的沟通往往是漏洞披露过程中最困难的环节之一，很容易让双方都对该过程感到沮丧和不满。

以下概述提供了理想沟通过程的示例：

回复初始联系请求，并提供明确的机制供研究人员提供额外信息。
确认漏洞详情并提供进行分类的时间线。
如果需要，请求额外澄清或详细信息。
确认漏洞并提供实施修复的时间线。
- 确认所提供的任何奖励或赏金的详细信息。
如果需要，请研究人员重新测试漏洞。
确认漏洞已解决。

在整个过程中，定期更新当前状态以及漏洞分类和修复的预期时间线。即使没有确切的时间线，持续的沟通也能提供一些保证，表明漏洞没有被遗忘。

研究人员要求付款¶

有些人可能会联系一个组织，声称发现了漏洞，并在分享详细信息之前要求付款。尽管这些要求可能是合法的，但在许多情况下它们只是骗局。

一种选择是要求他们通过中介漏洞赏金平台进行披露，这可以为双方提供一定程度的保护，因为诈骗者不太可能愿意使用这些平台。

披露¶

商业和开源软件¶

一旦漏洞得到解决（并重新测试），应在软件的安全公告中发布详细信息。重要的是要记住，发布安全问题详细信息并不会让供应商看起来很糟糕。所有软件都存在安全漏洞，而展示一个清晰且既定的处理和披露流程，比试图隐藏问题更能让人对软件的安全性充满信心。

安全公告至少必须包含：

漏洞的概要，包括其影响。
明确的受影响版本列表。
明确的补丁版本列表。
关于软件何时易受攻击的任何注意事项（例如，是否只有特定配置受影响）。
可作为临时修复实施的任何变通方案或缓解措施。
漏洞的 CVE 编号。

在可能的情况下，最好还包括：

漏洞披露过程的时间线。
发现漏洞研究人员的致谢。
漏洞的技术细节。
IDS/IPS 签名或其他入侵指标。

安全公告应易于开发人员和系统管理员查找。常见的发布方式包括：

网站上的专用“安全”或“安全公告”页面。
安全邮件列表或论坛。
从主要的变更日志和发布说明中链接。

一些研究人员可能会发布自己的漏洞技术报告，其中通常会包含利用该漏洞所需的完整详细信息（有时甚至包括可用的漏洞利用代码）。对于更严重的漏洞，明智的做法是要求研究人员延迟发布完整详细信息一段时间（例如一周），以便在漏洞利用代码可用之前，为系统管理员提供更多时间安装补丁。然而，一旦补丁发布，攻击者将能够逆向工程该漏洞并开发自己的漏洞利用代码，因此延迟完整发布价值有限。

私有系统¶

对于私有系统中的漏洞，一旦漏洞得到解决，需要决定是否发布详细信息。大多数漏洞赏金计划都给予组织选择是否在问题解决后披露详细信息的选项，尽管通常不要求这样做。

发布这些详细信息有助于表明组织正在采取积极透明的安全方法，但也可能导致潜在的令人尴尬的遗漏和错误配置被公开。如果未来发生泄露或数据泄露，它们还可能被用作组织内部安全文化薄弱的证据。此外，它们可能会暴露内部的技术细节，并可能帮助攻击者识别其他类似问题。因此，应仔细评估此决定，并且寻求法律建议可能是明智之举。

奖励研究人员¶

如果研究人员在漏洞赏金计划之外识别并报告了漏洞（实质上提供了免费安全测试），并且在整个漏洞披露过程中表现专业和乐于助人，那么最好向他们提供某种形式的奖励，以鼓励未来这种积极的互动。如果无法提供金钱奖励，则应考虑其他一些选项，例如：

组织提供的服务或产品的折扣或积分。
虚拟奖励（例如特殊的游戏内物品、自定义头像等）。
T恤、贴纸和其他品牌商品（赠品）。
“名人堂”中的致谢，或类似的其他认可。