Page 51 - 《软件学报》2021年第10期

戴启铭 等:DevSecOps:DevOps 下实现持续安全的实践探索 3023

 编码规范
编码规范涉及文件组织、编码风格、注释写法、命名规则等内容,良好的编码规范不会增加过多的工作负
担,也不会降低开发人员的开发效率 [47] .趋于一致的代码风格反而有助于组织进行代码审查,更易于发现隐藏在
高复杂度代码背后的安全漏洞,还能够提高代码的可读性和健壮性 [52] ,进而降低二次开发和维护的成本.但适合
公司的编码规范需要在实践中不断总结,仔细权衡编码效率和实际收益的关系,进而打造适应公司的编码规范.
 代码审查
代码审查一般是通过人工审阅的方式来查看提交的代码是否合乎公司的编码规范、是否功能齐全、是否
使用了危险函数、是否考虑到安全编码等 [53] ,它是一项提高开发人员的规范意识、促进开发人员之间技术交流
的重要举措.Dynatrac 公司的开发人员 Plank 指出:代码审查已成为公司安全开发的基本实践 [54] ,以确保每一段
代码在提交之后都能够得到别人的审查.它能够充分规避个人在编写过程中出现的疏漏,还能够使得整个团队
的代码风格趋于一致并符合安全规范要求 [47] ,进一步降低可能的安全风险.
编码阶段产出的代码是最终交付的产品或服务的核心部分,其重要程度不言而喻.如何保护整个开发过程
的安全、如何提高产出的代码质量,都应该是组织需要考虑的重点问题.为了处理好这些问题,我们介绍了一些
行之有效的安全实践,它们能够在不严重拖慢 DevOps 开发速度的情况下,对产出的代码进行严格的安全控制.
编码阶段是一个持续的过程,并与构建阶段结合紧密.开发人员需要不断地将自己编写的代码提交到指定的代
码仓库中,以便 DevOps 流水线进行持续的集成和构建.
3.1.3 构建阶段
构建阶段的主要内容是对源代码进行集成、编译、单元测试、打包、生成可运行的二进制等自动化操作.
整个构建阶段依赖 DevOps 流水线,是一个持续的过程.当开发人员将自己编写的代码提交到 DevOps 流水线中
时,集成的工具就能够自动化地完成对新代码的集成、测试和打包工作.倘若在这个自动化的过程中出现问题,
DevOps 流水线也会触发相应的保护机制,拒绝本次集成,并将检测到的问题及其原因反馈给开发人员处理,直
至完成本次集成为止.在此基础上,DevSecOps 提倡将安全措施无缝集成到 DevOps 流水线中去.为此,我们总结
了以下几种相关实践.
 静态应用程序安全检测
静态应用程序安全检测(static application security testing,简称 SAST)是提高代码安全的有效手段,也是目
前较为常见的安全实践方式之一.该方法不会实际运行代码,而是通过扫描工具自动化分析源代码的词法、语
法、语义、结构等多个要素,进而判断源代码是否违背既定的安全规则 [55] .SAST 的检测效果依赖于工具本身的
性能,速度过慢、准确率过低的安全扫描工具无疑会拖慢 DevOps 的进程,也会增加开发人员验证告警的工作量.
因此,为保证 DevOps 流水线的集成效率不会受过多影响,安全部门需要仔细甄别集成到 DevOps 流水线中的安
全工具,这些工具应当足够的快速并拥有较高的准确性,以符合组织的期望.
 可重复性构建
可重复性构建是指相同的源代码在经过多次编译后,始终输出比特位相同的二进制文件,这是组织确保源
代码到二进制文件的过程中没有被篡改的重要手段之一 [56] .但在实际操作时,这种二进制文件的一致性却难以
得到保障.例如:开发人员在源代码中添加了诸如获取时间戳、使用随机数等操作时,每次编译后的输出就很难
完全相同.为此,我们更需要在编码和构建这两个持续的过程中对这些可能发生变化的因素进行控制,如配置自
动化流程、避免使用不可控函数等,以实现这种一致性.
构建阶段的操作以自动化的方式运行,它与编码阶段共同形成的持续过程推动着整个项目的进展.在持续
集成的过程中加入自动化的安全实践,DevOps 流水线就能够较好地对进入流水线中的内容进行验证而不浪费
过多的时间,以此保障代码的安全性.完成打包的二进制或软件包会进入到测试阶段进行测试,从而进一步提高
最终交付的产品质量.
3.1.4 测试阶段
尽管 DevSecOps 已将部分测试工作提前,由开发人员负责完成,如单元测试等,但仍有部分测试需要由专业