问owasp 2017年十大自动化

EN

想要用自动化来解决这个问题是个好主意。然而，OWASP列表本身并不是一个漏洞列表，其中一个漏洞是公开发布的软件的已知坏版本，或者已知的错误配置，可以扫描、识别和纠正。

相反，它是OWASP所称的风险列表，这些风险是导致妥协和损失的安全故障类别。换句话说，每个OWASP项都是更高级别的抽象，而不是单个的、可识别的漏洞。

此外，许多可以归类在一个或另一个OWASP风险之下的漏洞本身是抽象的，不一定容易扫描。

例如，建议使用一些代码模式来帮助防止SQL注入(注入风险下的一类漏洞，多年来的第一种风险)--类似于使用准备好的语句。但是，并不是所有不使用准备语句的应用程序代码都容易受到SQL注入的影响。

从自动化的角度来看，被称为“静态分析器”的源代码扫描工具专门用于寻找次优代码模式--从安全角度和从成语/技术债务的角度来看，都不是最优的。根据我的经验，它们需要大量的配置投资，而且仍然常常只产生几乎无法使用的结果。

作为一个整体支持应用程序安全扫描的自动化并不是一个解决的问题，仅仅取决于机器可读的资源的可用性。我们仍然处于应用程序安全性的阶段。

可能最自动的风险是使用具有已知漏洞的组件的风险#9。现在，每个语言平台都有工具，可以根据标记为具有已知漏洞的库列表来检查特定代码库中使用的库的版本。这太棒了。

然而--对那些在这些领域没有报酬或名声的过度劳累的人们的极大尊重--这些清单并不是详尽的、全面的或明确的。特定库不存在与其相关的漏洞并不意味着不存在漏洞。这更多地意味着存在漏洞，但它们只是还没有被发现或( b)报告。

总的来说，这是一个相当糟糕的状态，而且同样，这种特殊的风险可能是目前自动化状态最强的地方。

最后，有一些有希望的项目。我一直关注的是谷歌的Grafeas：

https://grafeas.io

它的目标是支持机器可读的元数据构件的发布，从中可以构建应用程序安全管道。它还没有接近生产准备，但正在取得进展。