Acunetix在SDLC中的安全性测试

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

DevOps只是害怕尝试新事物。它们用于Selenium测试，这些测试占用了管道并提供了难以解释的结果，但是与此同时，它们经常避开了DAST测试，这远没有那么麻烦。

由于他们的应用程序是完全用Java开发的，Acunetix因此他们的质量检查流程涉及三种类型的测试。首先，有一些简单的用Java本身编写的单元测试。基本上，测试访问单个函数，将其提供给示例数据，获取输出值，并将输出值与期望值进行比较。而已。

然后，进行功能和集成的Selenium测试。这些测试遍及所有屏幕，并且基本上试图使Selenium像一个简单的爬网程序那样工作。根据设计，该搜寻器根本不会进入管理，配置或报告屏幕。

将每个Selenium动作产生的DOM结构与预期数据（之前手动记录的）进行比较。Acunetix如果存在差异，Selenium会对应用程序进行“截屏”，并基本上告诉开发人员“此屏幕上的某处存在错误，请查找并修复”。

他们的主要产品的整个质量检查测试过程大约需要4个小时。硒测试消耗了大部分时间。如果他们不减少创建新的Docker容器，则该过程将至少花费两倍的时间。每次测试后，他们只需运行一系列SQL命令并加载默认数据库内容，而不是加载整个环境。

在与Michael交谈之前，我对QA测试的知识还很理论。谈话后，我感到震惊。我从没想到Selenium测试会花费这么长时间，而可怜的开发人员只会有截图作为指导！

然后，我想到了两个想法。

第一个想法实际上是一个问题。为什么DevOps经理对SDLC中的DAST测试保持警惕？为什么他们说硒测试需要更长的时间呢？为什么当他们的Selenium测试只是为开发人员提供应用程序的屏幕快照时，为什么他们抱怨DAST并不指向一行代码？

我只能猜测，Acunetix这仅仅是因为SDLC中的DAST测试对他们来说是新手，或者他们在尝试运行免费的DAST产品方面有一些不好的经验。以我的观点，了解Acunetix的工作原理，SDLC中的DAST测试将花费Selenium消耗的时间的一小部分，并将为开发人员提供有关该错误的更多信息！当然，这不能解决Selenium的问题，但是它不会比已经解决的问题多得多。

我想到的第二个想法与我读过的一些营销技巧有关，这些技巧来自知名的被动式IAST工具制造商。这些营销材料错误地比积极/真实的IAST更全面地宣传其产品。如果Michael的公司的测试完全跳过了所有管理，配置和报告屏幕，那么如果使用被动IAST进行测试，其应用程序的安全性如何？毕竟，安全性测试将完全忽略产品功能的主要部分。

谈话之后，我得出了两个结论。首先，不是DAST产品的功能才是许多企业未能实施早期测试的真正原因。其次，我证实了自己的信念，即被动IAST并不是确保应用程序安全的好方法。