Vulnerability Disclosure Cheat Sheet / 漏洞披露作弊清单

Introduction / 介绍

This cheat sheet is intended to provide guidance on the vulnerability disclosure process for both security researchers and organizations. This is an area where collaboration is extremely important, but that can often result in conflict between the two parties.

这份作弊清单旨在为安全研究人员和机构提供漏洞披露流程的指导。这是一个需要双方紧密合作但往往会导致双方冲突的领域。

Researchers should:

研究人员 应该：

• Ensure that any testing is legal and authorized.
  中文：确保任何测试都是合法和授权的。
• Respect the privacy of others.
  中文：尊重他人的隐私。
• Make reasonable efforts to contact the security team of the organization.
  中文：合理努力联系组织的安全团队。
• Provide sufficient details to allow the vulnerabilities to be verified and reproduced.
  中文：提供足够详细的描述，以便验证和重现漏洞。
• Not demand payment or rewards for reporting vulnerabilities outside of an established bug bounty program.
  中文：不要要求在既定的漏洞赏金计划之外支付或奖励报告漏洞。

Organizations should:

**组织 应当：

• Provide a clear method for researchers to securely report vulnerabilities.
  中文：为研究人员提供一种安全地报告漏洞的明确方法。
• Clearly establish the scope and terms of any bug bounty programs.
  中文：明确任何漏洞赏金计划的范围和条款。
• Respond to reports in a reasonable timeline.
  中文：在合理的时间内对报告做出回应。
• Communicate openly with researchers.
  中文：与研究人员进行公开沟通。
• Not threaten legal action against researchers.
  中文：不得威胁对研究人员采取法律行动。
• Request CVEs where appropriate.
  中文：在适当的情况下请求 CVE 编号。
• Publish clear security advisories and changelogs.
  中文：发布清晰的安全公告和变更日志。
• Offer rewards and credit.
  中文：提供奖励和信用.

Methods of Disclosure / 披露方法

There are a number of different models that can be followed when disclosing vulnerabilities, which are listed in the sections below.

在披露漏洞时，可以遵循多种不同的模型，具体如下所述的章节中列出。

Private Disclosure / 私人披露

In the private disclosure model, the vulnerability is reported privately to the organization. The organization may choose to publish the details of the vulnerabilities, but this is done at the discretion of the organization, not the researcher, meaning that many vulnerabilities may never be made public. The majority of bug bounty programs require that the researcher follows this model.

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

The main problem with this model is that if the vendor is unresponsive, or decides not to fix the vulnerability, then the details may never be made public. Historically this has lead to researchers getting fed up with companies ignoring and trying to hide vulnerabilities, leading them to the full disclosure approach.

此模型的主要问题是，如果供应商无响应，或者决定不修复漏洞，那么详细信息可能永远不会公开。历史上，这导致研究人员对公司忽视和试图隐藏漏洞感到沮丧，从而转向完全披露方法。

Full Disclosure / 完全披露

With the full disclosure approach, the full details of the vulnerability are made public as soon as they are identified. This means that the full details (sometimes including exploit code) are available to attackers, often before a patch is available. The full disclosure approach is primarily used in response or organizations ignoring reported vulnerabilities, in order to put pressure on them to develop and publish a fix.

在完全披露方法中，一旦发现漏洞的详细信息就会立即公开。这意味着完整的详细信息（有时包括漏洞利用代码）可供攻击者获取，通常在补丁可用之前。完全披露方法主要用于应对或组织忽视报告的漏洞，以便对他们施加压力，促使他们开发和发布修复方案。

This makes the full disclosure approach very controversial, and it is seen as irresponsible by many people. Generally it should only be considered as a last resort, when all other methods have failed, or when exploit code is already publicly available.

这种完全披露的方法非常具有争议性，许多人认为这是不负责任的行为。通常情况下，它只应在所有其他方法都失败，或者漏洞利用代码已经公开的情况下，作为最后的手段来考虑。

Responsible or Coordinated Disclosure / 负责任或协调披露

Responsible disclosure attempts to find a reasonable middle ground between these two approaches. With responsible disclosure, the initial report is made privately, but with the full details being published once a patch has been made available (sometimes with a delay to allow more time for the patches to be installed).

负责任披露试图在这两种方法之间找到一个合理的折中点。在负责任披露中，最初的报告是私下进行的，但在补丁可用后（有时会有延迟，以便有更多时间安装补丁），会公布全部细节。

In many cases, the researcher also provides a deadline for the organization to respond to the report, or to provide a patch. If this deadline is not met, then the researcher may adopt the full disclosure approach, and publish the full details.

在许多情况下，研究人员还会为组织设定一个响应报告或提供补丁的截止日期。如果这个截止日期没有达到，那么研究人员可能会采用完全披露的方法，并公布全部细节。

Google's Project Zero disclosure policy generally gives vendors 90 days to make a patch available, then publishes technical details 30 days after that patch. If no patch is available by the deadline, details are normally published at 90 days. The policy provides grace periods and a shorter deadline for vulnerabilities exploited in the wild; consult the policy for those exceptions.

谷歌的Project Zero披露策略通常给供应商90天的时间来提供补丁，然后在补丁发布后的30天内公布技术细节。如果在截止日期前没有提供补丁，通常在90天后公布细节。该策略为野外利用的漏洞提供了宽限期和更短的截止日期；有关这些例外情况，请参阅该策略。

Reporting Vulnerabilities / 报告漏洞

This section is intended to provide guidance for security researchers on how to report vulnerabilities to organizations.

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

Warnings and Legality / 警告和法律

Before carrying out any security research or reporting vulnerabilities, ensure that you know and understand the laws in your jurisdiction. This cheat sheet does not constitute legal advice, and should not be taken as such..

在进行任何安全研究或报告漏洞之前，请确保您了解并理解您所在地区的法律。这份速查表不构成法律建议，不应被视为法律建议。

The following points highlight a number of areas that should be considered:

以下要点突出了一些应考虑的领域：

• If you are carrying out testing under a bug bounty or similar program, the organization may have established safe harbor policies, that allow you to legally carry out testing, as long as you stay within the scope and rules of their program. Make sure that you read the scope carefully - stepping outside of the scope and rules may be a criminal offense.
  中文：如果您在执行漏洞赏金或类似计划下的测试，组织可能已建立 安全港 政策，允许您在遵守其计划和规则的前提下合法进行测试。请务必仔细阅读范围 - 超出范围和规则可能构成犯罪。
• Some countries have laws restricting reverse engineering, so testing against locally installed software may not be permitted.
  中文：一些国家有法律限制逆向工程，因此对本地安装的软件进行测试可能不被允许。
• Do not demand payment or other rewards as a condition of providing information on security vulnerabilities, or in exchange for not publishing the details or reporting them to industry regulators, as this may constitute extortion.
  中文：不要以提供有关安全漏洞的信息或因不发布详细信息或向行业监管机构报告而作为索要支付或其他奖励的条件，因为这可能构成敲诈勒索。
• If you receive bug bounty payments, these are generally considered as income, meaning that they may be taxable. Reporting this income and ensuring that you pay the appropriate tax on it is your responsibility.
  中文：如果您收到漏洞赏金支付，这些通常被视为收入，这意味着它们可能是应纳税的。报告这笔收入并确保您支付适当的税款是您的责任。
• If you find vulnerabilities as part of your work, or on equipment owned by your employer, your employer may prevent you from reporting these or claiming a bug bounty. Read your contract carefully and consider taking legal advice before doing so.
  中文：如果您在工作过程中或在工作单位拥有的设备上发现漏洞，您的雇主可能阻止您报告这些漏洞或索要漏洞赏金。仔细阅读您的合同，并在这样做之前考虑寻求法律建议。

Finding Contact Details / 寻找联系方式

The first step in reporting a vulnerability is finding the appropriate person to report it to. Although some organizations have clearly published disclosure policies, many do not, so it can be difficult to find the correct place to report the issue.

报告漏洞的第一步是找到合适的人来报告。尽管一些组织已经明确发布了披露政策，但许多组织没有，因此很难找到正确的报告位置。

Where there is no clear disclosure policy, the following areas may provide contact details:

在没有明确的披露政策的情况下，以下区域可能提供联系方式：

• Bug bounty programs such as BugCrowd, HackerOne, huntr.dev, Open Bug Bounty or Standoff.
  中文：漏洞赏金计划，例如 BugCrowd、HackerOne、huntr.dev、Open Bug Bounty 或 Standoff.
• A security.txt file on the website at /.well-known/security.txt as per RFC 9116. At minimum include the required Contact and Expires fields; optional fields such as Preferred-Languages, Canonical, Policy, and Hiring improve routing for ethical researchers.
  中文：网站上的 security.txt 文件位于 /.well-known/security.txt，根据 RFC 9116。至少包括所需的 Contact 和 Expires 字段；可选字段如 Preferred-Languages、Canonical、Policy 和 Hiring 可提高道德研究人员的路由。
• An existing issue tracking system.
  中文：现有的问题跟踪系统。
• Generic email addresses such as security@ or abuse@.
  中文：通用电子邮件地址，如 security@ 或 abuse@。
• The generic "Contact Us" page on the website.
  中文：网站上的通用“联系我们”页面。
• Social media platforms.
  中文：社交媒体平台。
• Phoning the organization.
  中文：给组织打电话。
• Reaching out to the community.
  中文：向社区伸出援手。

When reaching out to people who are not dedicated security contacts, request the details for a relevant member of staff, rather than disclosing the vulnerability details to whoever accepts the initial contact (especially over social media).

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

If it is not possible to contact the organization directly, a national or sector-based CERT may be able to assist.

如果无法直接联系该组织，可能需要寻求国家或行业基于的 CERT 的协助。

Initial Report / 初步报告

Once a security contact has been identified, an initial report should be made of the details of the vulnerability. Ideally this should be done over an encrypted channel (such as the use of PGP keys), although many organizations do not support this.

一旦确定了安全联系人，应就漏洞的详细信息制作一份初步报告。理想情况下，这应该在加密通道（如使用 PGP 密钥）上进行，尽管许多组织不支持这一点。

The initial report should include:

初步报告应包括：

• Sufficient details of the vulnerability to allow it to be understood and reproduced.
  中文：足够详细的漏洞信息，以便理解和重现。
• HTTP requests and responses, HTML snippets, screenshots or any other supporting evidence.
  中文：HTTP 请求和响应、HTML 片段、截图或任何其他支持证据。
  • Redact any personal data before reporting.
    中文：在报告之前删除任何个人数据。
  • Some organizations may try and claim vulnerabilities never existed, so ensure you have sufficient evidence to prove that they did.
    中文：一些组织可能会试图声称漏洞从未存在过，因此请确保你有足够的证据来证明它们确实存在。
• Proof of concept code (if available).
  中文：概念验证代码（如有）
• The impact of the vulnerability.
  中文：漏洞的影响
• Any references or further reading that may be appropriate.
  中文：可能适用的任何参考文献或进一步阅读材料

In many cases, especially in smaller organizations, the security reports may be handled by developers or IT staff who do not have a security background. This means that they may not be familiar with many security concepts or terminology, so reports should be written in clear and simple terms.

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

It may also be beneficial to provide a recommendation on how the issue could be mitigated or resolved. However, unless the details of the system or application are known, or you are very confident in the recommendation then it may be better to point the developers to some more general guidance (such as an OWASP cheat sheet).

提供有关如何缓解或解决该问题的建议也可能是有益的。然而，除非您了解系统或应用程序的详细信息，或者对建议非常有信心，否则最好将开发人员指向一些更一般的指导（如OWASP速查表）。

If you are planning to publish the details of the vulnerability after a period of time (as per some responsible disclosure policies), then this should be clearly communicated in the initial email - but try to do so in a tone that doesn't sound threatening to the recipient.

如果您计划在一段时间后（根据某些负责任披露政策）发布漏洞的详细信息，那么应在初始电子邮件中明确沟通这一点 - 但尽量以一种不会让收件人感到威胁的语气来做。

If the organization does not have an established bug bounty program, then avoid asking about payments or rewards in the initial contact - leave it until the issue has been acknowledged (or ideally fixed). In particular, do not demand payment before revealing the details of the vulnerability. At best this will look like an attempt to scam the company, at worst it may constitute extortion.

如果组织没有建立漏洞赏金计划，那么在初始联系中避免询问付款或奖励 - 等到问题被确认（或理想情况下修复）后再说。特别是，在披露漏洞细节之前不要索要付款。这最多看起来像是在试图诈骗公司，最坏的情况可能是敲诈勒索。

Ongoing Communication / 持续沟通

While simpler vulnerabilities might be resolved solely from the initial report, in many cases there will be a number of emails back and forth between the researcher and the organization. Especially for more complex vulnerabilities, the developers or administrators may ask for additional information or recommendations on how to resolve the issue. They may also ask for assistance in retesting the issue once a fix has been implemented. Although there is no obligation to carry out this retesting, as long as the request is reasonable then and providing feedback on the fixes is very beneficial.

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

It may also be necessary to chase up the organization if they become unresponsive, or if the established deadline for publicly disclosing the vulnerability is approaching. Ensure that this communication stays professional and positive - if the disclosure process becomes hostile then neither party will benefit.

如果组织变得无响应，或者公开披露漏洞的既定截止日期即将到来，可能也需要跟进组织。确保这种沟通保持专业和积极——如果披露过程变得敌对，双方都不会受益。

Be patient if it's taking a while for the issue to be resolved. The developers may be under significant pressure from different people within the organization, and may not be able to be fully open in their communication. Triaging, developing, reviewing, testing and deploying a fix within in an enterprise environment takes significantly more time than most researchers expect, and being constantly hassled for updates just adds another level of pressure on the developers.

如果问题解决需要一些时间，请保持耐心。开发者可能正承受来自组织内部不同人的巨大压力，他们可能无法在沟通中完全开放。在企业环境中进行分类、开发、审查、测试和部署修复所需的时间比大多数研究人员预期的要长得多，而不断催促更新只会给开发者增加更多压力。

When to Give Up / 何时放弃

Despite every effort that you make, some organizations are not interested in security, are impossible to contact, or may be actively hostile to researchers disclosing vulnerabilities. In some cases they may even threaten to take legal action against researchers. When this happens it is very disheartening for the researcher - it is important not to take this personally. When this happens, there are a number of options that can be taken.

尽管你尽了最大努力，但有些组织对安全不感兴趣，难以联系，或者可能对披露漏洞的研究人员持敌对态度。在某些情况下，他们甚至可能威胁要对研究人员采取法律行动。当这种情况发生时，对研究人员来说是非常令人沮丧的——重要的是不要把它当作个人问题。在这种情况下，可以采取一些措施。

• Publicly disclose the vulnerability, and deal with any negative reaction and potentially even a lawsuit. Whether or not they have a strong legal case is irrelevant - they have expensive lawyers and fighting any kind of legal action is expensive and time consuming. Before going down this route, ask yourself is it really worth it?
  中文：公开披露漏洞，并处理任何负面反应，甚至可能面临诉讼。他们是否有强有力的法律依据无关紧要——他们有昂贵的律师，任何法律行动都是昂贵且耗时的。在走这条路之前，问问自己：这真的值得吗？
• Anonymously disclose the vulnerability. However, if you've already made contact with the organization and tried to report the vulnerability to them, it may be pretty obvious who's responsible behind the disclosure. If you are going to take this approach, ensure that you have taken sufficient operational security measures to protect yourself.
  中文：匿名披露漏洞。然而，如果你已经与组织取得联系并尝试向他们报告漏洞，那么披露背后的责任人可能很容易被识别。如果你打算采取这种方法，确保你已经采取了足够的操作安全措施来保护自己。
• Report the vulnerability to a third party, such as an industry regulator or data protection authority.
  中文：向第三方报告漏洞，例如行业监管机构或数据保护当局。
• Move on.
  中文：继续前进。

There are many organizations who have a genuine interest in security, and are very open and co-operative with security researchers. Unless the vulnerability is extremely serious, it is not worth burning yourself out, or risking your career and livelihood over an organization who doesn't care.

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

Publishing / 发布

Once a vulnerability has been patched (or not), then a decision needs to be made about publishing the details. This should ideally be done through discussion with the vendor, and at a minimum the vendor should be notified that you intend to publish, and provided with a link to the published details. The disclosure would typically include:

一旦漏洞已被修补（或未修补），就需要决定是否发布详细信息。这最好通过与供应商的讨论来完成，至少供应商应该被告知你打算发布，并应提供发布详细信息的链接。披露通常会包括：

• A high level summary of the vulnerability and its impact.
  中文：漏洞及其影响的概述。
• Details of which version(s) are vulnerable, and which are fixed.
  中文：受影响的版本和已修复的版本详情。
• Technical details or potentially proof of concept code.
  中文：技术细节或可能的概念验证代码。
• Mitigations or workarounds.
  中文：缓解措施或工作绕过。
• Links to the vendor's published advisory.
  中文：链接到供应商发布的公告。
• The timeline for the discovery, vendor communication and release.
  中文：发现、供应商沟通和发布的时间线。

Some organizations may request that you do not publish the details at all, or that you delay publication to allow more time to their users to install security patches. In the interest of maintaining a positive relationship with the organization, it is worth trying to find a compromise position on this.

一些组织可能要求您根本不要发布详细信息，或者延迟发布以给用户更多时间安装安全补丁。为了维护与组织的良好关系，尝试在这个问题上找到一个折衷的立场是值得的。

Whether to publish working proof of concept (or functional exploit code) is a subject of debate. Some people will view this as an unethical move, and will argue that by doing so you are directly helping criminals compromise their users. On the other hand, the code can be used to both system administrators and penetration testers to test their systems, and attackers will be able to develop or reverse engineering working exploit code if the vulnerability is sufficiently valuable.

是否发布工作原理证明（或功能性的漏洞利用代码）是一个有争议的话题。有些人会认为这是一种不道德的行为，并会辩称，通过这样做，您直接帮助犯罪分子侵害他们的用户。另一方面，该代码可以被系统管理员和渗透测试人员用来测试他们的系统，如果漏洞足够有价值，攻击者将能够开发或逆向工程有效的漏洞利用代码。

If you are publishing the details in hostile circumstances (such as an unresponsive organization, or after a stated period of time has elapsed) then you may face threats and even legal action. Whether there is any legal basis for this will depend on your jurisdiction, and whether you signed any form of non-disclosure agreement with the organization. Make sure you understand your legal position before doing so.

如果您在敌对的环境下发布详细信息（例如，组织无响应，或者经过一段声明的时间后），您可能会面临威胁甚至法律行动。是否存在任何法律依据将取决于您的司法管辖权，以及您是否与组织签订了任何形式的保密协议。在这样做之前，确保您了解自己的法律立场。

Note that many bug bounty programs forbid researchers from publishing the details without the agreement of the organization. If you choose to do so, you may forfeit the bounty or be banned from the platform - so read the rules of the program before publishing.

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

Receiving Vulnerability Reports / 接收漏洞报告

This section is intended to provide guidance for organizations on how to accept and receive vulnerability reports.

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

Bug Bounty Programs / 漏洞赏金计划

Bug bounty programs incentivize researchers to identify and report vulnerabilities to organizations by offering rewards. These are usually monetary, but can also be physical items (swag). The process is often managed through a third party such as BugCrowd or HackerOne, who provide mediation between researchers and organizations.

漏洞赏金计划通过提供奖励来激励研究人员识别并向组织报告漏洞。这些奖励通常是金钱，但也可能是实物（如周边产品）。这个过程通常由第三方如BugCrowd或HackerOne管理，他们提供研究人员与组织之间的调解服务。

When implementing a bug bounty program, the following areas need to be clearly defined:

在实施漏洞赏金计划时，以下领域需要明确界定：

• Which systems and applications are in scope.
  中文：哪些系统和应用程序在范围内。
  • Live systems or a staging/UAT environment?
    中文：是实时系统还是预发布/UAT 环境？
  • Excluding systems managed or owned by third parties.
    中文：排除由第三方管理或拥有的系统。
• Which types of vulnerabilities are eligible for bounties (SSL/TLS issues? Missing HTTP security headers? Version disclosure?)
  中文：哪些类型的漏洞有资格获得赏金（SSL/TLS 问题？缺少 HTTP 安全头？版本披露？）
• Legal provisions such as safe harbor policies.
  中文：法律条款，如安全港政策。
  • The disclose.io project provides some example policies.
    中文：The disclose.io 项目提供了一些示例策略。
  • Take legal advice from lawyers, not from this cheat sheet.
    中文：请从律师那里获取法律建议，而不是从这份速查表。
• How much to offer for bounties, and how is the decision made.
  中文：提供赏金的金额以及如何做出决定。
  • The program could get very expensive if a large number of vulnerabilities are identified.
    中文：如果发现大量漏洞，该程序可能会变得非常昂贵。
  • Too little and researchers may not bother with the program.
    中文：太少的话，研究人员可能不会费心参与该程序。
• The timeline for the initial response, confirmation, payout and issue resolution.
  中文：初始响应、确认、赔偿和问题解决的时间表。

When to Implement a Bug Bounty Program / 何时实施漏洞赏金计划

Bug bounty have been adopted by many large organizations such as Microsoft, and are starting to be used outside of the commercial sector, including the US Department of Defense. However, for smaller organizations they can bring significant challenges, and require a substantial investment of time and resources. These challenges can include:

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

• Having sufficient time and resources to respond to reports.
  中文：有足够的时间和资源来响应报告。
• Having sufficiently skilled staff to effectively triage reports.
  中文：有足够技能的员工来有效地分类报告。
  • Reports may include a large number of junk or false positives.
    中文：报告中可能包含大量垃圾信息或误报。
  • Managed bug bounty programs may help by performing initial triage (at a cost).
    中文：管理式的漏洞赏金计划可以通过进行初步分类（需付费）来帮助解决问题。
• Dealing with large numbers of false positives and junk reports.
  中文：处理大量误报和垃圾报告。
• The impact of individuals testing live systems (including unskilled attackers running automated tools they don't understand).
  中文：个人测试实时系统的影响（包括不熟练的攻击者运行他们不理解的自定义工具）。
• Being unable to differentiate between legitimate testing traffic and malicious attacks.
  中文：无法区分合法测试流量和恶意攻击。
• Researchers going out of scope and testing systems that they shouldn't.
  中文：研究人员超出范围测试他们不应测试的系统。
• The financial cost of running the program (some companies pay out hundreds of thousands of dollars a year in bounties).
  中文：运行计划的经济成本（一些公司每年支付数十万美元的赏金）。
• Dealing with researchers who are unhappy with how the program is run (such as disputing bounty amounts, or being angry when reported issues are duplicates or out of scope).
  中文：处理对计划运行方式不满意的研究人员（例如对赏金金额有争议，或者在报告的问题被认定为重复或超出范围时感到愤怒）。

Despite these potential issues, bug bounty programs are a great way to identify vulnerabilities in applications and systems. However, they should only be used by organizations that already have a mature vulnerability disclosure process, supported by strong internal processes to resolve vulnerabilities.

尽管存在这些问题，漏洞赏金计划是识别应用程序和系统漏洞的好方法。然而，只有那些已经拥有成熟漏洞披露流程并得到强大内部流程支持以解决漏洞的组织才应使用漏洞赏金计划。

Publishing Contact Details / 发布联系详情

The most important step in the process is providing a way for security researchers to contact your organization. The easier it is for them to do so, the more likely it is that you'll receive security reports. The following list includes some of the common mechanisms that are used for this - the more of these that you can implement the better:

在这个过程中，最重要的步骤是为安全研究人员提供一个联系您组织的方式。他们越容易做到这一点，您收到安全报告的可能性就越大。以下列表包括了一些用于此目的常见机制——您能实施越多越好：

• A dedicated security contact on the "Contact Us" page.
  中文：在“联系我们”页面上的专用安全联系方式。
• Dedicated instructions for reporting security issues on a bug tracker.
  中文：在漏洞跟踪器上报告安全问题的专用说明。
• The common security@ email address.
  中文：常见的security@电子邮件地址。
• A security.txt file on the website at /.well-known/security.txt as per RFC 9116. At minimum include the required Contact and Expires fields; optional fields such as Preferred-Languages, Canonical, Policy, and Hiring improve routing for ethical researchers.
  中文：网站上的 security.txt 文件位于 /.well-known/security.txt，根据 RFC 9116。至少包括所需的 Contact 和 Expires 字段；可选字段如 Preferred-Languages、Canonical、Policy 和 Hiring 可提高道德研究人员的路由。
• Using third party bug bounty program.
  中文：使用第三方赏金猎人计划。

It is also important to ensure that frontline staff (such as those who monitor the main contact address, web chat and phone lines) are aware of how to handle reports of security issues, and who to escalate these reports to within the organization.

同样重要的是确保一线员工（例如那些监控主要联系地址、网络聊天和电话线的员工）了解如何处理安全问题的报告，以及将这些问题报告升级到组织内部的相关人员。

Providing Reporting Guidelines / 提供报告指南

Alongside the contact details, it is also good to provide some guidelines for researchers to follow when reporting vulnerabilities. These could include:

在提供联系详情的同时，为研究人员提供一些在报告漏洞时遵循的指南也是好的。这些可能包括：

• Requesting specific information that may help in confirming and resolving the issue.
  中文：请求可能有助于确认和解决问题的具体信息。
• Using specific categories or marking the issue as confidential on a bug tracker.
  中文：使用特定类别或在漏洞跟踪器上将问题标记为机密。
• Providing PGP keys for encrypted communication.
  中文：提供PGP密钥以进行加密通信。
• Establishing a timeline for an initial response and triage.
  中文：建立初步响应和分类的时间表。
• Establishing safe harbor provisions.
  中文：建立安全港条款。

Communicating With Researchers / 与研究人员沟通

Communication between researchers and organizations is often one of the hardest points of the vulnerability disclosure process, and can easily leave both sides frustrated and unhappy with the process.

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

The outline below provides an example of the ideal communication process:

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

• Respond to the initial request for contact details with a clear mechanism for the researcher to provide additional information.
  中文：明确回应初始的联系方式请求，让研究人员提供更多信息。
• Acknowledge the vulnerability details and provide a timeline to carry out triage.
  中文：确认漏洞详情并提供进行分类的时间表。
• Request additional clarification or details if required.
  中文：如有需要，请求额外的澄清或详细信息。
• Confirm the vulnerability and provide a timeline for implementing a fix.
  中文：确认漏洞并提供实施修复措施的时间表。
  • Confirm the details of any reward or bounty offered.
    中文：确认提供的任何奖励或赏金详情。
• If required, request the researcher to retest the vulnerability.
  中文：如有需要，要求研究人员重新测试漏洞。
• Confirm that the vulnerability has been resolved.
  中文：确认漏洞已被解决。

Throughout the process, provide regular updates of the current status, and the expected timeline to triage and fix the vulnerability. Even if there is no firm timeline for these, the ongoing communication provides some reassurance that the vulnerability hasn't been forgotten about.

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

Researchers Demanding Payment / 要求支付的研究人员

Some individuals may approach an organization claiming to have found a vulnerability, and demanding payment before sharing the details. Although these requests may be legitimate, in many cases they are simply scams.

有些人可能会接近一个组织，声称发现了漏洞，并在分享细节之前要求支付。尽管这些请求可能合法，但在许多情况下，它们只是骗局。

One option is to request that they carry out the disclosure through a mediated bug bounty platform, which can provide a level of protection for both sides, as scammers are unlikely to be willing to use these platforms.

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

Disclosure / 披露

Commercial and Open Source Software / 商业和开源软件

Once the vulnerability has been resolved (and retested), the details should be published in a security advisory for the software. It is important to remember that publishing the details of security issues does not make the vendor look bad. All software has security vulnerabilities, and demonstrating a clear and established process for handling and disclosing them gives far more confidence in the security of the software than trying to hide the issues.

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

At a minimum, the security advisory must contain:

至少，安全公告必须包含：

• A high level summary of the vulnerability, including the impact.
  中文：漏洞的高级概述，包括影响。
• A clear list of vulnerable versions.
  中文：一个清晰的易受攻击版本列表。
• A clear list of patch versions.
  中文：一个清晰的补丁版本列表。
• Any caveats on when the software is vulnerable (for example, if only certain configurations are affected).
  中文：关于软件何时易受攻击的任何注意事项（例如，如果只有某些配置受到影响）。
• Any workarounds or mitigation that can be implemented as a temporary fix.
  中文：任何可以作为临时修复实施的解决方案或缓解措施。
• A Common Vulnerabilities and Exposures (CVE) ID, if one has been assigned. Request an ID through the appropriate CVE Numbering Authority (CNA), subject to the CVE assignment rules.
  中文：如果已分配，则包含一个通用漏洞和暴露（CVE）ID。通过 适当的 CVE 编号授权机构（CNA） 请求 ID，需遵守 CVE 分配规则。

Where possible it is also good to include:

尽可能包括以下内容：

• The timeline of the vulnerability disclosure process.
  中文：漏洞披露过程的时序。
• Credit for the researcher who identified the vulnerability.
  中文：识别漏洞的研究者的认可。
• Technical details of the vulnerability.
  中文：漏洞的技术细节。
• IDS/IPS signatures or other indicators of compromise.
  中文：入侵检测系统/入侵防御系统签名或其他入侵指标。

Security advisories should be easy for developers and system administrators to find. Common ways to publish them include:

安全通告应便于开发人员和系统管理员查找。发布它们的一些常见方式包括：

• A dedicated "security" or "security advisories" page on the website.
  中文：网站上的专用“安全”或“安全通告”页面。
• A security mailing list or forum.
  中文：安全邮件列表或论坛。
• Linked from the main changelogs and release notes.
  中文：从主要变更日志和发布说明中链接。

Some researchers may publish their own technical write ups of the vulnerability, which will usually include the full details required to exploit it (and sometimes even working exploit code). For more serious vulnerabilities, it may be sensible to ask the researcher to delay publishing the full details for a period of time (such as a week), in order to give system administrators more time to install the patches before exploit code is available. However, once the patch has been releases, attackers will be able to reverse engineer the vulnerability and develop their own exploit code, so there is limited value to delaying the full release.

一些研究人员可能会发布他们自己对漏洞的技术文章，这些文章通常会包括利用漏洞所需的所有详细信息（有时甚至包括可工作的利用代码）。对于更严重的漏洞，要求研究人员延迟发布全部详细信息一段时间（例如一周），以便在利用代码可用之前给系统管理员更多时间安装补丁，可能是明智的。然而，一旦补丁发布，攻击者将能够逆向工程漏洞并开发自己的利用代码，因此延迟全面发布的价值有限。

Private Systems / 私有系统

For vulnerabilities in private systems, a decision needs to be made about whether the details should be published once the vulnerability has been resolved. Most bug bounty programs give organizations the option about whether to disclose the details once the issue has been resolved, although it is not typically required.

对于私有系统中的漏洞，需要在漏洞解决后决定是否应该发布详细信息。大多数赏金猎人计划都给组织提供在问题解决后是否披露详细信息的选项，尽管通常不是强制性的。

Publishing these details helps to demonstrate that the organization is taking proactive and transparent approach to security, but can also result in potentially embarrassing omissions and misconfigurations being made public. In the event of a future compromise or data breach, they could also potentially be used as evidence of a weak security culture within the organization. Additionally, they may expose technical details about internal, and could help attackers identify other similar issues. As such, this decision should be carefully evaluated, and it may be wise to take legal advice.

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

Rewarding Researchers / 奖励研究人员

Where researchers have identified and reported vulnerabilities outside of a bug bounty program (essentially providing free security testing), and have acted professionally and helpfully throughout the vulnerability disclosure process, it is good to offer them some kind of reward to encourage this kind of positive interaction in future. If monetary rewards are not possible then a number of other options should be considered, such as:

当研究人员在漏洞赏金计划之外（本质上提供免费的安全测试）识别并报告漏洞，并在整个漏洞披露过程中表现出专业和乐于助人的态度时，提供某种形式的奖励以鼓励未来这种积极的互动是很好的。如果无法提供金钱奖励，则应考虑其他多种选择，例如：

• Discounts or credit for services or products offered by the organization.
  中文：组织提供的服务或产品的折扣或信用额度。
• Virtual rewards (such as special in-game items, custom avatars, etc).
  中文：虚拟奖励（如特殊游戏物品、定制头像等）。
• T-shirts, stickers and other branded items (swag).
  中文：T恤、贴纸和其他品牌商品（周边产品）。
• Credit in a "hall of fame", or other similar acknowledgement.
  中文：在“名人堂”或其他类似认可中给予信用。

References / 参考

• CERT: Guide to Coordinated Vulnerability Disclosure) （CERT：协调漏洞披露指南）
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure) （RFC 9116：一种帮助安全漏洞披露的文件格式）