Imported from a23882/instant-transmutation (skills/审计基础方法类/Source到Sink数据流追踪/SKILL.md). Install upstream with npx skills add a23882/instant-transmutation --skill Source到Sink数据流追踪. Copyright stays with the author.

Source到Sink数据流追踪

权威边界

本 Skill 只保留审计方法，不定义 JSON schema、报告模板正文、提交资格状态、账号对象矩阵字段或完成核验规则。

• 字段、状态族、EVID 命名以对应中文 schema、template 和 validator 为准。
• 报告版式只引用 templates/单漏洞提交报告模板.md、templates/赏金提交总入口模板.md、templates/完成核验模板.md，本 Skill 不复制模板正文。
• 账号对象事实只引用账号对象矩阵和证据链；本 Skill 不重新定义账号对象矩阵字段、平台表单或正文写法。
• 提交资格只由 evidence/赏金资格.json 和报告与复核类提交门禁裁决；本 Skill 只提示需要外部门禁，不生成提交资格状态。
• Web 浏览器复现、截图、trace、network、console、storage/session 证据必须按 skills/审计基础方法类/PlaywrightMCP运行证据归档/SKILL.md 归档并回链 evidence。

如何使用这个 Skill

使用本 Skill 时，把它当成“漏洞证据链闭合器”，不是危险函数词典。它适合在以下场景启动：

• 已经看到一个可疑 source，想知道它是否真正进入 SQL、命令、文件、模板、SSRF、鉴权等 sink。
• 已经看到一个 sink，想反向追踪参数来源、可控性、防护和触发条件。
• 扫描器、规则、正则、IDE、CodeQL、Semgrep、SAST、DAST 或其他模型/工具 给出告警，需要人工复核。
• 框架项目里出现“非标准写法”：绕过框架输入封装、绕过 ORM、禁用默认中间件、raw 输出、原生查询、整体对象写入、动态表达式。
• 需要把一条发现裁决为 technical_confirmed、candidate、blocked 或 rejected。
• 需要写漏洞报告相关 evidence 中的 Source、Sink、Trace、防护缺口、强验证、负控、修复建议和声明边界。

使用前先明确本次 trace 的单一目标：

入口是什么 -> 哪个 source 可控 -> 哪个变量/字段承载 taint -> 经过哪些调用/分支/transform -> 到达哪个 sink 的哪个危险参数 -> 是否有有效防护 -> 如何证明影响与负控

如果这条 trace 未来要进入报告，还要同步确认：官方安全模型是否支持该声明、对象/租户边界是否被突破、以及攻击者是否真的能拿到所需标识符。

每次判断的最小交付

每次写结论前，至少把下面几件事交代清楚，缺一项就先降级，不要抢着下 technical_confirmed：

• source 的控制主体、控制粒度、可信边界。
• source 到绑定变量、字段、对象、claim、文件或消息的映射。
• sink 的危险参数位置，以及参数是否被实际使用。
• transform、覆盖、分支、异常、权限和默认值如何影响 taint。
• 官方安全模型、范围、默认配置和 known risk 是否支持该 trace 的漏洞解释。
• 强正控、负控、清理/恢复。
• 当前可写的 allowed claims 与必须禁止的 forbidden claims。

如果入口、路由、handler 都没定位清楚，先做入口与调用链追踪；如果只有扫描器命中或正则命中，不得直接进入漏洞结论。

核心原则

1. 正则和扫描只负责发现候选，不负责下结论

正则匹配、grep、ripgrep、IDE 搜索、Semgrep/CodeQL 命中，都是“探照灯”，不是裁判。它们能快速定位危险函数、用户输入、raw SQL、文件操作、模板输出、危险配置，但不能证明跨行变量追踪、过滤语义、分支可达、框架绑定和运行态影响。

常见候选搜索可以这样启动，但命中后必须进入人工 trace：

# PHP 命令执行候选
rg -n "\b(system|exec|shell_exec|popen|proc_open|passthru)\s*\(" --glob '*.php' .

# PHP 用户输入候选
rg -n "\$_(GET|POST|REQUEST|COOKIE|FILES)\b" --glob '*.php' .

# SQL 拼接 / raw 查询候选
rg -n "(query\s*\(|execute\s*\(|whereRaw|orderByRaw|selectRaw|DB::raw|\$\{|\+\s*\w+\s*\+)" .

# 文件 / 包含 / 解压候选
rg -n "\b(include|require|file_get_contents|file_put_contents|fopen|fwrite|readfile|extractTo|ZipArchive|TarArchive)\b" .

检验：这条命中是否已经证明了 source、binding、trace、sink 参数、防护缺口、影响和负控？如果没有，只能标为 candidate 线索。

1.1 工具给出的 taint trace 必须人工复核

CodeQL、Semgrep、商业 SAST 或 IDE 的 data-flow/path trace 可以节省定位时间，但它们的模型和真实运行语义不等价。复核时至少检查：

• source 是否精确：source pattern 是否把整个表达式、子表达式、包装函数、默认值或 helper 都标成污染；source 是否真由攻击者控制。
• propagator 是否符合项目语义：赋值、函数调用、字段写入、集合传播、builder、serializer、ORM hydration、消息发送是否真的把同一个字段传下去。
• sanitizer 是否过宽：工具认为 sanitize(x) 安全，不等于 sink 使用了 sanitize(x) 的返回值；也不等于 sanitizer 覆盖当前上下文。
• sink 是否精确：命中函数不等于命中危险参数；必须看第几个参数、哪个字段、哪个结构片段、哪个执行分支。
• trace 是否唯一或完整：工具通常只展示一条代表性路径，不能证明其他路径不存在；也不能证明展示路径在当前 profile、DI 实现、feature flag、路由缓存下可达。
• local flow 与 global flow 要区分：函数内传播和跨函数、跨对象属性、跨异步消息、跨存储读取不是同一难度。局部 trace 完整不代表全局 trace 闭合。
• taint 与 value flow 要区分：y = x + suffix 可能不是同一个值，但仍受 x 影响；这适合 taint 传播，不代表能控制完整 sink 参数。

工具 trace 的正确用法是：把它拆成 source candidate -> propagation candidate -> sanitizer candidate -> sink candidate 四类线索，然后逐项用代码语义和运行态证据复核。禁止把 SARIF、dataflow 截图、规则命中或 agent 总结直接复制成报告结论。

2. 变量追踪看生命周期：定义、传递、使用

每个污染变量至少要回答三件事：

基本追踪方向有两种：

• 从 sink 反向：看到 system(cmd)、query(sql)、render_template_string(tpl) 后，向上找 cmd/sql/tpl 的来源。
• 从 source 正向：看到 req.body.url、$_GET['id']、@RequestBody dto、request.args.get() 后，向下追它是否进入 sink。

检验：能否写出 source -> 初始变量 -> 每一跳 -> transform/branch -> sink危险参数 的连续链路？中间缺一跳就不能 technical_confirmed。

2.1 追踪时优先证明“同一后继值”

Source→Sink 的关键不是“名字相似”，而是证明 sink 使用的是 source 的同一后继值。以下都要拆开：

• raw、safe、normalized、escaped 同时存在时，sink 到底用了哪个。
• dto、entity、model 同时存在时，sink 用的是请求字段、数据库字段、默认字段还是服务端覆盖字段。
• id 进入查询后换成 record.owner_id 时，id 控制的是对象选择，不等于控制 owner_id。
• url 经过 redirect、DNS、HTTP client wrapper 后，sink 使用的是初始 URL、规范化 URL、最终 URL、解析后 IP，还是服务端配置 host。
• filename 经过随机文件名、扩展名替换、对象存储 key 映射后，sink 使用的是原始文件名还是服务端生成名。
• role、tenant、userId 同时在 request、session、JWT、数据库中出现时，必须证明信任来源是哪一个。

检验句：如果我把 source 改成 A/B 两个不同测试值，sink 危险参数会不会同步变成 A/B？如果不会，变化发生在哪一跳？

3. 框架审计要找“标准写法之外的差异”

框架不是漏洞本身。主流框架通常提供路由、中间件、ORM、模板转义、CSRF、认证授权等安全机制；漏洞常出在开发者绕过这些机制的位置。

框架项目先做三步：

1. 认框架：依赖清单、目录结构、入口文件、路由配置、配置文件、响应头、启动代码。
2. 知机制：请求如何绑定到 handler，参数如何进入 DTO/Model，ORM/模板/鉴权/CSRF 默认如何工作，哪些配置会改变默认行为。
3. 找差异：原生输入、raw SQL、raw 输出、整体对象写入、禁用中间件、跳过 CSRF、绕过 Policy/Gate/Interceptor、动态表达式、危险组件可达。

检验：如果一个发现只说“Laravel/ThinkPHP/Spring/Django 默认安全/默认不安全”，没有读项目实际配置和调用方式，结论无效。

4. Transform 不等于 Sanitizer

trim、lower、decode、json_decode、base64_decode、对象映射、格式化、拼接、序列化、ORM hydration 都是 transform，默认仍保持 taint。只有在同变量、同分支、同上下文、sink 前执行，并且失败时阻断的处理，才可能是 sanitizer。

输入验证也一样：服务器端 allowlist + 规范化/归一化 + 失败即阻断 才能作为安全证据；客户端校验只算 UX，不算安全。安全 API 永远优先于转义；如果必须转义，也必须按 sink 上下文选择正确编码方式。

例子：

• trim(userInput) 对命令注入、SQL 结构注入通常不构成防护。
• htmlspecialchars 对 HTML body 可能有效，但对 SQL、shell、path、header、URL 不构成防护。
• addslashes 不能当作通用 SQL 或命令防护；要看数据库驱动、字符集、参数化情况和上下文。
• MyBatis #{} 通常按值绑定；${} 是字符串替换，动态表名/列名/排序必须额外白名单。
• Laravel / Django / ORM 的参数化只保护值位置，不自动保护 raw 片段、列名、表名、排序、表达式和拼接。
• 模板默认转义只保护默认输出语法；raw 输出、safe 标记、关闭 autoescape、服务端模板字符串仍要追踪。

5. 强验证默认用于授权可重置环境，结论必须有边界

在自有 Docker、CTF、靶场、本地可重置环境、隔离预发或明确授权的测试环境中，不应满足于弱 marker。trace 闭合后要尽量追到当前范围内最高可证明影响：查询语义、受控读写、对象越权、服务端请求、文件边界、命令输出、浏览器执行、组件链触发。

边界同时必须清楚：不越出授权范围，不测试第三方真实系统，不读取真实生产用户数据，不输出真实凭据，不制造不可清理副作用。没有环境、账号、对象、日志、快照、重置或清理能力时，不强行写 technical_confirmed。

6. 依赖对象标识符的 trace 必须补齐“标识符获取链”

Source→Sink 不是只追“字段能不能到 sink”。如果漏洞影响依赖 user_id、object_id、tenant_id、workspace_id、project_id、file_id、document_id、workflow_id、plugin_id、分享 token、lookup handle、物理表名、资源 URI 或其他对象标识符，trace 必须额外证明攻击者如何获得这些标识符。

• 单对象 trace：必须证明该 ID 来自攻击者自身可达路径，例如列表、详情响应、搜索、导出、日志、关系链、分享页、可预测序列或可推导路径；结论只能写到这个对象或同类可获得对象。
• 多对象 / 批量 / 广义 trace：必须证明 ID 能批量、持续、枚举、列表式、搜索式、导出式、日志泄露式、关系链式、分享页式或可推导式获得。
• 拿不到 ID：不能把“已知 ID 后可利用”写成高价值 technical_confirmed；通常只能写 candidate、blocked 或在排除证据充分时写 rejected。
• 管理员手工提供的 ID、报告作者笔记里的 ID、聊天上下文出现的 ID、历史附件里的 ID，只能作为定位样本，不能算攻击者可获得路径。

凡是 trace 依赖多账号、多对象、owner/victim、跨租户、低权限/高权限对照或清理动作，多主体或对象边界 claim 必须引用账号对象矩阵，记录主体、角色、对象归属、租户/workspace、token/cookie 隔离和清理责任；账号对象矩阵字段以 templates/账号对象矩阵模板.md 与对应 schema/template 为准，本 Skill 不重新定义。

检验句：如果我不给这个 ID，攻击者能不能从自己的入口稳定拿到它？如果报告写批量或广义影响，攻击者能不能批量或持续拿到足够多 ID？

7. 官方安全模型决定 trace 能否写成漏洞

source→sink 只证明“数据流到了哪里”，不自动证明“这条流就是新漏洞”。如果这条 trace 要进入报告，还必须补上官方安全模型的裁决：

• 官方是否把当前主体、对象、租户、插件、脚本、沙箱、导入、webhook、预览、URL fetch 或管理功能定义为受信任边界。
• 官方是否把当前行为定义为预期功能、已知风险、accepted risk、范围外或 hardening only。
• 官方是否明确默认配置、默认角色或默认部署不会受影响。
• 官方是否把这条路径的边界解释为对象级授权、功能级授权、租户级隔离、沙箱隔离或管理员正常能力。

如果官方安全模型 unknown、scope unknown、默认配置 unknown 或 known risk 未去重，这条 trace 只能给出技术候选，不能直接写 technical_confirmed 或对外提交。

审计目标

本 Skill 要证明或排除的是：污染数据是否以可利用方式进入安全敏感语义。

需要证明：

• 入口真实可达，路由/消息/任务/文件导入/CLI 已注册并启用。
• source 真实可控，控制主体、权限、租户、对象和字段粒度明确。
• 参数绑定清楚：从请求、消息、文件、claim、session、数据库或缓存进入哪个变量/字段。
• trace 连续：赋值、函数参数、返回值、对象属性、数组元素、集合、序列化、异步消息、ORM/Mapper、接口实现、父类/trait/AOP 都有证据。
• transform、防护、覆盖、分支、异常和权限判断被逐项裁决。
• sink 的危险参数位置被污染，且当前分支会执行。
• 若影响依赖对象标识符，攻击者获得 ID / handle / token / URI 的链路、规模和边界被证明。
• 若影响依赖多主体、多对象或跨租户，账号矩阵、对象归属、账号对象矩阵必要事实和清理责任可复核。
• 若这条 trace 需要写成漏洞报告，官方安全模型、范围、默认配置和 known risk 也要能支持当前声明。
• 强正控、影响证明、负控、清理/恢复和声明边界齐全。

需要排除：

• source 只在前端存在，后端不接收。
• source 来自可信服务端状态、固定配置、不可伪造 claim、不可写数据库字段，攻击者不能影响。
• 参数被无条件覆盖、白名单限定到安全值、类型转换阻断当前漏洞语义。
• 参数传递过但未实际使用，或进入非危险参数。
• sink 只在测试代码、示例、未注册 profile、不可达路由、未消费队列中存在。
• 同变量、同分支、同上下文的防护真实阻断。
• 官方安全模型明确该行为是预期功能、范围外、accepted risk 或 hardening only。
• 弱 payload 失败但尚未证明路径不可达或防护有效；这种情况不得直接 rejected。

输入材料

优先读取这些材料，不要只看目录或搜索结果：

• 入口材料：路由文件、注解/attribute/decorator、controller/action/handler/resolver、RPC、GraphQL、WebSocket、webhook、queue consumer、event listener、cron、CLI、file import。
• 绑定材料：request object、body parser、serializer、DTO/VO/FormRequest/ModelBinder、path/query/body/header/cookie/file、session/JWT/OAuth/OIDC/SAML claim。
• 传播材料：service、manager、usecase、repository、DAO、mapper、model、helper、trait、mixin、decorator、AOP、接口、抽象类、父类、magic method、ORM scope、query macro。
• 防护材料：middleware、filter、interceptor、guard、policy、gate、validator、schema、escape、sanitize、canonicalize、auth decision、CSRF/CORS/security header 配置。
• sink 材料：SQL/ORM/Mapper XML、NoSQL/DSL、command/code/template/expression、file/upload/archive/XML/deserialization/HTTP client/redirect/header/auth/cache/queue/log/crypto/config。
• 运行材料：baseline 请求、强正控请求、负控请求、测试账号/对象、日志、数据库/缓存/文件/队列/对象存储副作用、DNS/HTTP 回调、浏览器 DevTools、清理记录。
• 复核材料：扫描器 trace、报告、误报说明、历史修复、官方安全文档、框架版本和运行配置。
• 标识符材料：列表、详情、搜索、导出、日志、关系链、分享页、可预测序列、可推导规则、批量接口、分页接口、对象 URI、分享 token、lookup handle；必须区分单对象可得、多对象可得、批量可得和不可得。
• 多主体或对象边界 claim 必须引用账号对象矩阵，记录主体、角色、对象归属、租户/workspace、token/cookie 隔离和清理责任；账号对象矩阵字段以 templates/账号对象矩阵模板.md 与对应 schema/template 为准，本 Skill 不重新定义。
• 官方安全模型材料：SECURITY、安全策略、scope、默认配置、release notes、known issues、accepted risk、范围或官方已知拒绝（外部裁决）、预期行为、对象/租户/插件/沙箱边界与 report quality 规则。

Source 识别

Source 必须记录来源、进入点、控制主体、控制粒度和污染类型。

Source 裁决顺序

不要先问“这个字段危险吗”，先按顺序问：

1. 这个值是否进入后端或任务系统，而不是只停留在前端、文档、Swagger、Mock、测试数据。
2. 谁能控制它：匿名、普通用户、管理员、内部服务、第三方 webhook、任务系统、攻击者可污染存储。
3. 控制粒度是什么：完整值、字段、数组元素、对象 ID、枚举选择、格式受限、条件受限、存储型、不可控。
4. 它是否跨过可信边界：签名、session、JWT、OAuth/OIDC/SAML、反向代理 header、HMAC、CSRF、租户。
5. 它是否被服务端覆盖：当前主体、tenant、owner、固定 host、随机文件名、默认配置、数据库记录。
6. 它是否能到达目标 sink 所需的同一分支和同一字段。

只有 1-6 都有答案，才开始谈漏洞类型和强验证。

HTTP / API Source

• query：id、url、path、file、sort、order、filter、callback、returnTo、redirect、template。
• path：/{id}、slug、tenant、filename、wildcard、正则 capture、后缀。
• body：form、JSON、XML、GraphQL variables、protobuf、nested object、array、bulk list。
• header：Authorization、Host、Origin、Referer、X-Forwarded-*、Content-Type、自定义签名头。
• cookie：session、remember-me、JWT cookie、tenant、locale、业务偏好。
• multipart：文件名、Content-Type、文件内容、普通字段、压缩包 entry name。

非 HTTP / 二次污染 Source

• CLI argv/stdin、环境变量、导入文件、CSV/Excel/XML/JSON/YAML/ZIP/TAR/office 文档。
• webhook payload、OAuth/OIDC/SAML claim、支付/消息/代码仓库回调。
• queue message、event bus payload、workflow form、cron 读取记录。
• 数据库、缓存、文件和对象存储中的存储型污染：必须证明攻击者能先写入，再由后续入口读取。
• 前端/客户端代码中的隐藏参数、签名参数、硬编码 key、Authorization 生成逻辑：只有后端接受并信任时才成为后端 source。

存储型 Source 必须闭合写入端与读取端

存储型污染是最容易被误判的路径。要同时证明：

攻击者可写入口 -> 存储位置/字段/key/对象 -> 读取入口/任务/consumer -> 读取后变量 -> transform/防护 -> sink危险参数

常见错误：

• 只看到数据库字段包含危险字符串，但没证明攻击者能写。
• 只证明攻击者能写 profile/template/rule/callback，但没证明后续任务读取并进入 sink。
• 只证明后台管理员可写，却把结论写成低权限可利用。
• 只证明读取端会渲染/执行，但写入端字段被白名单、富文本 sanitizer、模板沙箱或审核流程限制。
• 存储型 XSS 只在攻击者自己页面触发，却写成可攻击其他用户。
• 存储型 SSRF/RCE 只保存配置，没证明 job、webhook、worker 或 scheduler 会消费。

存储型链路缺写入端或读取端时，只能写 candidate 或 blocked。

框架 Source 差异点

Source 证据模板

| Source | 类型 | 进入位置 | 控制主体 | 控制粒度 | 初始变量/字段 | taint 类型 | 证据 |
|---|---|---|---|---|---|---|---|
| `{field}` | query/body/header/... | `{file:line}` | 未登录/普通用户/管理员/系统 | FULL/FIELD/CONDITIONAL/... | `{var.path}` | direct/stored/claim/file/message | `{代码/请求}` |

Sink 识别

Sink 必须记录危险语义、危险参数位置、执行条件和影响，不得只写函数名。

Sink 裁决顺序

先定位 sink 的危险语义，再定位 API 名：

1. sink 属于哪类危险语义：查询、执行、文件、网络、输出、解析、权限、状态、缓存、队列、日志、配置。
2. 危险参数在哪里：参数序号、对象字段、SQL 片段、URL 部件、path segment、header name/value、模板表达式、operator、ACL 条件。
3. source 后继值是否进入该危险位置，而不是进入日志、label、非危险配置、错误消息或普通显示字段。
4. sink 是否在当前入口分支执行：profile、feature flag、role、object state、异常路径、early return、队列消费状态。
5. 防护是否在 sink 前覆盖同一字段：参数化、白名单、编码、canonicalize、鉴权、类型限制。
6. sink 影响是否可观察：响应、日志、状态、副作用、回连、浏览器执行、命令输出、对象权限差异。

如果只完成 1-2，最多是 sink candidate；完成到 3-5 才能进入强验证；完成 6 加负控后才考虑 technical_confirmed。

查询与注入 Sink

• SQL：JDBC Statement、PreparedStatement 拼接前 SQL、MyBatis ${}、Mapper XML、SQL Provider、JPA nativeQuery、Hibernate HQL/JPQL 拼接、PDO/mysqli query、Laravel raw/whereRaw/orderByRaw/selectRaw、Django RawSQL/extra/raw、动态表名/列名/排序/limit。
• NoSQL/DSL：Mongo filter/update/operator/aggregation、Elasticsearch DSL、Redis key pattern、GraphQL filter、用户对象直接构造查询。
• LDAP/XPath：filter/DN 拼接、XPath expression、XML query raw expression。

执行、表达式与模板 Sink

• command：PHP system/exec/shell_exec/proc_open，Java Runtime.exec/ProcessBuilder，Node child_process，Python subprocess/os.system，Go os/exec，.NET ProcessStartInfo。
• dynamic code：eval/assert、script engine、reflection invoke、dynamic import、SpEL/OGNL/MVEL/Groovy、EL、模板 compile/evaluate。
• template：模板名、模板内容、表达式字符串、render_template_string、Blade {!! !!}、raw/safe 标记、关闭 autoescape。

文件、解析与网络 Sink

• file read/write：readfile/fopen/file_get_contents/include/require、Files.read/write、fs.readFile/writeFile、open/read/write、object storage get/put。
• upload/archive：move_uploaded_file、MultipartFile.transferTo、object storage upload、preview conversion、Zip/Tar extract、自定义 entry path join。
• XML/deserialize：DOM/SAX/StAX、DocumentBuilderFactory、XMLInputFactory、SimpleXML、ObjectInputStream、Jackson default typing、Fastjson、XStream、Hessian、PHP unserialize/Phar、pickle/yaml unsafe load。
• SSRF：RestTemplate/WebClient/OkHttp/curl/requests/http.Client/fetch/URL.openConnection、file_get_contents($url)。

输出、权限与状态 Sink

• XSS：HTML body、attribute、JS、CSS、URL、JSON-in-HTML、Markdown/rich text、DOM sink、SSR hydration。
• redirect/header：Location、returnUrl、callbackUrl、Set-Cookie、CORS header、Content-Disposition filename、CRLF 控制字符。
• auth decision：hasRole、authorize、policy/gate、owner/tenant 条件、ACL query、object lookup before permission check。
• CSRF/state change：POST/PUT/PATCH/DELETE、GET state change、method override、JSON/multipart/AJAX 分支。
• cache/queue/log/crypto/config：cache key、message dispatch、日志输出、secret read/write、sign/verify、debug/error config。

Sink 证据模板

| Sink | 调用点 | 危险参数位置 | 输入变量 | 执行条件 | 影响语义 | 防护点 | 证据 |
|---|---|---|---|---|---|---|---|
| SQL/CMD/FILE/... | `{file:line API}` | 参数/字段/片段 | `{var}` | 分支/配置/角色 | 读/写/执行/越权/... | 参数化/白名单/... | `{代码片段}` |

Transform / 防护检查

每个 transform 都要判断是保持污染、改变形态、缩小控制面，还是完全阻断。

防护有效必须同时满足：

1. 作用在同一个污染值或唯一后继字段上。
2. 发生在 sink 前。
3. 覆盖当前执行分支、异常分支、批量元素和异步消费端。
4. 与 sink 上下文匹配。
5. 失败时 return/throw/deny/abort，不能 fallback 到原始值或危险默认值。
6. 有代码、配置或运行态证据，不靠方法名和框架默认假设。

路由与调用链追踪

Source→Sink trace 必须先证明入口可达，再证明每一跳传播。

入口枚举

• HTTP route：路由文件、注解、attribute、decorator、controller method、REST resource。
• 框架边界：Servlet/Filter/Listener、Middleware、Interceptor、Guard、Policy、AOP。
• API 入口：GraphQL resolver、RPC service、WebSocket handler、message listener。
• 非 HTTP：CLI command、scheduled job、queue consumer、webhook、file import、CMS hook。
• 动态路由、正则路由、通配符、group prefix、反向代理 prefix、route cache 必须有解析证据。

handler 到 sink

逐层追踪：

handler/controller/action
  -> service/usecase/manager
  -> repository/DAO/mapper/model/client/helper
  -> sink

复杂边界要特别处理：

• 依赖注入：构造函数、注解、容器绑定、provider、service registration。
• 接口/抽象类/父类/trait/mixin/decorator/AOP：解析真实实现；未解析写缺口。
• ORM/Mapper/XML/query macro/repository 基类：追到最终查询或操作。
• 事件/队列：同时追 producer 和 consumer；只追一端不能 technical_confirmed。
• 动态函数/反射/魔术方法/自动路由：必须给出解析规则或运行态补证。

每一跳记录格式：

Level-N: {file:line} {class/function}.{method}({args})
输入: {sourceField/localVar}
传播: assignment/call/return/field/container/serialization/message
transform: decode/validate/escape/canonicalize/auth/default/overwrite
分支: {condition} -> 进入/不进入下一跳
输出: {nextArg/return/field/message}
证据: {关键代码}
缺口: {未解析实现/缺配置/缺运行态/缺消费端}

数据流追踪步骤

第 1 步：建立 trace 任务卡

- trace_id: `{entry}:{source}:{sink}`
- 入口: `{METHOD PATH / CLI / queue / cron / webhook / file import}`
- 目标漏洞族: `{SQL/SSRF/CMD/FILE/XSS/AUTH/...}`
- source 假设: `{字段/claim/message/file/stored}`
- sink 假设: `{API/函数/配置}`
- 必需标识符: `{无 / user_id / object_id / tenant_id / file_id / lookup handle / ...}`
- 标识符获取假设: `{列表/搜索/详情/导出/日志/关系链/分享页/可预测/手工样本/未知}`
- 主体对象矩阵: `{attacker / owner / victim / control / cleanup}`
- 官方安全模型状态: `{已读/未读/unknown/expected behavior/accepted risk/in scope/out of scope}`
- 当前状态: `untraced`

第 2 步：候选定位，但不下结论

用正则、IDE、SAST、规则、依赖清单找候选：危险函数、source、raw 调用、框架差异、历史高危组件、配置关闭。记录命中位置和为什么值得追踪。命中本身只能写 candidate-source 或 candidate-sink。

候选定位要避免“搜索词替代语义”：

• 搜 eval、exec、raw、query 只能证明有危险 API。
• 搜 $_GET、req.body、@RequestBody 只能证明有输入读取。
• 搜 ${}、raw、unsafe 只能证明需要复核。
• 扫描器 trace 只能证明规则模型认为存在路径。

下一步必须把候选拆成可复核任务卡：source candidate、sink candidate、propagation candidate、sanitizer candidate、runtime gap。

第 3 步：写入口请求或消息样例

写清 method、path、query、headers、cookies、body、multipart、认证状态、对象 ID、租户、前置数据。非 HTTP 场景写 CLI argv、queue message、webhook payload、file import 样例。准备动态验证时使用测试对象和唯一 marker。

如果请求依赖对象标识符，不要只写 {id} 占位符。必须同时写：

• 这个 ID 是从哪里拿到的：列表、详情响应、搜索、导出、日志、关系链、分享页、可预测序列、批量接口，还是只能由管理员手工给出。
• 这个 ID 属于谁：attacker 自己对象、victim 对象、control 对象、跨租户对象、公开对象还是未知对象。
• 这个 ID 的可获得规模：单个样本、同类多个、分页批量、持续获取、可枚举、可导出、不可获得。
• 这个 ID 是否被服务端重新绑定到当前主体；如果查询同时绑定 owner/tenant，ID 可控不等于越权成立。

如果 ID 只能从手工样本得到，trace 可以继续定位代码问题，但报告结论必须降级，不能写成高价值 technical_confirmed 或批量影响。

第 4 步：定位参数进入点

记录读取 API、绑定变量、类型、默认值、数组/对象/嵌套字段、claim/session 来源、文件内容或文件名。框架自动绑定必须读 binder/serializer/form/model 配置。

第 5 步：追踪变量传播

逐层记录：

• 直接赋值：cmd = request['cmd']。
• 函数处理：cmd = trim(input)，继续判断 transform 语义。
• 跨函数：caller arg → callee param。
• 跨文件：include/import/autoload/模块导入。
• 数组/集合：arr['cmd']、map.get('url')、bulk list 每个元素。
• 对象属性：dto.url、getter/setter、Lombok、property accessor、mass assignment。
• 多来源拼接：每个片段分别追 source 和限制。
• 编码/解码：base64/url/json/xml/yaml decode 后继续追。
• 动态调用：函数名、类名、方法名、模板名、表达式名可控时，额外证明最终目标。

传播过程中遇到以下情况要单独建子任务，不要口头略过：

• alias：两个变量/引用/指针/对象属性指向同一底层对象。
• mutation：helper 原地修改对象、Map、数组、builder、request attribute、context。
• merge：默认配置、用户配置、数据库配置、请求配置合并，后者是否覆盖前者。
• serializer：字段别名、忽略字段、unknown fields、extra fields、case-insensitive binding。
• collection：批量列表每个元素是否逐项校验、逐项授权、逐项进入 sink。
• async：message body、headers、routing key、consumer schema 是否与 producer 一致。
• persistence：写入字段和读取字段是否一致，中间是否经过审核、转义、清洗、模板编译或缓存刷新。

第 6 步：记录 transform、覆盖和分支

| 位置 | 输入变量 | transform/覆盖/防护 | 条件 | true 分支 | false 分支 | 可控性影响 | 证据 |
|---|---|---|---|---|---|---|---|

必须记录 return、throw、continue、break、redirect、try/catch/fallback。安全检查失败后如果仍继续执行或换到危险默认路径，防护无效。

第 7 步：定位 sink 参数位置

不要只写“调用了 execute/render/exec”。要写：

• sink API/function。
• 第几个参数、哪个字段、哪个 SQL 片段、哪个 URL 部件、哪个 path、哪个 header、哪个模板表达式是危险位置。
• tainted 变量如何映射到该危险位置。
• sink 执行条件和防护点。

第 8 步：判断可控性和实际使用

| Source | Sink | 路径状态 | 实际使用 | 可控性 | 防护状态 | 影响状态 | 结论 |
|---|---|---|---|---|---|---|---|
| `{source}` | `{sink}` | COMPLETE/PARTIAL/UNRESOLVED | 是/否/部分 | FULL/FIELD/CONDITIONAL/... | 有效/不足/未确认 | 已证/待证/无影响 | technical_confirmed/candidate/blocked/rejected |

可控性常用状态：

• FULLY_CONTROLLABLE：完整值可控。
• FIELD_CONTROLLABLE：对象/JSON/DTO/数组中部分字段可控。
• CONDITIONALLY_CONTROLLABLE：满足分支、格式、角色、配置时可控。
• ALLOWLIST_CONTROLLABLE：只能选允许值；仍要判断允许值是否危险。
• TYPE_LIMITED_CONTROLLABLE：类型/范围缩小；可能阻断注入但不一定阻断越权。
• STORED_CONTROLLABLE：攻击者可先写入，后续读取进入 sink。
• SERVER_CONTROLLED / OVERWRITTEN：通常降级或 rejected。
• UNRESOLVED：证据不足，只能 candidate/blocked。

第 9 步：推进强正控、最高影响和负控

当 trace 显示可利用潜力时，不要停在弱 marker：

trace complete -> sink 参数可控 -> 防护不足 -> 弱正控 -> 强正控 -> 最高影响 -> 负控 -> 清理/恢复

SQL 从错误栈推进到布尔/时间/常量/测试表；RCE 从 marker 推进到命令输出、执行身份、受控文件；SSRF 从 callback 推进到最终 URL/IP、受控内网 canary、metadata mock；IDOR 从对象 ID 替换推进到双账号双对象；文件类从路径拼接推进到 resolved target 和受控读写；XSS 从反射推进到浏览器执行。

IDOR、未授权、对象级授权、批量越权类 trace 还要继续推进两件事：

1. 标识符获取：证明 attacker 能从自己的入口获得 victim/control 对象 ID，或证明只能获得单对象、不能批量、完全不可得。 多主体、对象边界或登录态相关结论必须引用账号对象矩阵、对象归属、主体边界、token/cookie 引用和清理责任；报告阶段按唯一模板渲染必要复现事实，本 Skill 不重新定义账号凭据字段或正文写法。

只完成 “A 账号替换 B 对象 ID 返回 200” 还不够。若 ID 获取链缺失，最多写“手工样本下可疑 / blocked / candidate”；若要写批量或广义影响，必须证明攻击者能批量、持续、枚举、列表、搜索、导出或可推导获得大量 ID。

第 10 步：写完整性声明

## Trace 完整性声明
- trace_status: COMPLETE / PARTIAL / UNRESOLVED
- 已证明:
  - {入口/source/binding/某几跳/sink/防护缺口/运行态/官方安全模型/...}
- 未证明:
  - {缺实现类/缺消费端/缺运行配置/缺负控/缺官方门禁/...}
- Allowed Claims:
  - {当前证据允许声明的具体边界}
- Forbidden Claims:
  - {不得声明 technical_confirmed/无需认证/任意/RCE/全局影响/对外提交资格/...}
- 下一步:
  - {补证或修复验证动作}

必检证据点

漏洞族细化证据：

• SQL：执行点、字符串构造、用户参数到 SQL 片段、参数化/白名单、查询语义差异。
• CMD/RCE：执行点、命令字符串/参数构造、用户片段映射、命令输出/执行身份/受控文件。
• SSRF：URL 归一化、最终 URL/host/port、重定向后校验、DNS/IP 内网拦截、出站日志。
• FILE/UPLOAD/ARCHIVE：resolved target、base 约束、entry name、内容来源、覆盖模式、写后可达、清理。
• XSS/TPL：输出上下文、raw/safe/escape、浏览器执行、CSP、存储触发。
• XXE/DESER/EXPR：解析/反序列化/求值入口、输入来源、危险配置、触发链、沙箱/类型限制。
• AUTH/IDOR/CSRF：路径保护、token/claim、权限函数、owner/tenant 条件、状态变更、双主体对照。

动态验证触发条件

必须动态验证的场景：

• 静态 trace 闭合，但影响依赖运行态：越权、SSRF、文件读写、命令执行、上传可访问性、CSRF、缓存/队列、组件可达性。
• 防护是否生效依赖配置、middleware 顺序、运行版本、feature flag、数据库方言、代理路径、object storage policy。
• 需要证明对象级授权、租户隔离、角色差异、双主体/双对象。
• 扫描器结果要升级 technical_confirmed。
• source 是存储型污染，需要证明写入端与读取端在同一运行环境相连。
• 需要证明最高影响、执行语义、服务端请求、文件边界或状态改变。
• trace 将进入报告，需要证明官方安全模型是否承认该边界，或当前行为是否只是预期功能、accepted risk、范围外或 hardening only。

静态证据足够进入 candidate 的场景：

• source→sink 静态链路较完整，但缺账号、对象、日志或负控。
• sink 参数可控，但防护是否覆盖当前 runtime 未确认。
• 动态调用、依赖注入或异步消费端部分未解析。
• 组件版本命中并有调用点，但缺实际触发输入。
• 官方安全模型、范围、默认配置或 known risk 未读完。

不能继续动态验证的场景：

• 目标不在授权范围。
• 会访问第三方真实系统或真实用户数据。
• 会暴露、复用、转储真实 secret、token、cookie、密码或云凭据。
• 无测试账号、测试对象、日志观察、快照、回滚或清理能力。
• 只能通过不可控、不可回滚、无法隔离的方式观察影响。

授权实验模式下的强验证方法

以下方法只用于自有、授权、隔离、可重置环境；payload 必须按实际上下文调整，并绑定测试对象、唯一 marker、日志观察点和清理步骤。

弱 payload 失败时，先确认：payload 是否到达 sink、上下文是否匹配、编码是否正确、权限是否满足、观察点是否正确、防护是否真实生效。不能因为一次弱 payload 阴性直接 rejected。

最高危害追踪

对每条 candidate 按以下阶梯推进，直到达到当前授权环境可证明上限或明确停止原因：

可触发 -> 可控 -> sink 执行 -> 强正控 -> 可读/可写/可越权/可执行/可横向 -> 负控 -> 清理 -> 声明边界

停止继续追踪必须写具体原因：

• 已达到当前测试范围内最高可证明影响。
• 防护经同变量、同分支、同上下文证据证明有效。
• 缺测试账号、对象、日志、回连、快照或清理能力。
• 继续验证会越出授权范围、触碰真实生产数据、真实凭据或第三方系统。
• 当前环境不支持触发该 sink，需要运行态补证。

禁止把低层现象夸大：

• callback-only SSRF 不能写内网敏感访问。
• marker-only RCE 不能写命令执行。
• error-only SQLi 不能写数据读取。
• reflect-only XSS 不能写浏览器执行。
• version-only SCA 不能写组件漏洞可达。
• secret-regex-only 不能写有效凭据泄露。

负控设计

负控用于证明正控结果由漏洞条件导致，不是正常功能、缓存、随机、权限本该允许、错误页、WAF、限流或工具误报。

technical_confirmed 至少要有一个与 claim 对齐的负控；高危/严重结论通常需要多组负控。

technical_status 方法性判定边界

technical_confirmed

必须同时满足：

• 入口可达。
• source 控制主体与控制粒度已证明。
• 参数绑定清楚。
• trace_status 为 COMPLETE，或静态 trace 与运行态证据等价闭合。
• 污染值到达 sink 危险参数位置，并且该参数被实际使用。
• 防护不足或被绕过，缺口具体。
• 若漏洞依赖 ID、对象 handle、分享 token、资源 URI 或租户标识，EVID_IDENTIFIER_ACQUISITION 已证明攻击者可获得路径，并且声明范围不超过可获得规模。
• 若漏洞依赖多主体、多对象或跨租户，EVID_ACCOUNT_OBJECT_MATRIX 已证明账号对象矩阵、对象归属、token/cookie 隔离和清理责任；没有混用账号或对象。
• 若这条 trace 将进入报告，EVID_OFFICIAL_SECURITY_MODEL 已证明官方资料、范围、默认配置、已知风险和预期行为支持当前声明。
• 强正控证明真实影响或最高可证明影响。
• 负控成立。
• 清理/恢复完成，或验证无副作用。
• Allowed Claims 与证据一致，Forbidden Claims 写清。

candidate

用于这些情况：

• source/sink 有线索，但中间层、字段级映射、实现类、动态调用、异步消费端缺失。
• 参数可能可控，但覆盖、白名单、类型转换、防护语义未判定。
• 静态 trace 较完整但缺强正控、影响证明或负控。
• 扫描器 taint trace 未人工核对 binding、field mapping、sanitizer、actual use。
• 弱 payload 失败但尚未证明路径不可达或防护有效。
• trace 依赖对象 ID，但目前只有手工样本、管理员提供 ID、旧报告 ID 或单个不可泛化 ID，尚未证明攻击者可获得路径。
• 多对象、批量或跨租户声明缺少足够 ID 获取规模或账号矩阵。
• 官方安全模型、范围、默认配置或 known risk 还没读完，不能写对外可提交。

blocked

用于必须依赖运行态才能裁决的情况：

• 需要测试账号、对象、租户、CSRF、session、JWT/OAuth claim。
• 需要 route cache、middleware 顺序、feature flag、运行版本、构建产物。
• 需要日志、数据库、缓存、队列、文件、对象存储、DNS/HTTP 回调、浏览器环境。
• 需要双主体/双对象/双租户负控。
• 需要证明对象 ID、用户 ID、租户 ID、文件 ID、分享 token、lookup handle 或资源 URI 能否由攻击者获得。
• 需要补齐账号矩阵、账号对象矩阵必要事实、对象归属、token/cookie 隔离或清理能力。
• 需要补齐官方安全模型、范围、默认配置、known risk、accepted risk 或预期行为裁决。
• 需要快照、重置或清理能力才能做强验证。

rejected

只有具备排除证据时才写：

• 入口不可达、未注册或当前配置不启用。
• source 不可控或只在前端存在。
• source 未绑定到目标变量，或未进入 sink。
• sink 参数不是危险参数，或 sink 使用服务端固定值。
• 参数被无条件覆盖，或白名单/类型/授权真实阻断当前风险。
• 强正控和负控证明参数变化不影响 sink 或影响不成立。
• 组件未打包、未加载、版本不受影响或漏洞路径不可达。
• 依赖对象标识符的漏洞，经代码、接口和运行态证据证明攻击者无法获得必要 ID，且不存在可列表、搜索、导出、关系链、分享页、可预测或可推导路径。
• 多主体结论所需账号/对象关系经负控证明为正常授权、公开对象、自己对象或权限本该允许。
• 官方安全模型明确该行为是预期功能、受信任主体正常能力、accepted risk、范围外或 hardening only。

rejected 必须写 file:line、配置、请求/响应、日志、负控或依赖/运行版本证据，不得只写“看起来安全”。

报告与产物边界

本 Skill 不内嵌报告正文或模板章节。需要输出报告时，只把本 Skill 产生的方法性事实写入对应 evidence，并由报告阶段引用唯一模板渲染：

• 入口、Source、Binding、Guard、Flow、Sink、Trigger、Effect、Negative、Clean、Claim 统一登记为 EVID_* 证据。
• 单漏洞 Markdown 只使用 templates/单漏洞提交报告模板.md。
• 提交总入口只使用 templates/赏金提交总入口模板.md。
• 完成核验只使用 templates/完成核验模板.md，只能检查，不能补证。
• 本 Skill 可以说明应写入哪些事实，但不得复制报告章节正文、平台表单、账号对象矩阵字段或外部门禁裁决规则。

修复建议写法

修复建议必须匹配根因和框架机制：

• SQL/NoSQL/LDAP/XPath：值位置使用参数化；动态表名、列名、排序、operator、DSL 结构用服务端白名单。
• 命令执行：避免 shell 拼接；使用参数数组、固定命令、允许列表、隔离执行用户和最小权限。
• SSRF：scheme/host/port allowlist，DNS/IP 解析后校验，重定向后重新校验，拒绝 metadata/内网，统一 HTTP client wrapper。
• 文件/上传/归档：decode/canonicalize/realpath 后做 base 约束；随机文件名；web 根外存储；禁执行；entry 路径归一化；清理临时文件。
• XSS/模板：使用上下文转义；禁 raw/safe；模板名白名单；关闭用户可控模板编译；补浏览器回归测试。
• XXE/反序列化/表达式：禁外部实体和网络；类型白名单；关闭危险 default typing；模板/表达式沙箱；禁止用户可控对象图。
• Auth/IDOR/CSRF：服务端对象级授权、tenant/owner 条件、逐项批量授权、CSRF token 全分支覆盖、Origin/SameSite 辅助防护。
• Secret/配置：移出客户端和仓库；服务端签名；最小权限；轮换；日志脱敏；debug 关闭。
• 测试：为 source→sink、负控、权限矩阵、修复后阻断写单元/集成/回归测试。

禁止事项

• 禁止 sink-only technical_confirmed。
• 禁止 source-only technical_confirmed。
• 禁止 scanner-only technical_confirmed。
• 禁止 external-tool-only technical_confirmed。
• 禁止 regex-only technical_confirmed。
• 禁止没有 trace 就 technical_confirmed。
• 禁止 trace_status=PARTIAL/UNRESOLVED 仍写 technical_confirmed。
• 禁止没有负控就写高置信。
• 禁止只看 200 响应。
• 禁止把框架默认安全或默认不安全当证据。
• 禁止把 sanitizer 名称当防护结论；必须看语义和上下文。
• 禁止把不可解析的动态调用强行补全为证据。
• 禁止 callback-only SSRF 写成内网高危 technical_confirmed。
• 禁止 marker-only RCE 写成命令执行 technical_confirmed。
• 禁止 error-only SQLi 写成数据读取 technical_confirmed。
• 禁止 reflect-only XSS 写成浏览器执行 technical_confirmed。
• 禁止 version-only SCA 写成组件漏洞可达 technical_confirmed。
• 禁止弱 payload 失败直接 rejected。
• 禁止把“已知 ID 后可利用”写成高价值 technical_confirmed，却不证明攻击者如何获得该 ID。
• 禁止把单对象 ID 样本外推成批量、全租户、全用户、全工作区或广义影响。
• 禁止管理员手工给出的 ID、聊天上下文里的 ID、历史附件里的 ID、报告作者笔记里的 ID 当作攻击者可获得路径。
• 禁止账号矩阵缺账号对象矩阵必要事实、主体 ID、租户、对象归属、token/cookie 引用和清理责任时声称多主体 technical_confirmed 可复核。
• 禁止在官方安全模型 unknown、scope unknown、默认配置 unknown 或 known risk 未去重时写对外可提交。
• 禁止为了凑数量写低价值漏洞。
• 禁止把项目运行、部署、恢复、调度、监控内容混进漏洞审计 skill。
• 禁止把当前工作记录、来源叙事、不可公开的环境细节、内部命名或临时任务过程写进通用 skill。
• 禁止越出授权范围、测试第三方真实目标、导出真实凭据、泄露真实生产用户敏感数据或执行不可清理验证。

自检清单

每项回答 是 / 否 / 不适用：

Source

• 是否识别 query/path/body/header/cookie/JSON/XML/multipart？
• 是否识别 GraphQL/WebSocket/CLI/webhook/queue/cron/file import？
• 是否识别 session/JWT/OAuth claim 和 framework request object？
• 是否识别 stored taint：数据库、缓存、文件、对象存储？
• 是否证明 source 的控制主体、权限边界和控制粒度？
• 客户端隐藏参数、签名头、硬编码 key 是否证明后端实际信任？
• 若 trace 依赖对象 ID、租户 ID、文件 ID、分享 token、lookup handle 或资源 URI，是否证明攻击者如何获得？
• 若报告写多对象、批量、持续、全量或广义影响，是否证明 ID 能批量、持续、枚举、列表、搜索、导出、关系链或可推导获得？
• 是否把手工样本 ID、管理员提供 ID、旧报告 ID 和攻击者可获得 ID 区分开？

Trace

• 是否从入口追到 handler/controller？
• 是否从 handler 追到 service/repository/mapper/model/helper/client？
• 是否处理父类、接口、trait、helper、middleware、decorator、依赖注入、注解/attribute、AOP、反射？
• 是否处理事件、队列、定时任务、异步消费端？
• 是否记录每一跳 file:line、变量名、输入/输出、分支？
• 是否给出 trace_status：COMPLETE/PARTIAL/UNRESOLVED？
• 若是 AUTH/IDOR/对象级授权 trace，是否有 A/B 主体、A/B 对象、跨租户或 control 对象的账号矩阵？
• 账号对象矩阵是否记录主体 ID、租户/工作区、角色、对象归属、token/cookie 隔离和清理责任；具体凭据字段以账号对象矩阵模板为准？
• 若 trace 要写成报告，是否查阅并裁决官方安全模型、scope、默认配置、known issues 和 accepted risk，而不是只看代码链路？

Transform / 防护

• 是否区分 transform 与 sanitizer？
• 是否确认防护作用在同一变量、同一分支、同一上下文？
• 是否确认参数化覆盖全部动态片段？
• 是否确认白名单在规范化后执行且允许值无危险语义？
• 是否确认 escape 匹配输出上下文？
• 是否确认权限检查在 sink 前执行且对象级/租户级覆盖？
• 若强正控失败，是否解释是防护有效还是 payload/路径/权限/观察点不足？

Sink

• 是否定位 sink API、危险参数位置和执行条件？
• 是否证明 tainted 变量进入危险参数，而不是非危险参数？
• 是否覆盖 SQL/NoSQL/CMD/FILE/UPLOAD/ARCHIVE/XXE/DESER/SSRF/XSS/AUTH/CSRF/REDIR/HEADER/cache/queue 等相关 sink？
• 是否判断 sink 所在分支可执行？
• 是否引用或等价覆盖相关 EVID_* 证据点？

动态验证与负控

• 是否写出 baseline、强正控、负控请求？
• 是否追踪到授权测试范围内合理最高影响？
• 是否记录日志观察点和副作用观察点？
• 是否为 technical_confirmed 提供至少一个负控？
• 是否有清理/恢复证据或说明无副作用？
• 不能动态验证时是否降级并说明原因？

判定与报告

• 是否给出 finding 状态：technical_confirmed/candidate/blocked/rejected？
• 是否说明 candidate/blocked 缺哪些证据？
• 是否说明 rejected 的排除证据？
• 是否避免“已知 ID 后可利用”直接写高价值 technical_confirmed？
• 是否避免单对象结果外推成批量、全局或广义影响？
• 是否避免 scanner-only、external-tool-only、sink-only、regex-only、无负控 technical_confirmed？
• 是否写清 Source、Sink、Trace、防护缺口、复现、Web 操作、负控、影响证明、最高危害、修复建议、Allowed Claims、Forbidden Claims？
• 是否没有混入不可公开的环境细节、来源叙事、临时任务记录或运维内容？