静态分析安全测试（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 博士将静态分析无法找出的诸多安全问题归为瑕疵，而非程序错误。这些瑕疵的性质与应用相关，静态分析可能无法找出的问题包括：
　　· 机密数据的存储与传输，尤其是当这些数据的程序设定与非机密数据无异时。
　　· 与身份认证相关的问题，比如蛮力攻击敏感系数，密码重置效力等。
　　· 与非标准数据随机选择的熵相关的问题
　　· 与数据保密性相关的问题，比如数据保持以及其它合规性问题（比如：确保信用卡号在显示时是部分掩盖的）。
　　与普遍观点相反，许多静态分析工具的覆盖缺口隐含着巨大的组织风险。而且，多数公司组织都无法接触源代码，导致 SAST 工具可能无法理解某种特定的语言或框架，再加上大规模部署这一技术以及处理错误警报带来的挑战，这一风险变得更为复杂了。
　　尽管静态分析是确保安全开发的重要技术，但显而易见，它比不上从建立应用之初考虑安全问题的策略。公司组织只有将安全理念融入产品需求与设计中去，并以静态分析等技术加以验证，才有可能创造出牢固安全的软件。