2026-07-13 04:30:54 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文基于Gartner2016年报告解读DevSecOps核心理念与实践。核心观点是安全必须可编程、自动化并深度融入DevOps全生命周期，而非作为事后审核环节。关键挑战包括合规与敏捷冲突、安全基础设施缺乏API、开源组件漏洞引入。建议包括：要求安全平台开放API实现自动化、采用信任并验证原则、对自定义代码和开源组件进行自动化安全扫描（如IAST、SCA）、将基础设施配置视为代码管理、实施白名单机制和系统完整性度量。可操作建议是优先修复高置信度漏洞，并将安全指标纳入开发考核。 综合评分： 86 文章分类： 安全建设,安全开发,安全工具,应用安全,云安全

cover_image

DevSecOps：安全如何丝滑融入DevOps（Gartner 2016 经典报告全解读）

原创

裴伟伟裴伟伟

洞源实验室

2026年7月12日 03:07 北京

在小说阅读器读本章

去阅读

本文基于 Gartner 2016 年 9 月发布的研究报告《DevSecOps: How to Seamlessly Integrate Security Into DevOps》（作者：Neil MacDonald、Ian Head）整理。虽然报告发布已经过了十年，但其中提出的理念和实践至今仍是理解 DevSecOps 的根本——即便 AI 开发颠覆了软件开发的过程。

一、安全团队正在被开发和运维”嫌弃”

Gartner 在2015年的数据中心和信息安全峰会上做过两组调研，问题很直接：

“你觉得你们公司的信息安全政策/团队，拖了 IT 效率的后腿吗？”

调研结果显示，77%的信息安全从业者和81%的IT运维人员回答“是”。

也就是说，安全行业和运维行业里每5个人就有4个认为安全工作正在拖慢业务发展速度，甚至连安全从业者自己都承认自己是业务发展的“绊脚石”。

与此同时，2016年5月份发布的另一份 Gartner 企业级 DevOps 调研发现：

安全和审计工具是 DevOps 落地中被评为最重要的工具类别（比 CI/CD 工具、监控工具排名还靠前）。
82% 的受访者表示他们的 DevOps 项目中至少要应对一项合规监管要求。

这两个调研结果说明，大家都知道安全很重要，但安全的跟不上 DevOps 的节奏（即便现在也是如此）。

Gartner 在 2012 年就提出过一个概念叫“DevOpsSec”，后来因为这个缩写太像DOS（Denial of Service，拒绝服务攻击），于是改名为“DevSecOps”。这个概念的内核是：让安全深度参与到 DevOps 的每一个环节里，而不是在开发流程走完之后，才作为一个审核或测试节点做补充。

二、DevSecOps落地的三个关键挑战

《DevSecOps: How to Seamlessly Integrate Security Into DevOps》报告开篇提炼了 DevSecOps 实践中的三个关键挑战：

挑战一：合规是 IT 领导最关心的事，但安全却被当成 DevOps 的“减速带”。

企业既想要 DevOps 的敏捷和速度，又必须满足监管合规要求，而传统的安全管控方式往往意味着“人工审核+人工签字”，这跟 DevOps 追求的分钟级发布节奏形成了天然的冲突。

挑战二：安全基础设施还没有软件定义化，很难被自动化调用。

简单而言，就是很多安全产品还停留在需要专人登录控制台去点鼠标配置的阶段，没有开放完整的 API，没法被融入自动化流水线里（实际上，在安全态势感知工作构建中也存在同类问题，安全产品或许开放了接口，但接口信息不完整导致很难让工具产生的数据融入到态势感知的数据源收集范围中）。

挑战三：现代应用是组装出来的，不是从零手写出来的。

现在的软件开放过程中很少有人从零开始编写代码，大量功能靠拼装开源组件实现。问题是，开发者经常在不知情（或者知情但图省事）的情况下，直接引入了已知存在漏洞的开源组件。

围绕这三个挑战，当时 Gartner 给出了一整套建议，这也就是本文的重点。

三、Gartner 给出的核心建议

Gartner 建议信息安全团队应该：

从安全开发和培训入手，但不要逼开发者变成安全专家，也别逼他们换开发工具。
拥抱“以人为中心的安全”理念，把安全责任下放给开发者本人承担，同时用监控手段做补偿，即所谓的“信任并验证”思路，而不是传统工作方式的零信任加层层审批。
要求所有安全平台都必须通过 API 暴露全部功能，否则没法自动化，也无法形成真正意义上的 ASPM（Application Security Posture Management，软件安全态势管理）。
是对所有应用代码、DevOps 里的脚本/模板/蓝图，都用规范的版本控制手段管理（比如 Git ，这在当下已然不是很大问题）。
拥抱“不可变基础设施”（Immutable Infrastructure）理念，即生产环境都应当是不可随意变更的，任何变更都必须通过开发流程重新走一遍，而不是有人直接登录服务器手动改（这也是为什么变更管理在软件开放中非常非常重要）。

以下部分是报告正文的分析，一共 13 个小节，笔者会在其中将每个专业术语都解释清楚，大家可以选择性阅读。

四、报告正文逐节详解

1. 安全控制必须可编程且自动化

报告里配了一张很经典的 DevSecOps 生命周期图：

左半个圈是Dev（开发）：计划（Plan）→创建（Create）→验证（Verify）→预生产（Preproduction）

右半个圈是Ops（运维）：配置（Configure）→检测（Detect）→响应（Respond）→预测（Predict）

中间是持续的“监控与分析”（Monitoring & Analytics），而Sec（安全）是虚线圆圈，把整个生命周期都罩在其中，这就是这张图想表达的核心意思：安全应该像空气一样渗透到开发到运维的每一个环节。

要做到这一点的前提是安全能力必须能被能被编程且可被调用。具体来说：

要求安全和管理类厂商把平台功能 100% 通过 API 开放；
要求厂商明确支持主流 DevOps 工具链（比如 Puppet 这类自动化配置管理工具）；
要求厂商明确支持容器和容器编排系统（虽然容器不是 DevSecOps 的必需品，但确实能让交付流程更顺畅）。

因为自动化能大幅减少人为误操作，运维事故、非计划宕机乃至很多成功的攻击事件追根溯源往往就是人工配置出错。而当安全能力可以被程序调用时，安全团队的角色就从手动点鼠标的执行者变成了制定策略并让机器去自动落地策略的架构师。

2. 用 IAM 和 RBAC 做职责分离

在 DevSecOps 循环里流转的服务和变更越来越多，审计人员和安全架构师需要清楚地知道谁在什么阶段能做什么事。哪怕是同一个团队的人，在开发阶段和生产阶段应该拥有的权限也完全不同。

具体建议包括：

对接 IAM（Identity and Access Management，身份认证和访问管理）系统（比如常见的 Active Directory 或 LDAP ），要求所有工具都接入统一的身份体系，而不是各搞一套账号密码；
给开发、预生产、生产环境分别定义不同角色，理想状态是没有人可以直接手动登录生产环境，所有操作都必须通过脚本和 API 完成；
采用“信任并验证”原则：产品团队对自己的变更负全责，但必须可审计，即通过审计日志和像 Git 这样的配置仓库来做事后验证。

这里 Gartner 并不建议把权限锁死，而是主张在各自负责的阶段内，给予团队充分的自主权，配合监控去做补偿性核查，这也是“以人为中心的安全”的体现。

3. 给应用建立风险和威胁模型

很多企业一听“威胁建模”就觉得是资深安全专家才能干的高深工作，但 Gartner 建议是先做一个简单的调查问卷（笔者将这类工作的结果称为业务档案和产品档案）。比如：

这个服务有没有处理敏感数据？处理的是什么类型的敏感数据？
通信有没有加密？
静态存储的数据有没有加密？

基于问卷结果，判断这个应用的风险等级，风险越高就意味着安全团队需要介入的安全建模就越深，比如涉及敏感数据或直接暴露在公网上的应用需要安全团队深度参与。

同时也要培训开发者编写安全的代码以防范常见的漏洞利用攻击，比如缓冲区溢出、SQL 注入、跨站脚本攻击等。

另外还有一条容易被忽视的建议：开发测试环境不要用真实的生产敏感数据，而是要做脱敏、去标识化，或者用合成数据代替——毕竟很多数据泄露事故，恰恰就发生在测试环境这种防护相对薄弱的地方（在环境管理中应该严格确保测试环境和生产环境隔离，笔者遇到过生产环境数据回流到测试环境的事故，虽然对生产环境无影响，但会造成测试环境中出现无任何脱敏的生产数据，这极大威胁到用户的个人隐私）。

4. 扫描自定义代码、应用和 API

这一节笔者先解释一下涉及到的英文缩写：

SAST（Static Application Security Testing，静态应用安全测试）：不运行程序，直接分析源代码或编译后的代码，找潜在漏洞。好比审稿人看你的文章草稿挑错别字。

DAST（Dynamic Application Security Testing，动态应用安全测试）：把程序真正跑起来，像攻击者一样从外部去攻击它，观察实际反应。好比找人真的去试穿你做的衣服，看会不会崩线。

IAST（Interactive Application Security Testing，交互式应用安全测试）：在应用内部植入探针，一边运行程序一边实时检测，兼具 SAST 的“看得到代码内部”和 DAST 的“真实运行环境”两种优点，但需要应用及其开发语言支持插桩，常见于 Java、.NET、PHP 等开发语言。

AST（Application Security Testing）：是上面这些测试类型的统称。

Gartner 的判断是传统的 SAST/DAST 太笨重、太复杂，通常需要专职安全人员操作，这种模式没法规模化，跟不上 DevOps 的节奏。其给出的对应建议是：

训练开发者在自己的IDE（集成开发环境，也就是写代码用的编辑器软件）里用上像拼写检查器一样轻量的安全扫描插件，边写代码边提示，而不是等代码写完了才被安全团队打回重做；
如果应用开发语言支持，最好优先用IAST（目前来看，IAST的应用同时还受到测试环境一致性、大规模应用时受到环境一致性影响），而如果不支持的话，用能完全自动化、不需要安全专员介入的 AST 工具，比如自动化测试脚本驱动 DAST 扫描；
如果用了 SAST/DAST，要求厂商支持差异化扫描——只扫描本次改动的代码和受影响的下游模块，而不是每次都全量扫描（不然扫描时间会拖垮 CI/CD 流水线）；
达成零漏洞是不现实的，要接受一定程度的误报和漏报，优先让开发者关注最高严重级别、最高置信度的漏洞，关键是把漏洞反馈的噪音降下来，避免失去开发人员对安全工具的信任；
制定安全漏洞修复政策，比如已知的严重漏洞不允许带着进入生产环境，而风险较低的漏洞可以酌情放到后续迭代再修；
把安全指标纳入代码质量考核，跟开发团队的绩效挂钩，形成正向激励。

5. 扫描开发过程中的开源软件（OSS）问题

这一节直接呼应了前面提到的第三个关键挑战，即现代应用是组装出来的。报告引用了 Sonatype（一家专注开源组件安全的公司）的数据：

Maven（Java 生态里最常用的开源组件仓库之一）上大约 6% 的下载是已知有漏洞的组件；

更早的一项研究发现，71% 的生产环境应用中，至少含有一个被标记为严重或高危级别安全缺陷的开源组件。

这一类扫描工具和服务，Gartner 给它的专业名字叫SCA（Software Composition Analysis，软件成分分析），简单理解就是给应用做一次成分检测，看看里面到底用了哪些开源“配料”，这些“配料”有没有被曝出食品安全问题（漏洞）。

而对此，Gartner 给出的具体建议是：

把 OSS 模块识别和漏洞扫描列为优先事项；
对开发中的应用、系统镜像、虚拟机、容器进行全面扫描，找出隐藏的、未申报的、或已知有漏洞的开源组件；
实施 OSS 防火墙，即从策略层面直接拦截开发者下载已知有漏洞的开源代码（比如基于Nexus构建开源组件防火墙），把问题挡在组件进门之前，而不是等代码都写完了再去补救。

6. 扫描开发环境中的漏洞和错误配置

除了自定义代码和开源组件，还需要对整个镜像的内容做扫描，包括虚拟机、亚马逊云的 AMI 镜像、容器等等，扫描范围要覆盖操作系统层、应用平台层、商业现成软件层，并且检查这些系统的配置是否符合行业标准的安全加固规范。

报告里有一个特别值得记住的数据：Gartner 预测，到 2020 年，99% 被利用的漏洞，都是安全和 IT 从业者早在至少一年前就已经知道的漏洞。这句话的意思是大部分攻击其实靠的不是什么 0day，而是已知但没打补丁的老漏洞。因此把有漏洞的系统挡在生产环境之外，其实是投入产出比很高的一件事。

对应的建议包括：

把镜像内容扫描做成 CI/CD 流程的自动化环节，政策上不允许带着严重级别漏洞的系统进入生产；
要求开发者移除不必要的模块，按行业标准做加固；
集成反恶意软件扫描（比如 VirusTotal 这种多引擎病毒扫描服务）、网络沙箱、算法式恶意代码检测，确保镜像在开发过程中没有被植入恶意代码。

7. 把脚本/配方/模板/镜像层也当成敏感代码对待

这一节讲的其实就是现在很流行的IaC（Infrastructure as Code，基础设施即代码）安全理念的雏形。其核心逻辑是：

既然基础设施现在也是靠代码/脚本/模板来自动部署和配置的，那么这些脚本本身，就应该被当成跟应用源代码同等重要的资产来保护。

一个写得很烂或者被误改的脚本，一旦被自动化流程执行、推送到生产环境，造成的破坏可能是放大的。

对此 Gartner 给出的建议是：

用良好的版本控制工具（比如 Git）管理所有部署到生产环境的应用软件；
把版本控制的范围，从应用代码扩展到基础设施配置和监控配置；
用自动化脚本部署到预发布环境做最终测试；
扫描脚本里的错误和内嵌风险，比如脚本里直接硬编码了账号密码、加密密钥、API Key 这类敏感信息（这是实际渗透测试和红队工作中极其常见的一个攻击面，很多内部沦陷事件的起点，就是某个脚本或配置文件里被明文写死的凭据，可参考应用配置信息的安全管理实践）。

当这套体系真正落地后，就能实现基础设施的任何变更，都是全程可记录、可审计的效果。

8. 测量系统完整性，确保加载时的配置是正确的

这一节开始，报告的视角从开发侧切换到运维/生产侧。核心问题是：你现在正在加载运行的这个系统/镜像，真的还是你当初部署的那个版本吗？会不会已经被人偷偷改过了？

一个老练的攻击者，完全可能在开发阶段就悄悄篡改镜像或某一层内容，然后潜伏到生产环境里生效，比如2020年发生的SonarWinds事件。为了防范这个风险，建议：

对系统启动时的各层元素做完整性度量，包括基于硬件的信任根度量（涉及 BIOS/固件、引导加载程序 Bootloader、虚拟化管理程序 Hypervisor、操作系统各层）；
如果使用虚拟机，静态存储时要加密并做哈希校验，启动时验证是否被篡改；
如果使用容器，选用支持哈希校验或类似技术的容器管理系统，确保加载时的完整性可被验证。

9. 在生产系统（包括容器）上使用白名单机制

传统的杀毒软件走的是黑名单逻辑，它需要维护一个已知恶意软件的特征库，匹配上了就拦截，但问题是，永远有未知的新恶意软件能绕过特征库。白名单则是只允许已知合法、被明确授权的程序、连接、访问行为运行，其他一切默认拒绝。任何试图作为文件被执行的恶意软件，天然就会被这套机制挡在门外。

白名单不只局限于哪些可执行文件能跑，还可以延伸到：

网络连接的白名单；
用户访问、管理员访问的白名单；
文件系统访问的白名单；
中间件/PaaS 访问的白名单；
进程运行的白名单。

Gartner 特别指出过去做全面白名单很难，但在 DevOps 环境下反而变得容易了——因为 DevOps 的模板、配方、脚本、容器清单本身就是声明式的（也就是说，部署脚本里本来就清清楚楚写明了这个系统应该运行哪些进程、开放哪些端口），这些声明式定义天然就可以直接拿来生成白名单规则，不需要额外再靠人工去总结。

因此报告给出的对应建议是：

在服务器工作负载上关闭基于特征库的实时杀毒扫描，转而采用白名单模型——Gartner 认为，在管理良好的服务器上，传统杀毒软件提供的价值很有限，反而白白浪费资源;
从 DevOps 工具链和容器的声明式配置里，自动生成白名单；
如果使用容器，要求厂商支持容器场景下的白名单方案。

10. 假设系统被攻陷；监控一切；为快速检测和响应而架构

在高级和定向攻击面前，完美的防御是不现实的。与其把所有筹码都押在如何防止被攻破上，不如同时投入资源去做一旦被攻破，我能多快发现、多快响应。

对此 Gartner 给出的建议是：

对关键应用做全方位持续监控，包括用户登录/登出、交易行为、交互、网络活动、系统活动等；
用监控数据建立正常行为的基线，从而识别出有意义的异常偏离；把监控数据在 DevOps/产品团队、平台团队、安全运营中心（SOC）团队之间共享——因为一次异常，既可能是硬件故障，也可能是软件 bug，也可能是内部威胁，也可能就是攻击，需要多方协同才能准确判断；
部署诱骗和陷阱服务（Deception/Decoy）——简单说就是部署蜜罐，故意布置一些看起来像真实资产、实际是陷阱的系统，一旦有人碰它，基本可以确定是攻击者，从而更容易识别攻击行为。

11. 锁定生产环境的基础设施和服务

这一条是不可变基础设施（Immutable Infrastructure）理念的落地：

安全架构师应该和运维团队配合，把生产服务器和基础设施锁死，使得自动化工具成为对生产环境做变更的唯一途径。

也就是说，不应该出现某个运维工程师半夜登录服务器手动改个配置，而是任何变更都必须经过 DevSecOps 流水线重新走一遍，自动化生成新的镜像去替换旧的。

Gartner 特别强调这种做法带来的防护力度，比单纯依靠”职责分离”（也就是前面第 2 节讲的 IAM/RBAC）要更高。而且在这种模式下，“变更咨询委员会”（CAB，change advisory board，传统 IT 里负责审批变更的委员会）的角色也会发生变化——从审批要不要放行转变为单纯的排期协调角色，因为真正的风险控制已经前置到了开发和自动化流程里。

具体建议是：

限制只能通过自动化工具和脚本做变更；禁用 SSH 远程登录、禁用 RDP 远程桌面，强制所有访问都走 API 和脚本；
采用不可变基础设施思路时，系统漏洞修复工作不是打补丁修复，而是直接用全新的镜像替换，用系统化、自动化的方式完成；
极少数确实需要直接管理员访问权限的场景，要求通过特权访问管理（PAM，Privileged Access Management）系统来管控这类高权限凭据的使用。

12. 要正视容器安全的局限性

Gartner 特意提醒容器不是 DevOps 的必需品，但因为容器能让应用从开发到生产的交付变得更一致、更顺畅，所以在 DevOps 环境里非常流行。不过容器也带来了一些绕不开的安全短板：

容器共享同一个操作系统内核，真正提供隔离的其实是这个共享的 OS，而不是虚拟化层（Hypervisor）——这跟虚拟机（每个 VM 有自己独立的 OS 内核）有本质区别；
容器之间的网络隔离，本质上是靠软件定义的虚拟网络（网桥/Overlay 网络）实现的逻辑隔离，同一宿主机 / 同一网络平面上的容器之间，默认是可以互相访问、互相通信的；
一旦操作系统内核层被成功攻破，宿主机上所有容器都会被暴露——一荣俱荣，一损俱损。

正因如此，Gartner 建议：只在信任级别相近的负载之间共用容器；如果需要更强的隔离性，应该用虚拟机或物理隔离来实现，而不是指望容器本身。

13. 最后的结论

报告在结尾处的总结非常凝练，笔者这里转述原文的核心意思：

DevSecOps 追求的目标，是让安全检查和管控自动化、透明化地贯穿在 DevOps 环境下 IT 服务的整个开发交付过程里。简单粗暴地把传统安全工具和流程叠加到 DevOps 上面，是行不通的。安全建设必须从开发的最早期就开始介入，并且一路跟随这个工作负载走完它的全生命周期。

最后一句话，笔者认为是整篇报告的灵魂：

成功的 DevSecOps 项目，归根结底必须忠于 DevOps 最初的哲学：团队协作与透明，以及通过持续学习实现的持续改进。

换个通俗的说法就是，如果要得到你想要的，得先满足你要服务对象的想法。

五、为什么这份报告到今天依然不过时

回头看这份十年前的报告，会发现它探讨的很多话题预判了今天安全圈的主流话题：

它讲的“安全能力必须可编程、要开放 API”，就是今天说的安全左移、安全即代码（Security as Code）的雏形；

它讲的“把脚本/模板当成敏感代码”，就是今天常说的IaC 安全（比如 Terraform、CloudFormation 模板扫描）；

它讲的“生产环境锁死、只能靠自动化变更”，就是今天云原生领域反复强调的不可变基础设施；

它讲的“假设已被攻陷，监控一切”，就是 SOC（安全运营中心）、XDR 这些方向的底层逻辑；

它讲的“OSS 防火墙、软件成分分析（SCA）”，放到今天对应的就是这几年因为 Log4Shell、XZ Utils 后门事件被反复强调的软件供应链安全和SBOM（软件物料清单）。

对安全从业者来说，这份报告最大的价值在于它提出的一套思维方式：

安全不应该是开发流程走到最后，突然冒出来卡关的那道闸门；而应该是从第一行代码、第一个部署脚本开始，就默默嵌入在整个流程里的一层底层角色。

这句话，放到今天依然值得每一个做安全从业者或者跟安全打交道的开发者反复回味。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：洞源实验室《DevSecOps：安全如何丝滑融入DevOps（Gartner 2016 经典报告全解读）》