安全审查：用分层规则发现问题，再做有边界修复

报告了很多漏洞，不等于发现了一个真实问题

“检查所有安全问题”听起来很负责。运行以后，报告塞满泛泛的风险描述，值班工程师却无法复现，也不知道该先看哪一行代码。

安全规则的价值不只看覆盖，还看克制、保留和可行动。 这节课从仓库不变量开始，用正反样本评估，再对一个已验证发现做最小修复。

这节课要交付什么

这不是一份只需要读完的功能介绍。你要在真实但可控的环境中留下一个可以复查的结果，并且能回答三个问题：Codex 看到了哪些事实，它实际做了哪些动作，你用什么独立证据确认结果成立。

最终结果是：一套经过覆盖率与克制性评估的审查规则，以及一个可回退的示例修复。开始前先创建一份简短记录，把当前环境、目标、禁止动作和验收方式写下来。后面的命令、截图和修改都回到这份记录，不靠聊天窗口里的“应该已经好了”判断完成。

先看官方边界

Codex Security 是面向安全与工程团队的独立应用安全产品，云端扫描和部分能力可能受研究预览、访问资格或组织设置限制。普通 Codex 代码审查也不等于安全证明。教程只处理你有权审查的代码，并把模型发现视为候选：必须复现、确认影响、审查补丁和运行回归后才能关闭。

官方页面会随产品更新。教程引用的是当前可核对的能力与命令，不把界面位置、套餐权限或预览功能包装成永久承诺。你在自己的设备上看到不同按钮时，先核对官方页面和本机版本，再决定是否继续；不要用过期截图覆盖现场事实。

任务现场

团队希望规则写“检查所有安全问题”。这样的句子覆盖面无限，几乎必然产生噪声。真正需要的是仓库不变量：公开路由必须鉴权、租户查询必须带 tenant_id、重定向目标必须来自允许列表。每条规则都能指向代码边界、违规样本和验证方式。

先把现场写成四行：工作目录或项目、当前版本或输入、允许动作、完成证据。如果其中任何一行只能写“让 Codex 自己看”，说明上下文仍然不够具体。Codex 可以帮助检查，但不能替你决定哪些数据能上传、哪个生产动作已获授权，或一个异常是否可以忽略。

动手前准备

从历史缺陷和架构文档选三条高价值不变量。广泛规则放根 AGENTS.md，服务特有规则放相邻目录，避免把某个框架假设施加到全仓库。为每条规则准备至少一个应报样本和一个不应报样本；机械格式检查留给 linter/CI，不占用模型判断。

把练习放在可恢复的位置，保留原始输入，并记录开始时的状态。涉及代码时先看版本控制状态；涉及数据时先复制脱敏样例；涉及外部服务时先使用只读或草稿模式。准备工作看似慢，却能让失败变成一次可以解释和回退的实验。

第一步：只读建立基线

让 Codex 只读定位认证入口、数据访问层和信任边界，为每条规则附文件证据与适用目录。规则写成“条件—风险—需要检查的证据—期望建议”，不要只列漏洞名称。先人工审查规则是否泄露秘密、是否超出团队授权。

这一阶段不要急着要求“直接修好”。先让 Codex 复述目标、列出它实际读取的来源，并指出还缺哪些证据。你要检查它有没有打开正确目录、有没有把搜索摘要当原文、有没有把旧日志误当当前状态。基线不可信，后面的修改越多，返工成本越高。

第二步：限制范围后执行

用正反样本运行代码审查，分别记录 coverage、restraint、retention、actionability：该报的是否报到，不该报的是否克制，跨轮是否保留规则，建议是否能定位并行动。噪声高时缩小范围或增加例外证据，不通过堆更多形容词修提示。

执行指令应该同时包含目标、范围和停止条件。把“不要乱改”换成可观察边界，例如只允许修改两个文件、不安装依赖、不发送消息、不触碰生产数据。出现新的权限、需要改变既有契约或发现输入口径不一致时，要求 Codex 停下来报告，而不是自行选择更大的方案。

第三步：用独立证据验收

对一个已人工验证的低风险发现，让 Codex 先生成补丁建议或独立 patch，不直接修改主分支。审查 diff 后在隔离工作区应用，重复原始复现并运行相邻合法用例。记录仍未覆盖的攻击面；只有证据闭环并获得批准，才进入正常提交与发布流程。

验收必须尽量脱离生成答案本身：安装类任务看版本、路径和真实启动结果；界面任务看目标视口与交互；数据任务用独立计算和异常清单；安全任务用原始复现、补丁 diff 与回归测试。把通过、失败和未验证分开记录，未验证不是失败，但绝不能伪装成通过。

完整案例

一条“所有查询必须 tenant_id”规则错误地报告了公共国家列表。团队在反例中发现 restraint 不足，把规则限制到租户资源仓储，并列出公共表证据。之后它准确抓到一个导出接口漏过滤。Codex 生成两行查询补丁与回归测试，但团队仍验证管理员跨租户用例，确认补丁没有破坏合法权限后才合并。

案例的重点不是复制同一句 prompt，而是观察决策顺序：先确定权威来源，再缩小动作面，最后让证据闭环。如果你的项目结构不同，保留这个顺序，替换文件名、命令和验收对象。任何会产生外部影响的步骤，都应在真正执行前再次获得明确授权。

故障诊所

报告看似严重却无法复现时，不争论措辞，回到数据流、可达路径和攻击前提。规则每轮遗忘时检查 AGENTS.md 作用域与实际工作目录。误报过多时优先删除宽泛规则。补丁让测试通过但改变合法行为时撤回补丁，重新定义安全不变量；不能用“更安全”作为破坏业务契约的理由。

恢复时一次只改变一个变量。先保存错误原文和当前状态，再判断问题属于安装路径、权限、上下文、实现还是验收环境。不要连续重装、重写和切换工具，因为那会抹掉因果关系。修复后重复最小复现，再跑相邻路径，确认没有用一个新问题遮住旧问题。

迁移练习

为一个虚构文件上传服务写两条目录级规则：文件类型与租户路径。准备四个正反样本，运行两轮审查并填写四维评估表。只选择一个被确认的发现生成 patch，在应用前后分别保存 diff、复现和合法用例结果。

完成练习后，把其中的产品名和文件名遮住，只保留“输入—动作—证据—停止条件”。如果这四项仍能指导另一个任务，说明你学到的是方法；如果离开示例 prompt 就不会继续，回到任务现场，补出你真正依赖的判断规则。

安全结论必须比普通建议多一层证据

候选发现先复现，影响先确认，补丁先审查，合法路径也要回归。任何一步没有完成，都明确写成 proof gap。

模型可以帮助扩大审查视野，但不会替团队承担授权和发布决定。可回退、可反驳、可复现，才让安全自动化值得长期信任。

完成检查

• 审查范围、代码所有权和授权已经确认
• 规则是可定位的不变量而非无限范围安全口号
• 正反样本同时评估覆盖率与克制性
• 发现经过复现，补丁在隔离环境审查并保留回退
• 我保留了开始状态、实际动作和最终证据
• 我把失败、未验证和已通过分开记录
• 需要新权限或外部影响时，Codex 会停下来询问