fix-finding

修复安全问题

在选择路径或保存保留的输出之前，请先阅读 ../../references/artifact-storage.md 并遵循其中的存储策略。

目标

将当前安全问题转化为最小且经过验证的代码更改。如果代码已经安全，请提供证据证明这一点，并报告无需更改。

根据证据判定当前状态，修复失效的安全边界，保留合理行为，并通过所选验证模式要求的检查。优先采用满足这些要求的最小仓库原生更改。

验证模式

除非调用方明确选择 verificationMode: static，否则使用 standard 验证。所选模式适用于此技能的各个环节，包括委派审查和工作台阶段；请将该模式传递给每个委派的 Agent。

在静态模式下，仅评估源代码和差异证据。不要安装依赖项，也不要运行构建、测试、复现程序或应用程序，即使验证说明要求运行也是如此。仍可使用仓库读取工具。请说明未执行运行时检查；不要将其计为已通过，也不要要求将其纳入本次评估。仅缺少运行时工具并非阻碍，但源代码证据存在实质性缺口时仍须标记为 blocked。

补丁约定

编辑之前，请检查受影响的实现、其直接调用方、附近的辅助函数以及相关现有测试。根据仓库证据确认：

• 攻击者可控的输入，以及具体的源到汇路径或失效的控制机制
• 安全不变量和范围最窄的共享强制执行边界
• 必须保留的合理行为、API、错误语义和兼容性约束
• 最接近的现有实现、验证和错误处理惯例

应将安全问题视为数据流和边界问题，而不只是针对所述输入示例的问题。检查等效编码、解析形式、别名、调用方、接收点，以及可能绕过拟议更改的安全敏感状态的每一种表示形式或副本。明确处理不安全状态；不要悄然接受、截断它，也不要将其重新解释为另一种可访问形式。

实施工作流

1. 跟踪报告中提到的路径，仅检查识别真实共享边界所需的上下文。如果仓库证据表明报告中的路径已经安全，则返回 no_change；不要做推测性修改。
2. 在标准模式下，如果可行，应通过该边界运行最小且信号明确的复现用例，并通过同一路径运行一个合法的对照用例。
3. 在共享边界实施最小的、符合仓库惯例的修复。优先使用附近的辅助函数和既有 API。不要扩展到无关的重新设计、清理或其他同类问题。
4. 验证前，先质疑补丁，而不是为其辩护：检查每个已修改辅助函数的所有直接调用方，以及每个已修改条件的两种结果。查找是否有一条同类路径、表示形式或副本仍能到达易受攻击的终点，以及是否有某种普通或默认输入被补丁新拒绝或重新解释；如果存在，修改实现。
5. 在标准模式下，验证最终变更：
   • 检查最终差异，并运行与其相关的最精简语法、导入、构建或类型检查
   • 重新运行安全触发用例或最有力的定向替代用例，并检查另一类恶意输入
   • 重新运行合法对照用例、最接近的现有测试，以及所属包适用的必需检查

在静态模式下，改用以下验证关卡：检查最终差异；跟踪原始攻击路径及相关替代输入在已修改控制逻辑中的流向；然后检查调用方和现有测试源码，以确认合法行为和兼容性仍然完好。为每个关卡引用源码证据，并指出其无法证明的事项。

如果漏洞可能确实存在，但缺少必要证据、工具、访问权限或产品／兼容性决策，导致无法负责任地完成或验证安全修复，则返回 blocked。

审查修复

检查补丁是否仍存在可绕过之处，或是否会破坏合法行为。当复杂度、不确定性或安全影响值得进行独立调查或审查时，应这样做。向一名未参与实现的只读审查者提供问题描述、仓库根目录、授权范围、仓库策略、验证模式和候选差异，让其依据源码独立评估，不受作者理由或所声称测试结果的影响。如果无法委派，则应另行完成该审查。

在修改补丁前，应依据源码或在标准模式下通过定向执行，确认审查提出的问题属实。仅处理问题范围和兼容性边界内已确认的问题，然后针对所选模式重复受影响的验证关卡。如果修订改变了安全边界或引入新的重大风险，则重新审查。确保没有遗留临时变更或无关变更。

Workbench 修复阶段

当 Codex Security 工作台请求包含扫描 ID、出现项 ID、修复请求 ID、操作令牌和预期版本时，只执行所请求的修复阶段。阶段边界会改变何时可以编写代码，但不会降低上述验证要求。

• Generate：保持选定的目标检出内容不变。需要编辑以开发或测试修复时，使用隔离的工作树或临时副本。遵循上述补丁约定和验证要求，编写一份包含完整源码和回归测试变更的规范统一差异，然后使用提供的工作台身份记录 generated 或 failed。
• Apply：验证记录的基础修订版本和补丁摘要，然后将该补丁原样应用到选定的工作树，不做无关编辑。记录 applied 或 failed。此阶段不要验证或关闭发现项。
• Verify：不要修改源码。根据上述选定模式的验证关卡进行验证。只有当证据证明原始易受攻击的路径已关闭、合法行为仍然正常，且所需检查均已通过时，才记录 verified；在验证摘要中保留准确证据和运行过的任何命令。否则记录 failed，并说明未通过的关卡或证据缺口。不要关闭发现项。

当父线程委派修复阶段时，工作线程负责该阶段，直至完成最终工作台更新。父线程仍是协调者，不得重复工作线程所做的编辑，也不得将聊天回复视为已完成。

结果与输出约定

如果调用方提供了输出架构，请遵循该架构。否则，最终回复中应包含：

• 结果：fixed、no_change 或 blocked
• 具体的易受攻击路径、安全不变量，以及必须保持的合法行为
• 所选补丁策略及其为何是最精简完整且符合仓库惯例的方案；若受阻，则说明尚未解决的产品决策
• 已更改的文件
• 添加的测试或验证产物
• 运行的命令及其通过、失败或未知的结果
• 原始易受攻击路径已关闭的证据，并区分源码评估与实际执行观察
• 明确说明如何证明合法行为仍然正常
• 如有任何剩余的不确定性或跳过的验证，予以说明

如果使用扫描产物目录，请根据 ../../references/scan-artifacts.md 确定其路径，然后将可见报告写入修复报告路径。如果不存在现有扫描目录，除非用户要求写入文件，否则最终聊天摘要即可。

硬性规则

• 只有在选定模式的所有验证关卡都通过后，才能报告 fixed。只有当仓库证据表明某项检查不相关时，才可省略该模式要求的检查；如果无法执行所需检查，验证结果应为 blocked，并且必须报告。
• 在标准模式下，如果可以进行有针对性的测试或复现，不要只依赖代码检查。
• 不要将补丁扩展到无关清理、相关发现项或架构重设计，除非有证据表明需要扩大变更范围才能彻底解决问题。
• 不要移除用户的更改或无关的本地修改。
• 不要为了让测试通过而削弱身份验证、授权、租户隔离、输入验证、沙箱隔离或日志记录。
• 不要掩盖证据缺口。如果环境阻碍了验证，请准确说明失败的命令或设置，以及仍缺少哪些证据。