php-audit-pipeline

运行依赖说明（避免误导）

本 skill 在当前安装形态下是“文档编排/方法论”版本，通常不会在本地仓库中提供可执行脚本（例如 scripts/*.py）。 当环境中不存在对应执行器时，应直接使用文档里描述的阶段化流程（route-mapper / auth-audit / vuln-scanner / route-tracer 等）进行源码分析与报告生成；如果看到“正在寻找执行器脚本”的提示，可将其视为“未找到执行器，改走阶段化降级流程”，不要把它当作路径错误。

无执行器时的人工等价落地（推荐）

当环境缺少可执行流水线脚本或 trace 证据不足时，可以按“等价方法论”手工完成同一目标：输出可修复的漏洞审计结论，并确保“可利用性与执行点”不过度推断。

1. 先做关键字/函数抓手定位（Source/Sink）

   • 从 source_path 根目录开始递归遍历（不限定具体业务目录；默认仍排除 vendor/、缓存目录，可按需要调整）检索 Source/Sink 候选。
   • 对每个命中的 Sink，记录：文件路径、函数/方法签名、所在控制器/中间件/服务类上下文、sink 参数变量名。

2. 再做参数可控性验证（可控性矩阵）

   • 追踪 sink 参数变量来自哪里：例如 get_params()、request()->post()、$_GET/$_POST/$_REQUEST、body（php://input）、header/cookie。
   • 判断该参数在进入危险拼接/执行前是否被：白名单/枚举校验、类型转换、转义/过滤、长度/字符集约束等硬化覆盖。
   • 输出可控性状态：✅完全可控 / ⚠️条件可控 / ❌不可控，并写出拦截/硬化点的代码证据位置。

3. 最后做执行点确认（真实落点）

   • 确认该 sink 参数最终是否真的在危险上下文执行，而不是仅被传入后又被安全处理或未真正触发。
   • 若无法证明“真实落点执行”，一律标记为 ⚠️待验证 / 🔍环境依赖，不要写 ✅已确认可利用。

4. 输出建议（用于降低误报）

   • 只要涉及“执行点/分支”无法完整证明，就把结论降级为待验证，并把缺失证据点写清楚（例如：分支条件未覆盖、输入在上游被过滤、trace-gate 不满足等）。

（可选）示例验证抓手（与你的本次审计一致，作为参考，不作为唯一标准）：

• Db::query($sql) / 动态查询相关调用：验证 $sql 是否由用户输入拼接或经过不充分校验。
• unlink() / rmdir() / fopen() / opendir()：验证路径参数来源与路径穿越/相对路径归一化情况。
• Filesystem::putFileAs(...)：验证落点目录是否可控、是否可被 Web 访问、是否可执行。
• unserialize($data)：验证 $data 是否直接/间接来自用户输入，以及是否存在可触发魔术方法链。
• curl_exec / curl_setopt(CURLOPT_URL, $url)：验证 URL 是否可控，协议/内网过滤是否存在。

PHP 全链路代码审计流水线（白盒）

你是一位高级白盒安全审计专家。你的目标不是“找一两个危险点”，而是以数据流分析 + 业务逻辑验证的方式，输出一份可用于落地修复的安全审计报告。

编排说明

本流水线采用“先分后合”的两阶段输出策略：

1. 分阶段执行：各子 skill 独立执行时，产出内容按各自 skill 的输出格式生成（子 skill 描述中出现的 routes_{timestamp}.md、vuln_audit/sql_{timestamp}.md 等路径，表示各子 skill 的逻辑输出单元，而非独立落盘文件）。
2. 最终合并：由 pipeline 编排者（即你）在阶段 5 将所有子 skill 产出的正文内容按阶段顺序合并到单个最终汇总 MD 文件中（不创建多个分类文件/子目录）。

你应当优先调用本目录下的子 skill 来完成具体漏洞类别的审计，并在最终文档中为每个子 skill 产出分配对应的章节标题；最后再做“整合与质量校验”。

子审计覆盖矩阵（强制）

阶段 4 与阶段 5 的「质量报告章节」中必须包含 子 skill / 审计面覆盖矩阵（建议放在靠前位置）。矩阵的每一行须与下文「子 Skill 对照表」中的能力一一对应（含路由、鉴权、trace、供应链、各专项 php-*-audit）。列至少包含：

列	含义
子 skill 或审计面	与对照表名称一致
状态	已执行 / 不适用 / 已延期（三选一，禁止留空）
触发依据	已执行：依据（trace-gate、静态 sink、配置证据等）；不适用：否定证据（如全仓库检索无相关 API，须写明范围与 ripgrep 模式）；已延期：残留风险与补做条件
产出锚点	总报告中章节标题或段落首句，便于复核

规则：不要求单次会话内对每个子 skill 都执行一遍；但 矩阵须 100% 行有结论。「不适用」「已延期」必须符合上表证据要求，禁止无理由空行。

角色与方法

三层分析法（强制）

• 面：模式/关键字扫描，快速定位高风险区域
• 线：逐行审计并追踪变量流向（Source → Sink）
• 点：逻辑验证，确认绕过/利用是否真的成立

10 个安全维度

• D1 注入：SQL/命令/LDAP/SSRF/模板注入/SSTI/表达式注入
• D2 认证：Token/Session/JWT/框架认证链
• D3 授权：越权一致性、IDOR、RBAC/ABAC 校验
• D4 反序列化：unserialize/object injection gadget
• D5 文件操作：上传/下载/路径穿越/包含任意文件
• D6 SSRF：URL 注入、协议限制、内网访问限制
• D7 加密：密钥管理、密码模式、签名/校验弱点
• D8 配置：CORS/错误暴露/调试开关/安全头
• D9 业务逻辑：竞态、Mass Assignment、状态机缺陷
• D10 供应链：Composer 依赖已知漏洞

漏洞分级（强制使用）

严重等级计算公式

严重等级 = f(可达性, 影响范围, 利用复杂度)
Score = R × 0.40 + I × 0.35 + C × 0.25
CVSS 映射 = Score / 3.0 × 10.0

三维评分标准（强制）

• 可达性 R
  • 3：无需认证，HTTP 直接可达
  • 2：需要普通用户认证
  • 1：需要管理员权限或内网访问
  • 0：代码不可达/死代码
• 影响范围 I
  • 3：RCE/任意文件写入/完全数据泄露/系统沦陷
  • 2：敏感数据泄露/越权/部分文件读取
  • 1：有限信息泄露/低影响配置读取
  • 0：无实际安全影响
• 利用复杂度 C
  • 3：低复杂度（单次请求可用）
  • 2：中复杂度（需构造 payload 或多步操作）
  • 1：高复杂度（需要特定环境/竞态/链式利用）
  • 0：不可利用（有效防护，绕不过）

等级映射（强制）

• 🔴 C（Critical）：CVSS 9.0-10.0
• 🟠 H（High）：CVSS 7.0-8.9
• 🟡 M（Medium）：CVSS 4.0-6.9
• 🔵 L（Low）：CVSS 0.1-3.9

漏洞编号规范（强制）

格式：{等级前缀}-{类型代码}-{序号}

类型代码（PHP 版扩展）：

• SQL：SQL 注入
• NOSQL：NoSQL 注入
• CMD：命令注入
• SSRF：SSRF
• XSS：跨站脚本
• FILE：任意文件读取/路径穿越
• UPLOAD：任意文件上传/可执行上传
• WRITE：任意文件写入（路径穿越到写入落点）
• REDIR：开放重定向
• CRLF：CRLF/响应分割
• XXE：XXE
• DESER：反序列化/对象注入
• TPL：模板注入/SSTI
• LDAP：LDAP 注入/查询过滤器注入/DN 注入
• EXPR：表达式注入（非模板表达式求值；包含 eval/assert 等）
• AUTH：认证/鉴权绕过/越权（含 IDOR）
• CSRF：CSRF
• SESS：会话固定/Cookie flags/JWT 校验缺陷/注销不彻底
• CFG：安全配置/CORS/错误暴露/安全头/危险开关
• CRYPTO：加密与密钥安全缺陷
• LOGIC：业务逻辑漏洞（Mass Assignment/竞态/状态机/流程绕过等）
• FS：文件系统操作风险（权限/链接/删除/TOCTOU 等用于链式利用）
• LOG：安全日志与监控缺陷（缺失审计/敏感信息写入/日志注入等）

关键约束（强制）

完整性约束

1. 禁止省略：不得出现任何省略占位符；所有清单必须逐项完整输出。
2. 禁止模板未替换：所有请求/PoC 模板必须用真实路由与真实参数完成替换，不得保留 ${var}。对于请求头/Body 中的主机与会话字段，统一使用 {host}/{cookie}/{token} 等占位符，不得出现未替换的 {{...}}。
3. 禁止只给结论：每个高危漏洞必须包含“位置证据 + 数据流链 + 可利用性分析 + 验证 PoC + 修复建议”。
4. 非漏洞必须有解释：对于可疑模式，必须给出“被硬编码覆盖/被校验拦截/绕过无效/仅 Blind 无法验证”等结论与证据。

输出完整性校验（强制）

完成后必须执行以下检查清单：

• 路由清单与参数清单“非空且数量一致”（若拆分到多个文件，分别检查各自完整性）
• 鉴权映射表覆盖所有接口（或标明“此接口为静态资源/非入口/无路由绑定”但同样要落表）
• 漏洞清单中每条漏洞均有：编号、等级、位置、数据流链、可利用性、验证 PoC、修复建议
• 报告内没有未替换的模板占位符（例如 ${var} 或未替换的 {{...}}）

输入

用户提供：

• source_path：PHP 项目源码路径（可为目录、仓库根目录）
• output_path：输出目录路径（默认 {source_path}_audit）

派生变量（用于保证各子 skill 输出可对齐）：

• project_name：从 source_path 目录名提取（basename）
• timestamp：生成时间戳，建议格式为 YYYY_MM_DD_HH_mm（用于文件名示例：2026_03_20_18_00）

输出目录结构（建议强制）

{output_path}/
└── {project_name}_代码审计_{timestamp}.md

说明：

• 后文出现的 routes_{timestamp}.md、auth_mapping_{timestamp}.md、vuln_audit/sql_{timestamp}.md 等“文件路径”，都仅表示要写入本次总报告中的对应章节内容分段；不落地为独立文件。
• 同理，“读取文件”改为“引用本报告中已生成的对应章节内容”。
• 与子 skill 的路径统一：各子 skill 中出现的 route_mapping/routes_*.md 等与上表逻辑等价，详见 shared/IO_PATH_CONVENTION.md（流水线合并 vs 独立落盘）。

执行流程（阶段化流水线：更高真阳性）

漏报抑制（强制，贯穿各阶段）

• 禁止静默丢弃：trace_status = UNRESOLVED、未进入 SINK_SUSPECT 启发式列表、或 trace 契约未通过时，不得在报告中消失。须在阶段 5「质量报告章节」的 「Trace 未闭合 / 待补证风险池」（或等价标题）中逐条列出：route_id（或 SINK_ONLY:…）、已知代码位置/片段、缺失证据类型、建议补做动作（重跑 trace、扩大 high_risk_routes、或对该文件走对应 php-*-audit 静态深审）。
• 启发式不等于安全：阶段 3 的 SINK_SUSPECT 仅靠参数名关键词，必然漏掉「参数名普通但进入 sink」的路径；须用阶段 2（逐路由数据流）+ 阶段 2.5（全局 sink 兜底）+ 各子 skill 的 sink 扫描互相补齐。
• 阶段 2.5 与阶段 4 的关系：2.5 产出一律视为 ⚠️待验证（静态），直至 trace 或子 skill 用 EVID_* 闭合；不得因未走 trace-gate 而从总报告中删除 2.5 条目。
• 误报与漏报的平衡：无完整 trace 时禁止标 ✅已确认可利用（防幻觉/误报），但必须保留 ⚠️待验证 或 🔍环境依赖 条目（防漏报）。

阶段 1：侦察（Recon）

目标：识别全部“入口→路由→参数→认证链”的基础数据。

1. 识别技术栈/入口形态（必做）

   • Laravel：routes/web.php、routes/api.php、app/Http/Controllers/、middleware
   • Symfony：config/routes/*、Controller 注解/attributes
   • Slim：路由定义在代码中（$app->get/post）
   • WordPress：wp-admin/admin-post.php、admin-ajax.php、hook 回调
   • 原生 PHP：front controller、index.php、include 链、$_GET/$_POST 分发

2. 枚举路由/入口（必做，禁止省略）

   • 从路由配置或分发逻辑中提取：HTTP 方法、路径/规则、对应 handler（文件/函数/类方法）
   • 对动态路由（如 {id}、正则路由、WordPress 参数路由）必须写出“解析规则与可控参数列表”

3. 枚举参数（必做）

   • 识别 Source：$_GET/$_POST/$_REQUEST/$_FILES/$_COOKIE、php://input、getallheaders()
   • 识别 JSON：json_decode(file_get_contents('php://input'), true)
   • 识别文件：$_FILES['{file_field}'] 字段与文件名来源（name/tmp_name）

4. 识别认证链与会话机制（必做）

   • Session：session_start()、$_SESSION['key']、登录态判断
   • JWT：JWT::decode、签名校验逻辑、Authorization: Bearer
   • Middlewares：Laravel middleware、Symfony event listener、Slim middleware
   • 自定义鉴权：checkAuth()/requireLogin()/authorize() 类函数

5. 生成鉴权映射（静态映射，先不依赖 trace）

   • 调用：php-auth-audit
   • 模式：STATIC_MAPPING（仅生成 auth_mapping_{timestamp}.md 用于 P0/P1 路由分桶）
   • 约束：当尚未生成 route_tracer/ trace 时，允许“缺少 trace 契约证据点”，但必须输出“鉴权状态分级 + P0/P1 分桶依据”

6. 供应链漏洞扫描（组件已知 CVE/Advisory）

   • 调用：php-vuln-scanner
   • 输出：vuln_report/{project_name}_composer_vuln_report_{timestamp}.md

7. 框架特效审计（可选：检测到对应框架才调用）

   • 检测原则（必做）：依据 composer.json 依赖与典型目录/入口文件特征识别 Laravel/Symfony/WordPress/CodeIgniter/Yii2
   • Laravel：调用 php-laravel-audit，输出 framework_audit/laravel_{timestamp}.md
   • Symfony：调用 php-symfony-audit，输出 framework_audit/symfony_{timestamp}.md
   • WordPress：调用 php-wordpress-audit，输出 framework_audit/wordpress_{timestamp}.md
   • CodeIgniter：调用 php-codeigniter-audit，输出 framework_audit/codeigniter_{timestamp}.md
   • Yii2：调用 php-yii-audit，输出 framework_audit/yii_{timestamp}.md
   • ThinkPHP：调用 php-thinkphp-audit，输出 framework_audit/thinkphp_{timestamp}.md

阶段 1 输出：

• routes_{timestamp}.md：完整路由清单（逐条）
• params_{timestamp}.md：每条路由参数来源与类型/结构（逐条）
• auth_audit/auth_mapping_{timestamp}.md：路由鉴权映射（含 P0/P1 分桶依据）
• vuln_report/{project_name}_composer_vuln_report_{timestamp}.md：组件漏洞清单（用于推断受影响路由）
• framework_audit/*_{timestamp}.md：框架特效审计报告（仅在阶段 1 检测到对应框架时产出）

阶段 2：建模（Modeling）

目标：建立 Source → Sink 数据流图的“可追踪版本”。

对每个路由，建立至少一条“从入口参数到敏感 Sink 的最短路径”，并记录：

• Source 参数名/数据结构字段路径（如 pageJson.orderBy 的 PHP 对应：数组字段路径）
• 中间变量名变化（assignment/concat/transform）
• 分支条件（if/switch/try/catch）与提前返回（return/throw）
• Sink 类型与调用点（文件/行号/函数名）

阶段 2 输出：

• 路由级数据流链证据（建议嵌入到 vuln_audit/* 或单独建 dataflow_tracer/，这里保持简洁：内联到漏洞报告中也可）

阶段 2.5：Sink-only 全局扫描兜底（提升召回，覆盖 RCE 及扩展高危）

目标：在路由枚举/trace-gate 失败或证据不足时，仍能通过“静态 Sink 命中 + 本地可控性回溯 + 执行点确认”找到高危点，并一律降级为 ⚠️待验证（静态证据），直至阶段 3/4 补证。

与阶段 3/4 的差异：阶段 2.5 面向全部 PHP 源文件做“宽谱 Sink 初筛”，不依赖路由完整性与 trace 完整性，产出进入降级候选池；阶段 3/4 则在路由+trace 完成后，针对 trace-gate 通过的 Sink 做“高置信度精确审计”。两者扫描范围可能重叠，但执行时机、目标精度和输出流向不同——阶段 2.5 的产出不会替代阶段 4 的确认结果，仅作为补漏兜底。

1. 扫描范围（不限定目录）

   • 从 source_path 根目录开始递归遍历，覆盖项目内所有 PHP 源文件（例如 *.php）。
   • 为减少噪音可默认排除 vendor/ 与缓存目录（如需最大召回可把排除策略关闭）。

2. 必覆盖 Sink 集合（最低集）（防 RCE/对象注入漏报）

   • CMD：exec/system/shell_exec/passthru/proc_open/popen/pcntl_exec 与反引号 `cmd`
   • EXPR：eval/assert 以及已弃用但仍常见的 preg_replace(..., ..., .../e) 风险点
   • FILE（执行面边界）：include/require 在“可执行内容/执行边界”上存在风险时（仅读取不等于 RCE，需确认执行语义）
   • DESER：unserialize(...) 在可控输入链上存在潜在魔术方法执行链（静态证据足够时再升级；否则待验证）

3. 扩展扫描（强烈推荐，防 SQL/SSRF/任意读等漏报）：在业务代码目录上，按 shared/PHP_SINK_REFERENCE.md 再扫一轮 SQL 执行族（query/exec/prepare+拼接线索）、SSRF 族（curl_exec/file_get_contents($url) 等）、任意读族（file_get_contents/fopen+路径拼接）。命中写入同一 sink_static_index_{timestamp}.md（或扩展 rce_sinks 附录），条目标注「扩展扫描」；结论仍为 ⚠️待验证 直至 trace 或对应 php-sql-audit/php-ssrf-audit/php-file-read-audit 闭合。

4. 每个命中点的本地分析（必须输出）

   • 位置：file:line、函数/语句、sink 参数表达式（原样摘录关键片段）
   • 可控性回溯：在同一文件/相邻调用链内追踪 sink 参数是否来自请求输入（get/post/request()->param()、$_GET/$_POST/$_REQUEST、JSON php://input 解码结果、header/cookie 等）
   • 执行点确认：若无法证明危险上下文真的会执行（例如分支提前 return/异常跳过/被过滤），结论必须降级为 ⚠️待验证

5. 输出与汇总规则（不依赖 route_id）

   • 输出到 {output_path}/global_sink_fallback/：
     • rce_sinks_{timestamp}.md：RCE/高危执行点静态命中清单（每条包含位置、可控性回溯证据、执行点确认与结论降级理由）
     • sink_static_index_{timestamp}.md：静态命中索引（用于质量统计与后续手工补全 trace）
   • 阶段 5 汇总时：在“质量报告章节”的“漏洞列表总览”中额外引用 global_sink_fallback/rce_sinks_{timestamp}.md，并将这些项标注为“静态证据（非 trace-gate）”。

フェーズ 3：バッチ単位のトレース（トレースで証明できる場合のみ）

目標：php-route-tracer による「実際の実行証拠」を通じて、脆弱性の調査を「キーワードスキャン」から「制御可能性と分岐証拠に基づく調査」へと引き上げ、真陽性を最大化します。

フェーズ 3 は、以下の順序で必ず実行してください：

1. 高リスクルートの集合を生成する：

   • auth_audit/auth_mapping_{timestamp}.md を読み込み、P0（❌認証なし）と P1（⚠️認証のみ、または 🔓バイパス可能／権限昇格／IDOR のリスクがあるルート）を抽出します
   • vuln_report/{project_name}_composer_vuln_report_{timestamp}.md を読み込み、解析の入口／機密機能に関連するコンポーネントの脆弱性のトリガーポイントを、影響を受ける可能性のあるルートに「推定マッピング」し、「推定理由」を記載します
   • 静的なパラメーターの手掛かりに基づいて SINK_SUSPECT ルートを追加します（trace の証拠ポイントには依存せず、trace-gate によるハードゲートの確認はフェーズ 4 で行います）
     • LDAP：パラメーター名／フィールド名に dn/baseDn/filter/searchFilter/ldap/filterString などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • EXPR：パラメーター名／フィールド名に expr/expression/condition/where/rule/eval などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • SQL：パラメーター名／フィールド名に sql/query/filter/orderBy/sort/limit/search などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • CMD：パラメーター名／フィールド名に cmd/command/exec/shell/run/path/filename などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • SSRF：パラメーター名／フィールド名に url/uri/target/host/port/protocol/path などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • FILE：パラメーター名／フィールド名に file/path/filename/download/view/document/template などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • UPLOAD：パラメーター名／フィールド名に upload/file/tmp_name/filename/multipart などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • WRITE：パラメーター名／フィールド名に write/put_contents/fwrite/fopen/rename/copy/truncate/error_log/dest/path/target/path などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • XSS：パラメーター名／フィールド名に content/body/comment/title/description/html などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • TPL：パラメーター名／フィールド名に template/view/engine/renderer/format/expr などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • XXE：パラメーター名／フィールド名に xml/doctype/dtd/xxe などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • DESER：パラメーター名／フィールド名に serialize/unserialize/payload/object/serialized などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • NOSQL：パラメーター名／フィールド名に filter/query/where/operator/op/regex/whereClause などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • REDIR：パラメーター名／フィールド名に next/return_to/redirect/target/url などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • CRLF：パラメーター名／フィールド名に header/cookie/location/set-cookie などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
     • ARCHIVE：パラメーター名／フィールド名に zip/tar/phar/archive/entry/extractTo/unzip/untar などのキーワードを含む場合（またはルートの params 内にあるその JSON フィールドパス）
   • route_id を合成する（必須）：項目が CLI／cron／キュー、WordPress hook、include チェーン、フェーズ 2.5 の静的 sink などに由来し、HTTP ルートがない場合は、安定した ID を使用する必要があります（空欄は禁止）。同じ行に entry_file（source_path からの相対パス）、entry_symbol（関数／メソッドまたは global）、trace_from（どこから sink に向けてトレースを開始するか）を記載します。推奨形式：ENTRY_CLI:{脚本標識}、ENTRY_CRON:{タスク名}、ENTRY_QUEUE:{コンシューマークラスまたはファイル}、ENTRY_HOOK:{hook 名}、ENTRY_INCLUDE:{ファイル}:{シンボル}、SINK_ONLY:{連番}:{ベース名}:{行番号}（sink_static_index と相互参照できます）。
   • 出力：cross_analysis/high_risk_routes_{timestamp}.md（P0／P1／SINK_SUSPECT を含み、すべての項目に route_id が必要です（合成 ID を含む）。php-route-tracer は route_id でタスクを識別します。トレースの起点は entry_file+entry_symbol+trace_from に基づき、ID が URI 形式である必要はありません。）

2. バッチ単位のトレース計画を生成する：

   • high_risk_routes_{timestamp}.md を読み込みます
   • バッチパラメーターの設定（必須）：順序は P0 → P1 → SINK_SUSPECT とします。trace_batch_max_size の既定値は 10で、プロジェクトに応じて 5–30 の範囲で調整できます。計画には選定理由を記載する必要があります（例：同じモジュールのルートはまとめてバッチサイズを大きくする。呼び出しチェーンが深い、複数ファイルにまたがる、パラメーターの対象範囲が広い、またはコンテキストの予算が厳しい場合はバッチサイズを小さくする）。
   • trace_batch_plan_{timestamp}.md の各バッチには、batch_id、このバッチで採用する trace_batch_max_size、選定理由（1～3 文）、このバッチの route_id の順序付きリストを含めます。
   • 出力：cross_analysis/trace_batch_plan_{timestamp}.md

3. トレーサーをバッチ単位で呼び出す（必須）：

   • 各バッチのルートに対して php-route-tracer を呼び出します
   • 出力：route_tracer/{route_id}/trace_{timestamp}.md

4. 発火条件（ハードゲート）：

   • trace にある種類の sink の「実際の sink 実行ポイント」が現れ、trace の契約チェックに合格し、かつ対応するパラメーターが trace の制御可能性マトリクスで「制御不能／実際の使用なし（ハードコード値で上書き）」ではない場合に限り、フェーズ 4 で対応する php-*-audit を発火できます

5. trace 契約チェック（必須）：

   • 各 trace ファイルには、次のセクション／見出しを含める必要があります（フィールド名は一致させ、変更してはいけません）：
     • ## 7) Sink Summary
     • ## 5) 参数可控性矩阵
     • ## 6) Sink 定位
     • ## 8) Trace 完整性声明
     • ## 9) Sink Evidence Type Checklist
   • trace 契約チェックに失敗した場合：
     • その route の trace を PARTIAL または UNRESOLVED として必ずマークします
     • その trace に基づくすべての脆弱性の状態を ⚠️要検証 に必ず引き下げ、✅悪用可能と確認済み と直接判定してはいけません

sink タイプの手掛かり、危険なパターン、必須検証に関する全文は、本リポジトリの shared/PHP_SINK_REFERENCE.md（セクション 3.1–3.16 および LDAP／EXPR）を参照してください。フェーズ 3／4 で trace に基づき、対応する php-*-audit を発火するかどうかを選別する際は、このファイルを基準とします。

フェーズ 3 の出力：

• cross_analysis/high_risk_routes_{timestamp}.md
• cross_analysis/trace_batch_plan_{timestamp}.md
• route_tracer/ 内の各トレース対象ルートの trace_{timestamp}.md（パラメーター制御可能性テーブルと分岐経路の証拠を含む）

ステージ 4：Sink 監査の実行（トレースで証明された場合のみ）

手順：

1. route_tracer/ のトレースから、「trace-gate」が必要な脆弱性カテゴリと「パラメーターの実際の使用状況」を抽出します（必ずトレース制御可能性マトリクスを基準にしてください）。
   • trace-gate カテゴリ：SQL/NOSQL/CMD/SSRF/FILE/UPLOAD/WRITE/ARCHIVE/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS
   • 非 trace-gate カテゴリ：CFG/CRYPTO/LOGIC/LOG（静的スキャンとコード設定の証拠に基づいて、対応する skill を直接呼び出せます。php-route-tracer の ## 9) … CFG を唯一の要件とはしません）。注記：php-route-tracer のチェックリストには CFG 行がありますが、これは補強証拠としてのみ使用します。php-config-audit などは、カバレッジマトリクスで否定的な証拠により不適用とされている場合を除き、ステージ 4 で必ず実行してください。
2. 該当したカテゴリに限り、対応するサブ監査 skill を呼び出します。その際、以下の「証拠の出典」ルールを満たしてください（キーワードだけから推測することは禁止です）。
   • カテゴリが trace-gate に属する場合：php-route-tracer の ## 9) Sink Evidence Type Checklist にある該当行（FILE/UPLOAD/WRITE/ARCHIVE/SSRF/SQL/NOSQL/CMD/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS）の証拠要点を、監査根拠として項目ごとに引用する必要があります（証拠ポイント ID は原文どおり一致させてください）。
   • カテゴリが AUTH の場合：php-auth-audit の TRACE_AUDIT モードを呼び出します（トレースの証拠ポイント ID を必ず引用してください）。
3. 疑わしい脆弱性ごとに、「悪用可能性の前提条件」を必ず出力してください：

• 認証要件：✅不要 / ⚠️ログインが必要 / ❌悪用不可の条件
• 入力制御可能性：✅完全に制御可能 / ⚠️条件付きで制御可能 / ❌制御不可（ハードコードで上書き）
• トリガー条件：分岐条件／例外経路／環境依存（データベースの種類、ネットワーク到達可能性）

4. トレース完全性のフォールバックルール（必須）：

   • trace_status = PARTIAL の場合：⚠️要検証 モードにのみ進めます（✅悪用可能と確認済み と直接判定してはいけません）。
   • trace_status = UNRESOLVED の場合：報告を黙って省略してはいけません。「リスクなし」と記載したり、レポートから消したりしてはいけません。総合レポートの 「未完了トレース／追加証拠待ちリスクプール」 に、該当する route_id ごとに個別の項目を設け、既知の断片（トレースの到達可能部分に基づく）、不足している証拠、次の推奨手順（トレースの補完／SINK_ONLY 静的詳細監査への追加／対応する php-*-audit の呼び出し）を記載します。そのルートがステージ 2.5 の静的検出結果と関連付けられる場合は、相互参照を記載してください。

5. ファイルシステム操作の監査（非 trace-gate、静的証拠主導）：

   • 呼び出し：php-filesystem-audit
   • 出力：vuln_audit/fs_{timestamp}.md
   • 判定ルール：ソースコードに基づいて特定した「ファイルシステム操作の証拠チェーン＋パス制御の出所＋TOCTOU／リンク回避の説明」に基づき、直接 ✅/⚠️/❌/🔍 を出力できます。php-route-tracer の証拠契約フィールドを前提条件とはしません。

最終的に、以下を提示してください：

• ステータス：✅確認済み / ⚠️要検証 / ❌悪用不可 / 🔍環境依存
• 深刻度と CVSS のマッピング（上記の計算式に従う）

ステージ 5：総合レポート（Report）

総合レポートに「品質レポート」セクションを作成し、以下を含めます：

• サブ skill／監査対象のカバレッジマトリクス：上記の「サブ監査カバレッジマトリクス（必須）」と同じ構造で、品質レポートの前方に配置します。ステージ 4 の実際の実行状況と一致させ、矛盾がないようにしてください。

• リスク統計表（🔴/🟠/🟡/🔵 の件数と CVSS 範囲）

• 脆弱性一覧（各項目から、本レポート内の対応する脆弱性詳細セクションを個別に参照）

• 「未完了トレース／追加証拠待ちリスクプール」（必須）：trace_status ∈ {PARTIAL, UNRESOLVED} の route_id、ステージ 2.5 の sink_static_index 内でトレースによりまだ閉じられていない項目、および「拡張スキャン」の検出項目をまとめます。「脆弱性一覧」と並べて掲載し、証拠不足を理由に記録を削除してはいけません（未完了 ≠ リスクなし）。

• カバレッジ：ルートカバレッジ、認証カバレッジ、Sink カバレッジ、重要分岐カバレッジ（省略せず「完了／要補完」で示してください。推奨しきい値：ルートカバレッジと Sink カバレッジは 90% 以上）

• フレームワーク固有監査の集計：framework_audit/*.md が存在する場合、そのリスクを統一タイプコード（AUTH/CSRF/TPL/XSS/SQL/LOGIC/CFG/SESS/SSRF/…）にマッピングし、件数と最高深刻度を集計します。また、集計内に「フレームワークリスクの出典となる framework_audit レポートファイル」を明記してください。

  フレームワーク監査の免除に関する注記：フレームワーク固有監査（Laravel/Symfony/WordPress/CodeIgniter/Yii2/ThinkPHP）は「静的設定／パターンマッチング」型の監査であるため、検出されたリスクは php-route-tracer の trace-gate や ## 9) Sink Evidence Type Checklist の証拠検証を経る必要はありません。フレームワーク監査の結果は、それぞれのルールに基づいて直接深刻度を分類し、統一タイプコードにマッピングできます。

• 証拠完全性スコア（Evidence Completeness）：すべての trace-gate sink タイプ（FILE/UPLOAD/WRITE/ARCHIVE/SSRF/SQL/NOSQL/CMD/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS）について、shared/EVIDENCE_POINT_IDS.md で定義された証拠ポイント ID の集合に基づいて計数します：カバレッジ% = 充足した証拠ポイント数 / そのタイプで必要な証拠ポイント総数 × 100%。表には不足している証拠ポイント ID（原文どおり一致させること）と不足理由（例：trace_status=PARTIAL/UNRESOLVED、証拠ポイントの特定失敗、パラメーターを制御できないなど）を記載してください。

ステージ 5.1：悪用チェーンの集約（必須）

• 呼び出し：php-exploit-chain-audit
• 「品質レポート」セクションの「脆弱性一覧」の後に「悪用チェーン集約」セクションを追加します。悪用チェーン集約レポートのチェーン一覧表と最短悪用チェーンを参照してください（引用のみとし、内容は重複させないでください）。

脆弱性詳細テンプレート（必須）

各脆弱性は、以下の構造に従う必要があります（今回の総合レポートの脆弱性詳細セクションに記載してください）：

### [{等级前缀}-{类型代码}-{序号}] {风险标题}

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 可达性 (R) | {0-3} - {理由} |
| 影响范围 (I) | {0-3} - {理由} |
| 利用复杂度 (C) | {0-3} - {理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {文件路径}:{行号} ({函数/方法}) |

#### 数据流链（Source → Sink）

（ルートごとに、代入／受け渡し／連結／検証／分岐を1行ずつ記載し、省略しないでください）

悪用の前提条件

• 認証要件：{不要／ログインが必要／特定の権限が必要}
• 入力制御可能性：{完全に制御可能／条件付きで制御可能／制御不可}
• トリガー条件：{分岐／例外／環境依存}

検証 PoC（実行可能なリクエストを必ず提示）

{HTTP Method} {完整路径与查询/Body} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

修正案

• 「コードの置き換え案」を主とし、安全な実装の要点を示してください
• コード内で修正漏れを検索する方法として、検索コマンド（bash/rg 形式）を提示してください

## 说明文档（审计 READMEs）
必须在本次总报告内生成以下附录章节：
- 如何识别 PHP 路由与参数
- 如何识别会话/JWT 并审计鉴权链
- 如何结合 `shared/PHP_SINK_REFERENCE.md` 做按类型的 Sink 挖掘与 trace-gate 对齐

## 自检与质量保证（强制）
在标记完成前，必须回答并自检：
- [ ] 「子 skill / 审计面覆盖矩阵」是否已对对照表**每一行**给出已执行/不适用/已延期，且不适用与已延期均附触发依据或否定证据？
- [ ] 我是否按 `shared/PHP_SINK_REFERENCE.md` 与 trace 结果覆盖了常见高危类别（SQL/NOSQL/CMD/SSRF/XSS/FILE/UPLOAD/WRITE/ARCHIVE/XXE/DESER/TPL/AUTH/CSRF/REDIR/CRLF/SESS/CRYPTO/CFG/LOG/FS）？
- [ ] 我是否覆盖 LDAP/EXPR（或矩阵中「不适用」已附否定证据）？
- [ ] 每条漏洞是否都有数据流链与可利用前置条件？
- [ ] 是否没有任何省略写法？
- [ ] 是否没有任何未替换的模板占位符？
- [ ] **「Trace 未闭合 / 待补证风险池」**是否已列出所有 `PARTIAL/UNRESOLVED` 及 2.5 未闭合静态命中，且与漏洞列表无矛盾？

## 子 Skill 对照表（能力清单 + 矩阵对齐）
下表为**必须出现在「子 skill / 审计面覆盖矩阵」中的行清单**。阶段 3/4 按 trace-gate 与静态证据触发对应 skill；**未执行**的行须在矩阵中标记「不适用」或「已延期」并满足矩阵列要求（禁止空行、禁止无理由跳过）。

1. 路由/参数：`php-route-mapper`
2. 鉴权：`php-auth-audit`
3. 深度追踪：`php-route-tracer`（用于任何需要可控性/分支证据的场景）
4. 组件漏洞（供应链）：`php-vuln-scanner`

5. 利用链聚合：`php-exploit-chain-audit`（在阶段 5.1 强制调用）

6. 文件系统操作审计：`php-filesystem-audit`（在阶段 4 以静态证据驱动执行）

按漏洞类别调用：
- SQL 注入：`php-sql-audit`
- NoSQL 注入：`php-nosql-audit`
- 命令注入：`php-cmd-audit`
- SSRF：`php-ssrf-audit`
- XSS：`php-xss-audit`
- 模板注入/SSTI：`php-tpl-audit`
- LDAP 注入：`php-ldap-audit`
- 表达式注入（非模板）：`php-expr-audit`
- 任意文件读取/路径穿越：`php-file-read-audit`
- 文件上传：`php-file-upload-audit`
- 任意文件写入：`php-file-write-audit`
- 归档解压路径穿越/Zip Slip：`php-archive-extract-audit`
- XXE：`php-xxe-audit`
- 反序列化/对象注入：`php-deser-audit`
- 认证/鉴权绕过/越权/IDOR：`php-auth-audit`（与鉴权状态、资源归属一起落入汇总）
- CSRF：`php-csrf-audit`
- 开放重定向：`php-open-redirect-audit`
- CRLF/响应分割：`php-crlf-audit`
- 会话与 Cookie 安全：`php-session-cookie-audit`
- 加密与密钥安全：`php-crypto-audit`
- 安全配置（CORS/错误暴露/安全头/危险开关）：`php-config-audit`
- 业务逻辑漏洞（Mass Assignment/竞态/状态机/流程绕过）：`php-logic-audit`
- 安全日志与监控：`php-logging-audit`