正文
摘要：根据Forrester的 The State Of Application Security, 2022一文的预测，应用安全性的缺失将仍然是最常见的外部攻击方式，因此SAST将会在可预见的未来一直被重视。
本文分享自华为云社区《SAST-静态应用安全测试》，作者： gentle_zhou 。
SAST，Static Application Security Testing，即静态应用安全测试，也叫静态分析，是一种测试方法，一直是应用程序安全性工作的核心部分。根据Forrester的 The State Of Application Security, 2022一文的预测，应用安全性的缺失将仍然是最常见的外部攻击方式，因此SAST将会在可预见的未来一直被重视。
什么是SAST
Static Application Security Testing，静态应用安全测试，是一种白盒测试，也是当前正在使用中的最成熟的应用程序安全测试方法之一。不用运行组件，在编译代码阶段之前，SAST可以通过分析源代码来发现一些容易让应用受到攻击的安全漏洞。
而Gartner对SAST的定义则是：“一组用来指示安全漏洞情况，设计用来分析应用程序在编码和设计阶段下源代码，字节码，二进制的技术”。
“a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities.”
为什么需要SAST
根据Forrester一项针对安全专业人士的调查报告显示，在2022年，近三分之二的外部攻击是通过web应用程序(32%)或利用软件漏洞(35%)进行的。
而SAST可以让开发人员检测到源代码中的安全漏洞或弱点，帮助研发团队遵守某要求或规定（比如PCI/DSS），更好地理解软件里存在的风险；可以说，SAST成为了降低软件风险第一步的工具，已经成为应用程序安全测试工具的代名词。也因为如此，如果我们真的想确保软件的安全，了解SAST是如何运作的就至关重要。
需要注意的是，为了更好的达到上述的效果，定期在应用上（比如每月/每天）、每次有新增代码或合入代码的时候运行我们的SAST工具就非常有必要。
SAST如何运作？
正如SAST 静态应用安全测试这名字明面上代表的意思一样，它可以在不运行代码（静止状态）的情况下，在软件开发生命周期 (SDLC) 的早期阶段进行静态代码的扫描；通常SAST是在开发的编码和测试阶段被使用，会被集成在CI阶段甚至IDE编辑器中。
SAST的扫描是基于一组预先确定的规则（这些规则定义了源码中需要评估和处理的编码错误）的，SAST扫描可以被设计用来识别一些常见的安全漏洞，比如SQL注入，输入验证，堆栈缓冲区溢出等。
SAST的优势与不足
SAST作为一种优秀的应用程序安全工具，如果操作得当，它对组织的应用安全策略就会至关重要。将SAST集成到SDLC中提供了以下好处:
优势
- 做到安全左移。将安全测试集成到软件开发的早期阶段是一项重要的实践，SAST可以帮助安全性测试提前进行，在设计阶段发现代码中的漏洞，修复相关安全问题；这么做的好处的是，为企业组织大大减少在临近发布日期阶段或则更迟的阶段才去解决安全问题的代价。
- 确保编码安全。SAST可以轻松检测出一些简单的编码错误而导致的缺陷，从而帮助开发团队可以遵守安全编码标准和最佳实践。
- 检测常见漏洞。自动化的SAST工具可以轻松并高效地检测出常见的安全漏洞比如换粗去溢出，SQL注入，跨站点脚本编写等问题。
- 更加易于使用。现代应用程序开发环境下，SAST与DevOps环境和CI/CD管道集成在了一起，更加高效、方便、易于使用；这样开发团队不需要再单独配置或额外进行触发扫描，也就是说团队不用离开开发环境就可以扫描、查看、修复安全问题。
- CWE全面覆盖。业界SAST工具提供的检测覆盖了多种CWE缺陷，包括各种平台和框架上开发的桌面、web和移动应用程序，并支持多种不同的编程语言和编程框架。
- 扫描高效。研发团队在实际研发过程中，会更注重效率，一款高效的SAST工具可以让团队更快获得需要的结果。
不足
- 覆盖不了所有的漏洞。因为是在代码未运行的情况下去测试，无法覆盖运行时问题或则配置问题；对于访问控制，身份验证或则加密之类的场景也测不出。
- 误报率高。SAST的扫描结果会包含大量误报，需要研发团队手动去排查和屏蔽，会耗费团队大量时间。更严重的是，有时候团队会要求强制清零漏洞，误报得不到重视，就会一直存在。
- 耗时。对于一些大型的项目，因为代码仓过大一次扫描可能要花费好几个小时；而SAST的扫描结果因为只是指出潜在的漏洞，还需要研发团队验证是否确实是隐患
选取SAST工具的衡量因素
实际研发项目中，不同的项目、大型的项目会或多或少涉及到不同的开发语言，技术框架，承载平台。而市场上又充斥着大量的SAST产品，很多又会与额外的解决方案捆绑在一起，那么如何选取最有效的SAST工具来达到高效执行的目的呢，有如下几个因素可以考虑：
- 支持语言：确保选择的SAST工具覆盖了我们当前项目所使用的编程语言
- 漏洞覆盖：确保选择的SAST工具覆盖了全面的主流的应用程序安全漏洞
- 准确性：确保选择的SAST工具误报率低
- 兼容性：确保选择的SAST工具兼容当前项目所使用的技术框架，也支持集成到SDLC中
- IDE集成：确保选择的SAST工具可以集成到IDE中，支持实时检查
- 扩展性：确保选择的SAST工具易于扩展，支持自定义规则
如何实施、部署SAST到项目中呢
如何将选择的SAST解决方案部署、实施进来呢，需要以下这些步骤：
- 选择部署方式：我们需要根据项目实际性质决定将SAST部署在本地还是云端环境里；这一决定取决于我们希望对SAST工具有多大的控制权，工具运行和扩展的速度、容易程度。
- 配置并集成到SDLC中：我们需要根据项目何时以及如何扫描分析代码来决定；我们可以选择如下4种方式中的一种：编译代码时分析；将新增代码合并到代码库时扫描；在CI/CD管道中添加；在IDE中运行SAST可以实时进行检查。
- 决定扫描分析的范围。我们可以选择如下几种：
完整：对应用程序及其全量代码的扫描是最全面也是最耗时的过程
增量：仅扫描新增或更改的代码
桌面：代码编写阶段进行扫描分析，实时解决问题
不用构建：对于不熟悉构建过程或IDE的人员，在源码中进行分析
- 自定义来满足需求：团队肯定希望可以减少误报，自定义新规则，修改现有规则，以满足可以更全面地识别安全缺陷的需求。也许还希望可以自定义用于分析扫描的仪表盘或则构建自定义的报告。
- 优先应用和结果：根据团队考虑因素的重要级来对应用和结果进行优先级排序，考虑因素包括遵从性问题、威胁严重程度、CWE漏洞、漏洞状态、风险级别和责任。
- 分析结果，跟踪进展，评估紧迫性：评估检查扫描结果以排除误报；建立一个系统，可以自动将问题发送、分配给负责的开发人员，让他们去解决。
- 报告和治理：研发团队要利用好工具内置的报告工具，或则做到可以将数据推送到我们已有的报告工具里，做好数据的分析与治理。
参考链接
- https://www.mend.io/resources/blog/sast-static-application-security-testing/
- https://www.synopsys.com/zh-cn/glossary/what-is-sast.html
点击关注，第一时间了解华为云新鲜技术~
