产品安全审计 vs. 漏洞赏金计划

2024年5月2日 - 作者：Anthony Trummer

我们经常看到人们在讨论：既然已经有了漏洞赏金计划，是否还需要进行产品安全审计（通常称为渗透测试）？虽然答案对我们来说很明确，但这仍然是一个反复出现的话题，尤其是在社交媒体的信息安全角落。我们决定发表对这个话题的看法，为那些可能仍然不确定的人澄清这一点。

定义方法

产品安全审计

我们所说的产品安全审计是一个有时间限制的项目，由一个或多个工程师专门专注于特定应用程序。测试由应用安全公司的员工执行。这项工作通常提前确定范围，并按固定的小时/日费率计费，客户在开始前就知道总成本。

这些测试可以是白盒（即访问源代码和文档）或黑盒（即无源代码访问，有或无文档），或介于两者之间。通常有明确的范围，并经常就比其他点更密切调查的兴趣点进行初步讨论。通常还会有应用程序功能的演练。大多数情况下，测试在预定的日期和时间进行。这通常是客户可以回答问题、在出现潜在问题时（例如，网站宕机）做出反应或可能避免高峰流量时间的时候。

由于客户对专业公司的信任，他们通常会允许直接访问其基础设施和代码——这在漏洞赏金计划中通常永远不会做。这使测试人员能够发现外部可能非常难以发现的错误，以及动态测试可能超出范围的问题，例如拒绝服务漏洞。此外，通过这种方法，通常会发现一个漏洞，然后很快发现它是一个系统性问题，特别是因为可以访问代码。通过这种访问，也更容易识别诸如易受攻击的依赖项之类的东西，这些依赖项通常深埋在应用程序中。

测试完成后，提供商通常会提供书面报告，并可能与客户进行总结通话。可能还会有后续（重新测试）以确保客户的修复尝试成功。

漏洞赏金计划

通常所说的漏洞赏金计划通常是一个开放式的持续努力，测试由公众执行。一些公司可能将参与限制在较小的群体中，允许根据他们希望的任何标准参与，过去在其他计划中的表现是一个常用因素。

大多数计划定义了要测试的内容范围和他们感兴趣接收报告的漏洞类型。客户通常设定他们提供的支付金额，对更有影响力的发现提供递增的奖励。客户还可以通过促销活动激励对某些区域的测试（例如，对他们的新产品提供双倍赏金）。大多数漏洞赏金计划完全是黑盒，不向参与测试人员提供源代码或文档。

在大多数计划中，测试发生的时间没有限制。参与者决定是否以及何时执行测试。因此，由测试引起的任何中断通常被视为正常的工程中断或潜在的安全事件。一些计划确实要求测试人员通过各种方式（例如，传递唯一标头）来识别他们的流量，以便在出现问题时更容易理解他们在日志中看到的内容。

漏洞赏金计划的报告概念通常是个别错误报告，有或没有预格式化的提交表单。计划要求提交报告的人验证修复也很常见。

混合方法

虽然不是本文的重点，但我们觉得有必要承认有可用的混合方法。这些产品结合了漏洞赏金计划和重点产品安全审计的各个方面。我们希望本文能充分告知读者，确保他们选择适合其组织的方法和服务组合，并完全理解每种方法所涉及的内容。

对比方法

从定义来看，这两种方法似乎相当相似，但当我们深入表面时，差异变得更加明显。

人员

用宽泛的笔触描绘任何群体都是不公平的，但通常在产品安全审计和漏洞赏金计划中工作的人之间存在一些明显的差异。两种方法都可以导致优秀的人测试应用程序，但也可能导致参与者缺乏您希望的专业精神和/或技能集。

当公司被保留为客户执行测试时，公司正在以其声誉赌客户的满意度。大多数有声誉的公司会尝试为客户提供他们可用的最佳人员，理想情况下考虑他们在 engagement 中的特定技能。公司承担筛选员工技术能力的责任，通常通过雇佣前的多轮测试和面试，以及持续的监督、培训和指导。客户通常还会获得工程师简历的摘要，并可以选择请求替代测试人员，如果他们觉得他们的背景与项目不匹配。最后，提供商通常还需要对员工进行犯罪背景调查以满足客户要求。

漏洞赏金计划通常有非常低的入门要求。通常这只是意味着参与者不是来自受禁运国家。参与者可能是任何从寻求赚外快的专业人士、安全研究人员、大学生甚至完全的新手 looking to build a resume。虽然理论上客户可能比典型审计吸引更多眼睛到他们的项目，但这并不保证，并且没有对他们资格的保证。漏洞赏金咨询公司的知名CEO Katie Moussouris被引用强调这一点，说“他们最新的报告显示大多数注册用户基本上是假的或没有技能的”。此外，根据他们自己的统计数据，最大的平台之一 stated that only about one percent of their participants “were really doing well”。因此，尽管潜在数字很大，但高效参与者的小百分比将 thinly stretched across thousands of programs, at best。实际上，顶级参与者倾向于聚集在他们认为最有利可图或最有趣的计划周围。

过程

当客户雇佣一家优质公司执行产品安全审计时，他们实际上获得了该公司的集体知识体系。这通常意味着他们的人员在公司内有其他人可以互动，如果他们遇到问题或需要帮助。这也意味着他们可能有一个专有方法他们遵守，所以客户应该期望彻底和一致的结果。内部同行评审和其他质量保证过程通常也到位以确保满意结果。

通常，客户想要或能够外部分享的内容有限制。公司和客户签署相互保密协议很常见，所以双方都不允许披露关于审计的信息。如果公司泄露信息，他们可能承担法律责任。

在漏洞赏金计划中，每个测试人员制定自己的规则。他们可能相互重叠，创建重复的冗余测试，或者他们可能相互补充，给予许多眼睛的假定优势。通常没有办法让客户知道什么已经或尚未被测试。客户还可能发现测试账户和数据 scattered throughout the app（例如，到处弹出警报），而专业测试人员通常更克制，并被要求不留下这样的残留物。

大多数漏洞赏金计划不需要具有约束力的保密协议，即使它们被认为是“私有的”。因此，客户面临决定与计划参与者分享什么和多少。作为实际问题，如果参与者决定与他人分享信息，几乎没有追索权。

结果

当客户雇佣一家公司时，他们应该期望一份写得很好的专业报告。大多数公司有专有报告格式，但通常也会应要求提供机器可读报告。在大多数情况下，客户可以在雇佣公司之前预览样本报告，以便他们可以非常清楚地了解可交付成果。

专业审计的报告通常在交付给客户之前经过几轮质量控制。这通常包括对报告问题的技术审查或验证，以及语言和语法编辑以确保报告可读和专业构建。此外，优质公司也理解结果可能由客户的广泛受众审查。因此，他们会投入时间和精力以这样一种方式构建它们，使得具有广泛技术知识的受众都能理解结果。测试人员通常还需要维护测试日志和所有问题的质量文档（例如，截图 - 包括请求和响应）。这确保了清晰的发现报告和再现步骤以及所有支持材料。

通过与客户的个性化关系以及可能的源代码，公司有机会理解什么对他们重要，什么让他们夜不能寐，以及什么他们不关心。通过启动会议、持续直接沟通和总结会议，公司与客户建立信任和理解。这使他们能够查看所有严重性级别的漏洞并理解客户的上下文。这可能只是节省客户的时间或认识到中等严重性问题实际上是关键问题，对于该客户的组织。

此外，重复测试允许客户切实展示他们对安全的承诺以及他们修复问题的速度。此外，由经验丰富的工程师进行的产品安全审计，特别是那些有源代码访问权限的工程师，可以突出可以采取的长期改进和强化措施，这些通常不是漏洞赏金计划报告的一部分。

在漏洞赏金计划中，结果不可预测，通常似乎主要由参与者对支付的关注驱动。大多数公司最终被 effectively meaningless reports 淹没。无论有效与否，它们通常不现实、过度炒作、已知的CVE或先前已知的错误，或组织实际上不关心的问题。结果完全满足期望是罕见的，但并非不可能。提交往往集中在 things pushing（通常非常有想象力）被认为是关键或高严重性，以获得最大支付或由自动化扫描器检测到的低 hanging fruits，通常由评级较低的参与者报告 looking for any type of payouts, no matter how trivial。现实是客户需要支付溢价以获得“好的研究人员”参与，但在公共计划上，这本身也可能导致“垃圾”报告的显著增加。

漏洞赏金报告通常不以一致的方式格式化，并且不是机器可读的以摄入缺陷跟踪软件。历史上，出现了许多问题，由于语言问题、糟糕的语法或糟糕的概念验证媒体（例如，无用的截图、无日志、漫无目的的视频），报告难以分类。为了解决这个问题，一些平台甚至通过增加支付或影响报告者声誉得分的正面评价来激励参与者提供清晰易读的报告。

价值

专业审计产生一个可交付成果，客户可以在必要时交给第三方。虽然它有固定成本，无论结果如何，但这种 documented testing 通常由合作伙伴公司和合规原因要求。此外，当使用有声誉的公司时，客户可能会发现更容易通过其合作伙伴的安全要求。最后，如果发生事件，客户可以证明他们的尽职调查并可能减轻他们的法律责任。

漏洞赏金不保证测试的应用程序量（即“覆盖范围”）。它既不产生可以提供给第三方的可接受可交付成果，也不证明测试应用程序的人技能的质量。此外，漏洞赏金计划通常不满足任何关于测试要求的合规要求。

总结

在下表中，我们并排比较两种方法以使差异更清晰。

结论

组织决定采取哪种方法将基于许多因素而变化，包括预算、合规要求、合作伙伴要求、时间敏感性和保密要求。对于大多数组织，我们觉得正确的方法是平衡的。

理想情况下，组织应该至少每季度和 after major changes 执行重复产品安全审计。如果预算不允许那种测试频率，典型的折衷是每年，绝对最低。

漏洞赏金计划应用于填补严格安全审计之间的空白，无论这些审计是由内部团队还是外部合作伙伴执行。这可以说是它们设计来填补的需求，而不是取代重复的专业测试。