@autobest-ui/agent 1.0.29 → 1.0.30

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autobest-ui/agent",
-  "version": "1.0.29",
+  "version": "1.0.30",
   "private": false,
   "description": "Autobest Agent skills/plugins/mcp assets + sync cli",
   "files": [

package/skills/common/code-quality/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-quality
-description: 审计前端与 Node.js 服务的上线安全风险，重点检查生产可达的 XSS、CSP、认证会话、敏感 key、明文传输、导航、第三方集成和服务端注入，并在 `.scratch/code-quality-report.md` 输出带证据的只读 Markdown 报告。用户要求前端安全编码审查、生产漏洞扫描或上线前安全 Review 时使用。
+description: 审计前端与 Node.js 服务的上线安全风险，覆盖 API 鉴权授权、业务副作用、敏感数据出站、日志、第三方集成、运行时、浏览器安全和依赖可达性，并在 `.scratch/code-quality-report.md` 输出可执行的只读报告。用户要求前端安全编码审查、生产漏洞扫描或上线前安全 Review 时使用。
 ---
 
 # 前端与 Node.js 安全审计
@@ -21,12 +21,24 @@ description: 审计前端与 Node.js 服务的上线安全风险，重点检查
 ## 指示
 
 - 明确审计目标、生产入口、边界、可用工具和所需运行条件。
+- 在检查依赖公告前，完成全部生产服务、路由、鉴权、权限、业务副作用和外部数据流的清单；每个生产入口都必须被矩阵覆盖。
 - 只把上线后可达或会进入发布产物的风险纳入安全结论；local/dev/test-only 问题记录为排除项，不计入风险统计。
 - 按 [implementation-playbook.md](references/implementation-playbook.md) 的固定顺序检查，不用单次 grep 或单次 `npm audit` 代替审计。
 - 应用 OWASP Top 10、OWASP API Security Top 10、OWASP ASVS、CWE、OSV/npm audit 和 Node.js 安全实践；每个结论绑定源码、配置、依赖树或工具证据。
 - 输出唯一项目产物 `.scratch/code-quality-report.md`，格式遵循 [report-format.md](references/report-format.md)。
 - 工具、漏洞数据库、生产入口或关键源码不可用时，报告 `Incomplete`/`Blocked` 和具体原因，不将缺失证据当作通过。
 
+## 质量门槛
+
+以下条件全部满足后才能生成最终报告：
+
+- **攻击面闭合**：每个生产服务和路由均记录网络入口、认证方式、授权粒度、输入、业务副作用、外部调用和速率/大小限制。
+- **信任边界闭合**：客户数据、凭据、token、会话、模型 prompt/response 和管理配置进入日志、遥测、缓存、第三方 API、文件或浏览器存储的路径均有结论。
+- **业务完整性闭合**：高权限操作检查对象级授权、租户/站点/账号边界、筛选条件、批量作用域、失败模式和重放，而不只检查 SQL/XSS 等通用 sink。
+- **运行时闭合**：检查生产镜像、基础运行时支持周期、运行用户、镜像固定、最终镜像内容、错误响应和安全日志归因。
+- **依赖可达性闭合**：每条进入 P0-P2 的依赖问题必须证明受影响版本、危险 API、仓库调用点、攻击者可控输入和生产运行路径；仅有 advisory 不构成项目漏洞。
+- **反向复核完成**：写报告前从“还能如何未授权调用、跨对象操作、泄露数据、滥用第三方额度、污染日志、拖垮服务、接管构建”七个方向重新审查一次，并把新证据纳入报告。
+
 ## 角色
 
 你是一名前端与 Node.js 安全审计专家，擅长客户端安全、DOM/XSS 防护、浏览器安全策略、认证会话、敏感数据流、供应链和生产配置风险。你的职责是评估和解释风险，不直接编辑业务代码。
@@ -75,12 +87,16 @@ description: 审计前端与 Node.js 服务的上线安全风险，重点检查
 - 检查 `apiKey`、`api_key`、`OPENAI_API_KEY`、`secretKey`、`clientSecret`、`privateKey` 等字段，以及 OpenAI/AWS/GitHub/Google/Azure/Stripe 等已知凭据格式。
 - 检查 JWT、Bearer/Basic 凭据、PEM 私钥和高熵字符串；普通 `key`、React `key` 和业务索引不能自动判定为漏洞。
 - 检查 CDN/SRI、iframe sandbox、`postMessage` origin、分析/聊天/支付集成和 API key 是否暴露到客户端。
-- 若存在 Node.js 服务，检查鉴权、schema、SSRF、注入、命令执行、原型污染、文件操作、反序列化、WebSocket、DoS、日志和安全 middleware。
+- 对 OpenAI/Azure/Anthropic、分析、聊天、支付等第三方建立数据出站路径，检查 PII/凭据最小化、脱敏、header 白名单、保留和供应商边界。
+- 若存在 Node.js 服务，检查逐路由鉴权/授权、对象和租户作用域、schema、SSRF、注入、命令执行、原型污染、文件操作、反序列化、WebSocket、DoS、日志和安全 middleware。
+- 检查容器基础镜像 EOL/CVE、非 root 用户、固定 digest、构建工具是否进入最终镜像，以及私有基础包的安全关键行为。
 
 ## 行为特征
 
 - 先判断生产可达性，再判断漏洞；local/dev/test-only 问题默认排除。
 - 先确认 source-to-sink 数据流，再给严重级别；关键词命中只能产生 `Needs Manual Verification`。
+- `Confirmed` 表示项目中已证明完整攻击链和生产可达性；只确认代码缺口但缺少网络暴露、角色语义或外部状态时归入“待验证阻断项”，不计入 P0-P4 漏洞数量。
+- 依赖版本命中、缺少安全头、宽松 CORS、localStorage 或旧运行时不能自动升级为高优先级；结合调用路径、攻击前置条件和实际后果判定。
 - 对真实 key 只输出前缀、后缀、长度或 SHA-256 截断指纹，绝不输出完整秘密。
 - 对登录/注册/改密/重置密码分别确认最终 URL、协议、重定向、transport、日志和存储。
 - 使用服务器提供的 frame policy；不把客户端帧检测当成授权边界。
@@ -90,26 +106,27 @@ description: 审计前端与 Node.js 服务的上线安全风险，重点检查
 ## 审计方法
 
 1. 确认仓库根目录、分支、提交、工作树、技术栈、生产入口、包管理器和锁文件。
-2. 识别生产构建、发布配置、Docker/nginx/启动脚本和会进入线上 bundle 的环境变量来源；不读取 `.env`、私钥或 secret store 的值。
-3. 按实现手册检查依赖供应链、认证/敏感数据路径、XSS/浏览器安全、Node.js 服务、生产配置和安全测试保护。
-4. 复核工具结果的源码上下文，聚合同一根因，排除固定常量、占位符、测试假值和不可达代码。
-5. 为每个 finding 记录来源、汇点、数据流、生产环境、攻击前置条件、影响、标准映射、状态和置信度。
-6. 生成 `.scratch/code-quality-report.md`，重新读取并验证章节、行号、脱敏、工具状态和 Git 工作树。
+2. 建立生产服务/路由/鉴权矩阵和敏感数据/第三方出站矩阵，直到每个入口都有结论。
+3. 识别生产构建、发布配置、Docker/nginx/启动脚本和会进入线上 bundle 的环境变量来源；不读取 `.env`、私钥或 secret store 的值。
+4. 按实现手册检查授权与业务完整性、敏感数据、客户端/服务端危险汇点、日志/错误、运行时和供应链；依赖公告放在代码路径之后。
+5. 复核工具结果的源码上下文，聚合同一根因，排除固定常量、占位符、测试假值和不可达代码。
+6. 为每个问题记录来源、汇点、完整攻击路径、生产环境证据、攻击前置条件、实际影响、标准映射、状态和置信度。
+7. 执行反向漏检复核；生成 `.scratch/code-quality-report.md` 后重新读取并验证矩阵覆盖、分类、编号、链接、脱敏、工具状态和 Git 工作树。
 
 ## 优先级
 
 报告使用 P0-P4，不使用 Critical/High/Medium/Low/Info 作为最终排序：
 
 - **P0**：生产 RCE、认证绕过/管理员接管、生产高权限 key/token 暴露、供应链/生产构建接管。
-- **P1**：确认的 DOM XSS/服务端注入、认证授权绕过、生产 key/token/支付数据泄露、注册/登录/改密/重置密码的明文 transport、SSRF、路径穿越、任意文件读取、高危依赖。
+- **P1**：确认的 DOM XSS/服务端注入、认证授权绕过、生产 key/token/支付数据泄露、注册/登录/改密/重置密码的明文 transport、SSRF、路径穿越、任意文件读取，或具备完整生产利用链的高危依赖。
 - **P2**：需要额外条件的注入、可影响生产发布的配置、低权限泄露、DoS、弱安全头、宽松 CORS、中危依赖。
 - **P3**：安全测试缺失、可进入发布产物的工程风险、日志脱敏不完整和依赖维护风险。
 - **P4**：不会进入生产的改进建议、维护性建议、浏览器兼容性和低风险加固。
 
-每条问题必须使用 `CQ-P<优先级>-<序号>` 编号，并按 P0 到 P4 排序。local/dev/test-only 且确认不会进入生产的问题不进入 P0-P4。
+只有具备生产可达攻击链的漏洞进入 P0-P2。P3/P4 只收录已确认进入生产的加固或维护风险，并与 P0-P2 漏洞数量分开汇总。缺少部署暴露、角色语义或外部状态证据的问题使用 `CQ-V-<序号>` 放入“待验证阻断项”；无可达调用链的依赖公告进入附录；误报进入排除项。local/dev/test-only 且确认不会进入生产的问题不进入 P0-P4。
 
 ## 输出和局限性
 
-报告必须区分 `Confirmed`、`Suspected`、`Needs Manual Verification` 和 `False Positive`，并遵循固定报告格式。它是只读安全审计，不是渗透测试、合规认证或“绝对安全”证明；没有运行时/生产环境证据时，必须明确局限。
+报告必须区分 `Confirmed`、`Suspected`、`Needs Manual Verification` 和 `False Positive`，并遵循固定报告格式。摘要先回答“是否阻断上线、先修什么、什么证据还缺”，而不是用漏洞数量代替决策。它是只读安全审计，不是渗透测试、合规认证或“绝对安全”证明；没有运行时/生产环境证据时，必须明确局限。
 
 如需详细检查顺序、字段示例和验证命令，请阅读 [implementation-playbook.md](references/implementation-playbook.md)。

package/skills/common/code-quality/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Code Quality"
-  short_description: "审计前端与 Node.js 服务安全和工程质量"
-  default_prompt: "使用 $code-quality 按固定流程审计当前前端与 Node.js 服务的生产可达安全风险，并生成 .scratch/code-quality-report.md。"
+  short_description: "审计生产 API、数据边界、运行时与依赖可达风险"
+  default_prompt: "使用 $code-quality 先建立生产攻击面和敏感数据边界，再审计可利用安全风险、条件风险与依赖可达性，并生成 .scratch/code-quality-report.md。"
 
 policy:
   allow_implicit_invocation: true

package/skills/common/code-quality/references/implementation-playbook.md

@@ -1,81 +1,175 @@
 # Code Quality Implementation Playbook
 
-本手册是 `code-quality` 的执行细节。入口 Skill 负责路由和边界，本文件负责固定检查顺序、证据门槛和可复用示例。
+本手册规定 `code-quality` 的固定执行顺序、完成条件和证据门槛。目标是先发现真实攻击路径，再整理依赖和加固项，避免由关键词或 CVE 数量驱动结论。
 
 ## 固定流程
 
-### 1. 生产范围确认
+### 1. 锁定生产范围
 
 - 执行 `git rev-parse --show-toplevel`，记录分支、提交和 `git status --short`。
-- 从 manifest、源码、构建脚本和部署文件确认 SPA/SSR、Node API/BFF、生产入口和包管理器。
-- 只读取生产构建、发布配置和会进入线上 bundle 的路径；local/dev/test-only 文件标记排除原因。
-- `.env`、私钥和 secret store 只记录路径和脱敏变量名，不读取值。
+- 从 manifest、源码、构建脚本、Docker/nginx、部署清单和启动命令识别 SPA/SSR、Node API/BFF、worker、定时任务和 WebSocket 服务。
+- 记录每个服务的默认端口、容器入口、Ingress/网关证据、调用方和网络信任假设。只有 `EXPOSE` 时写“端口存在，外部暴露待验证”，不能把 `EXPOSE` 当作公网证据。
+- 识别生产 bundle、运行时环境变量和配置覆盖顺序；`.env`、私钥和 secret store 只记录路径与脱敏变量名，不读取值。
 
-### 2. 依赖和供应链
+完成条件：所有会进入生产镜像或发布产物的服务均进入审计清单；未知部署边界进入待验证项。
 
-按实际工具执行 `npm audit --json`/OSV、`npm ls`、lockfile 一致性、安装脚本和生产 bundle 归属检查。依赖 finding 记录包名、安装版本、direct/transitive、CVE/OSV/GHSA、影响范围、修复路径和运行时/构建时/开发时影响。工具不可用写 `Incomplete`/`Blocked`。
+### 2. 建立逐路由攻击面矩阵
 
-### 3. 认证、注册和敏感数据流
+对每个生产 HTTP/WebSocket/RPC/任务入口记录：
 
-对注册、登录、登出、刷新 token、改密、重置密码、MFA 和高权限操作逐条追踪：
+| 字段 | 必填内容 |
+| --- | --- |
+| 服务/路由 | 完整 prefix、method、path 或事件名 |
+| 网络入口 | 端口、Ingress/网关/内部调用证据 |
+| 认证 | middleware、token/cookie/signature、fail-open/fail-closed |
+| 授权 | 角色、permission、tenant/site/object ownership |
+| 输入 | body/query/path/header/file/message 及 schema/大小 |
+| 副作用 | 读数据、改状态、发消息、转接会话、调用付费 API、写日志/文件 |
+| 外部调用 | 目标服务、凭据来源、重试、超时、header 传播 |
+| 滥用限制 | rate、并发、配额、幂等、重放保护 |
+
+检查中间件真实注册顺序，不以装饰器文档、Swagger `required` 或网关注释代替运行时控制。对认证成功后的每个高权限动作继续检查角色和对象级授权；“token 有效”不等于“有权执行所有动作”。
+
+完成条件：每条生产路由都有一行；所有无鉴权、仅认证无授权、Referer/Origin 当身份、配置失败后继续执行和高权限副作用均有明确结论。
+
+### 3. 建立信任边界和敏感数据出站矩阵
+
+追踪凭据、会话、客户消息、PII、订单/支付数据、模型 prompt/response 和管理配置：
 
 ```text
-输入 -> 表单/state -> API client -> base URL -> transport
--> retry/error -> logger/telemetry -> storage/cookie/cache -> redirect
+来源 -> 校验/脱敏 -> 业务处理 -> 第三方/日志/遥测/缓存/文件/浏览器存储
+-> retention/删除 -> 错误和重试路径
 ```
 
-判定规则：
+对 OpenAI/Azure/Anthropic、聊天、分析、支付、CDN 和 webhook 等第三方记录：
+
+- 发送的数据字段和敏感等级。
+- 目标协议、主机、区域、供应商和凭据来源。
+- PII/secret 脱敏与数据最小化。
+- 请求 header 白名单；禁止把 Cookie、内部身份、转发链和 hop-by-hop header 整包外发。
+- 供应商保留/训练边界、日志和错误响应是否再次泄露数据。
+
+完成条件：每种敏感数据的所有生产去向都有结论；不能只扫描 key 而忽略业务数据。
+
+### 4. 审查授权和业务完整性
+
+对状态变更、批量处理、对象选择和跨服务调用检查：
+
+- tenant/site/user/bot/chat/order 等对象是否与主体绑定。
+- `find`/`filter`/循环跳过条件中的 `&&`/`||`、否定和缺省值是否扩大作用域。
+- ID 可枚举时是否存在 BOLA；普通账号是否可执行管理员功能（BFLA）。
+- 内部接口是否仅靠网络位置、Referer、Origin、隐藏路径或调用约定保护。
+- 失败、超时、配置缺失和缓存未命中时是否 fail-closed。
+- 重试、重复提交、并发和 webhook 重放是否重复产生副作用。
+
+完成条件：每个高权限或有业务副作用的入口都有主体、权限、目标对象和失败模式证据。
+
+### 5. 检查客户端和服务端危险汇点
+
+- 客户端：HTML/JS/CSS 注入、Markdown/富文本、动态 script/iframe、导航、`postMessage`、客户端存储、CSP/SRI/Trusted Types、frame policy 和安全响应头。
+- 服务端：SSRF、命令/模板/SQL/NoSQL 注入、路径穿越、上传/解压、反序列化、原型污染、ReDoS、WebSocket 和文件操作。
+- 输入保护：schema 不只检查类型和必填，还检查枚举、长度、数量、范围、总大小和嵌套深度。
+- 资源保护：body/response 上限、上游超时/取消、并发、rate、配额和预算。
+
+关键词命中只是入口。必须继续追踪攻击者是否控制输入、危险 API 是否实际执行、结果是否可观察。
+
+### 6. 审查日志、错误和安全归因
+
+- 检查 request/response/body/header/error 是否整体序列化到日志或遥测。
+- 检查 token、Cookie、Authorization、PII、客户消息、模型 prompt/response、内部 URL 和第三方响应的脱敏。
+- 检查外部错误响应是否暴露 stack、供应商详情、部署 ID、内部路径或敏感上下文。
+- 检查保留期、文件权限、日志轮转、日志注入和攻击者制造日志量的能力。
+- 验证 `X-Forwarded-For`/`X-Real-IP` 只在受信代理链下使用；否则不能作为审计归因依据。
+
+完成条件：所有 logger/telemetry helper 及调用点均检查；“日志未提交 Git”不能替代运行时日志内容审计。
+
+### 7. 扫描 key 和秘密
+
+检查 `apiKey`、`api_key`、`OPENAI_API_KEY`、`secretKey`、`clientSecret`、`privateKey`、供应商前缀、JWT、Bearer/Basic、PEM 和高熵值。对每个命中确认是真实值、占位符、测试假值、变量引用还是普通业务字段。
+
+- 报告只保留前缀/后缀、长度或 SHA-256 截断指纹。
+- 追踪凭据是否进入生产调用、bundle、镜像、日志、URL、客户端存储和 Git 历史。
+- 当前工作树扫描不等于完整历史扫描；未运行历史 secret 工具时明确写入未覆盖范围。
+
+### 8. 审查运行时、容器和发布链
+
+- 检查 Node/browser/server 运行时是否 EOL，基础镜像是否固定版本和 digest，是否有可用镜像扫描结果。
+- 检查最终镜像的用户、文件权限、只读文件系统预期、capabilities、调试端口和 Swagger/管理端点。
+- 区分 build stage 与 runtime stage；确认构建工具、source map、源码和 secret 没有意外进入最终镜像。
+- 检查私有基础包和内部 SDK 的认证、重定向、TLS、日志、token 与 URL 处理。源码不可读时列为 `Incomplete`，不能由公共漏洞数据库推断通过。
+- 检查浮动 tag、未校验下载、安装脚本和 lockfile 一致性。
+
+### 9. 最后处理依赖公告
+
+执行仓库适用的 `npm audit --json`/`yarn audit --json`/OSV、依赖树和 lockfile 检查。逐条记录：
+
+- 包名、实际安装版本、direct/transitive、runtime/build/dev 归属。
+- CVE/OSV/GHSA 标题、漏洞类型、受影响/修复版本和公开链接。
+- 危险 API/函数、仓库调用点、攻击者输入、生产 bundle/镜像归属。
+- 触发条件是否成立；只导出不读取、未调用代码、固定 URL 等反证。
 
-- HTTPS 请求体中的密码不是仅凭字段名确认的明文传输漏洞。
-- HTTP、明文 WebSocket、mixed content、降级代理或不安全重定向传递生产凭据是 High。
-- 密码/token 进入日志、遥测、错误上报、URL、localStorage 或不安全缓存是敏感泄露。
-- 记录 token 的 Cookie 属性、过期/刷新、重放和跨环境风险。
+分类规则：
 
-### 4. Key 和秘密扫描
+- 完整生产利用链成立：进入 P0-P4。
+- 版本存在但缺少可达调用链：进入“依赖与维护附录”，不计入漏洞数量。
+- 调用链明确不可达：进入“已排除/误报”。
+- 工具失败或私有包无公告数据：标为 `Incomplete`，不视为通过。
 
-检查 `apiKey`、`api_key`、`OPENAI_API_KEY`、`secretKey`、`clientSecret`、`privateKey`、供应商前缀、JWT、Bearer/Basic、PEM 和高熵值。对每个命中确认是否为真实值、占位符、测试假值、变量引用或仅字段名。
+### 10. 反向漏检复核
 
-普通 `key`、React `key` 和业务索引不自动报漏洞。真实 key 只在报告中记录脱敏指纹；若进入生产 bundle、Git 历史、日志、URL、客户端存储或公开接口，建议撤销、轮换、收缩权限、清理历史并复测。
+写报告前重新从攻击者目标出发回答：
 
-### 5. 客户端和服务端安全
+1. 能否无凭据或低权限调用高价值接口？
+2. 能否跨 tenant/site/user/bot/chat 操作其他对象？
+3. 能否让服务端密钥替攻击者调用付费或高权限第三方？
+4. 哪些客户数据、PII、prompt、Cookie 或内部 header 离开信任边界？
+5. 能否通过错误、日志、遥测或 source map 获取敏感信息？
+6. 能否用大输入、慢上游、重试、并发或 ReDoS 拖垮服务？
+7. 能否利用失败时继续执行、默认配置或缓存降级绕过控制？
+8. 容器、运行时、私有 SDK 或构建链能否成为接管路径？
+9. 报告中的每个 P0-P2 是否真有完整攻击路径？
+10. 是否把条件风险、加固建议或 CVE 命中错误计入漏洞数量？
 
-检查 XSS sink、动态脚本、URL 导航、`postMessage`、CSP/SRI/Trusted Types、frame policy、CORS/CSRF、安全 Cookie、第三方集成；Node.js 服务检查鉴权、schema、SSRF、路径穿越、命令/模板/SQL/NoSQL 注入、文件上传、反序列化、DoS 和日志。
+任一问题无法回答时，在报告的“待验证阻断项”或“未覆盖范围”明确记录。发现新路径时回到相应步骤补证据，不能只在末尾追加一句泛化说明。
 
-### 6. 证据和报告
+### 11. 报告质量校验
 
-P0/P1 必须具备文件与行号、来源、汇点、调用链、生产环境、前置条件、影响和验证方式。静态关键词没有数据流证据只能是 `Needs Manual Verification`。报告固定写入 `.scratch/code-quality-report.md`，写后复读并检查 Git 状态。
+- 摘要直接给出上线决策、前三项行动和缺失证据。
+- P0-P2 只统计具备生产可达攻击链的漏洞；P3/P4 作为生产加固项单独汇总。
+- 每条 P0/P1 都有来源、汇点、完整攻击路径、生产可达证据、前置条件、影响和复测。
+- `Needs Manual Verification` 使用 `CQ-V-*`，不混入 P0-P4 计数。
+- 每个 CVE/GHSA 都解释漏洞类型和触发条件，并提供公开链接；编号本身不能代替说明。
+- 报告包含攻击面矩阵、敏感数据出站结论、依赖附录和排除项。
+- 重读报告，删除重复根因、夸大措辞和无法支持的影响；验证 secret 脱敏、链接、行号及 Git 状态。
 
 ## 推荐验证命令
 
-只在命令已存在且确认不会改写项目时执行：
+只执行已存在且不会改写项目或触发线上副作用的命令：
 
 ```text
-npm audit --json
-npm ls
+npm audit --json / yarn audit --json
+npm ls / yarn list
 npm run lint
 npm run typecheck
 npm test -- --runInBand
 npm run build
 ```
 
-命令不存在、网络不可用或失败时记录状态和原因；不要用失败结果推断安全通过。
+主动调用模型、支付、聊天、通知、状态修改、生产接口、压力测试或恶意样本前必须获得相应授权。未执行时给出精确复测步骤。
 
-## finding 示例
+## Finding 最小证据示例
 
 ```md
-### CQ-P1-001 登录凭据通过 HTTP 传输
+### CQ-P1-001 未认证接口使用服务端模型密钥
 
-- 优先级：P1
 - 状态：Confirmed
-- 标准映射：ASVS V9 / CWE-319
-- 来源：`src/auth/login.ts:18`
-- 危险汇点：`src/api/client.ts:42`
-- 数据流：`password field -> login request -> http://api.example.com/login`
-- 受影响环境：production
-- 攻击前置条件：攻击者可观察客户端到 API 的网络路径
-- 证据：生产 base URL 使用 `http://`，且登录请求未升级到 HTTPS
-- 修复建议：强制 HTTPS、阻止降级和 mixed content，并验证登录/注册/改密路径
-- 验证方式：在生产构建和网络检查中确认所有认证端点使用 HTTPS
+- 来源：`POST /ai/generate` 的匿名请求
+- 危险汇点：`src/providers/openai.ts:42` 注入服务端 key 并调用计费 API
+- 攻击路径：`anonymous request -> route -> provider client -> billed upstream request`
+- 生产可达证据：生产 Ingress 映射 `/ai`，路由前无认证 middleware
+- 攻击前置条件：能访问公开域名
+- 影响：任意调用和额度消耗
+- 验证方式：无凭据请求必须返回 401/403，供应商侧无请求记录
 ```
 
 报告不得输出完整 key、token、密码、私钥或用户数据。

package/skills/common/code-quality/references/report-format.md

@@ -1,120 +1,197 @@
 # Code Quality 报告格式
 
-报告唯一输出路径：`.scratch/code-quality-report.md`。报告面向开发人员修复问题，使用简体中文，按优先级从高到低排列。不要输出完整 key、token、密码、私钥或用户数据。
+报告唯一输出路径为 `.scratch/code-quality-report.md`。使用简体中文，面向开发、测试和发布负责人回答三个问题：是否阻断上线、先修什么、还缺什么证据。不得输出完整 key、token、密码、私钥或用户数据。
 
 ## 固定排版
 
 ```md
 # Code Quality Security Report
 
-## 扫描结论
+## 上线结论
+## 攻击面矩阵
+## 敏感数据与第三方边界
 ## P0 - 紧急修复
 ## P1 - 高优先级修复
 ## P2 - 中优先级修复
 ## P3 - 一般修复
 ## P4 - 建议优化
-## 修复排版建议
+## 待验证阻断项
+## 依赖与维护附录
+## 已排除或误报
+## 修复与复测顺序
 ## 未覆盖范围
 ```
 
-没有问题时仍保留 P0-P4 标题，并写“未发现”。工具不可用、生产入口不可读或检查范围不完整时，在“扫描结论”和“未覆盖范围”中写明 `Incomplete` 或 `Blocked`。
+没有内容的 P0-P4 仍保留并写“未发现”。工具不可用、入口不可读或矩阵未闭合时，状态写 `Incomplete`/`Blocked`，并说明缺失证据如何取得。
 
-## 优先级
+## 分类边界
+
+### P0-P2 漏洞
+
+只有满足以下条件的问题才能进入 P0-P2 并计入漏洞数量：
+
+1. 存在生产代码或发布产物中的来源和危险汇点。
+2. 攻击者可控输入能够到达汇点。
+3. 有生产可达证据，而不是仅凭端口、注释或默认配置推测。
+4. 能说明具体安全后果和攻击前置条件。
+
+`Confirmed` 表示完整链条已由代码/配置/运行证据证明。`Suspected` 只用于链条主体已成立、但某个非关键行为仍需复测的情况。
+
+### P3-P4 生产加固
+
+P3/P4 可收录没有独立利用链、但已经确认进入生产的会话、日志、响应头、运行时、容器和维护风险。它们使用 `CQ-P3-*`/`CQ-P4-*` 编号，但在摘要中归入“生产加固”，不与 P0-P2 漏洞合计。纯开发环境建议仍进入排除项。
+
+### 待验证阻断项
 
-- **P0**：生产环境正在暴露或可直接造成重大后果的问题，例如 RCE、认证绕过/管理员接管、生产高权限 key/token 暴露、生产构建或供应链接管。
-- **P1**：确认的生产漏洞或敏感数据泄露，例如 DOM XSS、服务端注入、SSRF、路径穿越、任意文件读取、生产 key/token 泄露、注册/登录/改密/重置密码通过 HTTP 或其他明文 transport 传输、高危依赖。
-- **P2**：需要额外条件才能利用，但会影响生产安全的问题，例如弱 CSP、宽松 CORS、CSRF 前置条件、低权限敏感信息泄露、DoS/ReDoS、中危依赖。
-- **P3**：不会立即造成漏洞，但会增加上线风险或修复成本，例如安全测试缺失、可进入发布产物的配置隐患、日志脱敏不完整、依赖维护风险。
-- **P4**：改进建议和低风险问题，例如代码可维护性、浏览器兼容性、非阻断安全加固。
+代码缺口已确认，但缺少网络暴露、角色语义、secret 当前有效性、网关补偿控制或外部状态时：
 
-local/dev/test-only 且确认不会进入生产构建、发布配置或默认上线路径的问题，不进入 P0-P4；只在“未覆盖范围”中记录排除原因。
+- 使用 `CQ-V-001` 连续编号。
+- 状态为 `Needs Manual Verification`。
+- 不计入 P0-P4 数量。
+- 必须给出负责人可直接执行的验证步骤和“成立时升级到哪个优先级”。
 
-## 扫描结论
+### 依赖与维护附录
 
-只写必要信息：
+只有 advisory/版本命中、没有仓库可达调用链的项目放在附录，不编号为 P finding。每项仍需写漏洞名称、触发条件、当前为何不可达、修复版本和公开链接。
+
+### 已排除或误报
+
+明确记录经过源码复核后不可达的告警，例如只导出不读取、固定 URL、测试代码、未进入生产 bundle。说明反证，避免下次重复调查。
+
+## 上线结论
+
+摘要使用决策语言，不用漏洞总数制造紧迫感：
 
 ```md
+## 上线结论
+
 - 状态：Findings / Passed / Incomplete / Blocked
-- 扫描范围：生产源码、发布配置、依赖和生产 bundle 相关路径
-- 扫描时间：YYYY-MM-DD HH:mm
-- P0：0
-- P1：2
-- P2：1
-- P3：0
-- P4：3
+- 建议：阻断上线 / 有条件上线 / 不阻断上线
+- 扫描基线：分支、commit、时间
+- 生产范围：服务、前端、worker、容器
+- Confirmed 漏洞：P0 n / P1 n / P2 n
+- 生产加固：P3 n / P4 n
+- 待验证阻断项：n
+- 首要行动：最多三项，按实际风险排序
+- 关键缺失证据：网络暴露、角色矩阵、运行配置等
 ```
 
-## 单条错误格式
+`Needs Manual Verification`、依赖附录和 P3/P4 加固项不能混入 Confirmed 漏洞数量。
+
+## 攻击面矩阵
+
+Node/API 项目必须逐路由覆盖；路由较多时可按相同 middleware 和副作用分组，但不能隐藏例外。
 
-每条错误必须有连续编号，并放在对应优先级章节内。编号格式为 `CQ-<优先级>-<序号>`，例如 `CQ-P1-001`。同一根因的多个位置合并到一条；攻击面不同才拆分。
+| 服务/路由 | 网络入口 | 认证 | 授权/对象范围 | 业务副作用 | 外部调用 | 限制 | 结论 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+前端项目改为页面/入口矩阵，记录路由权限、敏感数据、第三方脚本和导航。
+
+## 敏感数据与第三方边界
+
+| 数据 | 来源 | 目标 | 脱敏/最小化 | transport | 日志/保留 | 结论 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+至少覆盖凭据、会话、客户数据、PII、支付/订单、模型 prompt/response 和管理配置。没有某类数据时写“未发现”，不要省略整个矩阵。
+
+## 单条 Finding 格式
 
 ```md
-### CQ-P1-001 登录凭据通过 HTTP 传输
+### CQ-P1-001 未认证接口使用服务端模型密钥
 
 - 优先级：P1
-- 状态：Confirmed / Suspected / Needs Manual Verification / False Positive
-- 文件夹：`src/auth/`
-- 文件：`src/auth/login.ts`
+- 状态：Confirmed / Suspected
+- 置信度：High / Medium / Low
+- 文件：`src/api.ts`
 - 行号：42
-- 错误代码：`CWE-319`
-- 规则/标准：ASVS V9 / OWASP A02
-- 错误位置：`fetch(loginUrl, { method: 'POST', body })`
-- 错误说明：生产登录请求使用 `http://`，密码可能以明文方式经过网络传输。
-- 影响：网络观察者可能获取用户凭据。
-- 证据：`src/config/api.ts:12` 将生产 base URL 配置为 `http://...`。
-- 修改建议：强制使用 HTTPS，阻止协议降级，并检查注册、登录、改密和重置密码的最终请求地址。
-- 代码示例：
-
-  ```ts
-  const api = new URL('/login', 'https://api.example.com');
-  await fetch(api, { method: 'POST', body: JSON.stringify(payload) });
-  ```
-
-- 验证方式：检查生产构建配置和浏览器 Network，确认认证请求均使用 HTTPS。
+- 漏洞编号：CWE-306
+- 规则/标准：OWASP API2 / ASVS V4
+- 来源：匿名 `POST /ai/generate`
+- 危险汇点：服务端 key 注入后的计费 API 请求
+- 攻击路径：`anonymous request -> route -> provider -> billed request`
+- 生产可达证据：生产 Ingress 路由和 middleware 顺序
+- 攻击前置条件：能访问公开域名
+- 错误说明：具体说明控制缺口，避免只写“存在安全风险”。
+- 影响：说明攻击者能获得或改变什么。
+- 修复建议：说明控制位置、边界和失败模式。
+- 验证方式：给出不会歧义的预期结果。
 ```
 
-### 字段要求
+### 字段规则
 
-- `文件夹`：问题所在目录；无法归属时写最近的模块目录。
-- `文件` 和 `行号`：必须能直接定位；工具只给出包名时，补充 manifest 或 lockfile 位置。
-- `错误代码`：优先填写 CWE、CVE、OSV、规则 ID 或项目 lint 规则；确实没有时写 `N/A`，不要编造编号。
-- `错误位置`：给出具体函数、表达式、配置键或命令，而不是只写文件名。
-- `代码示例`：优先给最小修复前/修复后片段；涉及 key/token/密码时使用脱敏占位符。
-- `修改建议`：说明改什么、为什么改和边界条件，不直接修改仓库。
-- `验证方式`：给出命令、测试或浏览器检查方法。
+- `漏洞编号` 使用 CWE/CVE/OSV/GHSA/规则 ID；字段名不得写“错误代码”。
+- CVE/GHSA 必须同时写人类可读的漏洞类型、触发输入/危险 API、影响版本、仓库调用点和公开链接。编号不能代替漏洞说明。
+- `生产可达证据` 必须说明 Ingress/路由/镜像/bundle/调用方证据；若缺失则移入 `CQ-V-*`。
+- `攻击路径` 必须完整到可观察影响；只有关键词、危险函数或依赖版本时不成立。
+- `影响` 禁止使用“可能造成严重后果”等空泛表述；写明数据泄露、状态变更、额度消耗、跨对象访问、CPU 阻塞等具体结果。
+- `代码示例` 仅在能显著降低修复歧义时添加，不作为固定字段。
+- 同一根因合并；不同信任边界或验证方式才拆分。
 
-静态关键词命中但没有来源到危险汇点的证据，只能使用 `Needs Manual Verification`，不能直接列为 P0/P1。
+## 待验证阻断项格式
 
-## 敏感 key 报告规则
+```md
+### CQ-V-001 内部控制接口缺少鉴权，网络暴露未知
+
+- 状态：Needs Manual Verification
+- 代码事实：路由前没有认证 middleware
+- 缺失证据：生产 Service/Ingress/NetworkPolicy
+- 成立时优先级：P1
+- 成立时影响：未授权状态变更
+- 验证负责人：运维/服务 owner
+- 验证步骤：从非受信工作负载发送无凭据请求，预期 401/403 且无业务副作用
+```
 
-发现 `apiKey`、`OPENAI_API_KEY`、`secretKey`、JWT、Bearer Token、PEM 私钥或其他凭据时：
+## 依赖条目格式
 
-- `错误位置` 写字段和文件行号，不写完整值。
-- `证据` 只写前缀、后缀、长度或 SHA-256 截断指纹。
-- `修改建议` 必须包含撤销、轮换、权限收缩和历史清理建议（适用时）。
-- 普通 `key`、React `key` 和业务索引没有敏感值或数据流时，不作为安全错误。
+```md
+### DEP-001 `package@version`：漏洞名称
+
+- 公告：[CVE-...](https://...) / [GHSA-...](https://...)
+- 依赖归属：runtime / build / dev，direct / transitive
+- 触发条件：攻击者控制的输入到达具体危险 API
+- 仓库调用：路径与行号，或“未发现”
+- 当前判定：可达 / 条件可达 / 不可达 / 未知
+- 处置：升级版本、替代包或接受风险的边界
+```
 
-## 修复排版建议
+高危 advisory 若完整利用链可达，应移入 P0-P4；附录不重复列同一问题。
 
-最后单独列出哪些问题可以一起修复，哪些必须分开处理：
+## 优先级
 
-```md
-## 修复排版建议
+- **P0**：已证实生产 RCE、认证绕过/管理员接管、有效高权限密钥泄露、生产构建接管。
+- **P1**：已证实的未授权高价值操作、DOM XSS/服务端注入、SSRF、路径穿越、任意文件读取、敏感数据/凭据泄露、付费第三方滥用或高危依赖完整利用链。
+- **P2**：需要额外但现实条件的注入、跨对象影响、DoS、日志/第三方数据泄露、发布配置风险或中危依赖完整利用链。
+- **P3**：不会立即形成利用链，但增加生产攻击面或修复成本的日志、运行时、响应头、会话和维护风险。
+- **P4**：低风险加固、兼容性和维护建议。
 
-### 可以放在一起
+local/dev/test-only 且确认不会进入生产的内容只进入排除项。缺少生产可达证据的高后果代码缺口进入 `CQ-V-*`，不因“如果公网可达会很严重”而计为 P1。
 
-- `CQ-P1-001`、`CQ-P1-002`：同一个 API client 的 HTTP 降级问题，可统一修改 transport 和生产 base URL。
-- `CQ-P2-001`、`CQ-P2-002`：同一套 CSP 配置缺少 `frame-ancestors` 和 `object-src`，可统一调整响应头并一起验证。
+## 敏感凭据规则
 
-### 不要放在一起
+- 只记录变量名、类型、长度、前后缀或 SHA-256 截断指纹。
+- 当前值是否有效未知时使用 `CQ-V-*`；确认有效且生产可用后才按 P0/P1 计数。
+- 建议必须覆盖撤销、轮换、权限收缩、历史/镜像/日志清理和复测。
 
-- `CQ-P1-003` 密钥泄露与 `CQ-P1-004` DOM XSS：根因、验证方式和回滚策略不同，应分开修复。
-- 依赖升级与认证流程修改：分别验证依赖回归和业务登录流程，不能合并成一个无边界改动。
+## 修复与复测顺序
 
-### 推荐顺序
+按攻击路径和发布边界组织，不按文件数量组织：
 
-1. 先处理全部 P0。
-2. 再处理 P1，按生产暴露面和数据敏感度排序。
-3. 合并同一根因的 P2/P3 修复，完成后补充安全测试。
-4. 最后处理 P4 建议。
-```
+1. 先列立即隔离或轮换动作。
+2. 再列 P0/P1 的独立修复与回滚边界。
+3. 列需要运维、身份平台或供应商共同验证的 `CQ-V-*`。
+4. 合并同一控制面的 P2/P3，例如统一网关限流或日志脱敏。
+5. 依赖升级与认证/业务流程修改分开回归。
+
+## 报告自检
+
+提交前逐项确认：
+
+- 摘要中的数量与章节一致，并将 P0-P2 漏洞与 P3/P4 加固分开统计。
+- 每个生产路由都出现在攻击面矩阵中。
+- 每类敏感数据都出现在出站矩阵中。
+- P0-P2 均有来源、汇点、攻击路径和生产可达证据。
+- 所有待验证项均有负责人、步骤和成立时优先级。
+- 依赖公告均有标题、触发条件、调用点判断和链接。
+- 报告明确列出误报和反证。
+- 没有完整 secret、用户数据或未脱敏日志样本。
+- 工具失败、私有依赖、生产配置、镜像和动态测试缺口均在未覆盖范围中。