Imported from a23882/instant-transmutation (skills/审计基础方法类/漏洞报告复核与证据门槛/SKILL.md). Install upstream with npx skills add a23882/instant-transmutation --skill 漏洞报告复核与证据门槛. Copyright stays with the author.

漏洞报告复核与证据门槛

权威边界

本 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 用来复核一份漏洞报告是否真的达到可声明、可复现、可修复、可提交或可关闭的证据门槛。它不是报告润色器，也不是风险等级翻译器；它的核心任务是逐条拆解报告里的安全声明，判断每条声明是否有足够证据支撑，哪些必须降级，哪些需要运行态补证，哪些应拒绝，哪些可以进入修复或提交流程。

调用时先写一行目标句：

我要复核：{报告标题 / 扫描器工单 / 外部模型 finding / 复测报告 / submission} 中的每个 claim 是否满足 route、source、trace、sink、transform、identifier acquisition、account/object matrix、strong positive、impact、negative control、cleanup、official security model、对外提交资格和 allowed claims 门槛。

典型触发场景：

• 报告声称“已确认”“高危”“严重”“可利用”“已修复”，但证据只包含截图、扫描器结果、callback、marker、错误栈、HTTP 200、版本号或 外部模型/工具自述。
• 报告准备写未认证、低权限、跨租户、数据泄露、RCE、SSRF 内网、账号接管、有效凭据、默认配置受影响、最新版本受影响、所有部署受影响等强声明。
• 报告里混用 pending、candidate、blocked、triaged、fixed、resolved、informative、duplicate、not applicable 等状态，需要统一成人工复核状态。
• 报告提供了代码片段，但没有完整 route/source/trace/sink 或没有证明防护是否有效。
• 报告提供了运行态复现，但缺少代码链路、负控、清理、最高危害追踪或官方安全模型。
• 报告来自扫描器、SAST/DAST/SCA/secret/IaC/container 工具，需要判断能否转成 technical_confirmed。
• 修复后复测只说“扫描器不报了”或“接口返回正常”，需要判断是否真的修复。

每次使用至少输出：

报告对象：
原始结论：
拆分后的 claims：
证据矩阵：route / source / trace / sink / transform / runtime / impact / negative control / cleanup / security model
标识符获取：{需要哪些 ID / handle / token / URI；攻击者如何获得；单对象/多对象/批量/不可获得}
账号矩阵：{attacker / owner / victim / control / cleanup；内部复核记录账号对象矩阵必要事实、主体 ID、租户、角色、对象归属、token/cookie 引用}
最终状态：technical_confirmed / candidate / blocked / rejected
外部门禁引用：提交资格由 `evidence/赏金资格.json` 与报告与复核类提交门禁裁决；本 Skill 不复制枚举、不生成状态。
Allowed Claims：
Forbidden Claims：
Missing Evidence：
最高危害追踪与停止原因：
修复或补证建议：

本 Skill 不替代漏洞类型专项、语言专项、Source-to-Sink、动态验证、官方文档门禁或误报降级；它负责把这些结果汇总成报告级裁决。报告级 technical_confirmed 必须比单点技术命中更严格，因为它会直接影响修复优先级、提交状态、风险等级和对外声明。

核心原则

1. 复核每个 claim，不复核一整段情绪化结论

一份报告通常包含多个 claim，必须拆开裁决：

一个 claim 成立，不代表其他 claim 自动成立。例如 callback 能证明服务端出网，但不能证明内网敏感信息泄露；SQL 错误能证明查询受影响线索，但不能证明数据可读；登录态可访问不能证明跨租户越权。

2. technical_confirmed 是证据闭环，不是工具状态

以下都不能直接写 technical_confirmed：

• 扫描器 high/critical。
• CodeQL/Semgrep/SARIF 给出数据流。
• DAST 触发 callback、错误、延迟、反射或 200。
• agent 说“我已复现”。
• 报告写了“technical_confirmed”或“triaged”。
• 平台状态是 triaged、resolved、fixed、validated。
• PoC 只有截图、视频或单个 marker。
• 只出现 sink、版本、secret 格式、header 缺失或配置弱项。

人工 technical_confirmed 至少需要：入口可达、source 可控、trace 闭合、sink 危险参数受控、防护不足或被绕过、强正控证明真实影响、负控成立、清理/恢复、官方安全模型支持漏洞解释、声明边界清楚。

2.1 环境版本分层不得混用

复核报告时必须单独标注：历史旧版本、当前本地/实验运行态、官方 fixed/patched 版本、真实目标版本。旧版本 confirmed 不能自动支撑当前版本 affected；当前版本 patched 不能自动支撑真实目标 fixed；真实目标版本 unknown 时不能写 latest affected、not_official_known、submit-ready 或最终提交。

如果报告依据来自历史 case、旧镜像、旧插件、旧 commit、旧远程记录或旧运行环境，必须写明“只证明旧环境”，并要求补当前版本、当前运行态和官方已知差异。

3. technical_confirmed 不等于 对外提交资格

报告复核必须同时裁决两层状态：

1. 技术状态：代码链路和运行态证据是否证明安全现象真实发生。
2. 报告状态：官方安全模型、scope、默认配置、known issue、expected behavior、accepted risk、范围或官方已知拒绝（外部裁决）、duplicate 和提交质量要求是否允许把它作为新漏洞、强漏洞或提交总入口报告提交。

技术链路已经闭环，不代表一定可以写“可提交高危漏洞”。例如：

• 受控实验环境中确实触发了管理员正常功能，但官方权限模型说明管理员本来被信任。
• 扫描器和强正控证明了 debug 配置泄露，但官方默认配置、生产建议或 scope 说明该配置不在报告范围。
• 本地复现证明服务端会请求内网 canary，但官方 URL fetch 模型把该行为定义为受信任连接器能力，除非继续证明未受信任主体跨越了防护边界。
• 代码层面确实存在对象访问差异，但官方对象模型、分享模型或公开资源模型说明该对象本来可被当前主体访问。
• 问题已经在官方 known issue、advisory、release note、accepted risk 或 duplicate 中覆盖，当前证据没有新入口、新主体、新对象、新默认配置或更高影响。

这类结果应写成 需要外部门禁裁决、内部修复建议、加固建议、规则优化或补证任务，而不是包装成 对外提交资格。如果官方安全模型还没有读完，结论最多只能是 官方已知排除（外部裁决），不能写“官方未公开”“默认配置受影响”“可提交 Critical”。

检验句：我证明的是技术现象，还是证明了未受信任主体违反官方承诺保护的安全边界？如果后者没有证据，就不能写对外可提交。

4. 授权实验模式下不保守停在弱证明

默认复核发生在自有、授权、隔离、可重置、可清理环境中。只要环境允许，就应从弱证明推进到当前可证明最高影响：

• SQL/NoSQL：从错误栈推进到布尔/时间/常量/测试数据/受控写入。
• RCE/CMD：从 marker 推进到 stdout/stderr、执行用户、工作目录、受控文件、受控回连。
• SSRF：从 callback 推进到最终 URL/IP、重定向后目标、内网 canary、metadata mock、响应可读或状态改变。
• XSS/SSTI：从反射推进到浏览器执行、上下文突破、存储触发、模板执行语义。
• IDOR/Auth：从 200 推进到 A/B 主体、对象归属、跨租户、敏感字段或状态改变。
• SCA：从版本命中推进到运行加载、调用可达、漏洞条件触发。
• Secret：从正则命中推进到可获得性、有效性、权限范围和轮换状态。
• DoS/资源：从单次慢响应推进到自有环境最小资源曲线、恢复时间、限流负控。

真正边界是授权、数据和可恢复性：不测试第三方真实系统，不读取真实生产用户数据，不输出真实凭据，不制造不可清理副作用。缺环境、账号、对象、日志、快照、清理能力时写 blocked，而不是把弱证明包装成 technical_confirmed。

5. 负控是提交材料质量的一部分

负控不是额外可选项。报告要从“这个输入会触发”升级到“这个输入因为漏洞条件触发”，必须有负控排除正常功能、缓存、随机、权限本来允许、错误页、WAF、限流、测试数据污染、环境差异。

报告没有负控时：

• 可以是 candidate。
• 可以是 blocked。
• 不能是高置信 technical_confirmed。
• 不能写 High/Critical 的强影响声明，除非解释为什么负控不适用且有等价证据。

6. 风险等级必须解释，不照抄 severity

风险等级不是扫描器 severity、CVSS 数字或平台优先级的复述。评级必须说明：

• 攻击者需要什么权限。
• 入口是否默认暴露。
• source 是否完全可控。
• 影响是否真实证明。
• 是否跨用户、跨租户、跨沙箱、跨网络、跨文件或跨权限。
• 是否需要用户交互、特定配置、特定版本、特定 feature flag。
• 是否有官方已知、accepted risk、expected behavior、范围或官方已知拒绝（外部裁决） 或 duplicate 风险。
• 哪些因素让风险降级。

若使用 CVSS，必须记录 vector 或至少记录关键指标；Base 分数不能替代目标环境、威胁状态、范围规则和提交材料质量裁决。

7. ID 类报告必须证明标识符获取链和账号矩阵

报告声称 IDOR、未授权、对象级授权缺失、跨用户读写、跨租户访问、批量导出、任意文件访问、分享资源越权、对象存储越权或“已知对象即可利用”时，复核人必须先拆出两个前置 claim：

1. 标识符获取 claim：攻击者如何从自身可达入口获得 user_id、object_id、tenant_id、workspace_id、project_id、file_id、document_id、workflow_id、plugin_id、分享 token、lookup handle、资源 URI、对象 key、物理表名或其他必要标识符。
2. 账号对象矩阵 claim：attacker、owner、victim、control、cleanup 的账号用途、用户名或邮箱、账号对象矩阵必要事实、主体 ID、tenant/workspace、role/scope、token/cookie 引用、对象归属、适用步骤和清理责任是否可复核。

报告只写“已知 ID 后可利用”“替换 ID 返回 200”“拿另一个用户对象 ID 后成功”，不能自动进入高价值 technical_confirmed。管理员手工给出的 ID、报告作者笔记里的 ID、聊天上下文里的 ID、历史附件里的 ID、截图里的 ID 只能作为定位样本，不能当攻击者可获得路径。

结论必须按可获得规模写窄：

• 单对象：证明该 ID 来自攻击者可达列表、详情、搜索、导出、日志、关系链、分享页、客户端状态、可预测序列或可推导路径。
• 多对象 / 批量 / 广义：证明 ID 能批量、持续、枚举、列表式、搜索式、导出式、日志泄露式、关系链式、分享页式或可推导式获得。
• 不可获得：不能把影响写成高价值 technical_confirmed；有排除证据时应 rejected，没有排除证据时写 candidate 或 blocked。

检验句：删掉报告作者手工提供的 ID 后，攻击者还能不能自己拿到目标 ID？如果报告写批量或全量，攻击者能不能稳定拿到足够多 ID？

8. 敏感信息边界必须可复核

复核报告应让接收者能复现和修复，不能因为保护敏感信息而删除账号矩阵、账号对象矩阵必要事实、对象归属、主体边界或必要复现变量：

• 多主体、对象边界或登录态相关结论必须引用账号对象矩阵、对象归属、主体边界、token/cookie 引用和清理责任；报告阶段按唯一模板渲染必要复现事实，本 Skill 不重新定义账号凭据字段或正文写法。
• 第三方或生产真实 token、cookie、password、API key、secret、session、个人敏感信息、客户数据、内部主机名、真实凭据不扩散原值；如确需保留，只能使用字段名、长度、前后少量字符、hash、时间戳、请求 ID、角色、对象 ID、测试 marker 等非账号对象矩阵字段线索，且不能替代账号对象矩阵事实渲染。
• 强验证使用测试数据、canary、mock metadata、测试账号、测试对象和可清理资源。
• 不能把完整真实凭据、真实生产用户数据或第三方目标作为公开证据。

审计目标

复核报告时必须回答十二个问题：

1. 报告中的每个 claim 是什么？是否被拆开？
2. 入口是否真实可达？route、handler、认证、中间件、feature flag 是否明确？
3. source 是否由攻击者控制？控制主体、权限、对象、租户、字段粒度是什么？
4. source 到 sink 的 trace 是否闭合？每一跳 file:line、变量、分支、权限是否可解释？
5. sink 的危险参数是否被污染？是否真的进入安全敏感语义？
6. transform、防护、鉴权、对象级授权、框架默认安全是否有效？
7. 运行态强正控是否证明了 CIA 影响或安全边界破坏？
8. 负控是否排除了误报、正常功能和环境噪声？
9. 最高危害是否已经追到当前授权范围上限？停止原因是否具体？
10. 报告阶段可渲染声明、禁止声明和缺失证据分别是什么？
11. 如果 claim 依赖对象标识符，攻击者获得 ID / handle / URI / token 的路径是否被证明，是否能支撑单对象、多对象、批量或广义声明？
12. 如果 claim 依赖多账号、多角色、多对象、跨租户或清理动作，账号对象矩阵是否能让复核人重放并区分 attacker、owner、victim、control 和 cleanup？

必须排除：

• scanner-only、external-tool-only、sink-only、source-only、trace-only。
• callback-only SSRF、marker-only RCE、error-only SQLi、reflect-only XSS、status-only IDOR、version-only SCA、regex-only secret。
• pending 写 technical_confirmed、fixed 无复测、resolved 无修复证据、duplicate 未去重、informative 写高危。
• 管理员正常能力、插件作者正常能力、沙箱内预期能力、配置 hardening、范围外、accepted risk 被写成新漏洞。
• 报告只描述现象，没有攻击者条件、服务端条件、安全影响和安全模型。

输入材料

报告材料

• 标题、漏洞类型、风险等级、摘要、影响范围、前置条件。
• 复现步骤、Web 操作、curl、Burp 请求、截图、视频、payload、请求响应、日志片段。
• 影响证明：数据、状态、权限、文件、命令、浏览器、服务端请求、secret、组件触发、资源消耗。
• 标识符获取证明：对象 ID、租户 ID、空间 ID、文件 URI、分享 token、lookup handle、物理表名或资源 key 的来源、可获得规模和攻击者可达路径。
• 多主体、对象边界或登录态相关结论必须引用账号对象矩阵、对象归属、主体边界、token/cookie 引用和清理责任；报告阶段按唯一模板渲染必要复现事实，本 Skill 不重新定义账号凭据字段或正文写法。
• 修复建议、修复状态、复测结果、回归测试。
• Allowed Claims、Forbidden Claims、Missing Evidence、停止继续升级原因。

代码与配置材料

• route、controller/handler、service、repository/DAO/mapper、model、serializer、template、middleware/filter/interceptor、policy/guard。
• 配置、默认值、feature flag、profile、插件、路由缓存、依赖注入、AOP、队列、cron、事件监听。
• 依赖清单、lockfile、SBOM、镜像、运行包、构建产物、版本输出。
• 单元测试、集成测试、权限矩阵测试、安全 wrapper、修复 PR。

运行态材料

• 授权范围、环境类型、版本、配置、账号、角色、租户、测试对象、前置快照、清理能力。
• baseline、weak positive、strong positive、impact escalation、negative control、retest 请求。
• 响应、日志、审计日志、数据库、缓存、队列、文件、对象存储、OOB、浏览器、命令输出。
• 标识符获取运行态：列表、详情、搜索、导出、日志、关系链、分享页、客户端状态、可预测序列、批量接口或不可获得证据。
• 多主体运行态：不同账号、不同租户、自己对象、他人对象、无权限主体、过期/无效 token、清理账号的请求与响应。
• 清理命令、恢复快照、复测后状态。

范围与安全模型材料

• 官方安全策略、scope、范围或官方已知拒绝（外部裁决）、known issues、accepted risk、默认配置、权限模型、release notes。
• 报告目标的资产、版本、模块、部署方式、第三方依赖和披露要求。
• 去重材料：历史报告、公告、issue、修复记录、重复工单。

Source 识别

报告复核中的 Source 识别不是重新枚举所有输入，而是验证报告声称的攻击者可控点是否真实、具体、可复现。

Source 复核问题

• source 是 query、path、body、header、cookie、JSON、XML、multipart、GraphQL、WebSocket、RPC、CLI、queue、webhook、file import、stored taint 还是 claim？
• 攻击者是谁：匿名、普通用户、低权限成员、租户管理员、owner、管理员、插件作者、部署者、内部服务、供应链输入？
• 控制粒度是什么：完整字符串、字段、数字、枚举、URL host、path 片段、模板片段、operator、对象 ID、排序字段、文件内容？
• source 是否被服务端重写、默认值覆盖、schema 限制、类型转换、白名单替换、对象绑定或权限过滤？
• source 是否需要不可获得对象 ID、secret、token、受害者交互、管理员配置或特定 feature flag？
• source 如果是对象标识符，报告是否证明“可传入”之外的“可获得”：攻击者从哪里看到、推导、枚举、搜索、导出、关系链获得它？
• source 如果支撑批量或全量影响，报告是否证明标识符可批量获得，而不是只给一个手工样本 ID？
• source 如果来自另一个账号或受害者对象，是否有账号对象矩阵证明对象归属、登录态隔离、角色差异和清理责任？
• 如果 source 来自存储值，谁能写入，谁会触发读取，是否跨越权限或租户？

Source 状态

controlled：攻击者能稳定控制漏洞所需字段和值。
partially-controlled：只能控制部分结构或枚举，需限定 claim。
stored-taint：写入端和触发端需要一起证明。
not-controlled：服务端覆盖、可信来源或不可获得前置条件。
unresolved：报告未提供足够材料。

Sink 识别

报告中出现危险函数、组件版本或响应差异，不代表 sink 成立。必须确认危险参数和执行语义。

Sink 复核问题

• sink 是 SQL/NoSQL/LDAP/XPath、shell/process、eval/template、SSRF HTTP client、文件读写、上传/解压、XML parser、反序列化、HTML/JS 输出、auth decision、secret 使用、依赖组件还是 IaC/container 配置？
• 报告是否定位了危险 API、参数位置和执行条件？
• source 是否进入危险参数，而不是进入日志、错误消息、label、注释、安全上下文或非危险参数？
• sink 所在分支是否在当前 route、权限、配置、feature flag、插件下执行？
• sink 行为是否是官方预期功能、管理员能力、插件能力、沙箱内能力、debug 功能或范围外能力？

Sink 状态

dangerous：危险参数被可控数据污染，且执行条件明确。
wrong-parameter：命中了函数名，但污染值不在危险参数。
non-dangerous：当前上下文无安全敏感语义。
unreachable：sink 不可达或未启用。
unresolved：报告缺少代码或运行态证据。

Transform / 防护检查

证据复核必须说明防护为什么不足，或为什么有效；不能只写“未过滤”“已过滤”。

防护复核标准

防护裁决

effective：同变量、同路径、同上下文、sink 前执行，负控证明阻断。
partial：只覆盖部分字段、分支、上下文或配置。
bypassed：强正控证明绕过。
unknown：报告没有足够证据。
not-applicable：该漏洞语义不依赖该防护。

unknown 不能支撑 technical_confirmed；effective 必须导致 rejected 或降级；partial/bypassed 需要继续补强证据。

路由与调用链追踪

证据复核必须把复现入口接到代码路径，或把代码路径接到可触发入口；缺一端时只能给出 candidate 或 blocked 方法性建议。

必查入口

• HTTP route、REST、GraphQL、WebSocket、SSE、gRPC、RPC。
• CLI command、cron、queue consumer、event listener、webhook、file import、batch job。
• CMS/plugin hook、admin ajax、template render、mobile API、serverless function。
• DAST 请求对应的真实浏览器流程。

调用链记录格式

entry -> handler -> binder/DTO -> service -> helper -> repository/client/parser/template -> sink
file:line -> function/method -> variable/field -> branch/auth -> next hop

必须处理：

• 父类、接口、trait、decorator、middleware、filter、interceptor、AOP。
• 依赖注入、服务容器、注解、attribute、反射、动态路由。
• 异步生产端和消费端；存储型漏洞的写入端和读取端。
• 修复前后版本差异。

数据流追踪步骤

第 1 步：冻结复核对象

记录报告标题、报告来源、目标资产、版本、commit、运行环境、测试账号、测试对象、复核时间、原始状态和原始风险等级。不要把不同版本、不同部署、不同配置的证据混在一起。

第 2 步：拆分 claims

把报告拆成最小可裁决单元：

Claim A：漏洞类型成立。
Claim B：攻击者条件成立。
Claim C：服务端条件成立。
Claim D：安全影响成立。
Claim E：安全模型被违反。
Claim F：风险等级成立。
Claim G：报告可提交或可关闭。
Claim H：修复已完成。

第 3 步：建立证据矩阵

route: present / missing / unresolved
source: controlled / partial / not-controlled / unresolved
binding: clear / partial / missing
trace: complete / partial / broken / tool-only
sink: dangerous / wrong-parameter / non-dangerous / unresolved
transform: bypassed / partial / effective / unknown
runtime: strong / weak / missing
impact: proven / weak / missing
identifier_acquisition: proven-single / proven-bulk / manual-sample-only / missing / not-needed
account_object_matrix: complete / partial / missing / not-needed
negative_control: present / missing / not-applicable-with-reason
cleanup: done / not-needed / missing
security_model: violates / expected / unknown / 范围或官方已知拒绝（外部裁决）
security_model_status: 记录官方安全模型是否已复核、是否支持当前声明、是否属于预期行为/accepted risk/范围拒绝/known issue 等；具体状态值以对应中文 schema、template 和 validator 为准。
target_scope_status: in-scope / 范围或官方已知拒绝（外部裁决） / unknown
默认配置边界说明: default-affected / non-default-only / debug-local-only / admin-config-only / unknown
official_known_status: not-known / duplicate / known-limitation / advisory-covered / unknown
预期行为说明: violates-boundary / expected / unknown
accepted risk 说明: not-accepted / accepted / unknown
外部门禁引用：提交资格由 `evidence/赏金资格.json` 与报告与复核类提交门禁裁决；本 Skill 不复制枚举、不生成状态。
forbidden_submit_reasons: []

第 4 步：找最弱证据点

结论由最弱关键证据决定：

• route 缺失：不能 technical_confirmed。
• source 不可控：rejected 或降级。
• trace partial：candidate 或 blocked。
• sink 参数错误：rejected。
• 防护 effective：rejected。
• strong positive 缺失：不能强影响 technical_confirmed。
• impact weak：只能写弱声明。
• identifier_acquisition missing：依赖 ID 的越权、未授权、对象读取、对象写入、跨租户、批量或全量 claim 不能 technical_confirmed。
• identifier_acquisition manual-sample-only：只能写“手工样本下可疑”或 candidate，不得写攻击者稳定可利用。
• account_object_matrix missing：多主体、多对象、跨租户或清理相关 claim 不能 technical_confirmed。
• 负控缺失：不得高置信。
• cleanup 缺失：不得声称验证闭环完整。
• security model unknown：不能对外提交。
• security_model_status unknown：技术强证据可以继续裁决，但不能写对外可提交或默认影响的强声明。
• 外部门禁未裁决为可提交：不得把 technical_confirmed 包装成可提交漏洞；应写 需要外部门禁裁决、candidate 或 blocked。
• official_known_status 为 duplicate / known-limitation 时：除非证明新主体、新入口、新对象、新版本、新默认配置或更高影响，否则不得写新漏洞 technical_confirmed。
• 预期行为或 accepted risk 已成立时：只能写内部加固、文档改进或 需要外部门禁裁决；没有新边界时不得对外提交。

第 5 步：复核运行态证据

逐项检查 baseline、strong positive、impact escalation、negative control、cleanup。确认每个请求或操作的账号、对象、租户、marker、时间、请求 ID、响应、日志和副作用。

第 6 步：复核最高危害

判断报告是否停在弱证明。如果能在授权环境内安全推进，应要求补证；如果不能推进，必须写清停止原因。

第 7 步：写状态裁决

Status：本 Skill 只给 technical_status 方法性建议；提交资格由 `evidence/赏金资格.json` 与报告与复核类提交门禁裁决。
Reason:
Evidence strongest point:
Evidence weakest point:
Official Security Model:
对外提交资格 Status:
对外提交资格 Blockers:
Allowed Claims:
Forbidden Claims:
Missing Evidence:
Next action:

必检证据点

报告结构证据

• 标题是否说明漏洞类型、位置和影响。
• 目标资产、位置、角色、版本、配置是否明确。
• 复现步骤是否可按顺序执行。
• 预期结果和实际结果是否区分。
• 影响说明是否绑定证据，而不是泛泛描述。
• 修复建议是否指向根因。

入口证据

• method/path/handler 或 message/topic/command。
• route 注册、profile/feature flag、插件启用状态。
• middleware/filter/interceptor/guard/policy 顺序。
• 浏览器流程或 API 调用如何到达该入口。

Source 证据

• 字段名、来源、绑定位置。
• 可控主体、权限、租户、对象。
• 控制粒度和前置条件。
• 存储型污染的写入端和触发端。

标识符获取证据

• EVID_IDENTIFIER_ACQUISITION：列出漏洞成立所需的每个 user_id、object_id、tenant_id、workspace_id、project_id、file_id、document_id、workflow_id、plugin_id、分享 token、lookup handle、资源 URI、对象 key、物理表名或其他标识符。
• 对每个标识符写清来源：列表响应、详情响应、搜索、导出、日志泄露、关系链、分享页、客户端状态、可预测序列、批量接口、受害者交互、管理员手工提供、历史附件、截图、报告笔记或未知。
• 对每个标识符写清攻击者可达性：攻击者自己能否在同权限下获得，是否需要 victim 主动分享，是否需要管理员视角，是否只能在测试会话里手工拿到。
• 对每个标识符写清可获得规模：单对象、同类多对象、批量、持续、可枚举、可搜索、可导出、可推导、不可获得。
• 报告写“批量”“全量”“所有用户”“所有租户”“任意对象”“任意文件”时，必须有能支持该规模的标识符获取证据；只有一个样本 ID 时，只能支撑该样本或同路径可获得对象。

账号对象矩阵证据

• 多主体、对象边界或登录态相关结论必须引用账号对象矩阵、对象归属、主体边界、token/cookie 引用和清理责任；报告阶段按唯一模板渲染必要复现事实，本 Skill 不重新定义账号凭据字段或正文写法。
• 每个账号至少记录用途、用户名或邮箱、账号对象矩阵必要事实、主体 ID、tenant/workspace、role/scope、token/cookie 引用、对象归属、适用步骤和清理责任。
• 多主体 claim 必须证明 token/cookie 没有混用，attacker 不是 owner，victim 对象确实属于 victim，control 对象用于证明正常权限路径。
• 多主体、对象边界或登录态相关结论必须引用账号对象矩阵、对象归属、主体边界、token/cookie 引用和清理责任；报告阶段按唯一模板渲染必要复现事实，本 Skill 不重新定义账号凭据字段或正文写法。

Trace 证据

• 每一跳 file:line、变量名、函数、分支、异常、早退、权限判断。
• DTO/Model/Serializer/Mapper/ORM/队列/缓存/事件/AOP/DI 的字段映射。
• 工具 trace 与人工 trace 的差异。

Sink 证据

• 危险 API/函数/组件/配置。
• 危险参数位置。
• 执行条件。
• sink 所在分支可达性。

防护证据

• sanitizer/validator/escape/allowlist/parameterization/authz 是否同变量、同路径、同上下文。
• 框架默认防护是否启用，是否被 raw API 绕过。
• 官方缓解是否生效或被绕过。

官方安全模型与对外提交资格 证据

• EVID_OFFICIAL_SECURITY_MODEL：准备写报告、定级、对外提交、默认配置受影响、未认证/低权限/跨租户/有效凭据/RCE/SSRF 内网/批量越权等强声明时，必须证明官方 SECURITY、安全策略、scope、API 文档、权限模型、对象模型、默认配置、known issue、expected behavior、accepted risk、范围或官方已知拒绝（外部裁决）、duplicate 和提交材料质量规则已经裁决。
• security_model_status 必须说明官方资料是已复核、unknown、预期行为拒绝（外部裁决）、accepted-risk、范围或官方已知拒绝（外部裁决）、hardening-only、known-issue 还是 reviewed_supports_current_claim。
• target_scope_status 必须说明目标资产、版本、模块、部署方式、漏洞类型是否在范围内；范围 unknown 时不能写对外可提交。
• 默认配置边界说明 必须区分默认受影响、仅非默认配置、仅 debug/local、仅管理员配置或 unknown；不能把当前实验环境配置直接外推成默认配置受影响。
• official_known_status 必须完成去重：not-known、duplicate、known-limitation、advisory-covered 或 unknown；duplicate/known-limitation 只有证明新边界时才可继续写新漏洞。
• 预期行为 / accepted risk 说明 必须回答该行为是否官方预期、信任主体正常能力、accepted risk 或 hardening only。
• 外部门禁裁决必须单独输出，不得被技术状态替代；官方模型 unknown、scope unknown、默认配置 unknown、known issue unknown 时，不能写 对外提交资格。
• forbidden_submit_reasons 必须列出阻塞项：缺官方资料、范围不明、默认配置不明、已知风险、预期功能、accepted risk、范围或官方已知拒绝（外部裁决）、重复、提交材料质量不满足、非账号类敏感材料展示边界不足或缺账号/对象矩阵。

动态证据

• baseline、strong positive、impact escalation、negative control、retest。
• 请求、响应、日志、审计日志、数据库/缓存/队列/文件/OOB/浏览器/命令输出。
• 清理/恢复或无副作用证明。

声明边界证据

• Allowed Claims：可以写的最强事实。
• Forbidden Claims：不能写的更强事实。
• Missing Evidence：升级所需证据。
• Stop Reason：停止追踪最高危害的具体原因。

动态验证触发条件

必须动态验证才能 technical_confirmed

• 越权、IDOR、权限绕过、跨租户、对象级授权缺失；同时必须动态证明标识符获取链和账号对象矩阵，而不是只替换一个已知 ID。
• SSRF、开放重定向、webhook、URL preview、服务端请求。
• SQL/NoSQL/LDAP/XPath 注入。
• 文件读取、文件写入、上传、解压、路径穿越、对象存储 key 越界。
• 命令执行、代码执行、模板表达式、反序列化、XXE。
• XSS、DOM XSS、存储型 XSS、响应头注入。
• CSRF 和任何状态改变类漏洞。
• SCA 可达漏洞和供应链组件触发。
• Secret 有效性、权限范围和暴露面。
• 资源消耗和可用性影响。

对依赖 ID 的报告，动态验证至少包含三组动作：

1. attacker 用自身可达入口获得目标标识符或证明无法获得。
2. attacker 使用该标识符触发越权读、写、删、导出、绑定、复制、签名、状态改变或其他影响。
3. control 账号、自己对象、他人对象、无权限主体或不同租户负控证明差异来自授权缺失，而不是对象公开、正常共享、缓存、会话混用或测试数据污染。

可以先 candidate

• 代码 trace 基本成立但缺账号、对象、日志、运行配置或强正控。
• 报告证明低层现象，但未证明高层影响。
• 扫描器结果和人工 trace 一致，但缺运行态。
• 组件版本和调用点存在，但漏洞条件未触发。
• secret 暴露可疑，但有效性和权限未知。

必须 blocked

• 必须双账号、双租户、双对象才能判断。
• 必须真实配置、feature flag、license、插件启用状态才能判断。
• 必须日志、OOB、浏览器、队列、数据库、文件系统观察点。
• 必须构建产物、运行包、镜像 digest 或版本输出。
• 必须快照、重置或清理能力才能做强验证。

不能动态验证的边界

• 目标不在授权范围。
• 会访问第三方真实系统或范围外资产。
• 会读取、导出、泄露真实生产用户数据。
• 会输出、复用、转储真实 secret、token、cookie、密码或云凭据。
• 无测试账号、测试对象、日志、快照、重置或清理能力。
• 副作用不可控、不可回滚或不可隔离。

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

通用验证结构

baseline -> strong_positive -> impact_escalation -> negative_control -> cleanup_or_reset -> retest_if_fixed

• baseline：证明正常流程和观察点有效。
• strong positive：证明漏洞语义，而不是只证明 marker。
• impact escalation：在授权范围内继续追最高可证明影响。
• negative control：只改变一个关键变量，证明差异来自漏洞条件。
• cleanup/reset：恢复测试对象、测试文件、缓存、队列或快照。
• retest：修复后重放 strong positive 和 negative control。

强验证目标

请求记录框架

# baseline
curl -i -s -k \
  -X '{METHOD}' \
  '{SCHEME}://{HOST}{PATH}' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {TEST_TOKEN}' \
  -H 'X-Audit-Marker: AUDIT_BASELINE_{ID}' \
  --data '{BASELINE_JSON}'

# strong positive
curl -i -s -k \
  -X '{METHOD}' \
  '{SCHEME}://{HOST}{PATH}' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {LOW_PRIV_TEST_TOKEN}' \
  -H 'X-Audit-Marker: AUDIT_POSITIVE_{ID}' \
  --data '{STRONG_POSITIVE_JSON}'

# negative control
curl -i -s -k \
  -X '{METHOD}' \
  '{SCHEME}://{HOST}{CONTROL_PATH}' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {CONTROL_TOKEN}' \
  -H 'X-Audit-Marker: AUDIT_NEGATIVE_{ID}' \
  --data '{NEGATIVE_CONTROL_JSON}'

最高危害追踪

报告复核时要判断“报告停在哪一层”和“还能不能在授权范围内继续证明”。

现象 -> 可控 -> sink 执行 -> 弱正控 -> 强正控 -> CIA 影响 -> 跨主体/对象/租户/沙箱/网络/文件边界 -> 负控 -> 清理 -> 报告声明

必须降级的低层证明

• callback-only SSRF：只能说服务端请求了受控端点，不能说内网敏感信息泄露。
• marker-only RCE：只能说输入影响响应或执行链可疑，不能说命令执行，除非证明执行语义。
• error-only SQLi：只能说查询构造可疑，不能说数据读取。
• reflect-only XSS：只能说反射，不能说浏览器执行。
• status-only IDOR：只能说 ID 影响响应，不能说越权。
• known-ID-only IDOR：只能说“在手工样本 ID 下存在可疑对象访问/状态改变”，不能说攻击者稳定越权、批量越权或高价值 technical_confirmed。
• single-ID extrapolation：只能支撑单对象或同一获取路径下的对象，不能外推到任意用户、任意租户、全量对象或批量导出。
• version-only SCA：只能说版本命中，不能说可利用。
• regex-only secret：只能说疑似凭据，不能说有效凭据泄露。

合格停止原因

• 已达到当前授权范围内最高可证明影响。
• 继续需要真实用户数据、真实凭据、第三方系统或不可清理副作用。
• 缺双账号、双租户、测试对象、日志、OOB、浏览器、队列或快照。
• 防护在同变量、同路径、同上下文被证明有效。
• 官方安全模型说明这是预期功能且没有新边界。
• 现有影响已足以支撑准确等级，继续升级没有必要。

负控设计

负控类型

负控判读

• 正控成功、负控失败：继续确认差异能否归因到安全边界。
• 正控和负控都成功：可能是正常功能、权限本来允许、对象公开或测试设计错误。
• 正控和负控都失败：可能 payload 未到 sink、环境不匹配、防护有效或观察点错误。
• 负控不稳定：不能 technical_confirmed；记录干扰因素。
• 负控缺失：不得高置信 technical_confirmed。

technical_status 方法性判定边界

technical_confirmed

必须同时满足：

• 报告 claims 已拆分。
• route/entrypoint 可达。
• source 可控，攻击者条件明确。
• trace 人工闭合。
• sink 危险参数被污染并执行。
• transform/防护不足或被绕过。
• runtime evidence 证明当前版本和配置受影响。
• strong positive 证明真实影响。
• negative control 成立。
• 如果 claim 依赖对象标识符，EVID_IDENTIFIER_ACQUISITION 证明攻击者获得路径，且声明范围不超过可获得规模。
• 如果 claim 依赖多主体、多对象、跨租户、跨角色、受害者对象或清理动作，EVID_ACCOUNT_OBJECT_MATRIX 完整证明账号用途、账号对象矩阵必要事实、主体 ID、租户/工作区、角色、对象归属、token/cookie 隔离和清理责任。
• cleanup/recovery 完成或无副作用。
• EVID_OFFICIAL_SECURITY_MODEL 已裁决，security model 说明该行为违反官方预期保护边界，而不是受信任主体正常能力、expected behavior、accepted risk、范围或官方已知拒绝（外部裁决）、hardening only、known limitation 或 duplicate。
• scope、默认配置、版本、known issue、duplicate、expected behavior、accepted risk、范围或官方已知拒绝（外部裁决） 已复核，并且不阻塞当前报告声明。
• 如果该结论准备进入提交总入口报告、提交、评级、修复优先级或强漏洞声明，本 Skill 只提示需要外部门禁裁决；是否可主提交由 evidence/赏金资格.json 与报告与复核类提交门禁裁决。
• Allowed Claims 与 Forbidden Claims 写清。
• 风险等级有证据依据。

candidate

适用：

• 静态证据较完整但缺强正控、负控、运行态、官方安全模型或 对外提交裁决。
• 报告只证明低层现象，但值得继续补证。
• 代码 trace 有缺口，但 source/sink 方向合理。
• 修复建议可能正确，但根因未完全证明。
• 影响需要双账号、双对象、日志或 OOB 才能确认。
• 只有“已知 ID 后可利用”、手工样本 ID、截图 ID、历史附件 ID、报告笔记 ID 或管理员视角 ID，但尚未证明攻击者如何获得。
• 单对象样本成立，但批量、全量、任意对象、所有用户、所有租户或广义声明缺可获得规模证据。
• 多账号步骤存在，但账号矩阵缺账号对象矩阵必要事实、主体 ID、对象归属、token/cookie 隔离或清理责任。
• 可能违反官方安全模型，但官方资料、scope、默认配置、known issue 或 duplicate 尚未读完；不能写对外可提交 语气。

blocked

适用：

• 必须运行环境、账号、对象、租户、日志、浏览器、队列、构建产物、feature flag、license、插件或清理能力才能判断。
• 必须运行态确认标识符是否能从列表、详情、搜索、导出、日志、关系链、分享页、客户端状态、可预测序列或批量接口获得。
• 必须运行态确认账号矩阵、对象归属、tenant/workspace、role/scope、token/cookie 隔离和清理能力。
• 必须复测才能确认 fixed/resolved。
• 必须运行态对齐官方 scope、安全模型、默认配置、known issue、duplicate、expected behavior 或 accepted risk 才能对外提交。
• 必须补运行版本、配置、默认值、feature flag、插件启用状态或构建产物，才能判断官方模型是否适用。

rejected

只有明确否定证据才 rejected：

• 入口不可达或未启用。
• source 不可控。
• trace 断裂且已证伪。
• sink 参数错误或无安全语义。
• 防护 effective。
• 影响不存在或仅普通 bug。
• 版本未加载、组件不可达、secret 无效且不可获得。
• 代码、接口和运行态均证明攻击者无法获得必要对象标识符，且不存在列表、搜索、导出、日志、关系链、分享页、可预测或可推导路径。
• 多主体报告经复核证明其实使用同一账号、同一 token、同一对象、对象公开或 owner/victim 边界不成立。
• 完全重复已知问题且没有新边界。
• 范围外且只讨论提交状态。
• 官方安全模型明确这是 expected behavior、受信任主体正常能力、accepted risk、范围或官方已知拒绝（外部裁决）、hardening only、known limitation 或 duplicate，且当前证据没有新入口、新主体、新对象、新版本、新默认配置、新边界或官方缓解绕过。
• 官方默认配置、版本或部署方式证明当前强 claim 不成立，例如只在 debug/local/危险开关/管理员配置下出现，却被报告写成默认生产影响。

rejected 必须写证据，不得只写“误报”。

报告与产物边界

本 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：参数化、结构化 builder、动态字段 allowlist、禁止 raw fragment。
• RCE/CMD：不用 shell 拼接，固定命令，参数数组，最小权限，隔离执行环境。
• SSRF：协议/域名/端口 allowlist，解析后 IP 校验，重定向后重校验，metadata 阻断，出网隔离。
• XSS/SSTI：上下文编码，避免 raw/safe，模板自动转义，CSP 补充，浏览器回归。
• 文件/上传/归档：canonicalize 后 base 约束，拒绝链接和特殊文件，随机文件名，不可执行目录。
• Auth/IDOR：服务端对象级授权，tenant 绑定，批量逐项校验，不信任前端 owner/role。
• CSRF：状态变更 token，Origin/Referer 辅助，覆盖 JSON/multipart/method override。
• Secret：轮换、吊销、清理历史、降低权限、迁移密钥管理、日志脱敏。
• SCA：升级安全版本；无法升级时关闭漏洞功能、加配置缓解、限制入口，并确认运行包实际更新。
• IaC/container：最小权限、去特权容器、限制 hostPath/capability、网络隔离、认证/TLS。
• 标识符暴露：列表、搜索、导出、分享页、日志、客户端状态和批量接口同样要做对象级授权；不可预测 ID 只能降低枚举概率，不能替代服务端授权。
• 需要外部门禁裁决：不要写对外漏洞修复结论；先补官方材料、补 scope/default config/known issue 去重、收缩声明、转内部加固、补文档/警告/审计日志、优化扫描规则或登记 accepted risk。只有证明新主体、新入口、新对象、新默认配置、新版本、更高影响或官方缓解绕过后，才允许重新交由外部门禁评估对外提交资格。
• expected behavior / accepted risk / 范围或官方已知拒绝（外部裁决）：修复建议应写成“加固、文档、默认安全配置、审计日志、二次确认、最小权限、检测规则优化”，不得要求删除正常功能或把范围外问题包装成漏洞修复。

修复后必须重放 strong positive 和 negative control；扫描器不再报只能作为辅助，不能替代复测。

禁止事项

• 禁止 scanner-only technical_confirmed。
• 禁止 external-tool-only technical_confirmed。
• 禁止 sink-only technical_confirmed。
• 禁止 source-only technical_confirmed。
• 禁止 trace-only technical_confirmed。
• 禁止没有负控就写高置信 technical_confirmed。
• 禁止只看 200、500、callback、marker、error、reflect、version、regex。
• 禁止把 pending、triaged、fixed、resolved、validated 直接当人工 technical_confirmed。
• 禁止把 fixed 写成已修复而没有复测证据。
• 禁止把 technical_confirmed 直接写成对外可提交。
• 禁止在官方安全模型、scope、默认配置、known issue、expected behavior、accepted risk 或 范围或官方已知拒绝（外部裁决） 仍为 unknown 时写对外可提交、对外可提交、高危默认影响或官方未公开。
• 禁止把 需要外部门禁裁决 写成“已确认可提交漏洞”。
• 禁止把 expected behavior、受信任主体正常能力、accepted risk、范围或官方已知拒绝（外部裁决）、hardening only、known limitation 或 duplicate 包装成新漏洞，除非证明新主体、新入口、新对象、新版本、新默认配置、更高影响或官方缓解绕过。
• 禁止把非默认 debug/local/危险开关/管理员配置影响写成默认生产影响，除非有官方默认值或全新安装证据。
• 禁止把 callback-only SSRF 写成内网敏感访问。
• 禁止把 marker-only RCE 写成命令执行。
• 禁止把 error-only SQLi 写成数据读取。
• 禁止把 reflect-only XSS 写成浏览器执行。
• 禁止把 status-only IDOR 写成越权。
• 禁止把 known-ID-only IDOR 写成高价值 technical_confirmed。
• 禁止把“已知 ID 后可利用”“替换 ID 返回 200”“拿到另一个用户对象 ID 后成功”写成攻击者稳定可利用，除非证明攻击者如何获得该 ID。
• 禁止把管理员手工给出的 ID、报告作者笔记里的 ID、聊天上下文里的 ID、历史附件里的 ID、截图里的 ID 当成攻击者可获得路径。
• 禁止用单个样本 ID 外推批量、全量、任意对象、所有用户、所有租户、所有工作区或广义影响。
• 禁止账号矩阵缺账号对象矩阵必要事实、主体 ID、租户/工作区、角色、对象归属、token/cookie 引用和清理责任时写多主体 technical_confirmed。
• 禁止把 version-only SCA 写成组件漏洞可达。
• 禁止把 regex-only secret 写成有效凭据泄露。
• 禁止在报告中输出完整真实 secret、token、cookie、密码或可复用凭据。
• 禁止为了数量把低价值、无影响、范围外、hardening only 写成漏洞。
• 禁止把运行、部署、恢复、监控、调度、容器维护内容混进本 Skill。
• 禁止把个人机器环境信息、不可公开编号、临时对话过程或专用平台词写进通用 Skill 正文。
• 禁止越出授权范围、测试第三方真实系统、读取真实生产用户数据、泄露真实凭据或执行不可清理验证。
• 禁止弱 payload 失败直接 rejected。
• 禁止未追踪最高影响且没有停止原因。

自检清单

报告结构

• 是否拆分每个 claim？
• 是否区分原报告状态与人工复核状态？
• 是否写清风险等级依据和限制因素？
• 是否写清目标、版本、配置、角色、对象、前置条件？
• 是否保护敏感信息？
• 如果报告依赖 ID、URI、token、object key 或物理表名，是否写清标识符获取路径和可获得规模？
• 如果报告依赖多账号、多对象、跨租户或清理动作，是否有账号矩阵并能重放？

入口与 Source

• 是否有 route/message/command 入口证据？
• 是否有 handler/controller 证据？
• 是否证明 source 字段、绑定位置、控制主体和控制粒度？
• 是否排除服务端覆盖、默认值、枚举和类型转换？
• 存储型 source 是否证明写入端和触发端？
• 对象标识符 source 是否证明攻击者可获得，而不是只证明可传入？
• 批量、全量、任意对象声明是否有批量获取 ID 的证据？

Trace 与 Sink

• 是否有 source 到 sink 每一跳 file:line？
• 是否记录变量名变化、DTO/Model 转换、分支和权限检查？
• 是否处理父类、接口、trait、middleware、decorator、DI、AOP、事件、队列？
• 是否定位 sink 的危险参数位置？
• 是否证明 sink 在当前入口和配置下执行？

防护与影响

• 防护是否同变量、同路径、同上下文？
• 框架默认防护是否真实启用且未被绕过？
• 是否证明安全影响，而不是普通错误、200、回显、callback、marker？
• 是否明确测试数据、权限突破、状态改变、服务端请求、文件越界、执行语义或浏览器执行？

强正控与最高危害

• 是否有 baseline？
• 是否有足够证明漏洞语义的 strong positive？
• 是否继续 impact escalation？
• 是否写明最高已证明影响？
• 是否写明停止继续升级原因？

负控与清理

• 是否有至少一个负控？
• 高风险结论是否有多组负控或等价解释？
• 负控是否只改变一个关键变量？
• 是否排除缓存、随机、限流、错误页、WAF、正常权限？
• 是否记录清理/恢复或无副作用原因？

结论与修复

• technical_confirmed 是否满足 route、source、trace、sink、transform、runtime、impact、negative control、cleanup、security model？
• 是否区分 technical_confirmed 和对外提交资格？
• 如果要写对外可提交，是否具备 EVID_OFFICIAL_SECURITY_MODEL？
• 是否裁决 scope、默认配置、版本、known issue、duplicate、expected behavior、accepted risk、范围或官方已知拒绝（外部裁决） 和提交材料质量要求？
• security_model_status 为 unknown 时，是否降级为 candidate、blocked 或 官方已知排除（外部裁决），而不是写可提交漏洞？
• 外部门禁未裁决为可提交 时，是否写清 forbidden_submit_reasons 和 forbidden external claims？
• 是否避免把 expected behavior、受信任主体能力、accepted risk、范围或官方已知拒绝（外部裁决）、hardening only、known limitation 或 duplicate 包装成新漏洞？
• 依赖 ID 的 technical_confirmed 是否同时满足 EVID_IDENTIFIER_ACQUISITION？
• 多主体 technical_confirmed 是否同时满足 EVID_ACCOUNT_OBJECT_MATRIX？
• candidate 是否写清补证路线？
• blocked 是否写清缺账号、对象、日志、环境、构建或清理能力？
• rejected 是否有明确否定证据？
• 是否写 Allowed Claims 与 Forbidden Claims？
• 是否把 known-ID-only、手工样本 ID、截图 ID、历史附件 ID 或报告笔记 ID 降级？
• 是否避免单对象样本外推成批量、全量、任意对象、全租户或全用户？
• 是否提供具体修复建议和回归验证？
• 是否去除个人机器环境信息、不可公开编号、临时对话过程和专用平台词？

检验句：报告写得像 technical_confirmed，不等于证据达到 technical_confirmed；technical_confirmed，也不等于对外提交资格。只有当每个强 claim 都能被 route、source、trace、sink、impact、negative control、cleanup、security model 和 对外提交裁决支撑时，才允许写对外提交资格；否则必须降级、写 需要外部门禁裁决 或补证。