Page 50 - 《软件学报》2021年第10期
P. 50
3022 Journal of Software 软件学报 Vol.32, No.10, October 2021
识别出重要的数据信息、正确描述攻击者可能的攻击行为以及系统所有可能存在的威胁和漏洞 [18] ,并将这些识
别出来的威胁进行加固或重新设计.Microsoft 公司将威胁建模作为保障 DevOps 安全的最佳实践之一,并设计
了威胁建模工具以帮助开发人员分析和识别可能的威胁,使之成为标准开发过程的一部分 [47] .为适应 DevOps
的迭代速度,威胁建模应当也更加高效,更加轻量级,在有限的时间内更准确地去识别出更多的安全威胁.
由于安全实践的引入,组织在整个计划阶段需要经历一个从初步讨论、设计到再讨论再设计的迭代过程.
在迭代过程中,逐步完善系统的安全性需求,处理识别出来的安全威胁,从理论上保证整个系统的安全性.开发
团队在得到需求之后,便开始了相应的编码工作.
3.1.2 编码阶段
编码阶段是开发人员使用编程语言实现需求的过程.在这个过程中,开发人员需要高频率地将自己开发的
代码提交至指定仓库.受需求的难易程度、开发人员的技术水平、组织的实际管理等因素影响,这些提交的代
码质量通常难以得到有效保障.但是这些代码的质量却又直接影响到测试和维护的过程,也对整个软件应用的
安全性有着举足轻重的作用.结构良好、安全性能高的代码能够显著地减少后期的返工问题.为提高编码阶段
产出的代码的质量,并加强整个开发过程中的安全规范,我们总结了以下几种具体实践.
开发环境扫描
在进行具体软件开发工作之前,组织一般需要为开发人员提供开发环境.如果开发环境本身就不够安全,那
么就很难保证在这样的环境中所产出代码的安全性.为了始终保障开发环境的安全可靠,英国国家网络安全中
心指出,需要在整个编码阶段持续地识别并解决开发环境中潜在的安全隐患,保障开发环境和设备的安全性,进
一步提高交付代码的可信度.但持续地对开发环境进行扫描并不意味着阻止开发人员的正常工作,组织可以在
合适的地方应用安全控制技术,如身份验证、敏感点检测等方式,为开发人员提供一个安全、可靠的开发环境.
开源组件安全扫描
开发人员在开发过程中使用开源组件,能够节约大量时间和成本,进而满足愈发快速的产品发布要求.但使
用开源组件进行开发时,PhoenixNAP 公司指出了目前开发者对开源软件中的缺陷在识别意识上存在不足这一
问题 [48] ,并提示我们需要注意其可能带来的安全风险:首先,当开源组件没有得到很好的维护时,通常会存在安
全漏洞,一旦这些漏洞被不法分子发现并加以利用,则会威胁到整个系统的安全状况;其次,组织在使用开源组
件进行开发时,必须满足该组件许可证中规定的行为要求 [49] ,否则,组织则极有可能存在侵权行为,会面临被起
诉甚至进行赔偿的风险.例如,2008 年,在 Jacobsen v. Katzer 案件 [50] 中,Katzer 在一项专利中使用 JMRI(Java
model railroad interface)项目中的文件,却没有遵守 Artistic License 1.0 协议.据判定,Katzer 这一行为属于侵权,
需要赔偿 Jacobsen 十万美元,并永远禁止通过下载或其他方式复制、修改或发行 JMRI 材料 [50] .在实际开发中
使用开源组件时,我们需要选择合适的安全扫描工具对相关的开源组件进行扫描,如 FOSSID、BlackDuck 等,
避免使用含有安全漏洞的开源组件或开源代码片段,使用时也需要符合其规定的行为规范.
集成安全插件
为方便开发人员在编码过程中及时发现代码中存在的安全问题,组织应当在开发人员的开发环境中安装
统一的安全插件 [51] .这些安全插件在开发人员进行编码时开始工作,对开发人员编写的代码进行主动的安全扫
描.倘若在扫描过程中发现安全问题,便会加以提示,开发人员需要及时进行验证和修复工作.通过集成安全插
件,开发人员能够在开发的早期对代码中存在的安全问题进行修复,提高进入到 DevOps 流水线中的代码的安
全性.但需要保证的是,安全插件的扫描过程不会过度影响开发人员的正常开发.因此,为了与 DevOps 的速度相
匹配,集成的安全插件需要由安全团队指定,这些插件需要做到足够的轻量级和较高的准确率.
使用安全框架
安全框架的内容较为宽泛,认证处理、授权管理、会话管理、加密处理、线程安全等都可以交由安全框架
进行统一处理.开发人员只需进行一定的配置,即完成对常见安全问题的管理,可以更加专注于业务代码的开
发.安全框架能够帮助开发人员处理常见的安全问题 [51] ,极大地提高开发效率和编码质量,是 DevSecOps 实践中
不可多得的一项实践.但安全框架的选用仍需综合考虑诸如具体的业务场景、框架实际性能等多方面的因素.