Claude 代码安全审查流程：从 PR 检查到漏洞风险清单

Claude 做代码安全审查，适合放在“上线前多一道语义检查”这个位置。

它能帮开发团队更快发现一些传统规则扫描不容易描述的问题，比如认证逻辑遗漏、输入校验缺失、敏感信息处理不当、权限边界混乱、异常处理过宽。Anthropic 官方的 Claude Code Security Review GitHub Action 也把方向说得很清楚：用 Claude 分析代码变更，给 PR 提供上下文相关的安全分析。

但它不应该单独决定能不能上线。AI 审查有误报，也会漏报；更麻烦的是，Claude Code 这类工具一旦接入 GitHub Actions、MCP、内部 API，就会碰到 token、权限、prompt injection 和供应链风险。最近围绕 Claude Code GitHub Action 漏洞的讨论，也提醒团队：AI 安全工具本身也要被安全审查。

所以工程上更实用的方案是：传统扫描先跑，Claude 再做语义审查，最后由人确认。

适合 Claude 看的几类问题

第一类是鉴权和越权。

很多越权问题不是 grep 一个关键词就能发现。比如接口里验证了登录态，但没有验证资源归属；管理端接口复用了普通用户权限；多租户场景里只按 user_id 查数据，没有 tenant_id。Claude 这类模型的优势在于能把控制器、service、DAO 和路由上下文串起来看。

第二类是输入验证。

常见问题包括 SQL 注入、命令注入、路径穿越、反序列化、模板注入、SSRF。传统 SAST 能覆盖不少，但在业务代码包装得比较厚时，语义模型有时更容易看出“这个参数最终进入了危险调用”。

第三类是敏感信息。

比如日志打印 token，错误返回里带内部堆栈，测试配置混入生产密钥，Webhook 签名校验过于宽松。这类问题很适合让 Claude 在 PR diff 里做一次“上线前阅读”。

第四类是依赖和供应链。

这里不要指望 Claude 替代 Dependabot、Snyk、Semgrep 或 Trivy。更好的用法是：先把依赖扫描结果喂给模型，让它结合项目实际调用路径判断风险优先级，生成“哪些必须今天修、哪些可以排期”的解释。

推荐流程

1. PR 创建后先跑确定性工具

先跑 lint、单元测试、依赖漏洞扫描、secret scan、SAST。

这些工具输出稳定、可重复，适合做硬门禁。Claude 不应该替代这一步。AI 更适合解释复杂上下文，而不是承担全部规则检测。

2. 把 Claude 放在语义审查环节

可以用 Claude Code 的/security-review做本地审查，也可以用 GitHub Action 在 PR 上自动触发。

审查输入建议控制在这些范围内：

• PR diff
• 相关路由、鉴权中间件、数据模型
• 本次变更涉及的依赖扫描结果
• 项目安全约束，例如“所有多租户查询必须带 tenant_id”
• 输出格式模板

不要把整库无差别塞进去。大型仓库要按模块拆，否则上下文成本高，审查结果也容易发散。

3. 输出结构化风险清单

建议让 Claude 输出固定字段：

{"risk_level":"high | medium | low","category":"auth | injection | secrets | dependency | logging | config","file":"src/api/user.ts","line_hint":"around line 42","why_it_matters":"当前接口只验证登录态，没有验证资源归属","suggested_fix":"在查询条件中加入 tenant_id，并补充越权测试","needs_human_review":true}

固定格式有两个好处。第一，方便写入审查系统或工单；第二，减少模型写长篇解释，把注意力放到可执行问题上。

4. 高风险项必须人工确认

AI 审查不是免责工具。高风险问题应该由安全负责人或资深开发确认，尤其是支付、账号、权限、企业数据、日志系统和后台管理接口。

如果 Claude 给出修复建议，也不要直接合并。修复代码至少要过测试、review 和二次扫描。

一个可落地的 Prompt 模板

你是代码安全审查助手。请只审查本次 PR 变更，不要泛泛解释安全常识。 项目约束： 1. 所有多租户数据访问必须校验 tenant_id。 2. 所有外部输入进入 SQL、shell、文件路径、URL 请求前必须经过白名单或安全封装。 3. 日志不得输出 access token、refresh token、API key、手机号全文。 4. 管理端接口必须验证 admin scope。 请输出 JSON 数组，每个风险包含： risk_level、category、file、line_hint、evidence、suggested_fix、test_case。 如果没有发现高可信风险，请输出空数组，并说明还需要人工检查哪些点。

这个模板的重点不是“让 Claude 更聪明”，而是把审查边界收窄。边界越清楚，误报越少。

国内团队接入时的限制

国内团队最先遇到的通常不是模型能力，而是接入条件。

Claude 官方 API 在国内访问会受到网络、账号、支付、组织验证、服务稳定性和合规评估等因素影响。企业如果要把代码、日志、依赖清单发给境外服务，还要先确认数据出境、内部代码保密、供应商准入和审计留痕要求。很多团队测试时能跑通，到了采购和生产阶段卡在结算、发票、备案、专线、SLA 和权限审计上。

还有一个现实问题：Claude Code、GitHub Action、X 上的安全讨论和 GitHub 仓库资料，国内访问不一定稳定。安全工具一旦进入 CI/CD，网络抖动会直接影响研发流程。

如果团队只是做 POC，可以先用隔离仓库、脱敏代码和少量 PR 试验。进入生产后，建议把模型调用统一放到企业 API 网关后面，做日志、限流、脱敏、预算和回退。

词元无忧 API 可以放在哪一层

词元无忧 API 更适合放在“模型接入层”。

对已经有 OpenAI 调用经验的团队，统一 base_url 和兼容接口能降低迁移成本。代码安全审查场景里，可以把 Claude Opus 4.8 用于复杂语义审查，把 GPT-5.5 用于交叉复核或报告重写，把其他模型用于低成本摘要。词元无忧 API 聚合 GPT、Claude、Gemini 等主流模型，支持人民币相关结算、按量计费、专线优化和国内 cn 域名备案，对企业 POC 和生产接入会省掉不少非技术摩擦。

这里的关键不是“换个渠道调用模型”，而是让研发平台能统一记录：谁在什么 PR 上调用了哪个模型、花了多少、输出了哪些风险、有没有人工确认。

最后

Claude 做代码安全审查，价值在于补上传统扫描工具不擅长的语义层。它适合看业务逻辑、权限链路、敏感信息流和上下文风险。

但企业落地时要记住三件事：不要让 AI 单独做上线门禁；不要给 GitHub Action 过宽权限；不要把供应商接入、数据合规和账单治理留到最后。AI 审查越接近生产流程，这些工程问题越早出现。