Coordinated vulnerability disclosure
← 政策

NCSC.nl

1. 简介

社会日益数字化。如今，几乎所有流程在某个环节都会用到计算机，从手机到专业软件。尽管这一发展带来了许多新机遇，但 IT 系统中的漏洞可能造成重大影响。因此，应当有效地处理有关这些漏洞的知识。

2013 年初，一些组织开始发布关于如何报告漏洞的政策。在与这些组织协商之后，国家网络安全中心（National Cyber Security Centre，NCSC）以《实现负责任披露实践的指南》（荷兰语：‘Leidraad om te komen tot een praktijk van Responsible Disclosure’；以下简称“指南”）的形式总结了这些进展。企业通过这一政策表明自己愿意接收外部漏洞报告，说明其前提条件并作出承诺。这一过程为报告方创造了清晰且相对安全的环境，使其可以调查并报告漏洞，而不会直接触犯刑法。在 2016 年的欧盟网络安全高级别会议上，29 个组织签署了《协同漏洞披露宣言》（Coordinated Vulnerability Disclosure Manifesto）¹，再次确认了处理漏洞的政策的重要性；该宣言由荷兰 CIO 平台（CIO Platform Netherlands）和荷兰合作银行（Rabobank）发起，并与 NCSC 合作。

协同漏洞披露（Coordinated Vulnerability Disclosure，CVD）已被证明对公共和私营机构都非常重要。它们在日常运营中高度依赖信息系统的不间断运行。近年来，有关其系统漏洞的报告，一方面通过修复漏洞，另一方面通过提升荷兰企业对 IT 安全的整体意识，帮助改善了系统的安全性和连续性。

近年来已经清楚地表明，报告方愿意在各组织制定的 CVD 政策条件范围内开展工作。报告方直接或间接地向各组织提交报告。负责任披露的实践表明，怀有善意的报告方与存在漏洞的组织能够合作，从而在提高网络与信息系统安全方面迈出下一步。

在本次修订中，我们再次与广泛且多样的报告方、私营和公共机构，以及检察机关和国家警察进行了交谈。这些交流证实了当前的实践，并带来了补充和改进。最重要的新关注点，是漏洞报告者与组织之间，以及在漏洞修复后与其他各方之间的沟通。

以下各章讨论 CVD 的定义、CVD 政策的构成要素以及沟通流程。

题外话：先前的指南使用了“负责任披露”（responsible disclosure）一词，这在当时是这种做法的通用术语。此后已经清楚的是，这一术语过于强调报告方的责任，而基本原则应当是：报告方与可能存在漏洞的组织在对话中应是平等的伙伴。当前通用的术语“协同漏洞披露”（CVD）更好地表达了这一理念，ISO 29147 和 30111 标准在这一流程上也使用该名称。

2. 协同漏洞

在过去 30 年里，人们采用过各种方法来提高对 IT 系统漏洞的认识。例如：

  • ‘完全披露’（Full Disclosure），即完全公开漏洞；

  • ‘不披露’（Non-disclosure），即出售或自己利用漏洞；

  • ‘协同漏洞披露’（Coordinated Vulnerability Disclosure，CVD），即有协调地披露漏洞。

最后一种做法是明确的首选。

IT 社区表现出分享知识和经验的强烈意愿。因此，寻求与该社区的合作有助于提高系统的整体安全性。

协同漏洞披露的目标

CVD 的目标，是通过分享有关漏洞的知识来促进 IT 系统的安全。在 CVD 中，知识被分享给一个或多个可能存在漏洞的组织，以便与报告方合作，为所发现的漏洞找到共同的解决方案。重要的是，受影响的组织要有足够的时间来修复漏洞或保护系统，以尽可能限制或防止损失或损害。这一流程的基石，是在漏洞修复后披露有关漏洞的知识。

在 CVD 中，至关重要的是所有各方都遵守关于如何报告漏洞以及如何处理漏洞的约定。如果组织事先公布前提条件，例如哪些系统在范围之内，以及可以开展哪种研究，会有所帮助。这些前提条件的一项重要原则是：如果调查和报告是在设定的条件之内进行的，组织原则上不会举报报告方，也不会采取其他法律措施。本指南为组织制定自己的政策以体现 CVD 的原则提供了指导。

顾名思义，CVD 的核心是组织与报告方之间相互协调。在这方面，报告漏洞的人与组织内负责解决问题的人之间，应当尽可能少设中间环节。

如果某个漏洞影响许多系统，可能有必要同时通知多个相关方。在这种情况下，NCSC 或安全社区内的其他方可以以协调者的角色支持 CVD 流程。

3. 责任范围

推行 CVD 政策的目的，是让报告方与组织共同努力，减少 IT 系统中的漏洞。实施这一政策应被视为对现有信息安全措施的补充。各个参与者都有各自的角色和责任，下文将更详细地说明。

拥有/管理系统的组织

拥有/管理或提供系统的组织，对该系统的安全负首要责任。换言之，组织也要负责跟进处理漏洞报告。

组织可以选择依据本指南制定自己的 CVD 政策，并向潜在的报告方公布该政策。通过发布 CVD 政策，组织表明其愿意接收有关漏洞的信息。

制定 CVD 政策的一方可以承诺这样的原则：如果遵守了政策所适用的规则，就不会向警方提出控告。

一旦报告方报告了漏洞，责任就在于组织。需要认识到，报告方往往是组织之外的人。该方无法直接了解漏洞报告之后可能触发的内部流程。因此，报告方会乐于了解漏洞解决过程的进展。这种持续的沟通，对于就后续跟进和解决方案的及时性建立正确的预期，也很重要。

报告漏洞的一方

报告方以某种方式发现了漏洞，并希望通过让漏洞得到修复，并可能在之后阶段予以公开，来促进 IT 系统的安全。报告方可能是通过被动观察，也可能是通过主动测试 IT 系统发现的。当然，该方要对自己的行为以及发现漏洞的方式负责。了解组织在其 CVD 政策中设定的条件，是报告方自己的责任。大多数政府和企业都已在其网站上发布了 CVD 政策。

然而，发现漏洞可能涉及违法。在 CVD 的框架下，组织与报告方可以约定，对于任何犯罪行为都不提出控告。在这方面，组织发布的 CVD 政策是指导原则。双方也可以约定不采取民事诉讼。

如果怀疑报告方触犯了法律，CVD 政策首先可以帮助避免报告方被举报给当局。这一程序完全取决于组织要求报告方遵守的政策前提条件，以及这种遵守是否已经做到；同时可能附带相应的承诺：只要该方在政策条件范围内行事，就不提出刑事控告。如果警方接到报案，在荷兰，CVD 政策的存在以及报告方对其的遵守，是检察官在决定是否启动刑事调查和/或提起公诉时会考虑的相关情节。原则上，如果报告方明确遵守了相关组织 CVD 政策的规则，警方和检察机关（OM）不会启动刑事调查。然而，如果有迹象表明报告方有意或无意地做得过火，和/或未遵守 CVD 政策，检察机关和警方可以进一步调查该案。基于该调查，检察机关可以决定是否提起公诉。

检察机关发布了一份政策函，其中更具体地论述了在作出调查和/或起诉决定时重要的各个方面。例如，报告方的行为是否服务于重要的公共利益、该方的行为是否不相称，以及该方是否本可以采取另一种、不那么激烈的方式。相关政策函对这些方面作了进一步阐述。² 2013 年以来的相关判例法³ 表明，即使组织没有 CVD 政策，法院也会考虑这些方面。

4. 协同漏洞披露流程的构成要素

下文分别为组织、报告方和 NCSC 提供了构建 CVD 流程的构成要素。

组织

推动 CVD 始于拥有 IT 系统或提供 IT 产品/系统的组织。毕竟，该组织对这些 IT 系统的信息安全负首要责任。为了与各方有效合作解决漏洞，组织可以决定制定并发布 CVD 政策。制定自己的 CVD 政策，使组织能够展示其如何处理漏洞报告。这样，组织也可以确定其希望以何种方式接收通知。这样的流程可以按如下方式组织：

  • 组织制定并发布 CVD 政策。

  • 在该政策中，组织为报告方可以开展的研究提供清晰的规则，例如允许使用哪些技术，哪些系统在范围之内或之外。

  • 组织让报告方易于提交报告。一种选择是使用标准化的报告方式，例如专用电子邮件地址或在线表单。此外，组织可以决定是否接受匿名报告。

  • 组织预留内部资源并建立流程，以便对报告作出适当响应。建议建立一套流程，使所发现的任何漏洞都能得到妥善修复。在这方面，报告的来源无关紧要。例如，漏洞也可能是由内部员工发现的，或是在测试中发现的。

  • 实践经验表明，在 CVD 政策首次发布之后，人们向组织报告漏洞的兴趣会增加。组织在规划（额外的）资源时应考虑这一点。

  • 组织收到漏洞报告后，应确保报告尽快送达最适合评估和处理该报告的部门。

  • 组织向报告方发送收到报告的确认，最好进行数字签名，以强调其优先级。

  • 随后，组织将与报告方协商，以确定任何公开发布将在多长时间内进行。这一期限在很大程度上取决于漏洞的性质和系统的类型。

  • 作为参考，软件漏洞通常采用约 60 天的期限。修复硬件漏洞更为困难；可以采用 6 个月的参考期限。

  • 根据有多少 IT 系统依赖于被报告漏洞的系统，或者漏洞解决起来是更容易还是更困难，经双方同意延长或缩短这一期限可能是可取的。

  • 漏洞可能难以或无法解决，或者解决它可能需要高昂的成本。在这种情况下，组织可以同意将该漏洞视为可接受的风险而不予修复，可能会与报告方协商后作出。

  • 组织将随时让报告方了解流程的进展。

  • 此外，组织可以提出，因公布该漏洞而对报告方公开致谢。也可以选择向外界联合披露。

  • 如果报告方遵守了 CVD 政策的规则，最好对其报告系统漏洞给予奖励。奖励金额可以取决于报告的质量。奖励报告方可以改善该方与组织之间的关系，并提高人们依照 CVD 政策提交新报告的意愿。

  • 如果该漏洞很可能也存在于其他地方，组织可以经与报告方协商，同意将该漏洞告知更广泛的 IT 社区。

  • 在其 CVD 政策中，组织可以承诺这样的原则：如果报告方遵守了政策中列明的规则，就不会向警方提出控告。

报告方

报告方是 CVD 流程成功的关键。该方以某种方式发现了漏洞，并希望通过让组织修复该漏洞并予以公开，来促进 IT 系统的安全。这样做时，报告方承认，通过以协同的方式揭示漏洞，他们可以为社会作出重要贡献。为了实现成功的 CVD 流程，以下构成要素对报告方很重要：

  • 报告方对自己的行为负责，在调查和报告漏洞时必须遵守相称性原则以及辅助性原则。换言之，报告方不应做超出证明漏洞所必需的事情，并且应始终首先向系统/信息的所有者报告漏洞。

  • 报告方必须尽快报告问题，以防止恶意方发现并利用该漏洞。

  • 报告方必须以保密的方式向组织提交报告，以防止其他人获得这些信息。

  • 报告方不得将提交报告或进一步提供信息与奖励挂钩。在收到报告时给予奖励的主动权在于接收方组织，组织可以在其发布的政策中列出前提条件。

  • 报告方与组织就漏洞的披露作出明确约定。如果涉及多个组织，基本原则是，只有所有组织都同意，漏洞才可以公布。建议尽早作出这些约定。

  • 报告方与相关组织可以就告知更广泛的 IT 社区作出约定。例如，这种情形可能适用于已知存在于不止一处的漏洞（无论是否已为人所知）。国家网络安全中心（NCSC）可以参与这一过程，以支持中央政府和关键基础设施的目标群体，或者在漏洞影响许多系统时告知多个相关方。

NCSC

CVD 流程首先是组织和报告方之间的事。尽管如此，NCSC 将鼓励使用 CVD 流程。经与报告方和组织协商，NCSC 也可以参与向其服务对象分享漏洞信息，以限制该漏洞带来的进一步安全风险。

如果漏洞报告的进展不如报告方所愿，或者他们不愿意直接向组织报告漏洞，他们可以联系 NCSC。⁴ 在这种情况下，NCSC 可以在必要时充当中间人。

IT 系统的所有者始终对该系统的安全负责。NCSC 既不能强迫系统所有者修复漏洞，也不能保证所有者不会对报告方采取法律行动。因此，报告方在查找和报告漏洞时，必须考虑上述针对组织和报告方的构成要素。报告方可以期待 NCSC 尽最大努力让漏洞得到修复，并对报告保密。除非有法律义务，NCSC 不会分享任何个人数据。

在可能的情况下，NCSC 将经与组织和报告方协商，利用所获得的漏洞信息，向 IT 社区进一步分享知识。例如，它可以通过公布部分信息、撰写或更新情况说明书或白皮书，或者通知特定组织来做到这一点。

  • 视相关组织和所确认漏洞的性质而定，NCSC 将努力使相关组织注意到该漏洞。不过，相关 IT 系统的所有者仍对该系统负责。

  • 在可能且必要的情况下，NCSC 将就如何修复漏洞向相关组织提供建议。

  • NCSC 将对报告保密，未经同意，不会分享报告方或接收组织的个人数据，除非法定义务要求这样做。

  • 在可能的情况下，NCSC 将让报告方了解与组织联络以及漏洞修复的进展。

  • 在向 NCSC 提交报告的情况下，NCSC 将设法使报告方或潜在报告方与组织取得联系。

例如，如果报告方在某个软件产品中发现了漏洞，或发现了影响许多不同系统的漏洞，报告方可以请求 NCSC 协调漏洞的修复和披露。

NCSC 将与报告方、合作伙伴、开发者和/或软件开发者以及其他安全团队一起，帮助分析、修复或促成修复、协调并以可控的方式披露漏洞。整个过程都与发现该漏洞的报告方密切协商进行。

CVD 政策试图在两方面取得平衡：一是尽快披露漏洞以便采取措施的重要性，二是开发者和供应商有足够时间修复漏洞的重要性。对于这一过程，NCSC 在报告与公开披露之间采用 60 天的标准期限。不过，在某些情况下，可能会决定延长或缩短这一期限。

NCSC 只会在与报告方协商之后，才会与第三方分享有关漏洞的信息。在这方面，至关重要的是 NCSC 开展合作，因此会与利益相关方分享有关漏洞的信息，以便以协同的方式披露漏洞。NCSC 在此过程中将确保合适的各方能够着手修复漏洞，帮助限制任何损失或损害，并帮助引起人们对所发现漏洞的关注。

5. 沟通与披露流程

五年的实践表明，清晰的沟通是成功的 CVD 流程的基石。在 CVD 流程之初、之中和之后，都有需要注意的要点。

关于披露流程的沟通

发布 CVD 政策是就该流程进行沟通的第一步。通过公开发布政策，邀请报告方将所发现的任何漏洞通知组织。

一方面，组织可以对为发现漏洞而开展的研究以及联系方式制定条件。另一方面，组织可以承诺这样的原则：如果遵守了政策的规则，就不会向警方提出控告。这种做法保护了报告方的地位。

CVD 政策日后可能会被更改或更新。对此，必须清楚说明所作的更改。报告方有权了解改了什么、何时改的。例如，可以通过在 CVD 政策开头注明发布日期、在 CVD 政策下方描述变更摘要，或者保留 CVD 政策旧版本的档案，来明确这些更改。

CVD 政策可以提供关于如何在流程中沟通的指引，例如说明通过电子邮件或网络门户进行定期更新。此外，CVD 政策可以说明如何认可报告者，例如在更新中提及他们、将其列入名人堂，或采取任何其他形式的奖励。

披露流程期间的沟通

报告方通过向组织发送消息来启动 CVD 流程。在这条消息中，报告方对所发现的漏洞作出清晰的描述。重要的要素是受影响系统的 IP 地址或网址，以及重现该漏洞的必要步骤。

对组织来说，向报告方清晰地沟通很重要，这样关于流程的预期才会明确。

组织可以通过发送收到确认（自动的或其他方式）来做到这一点，其中注明将在多长期限内发出初步或后续的实质性答复。

也可以不确定这一期限，而在评估报告内容之后再给出初步的期限说明。建议尽早明确可以在多长期限内得出解决方案。这样，报告者就知道何时可以期待结果。

在某些情况下，报告方可能已经明确了公开发布的日期；例如，由于要在某个会议上做演讲，或者因为报告方已经确定了自己的期限。在这种情况下，报告方仍然需要清晰地沟通这一时间线，尽早说明，并明确是否可以推迟该日期。

报告方往往是组织之外的人，无法了解报告可能触发的内部流程。组织可以通过定期更新，让报告方了解流程的进展。这种做法让报告方清楚地知道正在着手解决问题。必要时，组织可以在流程中请求澄清，或请求测试某个解决方案。

如果组织无法满足最初的解决期限，可以与报告者商议推迟。定期沟通可以让报告者更早地了解这一情况。

CVD 的主要意图是缓解漏洞，但如果报告方觉得流程会耗时过长，“完全披露”漏洞始终是报告方可以选择的一项。这一手段就是报告方手中俗话所说的“大棒”。当然，这种情况必须尽可能避免。

披露流程之后的沟通

报告方可能出于多种原因去查找漏洞，然后通过 CVD 流程向组织报告。对许多报告方来说，一项重要的激励是（公开的）认可。

报告方通过更新中的致谢或进入名人堂获得公开认可。不过，并非所有报告方都需要公开认可；事实上，有些人不希望公众知道自己。因此，组织在对外沟通时，宜征得报告方同意后再提及其姓名。

此外，报告方也可以决定在 CVD 流程完成后就报告进行沟通。例如，报告方可以描述发现过程，或警告其他人注意该漏洞。报告者可以决定将发表的内容提交给组织，供其参考。由于 CVD 流程原则上在漏洞消除后即告完成，因此，除非政策中或流程中另有额外约定，报告方此后可以自由地就此进行沟通。

清单

关于披露流程的沟通

  • 在网站上发布 CVD 政策

  • 明确限制（不同的做法参见第 6 章）

  • 对调查方法的限制

  • 关于沟通的指引

  • 关于可能奖励的指引：名人堂、金钱奖励、T 恤等

  • 明确说明 CVD 政策的任何更新，包括更改日期

披露流程期间的沟通

  • 报告者就发现的漏洞联系组织。

  • 组织管理预期，例如首次技术响应的响应时间

  • 组织和报告者就预期的解决期限向对方说明清楚

  • 组织经常提供（流程）更新

  • 必要时，报告者和组织商议联系其他相关组织

披露流程之后的沟通

  • 商议对报告者的（公开）认可和奖励

  • 安排如何公布有关漏洞的信息，例如研究阶段或通知其他组织

6. 协同漏洞披露政策示例

协同漏洞披露的政策文本有许多不同的形式。由于发布的 CVD 政策是给潜在报告方的路标，请确保该政策的形式与组织的政策和战略保持一致。

CVD 政策中，下列要素很重要：

  • 安全通信的联系方式；

  • 对报告方的前提条件；

  • 对处理报告的明确预期；

  • 奖励报告的方式；

  • 版本号和最新修订日期。

下面是三个示例：荷兰的许多组织借鉴了 ResponsibleDisclosure.nl 的基本示例。另一些组织加入了额外的前提条件，参见 Fox IT 的政策。还有一些组织采用更自由的格式，以契合其目标受众，参见 Bits of Freedom 的政策。

示例：ResponsibleDisclosure.nl

本文由 Floor Terra 撰写，并以知识共享署名 3.0 未本地化版（Creative Commons Attribution 3.0 Unported）许可证发布。

在 Acme Corporation，我们把系统安全视为头等大事。但无论我们在系统安全上投入多少努力，仍然可能存在漏洞。

如果您发现了漏洞，我们希望得知，以便尽快采取措施加以解决。

我们想请您帮助我们更好地保护我们的客户和我们的系统。

请您这样做：

  • 将您的发现通过电子邮件发送至 cert@example.com。请使用我们的 PGP 密钥加密您的发现，以免这些关键信息落入不法之手，

  • 不要利用您发现的漏洞或问题，例如下载超出证明漏洞所需的更多数据，或删除或修改他人的数据，

  • 在问题解决之前，不要向他人透露该问题，

  • 不要使用针对物理安全的攻击、社会工程学、分布式拒绝服务、垃圾信息或针对第三方应用程序的攻击，并且

  • 请提供足够的信息以重现问题，以便我们能尽快解决。通常，受影响系统的 IP 地址或网址以及对漏洞的描述就足够了，但复杂的漏洞可能需要进一步说明。

我们的承诺：

  • 我们将在 3 个工作日内回复您的报告，给出我们对报告的评估和预计的解决日期，

  • 如果您遵循了上述说明，我们不会就该报告对您采取任何法律行动，

  • 我们将严格保密地处理您的报告，未经您许可，不会将您的个人信息透露给第三方，

  • 我们将随时向您通报解决问题的进展，

  • 在有关所报告问题的公开信息中，我们会署上您作为问题发现者的姓名（除非您另有意愿），并且

  • 为感谢您的协助，对于每一份我们此前未知的安全问题报告，我们都会提供奖励。奖励金额将根据泄露的严重程度和报告的质量确定。最低奖励为价值 50 欧元的礼品券。

我们努力尽快解决所有问题，并希望在问题解决后，积极参与最终的相关公开发布。

示例：Fox-IT

在 Fox-IT，我们把系统、网络和产品的安全视为重中之重。尽管我们在安全方面非常谨慎，弱点仍可能存在。如果您发现了这样的弱点，我们希望尽快得知，以便尽快采取适当的措施。

弱点可以通过两种方式被发现：您可能在正常使用数字环境时偶然遇到，也可能明确地尽力去寻找。

我们的负责任披露政策并不是邀请您主动扫描我们的业务网络来发现弱点。我们自己会监控业务网络，这意味着扫描很有可能被察觉，我们的安全运营中心（SOC）会展开调查，这可能造成不必要的成本。不过，我们欢迎您在离线的非生产环境中主动查找我们产品中的漏洞，并向我们报告您的发现。出于对客户的责任，我们无意鼓励针对客户基础设施的黑客尝试；但如果发现了漏洞，我们希望尽快收到您的消息，以便妥善解决。

我们希望与您合作，以便更好地保护我们的客户和我们的系统。

我们请您：

  • 尽快将您的发现通过电子邮件发送至 security-alert@fox-it.com。

  • 不要滥用漏洞，例如下载、编辑或删除数据。我们始终会认真对待您的报告，并调查任何关于漏洞的怀疑，即使没有证据。

  • 在问题解决之前，不要向他人分享该问题。

  • 不要使用针对物理安全的攻击、社会工程学或漏洞扫描器之类的黑客工具。

  • 提供足够的信息以重现问题，以便我们能尽快解决。通常，受影响系统的 IP 地址或网址以及对漏洞的描述就足够了，但对于更复杂的漏洞，可能还需要更多信息。

我们的承诺：

  • 我们将在三个工作日内回复您的报告，给出我们对报告的评估和预计的解决日期。

  • 我们将保密处理您的报告，未经您许可，不会将您的个人信息分享给第三方。在发生起诉或被要求提供信息时，向警方和司法机关提供除外。

  • 我们将随时向您通报问题解决的进展。

  • 在有关所报告问题的沟通中，如果您愿意，我们会注明您是发现该问题的一方。

  • 遗憾的是，我们无法事先保证不会对您采取法律行动。我们希望能够逐案考虑每种情况。如果我们怀疑弱点或数据被滥用，或怀疑您向他人分享了有关该弱点的信息，我们认为自己在道义上有义务向有关部门举报。您可以放心，在我们的在线环境中偶然发现问题不会导致起诉。

  • 为感谢您的帮助，对于每一份我们未知的安全问题报告，我们都会提供奖励。我们根据漏洞的严重程度和报告的质量确定奖励的价值。

我们努力尽快解决所有问题，让所有相关方了解情况，并希望在问题解决后参与任何有关该问题的公开发布。

示例：Bits of Freedom

我们对数字基础设施的依赖与日俱增。这既适用于整个社会，也适用于我们自己。因此我们认为，政府和组织（包括我们自己）应当坚定地致力于保障我们的数字基础设施安全。我们确实认识到，尽管我们怀着最好的意愿、给予了最大的关注，我们的系统中仍可能存在漏洞。如果您恰好发现了这些弱点，我们非常希望收到您的来信，以便我们解决问题。

我们对您的期望

  • 当您调查我们的某个系统时，请牢记攻击的相称性。无需通过对我们的网站发起互联网历史上最大规模的 DDoS 攻击，来证明网站可能会无法访问。这一点我们知道。我们也明白，如果您开着推土机撞进我们的办公室，您多半能抢走我们的一台笔记本电脑。

  • 这一相称性原则在演示漏洞本身时同样适用。为了确认您的发现有效，您不应查看或修改超出严格必要范围的数据。例如，如果您能够修改我们的主页，只需在其中添加一个无争议的词语，而不是接管整个页面。如果您能够访问某个数据库，只需向我们展示其中的数据表清单，或者也许是某个表中的第一条记录就足够了。

  • 我们系统中的漏洞应尽快通过发送电子邮件至 security@bof.nl 进行报告。最好使用 OpenPGP 加密您的邮件。请提供足够的信息，以便我们重现并调查该问题。

  • security@bof.nl 的 OpenPGP 公钥

  • 只要我们尚未解决该问题，并且距离您报告问题仍在合理的时间范围内，您就不会向其他方分享您所了解的该漏洞信息。

  • 一旦我们解决了该漏洞，您将删除调查期间获得的所有保密信息。

您可以期待我们做到

  • 我们将在三天内就您的报告给出详细答复。我们会附上我们处理该问题所需时间的预估。当然，我们会定期向您通报进展。

  • 我们将尽快解决该漏洞。在这方面，相称性同样重要：修复漏洞所需的时间取决于多种因素，其中包括问题的严重程度和复杂程度。

  • 当您遵循此处列出的指引时，我们不会就您的报告对您采取法律行动。

  • 如果您愿意，我们很看重对您所做工作的认可。只有在您同意的情况下，我们才会在有关该漏洞的公开发布中提及您的姓名。

  • 为感谢您帮助我们更好地保护系统，我们愿意奖励每一份当时我们未知的漏洞报告。奖励将取决于漏洞的严重程度和报告的质量。

  • 如果您在我们使用的第三方软件中发现了漏洞，并且该漏洞属于某个漏洞赏金计划的范围，我们不会试图领取这笔赏金；应当由您来领取。