作者：李祥敬   【原创】   2021-05-25 10:56:33

关键字： DevSecOps ThoughtWorks

在近日举行的2021年“ThoughtWorks技术雷达峰会”上，ThoughtWorks技术专家分享DevSecOps的发展现状、挑战以及未来趋势。

当前，我们看到数字经济的发展，各种各样的智能化应用，这虽然便利了生活和工作，但是数字化应用安全问题对于现实生活的影响将更加明显。这不仅对于数字资产造成影响，更能对人的人身安全、社会关系，甚至组织安全乃至国家安全都造成实际的影响。

所以，应用的全方位安全能力内建变得日益重要，DevSecOps理念的提出便是为了这样的问题。在近日举行的2021年“ThoughtWorks技术雷达峰会”上，ThoughtWorks技术专家分享DevSecOps的发展现状、挑战以及未来趋势。

多因素催生DevSecOps

DevSecOps的出现是与整个安全环境的变化息息相关的。ThoughtWorks首席安全咨询师蒋帆告诉记者，企业过去更多是关注网络安全或者信息安全，但是随着企业数字化产品系统的增多，虽然传统的安全设备和产品可以保护企业的IT基础设施，但是对数字化平台系统自身的安全风险却无能为力。

企业数字化全面提速，业务系统成为重要载体，这就涉及安全合规问题。国家层面也在通过相关立法确保安全风险的可控，作为企业自身更是需要尽到责任主体的义务。

蒋帆表示，从业务人员角度看，企业是不允许在没有完善的安全保护措施下将业务进行数字化。“先把数字化系统建设起来，再补充安全能力，这在传统行业客户的业务场景中是行不通的。”

安全不像质量问题，质量问题更多是功能层面，而如果在安全设计上面存在瑕疵，一旦被攻击者利用，就会成为安全漏洞，进而影响企业的业务运行。这就需要企业构建一个响应力，不断追踪产品上线之后的安全风险问题。

而且现在的安全攻击和传统的威胁是截然不同的，进攻思路更加丰富，体系更加复杂，活动难以察觉，潜伏和破坏并存的结构，从战术体系到具体的软件工具一系列综合的进攻方式，呈现出了专业化、组织化的特点。

蒋帆说，虽然企业能够为寻找相应的安全工具应对安全挑战，但是如何有效利用起来才是关键。企业的软件开发团队如果无法快速响应漏洞风险，再多的工具都是没有意义的。

于是我们看到DevSecOps的工作实践与方法论得到快速发展和广泛接纳，不过在具体的落地过程中，虽然DevSecOps的提出就是将安全实践融入到软件的各个生命周期，但目前的DevSecOps的工作仍然存在着太多的割裂，很多情况下是安全的触角伸到了软件各个生命周期上，但是并非融入，并形成完善流畅的体系流程。

这表现在DevSecOps只是局限于工具的单纯应用，而不是以一种更加系统的方式来推行相关工作。如何有机将这些工具和具体实践以及数字化软件本身结合将成为接下来DevSecOps落地的问题。毕竟软件本身就需要有内建的安全能力，而不是单纯靠软件的交付流程或是某个独立的安全岗位部门来实现。

DevSecOps的“下沉”

蒋帆认为，DevSecOps不能“悬在空中”，需要“下沉”，将安全工作进行全方位的内建是必然的趋势。也就是我们常说的“左移和右移”，这样DevSecOps实践、平台和工具能够软件生命周期的各个环节。

所谓“左移和右移”是相对于软件生命周期而言，向左即是朝着业务设计、项目启动、需求梳理以及开发阶段移动，向右是向着软件的零信任架构内部、部署运行和维护阶段移动。而中间就是当前常规安全审核与检测工作本来所处的阶段。“这正体现了安全工作的全面渗透，而并不是待在一个点上等着作为‘守门员’的角色而出现。”蒋帆说。

应该说，安全工作的全方位内建不光要将工具纳入到各个生命周期环节中，还要有方法体系进行指导。而ThoughtWorks最近两期的“技术雷达”在实践、平台和技术都体现了DevSecOps工作左移和右移的趋势。

蒋帆说，企业需要将安全工作“下沉”到开发团队或者运维团队，并配备相应的DevSecOps工具平台。而且企业需要有权责一体的角色定义，让开发运维团队构建起对安全的认知，提升在安全方面的能力水平。

在推动DevSecOps工作的时候，很多企业都成立了独立的安全团队，不过开发团队本身缺乏安全问题的一些意识认知、必要知识和上下文，而安全团队缺乏软件的架构和业务上下文。因此在这个问题的处理上就容易产生一系列的分歧，例如业务优先级、如何修复等等。

DevSecOps上的安全流水线不是单纯由开发团队负责或安全团队负责。代码和流水线所有权的分离同样是一种“守门员”的心态而非内建心态。安全专家应该融入团队进行各种上下文互相融合提供更好的解决方案，而不应该划定非常割裂的边界，不同角色安全的职责边界是存在交叉区域的，否则反而会阻碍安全工作的内建。

DevSecOps的“三化”

安全问题是一个跨功能、跨层次的问题，我们在应用层面上进行防守，但是进攻者可能从网络层或操作系统层面进行攻击。而且安全问题具有时间属性，它不是静态问题。安全问题无法像传统开发方式那样进行一次性的测试或者扫描。即便是通过所有测试上线也会随着时间的推移暴露各种各样的问题。而且是必然暴露各种各样的问题。

平台化、服务化、持续化将成为DevSecOps工作的重要目标。这有两个原因，第一是平台产品本身具有的安全属性；第二是平台提供的自动化配置能力。安全实践催生工具，而工具的整合离不开平台，最终形成一个全景的方式覆盖到软件完整的周期。服务化能够给企业提供一个灵活定制的能力，保证平台本身的安全。

蒋帆表示，在应用开发过程中，DevSecOps的链条所涉及的工具越来越丰富，在开发和维护过程中更是需要跨越层次来进行防护。持续对全领域问题进行投资和维护这绝不是一种产品甚至是一个部门能够承受的。

为了降低这种负担，平台服务作为软件开发、部署、运行的类似操作系统的存在，在这些产品上内嵌的安全属性及其完整闭环对于应用的开发和维护都将成为一种必需品。

此外，DevSecOps工作需要综合性的人才，安全专家需要拥有业务知识，需要深入理解软件架构以及开发。此类人才对未来DevSecOps的工作的融合和发展将起到越来越重要的作用。

目前，ThoughtWorks安全技术和系统研发部门也在通过规划咨询以及解决方案帮助企业实现DecSecOps能力的导入。同时，ThoughtWorks也在与产业伙伴一起在方案规划、标准制定等方面展开更多合作，打造完全的生态。