在本部分中，我们将详细讨论如何为您的组织做好准备以成功启动和运行漏洞披露计划，包括有关如何弥补所发现的不足之处的实用建议。
查找 bug
通过与外部安全研究人员一起增强您现有的安全计划，可以有效地发现复杂问题并掩盖漏洞。但是，使用 VDP 查找可以在内部发现的基本安全问题是一种资源浪费。
素材资源管理
在查找 bug 时，要想了解从何处入手，唯一的方法就是提前清楚发现 bug。您可以购买一百个安全工具，但如果团队在您不知情的情况下临时创建应用、系统和服务，这不会产生任何影响，尤其是在您无法发现这些资产并执行安全评估的情况下。与负责帮助建立新应用、系统和服务的个人和团队联系，了解他们是否有相应的流程来创建和维护正在增加的资源以及谁拥有这些资源。如果没有当前流程，这是与这些团队协作建立流程的绝佳机会。在确定受攻击面时，最好先了解贵组织的资产。在此过程中，安全团队应参与新基础架构实现的开发，以提供安全审核。最好拥有大量的资产和所有者清单。在应用需要暂时关闭某些系统的新补丁时，此类目录很有用。它提供了一份路线图，说明了需要知情的个人或团队以及受影响的系统。建立健全的资产管理流程可确保在流程的早期阶段确定所有者并定期更新，并确保组织中的所有系统都按预期运行。
除了主动式资产管理之外，还可以考虑可以实施哪些被动措施来找出属于您组织但被标准化资产管理流程缝隙漏掉的资产。这可能包括使用参与 VDP 和 bug 奖励计划的安全研究人员使用的相同“侦察”流程。例如，您可以利用免费的开源工具扫描和枚举可能属于您组织的面向互联网的 IP 范围或网域。在 Google 上搜索 bug 赏金调查会生成各种提示和技巧，以帮助您识别来自贵组织但不知道的资产。
基本漏洞扫描
现在您已经为需要找出安全问题奠定了坚实基础，接下来我们来深入了解一下如何实际执行此操作。根据贵组织的资源，您可以深入到各种程度的深度，但您需要通过漏洞披露计划，在内部安全工作与外部黑客社区之间取得平衡。每个组织的这种平衡情况各不相同，具体取决于可用的资源。
选择工具
许多不同的工具都可以帮助您识别漏洞。其中一些漏洞扫描工具可免费使用，另一些则需要付费。您可以根据自己的个人需求，确定要选择的工具。
- 贵组织的要求
- 每种工具在多大程度上满足这些要求
- 工具的优势大于成本（财务和实现）。
您可以使用此要求模板（OpenDocument .ods、Microsoft Excel .xlsx）来根据您的要求评估各种工具。模板中包含一些示例要求，但您应与安全、IT 和工程团队讨论以就所需功能达成一致。在启动漏洞披露计划之前，您至少要能够对任何面向外部的资产（例如网站、API、移动应用）执行漏洞扫描。这有助于您查找和修复易于发现的漏洞，然后再邀请外部安全研究人员对这些资产和服务进行测试。
扫描设置
自动漏洞扫描可以发现很多问题，但也会导致误报。因此，在与受影响的团队共享结果之前，必须有资源来验证结果。您需要实施相关流程，以确保定期运行扫描，并且能够切实解决这些扫描结果存在的问题。每个组织的运行时间各不相同，但至少，您需要确定：
- 扫描频率
- 连续模式
- 每周
- 每月
- 正在扫描的资产
- 凭据
- 经过身份验证的扫描与未经身份验证的扫描
- （提示：如果您不使用凭据进行扫描，然后在启动 VDP 时安全研究人员使用凭据进行测试，则发现的漏洞可能会激增）
- 角色和责任
- 确定负责运行扫描的团队成员
- 如有必要，设置轮替
- 扫描结果
- 验证扫描结果
- 提交已验证漏洞的错误
- 确定负责修复 bug 的所有者
- 向所有者跟进问题修复
本指南后面的修复 bug 部分将详细介绍如何确保修复发现的安全问题。
安全审核流程
虽然漏洞扫描是被动发现组织中的安全问题的好方法，但实施安全审核流程有助于从一开始就防止引入漏洞。在本指南中，“安全审核”一词是指任何会触发安全团队成员进行人工审核的情况。通常，这包括授权在认为某项更改存在过高风险时将其阻止。如果您的安全团队无法阻止有风险的更改，您仍然需要建立流程来记录风险。这有助于确保推动更改的任何人了解所涉及的风险，并主动接受该风险。
安全审核标准
应在何时进行安全审核？创建一组触发安全审核的标准有助于确保所有人都步调一致。以下是一些可能会触发安全审核的场景示例。
- 提出了与敏感用户数据相关的新功能
- 一项可让用户在地图上分享其位置信息的新功能
- 要求用户提供可能敏感的信息，例如家庭住址、出生日期或电话号码
- 对现有功能进行了重大更新
- 获取现有用户数据并以用户可能意想不到的新方式使用数据，而没有为用户提供选择停用的机会
- 与身份验证、授权和会话管理相关的任何功能的变更
- 公司生产环境的变化
- 网络配置更改，特别是可能导致对外公开服务的更改
- 安装处理敏感用户数据的新软件；如果软件被破解，可能会间接用于访问敏感用户数据
- 建立新的系统或服务
- 与新供应商互动或更改与现有供应商合作的方式
- 引入将处理敏感用户数据的新供应商
- 更改您与现有供应商的合作方式，导致供应商处理敏感用户数据
此列表并不详尽，但您应该考虑以下事项：哪些更改需要接受安全审核。在明确哪些标准需要安全审核以及哪些不需要安全审核时，请与组织内的关键利益相关方进行讨论，以确保：
- 利益相关方有机会审核这些标准并提供反馈
- 利益相关方同意这些条件
- 利益相关方同意主动要求进行安全审核
记录此标准以及如何请求安全审核（例如，向安全团队监控的队列中提交 bug），以便您的组织尽可能轻松地遵循此流程。
安全审核资源
与自动扫描不同，安全审核可能更加耗费资源。每个安全团队一天中只有很长时间的时间来完成无数的任务，因此您需要根据您的标准来估算可能会生成多少次安全审核。如果您发现自己的团队不堪重负且落后，等待其功能发布的团队将对安全团队感到不满。这可能导致组织中的文化转变，使安全团队被视为阻碍者，而不是合作伙伴。如果安全审核流程效率低下，许多个人和团队会尝试完全绕过安全审核流程。如果资源紧张，请考虑放宽要求进行安全审核的标准，并愿意接受更多残留风险。如果由于缺少执行安全审核的资源而造成突发事件，这将有助于证明您需要更多安全资源。
执行安全审核
在决定执行哪些安全审核以及如何执行时，您需要从优先队列中提取数据。为组织中的其他人创建标准化方式来请求安全审核，并提供您需要的所有信息来相应地确定处理优先级。例如，设一个调查问卷，其中包含变更的性质（包括变更的简要说明以及可能影响的用户数据类型）等内容。您可以根据这些问题的回答，自动将潜在的安全审核分类为高风险、中等风险或低风险变更。如果某项更改的风险较高，您可能需要执行更深入的安全审核流程。如果某项变更的风险较低，您或许可以实现更轻量级的安全审核流程，以帮助减少所需的资源并加快流程，更好地推动业务的发展。请考虑在团队中设置轮替以负责管理安全审核队列，确保团队成员选择新的安全审核，以及跟进现有安全审核的进度。安全审核的实际流程因要检查的内容而异。例如，移动应用中的新功能可能需要安全工程师审核代码并查找潜在漏洞。可能需要审核正在安装的新软件，以确保正确设置了访问权限控制。与外部供应商合作可能会带来完全不同的流程。作为参考信息，请仔细阅读 Google 的供应商安全性评估调查问卷。
修复 bug
发现 bug 固然重要，但只有在修复这些 bug 后，安全性才会提高。了解您的组织存在哪些风险固然很好，但能够高效地应对风险会更有利。
漏洞管理
漏洞来自各种资源，包括内部工作（例如漏洞扫描和安全审核）、第三方渗透测试和审核，甚至是在您的 VDP 正式推出之前通过支持渠道通知您的外部安全研究人员。您的组织需要一种方法来对新漏洞和现有漏洞进行分类，以确保将其传达给适当的利益相关方、正确排定这些漏洞的优先级并及时修复这些漏洞。推出 VDP 后，会有一系列新的漏洞进入您的漏洞管理流程。建立可靠的流程来处理这些漏洞，有助于您跟踪修复进度，并响应外部安全研究人员提出的更新请求。快速确定漏洞的优先级并与 VDP 参与者就补救时间表进行沟通能够提高与安全研究人员社区的互动度，并提升组织安全性的声誉。以下各部分概述了您在发布 VDP 之前需要实施的漏洞管理计划的各个方面。
制定严重程度标准和补救时间表
创建关于漏洞严重程度的通用语言以及与每种严重程度关联的理想补救时间表，可让您更轻松地为组织设定标准预期。如果将每个漏洞都当作紧急事件来对待，您的组织将会耗尽资源，并对安全团队产生不满。如果每个漏洞都被视为低优先级，则漏洞永远不会被修复，而且漏洞遭到破坏的风险也会增加。每个组织的资源都有限，因此您需要建立严重级别排名。此排名提供了相关标准，帮助您的组织了解漏洞的严重程度，以及与每种严重程度相关的预期补救时间表。起草一套严重程度准则，并与组织中的主要利益相关方共享以获取反馈。例如，如果工程团队参与制定严重级别标准，他们更有可能认同这些标准，并在指定时间范围内修复漏洞时遵循这些标准。这些严重程度准则可能会因您的业务特有的风险而异。您可能需要考虑进行威胁建模练习，来思考哪些威胁最有可能会对您的组织造成影响，并举例说明每种严重程度类别的问题。以下示例展示了某金融组织的严重程度标准和补救时间表。
| 严重程度 | 说明 | 修复时间表 | 示例 |
|---|---|---|---|
| 严重 | 会给我们的用户或业务带来紧迫威胁的问题。 | 所有者 ：应在 8 小时内确定负责确保漏洞得到修复的主要所有者。根据需要呼叫和寻呼资源，即使在正常工作时间以外。 修复：应尽快或最多三个工作日内修复问题本身，或者至少缓解风险。 |
包含所有用户财务记录的生产数据库遭到入侵。 攻击者窃取商业机密，例如我们的专有投资算法。 活跃突发事件，包括攻击者访问我们的内部网络或敏感生产系统。 |
| 高 | 问题如果被利用可能会造成严重损害。 | 所有者：应在 1 个工作日内确定主要所有者。 修复：10 个工作日内（约 2 周）内。 |
可能会导致敏感用户数据或功能遭到访问的漏洞（例如，任何用户能够窃取其他用户的资金）。 |
| 媒介 | 较难被利用或不会造成直接损害的问题。 | 所有者：应在 5 个工作日内确定主要所有者。 修复：在 20-40 个工作日内（约 1-2 个月）。 |
由自动扫描程序识别的已验证问题，例如不存在已知漏洞的安全更新补丁。 可能有助于进一步攻击的信息披露问题。 可能会被利用的速率限制问题（例如，能够持续猜测用户的密码）。 |
| 低 | 影响最小的问题；主要用于记录已知问题。 | 无需在指定的时间范围内查找所有者或解决问题。 | 不太可能存在风险但无需可从外部访问的信息披露。 |
梳理虫子
这里我们不讨论理发问题，而是说如何确保 bug 的格式正确无误，以便轻松修复。以上表为准则，确定您自己的严重级别定义。这些定义用于将 bug 分类为各种严重程度，并将其传达给所有者。
除了为每个漏洞指定严重级别之外，您还需要确保 bug 采用的是标准格式，以便接收团队更轻松地进行处理。漏洞会以各种形式（例如，自动扫描程序结果或安全审核的手动记录）进入漏洞管理流程。花些时间将每个漏洞转换为标准格式，将有助于接收团队快速理解并解决问题。
根据您的组织以及组织需要提供的信息，此格式或模板可能有所不同，这些信息可以帮助所有者修复分配给他们的错误，但这里有一个示例模板供您参考。稍后，当您创建面向研究人员的漏洞披露计划提交表单时，可以重复使用此模板。
标题：<针对问题的一行说明，通常是指漏洞类型，以及受影响的资产/服务/等；建议： （可选）提供严重程度，或将严重程度映射到问题跟踪器中的相应字段> 摘要：<漏洞描述及其重要性> 重现步骤<：有关如何说明此漏洞的存在或具体影响的分步说明以下是一个可能存在高严重级别的漏洞示例：
标题：[高] 个人资料页面中的不安全直接对象参考 (IDOR) 摘要：我们在应用的个人资料页面功能中发现了一个 IDOR，该 IDOR 可让任何用户未经授权地查看和修改其他用户的个人资料，包括其他用户的全名、住址、电话号码和出生日期。我们查看了相关日志，发现此问题似乎尚未被利用。此问题是在内部发现的。 重现步骤：
- 设置代理（例如 Burp Suite），以拦截安装了该应用的移动设备上的流量。
- 访问您的个人资料页面，并拦截关联的 HTTP 请求。
- 将 profileID=###### 修改为 profileID=000000（这是测试用户）并随 HTTP 请求一起发送。
- 该应用将显示用户 000000 的个人资料，您可以查看和修改其信息。
攻击场景 / 影响：任何用户都可以使用此漏洞查看和修改其他用户的个人资料。在最糟糕的情况下，攻击者可能会在我们的整个系统中自动检索每个用户的个人资料信息。虽然我们认为此问题尚未被利用，但应将其视为标准的“高”严重程度问题。如果我们观察到利用漏洞的证据，可能会上报至“严重”级别。 补救步骤：实施服务器端检查，以确保发出请求的用户应该有权查看/修改通过 profileID 的值请求的配置文件。例如，如果 Alice 已登录并且其 profileID 为 123456，但观察到 Alice 请求了 profileID 333444，那么用户应该会看到错误消息，并且应该记录此次访问其他用户个人资料的尝试。如需详细了解 IDOR 及其解决方法，请参阅 OWASP 上关于此 bug 的资料。
您可以想方设法将各种来源的漏洞自动转换为标准格式，从而节省时间和手动工作。随着创建更多漏洞，您可能会在修复步骤中发现一些共同主题。除了通用的 bug 格式模板之外，您可能还需要为常见漏洞类型创建其他模板。
查找所有者
或许，漏洞管理中最困难的方面之一是确定所有者以帮助修复 bug，以及获得他们的认同将资源投入到按计划实际修复 bug。如果您已设置资产管理流程，则要稍微简单一些。否则，这可能会成为这样做的动力。根据贵组织的规模，寻找所有者可能相当简单，也可能极其复杂。随着组织不断成长，确定谁负责解决新发现的安全问题的工作也在增加。考虑实施值班轮班。值班人员负责审核未分配的漏洞、跟踪所有者并根据严重程度确定优先级。即使您能够确定谁负责修复漏洞并将其分配给错误，也需要说服他们投入时间实际进行修复。此方法可能会因团队或个人以及他们正在处理的其他内容而异。如果您已经获得组织对严重程度标准和修复时间表的认可，则可以参考这些标准，但有时可能需要额外的说服让其他人修复 bug。以下是一些有助于推动漏洞修复的常规提示：
- 说明原因： 如果分配给某个漏洞修复，通常是意料之外的工作。请说明为何有必要及时修复此问题（例如影响 / 攻击场景），并确保负责人了解相关情况。
- 收集背景信息：在某些情况下，只有一个人具备修复 bug 所需的知识，并且他们可能正在处理其他任务。请花点时间了解这些问题是什么 - 这些任务有可能在短期内比修复此漏洞更重要。在修复时间表上表现出同理心和灵活性，将有助于赢得商誉，并加强您与需要修复漏洞的人员的关系。但要注意不要提供太多余地，否则您的组织不会认真对待修复时间表。
- 说明方法：即使您在 bug 中添加了修复建议，修复问题的所有者也可能会感到困惑，或者需要帮助来了解如何修复 bug。如果他们需要帮助来弄清楚如何解决问题，请帮助他们进行教学。 如果只是向所有者抛出 bug，而没有帮助他们，就会破坏组织与安全团队的关系。尽可能为他人提供帮助，就能让他们得以修复当前和未来的漏洞，同时帮助传授他人的经验。
- 调整您的请求： 不同的团队和个人可能已有关于如何接受传入工作请求并确定其优先级的流程。有些团队可能希望所有收到的请求都通过其经理进行。而其他人希望以标准格式提交帮助请求。有些查询仅适用于 Sprint 中预定义的内容。无论情况如何，花一些额外的时间来调整您的请求，以适应团队或个人通常用来接收帮助请求的格式，这将提高我们优先处理您请求并对其进行处理的可能性。
- 作为最后的补救手段进行上报：如果您已尝试了上述所有方法，但负责修复漏洞的个人或团队没有时间解决严重的安全问题，请考虑根据需要升级为领导层。这应该是万不得已的选择，因为这可能会破坏您与相关个人或团队的关系。
根本原因分析
除了查找和修复各个漏洞之外，执行根本原因分析 (RCA) 还可以帮助您识别和解决系统性安全问题。每个人的资源有限，因此很容易会跳过这一步骤。但是，花时间分析漏洞数据趋势，并进一步研究严重和高严重程度的 bug，能够节省时间并降低长期风险。例如，假设您发现同一漏洞类型（例如 intent 重定向）在整个应用中反复出现。您决定与在应用中引入此漏洞的团队沟通，意识到大多数团队并不了解 intent 重定向是什么、它的重要性，或者如何防范它。您整理了演讲和指南，帮助向组织中的开发者介绍此漏洞。此漏洞可能不会完全消失，但出现频率可能会降低。当您推出 VDP 时，第三方报告给您的每个漏洞都是在您现有的内部安全流程中泄露的。通过 VDP 中的 bug 执行 RCA 后，您可以更深入地了解如何系统地改进安全计划。
检测和响应
检测和响应是指您部署的用于检测和响应针对您组织的潜在攻击的任何工具和流程。具体形式可以是购买的解决方案或自行开发的解决方案，用于分析数据以识别可疑行为。例如，在梳理错误部分，我们讨论了每次用户试图未经授权访问其他用户的个人资料时进行日志记录。如果您发现某位用户在短时间内针对其他用户的配置文件生成了大量失败的尝试，系统可能会生成该信号或提醒。您甚至可以自动执行阻止该用户在特定时间段内或无限期访问您的任何服务的过程，直到可以审核并手动恢复访问权限为止。如果您还没有建立检测和响应机制，请考虑与专家顾问合作，让他们指导您为您的组织构建数字取证和事件响应 (DFIR) 计划。如果您确实已经部署了检测和响应机制，那么您将需要考虑对面向互联网的攻击面进行五个、十个甚至一百个安全研究人员进行测试的结果。这可能会对您部署的任何 IDS/IPS（入侵检测和预防系统）产生重大影响。
潜在风险包括：
- 提醒过载：大量提醒或信号看似恶意攻击，但实际上是参与 VDP 的安全研究人员进行的正常且经批准的测试。因为会产生太多噪声，所以很难区分真实攻击和合法安全测试。
- 事件响应虚假警报：如果您在周六凌晨 2:00 部署了该页面，那么他们肯定不会乐于起床来调查潜在漏洞，而实际上只是安全研究人员在执行合法测试。
- 阻止安全研究人员：如果您部署了激进的 IPS（入侵防御系统），最终可能会阻止安全研究人员的 IP 地址运行扫描、手动测试等，以便发现漏洞并向您报告。尤其是在 VDP 中，如果安全研究人员在测试 5 分钟后遭到屏蔽，他们可能会失去兴趣，转而专注于其他组织的计划。这可能会导致安全研究人员完全无法参与您的计划，从而增加漏洞未被发现（因此您的组织不知道）的风险。虽然您可能不想降低 IPS 本身的质量，但您可以采取其他措施来降低研究人员流失的风险。
如何应对这些风险在很大程度上取决于您与外部安全研究人员合作采用的方法。如果您想要一个更黑盒模拟真实攻击的测试方式，那您可能什么都不做。在这种情况下，研究人员的流量将产生提醒，您的团队可能会采取措施进行调查并相应地做出响应。这有助于您的团队练习如何应对看起来像真实攻击的行为，但可能会降低与安全研究人员的互动度，尤其是在他们无法进行测试时。在调查合法测试期间，也可能会导致错失真实攻击。如果您希望更多地使用灰盒方法，可以考虑与安全研究人员合作，以某种方式自行标识其测试流量。这样，您就可以将流量列入白名单或以其他方式滤除其测试和生成的提醒。您的团队将能够更好地区分真实攻击与已获批准的测试，研究人员将能够发现漏洞并向您报告，而不受您的入侵防御系统的阻碍。某些组织会要求安全研究人员提交表单，以申请唯一标识符，该标识符可以附加到研究人员生成的请求中的标头中。这样，组织就可以将研究人员的流量列入白名单，并能够确定研究人员是否开始超出商定的测试范围。如果发生这种情况，您可以联系研究人员，让他们暂缓执行，直到您与他们一起制定测试计划。