DevSecOps 背后的三个逻辑

---

复杂性：让安全从 “幕后” 走向 “台前”

安全并不是一个新鲜的话题，自软件诞生以来，安全就一路伴随，但是近几年安全似乎又到了一个新的 “热度” 与 “高度”。

一些企业、组织都在探讨软件供应链安全的问题。安全从之前的小众话题（可能只有安全、CISO 关注）变成了大众话题（研发、运维也在讨论）。究其原因可能是因为软件发展到如今的复杂性，让安全从 “幕后（个别人关注）” 走到了 “台前（大众关注）”。这些复杂性可能包括：

➤ 开源的使用率持续提升

开源成为了构建现代化数字基础设施的重要因素。企业、组织都无可避免的用到了开源。根据 Linux 基金会的 SBOM 报告显示，98% 的受访者表示自己所在的组织在使用开源；另外根据 Synopsys 开源安全和风险分析报告指出，调研使用的代码库中，75% 的代码是来源于开源软件。

当然，安全也成为了伴随开源使用和渗透率持续提升而出现的一个大问题。这两年为大众所熟知的 log4j 漏洞、NPM 包投毒就是典型的开源安全问题，还有时不时发生的许可证合规问题等。

➤ 软件研发模式的改变

软件研发模式从瀑布式到敏捷开发再到 DevOps 的演进，让软件的频繁发布（周发布，甚至天发布）成为常态，发布时间的缩短就并不意味着忽视安全，而是需要在早期就考虑安全问题，需要做到在保证软件安全的前提下完成软件的敏捷发布。

➤ 云（或者云原生）的转型

企业期望通过上云来利用云平台弹性伸缩的特性实现降本增效，而安全是企业 “走向” 云平台的首要考虑因素。拿这几年火爆的云原生（有说法是云原生是云计算的下一个时代）来讲，其安全也是经常被提及。

比如，镜像是云原生应用程序交付的关键，但 Snyk 发布的容器镜像安全报告指出，Docker Hub 上的热门镜像几乎都存在安全漏洞，多的达上百个，少的也有数十个。这些安全漏洞会对云原生应用程序的安全造成威胁。

➤ 法律法规的完善

近些年国内外都相继颁布了多项法律法规措施来推进安全的治理和发展。比如我国从 2017 年开始，陆续颁布并实施了《网络安全法》、《等保 2.0》、《数据安全法》以及《个人信息保护法》等法案，旨在针对数据安全（安全问题的背后其实是数据安全，安全问题是造成数据安全的重大杀手，而安全是数字化时代的核心要素）提出相应的要求和目标；而欧洲也在 2018 年开始实施 GDPR（通用数据保护条例）；美国总统在 2021 年签署了提高国家网络安全的行政命令。

法律法规的完善意味着如果发生了相应的安全问题，那么就有可能会受到监管机构的处罚，令企业蒙受经济损失。

➤ 软件供应链安全事件频发

Sonatype 发布的 2021 年软件供应链状态报告显示，2015 年 - 2021 年，软件供应链攻击事件的年增长率达到了惊人的 650%。

而 2020 年的 SolarWinds 事件，2021 年的 log4j 事件都是从业者耳熟能详的典型软件供应链安全实践。其影响将持续数年甚至更长时间。

DevSecOps：应用安全新范式，未来已来

2009 年 DevOps 首次面世，此后发展成为了应用交付的事实标准。众多企业在实践 DevOps 后实现了应用程序交付效率的大幅提升。但是安全是应用程序的基线，也是企业良好发展的生命线。尤其在现如今软件敏态开发场景下，需要在保证安全的前提下实现软件交付效率的提升。

而 DevSecOps 讲的就是将安全嵌入到软件研发生命周期的每一个阶段，通过流程、工具、文化的融合，构建起应用程序的纵深防御体系，形成应用程序效率与安全兼得的双赢局面。

DevSecOps 由 Gartner 在 2012 年首次提出（当初的叫法是 SecDevOps）。根据 Gartner 过往发布的应用程序安全测试（Application Security Testing）技术度成熟曲线来看，DevSecOps 也是经历了期望峰值期、泡沫破裂的低谷期、稳步爬升期，到了现在的成熟实践期，这也是另外一个原因：为什么这两年会有越来越多的人员、企业、组织在讨论 DevSecOps。

安全左移：解铃还须系铃人

安全问题的循环周期大概为：安全问题引入、风险识别、问题追踪、安全修复、安全复盘，然后再回到安全问题引入。绝大多数的安全问题都是在研发阶段引入，后续阶段的安全防护手段主要是对前期引入的安全问题进行挖掘修复，以其减轻其带来的安全风险。

而研发阶段在整个软件开发生命周期的左侧，因此这也是安全左移的由来：

越靠近左侧，修复安全问题的成本就越低，主要原因为：

• 研发对于环境的掌控能力强，可以在研发环境上自行进行问题复现、修复，沟通成本大大下降（相比集测环境、生产环境，如果需要抓取日志、问题复现等，可能需要权限的申请、团队的沟通协作）；

• 越快发现问题，研发越能够快速梳理清楚整个逻辑，快速解决问题（随着时间的推移，研发对于过往完成的研发任务的细节越模糊比如要梳理三个月之前的业务逻辑，总是会比梳理一周以前的业务逻辑要花费的时间更多），时间成本也大大降低；

• 研发阶段的 “爆炸半径” 相对而言是最小的（相比于生产环境）。研发阶段面对的是研发人员或者系统内部，而生产环境需要直面用户，用户体验下降，对产品的影响是重大的。

因此，对于 DevSecOps 常讲的安全左移来讲，属于是解铃还需系铃人：安全问题（绝大多数，非全部）的引入在研发侧，那么在研发侧来修复，从原则和成本来看都是可行的。

前面讲述了 DevSecOps 背后的三大逻辑：安全问题频发，需要修复 → DevSecOps 是当前认可的最佳手段 → 安全左移是 DevSecOps 落地的基本原则。这是一个层层递进的关系。

当然，目前安全这部分还有一个非常重要的逻辑：重要不等于重视。安全很重要是业界的认可，但是真正重视，在安全领域去做投入的却不多。这算是安全当前的一个窘境或困境吧！

DevSecOps 发展的四个阶段

---

人类的进化经历了漫长的阶段：从猿类到人类，从爬行到站立直行。不管是生产力还是社会的文明程度都得到了极大的提升。

图片来源：FreePik

对于 DevSecOps 来讲也是一样，大概经历了以下四个阶段：

手动化

这个阶段，主要以手动方式对于安全进行测试。当需要发布版本的时候，对发布版本进行一次安全测试（有可能针对单一安全手段，比如 SAST 或 DAST，也有可能针对多重安全手段，比如 SAST 和 DAST 的结合），针对输出的报告进行对应责任的划分，然后完成安全问题的修复。

手动操作是长时期以来一直存在的安全测试手段。其优点是：对于安全进行了投入。但是缺点也很明显：手动操作是重复性劳动，没办法针对每次代码提交都进行安全测试，只能是针对特定版本进行，而且需要测试人员熟悉所使用的测试工具。整体下来效率不高，安全问题修复的周期是比较长的。

自动化

自动化比手动化更近了一步。将安全测试集成到软件交付的自动化流程中，最典型的就是嵌入到 CI/CD 流程中，实现安全测试的持续自动化。自动化的优点比较明显：通过自动化降低了人为的干预，避免重复性的机械工作。

同时，嵌入到 CI/CD 中的安全测试，能够针对每次代码变更都进行对应的安全扫描，能够更加频繁的小步快跑的过程中及时发现安全问题。

但是缺点也是存在的：需要去学习运维负责的安全工具链，要熟悉各个工具的 API 或报告的数据结构才能够将多种安全防护手段对应的安全工具链 “串” 在一起，集成到 CI/CD 中，因此在工具上耗费的时间和精力是比较大的。

手动化和自动化有一个共性：发力点在工具链上。比如工具链的安装、配置、运维、学习等。随着工具链复杂程度的提高，这种成本陡升。比如下面这个调研报告显示，受访者表示自身企业使用到了多种安全测试工具，有的甚至多达 50 种。

此外，这种聚焦在工具链的方法，还有一个弊端：数据孤岛问题。所有的安全报告都在对应的安全检测工具上，研发、测试、安全人员想要查看安全报告就需要跳转到第三方安全工具端去查看，或者安全工具将报告发送到邮箱或 Slack 等通讯工具端，人员在通讯工具查看。

数据没办法在 SCM（研发最熟悉的工具）和安全测试工具之间打通，甚至多种安全工具之间的数据也是割裂的（不同的工具，数据格式不同，集成难度大）。数据孤岛又成了安全问题修复的新屏障。

平台化

平台化有效的解决了数据孤岛的问题，不仅可以将多种安全工具的数据经过整合后展示在同一平台上，同时还能够将安全流程和项目管理（可以用项目管理的方式来进行安全漏洞的管理）、编码、CI/CD 等流程集成起来，提高安全问题修复的速度，缩短修复周期。

因此，平台化的好处就是：可以屏蔽所有工具链的细节，直接使用开箱即用的安全能力。这也是平台化比前两个阶段有一个质的跃迁的地方：从工具的使用转向数据的挖掘和使用。

比如极狐GitLab 一体化 DevSecOps 平台，提供了 7 大安全测试手段（9 种安全防护能力），为用户屏蔽了所有的底层工具链细节，并且将安全测试无缝集成到 CI/CD 中，对于每次代码变更都会自动进行安全扫描。最后所有的安全数据都会直接嵌入到 Merge Request 中，用数据左移实现安全左移：

平台化还有另外一个好处：让研发、测试、安全等人员在同一个平台上协作，沟通成本大大下降。

虽然平台化通过发挥数据的作用，让安全左移成为现实。但是平台还有另外一个问题没有解决：并没有降低安全问题修复的门槛。安全问题的细节还是回到了安全漏洞的官方网站：

这也就意味着安全的修复依旧需要一些专业的安全知识，这对于研发来讲依旧充满了挑战，而这种门槛成为了 DevSecOps 发挥最大作用的最后一公里。

智能化（ChatGPT）

智能化主要是指利用 AI/ML 来构建应用程序安全防护体系。这并不是什么新鲜的玩法，国内外企业都有对应的常识，甚至成型的产品。

比如使用 AI/ML 来防止 DDos 攻击、自动修复安全漏洞等。但是 ChatGPT 的出现大大降低了安全问题修复的门槛：它能够以研发人员易懂的话术进行安全问题的解析，甚至直接给出可行的修复代码。

因此，ChatGPT 是否会成为 DevSecOps 的下一个发展阶段，成为 DevSecOps 落地实践的最后一公里？

ChatGPT：DevSecOps 落地实践的最后一公里

---

Medium 上有一篇文章Complete ChatGPT Guide for DevSecOps: Top 20 Most Essential Prompts 写了一些 ChatGPT 可以做的一些工作，来助力 DevSecOps 的落地实践，比如自动地代码审核、威胁建模的生成、安全测试的生成、安全漏洞的识别等。

下面几个小 Demo 展示了 ChatGPT 在 DevSecOps 实践中的可用 “玩法”。

Code Review

Code Review 是提升代码安全、构建质量内建、保障软件供应链安全的重要手段之一。比如保障软件供应链安全的框架 SLSA 就是由 Google 内部的 Binary Authorization for Borg （以下简称 BAB）实践演进而来，而 BAB 中非常重要的一个实践就是：Code Review。

通常 Code Review 的流程大体就是代码提交人员和审核人员之间关于变更代码进行代码风格、业务逻辑、安全问题等方面的沟通

这种模式下 Reviewer 的选择对于提升代码安全是非常重要的，诸如Reviewer 的能力（业务能力、技能储备、沟通能力）都会影响代码的合入。

另外，这种模式，人员之间的沟通往往是异步的（Reviewer 可能是跨时区的，也有可能手头有更高优先级的事情在处理等），这容易导致一个 MR 从创建到被审核之后的合入花费了较长的时间。当业务情况紧急的时候，往往可能发生，Code Review 让位于业务上线，让 Code Review 流于形式。

借助于 ChatGPT，一方面可以将异步 Review 变成同步，节省 Review 周期的时间，另一方面 ChatGPT 的知识库更加全面（尤其代码风格、安全漏洞库方面），能够针对代码提出更多潜在问题。

当然，对于业务逻辑本身的 Review，还需要经验丰富的人员进行。

关于使用 ChatGPT 进行 Code Review 的例子，可以参考本公众号过往的一篇文章👉玩转 ChatGPT + 极狐GitLab ｜自动化的 MR 变更评审来了。

安全漏洞的识别与修复

用一段 Node.js 代码片段来测试 ChatGPT 对于安全漏洞的识别能力。

const express = require('express');
const app = express();
const port = 3000;

// 不安全: 直接调用 eval 解析 json, 有安全漏洞，触发静态代码扫描告警
const sUserInput = getURLParam("json_val");
const jsonstr1 = `{"name":"a","company":"b","value":"${sUserInput}"}`;
const json1 = eval(`(${jsonstr1})`);

// Static Files
app.use(express.static('public'));
app.use('/css', express.static(__dirname + 'public/css'));
app.use('/js', express.static(__dirname + 'public/js'));
app.use('/img', express.static(__dirname + 'public/img'));

//  Listen on port 3000
app.listen(port, () => console.info(`Listening on port ${port}`));

const email_validator = require('./email_validator.js');
email_validator('workshop@jihulab.com')

上述代码中的 eval 函数存在安全风险，通过和 ChatGPT 交流来获得详情：

ChatGPT 明确告知 eval  函数的使用具有安全隐患。为了验证 ChatGPT 的答案是否可信，可以利用极狐GitLab 一体化 DevSecOps 平台来对上述代码进行安全扫描。以下是利用极狐GitLab DevSecOps SAST 功能的 CI/CD 代码：

stages:
  - test

include:
  - template: Security/SAST.gitlab-ci.yml

极狐GitLab 一体化 DevSecOps 平台，为用户屏蔽掉了安全工具的细节，提供开箱即用的安全能力，而且安全扫描和 CI/CD 无缝集成，可以针对每次代码变更都进行安全自动化扫描。扫描结果会自动嵌入到 Merge Request 中，方便研发人员查看安全报告。真正实现 “安全左移”。

扫描结果显示，有一个中危漏洞，也是关于 Eval 注入（Eval Injection）的。和 ChatGPT 所说一致。

如果对于上面提到的攻击者可以利用这个函数注入恶意代码，从而造成安全漏洞不甚明白，想要更细节的举例演示，则可以跟 ChatGPT 继续聊，ChatGPT 会根据上下文给出答案：

可以看出，ChatGPT 可以用研发人员易懂的话术对安全问题进行讲解，如果有疑惑的地方，可以和 ChatGPT 进行 “深入交流”。换句话说，ChatGPT 降低了安全修复的门槛（毕竟，研发能快速读懂的话，修复就省事、省时了）。

当然，ChatGPT 还会给出修复代码：

再次使用极狐GitLab 一体化 DevSecOps 平台对于上述 ChatGPT 给出的代码进行安全扫描：

从结果看，显示使用 SAST 检测未发现安全漏洞。

注意：上述示例仅为演示所用，实际使用需要将 ChatGPT 的输出与项目实际相结合，对于 ChatGPT 的建议代码进行人工审核。

上面演示了使用 ChatGPT 对于代码安全漏洞就行扫码并辅助修复的过程。可以看出，ChatGPT 有 “自己的” 安全知识库，但是在研发人员的引导下能够用研发人员易懂的话术（人话）对于安全问题进行解读，然后给出建议的修复方案（很直白，直接给代码）。

这在很大程度上降低了修复安全问题的门槛，研发人员体验会有提升，安全问题修复的周期会缩短。而且可以将这一步前置到 Code Review 阶段，使用 ChatGPT 在进行 Code Review 的时候就进行安全问题发现。

当然，ChatGPT 还可以用来进行威胁建模的生成、安全文档的输出等。限于文章篇幅，不再进行一一展示。

总结

---

DevSecOps 期望通过 “安全左移” 的方法在安全问题引入的源头及时修复问题，尽量减轻安全风险带来的攻击影响力，利用一体化 DevSecOps 平台来助力实现 “人人为安全” 理念的实践。

但是，对于安全问题的理解、报告的解读始终是横亘在研发和安全之间的一个壁垒，ChatGPT 的出现极有可能会是打破这道壁垒的希望，ChatGPT 可以将研发和安全纳入到同一个话术体系，用研发人员熟悉、感兴趣的语言解决安全问题，给研发愉悦的安全修复体验，打通 DevSecOps 真正落地的最后一公里。