摘自：SAST：静态应用程序安全测试

    超过50%的安全漏洞是由错误的编码产生的，开发人员一般安全开发意识和安全开发技能不足，更加关注业务功能的实现。想从源头上治理漏洞就需要制定代码检测机制，SAST是一种在开发阶段对源代码进行安全测试发现安全漏洞的测试方案。

    1.实现原理

    SAST：静态应用程序安全测试 - 图1

    1） 首先通过调用语言的编译器或者解释器把前端的语言代码（如JAVA，C/C++源代码）转换成一种中间代码，将其源代码之间的调用关系、执行环境、上下文等分析清楚。 2）语义分析：分析程序中不安全的函数，方法的使用的安全问题。 3）数据流分析：跟踪，记录并分析程序中的数据传递过程所产生的安全问题。 4）控制流分析：分析程序特定时间，状态下执行操作指令的安全问题。 5）配置分析：分析项目配置文件中的敏感信息和配置缺失的安全问题。 6）结构分析：分析程序上下文环境，结构中的安全问题。 7）结合2）-6）的结果，匹配所有规则库中的漏洞特征，一旦发现漏洞就抓取出来。 8）最后形成包含详细漏洞信息的漏洞检测报告，包括漏洞的具体代码行数以及漏洞修复的建议。

    2.SAST优劣势分析

    SAST需要从语义上理解程序的代码、依赖关系、配置文件。优势是代码具有高度可视性，能够检测更丰富的问题，包括漏洞及代码规范等问题。测试对象比DAST丰富，除Web应用程序之外还能够检测APP的漏洞，不需要用户界面，可通过IDE插件形式与集成开发环境（如Eclipse、IntelliJ IDEA）结合，实时检测代码漏洞问题，漏洞发现更及时，修复成本更低。 另一方面SAST不仅需要区分不同的开发语言（PHP、C＃、ASP、.NET、Java、Python等），还需要支持使用的Web程序框架，如果SAST工具不支持某个应用程序的开发语言和框架，那么测试时就会遇到障碍。DAST支持测试任何语言和框架开发的HTTP/HTTPS应用程序。 传统的SAST扫描时间很慢，如果是用SAST去扫描代码仓库，需要数小时甚至数天才能完成，这在日益自动化的持续集成和持续交付（CI/CD）环境中效果不佳。 还有一点是SAST的误报，业界商业级的SAST工具误报率普遍在30%以上，误报会降低工具的实用性，可能需要花费更多的时间来清除误报而不是修复漏洞。 SAST只对源代码进行检测，而不会分析整个应用程序，这迫使企业需要购买单独的软件组合分析工具（SCA），即使是SCA也只是识别公开的漏洞；开源、第三方API或框架中的未知漏洞超出了SAST和SCA的范围。

    SAST：静态应用程序安全测试 - 图2