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