finding-discovery

安全问题发现

根据威胁模型和适用的安全策略，识别授权源代码中技术上合理的安全漏洞。发现阶段保留证据供后续验证；不判定最终严重性。

保存输出前，先阅读 ../../references/artifact-storage.md；审查源代码前，先阅读 ../../references/security-guidance.md。针对每个审查路径解析适用的策略，包括委派的审查任务。遵循明确指定的输入和输出路径；仅当缺少明确要求的输入会妨碍所请求的分析时，才询问该输入。

选择工作流

Standard 和 Deep 工作线程使用其协调者提供的自包含提示词，而非此阶段技能。

• 运行精简差异审查： 通过 list_codex_security_review_items 读取提供的清单，审查所有分配到的变更文件，并通过 record_codex_security_discovery_candidates 一次性记录所有候选项。不要创建排序后的工作清单、逐项问题台账、回执或发现报告。
• 不含精简清单的独立差异审查： 使用 ../security-scan/references/scan-artifacts-and-ledger.md 获取变更文件工作清单和需保留的阶段产物。
• 独立仓库漏洞发现： 对授权源代码应用下方的证据标准，并返回候选项和覆盖范围限制。不要启动扫描或运行差异审查工作流。

对于差异审查，检查实际变更的行为，包括基准版本中的已删除文件。沿着相关代码继续追踪，直到理解受影响的边界；如果变更的共享控制会影响同级调用方，则扩展审查范围。不要扩展为与任务无关的全仓库审查。

证据标准

• 追踪攻击者可控的输入或特权操作，经过最近的相关控制，直至接收点和安全影响。说明为何控制缺失、可被绕过，或作用于错误的值或边界。
• 检查运行时可达性和部署假设。记录有效的防护措施和限制影响的机制，作为反证；安全的同级实现并不能证明候选路径安全。
• 除入口、包装层、具体实现和接收点外，还要保留根控制的位置，以便理解问题主张。如果问题主张涉及多个实现，应检查这些实现，而不是断言它们都受影响。
• 让彼此独立且可达的易受攻击实例能够分别定位。将同一源、控制、接收点和影响的重复观察合并，而不是按表面差异拆分；合并时保留所有受影响位置和原始候选 ID。
• 将明确的用户线索或安全公告线索追踪到其确切源代码和控制点。记录支持、反驳或尚无法解决该线索的证据；同一漏洞类别中的邻近问题不能作为结案依据。仅使用授权的源材料；未经许可，不要访问安全公告链接。
• 区分具体安全影响与可维护性或稳健性问题。崩溃、危险 API、可选功能或缺失检查本身都只是线索，并不足以构成问题发现。对于存在明确证据缺口但仍合理的候选项，将其交由验证阶段处理；不要捏造证据，也不要仅因缺少可运行的复现而将其丢弃。

如有帮助，可将独立审查任务分配给可用的工作线程，并提供目标、范围、相关策略或模型，以及所需结果字段。父级负责审查未分配的工作并协调重复项。发现阶段不要重复执行验证阶段或攻击路径阶段。

候选结果

对于每个候选项，请保留：

• 稳定的候选项 ID 和标题；保留提供的种子 ID 或台账 ID，以及参考建议。
• 受影响的文件／行位置；适用时标注 entrypoint/wrapper、root_control、sink 和 concrete_implementation。
• 攻击者可控的来源、最近的控制措施、接收点或失效的控制措施、可能造成的影响，以及将它们关联起来的来源证据。
• 反证、部署前提、未解决的问题，以及验证需要确认的内容。
• 已知时填写 CWE ID；否则使用空列表。
• 对于仓库或限定路径中的实例，在调用方要求时提供实例键 <family>:<file>:<line>。
• 对于差异审查发现，仅当相关易出错行为与差异重叠时才填写 relevant_lines。

使用调用方的结构化候选项约定。对于旧版差异，按照 ../../references/scan-artifacts.md 中的路径保存发现报告和发现凭证；后续阶段负责各自的证据和凭证。完成分配的源代码审查和具体后续事项，并如实记录尚未完成的审查。如果没有剩余的合理候选项，请说明这一结果，并列出实际审查的范围和局限性。