这次工作的产物是一份变更安全审查记录。提交或 PR 要保存 base 与 head SHA，未提交改动则保存基线 HEAD、精确 patch 或归档，以及 scan-manifest.json 中的产物哈希。记录还要写明发现及证据、未覆盖部分和复核结论。验收者应能重新取得同一段差异，找到报告指向的代码，并按触发条件判断风险是否成立。一次扫描出现了提示，不足以证明仓库存在已证实漏洞。
开始前把边界写死
只扫描你拥有或得到明确授权的仓库和变更集。准备可用的本地 Git 检出，确保基础版本与目标版本都能解析。再安装并启用 Codex Security 插件，确认桌面端安全工作台能够看到所选仓库。若改动涉及认证、授权、输入解析、文件访问、网络请求或高权限操作，把这些关注面写进任务说明。
先建立一张范围卡。提交或 PR 记录基础引用、目标引用和两端 SHA。未提交改动记录基线 HEAD，并把精确 patch 或归档与扫描产物哈希一起保存。范围卡还要写明变更目的、允许读取的目录和禁止触碰的外部系统。远端 PR 若尚未取到本地，先获取所需引用。官方流程不会替你切换分支，也不会替你猜缺失的修订版本。
扫描前用 Git 查看文件清单和差异统计，单独标出生成代码、压缩文件、依赖锁文件与大型二进制。它们可能降低可读性，也可能藏着真实的依赖变化。若决定排除某类文件，要在范围卡中写明理由，并安排人工核对对应的源文件或依赖声明。
范围仍有歧义时先停下。由仓库负责人确认后再运行，并把确认记录附在报告中。
先确认差异再启动扫描
在安全工作台选择 Scans 和新增扫描，选中仓库后使用 Changes。未提交改动、单个提交、基础与目标修订范围都可以成为检查对象。开始前再次核对当前分支、最新提交和界面给出的变更摘要。提交范围要与两端 SHA 一致，未提交范围要与保存的 patch 和 scan-manifest.json 产物哈希一致。文件数量异常就先停下。
也可以在会话中调用 $codex-security:security-diff-scan，明确写出从 origin/main 到 HEAD 的范围和关注面。这个工作流会检查改动过的源代码及其直接支持代码，不会自动扩成整仓库审计。想查整个代码库时应改用标准扫描或深度扫描。
启动后保存扫描标识、开始时间和输入范围。先让扫描完成报告，不要看到第一个可疑点就立即改代码。这样能保留原始差异和完整发现集，后续复核也不会混入修复产生的新变化。
把发现还原成能重走的路径
逐条阅读结果，先找攻击者可控输入，再沿调用关系走到敏感动作。报告至少要回答输入从哪里来，经过哪些校验，调用者需要什么身份，危险动作在什么条件下发生，现有测试覆盖了什么。只有静态模式相似、缺少可达路径或权限前提的条目，应标成待复核线索。
复核可以使用只读检索、已有测试和隔离环境中的安全样例。不要把生产账户、真实用户数据或有破坏性的载荷带进验证。证据仍不足时，写清缺哪一段调用关系或运行结果。严重度来自可达性、权限、影响和缓解条件，不能只看规则名称。
每条记录用同一结构整理，包含文件与行、相关提交、触发前提、预期安全属性、实际代码行为、支持证据、反证和建议下一步。修复建议保持最小范围，但本次交付仍以审查为主。是否接受发现、安排修复或阻止合并，应由仓库负责人结合业务上下文决定。
如果一条发现依赖部署配置或外部策略，报告应给出待查询的配置名和责任人，避免用猜测补齐。复核者确认后再更新状态，同时保留原始提示和补充证据，方便之后解释结论为何改变。
用同一提交完成验收
最终复核时重新解析提交范围的两端 SHA，或核对未提交范围的基线 HEAD、保存 patch 与产物哈希，确认扫描期间范围没有漂移。随机抽查无发现的高风险文件，核对扫描确实看过关键入口。再把确认项、待复核项和未支持项分开，附上覆盖说明和运行条件。若目标分支或工作区已经变化，应为新差异重新扫描，旧报告只能证明旧范围。
风险与限制
变更扫描只覆盖一个 Git 差异及直接支持代码，发现不了所有历史问题。动态配置、生产身份、外部服务和运行时状态也可能不在本地证据中。自动扫描能缩小审查面，不能代替安全负责人对业务权限、部署环境和真实影响的判断。
交付清单
- 授权主体、仓库和允许范围已经记录
- 提交范围的两端 SHA，或未提交范围的基线与 patch，和扫描结果一致
- 每条可疑点都有代码位置、前提和支持证据
- 待复核线索没有写成已证实漏洞
- 未覆盖路径和环境限制已经说明
- 报告保留扫描标识、时间和复核状态