静态分析安全测试（SAST）优缺点探析

静态分析安全测试（SAST）是指不运行被测程序本身，仅通过分析或者检查源程序的语法、结构、过程、接口等来检查程序的正确性，那么采用静分析安全测试的方法有什么优缺点呢，且让小编给你说道说道。

许多公司都投资于 HP Fortify、IBM AppScan Source、 Checkmarx 或 Coverity 之类的静态分析安全测试（Static Analysis Security Testing，SAST）解决方案。如果使用得当，SAST 解决方案的确能大放异彩：相比于动态分析或运行时测试方案，它们能在开发阶段，而不是开发完成之后，探测出源码中的安全漏洞，从而大大降低修复安全问题的成本。它们还能找到许多动态分析工具通常无法找到的漏洞。而且，得益于其自动化的特性，SAST 工具能在成百上千款应用间实现伸缩，而这是仅靠人为分析方法无法企及的。

在对 SAST 解决方案投资之后，一些公司便放弃了在应用安全领域的进一步投资。这类公司的股东往往认为：静态分析方法覆盖了绝大多数软件安全漏洞，或是诸如 OWASP 前十的重要高风险漏洞，因此已经足够好了。这些公司往往不会在软件开发初期就考虑安全问题，而是止步于在应用部署到生产环境之前，获得一份来自扫描工具的“无瑕疵报告”。其实，这种心态非常危险，因为它无视了 SAST 技术的基本限制。

《用静态分析方法确保编程安全(Secure Programming with Static Analysis)》一书详细描述了静态分析技术的基本原理。此书的作者 Brian Chess 与 Jacob West 是 Fortify Software 公司背后的技术骨干，此公司后来被惠普收购。在书中，作者谈到：“一半的安全问题都源自软件的设计，而非源码。”之后，他们列举了软件安全问题的类别，比如与上下文特定的缺陷（这类问题往往在代码中可见）等等。他们还指出：“没有人敢断言，源码检查就能找出所有问题。”

静态分析工具相当复杂。为了正常发挥其功能，它们需要从语义上理解程序的代码、依赖关系、配置文件以及可能不是用同一种语言写的组件。与此同时，它们还必须保持一定的速度以及准确性，从而降低误报的数量。此外，JavaScript、Python 之类的动态类型语言，在编译时往往无法决定对象所属的类或类型，因此进一步影响了静态分析工具的效率。因此，找到大多数软件安全漏洞不是不切实际，就是不可能的。

NIST SAMATE 项目力求测量静态分析工具的效率，从而帮助公司改善该技术的使用情况。它们对一些开源软件包分别执行了静态分析以及人工代码检查，并对比两者的结果。分析显示，在所发现的全部漏洞中，1/8 到 1/3 的漏洞属于简单漏洞。进一步的研究发现，这些工具只能发现简单的实现错误，对于需要深入理解代码结构或设计的漏洞往往束手无策。在流行的开源工具 Tomcat 上运行时，面对26个常见漏洞，静态分析工具只对其中4个（15.4%）发出了警告。

这些统计数据与 Gartner 论文《应用安全：大胆想象，从关键入手 ( Application Security: Think Big, Start with What Matters ) 》中的发现相互呼应。在这篇论文中，作者谈到：“有趣的是，通常认为 SAST 只能覆盖10%到20%的代码问题，DAST 覆盖另外的10%到20%。”按照这种观点，如果一个公司自主开发了一个类似 Tomcat 的工具，并以静态分析为主要的应用安全措施，这意味着，会有22个常见的安全漏洞原封不动地遗留在他们部署的应用中。

Gary McGraw 博士将静态分析无法找出的诸多安全问题归为瑕疵，而非程序错误。这些瑕疵的性质与应用相关，静态分析可能无法找出的问题包括：