如何将SAST融入DevSecOps流程中? - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com

如何将SAST融入DevSecOps流程中?

鸿渐科技安全实验室 技术 2021-09-14 13:18:11
收藏

导语:在DevSecOps的建设中,想要大幅度降低安全风险,核心是构建和利用好应用安全工具(AST)进行自动化漏洞发掘。

Part1 背景

随着软件产业的迅猛发展,业务体系庞大、产品迭代迅速是许多互联网及软件公司的特点。使用传统的瀑布式开发无法满足用户的需求,由此敏捷开发(Agile Development)走进人们的视野。

敏捷开发大幅提高了开发团队的工作效率和版本更新的速度,但却不利于运维工作的进行。为了让开发人员与运维人员更好地沟通合作,缩短系统开发生命周期,实现高质量的持续交付,开发团队逐步转向DevOps模式[1]。DevOps与敏捷软件开发相辅相成,使得团队减少时间损耗,更加高效地协同工作。

DevOps可以有效推进快速频繁的开发周期,但是过时的安全措施则可能会拖累整个流程[2],因此催生出了DevSecOps概念。DevSecOps强调在软件开发生命周期(SDLC)的早期引入安全防护,在软件研发开始阶段就要考虑应用和基础架构的安全性,为DevOps打下扎实的安全基础。

在DevSecOps的建设中,想要大幅度降低安全风险,核心是构建和利用好应用安全工具(AST)进行自动化漏洞发掘,确保执行缺陷检测的时机准确、及时,并且不会影响研发效率[3]。

全球最具权威的IT研究与顾问咨询公司Gartner发布的应用安全检测魔力象限报告显示,目前市场上的应用安全工具主要分为4类,分别是Static AST (SAST)、Dynamic AST (DAST)、Interactive AST (IAST)以及Mobile AST [4]。

四种应用安全工具中,静态代码分析工具SAST采用白盒测试的方式,真正从代码的“基因”上解决问题,是目前最广泛使用的工具。

因此,在这里我们将介绍SAST在DevSecOps中常见的使用场景,期待能解答开发人员对于SAST使用的部分问题。

Part2 SAST融入Devsecops的不同场景

场景1. IDE研发阶段检测

使用场景:将SAST集成到开发人员的IDE中,在开发人员键入代码时保存时,进行检测

目的:在代码被提交到代码仓库之前发现修补并最常见的的安全问题,帮助代码研发人员在研发阶段发现缺陷

检测耗时:秒级

规则集:低误报的检测项,偏规则类,主要采用函数内分析技术

典型应用企业:阿里巴巴、华为研发部门

在前期阶段的检测中,为了最大程度降低安全工作对生产效率的影响,开发人员对于检测工具的要求是响应速度快,并且尽可能的低误报。故在此阶段,检测引擎在研发者本地,检测器通常只检测编码风格、API使用错误等低级错误。对于部分检测器无法确定的问题,SAST工具在预提交检测时会选择暂时不报出漏洞,避免给开发人员增加额外的负担。

场景2. 提交时检测

使用场景:代码提交至代码仓库后自动触发

目的:每次提交的结果快速返回给提交代码的开发人员

检测耗时:分钟级

规则集:可选有限检测项

典型应用企业:用友软件

此阶段检测由开发人员向版本管理工具提交代码时自动触发,每次提交都会触发一次。开发人员提交代码后,检测器对于单次提交的代码以及其影响的数个文件进行检测,收集本次提交中需要关注的重要缺陷和漏洞。与IDE检测不同的是,在该阶段会关注跨函数,跨文件的缺陷类型。对代码质量要求比较高,或接近发版的团队,往往选择该方式进行代码检测。

场景3. 构建时检测

使用场景:代码提交成功并编译后,定时进行检测

目的:每天定时反馈问题

检测耗时:小时级

规则集:允许配置更全面的检测项,例如OWASP Top 10

典型应用企业:金融企业的研发部门、中电科某软件研发大所

在使用编译器整体构建工程时,SAST工具对构建过程中涉及的文件进行检测,收集工程中所有可能影响版本发布的重要缺陷或漏洞。在此阶段,SAST工具对代码进行全量分析,开发人员也可以创建自定义规则进行检测。该模式往往通过持续集成工具,在晚上定时拉取代码进行检测,对于代码量庞大的工程,往往要求增加检测。同时,本阶段往往使用软件成分分析工具(SCA)识别依赖关系,检测第三方组件中是否含有已知漏洞。

场景4. 测试时检测

使用场景:成功构建后在环境中进行全量检测

目的:将构建好的软件部署到模拟环境中,进行全量测试

检测耗时:数小时级

规则集:全部检测项

典型应用企业:电科院、军工软件测评中心

SAST检测结果将由QA进行分析和评估。QA期望发现尽可能多软件可能存在的问题,因此,与前三个场景要求低误报有所不同,此阶段需要SAST工具报告所有可能的漏洞或缺陷,保证低漏报,达到较高覆盖率。在这一阶段,使用工具的往往是测试部门,利用SAST工具对所有文件进行全量检测。

Part3 现状及未来

实际使用中,由于部分技术尚未成熟,代码分析工具出现的一些问题让开发人员抱怨频频,这使得在DevOps中融入SAST工具,阻力依然较大[5]。

国内某大厂使用某一代码分析工具时,测试人员花费大量时间去除了误报,但在第二次检测后仍然报出类似问题,饱受开发团队诟病。

此外,漏报率高也不容忽视。研究人员曾使用三种国际高水平的代码分析工具对CVE中100个缓冲区溢出错误进行检测,其中表现最好的工具也只检测出了其中的32个,漏报率接近70%[6]。

但了解以上SAST工具的使用场景后,我们看到SAST工具已经在尽力适应开发人员的工作习惯。

为满足各阶段开发人员对于代码分析工具的要求,SAST工具的规则集、检测时长在不同时期做出调整。例如,开发人员认为在编写代码时进行安全检测影响其生产效率[7],故SAST在初期只允许配置有限规则集,就是为了能够进行快速扫描、及时反馈,尽力降低开发与安全检测脱节的影响。

即使对于同一检测项,SAST工具在不同阶段的检测范围也有所不同。拿SQL注入举例,SAST工具在预提交时可能只检测单函数内部的问题,提交时检测单文件内的问题,最后阶段再进行跨文件检测。通过这种方式进行误报、漏报、检测时间的调节,最大程度提高开发人员对SAST工具的接受度。

我们期待未来有更加优质的SAST工具出现,同时开发团队也应根据自身需要,在工作流程中选择适当的节点使用合适的SAST工具进行代码安全审查,向实现真正安全防护一体化的DevSecOps更进一步。

参考

[1] https://en.wikipedia.org/wiki/DevOps#DevSecOps,_Shifting_Security_Left

[2] https://www.redhat.com/zh/topics/devops/what-is-devsecops

[3] https://www.freebuf.com/articles/es/243902.html

[4] https://www.gartner.com/reviews/market/application-security-testing

[5] Christakis M, Bird C. What developers want and need from program analysis: an empirical study[C]//Proceedings of the 31st IEEE/ACM international conference on automated software engineering. 2016: 332-343.

[6] Tao Y , Zhang L , Wang L , et al. An Empirical Study on Detecting and Fixing Buffer Overflow Bugs[C]// IEEE International Conference on Software Testing. IEEE, 2016.

[7] Johnson B , Song Y , Murphy-Hill E , et al. Why don't software developers use static analysis tools to find bugs [C]// Software Engineering (ICSE), 2013 35th International Conference on. IEEE Press, 2013.

如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论