当前位置：如何将SAST融入DevSecOps流程中？
文章来源：本站原创 发布时间：2021-08-26 11:36:50 文章作者：本站编辑
文章来源：本站原创 发布时间：2021-08-26 11:36:50 文章作者：本站编辑
DevOps可以有效推进快速频繁的开发周期，但是过时的安全措施则可能会拖累整个流程，因此催生出了DevSecOps概念。DevSecOps强调在软件开发生命周期（SDLC）的早期引入安全防护，在软件研发开始阶段就要考虑应用和基础架构的安全性，为DevOps打下扎实的安全基础。
在DevSecOps的建设中，想要大幅度降低安全风险，核心是构建和利用好应用安全工具（AST）进行自动化漏洞发掘，确保执行缺陷检测的时机准确、及时，并且不会影响研发效率。
目前市场上的应用安全工具主要有Static AST (SAST)、Dynamic AST (DAST)、Interactive AST (IAST)以及Mobile AST，其中静态代码分析工具SAST采用白盒测试的方式，从直接从代码中发现查找问题，是目前较为广泛使用的工具。本文将介绍SAST在DevSecOps中常见的使用场景。
IDE研发阶段检测
使用场景：将SAST集成到开发人员的IDE中，在开发人员键入代码时保存时，进行检测
目的：在代码被提交到代码仓库之前发现修补并最常见的的安全问题，帮助代码研发人员在研发阶段发现缺陷
检测耗时：秒级
规则集：低误报的检测项，偏规则类，主要采用函数内分析技术
在前期阶段的检测中，为了最大程度降低安全工作对生产效率的影响，开发人员对于检测工具的要求是响应速度快，并且尽可能的低误报。故在此阶段，检测引擎在研发者本地，检测器通常只检测编码风格、API使用错误等低级错误。对于部分检测器无法确定的问题，SAST工具在预提交检测时会选择暂时不报出漏洞，避免给开发人员增加额外的负担。
提交时检测
使用场景：代码提交至代码仓库后自动触发
目的：每次提交的结果快速返回给提交代码的开发人员
检测耗时：分钟级
规则集：可选有限检测项
此阶段检测由开发人员向版本管理工具提交代码时自动触发，每次提交都会触发一次。开发人员提交代码后，检测器对于单次提交的代码以及其影响的数个文件进行检测，收集本次提交中需要关注的重要缺陷和漏洞。与IDE检测不同的是，在该阶段会关注跨函数，跨文件的缺陷类型。对代码质量要求比较高，或接近发版的团队，往往选择该方式进行代码检测。
构建时检测
使用场景：代码提交成功并编译后，定时进行检测
目的：每天定时反馈问题
检测耗时：小时级
规则集：允许配置更全面的检测项
此阶段检测由开发人员向版本管理工具提交代码时自动触发，每次提交都会触发一次。开发人员提交代码后，检测器对于单次提交的代码以及其影响的数个文件进行检测，收集本次提交中需要关注的重要缺陷和漏洞。与IDE检测不同的是，在该阶段会关注跨函数，跨文件的缺陷类型。对代码质量要求比较高，或接近发版的团队，往往选择该方式进行代码检测。
测试时检测
使用场景：成功构建后在环境中进行全量检测
目的：将构建好的软件部署到模拟环境中，进行全量测试
检测耗时：数小时级
规则集：全部检测项
SAST检测结果将由QA进行分析和评估。QA期望发现尽可能多软件可能存在的问题，因此，与前三个场景要求低误报有所不同，此阶段需要SAST工具报告所有可能的漏洞或缺陷，保证低漏报，达到较高覆盖率。在这一阶段，使用工具的往往是测试部门，利用SAST工具对所有文件进行全量检测。
实际使用中，由于部分技术尚未成熟，代码分析工具出现的一些问题让开发人员抱怨频频，这使得在DevOps中融入SAST工具阻力依然较大。一些企业用户的测试人员花费大量时间去除了误报，但在第二次检测后仍然报出类似问题，饱受开发团队诟病。
此外，漏报率高也不容忽视。研究人员曾使用三种国外主流的代码分析工具对CVE中100个缓冲区溢出错误进行检测，其中表现最好的工具也只检测出了其中的32个，漏报率接近70%。
国内自主研发的代码分析工具——WuKong软件代码安全检测修复系统，是在中科院计算技术研究所的大力支持下，由中科院百人计划研究员李炼博士带领团队经过多年技术攻关，最终完成的具有国际领先水平的软件代码安全漏洞检测修复产品。该产品在软件安全漏洞检测产品的各项关键技术指标上，包括测试能力、测试准确性、测试效率等方面，均明显优于国内外已有安全测试产品。
我们认为，SAST工具的能力未来将不断增强，同时开发团队也应根据自身需要，在工作流程中选择适当的节点使用合适的SAST工具进行代码安全审查，向实现真正安全防护一体化的DevSecOps更进一步。