forge-security-review

Forge 安全审查

运行针对 Forge 的白盒安全审查，并报告经过验证的发现，包括可利用性、影响、证据和修复建议。

默认采用节省 Token 的方式

默认使用由清单驱动的路由，以减少 Token 用量。不要一开始就加载所有规则文件。

规则资源

此技能的审查规则打包在 assets/security-rules/ 下：

• 全局基线：assets/security-rules/_global-forge.mdc
• 类别索引：assets/security-rules/forge-*/_index-*.mdc
• 类别深度检查：assets/security-rules/forge-*/*.mdc

执行要求

触发此技能时：

1. 首先在此技能目录中运行静态分析：

• scripts/run_static_analysis.sh <forge-project-root-directory>
• Windows 系统使用 .ps1 脚本

2. 开始任何深度代码审查前，先读取 manifest.yml。
3. 首先加载 assets/security-rules/_global-forge.mdc。
4. 根据清单和代码信号，仅加载相关类别的索引规则。
5. 只有在真实代码模式触发匹配的检测启发式时，才加载深层子规则。
6. 围绕以下方面进行基于证据的安全审查：
   • 身份验证／授权
   • 注入和输入验证
   • 租户隔离和跨租户数据泄漏
   • 密钥和存储
   • 出站流量／远程服务／CSP 和清单权限
   • 公共入口点（Web 触发器）
   • Agent 和其他 Forge 安全风险
7. 除非用户明确要求修复，否则不要修改应用代码。
8. 将所有扫描输出和生成的构件写入 security-audit-artifacts/。

规则路由工作流

阶段 1：侦察（必需）

首先读取 manifest.yml 并提取：

• permissions.scopes
• permissions.external.fetch
• permissions.content.scripts
• modules（resolver/webtrigger/scheduledTrigger/rovo 等）
• remotes
• app.runtime.name

构建执行映射：

• UI 模块 -> bridge 调用 -> resolvers/functions
• 外部入口点（Web 触发器、事件、计划任务）
• api.asUser() 与 api.asApp() 路径
• 出站 fetch 目标

阶段 2：索引规则选择（双层加载）

始终首先加载：

• assets/security-rules/_global-forge.mdc

然后仅加载相关类别的索引规则：

信号	加载
使用了任何有意义的作用域、进行了变更或使用了 asApp()	assets/security-rules/forge-authn-authz/_index-authn-authz.mdc
webtrigger 或 scheduledTrigger 模块	assets/security-rules/forge-webtrigger-entrypoints/_index-webtrigger-entrypoints.mdc
permissions.external.fetch 或 remotes	assets/security-rules/forge-egress-remotes/_index-egress-remotes.mdc
SQL API，或不可信输入到达 resolver 接收点	assets/security-rules/forge-injection/_index-injection.mdc
多租户模式、模块/全局状态、缓存复用	assets/security-rules/forge-tenant-isolation/_index-tenant-isolation.mdc
凭据/令牌/密钥处理	assets/security-rules/forge-secrets-storage/_index-secrets-storage.mdc
不安全的 CSP 或可能存在的作用域/配置错误	assets/security-rules/forge-manifest-config/_index-manifest-config.mdc
Rovo 模块/操作	assets/security-rules/forge-rovo-agents/_index-rovo-agents.mdc
基线日志记录/错误处理/静态分析相关问题	assets/security-rules/forge-auditing/_index-auditing.mdc
依赖项/软件包风险审查	assets/security-rules/forge-misc/_index-misc.mdc

子规则策略：

• 读取索引后，仅加载与代码中观察到的检测启发式相匹配的子规则。
• 不要预加载某一类别中的所有子规则。

阶段 3：分析与验证

对于每个已加载的类别：

1. 列出所有可到达的入口点。
2. 跟踪 source -> validation/authz -> sink。
3. 通过证据确认可利用性。
4. 使用 CVSS v3.1 对已确认的问题进行评分。

聚焦审查模式

如果用户要求进行范围较窄的审查（例如仅审查 authz），则加载：

• 全局基线
• 请求审查类别的索引
• 该类别中仅匹配的子规则

仍需提及范围之外发现的任何明显严重问题。

审查工作流

1. 构建执行路径图：
   • UI Kit/Custom UI 入口点
   • Bridge 调用和 resolver 处理程序
   • api.asUser() / api.asApp() 调用路径
   • 外部出站请求/remotes 和触发器入口点
2. 对于每个发现，跟踪 source -> validation/authz -> sink。
3. 在将问题归类为已确认漏洞之前，验证其可利用性。
4. 将不可利用的加固建议单独放在“需要验证”部分。
5. 为每个问题提供文件级证据和实用的测试线索。

静态分析模式

如果用户要求进行完整扫描，则运行以下文件中的完整工作流：

• assets/security-rules/forge-auditing/static-analysis-forge.mdc

可用时的预期工具：Semgrep、npm audit、Snyk、gitleaks。

输出要求

• 提供 Markdown 格式的安全审计报告。
• 按 CVSS v3.1 严重性和影响对已确认的可利用问题排序。
• 对每个已确认的问题，包含：
  • CVSS 向量和基础分数
  • 严重性级别
  • 可利用性和影响
  • 文件证据和 source-to-sink 跟踪
  • CWE 映射
  • 可复现的 PoC/测试步骤及具体命令
• 列出假设和证据缺口。
• 存在漏洞时，不要只报告扫描器统计数量。

示例触发短语

• “对这个 Forge 应用进行安全审查”
• “对我的 Forge 应用进行白盒安全审计”
• “检查此应用是否存在授权绕过和租户隔离问题”
• “对这个 Forge 代码库进行完整的静态分析”