--- name: vulnerability-report-evidence-review description: Use when reviewing vulnerability reports, reproduction notes, scanner tickets, submission drafts, audit findings, or claimed technical_confirmed vulnerabilities for evidence quality, claim boundaries, impact proof, downgrade decisions, retest needs, remediation readiness, or 对外提交资格 status. --- # 漏洞报告复核与证据门槛 ## 权威边界 本 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 用来复核一份漏洞报告是否真的达到可声明、可复现、可修复、可提交或可关闭的证据门槛。它不是报告润色器，也不是风险等级翻译器；它的核心任务是逐条拆解报告里的安全声明，判断每条声明是否有足够证据支撑，哪些必须降级，哪些需要运行态补证，哪些应拒绝，哪些可以进入修复或提交流程。 调用时先写一行目标句： ```text 我要复核：{报告标题 / 扫描器工单 / 外部模型 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。 - 修复后复测只说“扫描器不报了”或“接口返回正常”，需要判断是否真的修复。 每次使用至少输出： ```text 报告对象： 原始结论： 拆分后的 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 类型 | 例子 | 必须证明 | |---|---|---| | 漏洞类型 | “这是 SSRF / SQLi / RCE / IDOR” | source、sink、trace、漏洞语义 | | 攻击者条件 | “未认证 / 普通用户可利用” | route、认证状态、角色、对象、前置条件 | | 服务端条件 | “默认配置 / 最新版本受影响” | 版本、配置、feature flag、依赖、部署方式 | | 安全影响 | “可读数据 / 可执行命令 / 可越权修改” | 强正控、日志、副作用、负控 | | 范围与新颖性 | “可提交 / 非重复 / 范围内” | scope、known issues、官方门禁、去重 | | 风险等级 | “High/Critical” | 可达性、权限、影响、利用复杂度、限制因素 | | 修复状态 | “已修复 / 已缓解” | 修复变更、复测、强正控阻断、负控正常 | 一个 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 状态 ```text 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 状态 ```text dangerous：危险参数被可控数据污染，且执行条件明确。 wrong-parameter：命中了函数名，但污染值不在危险参数。 non-dangerous：当前上下文无安全敏感语义。 unreachable：sink 不可达或未启用。 unresolved：报告缺少代码或运行态证据。 ``` ## Transform / 防护检查 证据复核必须说明防护为什么不足，或为什么有效；不能只写“未过滤”“已过滤”。 ### 防护复核标准 | 防护 | 有效条件 | 常见报告缺陷 | |---|---|---| | 参数化 | 同一 SQL/查询值位置使用绑定变量 | 动态列名、表名、排序、operator、raw 片段仍拼接 | | allowlist | 服务端固定集合，失败阻断 | 黑名单、前缀判断、用户可写列表、只校验长度 | | escape/encode | 与 HTML/JS/CSS/URL/header/shell/SQL 上下文匹配 | HTML escape 被拿来证明所有上下文安全 | | normalize/canonicalize | 在权限和路径判断前执行 | realpath 后没重新校验 base，符号链接/双编码遗漏 | | schema/type | 服务端执行且覆盖实际字段 | 客户端校验、只校验另一个字段、默认值覆盖不清楚 | | authz/policy | sink 前执行，绑定当前主体、对象和租户 | 只在 UI、列表页或单项接口检查，批量/导出/异步遗漏 | | framework default | 当前配置启用且调用方式未绕过 | raw API、关闭 autoescape、禁用 CSRF、跳过 middleware | | rate limit/WAF | 稳定阻断漏洞语义 | 只挡当前 payload，换编码/结构/路径仍可达 | ### 防护裁决 ```text 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 请求对应的真实浏览器流程。 ### 调用链记录格式 ```text 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 把报告拆成最小可裁决单元： ```text Claim A：漏洞类型成立。 Claim B：攻击者条件成立。 Claim C：服务端条件成立。 Claim D：安全影响成立。 Claim E：安全模型被违反。 Claim F：风险等级成立。 Claim G：报告可提交或可关闭。 Claim H：修复已完成。 ``` ### 第 3 步：建立证据矩阵 ```text 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 步：写状态裁决 ```text 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、密码或云凭据。 - 无测试账号、测试对象、日志、快照、重置或清理能力。 - 副作用不可控、不可回滚或不可隔离。 ## 授权实验模式下的强验证方法 ### 通用验证结构 ```text 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。 ### 强验证目标 | 类型 | 弱证据 | 强证据 | 负控 | |---|---|---|---| | SQL/NoSQL | 错误、扫描命中 | boolean/time/常量/测试数据/受控写入 | false 条件、安全值、参数化修复 | | RCE/CMD | marker | stdout/stderr、执行用户、工作目录、受控文件、受控回连 | 普通值、移除字段、禁止命令 | | SSRF | DNS/callback | 最终 URL/IP、内网 canary、metadata mock、响应可读 | allow/deny host、重定向、协议/IP 变体 | | XSS/SSTI | reflect | 浏览器执行、上下文突破、存储触发、模板执行 | 编码值、安全模板、不同上下文 | | 文件 | 路径拼接 | resolved target、测试文件读写、写后可达、覆盖/追加 | base 内外、安全文件、修复后 | | IDOR/Auth | 200、已知 ID 后成功 | 标识符获取链、账号对象矩阵、A/B 主体、对象归属、跨租户、敏感字段、状态改变、批量可获得规模 | 自己对象、他人对象、无权限、不可获得 ID、不同租户、token/cookie 隔离 | | SCA | version hit | 运行加载、调用路径、漏洞条件触发 | 修复版本、组件未加载、配置关闭 | | Secret | regex | 可获得性、最小有效性、权限、轮换 | 占位符、吊销、权限不足 | | DoS | 单次慢 | 资源曲线、恢复时间、限流负控 | 安全输入、限流、低资源阈值 | ### 请求记录框架 ```bash # 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}' ``` ## 最高危害追踪 报告复核时要判断“报告停在哪一层”和“还能不能在授权范围内继续证明”。 ```text 现象 -> 可控 -> 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 偶然性 | | 移除关键字段 | 证明目标字段导致差异 | | 反条件 | 证明查询/执行/分支语义 | | 无权限主体 | 证明权限边界 | | 自己对象/他人对象 | 证明对象归属 | | 不同租户 | 证明隔离边界 | | 标识符获取对照 | 证明 ID 不是报告作者手工样本或管理员视角样本 | | 批量标识符对照 | 证明批量、全量、任意对象声明是否有可获得规模 | | token/cookie 隔离 | 排除多账号会话混用、复制 Cookie、同一主体误判 | | 修复后版本 | 证明修复有效 | | 安全配置 | 证明官方缓解或默认防护 | | 清缓存/重复请求 | 排除缓存和随机 | | 组件未加载/配置关闭 | 排除 SCA 可达性 | ### 负控判读 - 正控成功、负控失败：继续确认差异能否归因到安全边界。 - 正控和负控都成功：可能是正常功能、权限本来允许、对象公开或测试设计错误。 - 正控和负控都失败：可能 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 和 对外提交裁决支撑时，才允许写对外提交资格；否则必须降级、写 需要外部门禁裁决 或补证。**