共计 2878 个字符，预计需要花费 8 分钟才能阅读完成。
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…
https://www.synopsys.com/zh-c…
