极狐(GitLab) 马景贺：DevSecOps落地实践的挑战与应对之道

嘉宾 | 马景贺   整理 | 西京刀客

出品 | CSDN云原生

为什么是DevSecOps而不是DevOps？安全“左移”是要逼疯开发者吗？安全持续自动化真能搞定安全吗？人人为安全是一句口号吗？

2022年5月24日，在线上举行的云原生系列Meetup·北京站上，针对这些连续发问，极狐（GitLab）DevOps技术布道师马景贺给出了详细解答。

Why DevSecOps

DevOps从诞生到传至国内，相关的会议、文章、书籍数不胜数，当前也有非常多的企业在做DevOps转型。

那为什么要讲DevSecOps而不是DevOps呢？是因为DevOps不香了吗？

DevOps是指Dev和Ops两个Team通过有效的协作，加速整个软件研发生命周期，加速交付进程。既然如此，对于DevSecOps来说，是不是也就是把Dev、Sec、Ops这三个词融在一起就可以落地实现DevSecOps呢？其实也没有那么简单。

Security从“幕后”到“台前”

在DevOps时代，大家已经认识到应用程序的安全性了。但对于之前的软件开发模式来说，其软件交付生命周期比较长，传统的保障安全的方法基本都是被放在整个软件开发生命周期的后期集中进行。

Security逐渐受重视

首先，随着企业积极地向云上迁移，这个过程中有非常多的安全问题，如数据安全、网络安全、存储安全等。所以在此过程中，Security越来越受到重视。

其次，开源也导致大家现在把安全话题又提出来了。一些报告数据显示，所有企业其实都用了开源，比如Linux、Git、Android。从数据来看，现在企业内部使用的软件70%以上是开源的。因此，安全一下子进入人们的视野。

Security is money

安全问题会带来直接或者间接的经济损失。

直接损失如赎金支付，现在经常有勒索团伙通过攻击企业或组织的重要文件系统、窃取数据，然后勒索赎金，否则就将客户的敏感信息暴露到公网中。很多企业会为此支付赎金。

间接的形式也很多，比如当你的产品发生安全问题时，会对客户产生非常大的影响，大大降低与客户之间的信任度，有可能造成客户流失。

DevSecOps的发展现状

如下图所示，可以看到，DevSecOps经历了泡沫期与低谷期，现在处于信心恢复期，即将到达高产期。

Gartner I&O自动化技术成熟度曲线

DevSecOps三大原则

安全“左移”

传统开发模式下，安全都是在开发的最后阶段介入，甚至上线之前。在DevSecOps模式下，安全在计划阶段就介入，在软件的生命周期中，可以看到左移了。

一般软件开发生命周期，包含计划的编码、运维、部署和上线，是一整个SDL。但现在安全都是尽量往前走，尽可能在Plan阶段就介入。

为什么左移呢？看下面两张图。

左图是安全问题的发现和修复成本之间的逻辑关系图，说明越早发现安全问题，修复用的成本越低。有数据显示，如果在研发阶段发现了一个安全问题，修复它的成本是一美分；到测试阶段发现一个安全问题，修复它的成本到了十美分；到上线的时候，再去修复这个安全漏洞，同样的安全漏洞修复成本是100美分，相当于扩大了100倍。所以提出了安全左移，发现问题越早修复越好。

右图是使用DevSecOps与否和修复漏洞时间的关系图。可以清晰看到，如果采用了DevSecOps，修复漏洞所需要的时间是52天，如果不采用需要113天，如果是生产阶段，那就更高。

持续自动化

之前，很多安全测试是通过手工完成，而随着现在业务的增加，手动进行安全测试已经无法满足要求。其次，手动测试是重复的工作量，对于测试人员来说并没有技能上的提升。

如果能做到持续自动化，将安全测试手段嵌入到不同的软件开发生命周期的不同阶段，将会大大提升效率。如在构建阶段，将SAST与镜像扫描嵌入等，通过将这些测试手段自动化，以此进行持续自动化。这样在每次代码有变更时，都可以进行自动安全测试，其次能够降低测试人员重复的体力劳动。

人人为安全

以F1赛车时换轮胎的过程为例，通过大家多人的努力，可以在十几秒之内就将轮胎换好。

对软件开发生命周期也是一样，所有人、产品市场、安全、测试、研发、运维，大家都围绕着一个目标进行工作。这个目标就是更快地去给客户交付有价值的软件。

这个过程，除了快也要保证安全，否则对客户也是一种损害。从安全角度来看，我们所有人应该为安全负责。

有小伙伴会问为什么需要人人为安全，安全团队负责安全不就够了吗？和开发人员有什么关系？

当前还有很多人认为安全是安全团队的事情，与开发无关。举个简单的例子，如果你是开发人员，在平常写代码时，若引入了一个带有漏洞的包，那这就是一个安全风险的引入。任何一个人都有可能成为软件交互的瓶颈，所以开发也应该为安全负责。

DevSecOps落地实践的挑战

在DevSecOps落地过程中，会遇到很多挑战。

淡薄的安全意识

大家可以想一下，自己的企业是否做到了真正的安全。应用程序安全、网络安全以及体系的安全，是否都能做到呢？

购买软件、构建防护体系、招聘安全员，这些都会增加运营成本。而对于小公司来说，这是一笔不小的负担。他们会认为，没有人攻击我，之前也从未发生过任何问题。

目前，仍有很多人认为安全是安全团队的事情，这是很大的误区。

随着安全手段的加入，会延长业务上线的前期准备时间，这是不可避免的。但要优化或权衡该流程，不能因为会延误上线就完全放弃安全。如果上线之后发生了安全问题，那业务上线还有何意义。

大多数人认为，只有黑客攻击才算是安全事故，而这种遭遇攻击的安全事故离我很远。其实不然，我们承认黑客攻击绝对是安全问题，但除此以外，安全包含大大小小各个方面，例如密码设置强度较弱也会带来安全隐患。

• 安全是什么？不存在的

• 安全是安全团队的事情

• 安全会延误业务上线

• 黑客攻击才算安全事故，而攻击离我很远

多样的手段，繁杂的工具

前面提到了多种静态、动态覆盖软件开发生命周期不同阶段的安全检测手段。手段非常多样，每一个手段都会有一种相应的工具。所以这也是一个挑战，这么多手段、工具，该如何选择、如何使用？这是一个大问题。

复杂的报告，离散的数据

通过不同的测试方法、工具，最后都会产生一份相应的检测报告。安全检测报告并不像日常业务报告，它更为复杂、数据更加离散，大多情况下需要专业的安全人员来查看。同时，检测手段也可能是离散的，这会导致数据更加离散，最终导致信息孤岛的情况出现。

漏洞管理缺失

众所周知，安全检测存在“假阳性”的问题，有些情况下（诸如SAST）“假阳性”比例会高达50%。所以安全检测如何做到真正的去伪存真，也是一大挑战。

我们不能只是单单把漏洞记录下来，还需要去追踪其原因以便进行下一步修复工作。

修复打通就是漏洞修复的过程，这是落地实践中的一个难点。 

• 漏洞去伪存真

• 漏洞追踪机制

• 漏洞修复流程

DevSecOps落地挑战的解决之道

针对以上的痛点及挑战，有几种应对方法。

前面已经提到有多种安全测试手段，试想如果把所有的安全测试手段放到一个平台里面去，最后将漏洞报告进行统一展示。这样的话，数据就可以实现统一汇总，打通之前的数据孤岛现象。

此外有一个好处，那就是推动所有团队都进入到该平台进行协作。研发、测试等人员可以针对性地查看、分析测试报告，然后与他人进行沟通。安全员也可以根据这些报告，进行漏洞机制的回溯、管理等。

DevSecOps的落地时间，并不是将所有安全手段一股脑地嵌入到研发流程里面，而是要循序渐进地去做。

举个最简单的例子，现在云原生非常火爆，云原生时代的容器安全和镜像安全备受关注。我们如果想实现DevSecOps的话，可以先把镜像安全做起来，以此为切入点慢慢推动。

针对前文所提到的安全意识淡薄的问题，最好的方法是通过安全培训，让大家了解认识安全有用的，慢慢提升大家的安全意识。这样的话，能够为安全技术的落地实现打好坚实的基础。

• 平台化能力，打通数据孤岛

• 以点带面，循序渐进

• 安全培训要兜底

总结

安全漏洞是随着时间的迁移，陆陆续续发生的。所以说漏洞是不断发生的，安全防护是一直演进的。我们一定要去跟随这些事情，做相应的变化。不是说定制了一套很完善的安全体系就能一劳永逸。

对安全来讲，厉害的并不是发现问题，而是提前预防问题。当发现问题发生时，已经晚了，最好的情况是预防为主，防治结合。

DevOps的发展已过十多年，但安全的发展却一直伴随着IT行业的发展。在DevOps中融入安全本就不是一蹴而就的事情，需要软件开发生命周期内的所有人都参与进来。绝对安全是不存在的，也是做不到的，但我们可以用持续改进的方式去避免更多的由人祸引发的安全事故。相信我们有能力让产品变得更安全！

---

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生CSDN云原生微信公众号～ 

 限时活动，数量有限🔥

关注【CSDN云原生】公众号，回复【图书】

邀请好友助力即可免费领图书，赶快参与吧！

​