让我首先提供我们手动过程的简化视图：
定义攻击面。找到我们要攻击的所有网址
（使用工具的搜寻器，然后添加任何其他孤立的网址）。
修改设置以过滤掉一些常见的安全漏洞
知道我们的产品不是降低噪音的问题。
运行该工具并获取大量警告/错误
在时间允许的情况下仔细阅读警告/错误，以确定是否存在实际的安全错误。
我看到的与安全测试自动化有关的主要问题是：
每组渗透测试都有其执行的多个实际测试
（成千上万个），但未记录作为
单独测试，因此每个
“测试”都获得多次通过/失败/警告。很难将这些结果推送到我们现有的报告基础结构中。
一组测试的结果可能会产生多个信息性的
消息/警告/错误，这些信息会根据严重性和可能性进行加权是一个实际的错误。通过这些结果是一个耗时的手动过程，并且由于结果
一旦我调查了一个故障并确定它不是一个实际的错误，我可以
过滤掉类似的故障以便将来运行，但是以后可能会遇到另一个不同但类似的问题构建实际上是一个
一个安全漏洞，由于我的筛选，我不再遇到错误。
有人成功完成了部分或全部此过程的自动化吗？我相信有些东西可以自动化，也可以更智能地使用我们的工具，但最终，我看不出围绕筛选结果的大量手动过程的方法。如果有人能成功完成此过程的自动化或减少涉及的体力劳动，我将被证明是错误的。
#1 楼
即使我们从未尝试过这样做，我也几乎可以肯定地回答您的问题：否
因为发现安全缺陷不是一个过程，而是一种技能，组。并非每个人都能做到-机器人将是我最后一次报告真正的安全问题。他们有时会很好地发现SQL注入等基本缺陷，但是将它们与基础架构集成在我看来并不可行，因为这样做没有投资回报。
为了支持我所说的，几年前，我的程序员发现了一个很大的安全漏洞，那就是更改Cookie的名称以获取对未授权帐户的访问权限。这是您无法期望机器人完成的。这需要情报。
评论
可以使用该工具运行回归测试（检查）以确保现有安全质量不会降低吗？我同意探索性安全测试是一种认知技能。
– DuncN
2011年10月21日在20:18
不，我认为-因为质量下降可能不是由于一两个原因，而是无限的原因。我想补充一点，尽管琐碎的事情（例如检查SQL注入等）可以自动化，但是由于过去的经验，这种自动化的ROI仍然没有吸引我。
– Abhimanyu
11-10-23在15:19
这个问题已经很老了，但是对于遇到这个问题的其他人来说。我同意，发现新的安全漏洞是人们应该做的事情。但是，如果您需要测试一次，请手动进行。如果需要多次测试，请使其自动化。
– AndrewK
2014年11月11日下午0:30
#2 楼
那么您的代码是否缺乏安全性可测试性？我相信Burpsuite应该允许创建和运行自动化脚本-是否有可能在代码中添加自动化安全测试钩子？如果Burpsuite无法做到，尽管有工具，但是我不知道它们与Burpsuite相比如何。
在短期内，您正在手动检查日志-您可以轻松编写脚本以仅从噪音中解析出实际威胁。这些可以输出到csv / xls文件中，以便于过滤和解释。
#3 楼
一句话，有可能吗？但是，这需要一些投资。我个人使用工具Acunetix。它相当可定制和全面。是的，它发现了更改Cookie的安全漏洞。是的，如果设置为侦听，则可以通过命令行或远程请求运行它。而且，是的，它很昂贵。除了许可外，我很乐意在构建服务器上运行它。我们通常在多个环境（例如Dev，PreProd，有时是Test）中对同一应用程序运行扫描，并且需要扫描几十个应用程序，有时在构建时运行对于我们的发布时间表不起作用。
如果您想检查典型威胁，那么这样的工具非常有用。通常，我本人通常希望对Dev中的OWASP Top 10进行快速扫描，然后在PreProd环境中进行全面扫描（有时需要进行数百万次测试）。如果找到了任何东西，它将为您提供使用的确切信息以及如何在类似Fiddler的界面中重现它。完成后，它为您提供了创建快速报告以供管理人员查看的选项，或者提供了数百页的报告，其中包含测试人员和开发人员的所有详细信息，并提供了纠正步骤和基于此的手动测试思路。
最后，取决于您要从中获得什么。如果您想要类似于典型的测试自动化的东西，它会捕获回归的错误，那就太好了。如果您以前曾经在网站上进行过测试，现在想寻找新事物，那么Abhimanyu是绝对正确的，可以并且应该将自动化工具替换为专门研究安全性的专用测试仪（恕我直言，除了工具）。
评论
山姆，您希望通过自动化这些测试实现的主要目标是什么？是主要是为了节省您需要花在其他测试任务上的时间，还是希望自动化可以使更多的人使用测试结果？主要是为了节省时间并可能增加我们运行测试和处理结果的频率。乌托邦将在整个构建过程中进行100％自动运行，以发现每个构建过程中的特定新安全问题。我不确定将结果开放给更广泛的受众是否会有很多好处，因为发现的任何“实际”安全问题最终都将成为每个人都可以访问的错误。