评估
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
如何判断您是否已准备好启动漏洞披露计划 (VDP)？在实施 VDP 之前，您需要进行一些重要的评估。这些评估有助于发现基础架构中的不足，让团队为收到的 bug 报告流程做好准备。正确实施的 VDP 可以带来稳定的报告流。如果您的团队尚未准备好应对额外的工作负载，则新计划可能会产生负面影响，而不是提高安全性。评估您的安全计划以发现并弥补不足，这对提高您处理 VDP 吞吐量的能力大有帮助。及时响应报告的漏洞可以改善您与黑客社区的关系，从而实现更健康的计划。
基本的安全措施
无论组织的安全成熟度或可用资源如何，评估当前的安全状况都是发现问题的最佳方式。下面我们将讨论识别容易被忽视的关键领域中的潜在漏洞，包括发现 bug、修复 bug、分析根本原因、检测和响应以及安全文化。
查找 bug
在准备发布 VDP 时，请务必评估您的团队用于识别环境中的漏洞的方法。作为启动 VDP 的评估和准备的一部分，应首先着手查找并修复漏洞。
否则，可能会导致在 VDP 发布时大量漏洞报告激增，进而导致您的团队不堪重负。通过设置基本的漏洞扫描和安全审核流程，您的组织可以建立可靠的安全问题处理流程。启动 VDP 后，您就能为处理收到的漏洞报告做好更充分的准备。
修复 bug
除了发现漏洞之外，您还需要明确定义的流程和资源，以确保及时修复漏洞。仅仅找出 bug 还不够，只有在 bug 得到修复后，安全性才会提高。您是否有用于漏洞管理的流程和资源？您的组织内的安全文化是什么样的？安全团队是否被视为工程师的反对者、阻碍者或障碍？还是认为您是我们的合作伙伴？你们如何确定漏洞修复的优先级？您是否对严重程度和修复时间表有通用的命名法和了解？找到所有者修复已确定的漏洞的难易程度如何？您是否跟踪与发现的漏洞相关的指标（包括修复时间）？您的组织是否有资产清单，还是遥远的未来梦想？同样，如果您觉得这方面还不错，并且能够很好地确保严重的 bug 得到及时修复，与负责修复漏洞的团队和个人保持牢固的关系，并且拥有适当的资源来顺畅处理传入的安全 bug，那么您就很有方向性了。如果没有，我们将在下一章中提供有关如何成功实施漏洞管理计划的指导。无论是哪种情况，您都需要实施可靠的漏洞管理做法，以便处理 VDP 提供的新 bug，确保能够及时响应和解决发现的漏洞。
根本原因分析
除了发现并修复一次性 bug 的运营工作之外，您是否还对问题进行根本原因分析 (RCA)，并找出导致漏洞引入您环境中的系统性原因？能够快速查找和修复 bug 真是太棒了。不过，若要顺利开展 VDP，您需要能够从一开始就确定这些 bug 是如何出现的。这些类型可以有多种形式，例如：
- 确定应用安全漏洞是如何引入的。
- 分析数据并确定趋势。
- 您是否注意到，由特定团队管理的基础架构从未进行安全更新修补？
- 安全事件或数据泄露。
- 与所有相关方一起进行事后分析，分析发生的情况和原因，并从中学习，以免将来犯同样的错误。
如果不执行 RCA，在处理 VDP 提供的大量类似 bug 报告时可能就会白白浪费大量精力。如果您日后启动漏洞奖励计划，缺少 RCA 也会对您的组织造成财务影响。我们将在下一章中深入介绍如何实现 RCA 流程和事后分析文化。
检测和响应
邀请外部研究人员入侵您的资产会影响您的检测和响应机制。如果您部署了入侵检测/防御系统，则需要考虑您希望安全研究人员进行哪些类型的测试。你们是否会创建例外情况，让他们在这些自动化防御系统“背后”发现漏洞？如果 10 名研究人员都于周六凌晨 2:00 开始对您面向外部的资产运行漏洞扫描，警报会唤醒您的安全团队吗？如何识别来自安全研究人员的合法测试流量与针对您系统的潜在真实攻击？您是否知道如何利用安全研究人员针对您的系统进行测试而生成的数据？如果安全研究人员试图暴力猜测用户名和密码，他们能否锁定真实用户？在启动 VDP 之前，您需要考虑以下所有方面。您需要确保就哪些类型的测试可以和不可以向安全研究人员提出明确的预期，并确定如何配置您的现有检测和响应机制。下一章将更详细地介绍如何实现这一目的。
安全文化
您组织内的文化对您启动和维护成功的 VDP 的能力有着巨大的影响。不妨退一步，了解需要接受该计划的主要利益相关方是谁，以及他们与信息安全团队的现有关系是什么。根据各个利益相关方以及您预计他们会如何处理启动漏洞披露计划的方案，您需要找到方法来说服他们认同这一概念。一个不参与的关键利益相关方可能会阻碍 VDP 启动。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-26。
[null,null,["最后更新时间 (UTC)：2025-07-26。"],[[["\u003cp\u003eBefore starting a Vulnerability Disclosure Program (VDP), assess your organization's security posture, including processes for finding and fixing bugs, root cause analysis, and incident response, to ensure you can handle the influx of vulnerability reports.\u003c/p\u003e\n"],["\u003cp\u003eEstablishing clear vulnerability management processes, fostering a collaborative security culture, and understanding the potential impact on your detection and response systems are crucial for VDP success.\u003c/p\u003e\n"],["\u003cp\u003eRoot cause analysis helps identify systemic security issues, preventing recurring vulnerabilities and optimizing VDP efforts by addressing underlying problems.\u003c/p\u003e\n"],["\u003cp\u003eEngaging key stakeholders and obtaining their buy-in is essential for implementing and maintaining a successful VDP, as their support is crucial for program adoption.\u003c/p\u003e\n"],["\u003cp\u003eEvaluating your security hygiene, including bug finding and fixing processes, root cause analysis, detection and response mechanisms, and security culture, is fundamental for VDP readiness.\u003c/p\u003e\n"]]],["Before launching a VDP, assess your security program's ability to handle a surge in vulnerability reports. Key actions include evaluating current methods for finding and fixing bugs, establishing vulnerability management processes, and determining root causes of vulnerabilities. Organizations need to analyze trends, and perform post-mortems on incidents. Evaluate detection and response mechanisms, setting researcher expectations and system configurations. Lastly, assess the organizational security culture to gain stakeholder buy-in for the VDP initiative.\n"],null,["# Assessment\n\nHow do you know if you're ready to start a (VDP)? There are important assessments you should make\nbefore implementing a VDP. These assessments help identify gaps in your\ninfrastructure and prepare the team for the stream of incoming bug reports.\nA properly implemented VDP brings in a steady flow of reports. If your team isn't\nready for the additional workload, the new program could have a negative impact\ninstead of improving security. Assessing your security program to identify and\naddress gaps can go a long way towards increasing your ability to handle the\nthroughput of a VDP. Promptly responding to reported vulnerabilities can improve\nyour relationship with the hacking community, resulting in a healthier program.\n\nBasic security hygiene\n----------------------\n\nRegardless of the security maturity of your organization or the resources\navailable, evaluating your current security hygiene is the best way to identify\ngaps. Below we discuss identifying potential gaps in key areas that are commonly\noverlooked including, finding bugs, fixing bugs, root cause analysis, detection\nand response, and security culture.\n\n### Finding bugs\n\nWhen preparing to launch a VDP, it is important to assess the methods that\nyour team uses to identify vulnerabilities in your environment. As part of your\nassessment and preparation for starting a VDP, an initial effort should be made\nto find and fix vulnerabilities.\n\nNot doing so could result in a huge spike of reports when your\nVDP launches, potentially overwhelming your team. Setting up a basic\nvulnerability scanning and security review process will enable your organization\nto establish solid processes for handling security issues. When you start your\nVDP, you'll be better prepared to handle incoming vulnerability reports.\n\n### Fixing bugs\n\nIn addition to finding vulnerabilities, you'll need well-defined processes\nand resources for ensuring vulnerabilities get fixed in a timely manner . Simply\nfinding bugs is not enough, security only improves when bugs are fixed. Do you\nhave processes and resources in place for vulnerability management? What's the\nculture like within your organization when it comes to security? Is the security\nteam viewed as the naysayers, the blockers, the thorn in the side of\nengineering? Or are you viewed as a collaborative partner? How do you prioritize\nvulnerability remediation? Do you have common nomenclature and understanding\naround severity and remediation timelines? How easy or difficult is it to find\nan owner to fix an identified vulnerability? Do you track metrics around\nvulnerabilities identified, including time to fix? Does your organization have\nan asset inventory, or is it a distant dream of the future? Again, if you're\nfeeling pretty good about this and have a good grasp of ensuring severe bugs get\nfixed promptly, have a solid relationship with the teams and individuals\nresponsible for fixing vulnerabilities, and have resources in place to process\nincoming streams of security bugs smoothly, you're well on your way. If not,\nwe'll provide guidance on how to implement a successful vulnerability management\nprogram in the next chapter. In either case, you'll want to have solid\nvulnerability management practices in place to be able to handle the new stream\nof bugs you'll receive from your VDP, ensuring you can respond to and address\nidentified vulnerabilities in a timely manner.\n\n### Root cause analysis\n\nBeyond the operational work of finding and fixing bugs as one-offs, are you\nperforming root cause analysis (RCA) of issues and identifying systemic causes\nof the introduction of vulnerabilities into your environment? It's great to be\nable to find and fix bugs quickly. However, when it comes to running a\nsuccessful VDP, you'll want to be able to determine how these bugs are appearing\nin the first place. This can come in different forms, such as:\n\n- Identifying how an application security vulnerability was introduced.\n - Are developers using common libraries and frameworks that reduce the risk of vulnerabilities being introduced?\n- Analyzing data and identifying trends.\n - Are you noticing infrastructure managed by a particular team is never patched with security updates?\n- Security incidents or breaches.\n - Perform a [post-mortem](https://landing.google.com/sre/sre-book/chapters/postmortem-culture/) with all related parties to dissect what happened, why, and learn from it so as not to make the same mistakes in the future.\n\nWithout performing RCA, a lot of effort can be wasted processing numerous\nsimilar bug reports from your VDP. If you start a vulnerability reward program\nin the future, lack of RCA also has a financial impact to your organization.\nWe'll go into more specific advice on how to implement RCA processes and a\npost-mortem culture in the next chapter.\n\n### Detection and response\n\nInviting external researchers to hack on your assets will impact your\ndetection and response mechanisms. If you have intrusion detection/prevention\nsystems in place, you'll want to consider what types of testing you'd like\nsecurity researchers to perform. Will you create exceptions for them to find\nvulnerabilities \"behind\" these automated defense systems? If ten researchers all\nstart running vulnerability scans on your externally facing assets at 2:00AM on\nSaturday, will alarms go off waking up your security team? How do you identify\nlegitimate testing traffic from security researchers versus a potential real\nattack against your systems? Do you know how to leverage data generated by\nsecurity researchers testing against your systems? If a security researcher\ntries to brute force guessing usernames and passwords, could they lock out real\nusers? Before you start a VDP, you'll want to consider all of these aspects. You\nneed to ensure you've set clear expectations with security researchers in terms\nof what types of testing is and isn't okay, and determine how to configure your\nexisting detection and response mechanisms. The next chapter will go into more\ndetail on how to approach this.\n\n### Security culture\n\nThe culture within your organization has a huge impact on your ability to\nstart and maintain a successful VDP. It's good to take a step back and\nunderstand who the key stakeholders are that will need to buy into this\ninitiative, and what their existing relationship is with the information\nsecurity team. Based on the various relevant stakeholders and how you anticipate\nthem handling a proposal of starting up a vulnerability disclosure program,\nyou'll need to identify methods and materials to persuade them to buy-in to this\nconcept. One key stakeholder that isn't on board could potentially block a VDP\nfrom ever getting started."]]
