静态分析安全测试（SAST）优缺点探析（sas平稳性与纯随机性检验）

静态分析安全测试（SAST）优缺点探析（sas平稳性与纯随机性检验）

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

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

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

机密数据的存储与传输，尤其是当这些数据的程序设定与非机密数据无异时。与身份认证相关的问题，比如蛮力攻击敏感系数，密码重置效力等。与非标准数据随机选择的熵相关的问题与数据保密性相关的问题，比如数据保持以及其它合规性问题（比如：确保信用卡号在显示时是部分掩盖的）。

与普遍观点相反，许多静态分析工具的覆盖缺口隐含着巨大的组织风险。而且，多数公司组织都无法接触源代码，导致 SAST 工具可能无法理解某种特定的语言或框架，再加上大规模部署这一技术以及处理错误警报带来的挑战，这一风险变得更为复杂了。

尽管静态分析是确保安全开发的重要技术，但显而易见，它比不上从建立应用之初就考虑安全问题的策略。公司组织只有将安全理念融入产品需求与设计中去，并以静态分析等技术加以验证，才最有可能创造出牢固安全的软件。