1. 为什么 PR 过了 Code ReviewSecurity Review 还是绕不过去先说结论Code Review 和 Security Review 解决的不是同一层问题。Code Review 回答的是「代码按设计工作了吗」Security Review 追问的是「如果攻击者故意绕开正常用法会发生什么」。这两个问题在大多数业务 PR 里可以合并但一旦 PR 触碰认证、权限、支付、文件上传、用户数据这些区域它们就必须拆开。我见过太多团队的真实情况一个 10 行的接口改动功能测试全绿Code Review 也过了上线两周后被扫出越权——因为那 10 行只判断了「资源存在」没判断「当前用户是否拥有这个资源」。反过来一个 500 行的 CSS 重构 PR改的全是颜色、间距、响应式断点它压根没动 Trust Boundary跑再重的安全审查也是浪费。所以真正该盯的指标不是 PR 数量也不是改动行数而是安全边界变化频率你的 PR 里有多少比例在改变「谁能登录、谁能访问数据、用户输入能进入哪里、什么资源能被读取」。这个比例低普通 Code Review 加测试基本够用这个比例高你就需要一套独立、可重复执行的安全审查流程而不是每次靠人肉记忆去补。这篇要交付的就是这套流程的工程骨架从 CI 触发条件、检查项清单到可复制的settings.json与config.toml示例再到在统一 Key/API 通道下怎么验证配置真的生效。适合已经在用 ChatGPT、Codex 辅助开发、PR 流程跑得比较顺、但安全审查还停留在「想起来才做」的团队。2. 前置准备把安全审查接进统一 API 通道在写配置之前先把调用通道理清楚。安全审查这类任务的特点是触发频繁、单次上下文长要读 Diff、仓库上下文、Threat Model、对稳定性要求高。如果每个开发者各自维护一套 Key轮换、限额、审计都会变成灾难。我的做法是把模型调用统一收敛到一个 API 通道所有 CI 里的安全审查脚本、本地 Codex 辅助、ChatGPT 侧的对话验证都走同一个入口。这样 Key 只需要在一处管理配额和调用记录也能集中看。具体操作上先到控制台创建一把专用 Key建议按用途命名比如ci-security-review不要和本地开发用的 Key 混在一起。创建入口在控制台的 API Keys 页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite拿到 Key 之后接入文档里有各语言 SDK 和原生 HTTP 的调用方式CI 脚本里用 curl 或官方 SDK 都行https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 基地址统一用https://taotoken.net/api注意这个地址不带任何查询参数Key 通过请求头传递。如果你在本地想先手动验证模型对某段 Diff 的判断可以直接用模型对话页面把 Diff 和 Threat Model 贴进去试https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite这一步的意义在于后面所有配置里的 endpoint 和鉴权方式都从这里来配置骨架才能一次写对不用在 CI 里反复试错。3. 可复制的 Security Review 配置骨架下面这套配置分两部分settings.json负责定义「什么 PR 触发安全审查、审查哪些检查项」config.toml负责定义「审查任务怎么调用模型、用哪个通道、超时和重试怎么设」。两者配合才能让安全审查从一句 Prompt 变成 CI 里的固定步骤。3.1 settings.json定义触发条件与检查项触发条件的核心是路径匹配加关键词匹配。路径上认证、权限、支付、上传、数据访问相关的目录全部纳入关键词上Diff 里出现auth、permission、role、token、session、upload、payment、balance这类词时也触发。{ security_review: { enabled: true, trigger: { paths: [ src/auth/**, src/permission/**, src/payment/**, src/upload/**, src/api/**, src/middleware/** ], diff_keywords: [ auth, permission, role, token, session, cookie, upload, payment, balance, tenant, acl ], min_changed_lines: 1, exclude_paths: [ **/*.css, **/*.md, **/__snapshots__/** ] }, checks: [ new_attack_surface, user_controlled_input, authorization_placement, sensitive_data_boundary, failure_path_test, id_param_header_tampering ], severity_gate: { block_on: [critical, high], warn_on: [medium], ignore: [low, info] } } }这里几个参数值得展开。min_changed_lines设成 1 是有意的安全边界变化经常就藏在几行里用行数过滤会漏掉最危险的那种改动。exclude_paths把 CSS、文档、快照排除掉避免纯样式 PR 触发无意义的审查。severity_gate决定审查结果怎么影响合并critical 和 high 直接阻断medium 只警告low 和 info 记录但不打扰。checks数组里的六项对应六个具体问题审查时逐项过而不是笼统问一句「有没有安全问题」。这六项分别是有没有新增攻击入口、有没有新的用户可控输入、权限校验放在哪一层、敏感数据有没有跨越新边界、失败路径有没有测试、攻击者篡改 ID/参数/Header/Token 会发生什么。3.2 config.toml定义模型调用与通道[security_review.model] provider openai-compatible base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY model gpt-4o max_tokens 8192 temperature 0.1 [security_review.context] include_diff true include_repo_context true threat_model_path .security/threat-model.md max_context_files 20 [security_review.runtime] timeout_seconds 180 max_retries 2 retry_backoff exponential concurrency 1 [security_review.output] format markdown include_severity true include_attack_path true include_evidence true include_remediation truetemperature设成 0.1 是为了让审查结果稳定安全判断不该有随机性。threat_model_path指向仓库里的 Threat Model 文件审查时会把它作为上下文一起送进去这样模型知道你的信任边界在哪、哪些组件是高风险的。concurrency设成 1 是保守做法避免多个审查任务同时读仓库上下文时互相干扰如果你的 CI 资源充足可以调高。output部分要求输出里必须带 Severity、Attack Path、Supporting Evidence 和 Remediation Guidance这样审查报告才可执行而不是一句「这里可能有风险」。3.3 CI 流水线里的触发脚本配置写好后在 CI 里加一个步骤判断当前 PR 是否命中触发条件命中就调用审查。下面是一个简化的 shell 片段#!/usr/bin/env bash set -euo pipefail CHANGED_FILES$(git diff --name-only origin/main...HEAD) DIFF_CONTENT$(git diff origin/main...HEAD) TRIGGEREDfalse while IFS read -r file; do case $file in src/auth/*|src/permission/*|src/payment/*|src/upload/*|src/api/*|src/middleware/*) TRIGGEREDtrue ;; esac done $CHANGED_FILES if [ $TRIGGERED false ]; then echo No security-sensitive paths changed, skip security review. exit 0 fi echo Security-sensitive change detected, running review... python scripts/run_security_review.py \ --diff $DIFF_CONTENT \ --config .security/config.toml \ --settings .security/settings.json这个脚本先看改动文件是否落在敏感路径命中才继续。run_security_review.py负责读配置、拼上下文、调 API、解析结果最后按severity_gate决定退出码。退出码非零时 CI 直接失败PR 无法合并。4. 验证请求与成功结果配置写完先别急着接 CI手动跑一次确认通道和输出都正常。最直接的方式是用 curl 打一次 API确认 Key 和 endpoint 通curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, temperature: 0.1, messages: [ { role: system, content: You are a security reviewer. Analyze the diff for trust boundary changes. }, { role: user, content: Diff: if (resource.ownerId userId) { return resource; } } ] }返回里能看到正常的choices结构说明通道没问题。接着跑完整的审查脚本拿一个真实的敏感 PR 试。成功的结果应该长这样Security Review Report PR: #482 Triggered by: src/api/resource.ts (path match), diff keyword permission Findings: 1. [HIGH] Missing ownership check on resource query Attack Path: Attacker changes resource ID in request, server returns resource without verifying current user owns it. Evidence: src/api/resource.ts:42-48 Remediation: Add ownership assertion before returning resource. 2. [MEDIUM] Failure path not tested Attack Path: N/A Evidence: no test covers unauthorized access attempt Remediation: Add test asserting 403 when user does not own resource. Gate: BLOCK (1 high finding)看到Gate: BLOCK且退出码非零就说明整条链路通了触发条件命中、上下文正确送入、模型返回结构化结果、severity gate 生效。这时候再把它接进 CIPR 一旦触碰安全边界就会自动跑审查并阻断高风险合并。如果你还想在本地快速验证某段代码的判断可以把 Diff 贴到模型对话页面手动问一轮确认模型的判断和你的预期一致再固化到配置里。5. 本篇常见错排查触发条件太宽每个 PR 都跑。最常见的原因是diff_keywords里放了太通用的词比如user、data、api。这些词几乎每个 PR 都会出现导致审查变成噪音。解决办法是把关键词收窄到真正指向安全边界的词路径匹配优先于关键词匹配。审查结果全是 low没有阻断。检查severity_gate的block_on是否写对以及模型输出里 severity 字段是否被正确解析。如果模型返回的是自然语言而不是结构化字段需要在 prompt 里明确要求按固定格式输出或者在脚本里加一层解析容错。上下文太长导致超时。max_context_files设太大时仓库上下文会撑爆 token 限制。建议从 20 开始观察审查质量和耗时再决定是否调整。timeout_seconds设 180 是保守值如果仓库很大可以适当放宽但不要无限等。Key 泄漏进 CI 日志。用api_key_env从环境变量读 Key不要写死在config.toml里。CI 的 secret 管理里配置TAOTOKEN_API_KEY日志里确保不打印请求头。审查通过但线上仍出问题。这通常不是配置问题而是 Threat Model 没更新。.security/threat-model.md需要随架构演进维护新增了外部 API、新的数据流、新的角色都要同步进去否则模型不知道新的信任边界在哪。6. 把安全审查落到工程配置里回到最开始那个问题PR 过了 Code Review为什么还要单独做 Security Review。答案不是 Code Review 不够好而是它和 Security Review 在解决不同层次的问题。Code Review 保证代码按设计工作Security Review 追问攻击者绕开正常用法时会发生什么。这两件事在触碰安全边界的 PR 上必须分开做而且要做成固定流程而不是靠人记得。这套配置骨架的价值在于它把「安全审查」从一句 Prompt 变成了 CI 里的固定步骤路径和关键词决定什么时候触发六项检查决定查什么severity gate 决定结果怎么影响合并统一 API 通道保证调用稳定可审计。你不需要一开始就追求完美先把触发条件和阻断规则跑起来再逐步补 Threat Model 和检查项。如果你的团队已经在做长期编码和 Agent 辅助开发安全审查的调用频率会越来越高这时候可以考虑把这类任务放到更稳定的通道上避免和日常对话抢配额。具体可以看 Coding Plan 的说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite配置写完、验证通过之后真正的判断标准只有一个你的 PR 里安全边界变化是偶发事件还是每天开发工作的常态。偶发普通 Code Review 加人工检查够用高频就该让这套流程自动跑起来。
