氛围编码安全风险与普通安全风险不同

氛围编码方式的出现，势必会引发编码实践和软件开发方面的一系列复杂变革。随着 AI 生成代码在实际项目代码库中的占比不断提升，最关键的变化在于网络安全风险的数量与风险类型均发生了显著转变。

简而言之，氛围编码指仅依靠 AI 工具与自然语言提示词完成产品开发的模式。需区分其与智能体编程、智能自主工程开发：后两者由资深开发人员规范、可控地使用 AI 编码工具。这个术语是由著名开发者和人工智能资深人士 Andrej Karpathy 在一条推文中提出的，他在推文中描述了一种自由奔放的人工智能编码风格，这种风格完全依赖于大语言模型 (LLM) 的提示，让用户“完全沉浸于感觉中”，并且“忘记代码的存在”。

他将这是一种有趣的“一次性周末项目”方法，但强大的 AI 编程的激增为工作场所的氛围编程打开了大门，即使在处理敏感数据的生产软件中也是如此。2025 年末行业调研显示，AI 生成代码占所有合并入库代码总量的 22%¹；GitHub 相关报告预估，平台内 46% 的代码均由 Copilot 生成²。

这导致漏洞和安全问题大幅增加，远远超出了编码助手带来的新代码数量和速度自然增长所能解释的范围。一份针对真实项目代码库的分析显示：借助 AI 辅助开发的团队代码交付速度提升 4 倍，但产出的漏洞数量却增至原先的 10 倍。³

完全放弃基于氛围的编码方式会牺牲自动化和提高参与度带来的显著生产力提升，但很明显，安全的编码实践必须随之发展。传统安全检测机制是针对专业开发人员常见人为失误设计的。企业需升级安全防护体系与检测工具，适配由 AI 智能体、采用随心编码模式的新手开发者带来的全新开发现状。

多项跨平台、跨环境、跨大语言模型的行业研究均证实：AI 代码生成量越高，应用安全漏洞 (AppSec) 数量同步增多。

例如：

• 2025 年 12 月一项针对开源代码仓库的研究发现，45% 的开发任务中，AI 生成代码都会引入安全漏洞。研究人员对比 AI 辅助提交的代码合并请求与纯人工编写的合并请求后发现：前者产生的安全隐患数量是人工代码的 2.74 倍，各类缺陷总量也高出 70%。⁴

• GitGuardian 2026 年一份关于密钥泛滥问题的报告指出：借助 Claude Code 生成的代码提交记录，泄露密钥的概率是纯人工编写提交的两倍以上。总而言之，在 GitHub 公开提交中公开的硬编码密钥（例如密码和 API 密钥）2025 年同比增长了 34%，这是有记录以来最大的单年增幅。⁵

• 2025 年 10 月一份报告指出，氛围编码开发的应用普遍存在高危漏洞与数据泄露问题，例如 API 配置错误、身份验证缺陷等；这类漏洞完全暴露在外，可通过公网接口直接被访问利用。⁶

安全团队还应该考虑到，GitHub 和类似服务上的公共存储库只是冰山一角。GitGuardian 指出，内部仓库中硬编码密钥的可能性是公共仓库的六倍。

同样值得警惕的是：相比传统开发工作流产生的安全问题，氛围编码引发的敏感凭据泄露更难被修复整改。GitGuardian 的报告指出，在 2022 年验证为合法的暴露凭据中，近 70% 到 2025 年 1 月仍然有效。截至 2026 年 1 月，仍有 64% 的用户仍处于暴露状态且未撤销。曾发生一起典型安全事件：澳大利亚足协不慎将 AWS 访问密钥泄露至网站源代码中，该密钥暴露时长超 700 天。

综合以上各类现象可见，氛围编码带来的安全风险累积速度，已超出传统漏洞修复体系的处置承载能力。

即使大语言模型功能不断改进，但 AI 衍生安全缺陷的频率和严重程度似乎依然存在。因此，业内观察家认为，用于优化和验证模型性能的训练管道和基准并不总是自然地与现实世界中的安全代码生成保持一致。⁴大多数研究将 AI 生成的代码孤立地进行评估，重点关注其正确性（即代码是否能够编译、运行并执行任务）以及在合成基准测试中的性能。⁷

但在企业开发环境中，模型并非孤立运行。GitGuardian 报告显示，编排服务、检索增强生成 (RAG)、向量存储等大模型配套基础设施的密钥泄露发生率，是大模型原生厂商平台的 6 倍。⁵

换言之，氛围编码的许多安全风险并非源自大语言模型，而在于使用模型的生态系统。新发布的推理提供商、网关、注册表和整合层进入生产工作流的速度往往过快，安全状况（或新手编程者）难以跟上。

智能体式 AI 进一步增加了安全考虑的复杂性：当授予 AI 智能体对文件、凭据存储和终端的本地访问权限时，计算机本身可能会成为另一个潜在的攻击面。提示注入和供应链攻击利用暴露的本地凭据可以引发组织风险。2025 年末，臭名昭著的 Shai-Hulud 蠕虫入侵全球最大 JavaScript 代码仓库，此次事件中遭攻陷的设备里近六成并非个人开发电脑，而是 CI/CD 管道执行节点⁴——颇具讽刺的是，这类节点本用于自动化安全检测、把控代码质量。

加剧氛围编码安全风险的一大关键因素，是 AI 生成代码的提交打包方式：使用 AI 辅助的开发人员提交代码次数平均为传统开发者的三倍，但这些提交会被合并成数量更少、体量更大的代码合并请求 (PR)。这些使用氛围编码的 PR 通常范围更大，会修改多个文件和服务。

Cursor 于 2026 年春季发布的《开发者习惯报告》指出，每个 PR 的平均代码行数同比上升了约 250%（且这一增长率本身正在加快）。Cursor 将修改代码行数不少于 1000 行的合并请求定义为“巨型 PR”；此类巨型 PR 占全部 PR 的比例，从 2025 年 1 月的 8% 攀升至 2026 年 5 月的 13.9%。⁸

覆盖代码库多处模块的大规模、碎片化合并请求，相比改动范围精准小巧的 PR，很难做到全面细致的安全评审。仅针对单一服务或代码块的改动，往往需要配套修改其他位置以规避下游故障；但若 PR 改动范围杂乱宽泛，审核人员精力被分散，这类连带衍生问题很难在代码评审阶段被发现。应用安全平台 Apiiro 的调研显示：采用 AI 辅助开发的团队，代码合并请求总量虽下降近三分之一，但上线的安全缺陷数量却是原先的十倍。³

简言之，AI 能够加快代码开发全流程，也助长了一次性大规模修改代码的不良开发习惯。代码改动集中化、迭代速度加快，也会让每次代码合并的安全风险同步聚集、快速放大。

在第 36 届 IEEE 软件可靠性工程国际研讨会 (ISSRE 2025) 上展示了一项针对 500,000 个代码样本的大规模研究，该研究确定“AI 生成的代码与人类编写的代码的不同之处不仅在于安全漏洞的数量，还在于它们的性质和分布”。

这就引出了根本性问题：现行代码质量与安全漏洞评估体系均以人工开发为核心，其设计逻辑建立在人类的思维模式、出错类型与评审流程之上。AI 生成的代码表现出明显不同的特征和趋势，这使得这些以人为本的框架不适合对其进行评估。⁷

雪上加霜的是，针对氛围编码安全风险的相关研究还发现了多种全新攻击类型，这类威胁在纯人工编写的软件中从未出现。

大语言模型及其支持的 AI 编程工具倾向于推荐实际上并不存在的软件包——研究发现，这些幻觉的软件包名称有时会在不同的场景甚至不同的模型中重复。幻觉包抢注属于依赖包幻觉攻击的一类，正是利用该漏洞趋势实施破坏。

注册抢注攻击者会观察大语言模型反复生成的虚构软件包名称，并在公共注册表中预先注册这些（以前）虚构的软件包名称。采用氛围编码的开发者往往不熟悉主流第三方依赖包，很难识别虚假包名；一旦提交包含这类包名的代码，就会在不知情的情况下安装恶意程序。

这在传统软件开发中是无可比拟的。人工开发者几乎不会凭空编造不存在的依赖包；即便偶然写错，攻击者也很难预判、猜出这个虚构包名并提前注册带恶意代码的同名包，实操层面不具备可行性。

规则文件后门攻击利用配置（“规则”）文件，这些文件在 Cursor、GitHub Copilot 和 Claude Code 等平台上生成或修改代码时用于自定义 AI 智能体行为。

攻击者通常篡改热门开源规则文件，以肉眼难以识别的隐藏 Unicode 字符植入恶意指令。一旦这些更改被接受，该恶意代码将在每个引用受感染规则文件的后续 AI 编码会话中被激活。最终，该会话生成的所有代码都会被植入恶意内容；但由于恶意载荷采用肉眼不可见的 Unicode 字符，代码评审环节看起来完全正常，难以识别异常。

攻击者的目标通常是在随后生成的代码（以及使用该代码的应用程序）中引入脆弱性和“后门”，以便稍后利用。

组织在充分掌握上述各类风险特征后，应更新安全最佳实践，既能发挥 AI 生成代码的效率优势，又可规避粗放式氛围编码带来的各类安全漏洞。

安全缺陷的隐患固然源于 AI 编码工具自身的局限性，但风险最终爆发，本质是人工监督管控缺位所致。最终，开发人员仍然可以控制接受、修订或忽略哪些添加和更改。编程助手不断扩展和改进其内置防护措施，但人工审核仍是安全漏洞上线的最后一道障碍——这也是 IBM Bob 默认设置在每个阶段集成人工审核和人工审批的原因。

尽管如此，仍有办法提升人工代码评审的有效性。

• 庞大且无序扩展的 PR 中隐藏的缺陷在安全检查中比目标更明确的 PR 中的缺陷更难发现。安全团队应据此制定 PR 规模准则。

• 需重点核查项目依赖包，最大限度防范幻觉包抢注攻击。安全团队需留意：同一 AI 模型每一轮版本更新，都可能产生全新的依赖包幻觉特征。

• 开发与安全团队均需充分区分人工编写代码和 AI 生成代码两类漏洞的差异。

组织应将 AI 生成的代码视为一个独特的输入类别，需要单独的、专用的安全控制（而不是简单地将 AI 输出集成到标准的、以人为本的审查流程中）。

作为一条普遍原则，组织应该像对待外部库代码一样，将任何 AI 衍生的代码或模块视为不可信的输入。所有 AI 生成代码并入代码库前，必须经过静态应用安全测试 (SAST) 关卡校验。各类第三方规则文件（开源预置 Cursor 规则、Claude.md 文件、Copilot 配置指令、Bob Modes 等）必须经过全面核查，仅将安全文件选择性加入白名单，不可默认放行。

智能自主开发平台持续迭代，企业可借力 AI 驱动的密钥检测工具以 AI 治 AI；针对大模型接口密钥、向量数据库令牌等 AI 专属凭据，该工具配备专用识别特征库。

例如，IBM Bob 拥有内置工具，可以通过 Bob 自定义模式、HashiCorp Vault 集成和 IBM MCP 网关的组合来大规模执行安全编码和访问控制。该工具同步支持实时代码评审，可扫描代码中的逻辑复杂度问题、潜在安全漏洞及代码重构优化点，相关问题可就地处理，也能后续在 Bob Findings 对应面板统一核查。

捕获代码库中新引入的缺陷的能力在很大程度上取决于该代码库的可读性。因此，建立和执行代码质量标准对于促进生产性安全评审至关重要。共享的标准和例行重构将最大限度地提高不安全代码被识别和解决的机会。