文章总结： 本文基于GitLab报告指出AI已成DevSecOps基础变量，生成代码占比达34%。AI虽提效但引发数据隐私、影子AI及工具链割裂风险。建议企业勿简单禁止，应依托平台工程整合工具，建立Agent治理与审计机制，推动合规代码化，将AI纳入受控体系并加强人员复合能力培养。 综合评分： 92 文章分类： 安全建设,AI安全,数据安全,安全开发,安全运营

AI在重塑DevSecOps，但真正考验的是工程能力

原创

裴伟伟 裴伟伟

洞源实验室

2026年7月22日 20:22 北京

在小说阅读器读本章

去阅读

过去谈 DevSecOps，很多团队关心的是怎样把安全更早地放进研发流程里。现在，AI 已经进入软件开发生命周期：代码生成、软件测试、代码审查、漏洞修复，甚至文档编写、代码部署、产品合规都开始被 AI 影响。于是 DevSecOps 面临的不再只是“安全左移”，而是一个更现实的问题：当 AI 开始参与写代码、改代码、审代码，安全、合规和工程效率应该怎么重新组织？

GitLab 去年发布了一份调查报告《The Intelligent Software Development Era: How AI will redefine DevSecOps in 2026 and beyond（智能软件开发时代：2026年之后AI将会怎样重新定义DevSecOps）》，报告由 The Harris Poll 代表 GitLab 在 2025 年 7 月 31 日至 8 月 15 日期间调研完成，样本包括 3266 名 DevSecOps 专业人士，覆盖 IT 运维、IT 安全和软件开发岗位。同时，报告还引用了另一项面向 2786 名 C-level 高管的研究数据。

这份报告的概括成一句话是：AI 已经成为 DevSecOps 的基础变量，但它带来的不是简单提效，而是流程、工具、责任和能力结构的重新分配。

一、AI 已经不是试验品，而是 SDLC 的一部分

97% 的 DevSecOps 专业人士表示，他们所在组织已经在软件开发生命周期中使用 AI，或者计划未来使用。其中，63% 已经在使用，34% 计划未来使用。明确表示没有计划引入 AI 的只有 2%，明确禁止 AI 进入 SDLC（Software Development Lifecycle，软件开发生命周期） 的比例为 0%。这意味着研发流程里的很多环节都会因为 AI 被加速，甚至重新定义。

报告中提到，当前 AI 在测试和编码中的使用比例普遍都达到 60%，代码审查为 58%，文档为 58%，监控为 56%，安全测试为 55%，安全扫描和修复为 54%。未来两年，部署、合规、安全扫描等环节的 AI 使用计划也都在继续增长。这说明 AI 不再只处理局部任务，而是开始参与整个软件交付链路。但问题是，软件交付链路越长，AI 的影响就越不可能只停留在效率层面，它必然会进入安全、隐私、合规、责任边界这些更难处理的区域。

二、开发者写新代码的时间，其实没有想象中那么多

报告中有一个很值得注意的数据：DevSecOps 专业人士平均只有 15% 的时间用于编写新代码。其他时间被会议和行政事务、测试、理解已有代码、识别和缓解安全漏洞、代码维护、改进已有代码等工作占据。外界常以为开发者主要是在写新功能，但实际上大量时间消耗在理解系统、处理历史包袱、修复问题、响应流程和跨团队沟通上。这也解释了为什么 85% 的受访者同意：Agentic AI 可以帮助他们处理堆积起来的辅助任务，让他们更专注于原本被雇来做的工作。这也是 DevSecOps 未来一个重要方向：AI 不只是生成代码，而是承担一部分流程性、重复性、低创造性但高消耗的工作。

问题在于，这类工作往往也是安全和合规风险最容易出现的地方，比如自动修复漏洞、自动更新依赖、自动生成配置、自动调整流水线，如果没有审批、回滚、审计和测试机制，效率提升很可能变成风险放大。

三、应用安全责任正在分散，但不等于责任自然落地

在应用安全责任归属上，44% 的组织主要由安全工程师负责，21% 由开发者负责，18% 由运维团队负责，10% 由平台工程团队负责，5% 交给第三方。这说明应用安全已经不再是单一安全团队的事情，但也暴露出另一个问题：责任分布越广，越需要统一流程和共同语言。

报告中 85% 的受访者表示对组织的应用安全方法有信心，但信心不等于问题已经解决。因为同一份报告显示，76% 的受访者同意：当前更多合规问题是在部署之后，而不是开发过程中被发现。72% 的人认为，快速修复漏洞的努力经常被组织内的流程阻碍拖慢。

这不是单个工具能解决的，而是 DevSecOps 的基本矛盾：安全希望更早介入，业务希望更快交付，合规希望更完整留痕，开发希望更少干扰。AI 能加速其中一些动作，但不能自动解决这些角色之间的责任冲突。

四、安全工具很多，但不等于安全能力强

报告列出了组织在 SDLC 中启用安全的方式：DAST 占 30%，SAST 占 29%，SCA 占 29%，IAST 占 27%，DevOps/DevSecOps 平台占 27%，许可证管理占 23%，依赖防火墙占 23%，SBOM 生成占 21%，外部扫描器占 20%，库白名单占 20%，流水线合规占 19%，容器扫描占 19%，密钥检测占 19%，API 模糊测试占 17%。

但从第三方视角看，工具覆盖得越多越好是一方面，工具之间是否形成闭环则是另一个问题。如果 SAST 发现的问题没人修，SCA 报出的高危依赖没人确认影响范围，SBOM 生成后没人用于应急响应，容器扫描结果不能阻断高风险发布，那么工具只是把风险换成了报表。

DevSecOps 的价值不在于工具采购清单，而在于能否把发现、分诊、修复、验证、发布、审计串起来。AI 进入之后，这个问题会更明显。因为 AI 会生成更多建议、更多报告、更多自动化动作。如果底层流程不清楚，AI 只是让混乱变得更快。

五、AI 生成代码已经很庞大，风险也随之扩大

报告显示，在当前使用 AI 工具的人群中，他们处理的代码里，AI 生成代码平均占 34%，从零手写的代码占 37%，从 Stack Overflow、Google、Reddit 等其他来源复制粘贴的代码占 29%。AI 生成代码已经接近手写代码的比例，换句话说，很多团队面对的已经不是“少量 AI 辅助”，而是“AI 成为代码来源之一”。

但报告也指出，AI 生成代码正在引入新挑战。受访者认为最大的挑战包括：安全威胁和数据隐私 39%，代码中的安全漏洞 37%，不得不重写 AI 生成代码 31%，复杂任务能力有限 30%，与遗留系统兼容 29%，学习曲线和技能差距 27%，编码标准遵循 27%。更准确地说，AI 生成代码降低了写代码的门槛，也降低了把不理解的代码带进仓库的门槛。

报告中还有一个数据：73% 的受访者表示，他们遇到过“vibe coding”带来的问题，因为代码一旦进入生产环境，责任不属于模型，而属于组织。从安全角度看，vibe coding 最大的问题不是 AI 会不会写错，而是人是否失去了判断。开发者可以借助 AI 提高速度，但不能把理解权交出去。代码审查、测试、威胁建模、依赖治理和权限设计，仍然需要人承担最终责任。

六、数据隐私是 AI DevSecOps 的第一道硬门槛

报告显示，94% 的 DevSecOps 专业人士对使用 AI 工具有数据隐私方面的担忧。具体来看，49% 担心数据可能被 AI 服务提供商存储或记录且缺乏明确保留策略，48% 担心敏感信息可能被包含在模型输出中给其他用户，45% 担心难以确保符合 GDPR、CCPA 等数据保护法规，42% 担心输入数据如何被处理和保护缺乏透明度，42% 担心专有代码可能通过共享训练数据暴露给竞争对手。

因为 DevSecOps 场景里的输入往往不是普通文本，而是源代码、配置、密钥痕迹、架构细节、漏洞信息、客户数据字段、内部接口路径。这些内容一旦进入不受控的 AI 工具，就不只是“提示词泄露”，而可能变成供应链风险、合规风险和商业秘密风险。

报告还提到，39% 的 DevSecOps 专业人士在工作中不同程度使用未经组织正式批准的 AI 工具。这就是典型的 Shadow AI，也就是影子 AI：员工为了效率使用未经批准的软件或云服务，组织看不见、管不了，也无法审计。

这对安全团队是一个很直接的提醒：禁止往往不是有效策略。组织需要提供可用、好用、合规的 AI 工具，并明确哪些数据可以输入，哪些不能输入，哪些场景需要企业模型，哪些场景可以调用外部服务，哪些任务必须保留人工审批。如果企业只说“不准用”，员工很可能在浏览器里偷偷用。如果企业给出安全可用的路径，治理才有落地基础。

七、Agentic AI 会带来新效率，也会带来新攻击面

报告显示，DevSecOps 专业人士平均愿意让 AI 在无需人工审查的情况下处理 37% 的日常任务。其中，他们最愿意让 AI 独立处理的任务包括文档 52%、测试编写 49%、代码审查 47%、发布说明 44%、依赖更新 42%、安全修复 42%。同时，83% 的受访者表示，他们愿意让 AI agent 在人工审批流程下自动修复安全漏洞。

但 Agentic AI 的风险比普通代码助手更高。因为它不只是回答问题，而是可能调用工具、改代码、开 PR、更新依赖、触发流水线，甚至影响生产环境。

报告中，受访者对 AI agent 采用的主要担忧包括：隐私和数据安全 43%，安全风险 42%，质量控制 36%，监管合规 32%，AI agent 被给予过多自主权 31%，集成复杂度 28%，决策透明度不足 26%，调试问题 20%。

Agent 的权限越大，越需要边界。它能读哪些仓库？能不能访问生产日志？能不能看到客户数据？能不能修改安全策略？能不能自动合并代码？失败后如何回滚？它的每一步动作有没有审计记录？

所以未来 DevSecOps 的一个重要工作是 Agent Governance，或者叫 AI Agent 治理，即围绕权限、审计、审批、隔离、回滚、监控建立工程机制。没有这些机制，Agentic AI 就像一个很勤快但没有权限边界的实习生，它可能帮你做很多事，也可能在你没看见的时候做错很多事。

八、合规正在从人工负担走向代码化

报告显示，组织当前仍然依赖大量人工处理合规。86% 的受访者同意，公司仍然需要大量人工监督来处理更复杂的合规任务；79% 同意组织在开发中使用人工合规方案。与此同时，82% 的受访者认为，到 2027 年合规将内置到代码中并自动应用。也就是合规即代码（Compliance-as-Code）。意思是把合规要求转化为可执行、可检查、可审计的策略。例如某类数据必须加密，某类服务必须启用日志，某些依赖版本不得进入生产，某些变更必须有审批记录。

报告也显示，DevSecOps 专业人士平均每月花 13 小时在合规相关活动上，每月花 11 小时处理发布后的安全问题；团队每年直接参与或负责 9 次合规审计；合规要求导致 14% 的发布出现延迟。

如果合规只在上线前检查，就一定会拖慢交付。如果合规可以在开发过程中自动提示、自动阻断、自动留证，才可能同时满足速度和监管要求。它需要平台化能力，需要策略维护，需要组织把合规语言翻译成工程语言。AI 可以帮助解释条款、生成策略草案、整理审计材料，但最终是否可信，仍取决于规则是否准确、执行是否一致、证据是否完整。

九、AI 提效的同时，工具链复杂度正在抵消收益

报告第四部分用了一个说法：AI Efficiency Paradox（AI 效率悖论）。一方面，AI 让团队更快。报告显示，36% 的组织每天或每天多次部署到生产环境，其中多次部署占 20%，每天一次占 15%。在每天多次部署的组织中，83% 已经在 SDLC 中使用 AI。另一方面，工具链越来越复杂。60% 的 DevSecOps 团队使用超过 5 个软件开发工具，49% 使用超过 5 个 AI 工具，53% 使用超过 5 个安全工具。

工具多不一定是坏事，但工具之间如果割裂，就会产生新的损耗。DevSecOps 专业人士每周因为低效流程损失 7 小时。限制协作的因素包括跨职能沟通不足 32%，知识共享不足 31%，不同团队使用不同工具 30%，流程低效或不清晰 28%，组织孤岛 27%，文档过时 27%，工具过多 26%。

这正是很多企业的真实状态：每个局部都在提效，整体却没有变快。开发有自己的工具，安全有自己的工具，运维有自己的工具，合规有自己的表格，AI 又新增一批入口。最后，信息在工具之间断裂，责任在团队之间转移，问题在会议之间漂流。

平台工程强调为开发、安全和运维提供自助式、标准化、可复用的工作流。85% 的受访者同意，Agentic AI 在平台工程方法下最可能成功。受访者观察到的平台工程收益包括更快部署 32%，问题解决能力提升 30%，成本效率提高 29%，开发者生产力增强 29%，代码质量指标改善 27%，风险缓解改善 27%。这说明 AI 要真正发挥作用，不能散落在个人工具里，而要进入平台。平台提供统一身份、权限、策略、审计、数据边界和流程编排，AI 在其中作为能力组件，而不是游离在组织之外。

十、DevSecOps 人才不会消失，但能力结构会改变

83% 的受访者认为 AI 会在未来五年显著改变自己的角色。对于 2026 年开发者角色如何变化，40% 认为开发者会主要成为 AI 提示工程师和代码审查者，40% 认为开发者会主要管理 AI agent 而不是亲自编码，40% 认为 AI 会加速初级开发者职业成长，39% 认为行业知识会更重要，37% 认为理解业务影响会更重要，36% 认为重心会转向架构和系统设计。同时，也有 35% 认为 AI 会降低对初级开发者的需求。

AI 会降低部分编码任务的门槛，但不会降低软件工程的整体复杂度。相反，当代码更容易生成，系统设计、需求理解、质量控制、安全判断和业务语义会变得更重要。

报告中 87% 的受访者认为，采用 AI 的软件工程师是在为未来职业做准备。面向未来 18 个月，他们认为需要发展的 AI 技能包括：使用 AI 处理安全分析数据 49%，使用 AI 自动化安全实践 48%，将 AI 集成到 DevSecOps 工作流 45%，缓解 AI 系统带来的安全挑战 44%，AI 模型训练和验证 38%，提示工程 36%。

职业发展所需技能中，排名靠前的是为安全和合规实施 AI，占 43%；为代码生成实施 AI，占 39%；创建安全 SDLC，占 38%；编程和脚本语言能力，占 36%；合规和监管意识，占 35%；云环境安全，占 35%。

这说明 DevSecOps 从业者未来需要的是复合能力。懂一点 AI 不够，懂一点安全也不够。更重要的是知道如何把 AI 放进安全流程，如何设计控制点，如何验证输出，如何治理风险。

88% 的受访者认为构建新技能是工作满意度的重要组成部分，87% 希望组织投入更多帮助他们提升技能。但 71% 表示工作日没有足够时间学习和发展，68% 认为组织把提升技能的负担完全放在个人身上，却没有提供时间、资源或资金。

也就是说，对于企业而言：不要一边要求员工拥抱 AI，一边不给学习时间。AI 转型不是发几个工具账号就完成了，它需要训练、实践、复盘和流程改造。

十一、AI 不会替代人的价值，但会暴露人的短板

88% 的 DevSecOps 专业人士同意，有些关键人类品质是 Agentic AI 永远无法完全替代的。受访者认为软件开发中最有价值的人类贡献包括创造力 42%，创新 41%，协作 37%，战略视野 36%，适应能力 32%，沟通 32%，伦理 30%，同理心 29%。

对于 DevSecOps 而言，安全决策本来就不是纯技术判断。一个漏洞是否必须立即修复，要看暴露面、业务影响、利用条件、补丁风险和发布窗口。一个合规策略是否合理，要看监管要求、组织成本、系统架构和审计证据。一个 AI agent 是否可以自动合并安全修复，要看测试覆盖、权限边界和回滚能力。而这些判断目前仍然离不开人。

AI 可以帮助收集信息、生成建议、执行重复任务，但它不能替组织承担责任。它也不能天然理解企业的风险偏好、业务优先级和合规边界。AI 时代的 DevSecOps，不是“人退后，模型上前”，而是“人从重复劳动中退出来，把更多精力放到判断、设计和治理上”。

结语：DevSecOps 的下一阶段，不是更快，而是更可控

这份报告最有价值的地方，不是证明 AI 很热，而是把一个现实摆在面前：AI 已经进入软件开发的各个环节，但企业的安全、合规、协作和工具治理还没有完全跟上，DevSecOps 在之后真正要解决的不是“要不要 AI”，而是“如何让 AI 在可控的工程体系里工作”。

AI 会让软件开发更快，但安全从来不只是速度问题。没有治理的速度，会把问题更快推向生产；没有平台的 AI，会把工具复杂度继续放大；没有人的判断，自动化只是在更高频率地执行不确定性。

真正成熟的 AI DevSecOps，不是让 AI 替代安全团队，也不是让开发者把代码完全交给模型，而是把 AI 放到一个有边界、有证据、有责任、有反馈的工程系统里。这才是智能软件开发时代真正要补的一课。

免责声明：

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

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

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

本文转载自：洞源实验室 裴伟伟 裴伟伟《AI在重塑DevSecOps，但真正考验的是工程能力》