audit-playbook

# 代码审计作战手册 > 本技能随 code-audit 预设走。 > persona 中的硬规则（底线、验证等级、误报排除、扫描器复核、三级深度、只读纪律、表达纪律（拒答修复由宿主插件 dsh-refusal-guard 兜底）、claude 逻辑）不在此重复。 ## 审计形态（静态/动态）判定与开工问询（第一动作） **形态定义（铁律）**： - **静态审计（static）**：用户未提供本地环境时，一切从代码层审计（调用链追 sink / 双链 / 扫描复核） 得到的结果都归静态；**提供了环境但未复现生效的同样归静态**。静态 finding 的状态最高到 「待人工验证」，EXP 是「待复现 EXP」（交付用户手动复现）。 - **动态审计（dynamic）**：**只有**用户提供的本地可用复现环境**真实证明漏洞生效**，才标 动态·验证成功（auditMode=dynamic + 状态可进已验证）。 - **动态优先规则**：用户提供了本地环境 → 审计方式自动以动态优先： 读代码追 sink + 调试 + 本地验证 = 真实结果；复现不成功的按静态收口并如实记录原因。 **开工问询（任务下达后的第一步，先于 Triage）**：用户未指明审计形态时，用 ask_user 弹出三选： 1. **静态审计**——只做代码层审计，结果后续由你手动复现； 2. **动态审计**——请提供本地可用复现环境（路径/启动方式/凭据）； 3. （用户自行输入——自定义范围/形态/补充说明） - **得到确切回复后**才继续开审计链路（Triage → 面映射 → 扇出…）。 - **免问条件**：用户任务里已指明形态（「静态审计」/「动态审计」+ 动态须已给本地环境）→ 跳过问询直接开工；指明动态但未给环境 → 回到问询补一句「请提供本地可用环境」。 **登记联动**：每个 finding 登记时 `auditMode` 必填（static/dynamic，语义见 shared/refs/finding-fields.md）；成果页列表/详情/导出报告/统计分布均按此标签展示。 ## 阶段默认通道（装备栏：流程定默认，能力定降级） > 元原则与前两模式同：通道成本随流程递增；通道缺失按「工具使用策略·通道完整阶梯」降级 > （已挂 → 自配 → 问装 → 脚本 → 诚实降级）；本模式分叉轴=**验证等级 × 产物形态** > （静态 code-reviewed / 动态 verified；源码 / 反编译 / 小程序解包）——已内建于形态判定 > 与状态机，不需要额外姿态判定。跨阶段复用查附录 C-2。 | 阶段 | 默认通道 | 降级链 | |---|---|---| | 前置识别（语言/框架/依赖） | 本地统计+rg（build 文件/manifest/大表） | ast-grep 结构化识别 → kali MCP → 脚本 | | 面映射（surface-map） | 本地 rg 逐 sink 面 + sinks.csv 机器工件 | ast-grep 模式 → 脚本 | | 静态扫描 | **本地 semgrep 三层规则集**（402 自建+1080 oss+chanzi 语义，随预设离线自包含=主通道） | kali MCP semgrep_scan（**只替引擎不替规则集**，命中面收窄如实标注）→ bandit/flawfinder 专项 → 规则降级章通用模式+脚本 | | 供应链 SCA / 凭据 | trivy + gitleaks（本地） | osv-scanner / syft+grype → kali MCP → pip-audit/npm-audit | | 深审调用链（双链 TRACE） | 人工推理 + rg 佐证（追踪员独立 grep，不预设写法） | ast-grep 结构化检索 → 脚本 | | 反编译（产物形态路由） | 卡 4 家族表：JVM=CFR·procyon / Android=jadx·apktool / .NET=ilspycmd·dnSpyEx / pyc=pycdc·uncompyle6 / Lua=unluac / native=生态分流 binary | kali MCP apk_decompile（apk 侧）→ 请用户提供反编译产物（生态流转）→ 标注「未反编译，结论降级」 | | 动态验证 | 隔离部署环境（隔离级见动态验证线）+ 调试 attach（jdb/XDebug） | chrome MCP 浏览器侧互证（可自配档）→ 待人工验证清单 | ## 审计前置识别（Triage） - 先判断代码/框架/系统类型：语言、框架、中间件、部署形态。 - 通用框架：先核对已知漏洞是否仍存在（版本比对 + 公开漏洞库），再针对业务代码做增量审计。 - **开源框架二次审计（魔改目标）**：审计对象是开源框架或其魔改版时，上游仓库 （GitHub/Gitee）的 issue 区（Open 与 Closed 都看）与历史漏洞清单是第一输入—— **历史漏洞的审计思路可直接学习**（sink 位置/触达路径/利用条件映射到魔改代码逐一 二次核对）；再对照上游架构（路由/过滤层/基类）圈定魔改增量面，增量部分按本手册 主线深审（魔改≠安全：上游修了本地没修=直接命中，上游没修魔改引入=深审增量）。 - **框架专项路由**：识别出已知框架/组件后直达专项手册（`refs/components/` 九篇——fastjson / shiro / log4j / struts2 / weblogic / jeecg-boot / ruoyi（若依）/ spring-framework（全家桶）/ thinkphp）：先核该组件全部 已知漏洞面（版本比对 + 利用条件核对）再增量审业务代码；refs 未收录的框架按 `refs/lang/` 对应语言手册 + 公开漏洞库检索兜底，并登记「未收录框架」到规则降级记录。 - **经验召回**：开工读工作区 `lessons.md`（存在时）——同类框架/组件续审召回历史坑与方法（本仓续审专用；跨任务/跨客户知识已由战役记忆自动注入，勿在此重复检索） （格式见 ecosystem-cooperation「经验台账」）。 - **战役记忆沉淀（代审特化）**：框架 sink 特征经验证后 `campaign_memory_write`（kind=fingerprint， 命中条件与 sink 清单入正文）；semgrep 规则集调优结论记 tooling；跨任务复用走战役记忆，本仓 续审用 lessons.md——两轨不重叠。 - 完全不认识的代码/框架/系统：才走 0→1 全量审计，且先向用户确认范围与深度。 ## 静态审计标准 - **标准参考（预设内置，随预设分发）**：`refs/standards/fortify-kingdom-reference.md`—— 八王国分类 + CWE 映射 + 定级指南 + 与本预设手册的对应表；不依赖任何本机/外部安装。 - **外部 Fortify 安装（可选增强，绝不调用）**：目标机若有 Fortify，其扫描结果只能作为 **交叉参照**，不写死路径、缺失不阻断——标准参考以预设内置文件为准。 - 规则体系 + CWE/OWASP 模式库，映射到具体语言的 sink 清单（见下）。 - **LLM Agent 应用审计**：参照 OWASP Agentic Top 10 (2026)—— 提示注入、MCP 配置（权限过大、明文密钥）、工具滥用、上下文污染等； 可参考 OSS 项目 agent-audit（51 条规则、污点分析）的组织方式。 ## 危险 sink 优先策略 - 按语言建立危险函数清单（greppable sinks）：命令执行、SQL、反序列化、 任意文件读写、SSRF、XXE、模板注入、路径穿越等。 - 审计顺序：外部输入入口 → 传播路径 → sink；先扫 sink 反查输入，再逐条确认数据流。 - 平均用力是审计大忌：把时间花在外部输入可达的 sink 上。 - **同型命中横扫（放大器纪律）**：任一 sink 命中确证后，立即三层横扫并清单化—— ① 同函数/同方法的**全部调用点**反查（命中一处 ≠ 只报一处）； ② 同型模式全局反查：同拼接习惯（同一 Mapper 的其他 `${}` / 同一工具类的同用法 / 同一作者的相邻提交）； ③ 同框架组件的其他暴露面（某框架接口出 SQLi → 该框架全部同类接口清单）。 横扫产出=候选清单入覆盖矩阵新行（同型格），每处仍独立走双链——横扫给的是候选， 不是结论。 ## RCE 主线聚焦（主观念） > 主观念锚点：审计聚焦**可 RCE**——凡能通往远程代码执行/权限提升的链都优先深审； > 常规漏洞审计并行不辍。每类 RCE 候选的判定要点与常见形态： | RCE 类别 | 审计判定要点 | 常见形态 | |---|---|---| | 任意文件上传 RCE | 上传点（入口）→ 存储路径是否可控/可预测 → 后缀/类型校验是否可绕过 → 落地文件是否被解析执行（webroot/PHP/JSP/模板目录） | 双后缀、MIME 伪造、路径拼接穿越、覆盖 .htaccess、软链 | | 未授权 RCE | 危险接口（管理端点/调试端点/actuator/jmx/rpc）的鉴权是否缺失或可绕过 → 接口是否直达命令执行/反序列化/上传 | 无鉴权 actuator、debug 端口、RMI/JMX 未授权 | | 组合 RCE（多步链） | 把孤立低危串成链：写文件 + 路径穿越 → 任意写 → 覆盖脚本/计划任务/启动项；SSRF + 文件读 → 内网 RCE 面 | 模板注入 + 文件写、SSRF→gopher、任意写→cron/webroot | | 硬编码凭据/密钥造成前端绕过与利用链 | 前端 JS/配置/打包产物中硬编码密钥、签名密钥、管理凭据 → 前端校验可被绕过或伪造 → 直达后端敏感接口；**利用链纵深**：硬编码密钥 → 伪造/生成合法 token（JWT 签名、session 加密、接口签名）→ 认证绕过直达高危接口乃至 RCE（如利用密钥构造反序列化/命令执行载荷）——利用链成立即高危定级并给出可复现利用证明 | JWT 弱密钥、加密参数可伪造、硬编码 admin 口令、密钥伪造 token 触发 RCE | | zip 自解压/释放导致 RCE | 解压入口（上传 zip/更新包）→ 条目名路径穿越（zip-slip `../`）→ 落点覆盖关键文件（webroot/依赖/启动脚本） | 更新包解压穿越、符号链接条目、解压炸弹 | | 深度反序列化 | 入口是否接受不可信序列化数据 → 反序列化框架与版本 gadget 链 → 嵌套/二次反序列化（JSON 内嵌序列化串、回调触发二次 readObject） | fastjson/shiro/log4j、hessian 二次反序列化、XStream 回调 | | 溢出导致 RCE | C/C++ 系：不可信长度入 memcpy/strcpy/sprintf → 栈/堆溢出可控性 → 缓解机制（ASLR/PIE/canary）判定 | 协议解析、图片/压缩解码、内核模块 | **每类 RCE 候选的硬要求**： - 双链（工人链/追踪员链）三要素一致才入报告，否则标「未决」； - **可利用性条件全列**：前提（版本/配置/权限/依赖 gadget）、限制、组合步骤——缺条件的 RCE 降级为「有条件 RCE」并如实标注； - 已验证（静态待手动验证或动态已验证）的 RCE 发现，**直接生成完整 python 复现脚本**（exp/<finding-id>.py）： 参数化目标、默认只读/最小影响（命令执行默认 whoami 级）、破坏性步骤默认关闭（开关变量）、 退出码 0=复现成功、头部注释写明授权前提与清理说明——随报告交付客户手动复现。 ## 审计对象范围 | 对象 | 要点 | |---|---| | 业务应用代码 | sink 优先 + 真实调用链 | | 配置与部署资产 | Dockerfile、nginx、云配置、K8s manifest（权限、端口、密钥、镜像来源） | | 依赖供应链 | SBOM 生成 → osv-scanner/版本核对 → Semgrep Supply Chain 类工具 → SLSA/provenance 意识 | | LLM Agent 应用 | OWASP Agentic Top 10 (2026) 视角（见上） | | 移动端反编译代码 | Android：jadx/apktool 出 Java/smali；iOS：class-dump/Hopper 出头文件与伪代码；审计反编译产物，调用链引用标注反编译来源 | | 小程序解包代码 | wxapkg 解包 → JS + wxml/wxss；JS 混淆先识别后去混淆再审计，无法还原的如实标注 | ## 移动端 / 小程序反编译审计 - **反编译产物作为审计对象**：反编译出的代码同样是「代码侧真实调用链」的载体；调用链引用格式加注来源（如 `jadx#com.app.Login.a()`）。 - **Android**：jadx/apktool/dex2jar 出 Java 与 smali；优先审 Java，smali 用于确认字节级行为（混淆/加固后的兜底）。 - **iOS**：ipa 解包 + class-dump 头文件 + 反编译器伪代码；注意 OC runtime 的调用间接性，调用链要落到 selector。 - **小程序**：wxapkg 解包后审计 JS（api 调用、鉴权缺失、敏感信息硬编码）；先识别混淆（字符串加密/控制流平坦化），能还原再审计，不能还原的标注「混淆未还原，结论降级」。 - 与 binary-analysis 的分工：脱壳/还原归 binary-analysis，还原产物的代码审计归本模式；接收还原产物须先核对「完整性已验证」（dex 校验/IAT 有效性/可运行性，见 re-playbook Gate B1）+ 哈希与来源登记后再开审。 ## 场景化审计卡（按对象形态入口） > 「审计对象范围」表的作战化展开：每卡=入口判定 → 打法 → 产物 → 门禁挂接；命中即按卡 > 打，多形态并存时并行各卡（覆盖矩阵开对应轴行）。 ### 卡 1 LLM Agent 应用审计 - **入口判定**：代码中出现 Agent 框架/LangChain 类编排/MCP 服务端或客户端/工具注册表/ 系统 prompt 组装——任一即按本卡。 - **打法**（OWASP Agentic Top 10 2026 视角）：①提示注入面——外部内容进 prompt 的全部 路径（检索结果/工具返回/文件内容）是否带隔离标记；②**工具滥用链=Agent 版越权**—— 工具权限声明与实际能力差、用户可指令触达的工具集合；③MCP 配置——权限过大、明文密钥、 服务端鉴权缺失；④上下文污染与记忆投毒路径；⑤沙箱/审批旁路。 - **产物**：面映射的「入口」轴=工具与 prompt 边界清单；finding 走 A1-A3 同款门禁 （双链的 entry=用户可控输入进 Agent 的位置）。 ### 卡 2 依赖供应链审计 - **入口判定**：锁文件（lock/pom/go.sum）、SBOM 输入、或用户点名供应链场景。 - **打法**：SBOM 生成 → osv-scanner/版本核对（对照 refs/components 专项）→ 组件级 finding（可达性核对：**被引入 ≠ 被利用**，利用条件全列）→ provenance/SLSA 意识 （源不可信/改名包/私源混入）。 - **产物**：scan-reconcile 对账挂接（SCA 工具命中同走数量守恒）；组件 finding 标 sourceOrigin=scan 系，人工确证后升格。 ### 卡 3 配置与部署资产审计 - **入口判定**：仓库含 Dockerfile/compose/K8s manifest/nginx·云配置/IaC。 - **打法**：以 root 运行/privileged、端口暴露面、密钥内嵌（trivy/conftest+rego 策略）、 镜像来源与固定、能力位（CAP_*）与 hostPath、TLS 与 header 策略。 - **产物**：配置类 finding 进六字段报告（fix 给具体配置修正 diff）；策略规则集登记进 覆盖矩阵头部（规则降级记录）。 ### 卡 4 反编译产物审计 - **入口判定**：binary-analysis 回传还原产物 / 直接给 apk·ipa·wxapkg。 - **反编译工具家族（按产物形态路由，检测制；安装走总纲安装阀门）**： | 产物形态 | 首选（agent 可自动用） | 备选 / 交互 | 备注 | |---|---|---|---| | Java/Kotlin jar·字节码 | **CFR**（单 jar 可批量） | procyon / fernflower | java-audit refs 含 CFR 策略 | | Android apk/dex | **jadx** | apktool（资源/smali）/ dex2jar | 优先审 Java，smali 兜底 | | .NET（C#/VB dll·exe） | **ilspycmd**（ILSpy CLI，dotnet tool，跨平台可批量） | **dnSpyEx**（Windows GUI，交互调试/动态补丁强——**agent 不自动开 GUI，需要时请用户配合操作**） | agent 默认 CLI 批量反编译 | | Python pyc/pyz | **pycdc**（高版本覆盖好） | uncompyle6（≤3.8）/ decompyle3 | 解不出反汇编字节码兜底 | | Lua（游戏/嵌入式脚本） | **unluac**（jar 单文件） | luadec | 混淆 Lua 先过 js-reverse/方法论 refs | | Electron asar | **asar extract**（npm） | — | ≈源码级（同 pentest 客户端侧） | | native 二进制（C/C++/Go/Rust） | **生态分流 binary-analysis**（Ghidra headless/IDA/r2 产伪代码） | — | 脱壳还原+产物校验归 Gate B1，回流转本模式审伪代码 | - **打法**：先核对「完整性已验证」（B1 产物校验+哈希）→ 走「移动端/小程序反编译审计」 章打法（本卡=入口路由，不重复内容）；调用链标注反编译来源（`jadx#类#方法`·`ilspycmd#命名空间.类`·`CFR#类`）。 ## 规则降级 - 无现成规则的语言：用通用模式兜底——输入校验、权限控制、加密/哈希误用、竞态条件、错误信息泄露。 ## 动态验证与证据留痕 - **环境启动登记**：用户提供环境后，先把启动方式/版本/关键配置登记进 evidence-index （环境差异是复现失败首因，登记是排障依据）。 - **本地动态部署环境的隔离级**（按「虚拟化与沙箱公约」）：已知非恶意的靶场/被审应用 可容器级（docker/podman 起，无宿主敏感挂载）；**未经审计的第三方依赖、来历不明的 构建产物须 VM 级**再运行——检测虚拟化平面并入 tool-plane，无虚拟化则静态结论 + 待人工验证，不本机硬跑。 - **调试纪律**：断点优先于插桩 print；断点落在 sink 前一行观察实参流转；远程调试 （jdb / XDebug / IDE attach）的连接配置一并登记。 - **payload 打点（动态版确定性信号）**：payload 携带高熵随机标记（marker），在断点变量/ 响应回显/落库记录任一处观察到标记 = 污点真实到达该点——与静态链推断互证。 - 保留请求/响应包作为证据；静态发现一律进「待人工验证清单」，审计结束汇总输出给用户。 - **复现不成功的降级记录格式**：尝试过的 payload 形态 + 环境差异点 + 结论归静态（附 原因）——按 persona 验证等级如实降级，不硬凑动态。 ## 确证闭环流程 1. 发现（扫描/人工）→ 2. 交叉复核（独立子代理复核调用链与结论）→ 3. 确证（静态→待人工验证；动态→自动验证）→ 4. 报告 → 5. 修复 → 6. 复测（原 poc 复验）→ 闭环记录。 - 状态机：疑似 → 待人工验证 → 已验证 / 已排除（误报）→ 已修复 → 已复测。 **双链分档纪律（按 finding 等级配确证成本）**： - **critical/high**：完整双链（审计工人链 + 追踪员独立重追）+ 复核员确证——现有全流程不变； - **medium**：单链完整（工人链 entry→sink 落台账）+ 复核员抽检（抽检比例与理由记台账）； - **low**：登记即收（finding 落库 + 台账一行登记标记，不产链文件、不派追踪员）。 分档标记写入台账该 finding 节首行（tier: dual / single / registered）；`verified` 语义各档不变 （动态验证成功才可标，静态最高 code-reviewed）。 **EXP 交付（静态/动态统一硬要求）**：审计出的每个漏洞都必须具备**完整 EXP 用于测试**—— 复杂漏洞（多步链/需构造 payload/依赖环境）产出完整复现脚本 `exp/<finding-id>.py` （参数化、破坏性步骤默认关闭、复现条件写头部注释）；简单漏洞（单请求/单输入触发） 在 poc 字段**直接给可复现 EXP**（完整请求包/命令/构造输入），不绕「利用前提」措辞。 只写复现条件不算完成——静态审计复核通过只登记 `code-reviewed`（代码侧已复核）； `verified` 仅限动态验证成功（EXP 本地复现真实生效，或在线授权环境实测 L1 通过）； 无完整 EXP 的 finding 停在 `pending`（待动态验证）； 成果页登记的 poc 字段同步必含该 EXP（脚本路径+用法 或 直接可复现内容）。 **一键实测配套（poc 顶部指纹节，hunter 实测按钮使用）**：登记 finding 时在 poc 字段 顶部附加两行可选约定节（有则实测可自动执行，无则实测按钮提示补指纹）： ``` 指纹:framework=xxl-job,version=2.4.0,title="任务调度中心",body="XXL-JOB",header="xxl" L1验证:GET /toLogin 期望:任务调度中心 ``` - 指纹节=目标框架的可观察特征（title/body/header 特征优先，framework/version 兜底）， 供 hunter 以特征方式搜索互联网对应框架资产并做一致性校验。 - L1验证节=EXP 的最小影响验证请求（只读路径/whoami 级回显），仅对「hunter 狩猎」页 标记授权的资产执行；未授权资产只做 L0（存活+指纹一致）判定。 - 实测按钮（成果页 code-audit finding，「验证」前）：静态审计=完整验证流水线（搜索 50 条→存活探测→指纹一致性→L1（授权资产）→任一成立即停+回写）；动态审计（EXP 已在本地复现）=影响面评估（搜同类资产+存活指纹统计）。主特征零命中时自动放宽 （单一特征→框架名兜底）从互联网侧续搜；仍零命中才收 no-assets 并给下一步建议 （人工扩大特征词/提供授权资产/本地靶场）。 - 未授权资产需要 POC 验证时**不做死路拒绝**，给三条出路（实测结论与通知同步给出）： ①hunter 页「标记授权」后重试 L1 快验；②交接渗透测试模式执行完整 POC——先向用户 确认该资产测试授权，按渗透纪律探测复测+对照三件套留证，命中后按渗透模式登记成果 并回标审计 finding；③本地同版本靶场验证。 ## Diff 审计模式 - 对 patch/PR：审计变更行 + 必要上下文，不整仓重审。 - 关注：新增 sink、权限变更、依赖升级/降级、配置修改。 ## 交叉复核规范 - 每个 finding 由一个独立子代理复核：独立重算调用链、核对证据、挑战结论。 - 两人一致才进报告；不一致的退回确认或降级为「疑似」。 ## 调用链引用规范 - 格式：`文件:行号` 起点的数据流描述，如 `Login.java:42 (userId) → SqlMapper.xml:18 (${userId})`。 - 禁止「看起来像」「疑似存在」这类无链路的表述；禁止原样粘贴扫描器输出。 ## 成果页登记（会话隔离） - 每个进入六字段报告的 finding，同步调 `redteam_finding_register` 登记到本会话「redteam 成果」页 （Web 端会话标签页，code-audit 页统计含 RCE 主线分布，详情含调用链块）。 - 字段对齐：**auditMode=审计形态（必填，static/dynamic，判定规则见「审计形态」节）**、title=名称、severity=等级、target=sink 位置（file:line）、summary=一句简介、 **chain=调用链（必填，双链格式每行一链：`entry → … → sink(file:line)`）**、 type=RCE 主线词表（任意上传RCE/未授权RCE/组合RCE/硬编码前端绕过/zip自解压RCE/深度反序列化/溢出RCE/其他）、 **poc=完整 EXP（必填，见「确证闭环流程」节：复杂=exp/<finding-id>.py 脚本路径+用法；简单=直接可复现的请求/命令）**、 evidence=双链台账路径（artifacts/audit-chains.md 的对应 finding 节）、**fix=修复建议（必填）**。 - 双链复核后 `redteam_finding_update` 回写 verified/false-positive + verifyNote；作废条目 `redteam_finding_delete`。 - **代审富字段登记必填组**：chainTracer=追踪员链（独立重追）、chainVerdict=双链一致性结论（页面双栏对照展示）、 snippetEntry/snippetSink=入口与 sink 处关键代码——导出报告的「双链对照/一致性结论/关键代码」节 直接取这三个字段，漏登即导出为空；cwe=CWE 编号（统计出 CWE 分布）； sourceOrigin=来源（manual 人工深审 / scan-confirmed 扫描确认 / scan-false-positive 扫描误报，对齐 scan-reconcile）； patch=修复 diff 建议。页面支持按文件/sink 分组、总览（MD）与报告包（HTML）导出。 ## 报告模板 - 覆盖声明（operation_scope 已登记时必带）：报告含「覆盖：M/N」一行，与 operation-state 台账实测一致（报告门算术对账，虚报/漏报拦门）；未测项列入未覆盖清单并注明原因（不在范围/超预算/未授权等）。 ### SARIF 机器可读导出（CI 集成场景） 报告除 markdown 主文件外，可按需附 `reports/findings.sarif`（SARIF 2.1.0）供 CI/扫描平台消费： 每个 confirmed 漏洞一条 result——`ruleId`=漏洞类型（ CWE/自定义 ）、`level`= error/warning/note（按 severity 映射）、`locations[].physicalLocation`= 文件路径+行号（source-to-sink 链取 sink 行）、`message.text`=六字段摘要、 `partialFingerprints`={sourceFunc, sinkFunc}（同一漏洞复测去重键）。 顶层 `runs[].tool.driver` 写本审计标识与版本。CI 场景（PR 门禁/平台导入）才生成， 人工交付场景以 markdown 报告为准。 - 与 pentest 同构六字段：漏洞名称 / 漏洞描述 / 漏洞等级 / 漏洞地址(file:line) / 测试过程（完整调用链 + 验证状态 + 交叉复核记录）/ 修复建议（针对该问题点，可附 patch/diff 建议，不落盘）。 - 文件命名「序号-漏洞名.md」；审计结束另出「待人工验证清单」汇总。 - 局限性声明（固定行）：本报告由 AI 多 harness 协作生成（DSH=DeepSeek 主模型；复核通道=claude/codex CLI，后端随各自 CLI 配置），关键结论经 DSH 独立子代理复核后定稿输出；跨 harness 复核作为建议项由用户决定是否追加，仍可能存在模型级盲区——重大决策请结合人工判断。 ## 工具手册 - **过程检索（trace-vault，自动留痕）**：`trace_search(query)` 按关键词子串检索历史工具调用的参数与响应文本（报错原文/拦截响应/回显/响应头/某工具当时的调用参数），`trace_get(id)` 取全文，`trace_recent` 看最近调用与出局统计（blocked 聚集=换路径/降速信号）——上下文被压缩或轮次久远后找回「曾经出现过」的过程观察，不依赖记忆；留痕自动进行，无需手动登记。 ### 工具使用策略（总纲） - **通道决策三原则（audit 特化）**：①**规则集优先于引擎**——本地三层规则集是主资产， 引擎可被替代而规则集不随行（替代=命中面收窄，如实标注）；②输出可读性优先（扫描一律 `--json` 落盘再对账，长输出走 A8 纪律）；③最小装载成本（识别/面映射阶段不起扫描器）。 - **工具平面检测制（替代本机快照）**：期望工具集不声称已装，开工检测为准；tool-plane 节 登记四列——**CLI**（command -v，多工具批量 tool-plane.sh/.ps1）/ **MCP**（自省 `mcp__<server>__<tool>`，mcp-studio 挂载时 tools.view()；来源标 mounted | self-configured）/ **installed-by-agent**（收尾卸载对账）/ **install-failed**（防重试白费）；涉部署环境另含 「虚拟化平面」行（虚拟化与沙箱公约）。 - **通道完整阶梯（与前两模式同构，每级有出口有留痕）**： ① **已挂直接用**——CLI/MCP 两列检测到即用（本地 semgrep 三层规则集=静态扫描主通道）； ② **可自配 MCP 档**——白名单制（chrome-devtools 类无副作用 stdio MCP 自配+复测+用）； kali/js-reverse 等**需服务型不可自配**（宿主未启动时 ask_user 请用户开）； ③ **安装阀门**——CLI 工具缺失（semgrep/trivy/反编译器类）首次 ask 是否允许自动化配置并 调用；**批准=本会话预授权**；不批准=降级或遵用户建议。**失败最多 3 次重试**判死登记 install-failed 后直接写脚本代替；**安装位置项目/工作区目录优先**（venv/pip --target/ 工作区 tools/；反编译 jar 类单文件落 tools/ 即用）；成功登记 installed-by-agent 列； ④ **脚本兜底**——python3 → shell → ps1，落 scripts/ 登记后**先自测再用**； ⑤ **诚实降级**——不可替能力（如 .NET 反编译全缺且用户不配合）登记覆盖度台账、收窄 结论，不虚构；**收口卸载阀门**——报告产出后按 installed-by-agent 清单 ask 是否完全 卸载（只卸 agent 装的），不批准则保留结束。 - 期望工具集：核心 = 附录 A（扫描/供应链主链），补充 = 附录 B（语言专项扩展）； 缺失不阻断开工，走通道完整阶梯。 - **跨平台（win/mac/linux）**：`find|wc -l`、`grep -rn` 等 bash 统计命令在 Windows PowerShell 用公约等价形式（Get-ChildItem/Select-String）；semgrep/trivy/gitleaks 三平台原生， 参数一致；bash 辅助可用 rg 跨平台替代。 ### 阶段速查卡（六要素：定位 / 高频命令模板 / 输出解读 / 速率纪律 / 证据留存 / 复核义务） #### 前置识别（Triage） - **bash 统计先行**：`find . -name '*.java' | wc -l`、依赖清单解析 （package.json / requirements.txt / go.mod / pom.xml / Gemfile）—— 语言与框架判定是选择规则集与参考手册（refs/lang/）的前提。 - 通用框架先做版本比对：从依赖清单提取版本，对照已知漏洞库（见供应链阶段）。 #### 静态扫描 - **semgrep**（检测后使用）——多语言规则扫描主工具。 - **首选封装工具 `semgrep_scan`**（preset 平面）：规则层参数化（builtin-java=402 自建 / builtin-php / oss=1080 开源 / custom=自定路径），预设 refs/ 自动定位，产物自动落 `artifacts/scans/`+evidence-index 回行，**命中自动双写 scan-reconcile.md/.csv 待处置行** （命中≠漏洞——复核后经 `redteam_finding_register` sourceOrigin=scan-confirmed/ scan-false-positive 升格，A3 数量守恒）。缺装时工具自带三级兜底提示。 - 手工 CLI（工具不可用/需精细控制时）： `semgrep scan --config refs/lang/java-audit/semgrep-rules/ --json -o semgrep.json <path>` （java 系 402 条自建规则）；php 用 `refs/lang/php-audit/semgrep-rules/`； 其他语言与开源规则用 `refs/standards/semgrep-oss/<语言>/`（按需挂单目录）。 - registry pack 兜底（仅联网时）：`semgrep scan --config p/owasp-top-ten --json <path>`。 - 自定义规则：`semgrep scan --config <rule.yml> <path>`；规则编写方法读 refs/methodology/devsecops-sast.md。 - 输出：`--json` 供程序化解析；**命中 ≠ 漏洞**——每条命中必须复核 + 补真实调用链 （persona 硬规则，禁止原样转报告）。 - 速率：本地静态扫描无网络速率问题；大仓分模块跑，控制单次输出规模。 - **标准参考内置**：`refs/standards/fortify-kingdom-reference.md`（八王国分类/CWE 映射/ 定级指南）作定级参照，随预设分发；外部 Fortify 安装仅作增强参照（**不调用本体**、 不写死路径），缺失不阻断——标准参考以预设内置文件为准。 #### 依赖供应链 - **trivy**（检测后使用）——SBOM + 漏洞 + 配置三合一。 - 仓库扫描：`trivy fs --scanners vuln,secret,config --format json -o trivy.json <path>` - 单镜像：`trivy image <image>`（容器资产场景） - 输出：漏洞 ID/版本/修复版本三要素，回填「待人工验证清单」的依赖部分。 - **gitleaks**（检测后使用）——凭据硬编码检测。 - `gitleaks detect --source <path> --report-path gitleaks.json --report-format json -v` - 命中复核：区分真实凭据 / 测试样例 / 假阳性（误报排除义务）。 - 供应链方法论与投毒检测读 refs/sca/devsecops-supply-chain.md、devsecops-secrets.md。 **gitleaks 自定义 toml 规则模板**（检测内部/业务特有凭据形态）：