彩票走势图

SAST和DAST之间实现真正协同作用的潜力来自您的SAST和DAST工具，这些工具以真正驱动安全设计应用程序安全方法的核心方式相互支持。所以它不是SAST vs DAST，而是DAST-SAST。

那么是如何运作的呢？让我们从基础开始讲。

什么是SAST？

SAST是静态应用程序安全测试，即在不运行应用程序的情况下分析应用程序。从人工审核到指标分析，模式分析再到数据流分析，有多种方法可以做到这一点。这被认为是白盒测试。最常见的是，SAST用户关注数据流分析，因为它使他们能够在应用程序完成之前查找受污染数据等安全问题。

在静态分析的早期阶段，不但强调不仅要发现错误，还要发现可疑或有风险的代码结构以及执行软件工程标准。在安全领域，SAST主要是指流量分析。基本上SAST用于查找漏洞，类似于DAST，但在SDLC（软件生存周期，软件开发生命周期）中较早。

SAST的优点

更早的测试更好，因为它的成本要低得多，所以SAST的主要优点是它可以提前完成——早在整个应用程序或系统准备好之前。通过SAST，您可以深入了解代码，从而准确了解代码涉及的问题。

SAST的缺点

在缺点方面，使用SAST，您的测试不是针对真实系统，并且工具必须合成数据以尝试驱动功能或数据路径的覆盖。因此，SAST工具存在误报问题，这意味着它们可以告诉您一段代码在实际安全时是不安全的。此外，SAST工具通常特定于特定语言。这使得构建和维护成本高昂（主要是工具供应商的问题），并且意味着您需要为应用程序中使用的每种语言提供工具。

什么是DAST？

DAST是动态应用程序安全测试。这意味着通常通过其输入和接口测试工作应用程序（或设备）。通常这是黑盒测试，在某种意义上说，您正在使用该应用程序而不深入了解其内部（源代码）。

DAST的优点

DAST的最大优点是，这些显然是真实的测试，考虑到端到端的完整应用程序和/或系统。其次，DAST测试不依赖于对代码的深入了解，并且工具不需要对每种语言的特定支持。

DAST的缺点

另一方面，DAST的最大缺点是它不包含对代码的深入了解。这意味着当您发现问题时，可能需要一些实时和精力来精确缩小导致问题的底层代码。

此外，DAST是一种“测试”技术，意味着它发生在设计和编码之后。因此，这是验证应用程序是否安全的一种非常好的方法，但如果它是用于保护软件的主要方式，那么您真正尝试在应用程序中测试安全性，这是一项麻烦的任务。您无法在应用程序中测试安全性，也无法在应用程序中测试质量 - 这就是为什么像GDPR这样的新法规和即将出台的FDA指南依赖于安全设计方法。

使用SAST补充DAST

拥有强大的SAST策略，将早期检测检查器与CWE等弱点以及CERT等安全编码标准相结合，是保护应用程序和防止重复出现相同安全问题的最完整方法。但是为了补充DAST，我们可以将SAST与DAST正在做的事情联系起来，通过从DAST获得的信息告知我们的SAST活动。

为了更好地理解它是如何工作的，我喜欢将软件看作装配线，并从生产线的最后开始，使用3步改进过程来确保安全性。第1阶段总比没有好，但它远没有第3阶段那么好。

发布前的安全测试（第1阶段）

应用程序安全性的第一阶段都是DAST。对于应用程序安全性，我们采用最终的应用程序，在发布之前构建，然后对其进行攻击，尝试以任何方式进行攻击 - 这是DAST。如果我们找到了什么，我们会评估它是多么令人讨厌，并在我们可以的时候进行修复，在必要的时候释放。关于这个问题本身就存在一个很大的话题（发布具有已知弱点和漏洞的软件），但我会将其留下后续再说。

因为这个测试结束了，总是有时间压力，以及寻找和修复潜在问题的额外难度，但是做这个测试肯定比完全不做更好，所以这是一个好的开始。

早期检测 - 转移安全性（第2阶段）

应用程序安全性改进之路的第二阶段增加了SAST，以解决周期性问题。如何在应用程序准备好之前启动安全测试？SAST就是我们的答案。SAST检查器可以在我们有代码后立即运行。SAST中的数据流检查器通常可以直接与DAST发现的问题类型相关联，因此很容易知道在SAST发现弱点时要查找什么以及它意味着什么。

这是一个很好的下一步，因为我们不仅有更多的时间来修复，而且测试更靠近源，因此找出出错的时间要短得多。我们的SAST现在正在进行DAST的工作并提前完成。

预防 - 超前（第3阶段）

数据流实际上只是在进行更多的测试安全性，因此我们如何进入下一个级别并将SAST与DAST相结合以相互补充？第三阶段是我们实际意识到将两种工具结合使用的价值。

要将SAST与DAST转移到完全互补的情况，我们可以从DAST获取结果来通知我们的SAST，调整我们的静态分析规则配置并告诉我们需要寻找哪些类型的安全漏洞。通过这种方式使用DAST，它可以使SAST告诉我们我们需要的安全漏洞来源，我们如何缓解它们以及我们如何以不会发生的方式进行编码。

那么这是如何工作的呢？首先，我们需要使用DAST的结果执行根本原因分析。例如，使用SQL注入，我们需要确保数据在进入时进行清理，因此我们不必依赖于通过无数路径追踪数据以查看它是否可以逃避清理。我们还需要查看CERT中的SAST标准，以便我们既可以避免可能有效但又不安全的构造，也可以强制执行可以加强我们应用程序的良好行为，即使它们在正常（不安全）编程中可能不是必需的。适当的SAST规则可以防止DAST出现问题，我们不断向DAST学习如何配置和调整SAST。

从故障安全方法中受益

通过一起使用SAST和DAST，您最终会得到我认为的故障安全心态。因此，例如，在没有安全设计的情况下，在GDPR之前，我们存储了所有用户数据而没有加密，然后讨论了哪些特定数据值得额外保护，如密码或社会安全号码。在安全设计，故障安全的环境中，我们采取相反的方法并加密所有内容，然后讨论不加密的安全措施。这样，默认行为是安全的或“故障安全的”，并且您成功地最大化了SAST和DAST。

所以要小心！进行类似DAST测试的SAST检查器是那些能够吸引用户和分析师兴趣的检测器，但更大的价值来自于执行适当安全行为的无聊的基于标准的检查器。这些检查器将您从后期测试转移到早期检测，并且一直到实际的预防性编码标准，这些标准会强化您的应用程序。SAST可以通过提供早期缓解来补充DAST，并允许DAST主要用于验证应用程序是否安全，而不是试图破坏应用程序。

如果您正在寻找具有所有这些功能的解决方案，请查看Parasoft。免费试用版可供您在您的组织中试用。

想要了解Parasoft、Parasoft SOAtest、Parasoft Virtualize更多信息或资源的朋友，请