你以为AI代码审查比人更客观？Manifold Security的测试证明恰恰相反——它可能比人类更容易被"熟人"骗过。
Git身份伪造：一个老问题撞上AI新场景
Git的提交元数据从来不难伪造。设置个假的作者名和邮箱，两行命令搞定：
git config user.name "知名维护者"
git config user.email "trusted@example.com"
这不是漏洞，是设计取舍。Git诞生于协作信任的小圈子时代，身份验证靠外部工具（签名、SSH密钥）补充。二十年来，这个"特性"没造成大规模灾难，因为人类审代码时会交叉验证：这人平时写什么风格？这个改动是否符合他的专长领域？
但AI审查工具把这套直觉扔了。
Manifold Security的测试直指核心：当Claude（Anthropic的大语言模型）被配置为"自动批准知名行业传奇人物的PR"时，伪造身份的恶意代码直接通过。模型没有质疑"为什么这位维护者突然提交了一个风格迥异的补丁"，它只是看到了一个信任信号，然后执行了预设规则。
「开源项目维护者被PR淹没，为知名可信人物自动开启审查绿色通道，动机可以理解。」Manifold在报告中写道，「但这制造了一个假设：作者身份可以照单全收。」
信任链的断裂：从OpenClaw到Claude
Manifold把这个案例与近期的OpenClaw Cline包污染事件并置。后者是攻击者向可信环境注入恶意包，前者是伪造身份让AI主动放行。表面不同，底层逻辑一致：来源可信≠内容可信。
人类审查员的优势在于不一致性——会累、会好奇、会对"不对劲"产生直觉。AI审查员的优势是规模，代价恰恰是这种不一致性的消失。它不会在某天下午突然想："等等，这位维护者从不碰这部分代码。"
更隐蔽的风险在现实配置中。Manifold的测试用了显眼的"行业传奇"规则，实际生产环境更常见的是：组织成员检查、历史贡献统计、维护者名单匹配。这些机制同样脆弱——它们验证的是Git元数据，不是真人。
「开源库越来越依赖AI工作流工具自动审查和批准PR，但这些智能体极易被欺骗，为威胁行为者绕过安全控制、污染流行代码库创造机会。」Manifold警告。
五个要点：为什么这事值得技术人警惕
1. 这不是Claude的"bug"，是信任模型的错位
Claude按规则行事。问题出在把"作者字段匹配"等同于"真人验证通过"。任何大语言模型在同样配置下都会中招，这不是Anthropic独有的缺陷。
2. Git签名不是可选项，是AI时代的必选项
GPG签名或SSH签名提交从未像今天这样重要。它们把身份验证从"字符串匹配"提升到"密钥持有证明"。AI审查工具如果读取签名验证状态，伪造攻击的门槛会从"两行命令"跃升到"窃取私钥"。
3. "自动批准"规则需要多重锚点
单一信号（作者名）= 单点故障。可靠的自动批准应该组合：签名验证 + 代码变更范围（是否触及敏感路径）+ 与作者历史贡献模式的偏离度检测。这些不需要AI，传统规则引擎就能做。
4. AI审查的定位应该是"初筛"而非"终审"
把AI当成节省人力的第一层过滤，而非替代人类判断的终审法官。高风险变更（修改CI配置、引入新依赖、变更权限相关代码）必须强制人工复核，无论作者是谁。
5. 供应链攻击的入口正在向AI工作流迁移
传统供应链攻击瞄准依赖包（npm、PyPI），现在多了一个维度：直接污染上游仓库。如果AI工具被广泛用于自动合并PR，攻击者可以跳过"发布恶意包"的步骤，直接把恶意代码写进项目主线。
guardrails不能活在模型里
Manifold的结论很直白：如果系统层面没有验证"谁做了什么"，坏代码不会被建议——会被推送。
这句话值得贴在每个引入AI代码审查的团队墙上。大语言模型没有原生的事实核查机制，它的"信任"是训练数据里的统计关联，是提示词里的规则注入。把这些当成安全边界，就像把门锁密码写在门牌上。
技术社区正在快速把AI嵌入开发流水线，这个过程中有太多"先跑起来再说"的妥协。Git身份伪造是个老问题，但AI的规模化、自动化特性让它从"需要社会工程学配合的攻击"变成了"可批量复制的攻击模板"。
好消息是防御手段成熟且免费：签名提交、分支保护规则、强制代码所有者审查。坏消息是这些措施需要人为配置，而配置的人可能正忙着用AI生成更多代码。
最后说个冷笑话：以后面试问"怎么保证代码安全"，回答"我们用AI审查"的，和回答"我们信任作者字段"的，可能得分一样低。
热门跟贴