为什么仅依赖Claude进行代码安全审查在团队扩张时会失败

Source: Dev.to

介绍

第一次在拉取请求上看到 AI 评论时，反馈循环会让人印象深刻。完整的审查在几秒钟内出现，在人工审阅者甚至打开文件之前就指出潜在问题。使用像 Claude 这样的工具进行 代码安全审查——SDLC 中安全的关键环节——的吸引力显而易见：提前捕获问题，减轻团队的手动工作负担。

然而，在实际使用中，这种速度常常会产生 虚假的安全感。起初效果不错，但随着团队规模扩大、系统变得更复杂时，这种效果就会开始崩溃。

关键盲点

一次好的安全审查依赖于 不在 diff 中 的上下文。这些上下文存在于孤立代码之外。由于本质上 LLM 无法访问 这些信息，它只能在孤立的代码片段上进行分析，因而错过了实际中最严重漏洞往往所在的更广阔视角。

容易被忽视的架构与数据流风险

• 许多关键安全缺陷并不在代码本身，而在 组件之间的数据流动 中。
• LLM 并不知道系统的 信任边界。例如，它可能不知道 UserService 仅限内部使用，或任何来自公开暴露的 APIGateway 的数据都必须重新验证，即使之前已经做过验证。

示例：跨租户授权缺陷

1. 开发者新增了一个端点，正确检查了用户是否拥有 admin 角色。
2. 仅从 diff 看，代码似乎没有问题。
3. 高级工程师知道一条隐式系统规则：租户 A 的管理员绝不能访问租户 B 的数据。代码 没有 检查租户 ID。

Claude 不会标记此问题，因为它不了解你的多租户模型或围绕数据隔离与敏感性的内部规则。它只看到有效的角色检查并继续前进，导致潜在的跨租户数据泄漏被忽略。

忽视仓库历史与威胁演变

• 代码库是 活文档。提交记录、Pull Request 和事件报告的历史蕴含着宝贵的安全上下文。
• 人类审查员可能记得过去一次涉及特定数据模型的输入验证不完整的事故，并对类似的改动保持高度警惕。LLM 没有这种记忆。

示例：重新引入已知的 DoS 漏洞

# 六个月前
- 通过对自由文本字段添加硬性大小限制，修复了拒绝服务问题。

# 新的改动
+ 新增了类似的自由文本字段，但省略了大小验证。

代码在语法上是正确的，但它 重新引入了已知的漏洞模式。有经验的审查员会立刻发现；而 LLM 只看到新代码，无法获取过去的经验教训。

无法学习团队特定的安全策略

每个工程团队都会制定自己的安全约定和策略，这些往往是领域特定的，并不总是显式写在代码里。

LLM 可能无意中提出 直接违反 这些规则的方案，给审查员带来额外工作——他们必须同时修正代码 和 AI 的建议。LLM 那种自信、权威的语气会让初级开发者误以为其建议就是最佳实践，即便它们与已确立的标准相冲突。

可扩展性陷阱：当大语言模型的局限性叠加

对于一个小团队在单体项目上工作时，这些缺口或许还能应付。但当组织尝试在不断壮大的团队、更多工程师、更多服务以及更多微服务之间推广代码审查时，这些限制会产生系统性问题，仅靠自动化无法解决。

人工验证瓶颈

• 审查 AI 自己的输出 成为一项新任务。
• 在源源不断的低影响或无关建议面前，工程师很快会产生 警报疲劳，并把 AI 评论当作 linter 噪声——容易被忽视的东西。

实际上，每条 AI 生成的评论仍需有人评估其有效性、影响和上下文。这会拖慢审查速度，并把注意力从真正重要的事项上转移。过滤 AI 噪声的认知负荷往往会抵消捕获少数明显问题的收益。

基于 LLM 的代码安全审查中的架构理解缺口

• 在分布式系统中，最危险的 bug 通常出现在 服务之间的交互 中。
• LLM 在审查单个仓库的变更时 看不到 该变更可能破坏下游消费者的隐式契约。

示例：破坏 JSON 合约

- "userId": "12345",
- "email": "alice@example.com",
+ "userId": "12345"

删除 email 字段可能导致依赖该字段的其他团队服务出现静默失败——这是 LLM 检测不到的。

• 同样的情况也适用于密码学错误。LLM 能标记显而易见的问题（例如使用 DES），但往往会遗漏更难检测的缺陷，如 在块密码中重复使用初始化向量（IV）。识别此类问题需要了解应用状态和跨多个请求的数据流，远超对代码片段的静态分析。

幻觉

LLM 可能 以极大自信给出错误答案。常见的情况包括：

• 推荐根本 不存在的 安全库。
• 对真实 CVE 细节的错误解读。
• 将错误的代码片段呈现为“修复”。

在安全领域，这尤其危险。开发者可能接受看似合理却错误的解释，进而 引入新的漏洞。

要点

1. AI 可以加速低层次的语法检查，但它无法取代人工审查者带来的上下文、历史和架构洞察。
2. 将 AI 建议视为 建议，而非权威——始终根据团队的政策、系统设计和威胁历史进行验证。
3. 投资能够 增强 人工审查者的工具（例如数据流分析、策略即代码、溯源追踪），而不是仅仅依赖 LLM。
4. 建立明确的 防护栏：
   • 将团队安全政策以机器可读的格式显式编码。
   • 将 LLM 输出与现有的静态分析和运行时安全工具集成。
   • 提供反馈回路，使模型的建议随时间改进而不产生幻觉。

通过认识到基于 LLM 的代码安全审查的 关键盲点，并设计将 AI 速度与人工深度相结合的流程，团队可以在保持强大安全姿态的同时，收获自动化的好处。

在修复其他漏洞时引入新漏洞

在尝试修复一个漏洞的同时产生新的漏洞，会产生一种错误的自信感。这会削弱学习，并可能导致比原始问题更糟糕的安全结果。

为什么人类专业知识仍然重要

• AI 工具有价值，但它们应该 增强 人类判断，而不是取代它。
• 人类审阅者带来机器无法提供的关键上下文。

超越语法：业务逻辑与意图

资深工程师理解代码背后的 原因。他们能够将提议的更改与业务目标关联，并提出 LLM 永远不会考虑的关键问题，例如：

“如果用户上传的文件名超过 255 个字符，会发生什么？”
“这个新用户权限是否符合公司 GDPR 合规要求？”

这种对现实影响的推理是良好安全审查的基础。

导师制与构建安全文化

• 代码审查是团队内部知识传递的主要机制。
• 当高级工程师指出安全缺陷时，他们不会仅仅说 “这不对。” 他们会：
  1. 解释风险。
  2. 引用过去的决策或内部文档。
  3. 将审查作为学习的机会。

结果是整个团队的安全意识得到提升，形成共享责任的文化。自动化机器人评论则没有这些——它感觉像是要清除的另一个检查清单项目。

混合审查模型

目标不是拒绝新工具，而是有意识地使用它们。健康的安全姿态 使用自动化来增强人类判断，而不是取代它。

增强而非取代：LLM 适用的场景

在代码审查中，LLM 的最佳使用方式是作为 第一次自动化审查，针对非常特定的一类问题。例如：

• 硬编码的密钥和 API 密钥
• 使用已知的不安全库或函数（例如 C 语言中的 strcpy，Python 中的 pickle）
• 表明 SQL 注入或 XSS 的常见模式

LLM 的输出应视为 建议，而非裁决。最终权威仍由人工审查员掌握。

投入上下文

要从 LLM 获得持续有用的结果，需要在提供正确上下文方面进行大量投入，例如：

• 架构图
• 数据流信息
• 内部团队政策

这些输入通常需要高级提示工程实践，并且必须保持最新，形成持续的维护负担。在将 LLM 设为 CI/CD 的强制步骤之前，必须了解其成本及其限制。

培养强大的安全姿态以实现规模化

归根结底，强大的安全文化依赖于 人为判断。自动化非常适合处理简单、重复且与上下文无关的任务，从而让有经验的工程师能够专注于复杂、依赖性强的风险——在这些场景中，经验才是真正重要的因素。

在自动化效率与了解系统的人的判断之间取得平衡，是构建真正可扩展的安全实践的唯一途径。