# Report

> report — 漏洞报告成稿收口

- Skill: `zhaji2333/report` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add zhaji2333/report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaji2333/report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: zhaji2333 (https://skillmd.com/u/zhaji2333)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/zhaji2333/report

---


# report — 漏洞报告成稿收口

> **EN**: This skill turns confirmed vulnerabilities into submission-ready DOCX reports. The body is in Chinese because the target platforms (Chinese SRCs, CNVD/CNNVD, EDUSRC) require Chinese reports; the methodology is language-agnostic. See README.md for an English overview.

> 这是**薄编排层**，只做一件事：把**已确认**的漏洞写成可直接提交给审核方的 **DOCX** 提交稿。
> 漏洞怎么挖、怎么验证不在本 skill 范围；但"什么漏洞够格写成报告"的**分层验证门已内联在本文**，自成一体。

## 何时用 / 何时不用

- ✅ 用：漏洞已确认（硬门过了）、准备成稿交付、扩大危害后更新报告、被驳回后追加申诉。
- ❌ 不用：还在挖 / 还在验证 / 只有单点信号没到终局 → 继续验证，别急着开报告。
- 成稿前若存在 `hunts/<目标>/CLUEBOARD.md`，证据链以板上「已证实」行为准（见 `hunt-clueboard`），不从聊天重新编出处。

**前置铁律**：无 PoC = 不存在漏洞；影响没落地到链路终局 = 不写报告。P3 以下不写。

---

## 分层验证门（成稿前必过，本 skill 自带完整判据）

> 分两层：**硬门**（所有漏洞必过，缺一不报）+ **按类型命门**（不同类型的"关键钥匙"）+ **质量项**（尽力，不卡报告）。

### 硬门（所有漏洞必过，缺一不报）

0. **先证伪（正常功能排除）** — 先假设"这就是正常功能"，主动跑否定实验去推翻它：未授权→用 `zzz不存在<时间戳>` 跑同协议，看是不是 catch-all/公开/样例；越权→用合法 body 重测排除 400 假阳性、POST 排除 SPA 回退；SSRF→确认是不是服务端正常连接功能而非越过边界。**证伪不掉，才可能是漏洞；证伪掉了，作废不报。**
1. **PoC 可复现** — 能直接粘贴 Burp 原始请求块，不需要额外解释上下文。
2. **真实业务影响（链路终局，危害要实际打出来）** — 拿到别人的 ≥3 个敏感字段真实数据 / 操作真实生效改了别人业务状态 / 凭证实际访问到敏感内容。是数据泄露/账户接管/资金损失/服务端 RCE/内网横向的**终局结果**，不是中间信号（文档/token/拓扑泄露不是终点），不是"理论上有风险"。打不出实际危害 = 信号作废 = 不报。
3. **服务端/权限边界确认** — 是服务端或权限边界问题，不是浏览器 JS 假象/调试功能/页面渲染。
4. **类型命门** — 命中下方按类型命门表中对应行的硬条件。
5. **链式追问到终局** — 已顺根因穷举同类接口 + 纵深追到危害边界（不是问一层就交），或已记录"为什么到此为止"。

### 按类型命门表（不同类型，关键钥匙不同）

| 漏洞类型 | 命门（硬条件） |
|---------|--------------|
| 数据泄露 | 别人的数据 + ≥3 敏感字段 + 非公开/非样例/非模板；自己测试账号数据 ≠ 漏洞 |
| 越权 / IDOR | **A/B 交叉证明**：A 拥有的资源，B 的 token 能读/改；只读到自己不报 |
| RCE / 命令执行 | 真实命令执行实证；"别人的数据"对 RCE **天然不适用**，能执行命令本身就是危害 |
| SSRF | 服务端发出（回调 UA 证明 Java/Go/Python，非客户端 JS fetch）+ **有官方靶场必须先过靶场（不过不收）；无靶场必须回显内网数据**（云元数据/内网服务 banner/内网页面内容）。**DNSlog 只是其中一步**：出网响了 = 敲门砖，必须继续打到回显/危害终点，仅 dnslog 记录直接交 = 半成品不收 |
| 认证绕过 / ATO | **任意**用户可绕过/接管，不只证明自己能登自己号；OAuth/JWT/密码重置逻辑要 A/B 双账号证明 |
| 业务逻辑 / 资金 | 操作**真实生效** + 影响的是他人业务状态（金额/订单/状态机跳转），不是自己测试数据 |
| 文件上传 | **造成实际效果才算**：webshell 可执行（getshell）或存储型 XSS 触发（HTML/SVG 被服务端解析）；只传上去/能访问但纯存储不解析 = 不成立 |
| 注入 (SQL/NoSQL/SSTI/XXE) | 有确定输出/副作用证明（错误回显、时间差、OOB marker），不是"报错就报"；**SQL 注入最低共识 = 注出库名 `database()`**（盲注需时间差 + 库名内容，特殊情况另议） |

### 质量项（不卡报告，写进报告说明即可）

- **否定实验**：对存疑结论写出"如果这不是漏洞，最可能的解释"并执行证伪。
- **跨环境复现**：两个 IP/浏览器/账号/机器之一复现。
- **WAF/防护绕过已记录**：有防护→试了哪些绕过→结果；无防护→说明确认方式。

### 0day / 通用产品漏洞：收录审查门（按 0day 成稿前必过）

> 各收录平台（CNNVD/CNVD/补天/厂商 SRC 等）规则取**最严并集**，任一否决项命中 = 不按 0day 成稿。

**A. 版本与公开性（最新版不带洞 = 不是 0day）**
- [ ] 漏洞在厂商**当前最新版仍存在**：GitHub 漏洞文件引入时间 vs 最新 release tag 日期对比 / 官网下载最新版实测 / 厂商安全公告与 changelog 检索，三选一。只在未发布分支或老版本存在 → 不按 0day 成稿
- [ ] 老版本洞例外：最新版已修但老版本测绘存量巨大 → 报告必须写清受影响版本范围 + 修复版本 + 修复 commit/版本对比证据
- [ ] 未完全公开：无 CVE/CNVD/CNNVD 编号、无公开 PoC/分析文章/厂商公告；OEM/同源源码产品任一已公开 = 全线视为公开
- [ ] 产品本身三年内官方有更新维护（废弃/测试/演示系统不收）

**B. 类型与前提（平台明文不收的类型，一票否决）**
- [ ] 非通用型弱口令/默认口令；非"需账号密码/验证码登录后台为前提"；非用户配置不当/主动暴露；非沙箱预期功能 RCE；非单纯盲注/仅延时无明确危害；非未越权的 DOM/反射 XSS
- [ ] 同根因多个同类问题并为一洞；同系统相似类型历史只发一次
- [ ] 危害已实证（数据/权限/RCE 终局），非"存在可能性"

**C. 案例与证据**
- [ ] 黑盒底线 ≥10 互联网案例（3 个详细 + 10 个以上其他）；目标高奖金档位需更多独立 IP（按目标平台档位对齐，成稿前如实告知预期档位）
- [ ] 证据 2 周内（事件型 3 天内）+ 保留时间戳；案例 IP 提交时现场验证存活
- [ ] 测绘语法精准 + 独立 IP 数 + 统计来源与时间进报告
- [ ] 白盒另需：代码审计/逆向过程 + 准确版本号 + 当前最新版本证明 + 待测试程序

**D. 投递纪律（诚信红线）**
- [ ] **一洞只交一家**（多交会被各平台拉黑/信用评估）。交前定主平台路由：未授权前台 RCE → 通用漏洞高奖金平台；认证绕过/文件读取/凭证泄露等非 RCE → CNNVD/CNVD 类；老版本洞 → CNVD/CNNVD 类；教育行业资产 → EDUSRC
- [ ] 附件齐套：Word 报告 + POC/EXP + 待测试程序 + 复现录屏（按目标平台要求）

---

## 核心写作标准：双重可读（每份报告都要同时做到）

报告必须**同时**满足两个维度，缺一份都不合格：

**① 小白可复现** —— 让完全不懂安全的审核者也能照着一步步复现出来：
- 每个 Step 让人看懂：**做什么** → **在哪个 URL 操作** → **实际看到什么结果**；不跳步、不省略上下文、不用只有安全圈才懂的黑话而不解释。
- 但"能复现"≠啰嗦：背景交代一两句够用，禁止八股标签和填充语（见下方「简洁硬规」）。
- PoC 给可直接复制粘贴的完整 Burp 原始 HTTP 请求块（**不放 curl**），配真实截图，照做就能看到同样结果。
- 逻辑连贯顺滑，像一条能走通的路，不是散落的证据堆。

**② 技术不空洞** —— 该有的技术深度一分不能少：
- 讲清**根因**：为什么会有这个漏洞（鉴权缺失在哪一层/逻辑缺陷在哪/信任边界哪里破了）。
- 讲清**原理**：接口如何工作、参数如何被利用、鉴权差异如何证明、payload 为何生效。
- 给出**关键技术证据**：真实请求/响应字段、路由映射、代码片段、鉴权头对照、规模化数据统计。
- 结论有据可查，不是"我觉得有问题"，而是"因为 X 技术事实所以是 Y 漏洞"。

> 判断标准：一个产品经理照着能复现，一个安全工程师看了觉得技术扎实、无懈可击。两个都过才算合格。

---

## DOCX 版式规格（格式基准，不得自由发挥）

**生成方式**：python-docx。从同目录 `template.docx` 复制起步（已含全部样式），逐节 append。**不要**手写 HTML 再转换。

**样式**（模板已内置，直接用样式名）：
- 正文 `Normal`（微软雅黑 11pt）；章节标题 `Heading 2`（13pt 加粗）；Step 标题 `Heading 3`；bullet 用 `List Bullet`。
- **全文统一黑色**：模板已去除 Word 默认主题蓝（Heading/Title/边框全部 000000），标题与正文颜色一致。生成时不得再给任何文字/边框手动设置彩色。
- 不用表格堆排版、不用卡片/配色——审核接受的是朴素的线性文档。

**章节骨架**（Heading 2 按此顺序，可选节用〔〕标注）：

| 章节（Heading 2） | 内容要求 |
|------|---------|
| 漏洞名称 | 一句话：`资产 存在 漏洞类型 + 终局危害 漏洞` |
| 漏洞等级 | 严重/高危/中危 + 一句定级依据（标题就叫"漏洞等级"，不加"自评"等后缀） |
| 漏洞类型 | 类型全称 + CWE（如有） |
| 漏洞影响资产 | 主资产域名/范围 + API 路径 + 关联资产 |
| 漏洞URL | 纯 URL 列表，一行一个，**不写注解**（"它是干什么的、参数怎么被利用"归漏洞描述讲） |
| 漏洞描述 | 功能如何工作 → 根因 → 攻击者能干什么（编号列点）→ 关键验证结论（规模数字/IP/已确认事实） |
| 〔测试账号与会话上下文〕 | 测试角色、account_id、复验用 Cookie/token（注明"过期重登替换即可"） |
| 漏洞复现步骤（POC） | 见下方 Step 规格 |
| 漏洞危害 | 危害枚举（编号，每条带已验证事实）+ 影响数据明文样本（便于审核直接验证，不打码）+ 边界声明（未做的越权动作）。就这一节，不另开"影响数据示例" |
| 修复建议 | 具体可执行（编号，含网段/参数级细节；根因已在漏洞描述讲清，不另开"根因分析"节） |

报告正文到「修复建议」为止。**「复验清单」「建议评级说明」「实际攻击场景」「根因分析」「漏洞关键点」「影响数据示例」一律不单开节**——复验走上方分层验证门（内部动作）；定级理由只保留「漏洞等级」里的一句；攻击链时序和根因并进漏洞描述；数据样本并进漏洞危害。

### 0day / 通用产品漏洞：走通用型漏洞报告模板

**成稿前先过上方「0day 收录审查门」**（A 版本公开性 / B 类型前提 / C 案例证据 / D 投递纪律，任一否决项命中不成稿）。审查门没过 = 不按 0day 交付，回挖掘或换平台通道。

0day、通用产品漏洞**不用上面的 SRC 章节骨架**，一律按通用型漏洞报告模板成稿。章节顺序：

漏洞报告标题 → 漏洞发现时间 → 漏洞技术类型 → 漏洞描述（两段式：第一段产品介绍、第二段成因+危害）→ 漏洞危害 → 漏洞厂商全称 → 已知受影响产品及版本（附资产-产品强相关证明截图）→ 互联网资产证明（精准测绘语法 / 独立 IP 数量文字描述 / 测绘平台截图）→ 1、漏洞技术细节（完整 PoC：Burp 请求块+每步真实截图；触发条件）→ 2、复现证明（黑盒：3 个详细案例 + 10 个以上其他受影响目标）→ 3、修复方案（厂商修复 + 运维临时方案）→ 4、备注（边界声明）。

- 案例 IP 必须**提交时现场验证存活**，宁换不凑（云上动态实例隔天就会掉线，演示目标死掉会导致审核复现失败）。
- 测绘数据用测绘平台 API 取**当日口径**（独立 IP 数/国家分布/端口分布），测绘平台截图贴结果页。
- PoC 请求块用等宽字体段落；每步真实截图、不打码、不放 curl 等既有硬规全部沿用不变。

**Step 规格**（POC 章节内，每步严格这个结构）：

```
[Heading 3] Step N：一句话标题
[Normal] 一两句话交代这步做什么、在哪个 URL 操作（必要背景并入此处，不写"为什么:"标签）
[Normal] PoC:
[Normal] POST /path HTTP/2          ← Burp 原始请求块整段贴入（纯文本段落，不打码）
Host: ...
...
[Normal] 结果: 一句结论（证明了什么）。**不贴返回数据包原文**——响应内容以截图为准，文字只写结论
[Normal] 截图(说明这是什么的截图):
<内嵌图片>                          ← docx.add_picture，紧跟"截图"段
[Normal] 图：xx_说明.png            ← 图注一句
```

**简洁硬规（违反即返工）：**
- **禁止"为什么:"/"操作:"这类八股标签**，Step 用一两句自然语言交代动作即可；背景知识确有必要才写，能省就省。
- **同一事实全文只出现一次**：IP 清单、测绘数字、版本号、实证结论，写在哪一章就只在哪一章；其它章节需要时用"见漏洞描述"式指代，不整段复读。
- **相邻章节不得内容重叠**：漏洞描述讲清链路和结论后，后续章节需要时用"见漏洞描述"式指代，不整段复读；漏洞危害每条一行事实，不展开复述攻击过程。
- **一句话能说完的不写三句**：删掉"值得注意的是""也就是说""换句话说"类填充语，删掉对截图内容的文字复述（截图就在下面）。

**去AI腔硬规（违反即返工）：** 报告要读起来像安全工程师手写的，不像模型生成的。
- **内部方法论黑话不进报告**：证伪/否定实验/同根因/命门/链路终局等过程词一个都不出现。这些结论用自然语言陈述事实（"同框架其余接口鉴权正常，排除是公开查询功能"），不点名方法论。
- **禁止破折号拖尾解释**：结果一句话写完，不用"——证明了……/——即……/——说明……"收尾；结论确有必要时独立成短句。
- **禁止形容词渲染**：删掉"极具迷惑性""防骗难度极大""恶性竞争""天然构成"类修饰，只摆事实，严重性由审核者自己判断。
- **禁止截图元描述**：不写"下图为浏览器内实时请求后将响应转表格展示"这类关于截图本身的说明；截图处只有"截图（内容）:" + 图片 + 一句图注。
- **bullet 不强行"主题词："排比**：一事一句自然陈述，类别前缀只在确有助分类时用。
- **不单独开节游说评级**：「建议评级说明」不进报告（重申）；定级依据只在「漏洞等级」留一句，升级理由融进漏洞危害的事实里。

---

## 成稿流程（按序执行）

### 第 0 步：查重（写之前必做，命中重复就停）

写任何新报告前，先 Glob/Read 目标单位的报告目录，按**四项**查重：

```
资产（同域名/IP）  根因（同一鉴权缺失/同一逻辑缺陷）  接口/功能点  影响面
```

- 四项高度重合 → **不新写**。要么作为原报告的补强（见第 5 步），要么换资产/换漏洞类型。
- 只重合资产但根因/影响不同 → 可新写，但报告里说明与已有报告的区别。

### 第 1 步：过分层验证门（判据见本文「分层验证门」节）

逐条打勾，硬门缺一不写：

```
[ ] 硬门0 证伪：假设"这是正常功能"并跑了否定实验，证伪不掉
[ ] 硬门1 PoC 可复现：能直接粘贴 Burp 请求块，不需额外解释
[ ] 硬门2 危害是链路终局：资金/数据/接管/RCE/横向，不是中间信号
[ ] 硬门3 服务端/权限边界确认：不是浏览器 JS 假象/调试/渲染
[ ] 硬门4 命中类型命门（见上方按类型命门表对应行）
[ ] 硬门5 同根因接口穷举完、纵深追到边界，或记录"为什么到此为止"
[ ] 质量 否定实验：对存疑结论写出"如果这不是漏洞最可能的解释"并证伪
[ ] 质量 跨环境/跨账号/跨IP 至少一种复现
[ ] 质量 WAF：有防护记录绕过；无防护说明确认方式
[ ] 截图 每一步都有真实截图（浏览器打开原始 URL / Burp Repeater 实际响应），无一处自造渲染
[ ] 双读 小白照着能复现（操作→PoC→结果）且技术不空洞（根因+原理+关键证据）
```

硬门全过 → 写。质量项缺 → 不卡报告，但报告里说明。

### 第 2 步：生成 DOCX

复制 `template.docx` → python-docx 按「DOCX 版式规格」逐节填充。要求：
- 每个 Step 的截图用 `doc.add_picture(png路径, width=Inches(6))` 内嵌，紧跟"截图(...):"段落。
- PoC 请求块保持等宽可读：整块作为独立 Normal 段落（可用单个段落内换行），**不打码**。
- 数字、IP、marker、时间等所有事实**必须与截图/原始日志逐字一致**——写完回读截图核对一遍。凭记忆写数字极易出错（真实教训：一份报告里 DNSLog 数字凭记忆写了四处，全错，复核时才抓出来）。

### 截图铁律（最高优先级，绝不违反）

**报告每一步都必须配真实截图，绝不允许自己 PS/仿造/手绘渲染效果。**

- 截图来源只能是：浏览器打开目标原始 URL/响应后截图（可用浏览器自动化工具的截图能力）、Burp Repeater 实际请求/响应截图。
- 凡绕过限制后能在浏览器直接打开渲染的图片/视频/页面/文件/JSON 响应 → **必须用浏览器打开原始 URL 截图**放进报告。
- 每个 Step 的关键结果都要有对应截图，让审核者能看到"我确实在真实目标上看到了这个"。
- **唯一例外**：目标内容客观无法在浏览器渲染时，才允许离线渲染/转存，并在报告里**明确写出为什么无法用浏览器直接截图**。
- PoC 数据包以文本完整保留即可，审核方会另行核对，不强制截图（但有 Burp 截图更好）。

截图 PNG 与 DOCX 同目录留存备查（如 `reports/<单位>src/shots/`），DOCX 内图片为内嵌副本。任务收尾时截图随报告保留，不删。

#### 截图能力检测与降级（开工前先判定，三级阶梯）

**AI 不是天生会截图**——截图能力来自浏览器自动化工具（MCP）。成稿流程开始时先检测当前环境，按三级阶梯走：

1. **自动检测**：检查当前可用工具列表，凡是能"打开 URL + 截图"的都算——Playwright MCP、chrome-devtools MCP、Puppeteer MCP、js-reverse 等浏览器类 MCP 提供的 navigate/screenshot 工具。**检测到就直接用**，每个 Step 由 AI 打开原始 URL 自动截图，无需询问用户。
2. **没有工具 → 给建议**：明确告诉用户"检测到当前环境没有浏览器工具，无法自动截图"，并给出推荐安装命令（如 `claude mcp add playwright -- npx @playwright/mcp@latest`）。用户愿意装 → 装完回到第 1 级全自动。
3. **用户不装 → 人工供图**：每到一个需要截图的 Step，明确告诉用户"请把这一步的 Burp/浏览器截图保存为 `shots/step<N>_<说明>.png`"，用户放好后嵌入对应位置。**禁止**因为没工具就静默跳过截图、用"此处应有截图"占位、或用文字描述代替。

用户也不提供截图 → 报告不满足截图铁律，明确告知"缺真实截图的报告大概率被平台驳回"，由用户决定是否继续，不偷偷降级成无图报告。

#### 提交前自检（交稿前必过）

- [ ] 截图裁掉/遮盖：任务栏、本机用户名（含路径里的用户名）、其他浏览器标签页标题、书签栏、浏览器登录头像
- [ ] Burp 请求块：不含与漏洞无关的个人标识（自己的 cookie/token/测试账号之外的隐私信息）
- [ ] PoC/正文：本地路径打码；IOC 按目标平台风控规则脱敏（有平台会因正文含特定 IOC 关键词整单拒收，被拦时二分定位脱敏）
- [ ] DOCX 元数据：作者/公司字段清空（生成后检查 docProps/core.xml）
- [ ] 报告内不留测试基础设施细节（代理、接码、邮箱服务商等）

#### 去 AI 腔检查（交稿前必过）

平台审核开始用 AI 检测+人工直觉筛报告，模板化 AI 腔会被降权/忽略。逐条过：

- [ ] **句式人化**：消灭"首先/其次/综上所述/值得注意的是"类连接词；长短句混排，允许口语化短句（"这里直接就断了""这步没拦"）
- [ ] **结构去模板**：不机械分"漏洞描述/漏洞危害/复现步骤"八股标题堆砌；按这个洞的叙事顺序走（怎么发现的→怎么验证的→打到什么）
- [ ] **删掉正确的废话**：危害段不写"攻击者可能利用该漏洞造成严重影响"类空话，只写实际打出来的东西
- [ ] **保留人味细节**：复现里带上真实判断痕迹（"一开始以为是 X，测了 Y 排除"），这种否定实验过程 AI 腔写不出来，也是审核信任点
- [ ] **术语不翻译腔**：直接用 Burp/越权/getshell 等行话，不写"未经授权的访问漏洞（IDOR）"类教科书腔
- [ ] **列表节制**：满屏 bullet 是 AI 指纹；能一段话说清的不拆列表

### 第 3 步：语义化命名

文件名格式：`资产 存在 漏洞类型 漏洞.docx`

```
api.example.com 存在订单接口越权读取他人敏感信息漏洞.docx
console.example.com 存在文件上传绕过致存储型XSS漏洞_详细复现_2026-08-01.docx
```

阶段总结类可用：`单位SRC测试工作存在阶段总结报告.docx`

### 第 4 步：放对目录

报告统一放 `reports/` 下按单位/类型分目录：

| 目标 | 目录 |
|------|------|
| 企业 SRC | `reports/<单位>src/` |
| EDU | `reports/edu报告/`（根目录，不放子目录） |
| 0day / 通用产品 | `reports/0day/`（走通用型模板；报告内需含测绘语法、独立 IP 数、统计来源和时间） |
| 其他新单位 | 在 `reports/` 下新建 `<单位>src/` |

**只有确认漏洞的最终 DOCX 进这里**。JS/抓取归档/临时产物一律不进，任务结束即删。

### 第 5 步：更新 vs 驳回（两种截然不同的处理）

- **正常补强 / 扩大危害**（未被驳回）→ **融合改写**：把新证据整合进对应章节（描述/Step/危害/评级），必要时重排 Step、替换旧证据为更强证据，重新生成一版干净 DOCX。**不要**在底部堆"补充/追加/扩大说明"。
- **被审核驳回 / 需申诉**（明确被打回）→ **底部追加**：保留原报告上下文，在 DOCX 底部追加"驳回后补充说明/复核证据/申诉证据"（Heading 2 + 同样 Step 规格），不覆盖不另起；关键 PoC 发送到 Burp Repeater 便于复核。

### 第 6 步：收尾

- 只保留 DOCX（+ shots/ 截图源文件），删除对应临时目录/中间产物（Markdown 稿、转换中间文件也删）。
- 确认漏洞后写复盘记录（什么信号命中的、哪步卡过、下次怎么更快）。

---

## 硬约束速查

- **每一步配真实截图**，绝不自己 PS/仿造渲染；来源只能是浏览器打开原始 URL / Burp Repeater 实际响应。PoC 数据包保留文本即可。
- 报告内证据**不打码**（提交稿要能被平台验证）；普通聊天里可摘要。
- 只写能证明**非公开、他人数据、真实业务影响**的证据；公开内容/默认样例/自己测试账号数据 ≠ 危害，不写进危害。
- 单纯密钥/token 泄露不单独成报，只作高危链证据。
- CORS/安全头/版本号/Cookie 标志位/Self-XSS 不成报。
- 报告最终产物只有 **DOCX**，不留 HTML/Markdown。