共计 6876 个字符，预计需要花费 18 分钟才能阅读完成。
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 真正落地的最初一公里。
