编者按: 以下是Adobe赞助的博客文章:
应用程序测试是软件开发生命周期的关键组成部分. 这是已知的. 通常, 任何应用程序的可靠测试不仅包括功能测试和可用性测试, 同时也考虑到了安全性和可靠性测试. 然而, 在我们的行业中，大多数测试方法都有一个致命的缺陷:它们经常不能确定正确的可操作项目——以及正确的优先级——而这正是产品质量和弹性的关键所在.
而“OWASP Top 10”和“CWE/SANS Top 25”也很重要, 它们现在确实只是现代安全测试策略的最低限度. 变得更加“对手意识”，并帮助开发团队在其应用程序中“向左转移”安全控制，应该是当今任何领先的安全组织的目标.
Adobe开始着手解决这些挑战，而不仅仅是通过使我们的测试工作更广泛或更频繁, 而且让他们更聪明. 测试与软件开发生命周期的紧密结合，以及对现实世界对手威胁的更好建模，使Adobe在应用程序安全测试的方法中变得更加注重devsecops.
现行标准
年度外部渗透测试是软件行业中预期的标准实践. 公司给外部渗透测试人员一个账户，他们可以访问内部网络, 这个过程被称为“灰盒测试”.他们进行网络和应用程序测试，并在报告中与公司分享结果. 很简单，对吧??
嗯，不完全是. 公司面临的最大的应用程序安全问题之一是标记的问题的数量和外部渗透测试产生的误报的数量. 在大多数组织中, 这些问题中的每一个都被赋予了从低到严重的严重性等级，并被标记为需要进行补救. 产品团队看到他们的收件箱里塞满了罚单，虽然他们有一个模糊的想法，即关键和高严重性的问题必须在低严重性的问题之前得到解决, 他们不知道哪些对产品质量和弹性真正重要. 他们也不知道对手今天正在积极利用哪些问题——或者将来可能会利用哪些问题.
这说明了前面提到的致命测试缺陷:严重性和临界级别的确定通常与实际情况不一致，而实际情况将在防御对手方面发挥作用. 虽然在目前的行业中是可以接受的, 这种方法通常不能为应用程序开发人员提供足够的信息来确定优先级并采取行动. 产品团队急于解决通过这种不充分的测试发现的问题，以获得报告的签署，而没有任何关于该努力将如何提高产品安全性的清晰视图. +, 这可能导致对客户实际应用程序安全性和风险的评估没有多大帮助.
不仅更频繁的测试……
在2022年初，Adobe从两个方面修改了我们的整个产品安全测试策略. 第一个, 除了每年对我们每个面向客户的产品进行外部渗透测试(通常是两到三周的过程), 我们使用对手驱动的方法对所有系统进行持续测试, 包括面向客户和我们的后端内部系统. 从遵从性的角度来看，渗透测试很重要, 我们还使用更广泛的测试来补充这些测试, 在我们的软件开发生命周期的早期，哪一个可以发现在年度外部测试和这个过程之间出现的问题. 然后, 我们将给定产品或服务的所有测试数据(包括内部和外部)汇总为一个, 高层报告.
所有这些都意味着我们获得了更多的数据来进行分析，这使我们能够更好地预测可能发生的问题. 我们从持续测试中获得的数据量与外部测试相结合，为我们提供了比以往更多的信息, 帮助我们在长期内更好地领先于对手. 但重要的不仅仅是数量.
还有更智能的测试
正如我提到的, 以前，我们从渗透测试供应商那里收到报告，并为每个项目创建票证. 经常, 这产生了对整体软件质量和安全性没有影响的“噪音”, 而且有可能成为转移注意力的话题. 现在, 我们要求我们的渗透测试供应商告诉我们哪些发现是可利用的，哪些是简单的最佳实践或信息，但今天不是真正可利用的. 这种转变与我们测试方法的总体变化相吻合.
通过关注对手的潜在利用，而不是传统的分散方法, Adobe可以更好地将我们的产品团队集中在真正影响产品质量和弹性的问题上. 他们现在知道，我们已经核实了我们的机票是高风险的，他们必须纠正它. 通过只对可利用的发现开票，并在这些票上设置积极的SLA, 我们的产品团队不仅关注对公司来说最重要的事情, 还有我们的客户. 更重要的是, 通过关注最具影响力的问题, 我们的产品团队学习如何创建更好的代码.
的第4名
结合, 这两个战略变化是我们减少产品团队噪音的整体努力的一部分, 使他们能够更成功地采用产品安全的“左移”方法. 此外，我们可以实现一种更注重devsecops的安全方法 测试. 客户受益，因为这些变化使我们能够更加透明地了解我们的测试工作, 哪一个, 反过来, 帮助我们提供用户所需的更安全的数字体验，更好地获得和保持他们的信任.
