★ FEATURED ARTICLE 这两年AI编程工具已经成了开发流水线上绕不开的一环。我见过太多团队把AI当成超级实习生——补全功能、写单测、搭脚手架确实快但一到线上出事故第一反应不是修bug而是争一个问题这段AI生成的代码到底谁来背锅我自己也在用AI写代码主力编辑器里带AI痕迹的代码大概占了三分之一。但正因为用得深AI编程安全这个问题就越绕不过去。AI生成的代码在线上泄露了数据、被注入了漏洞、甚至因为一个编造出来的依赖包被供应链攻击这锅是使用者的、提示词写作者的还是模型厂商的这篇文章不喊口号也不劝你别用AI——那不现实。我想用几个高频事故场景结合底层原理把AI代码为什么容易出事讲透再聊聊责任归属的现实逻辑最后给出一套我实际落地过的审查机制和团队红线。无论你是开发者、技术负责人还是需要给AI代码做安全兜底的人都值得看完。1. 我见过最典型的AI代码事故从看着没问题到线上故障1.1 加密逻辑长得好看用着致命先说一个我印象最深的例子。前阵子一个朋友负责的项目要给用户敏感字段做加密存储他用AI生成了一个AES/CBC/PKCS5Padding的实现代码结构非常工整注释也齐全一眼看过去专业性拉满。但细看就发现问题AI把每次加密必须随机生成的IV初始向量直接写死成了一个固定值。// AI生成示例固定IV是重灾区 private static final byte[] IV new byte[] {0x00, 0x01, 0x02, ...省略...}; Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); cipher.init(Cipher.ENCRYPT_MODE, secretKey, new IvParameterSpec(IV));固定IV意味着什么相同明文加密后得到完全相同的密文。一旦数据库泄露攻击者可以直接做字典比对——这个加密约等于没加。这类问题静态扫描工具其实能扫出来但很多项目是在集成扫描之前就上了线等发现的时候数据已经导了好几轮殃及的用户都开始投诉了。更普遍的是硬编码密钥、AES-GCM的nonce复用、随机数用Math.random()这类代码本身没有语法错误、单测能跑通的安全债务。AI之所以高频踩这些坑是因为它在训练语料里见到的教程级示例普遍把IV写死、把密钥写进源码它自然觉得这是合理写法。要命的是AI生成结果在格式上实在太工整了很多reviewer看一眼缩进和注释质量就下意识放行——这是一个心理陷阱我们倾向于用代码看起来是否专业来评判安全性但安全恰恰藏在AI看不见全局、又特别容易想当然的细节里。1.2 一本正经地发明依赖依赖幻觉事故第二个典型事故跟依赖供应链有关而且更难防。某后端服务的requirements.txt里凭空多了一个包名字叫authlib-oidc跟官方authlib只差一个连字符和后缀。开发同学没多想就pip install了结果拉下来的是一个抢注了相似名字的恶意包包里藏着回连远程服务器的代码。这就是业内常说的依赖幻觉——AI在生成代码时更关注语法上合理的import语句而不是这个包是否真实存在于远端仓库。我自己也踩过类似的坑。让一个AI助手写一段LDAP认证代码它给了我一个叫ldap3plus的包我本能地多看了一眼发现根本没有这个官方包真正的名字是ldap3。那个多出来的plus后缀包恰好是某个抢注者提前注册的。我当场倒吸一口凉气——如果当时直接复制运行等于亲手往生产环境里装了一个身份不明的第三方包。这事的本质是AI对依赖名的记忆来自训练语料而训练语料里正常的包名和typosquatting攻击的案例混在一起它分不清哪个是教程里提到的哪个是已经被攻击者抢注的。单个开发者一年可能才遇到几次但大规模使用AI的团队这种事件会周期性出现每次都在给供应链安全埋雷。1.3 业务逻辑偏差比漏洞更隐蔽第三种事故不用漏洞扫描器都扫不出来但经济损失通常更大——业务逻辑偏差。比如AI写查询最近30天订单的接口很自然地用了now() - interval 30 day而订单表里存的是UTC时间前端展示用的是东八区。单测全绿因为测试数据都填在同一时区。等跨月、跨年、夏令时这类边界条件一碰统计报表错得离谱财务拿着对不上账的订单数来拍桌子你才知道出了问题。还有一个经典场景是库存扣减。AI生成的秒杀扣库存代码注释里写着乐观锁安全但实际实现用的是UPDATE products SET stock stock - 1 WHERE product_id ?既没有版本号校验也没有AND stock 0的兜底条件。低并发测试跑不出来问题一上秒杀流量就超卖。这类问题你很难说AI写的代码有bug因为在merge环节是人有逐行review义务的——但人确实很容易被AI那种看起来很顺滑的回答催眠。这几个事故的共同特点不是AI太笨恰恰相反是AI太顺滑顺到让人放松了本该有的警惕。这才是AI编程安全的核心矛盾。2. 为什么AI生成的代码天生欠着安全债模型机理与依赖链的双重风险2.1 概率生成决定了貌似正确是常态想弄清楚AI代码为什么容易出事得先理解大模型生成代码的底层逻辑。它不是一个查表系统不会去数据库里翻你线上有几千条数据、并发有多高。它在做的是逐token地最大化这段代码看起来像正确代码的概率。换句话说AI优化的目标是形式的合理性而不是语义的正确性。打个比方一个擅长写议论文的人能写出结构完整、措辞漂亮的文章但里面的论据有没有真实查证过他并不负责。代码也一样——AI生成的函数循环、分支、异常处理的骨架往往比新手写的还规范但那个骨架背后隐含的假设比如用户一定是登录状态密钥放这里没人能读到这个接口只被内部调用它根本没能力验证。这些未被验证的假设就是安全债的起点。2.2 训练数据把历史漏洞原样复制第二层风险来自训练语料本身。代码大模型几乎都建立在GitHub公开仓库、技术博客、Stack Overflow问答之上这些数据的共同特点是——包含海量的过时写法和已公开漏洞。比如早年PHP的mysql_*函数、很久以前流行的eval拼接、各种教程里写了但早该废弃的加密模式在训练语料里都被当成正常代码存在。模型不判断新旧只判断这在语料中是不是常见。于是AI会脸不红心不跳地生成一串十年前就该淘汰的API调用还附带一行这是行业标准做法的注释。我甚至见过AI生成的Node.js代码里带Math.random()做验证码这要是被安全组抓到妥妥一个高危漏洞。这跟人抄代码是一样的你抄了一堆老博客的代码自然把老博客的坑一起抄进来了。区别在于人看到过时API可能会警觉AI不会——它连这玩意儿可能已经有CVE的概念都没有。2.3 上下文窗口限制没有全局视野再往深处说一层。即使AI生成的那段代码本身没漏洞在一个大型系统里安全是强上下文相关的。一个函数是否安全要看它被谁调用、参数来源在哪、数据经过哪些流转、有没有做权限校验。AI只能看到当前文件或者当前对话窗口里的内容它没法建立完整的调用链安全模型。我记得有个项目让AI写导入用户的接口它生成的代码里用到了RequestParam接一个文件名参数直接拼到文件路径里做读取。单看这个接口你可能会说这是路径穿越漏洞。但为什么AI会这么写因为它没看到这个服务的网关层已经做了统一的路径清洗。反过来更多情况下AI是看不到网关层的存在默认所有来得请求都是可信的。跨模块的权限校验、速率限制、日志脱敏这些全局性安全控制AI大概率会漏。这不是调几个参数能解决的是模型结构上的先天缺陷。2.4 提示词里的意图缺口也在制造漏洞还有一个容易被忽略的源头提示词本身就带着安全缺口。用户说给订单模块写个导出功能AI在训练语料里见过的导出demo大概率长这样——一个没有鉴权的下载链接点开就下载CSV。它不会主动加上仅管理员可导出的权限校验除非提示词里明确写了。换句话说AI没有安全默认值的概念。它的默认倾向是从主流示例里学来的最小可用而不是最小权限。提示词写得不精确AI就在安全维度上自由发挥而这个自由发挥通常都不太安全。3. 真出了事背锅的到底是谁责任链条的现实答案3.1 最直接的承担者合入代码的人无论代码是AI生成的、还是人一行行敲的线上系统出事最先被追责的永远是部署这个系统的企业或开发者。合同层面客户为你的服务付费你交付的软件必须符合约定的质量和安全预期数据泄露事故一旦发生面对监管和用户质询的也是运营方不是什么AI模型。这一点特别像第三方组件出事时的责任划分你引用了某个开源库它爆出高危漏洞最终被点名批评、被要求修复的是你的产品而不是那个开源库的某个维护者。AI代码同理它只是你引入的又一层第三方产物集成方必须为最终结果负责。这是AI写的在责任认定上不是免责金牌。3.2 AI工具厂商的条款是怎么设计的我也专门翻过几个主流AI编程工具的服务条款。几乎无一例外这类工具会把输出内容的使用后果完全划给用户不承诺生成代码无漏洞、不承诺无侵权风险、甚至对输出的可用性都不做担保。这在商业逻辑上合理——如果AI厂商要为每一段代码的缺陷负责这个商业模式根本撑不起来。但这也意味着指望AI厂商赔钱基本是幻想。你唯一能落地的保护是把AI生成的代码当成一条需要走完整测试、扫描和评审流程的PR来管理而不是免检提交。我见过一些团队把AI生成的代码直接推送主干连CI都不跑这等于把安全责任主动扔出去了。3.3 开源许可证风险代码算谁的还没定论责任链条里还有一条经常被忽视的线——许可证。AI训练语料里有大量GPL、AGPL等强传染性许可证的开源代码模型在生成时可能产出一段与某个受保护代码高度相似的结果。这在法律上仍处于非常模糊的地带但保守的做法已经出现不少闭源商业项目开始规定高风险复杂模块不允许AI生成生成后必须人工重构。这不是危言耸听。公开报道里已经有开源项目因为AI生成代码与受保护代码相似而被要求下架的先例。也就是说即使代码不出安全漏洞它还可能带来版权层面的合规风险。这一层锅最终也是落回使用AI的组织头上。我在实际操作中建议如果你的项目是闭源商业化AI生成的高复杂度算法模块至少要经过一次深度人工重构别让生成结果原样留在仓库里。3.4 团队内部的追责避免翻AI旧账的内耗说点更务实的。比起外部责任团队内部怎么定义责任更重要。我见过一些团队一出事就翻git blame看到commit作者是Copilot就急着划分责任这是最内耗的做法。健康的逻辑应该反过来不区分AI写的和人写的统一定义为合入代码的人对代码负责。同时把审查、测试、扫描这些环节放在AI生成的必经之路上让风险在上线之前就被兜住而不是等出了事故再分锅。一句话责任阀门的材料是流程不是事后追溯。谁merge谁负责谁发布谁承担先把这句话刻在团队协作规范里。下面这张表是我在团队里用来对齐责任认知的可以当参考事件参与方常见免责逻辑现实风险兜底措施写提示词的人我只是让它生成没让它上线提示词是需求的源头意图缺口最终变成漏洞关键功能提示词必须有安全约束词合入代码的开发者CI都绿了AI写的我没细看merge是一次明确的人类决定强制人工review 安全清单代码审查人只看了逻辑没看依赖和加密审查视角落后于AI风险分布更新review清单纳入AI特有风险项AI工具厂商我们只是生成工具不负责使用后果条款明确免责索赔无门别把AI当担保方风险自担开源许可证受让方我都不知道它抄了哪段侵权指控落到组织头上高风险模块人工重构生成结果做溯源最终用户/客户我是受害者经济损失和信任危机由运营方扛上线前漏洞扫描保险应急预案4. 把AI代码驯化成生产级代码我落地的一套审查机制4.1 静态扫描和依赖审计是最低门槛前面说了那么多风险解决办法不是不用AI而是给AI的生产过程装上护栏。我强烈建议团队至少先接两套工具一套静态应用安全测试SAST一套软件成分分析SCA。我在团队里强制接入的是这样一套组合环节工具示例必须扫什么拦截阈值SASTSemgrep、CodeQL、SonarQube固定IV、ECB模式、eval、SQL拼接模板、硬编码密钥高危问题直接阻断CISCA依赖审计npm audit、pip-audit、OSV-Scanner全部直接和传递依赖含许可证类型漏洞等级High及以上直接失败镜像扫描Trivy、Grype基础镜像中的CVE、非预期文件中危以上告警高危阻断密钥扫描Gitleaks、TruffleHog提交历史里的API密钥、token、连接串一旦发现立即撤回推送CMake里的find_package、Go的go.mod、Python的requirements.txt、npm的package.json全部进入SCA扫描范围。我见过太多我本地编译能过上了CI就挂的案例多半是依赖解析环境不一致导致拉错了包。SCA工具能帮你把AI幻觉出来的依赖在CI阶段就拦下来。4.2 威胁建模让AI代码过一遍攻击者视角工具只是第一步真正能兜住AI默认行为错误的是威胁建模。我会给AI产出的每一项高危功能——认证、支付、文件上传、导入导出、优惠券——单独补一张威胁建模表问五个问题资产是什么攻击者最想拿到什么攻击面在哪哪些接口是外部可达的有哪些隐含假设比如调用方已登录参数来自可信源需要哪些安全控制鉴权、限流、输入校验、审计日志如果控制缺失最坏的影响是什么这个方法能发现比例相当高的AI默认错误。我印象最深的是一个文件导出功能AI生成的接口默认所有人都能下载威胁建模时明确标出假设只有管理员可访问然后一查实际权限配置发现模型根本没往鉴权方向想。如果没有这一步这就是一个数据泄露漏洞。4.3 人工Code Review的重心要转移过去code review看重逻辑正确性和代码风格有了AI之后这远远不够。我要求团队做review时必须加三件事第一逐行核对import来源和依赖名。AI编写的import语句凡是第三方包必须确认在远端仓库真实存在且名称没有可疑后缀/连字符变体。第二检查数据校验是否发生在不可信边界。AI经常把校验放在service层而边界应该放在Controller、API网关或者反序列化入口——最迟要在数据进入业务逻辑之前完成类型、范围、格式校验。第三对AI生成的加密、反序列化、正则相关代码默认走极不信任流程。这类代码历史漏洞最密集AI踩坑概率最高需要安全组成员专门复核。不是说不信任AI的每一行代码而是这类高风险代码值得更高的检查优先级。4.4 一份可以直接抄进review模板的AI代码安全清单我把我常用的检查项整理成了一份清单团队内部直接当review模板用这个依赖包名是真实存在的吗有没有近似的抢注名加密用的密钥和IV是随机生成、独立存储的吗有没有硬编码外部输入是在不可信边界完成校验的吗还是下沉到了service层异常处理会把SQL、内部IP、堆栈信息带出去吗文件上传有没有做扩展名/内容类型/大小限制的多重校验接口需要鉴权吗默认逻辑是拒绝还是放行有没有对批量操作做数量限制和速率限制日志里有没有可能打印token、密码、身份证号反序列化有没有指定允许的类白名单缓存键的构造方式会不会导致信息越权4.5 给人机混合代码打标记的经验关于是否要标记AI生成的代码我做过实验。一开始我们在commit message里加[ai-generated]标签用GitHub Action自动把这类PR分派给安全组优先review。试了一段时间发现成员反馈心理暗示太强反而降低了对普通代码的警惕——大家都去看AI代码了普通代码反而成了被忽略的角落。于是我们改成了现在的做法弱化标记、强化流程。所有PR都走同样的安全检查但重点文件认证、支付、文件上传、密码重置强制指定专人review不管是人写的还是AI写的。标记只保留在可视化统计面板里用来观察AI产出比例不再做信任分级。这个调整之后整体的安全意识反而更均衡了。5. 容易被忽略的细节提示词中的安全信息披露与团队红线5.1 提示词不要把密钥和内部拓扑喂给AI有一类风险不在代码里而在提示词里。很多人习惯把公司内部API文档、数据库schema、甚至access token直接贴进AI对话框。这里有几个问题你用的工具可能把对话记录存进日志或者用于模型改进即使选用企业版你的内部数据也已经出了自己的安全边界。我自己经历过一次同事在debug时把一个内网PostgreSQL连接串贴进了对话窗口里面带着账号密码。虽然最终没出事但这个习惯比代码bug更危险——因为代码bug还能被扫描器拦下来提示词泄露则完全没有审计痕迹。我的建议是提示词里只给脱敏后的最小上下文敏感字段用占位符。比如要AI写数据库查询就把表结构里真实字段名换成col1、col2这种占位等生成完再替换回来做人工确认。顺带说一句如果团队做的是保密项目应该考虑使用私有化部署的本地模型把推理过程留在自己的网络环境内。这个方案能显著降低提示词外泄风险但要注意本地模型同样要有权限管理不是部署了就万事大吉。5.2 AI生成代码的适度信任边界不少用过AI的人会感觉它写的异常处理比我写的全这是事实。但AI生成物没有信誉积累——它这次帮你写出一个完美无缺的并发安全函数不代表下次不会在加密上翻车。把AI当固定水平的外包人员是不对的它的水平呈脉冲式波动关键模块可能很强细节上又可能把密钥写死。我的经验是把AI当一个能力很强但容易在关键处犯错的实习生来管理。信任边界应该划在我能理解并覆盖它全部假设的地方而不是它看起来正常的地方。如果一段AI生成代码的假设条件你讲不出来那它就不该进生产环境。5.3 团队红线四类代码建议禁止交给AI实际操作下来我觉得有这几类代码是应该画红线禁止AI生成的加密、数字签名、随机数生产。这类代码有完整的安全生命周期和规范要求AI输出大概率带着历史旧习。支付金额、优惠券、抽奖概率等业务计算。AI的边界幻觉在业务正确性上尤其致命少一个AND stock 0就是真金白银的损失。认证、鉴权、会话管理。AI的默认配置往往是不安全的——默认放行、默认不校验、默认无过期时间。反序列化、复杂正则、XPATH处理。历史漏洞密集区AI容易沿用过时写法。不是不能碰而是这些场景的风险收益比不合理AI带来的效率提升有限但踩坑成本极高。5.4 一个实际的推行路径如果团队想落地AI编程安全治理不必一步到位。我建议的顺序是先接入SAST和SCA并定好拦截阈值让工具兜住最底线的漏洞。再定义关键目录必须人工review认证、支付、上传相关文件的PR强制安全组签名。然后给管理层开一个权限审计面板能看到AI生成代码的分布和漏洞率趋势。最后慢慢推全员安全清单和提示词规范。先工具后流程、先护栏后文化这样落地的阻力最小也不会让团队觉得又多了一堆流程要跑。我在实际项目中体会到的一点是AI编程安全问题的核心与其说是谁背锅不如说是一个组织愿不愿意为AI参与生产的透明度埋单。给它逐行review的耐心、给它跑全套安全扫描的资源、给它明确的责任边界这些投入最终都会省下更大的线上损失。最后分享一个小习惯我每次让AI写完代码后都会多追问一句这段代码在哪些情况下是不安全的。用它的回答反过来校准上面的安全清单。多数时候AI的自我审视会暴露第一版里我没注意到的edge case——这也算是跟AI协作的一种止损方式吧。
阅读完成 · 觉得有帮助？
