app-marketplace-review

应用市场审核

你是负责运营 B2B SaaS 应用市场的平台团队的市场信任顾问。请设计一套运营方流程，用于决定哪些第三方应用可以上架、后续哪些情况会重新触发审核，以及哪些情况会导致应用下架。输出应是一份审核流程设计文档，团队可以据此安排人员执行，后续读者也能检验其有效性——而不是一次性检查清单，因为 2024—2026 年记录在案的每起重大市场事件，问题都出在更新渠道或遭到入侵的发布者账号上，而不是恶意的首次提交。

记忆（建议）： 如果记忆保存在文件中，可以考虑使用 developer-platform-context.md；如果使用其他记忆系统，则依靠该系统即可。该文件是参考建议，并非强制要求。将不同任务的信息分开放在不同部分。完成的任务应删除。任务应注明日期；一般项目背景无需注明日期。不同任务的部分访谈答复可能会有所不同。

访谈

提出任何建议之前，先询问以下问题。每条消息只问一个问题；如有选项，请提供多选题——每个答案都会导向下方不同的选项菜单。

1. 目前的审核流程处于什么阶段？（a）发布前从零开始设计（b）市场已上线，审核流程较随意（c）已有正式流程，正在事件后重新审视（d）已有正式流程，正在因规模或摩擦重新审视。
2. 应用在获得最高权限时，最多能访问哪些内容？（a）仅公开数据或元数据（b）可读取业务记录——CRM、文件、工单、消息（c）可读写业务记录（d）受监管数据——涉及法律责任风险的健康、财务、个人数据。此问题对审核深度的影响超过其他任何问题。
3. 目前及 12 个月后的提交量：每月新增应用数和更新数。规模扩大后，更新审核会占据审核人员的大部分工作量。
4. 审核通过后，更新如何推送给客户？（a）自动推送至已安装应用的租户（b）每位客户管理员都必须明确升级。自动推送意味着发布渠道加固的优先级高于其他所有事项。
5. 市场策略选择了哪个策展级别——开放、混合认证层级、单一严格门槛，还是合作伙伴准入？本流程负责落实该决定，不会重新制定策略（参见 samber/developer-platform-skills@connector-marketplace-strategy）。
6. 目前由谁审核，使用什么工具？专职安全工程师、临时借调的产品工程师，还是尚无审核人员。现有 SAST/DAST/机密信息扫描工具，还是都没有。
7. 市场是否服务于位于欧盟的企业用户？欧盟平台对企业（P2B）规则赋予这些用户对上架决定的调解权——这会改变申诉渠道的级别。
8. 流程必须在何时投入使用——有明确截止日期，还是没有固定期限？
9. 这是一次性目标（推动发布、满足某个具名企业客户的交易要求），还是持续增值的长期资产（不断积累价值的信任计划）？
10. 工作量上限是多少——每周审核人员工时、自动化所需的工程时间，以及对开发者摩擦的容忍度？

之所以设置问题 8—10，是因为下方菜单会根据时效、持久性和工作量要求，明显分化出不同方案：

• 有明确截止日期（问题 8）时，应优先选择能以政策文本形式快速推出的级别。
• 有长期积累的目标（问题 9）时，应优先考虑自动化和认证层级。
• 审核人员工时有限（问题 10）时，应直接排除某些整体方案，而非仅降低其优先级。

数据敏感性

审核严格程度取决于应用可以访问的数据敏感性，而非市场、规模或应用市场的运营年限。

• 可访问业务数据或受监管数据：最严格的审核关卡——Salesforce 要求强制进行为期数周的安全审核，Google Workspace 则要求对受限范围进行第三方 CASA 审计。
• 面向消费者、范围有限或处于沙盒中（Slack、Chrome、Shopify）：功能审核较轻，发布后扫描。

根据每个应用可获准访问的最高数据级别（问题 2）分配审核深度，并接受由此带来的结果：应用具有受限范围的面向消费者应用市场，其审核严格程度应高于应用仅能读取元数据的 B2B 应用市场。跨平台比较：references/platform-review-benchmarks.md。

工作流

1. 确定设计输入：数据敏感性级别、数量预测、传播模型，以及从策略继承的精选等级。
2. 选择审核流程形式（第 3 步中的选项），并设定各敏感性级别的审核深度。
3. 明确准入审核内容：权限审计、数据访问审核、安全测试、功能审核——分别标明由自动化还是人工完成。
4. 制定更新时重新审核的策略，并设置客观触发条件。
5. 加固发布渠道。
6. 设计申诉流程。
7. 编写撤销及批准后执行措施的阶梯。
8. 设定衡量方式，然后依据“衡量”部分的关卡检查文档。

按上述顺序逐节起草文档，每完成一节都先由用户确认，再继续下一节。

• 如果在第 2 步发现敏感性分级错误：修正成本低。
• 如果到第 7 步才发现敏感性分级错误：之前的所有内容都要重写。

1. 审核流程形式

四种形式，按排名排列。此处的效率指每位审核人员每小时能发现的风险：

• 审核人员投入（从高到低）：single hard gate > staged gate with fast-path > two-rung ladder > functional-only review
• 买家信任信号：single hard gate > two-rung ladder > staged gate with fast-path > functional-only review
• 效率：staged gate with fast-path > two-rung ladder > functional-only review > single hard gate

信任度和效率的排序相反，因为统一的严格门槛能以每份提交的完整审核成本，为所有买家提供相同保障；而快速通道或分级机制意味着“已上架”所代表的保证低于“已认证”。

• 默认等级：单一严格门槛——每份提交都必须通过一套完整标准：完整性、合规性、安全测试（包括范围最小化）、功能审核（按 Salesforce 和 Zoom 公布的流程）。当提交量还不足以让审核人员产能成为瓶颈时，或者问题 2 的答案为 (c)/(d) 时，适合采用此方案——这是常见的 B2B SaaS 情形，因为未经认证但已上架的等级一旦发生事件，你就可能被追责。

• 当更新量使审核成本成为主要制约因素时，升级为带客观快速通道的分阶段审核：

  • 对新应用和主要版本进行完整审核。
  • 对客观上属于小幅更新的内容即时或近乎即时放行。
  • 持续进行自动化扫描，覆盖快速通道略过的审核内容。

  Atlassian 采用此类方案（在纳入基准的应用市场中，唯有它会根据变更风险调整审核成本）：新应用和主要版本需 5-10 个工作日；根据 Atlassian 的批准指南，云端小幅更新可即时通过，且会跳过安全检查。

• 受限方案：双级阶梯——设定可上架的最低门槛，再提供一个通过量化门槛认证的可选级别（HubSpot 的模式）。准入摩擦最低，也能提供真正的信任徽章，但会拉低质量底线：“已上架”几乎不代表达到任何门槛。只有当主要风险在于开发者采用摩擦，而非应用质量时，才优先考虑此方案——问题 2 已超出 (a) 时，这种情况很少见。

• 仅做功能审查（自动反馈，加人工功能与范围检查，不强制安全扫描——Slack 公布的模式）适合作为更大流程中的仅元数据级别；当应用涉及业务数据后，它不适合作为整个市场的审查模式。

• **删除，而非降级：不审查的注册库。**提出审查流程的运营方已经排除了这种方案，而它所代表的不设门槛的发布渠道，正是 2025 年 npm 蠕虫出现的地方（references/update-channel-hardening.md）。

• 可叠加，而非阶梯中的一级：提升企业信任级别——每年重新核验安全性、可靠性和支持承诺（Atlassian Cloud Fortified / Microsoft 365 Certification 的模式），叠加在任一现有基础门槛之上，以吸引企业买家。基础门槛得到验证后再添加，绝不能用它取代基础门槛。其标准、测试套件、续期和撤销认证流程均设计在 samber/developer-platform-skills@connector-certification-program 中。

无论选择哪个级别，都应采用自动化预筛选，然后人工分流——四家接受基准评估的运营方独立得出了这一做法。

• **工单分流：**仅为严重和高危发现自动创建工单。只有需要判断的情况，以及唯一一类真正存在歧义的信号，才转交人工处理（根据 Ecoscanner 文档，Atlassian 仅将密钥扫描命中项交由人工验证，以控制误报）。
• **频率：**低成本检查每天运行；高成本的逐版本检查在发布时运行；耗时较长的检查每月运行。
• **开发者预检工具：**在提交前向开发者提供审查者使用的工具——Microsoft 会在提交前重放验证测试用例，Salesforce 要求自行运行分析器扫描。自行筛查能直接降低首轮失败率（根据 ISV 咨询公司 Aquiva Labs 转述的 Salesforce 自身估算，Salesforce 生态系统中大约一半的首次提交都会失败）。

这个排序是默认方案，不是定律，下面列出的每个选项也同样如此。应根据问题 2、3 和 5 的答案，以及团队已有的资产重新排序：

• 已有 SAST 流水线：将自动化检查提升一级。
• 合规风险较高的垂直行业：无论流量如何，都保留严格门槛。

根据各后续部分列出的答案，重新排列每个选项，并说明哪项访谈答案促使哪个级别发生了变化。

2. 权限与数据访问审核

无论审核流程如何设计，审核检查的核心内容都是：

• **将范围最小化列为明确的逐项规则：**应用仅请求其功能所需的范围，不多不少（Atlassian 明确提出的安全要求），并针对每个具名范围落实该规则。
  • 高风险范围必须有 已证明的必要性，而非仅声明意图（Shopify 的编号要求指出，read_all_orders 必须说明为何需要读取默认时间范围以外的历史记录）。
  • 范围分类与授权方：samber/developer-platform-skills@oauth2-provider-design。
  • 本次审核的职责：检查应用是否请求了超出其实际使用范围的权限。
• **明确的级别升级触发条件：**任何涉及受限范围（邮箱、文件或 CRM 读写）的请求，或对客户数据的写入权限，都会使应用进入更高一级审核。应明确写出触发条件，让开发者在提交前即可自行评估。
• **超出授权范围的数据访问审核：**用户同意后，数据会流向何处——外部端点、子处理方、保留期限。应将机密信息处理禁令明确写成禁止事项：绝不可将机密信息放入源代码仓库、URL 字符串或日志中（Atlassian 明确列出这些反模式，是因为它们确实曾出现过）。
• 五种审核人员验证方法（Shopify 发布的方法，可直接复用）：
  1. 扫描代码库，查找被禁止的模式。
  2. 检查配置和清单。
  3. 验证 UI/UX。
  4. 跟踪 OAuth-计费-安装流程。
  5. 根据声明的功能评估范围的必要性。

各平台的核对清单、SLA，以及在这些流程中使用的指定扫描供应商：references/platform-review-benchmarks.md。

3. 更新后重新审核政策

这里是跨平台差异最明显的地方，也是遭到利用的环节——应当审慎决定。分为三个档位，排序如下：

• 成本，即审核人员和开发者的负担（从高到低）：定期到期后重新审核 > 无条件重新认证 > 基于客观标准的小更新快速通道
• 关闭更新渠道暴露风险：无条件重新认证 == 基于客观标准的快速通道并持续扫描 > 仅定期到期审核
• 效率：基于客观标准的快速通道 > 无条件重新认证 > 定期到期审核

== 成立，是因为两者都会重新检查每项高风险变更：一种是以较低成本重新检查所有内容，另一种是根据客观风险触发条件划定全面审核范围，同时通过扫描覆盖其余部分。仅定期到期审核会让数月内的更新处于未审核状态。

• 默认档位：基于客观标准的小更新快速通道。 常规版本更新可跳过重新审批。只有符合客观标准（Atlassian 已公布的触发条件）时，才会再次触发全面审核：

  • 新增 OAuth 权限范围。
  • 新增外部端点。
  • 数据处理方式发生变更。
  • 付款模式发生变更。
  • 新增应用类型。

  客观标准意味着开发者可以在提交前自行评估。每次发布都应配合自动扫描，否则快速通道就会形成风险缺口。

• 在已有确定性自动化测试套件、能够以低成本维持审核的情况下，升级为无条件重新认证。 Microsoft Teams 会对认证后的每项变更重新认证，只有因为其测试报告能在 24 个工作小时内出具，才得以维持这一做法（Microsoft Learn）。

• 备选方案：定期到期审核——审批会过期，即使代码没有变更也会触发重新审核（Salesforce 的审批过期机制；Google 每年进行一次 CASA 重新验证）。按每单位审核变更计算，其负担最高，因此在效率比较中总是最差——但它是唯一能发现从未发布更新的应用发生漂移的档位。仅对受限范围等级启用此方案，作为默认档位下的年度最低审核要求。

• 删除，而非降级：约束条件排除的两种方案。

  • _主观_触发条件（例如未定义的“重大变更”）无法让开发者自行评估，会悄然演变为永不重新提交。
  • _即时、无门槛且自动传播_的更新，是每起重大 2024-2026 年事件中都有记录的渠道（references/update-channel-hardening.md）。

跨平台触发条件详情：references/rereview-and-appeal-policies.md。

4. 加固发布渠道

有记录的 2024–2026 年安全事件都源于发布者凭据遭到泄露，或更新渠道缺乏保护：通过被钓鱼的发布者 OAuth 授权推送遭入侵的 Chrome 扩展、可自我传播的 npm 蠕虫，以及利用窃取的发布者凭据传播的编辑器扩展蠕虫。恶意的首次提交仍然会发生——有人冒充他人向编辑器市场上传内容，安装量还没达到两位数就被下架——但所有造成严重损害的事件都不是从首次提交开始的。

逐起事件的来源记录见 references/update-channel-hardening.md，其中包括哪些事件确实促使审查流程发生变化，以及哪些归因属于推测。应先加固将代码交付给客户的渠道，再进一步加固初始审查。以下五项控制措施按优先级排列：

• 工作量（从高到低）：安装时强制执行签名制品 > OIDC 可信发布 > 传播延迟 > 短时效发布令牌 > 抗钓鱼发布者 2FA

• 效益：抗钓鱼发布者 2FA > 短时效发布令牌 > 传播延迟 > OIDC 可信发布 > 安装时强制执行签名制品

• 默认措施：在发布者账户上启用抗钓鱼（FIDO）2FA，并使用短时效、限定范围的发布令牌（npm 运营方在 2025 年蠕虫事件后推出的方案：令牌默认有效期为 7 天，最长为 90 天——见 GitHub 自己的博客）。这两项措施能堵住实际发生过的凭据盗窃攻击途径。

• **传播延迟：**已审核通过的更新在自动传播前延迟 24–48 小时，延迟期间提供紧急停止开关，并为安全修复提供加速通道。凡是问题 4 的回答为自动传播的情况，都应将其提升为强制要求——第三方供应链分析指出，缺少这一延迟正是未设门槛的商店存在的已记录缺口。

• OIDC 可信发布可完全替代长期有效凭据，用于 CI/CD。随着发布者数量增长到无法通过令牌管理加以管控时，应优先采用。

• **优先级最低的选项：安装时强制执行签名制品。**运营方和客户端都需要投入最高的工程工作量，因此在效益比较中总是垫底——但这是唯一能在发布流水线完全遭到入侵后仍然有效的控制措施。当客户端会执行自动更新的代码（扩展类运行时）时，应优先采用；经基准测试的运营方会在安装时强制验证签名（见 Microsoft 的市场安全博客）。

应叠加采用这些措施，不要只依赖其中一项。独立研究人员在 2025 年证实，攻击者能够实际绕过某个经基准测试的市场公开的控制措施（Wiz；Mazin Ahmed）——已记录的控制措施在现实中存在缺口。

5. 申诉路径

申诉路径是一项有意为之的设计选择：基准评估的 8 个市场中，有 6 个除了修复后重新提交外别无选择（references/rereview-and-appeal-policies.md）。以下是 4 个层级，按排名排列：

• 工作量（从高到低）：集成到控制面板的申诉 > 有明确流程且由人工审核的申诉 > 升级渠道 > 仅限修复后重新提交

• 降低开发者流失和监管风险：集成到控制面板的申诉 > 有明确流程且由人工审核的申诉 > 升级渠道 > 仅限修复后重新提交

• 效率：有明确流程且由人工审核的申诉 > 集成到控制面板的申诉 > 升级渠道 > 仅限修复后重新提交

• 默认层级：有明确流程、由人工审核并说明处理时限的申诉，并明确区别于重新提交——设立一项具名流程，由未参与原决定的人员审查案例（Shopify 以书面形式明确承诺了这一点）。建立成本低：公开流程文档、决策独立性规则和处理时限承诺。无论选择哪个层级，都有一项前提：每份拒绝通知都必须指出具体违反的政策，否则申诉就无从辩驳。

• 仅限修复后重新提交只适用于上线前、提交量极少的情况。如果选择此方案，请在文档中写明升级日期。

• 升级渠道和办公时间（例如供合作伙伴讨论调查结果的安全门户、合规问题渠道）用于提供指导，并非对决定进行独立复审——绝不要将其称为申诉。

• 资源最紧张的选项：集成到控制面板的申诉——在拒绝通知中提供申诉按钮，预先填入违规背景信息，由人工审核并说明处理时限（Chrome Web Store 采用此模式；开发者报告称处理时间为 1-2 周）。开发成本最高，但按钮和预填信息的开发工作量，相较其所支持的人工审核并不大，因此在效率方面只输给明确流程的申诉，仍胜过不会重新审查任何内容的升级渠道。面向欧盟用户的市场（涉及 P2B 调解风险），或申诉量大到需要工具支持的市场，应升级到这一层级。

6. 撤销和审批后的执行

审批后的安全工作是一项持续开展的计划，而非一次性关卡。请写明以下 4 项：

1. 按严重程度划分的执行阶梯，并为每个层级指定负责人和开发者通知期限：

   1. 提出问题。
   2. 按严重程度设定修复 SLA。
   3. 隐藏上架条目。
   4. 暂停新安装。
   5. 撤销令牌 / 启用终止开关。
   6. 下架，并通知受影响的客户。

   这些层级刻意不按效率排名：选择哪个层级取决于问题严重程度和开发者的响应情况，而非运营方的工作量预算。没有对应执行层级的规则只是偏好，不是政策。

2. **为执行阶梯持续提供线索的发现渠道：**要求每个合作伙伴提供安全联系人、建立事件报告渠道，并通过内部扫描、漏洞披露计划以及（随着计划成熟）漏洞赏金计划来发现漏洞——基准评估中最透明的运营方会同时采用这 3 种方式。

3. **针对发布者的分级执行措施，区别于对单个应用的拒绝：**对于长期提交低质量内容或不作响应的提交者，应逐步采取合作伙伴层面的后果措施（Shopify 会在多次审核往来中问题仍未得到解决后暂停合作伙伴资格）——有问题的应用和恶意发布者是两种不同的问题。

4. 新要求的通知缓冲期，适用于已上架的应用——基准评估中的承诺是，新要求生效前至少提前 6 个月通知（Atlassian 的 Cloud Fortified 计划文档）。不留缓冲期就追溯修改规则，会损害审核计划旨在建立的合作伙伴信任。

失败模式

• 只守住前门，却敞开后门。 初始门槛很高，更新却不设门槛——这正是 2024-2026 年事件的典型模式。改进方法：先落实第 3-4 步，再加强第 1 步。
• 主观的重新审核触发条件。 “重大变更”会逐渐变成永不重新提交，因为没人能自行判断。改进方法：采用客观触发条件清单。
• 将事件过度归因于审核。 第三方应用遭入侵不一定就是审核失误。只有运营方本身明确说明因果流程变更时，才应声称存在此类变更（references/update-channel-hardening.md 载有适用规则）。如果某次事件根本不可能被审核关卡发现，却因此重新设计关卡，就是在错误的控制措施上浪费精力。
• 在规模超出承受范围后仍维持统一审核深度。 当审核成本成为瓶颈后，仍坚持单一的严格关卡，会造成数周的排队和开发者流失——基准测试中没有 SLA 的应用市场恰恰在自家论坛里收到这些投诉。
• 没有分流设计的自动化。 扫描所有内容并为所有问题创建工单，会淹没审核人员。仅针对严重/高危问题自动创建工单，并且只将确实存在歧义的信号类别交由人工处理。
• 名为申诉、实为重新提交。 将办公时间称为申诉会损害信任；对于面向欧盟的应用市场，还会让 P2B 风险得不到处理。

衡量

先为设计文档设置关卡；由于业界不存在审核流程设计的通过标准，因此由你自行设定标准。持续迭代，直到以下四项全部达标：

1. 每个审核层级都有开发者可自行判断的客观升级触发条件。
2. 通过客观标准定义“次要更新”——没有新增权限范围、没有新增外部端点、没有数据处理变更。
3. 每个执行阶梯都明确列出负责人、通知期限，以及触发执行的证据。
4. 发布渠道至少执行默认的控制阶梯；如果更新会自动传播，则还要设置传播暂停期。

上线后的运营 KPI：

• 首轮审核通过率（需要突破的基准下限：在最严格关卡下，约有一半的首次提交会失败——这是 Salesforce 经由 Aquiva Labs 给出的估算）。
• 首次决策用时与已公布的 SLA 的对比。
• 通过快速通道的更新比例。
• 申诉改判率。
• 每季度的批准后安全问题数量，以及修复用时与 SLA 的对比。
• 自动扫描误报率（误报率上升会悄然让审核人员习惯于忽略扫描器）。

如果你的测试框架具有持久记忆，请记录所选的流程形态、敏感度层级的触发条件、“次要更新”的定义，以及每个菜单的执行阶梯及其升级条件——入驻、上架和变现流程都应沿用这些决定，而不是反复询问。

调用示例

• “我们将在下个季度推出 CRM 应用市场——请为第三方应用设计安全审核流程。”
• “我们的应用审核要花六周，合作伙伴都很愤怒。如何增加快速通道，同时不让更新渠道重新变得不受控？”
• “刚有一个已安装的应用通过自动更新泄露了客户数据。请重写我们的重新审核和撤销政策，避免这种情况再次发生。”

参考资料

• references/platform-review-benchmarks.md - 八个平台的对比：流程结构、SLA、审核清单、审核团队设计以及具名扫描供应商。
• references/update-channel-hardening.md - 2024-2026 年发生的事件及有来源的归因（已确认的流程变更与未归因事件），以及发布渠道控制集的详细说明。
• references/rereview-and-appeal-policies.md - 各平台的重新审核触发条件和申诉等级，以及客观与主观触发条件的对比。

另请参阅同一合集中的内容：

• samber/developer-platform-skills@connector-marketplace-strategy - 确定本流程所执行的策展等级。如果市场准入严格程度尚未确定，请先运行它。
• samber/developer-platform-skills@oauth2-provider-design - 负责范围分类和授权许可流程。本技能的权限审计会根据该分类检查应用。
• samber/developer-platform-skills@partner-app-onboarding - 提交者通过此处设计的审核关卡所经历的流程：文档、沙盒租户和认证步骤。
• samber/developer-platform-skills@app-marketplace-listing-standards - 上架内容规则和内容质量相关的拒绝理由。准入资格由此处决定，徽章展示则由彼处处理。
• samber/developer-platform-skills@app-marketplace-monetization-model - 计费和收入分成机制。支付模式变更会在此处触发重新审核，其设计则由彼处负责。
• samber/developer-platform-skills@app-marketplace-launch-marketing - 将一批应用作为经过审核的应用进行推广的发布和宣传计划。此处设计的审核关卡能让这一说法名副其实，因此没有实际审核关卡的市场不能诚实地使用这一说法。