漏洞赏金计划
Capgo 致力于安全与透明。我们的所有 code 都是开源的，欢迎安全研究人员帮助我们找出代码库中的漏洞。
开源 Code
Capgo 组织下的每个仓库都是开源的。你可以审查、审计，并为我们的 code 做出贡献。
GitHub 组织： github.com/Cap-go
有效报告的要求
若要符合 Bug Bounty 计划的资格，你的报告必须满足以下所有要求：
- 您必须指出漏洞在我们 GitHub 仓库中的确切文件和行号
- 您的报告必须通过相关仓库的 GitHub Security Advisory 提交
- 您必须包含对漏洞及其潜在影响的清晰描述
- 您必须提供可复现的步骤来演示该问题
重要提示： 如果您无法提供问题所在的 GitHub 中 code 的确切行号，您的报告将不符合 Bug Bounty 计划的资格。报告必须仅通过 GitHub Security Advisory 提交。奖励通过 Algora.io 发放；请在那里创建账户，以便我们直接在平台上向您付款。
响应时间与尊重
我们很友好，也确实会为有效报告支付奖励，但无法与不尊重我们时间的人合作。请保持冷静沟通，并遵守本计划。
- 我们会在 24-72 小时内响应安全报告和入侵事件。
- 请勿向我们发送垃圾邮件。一天内发送超过三封邮件会被视为垃圾邮件并被屏蔽。
- 我们不会为无视这些规则或属于垃圾邮件的报告支付奖励。
- 我们只接受属于本 Bug Bounty 计划范围并遵守该计划的报告；其他内容可能会被屏蔽。
- 请勿询问“检查了吗？”之类的进度更新。一旦我们确认收到您的报告即可。后续仍有大量工作需要处理，准备 pull request 可能需要几天时间。
重要提示： Capgo 是一家初创型小公司，因此我们的赏金金额低于大型公司的项目。没有明确利用路径的报告最高支付 $30。对 Capgo 有实际、可复现影响的漏洞最高支付 $300。我们接受并审核 Capgo 插件的安全报告，但针对插件 code 的付费赏金上限为 @capgo/capacitor-updater.。其他 Capgo 插件可免费使用，不属于我们的付费产品范围，因此相关报告会经过审核但不会支付赏金。只有在我们确认问题、发布修复程序，且您在发布后验证修复有效时，才会发放款项。仅提交或关联 pull request 并不符合支付条件。根据严重程度和发布周期，此过程通常需要几天到几周不等。请不要发送“为了拿到钱”之类的消息；只有在版本发布且您测试验证修复有效后，才会进行支付。
如何报告
- 前往 GitHub 上的相关 repository
- 点击 “Security” 选项卡
- 点击 “Report a vulnerability” 以创建新的安全公告
- 请包含漏洞存在的准确文件路径和行号
- 请提供详细的复现步骤，并说明该漏洞的安全影响
不在范围之内
- 未在 GitHub 中提供准确的 code 行号引用的报告
- 未通过 GitHub Security Advisory 提交的报告
- 缺乏 PoC（概念验证）的理论性漏洞
- Capgo 无法直接修复的第三方平台、依赖项或服务的漏洞（请向其上游厂商报告，例如 Supabase）
- 社会工程学或网络钓鱼攻击
- 拒绝服务攻击 (DoS)
- 针对 webhook 或网站预览的 SSRF 或 DNS 欺骗报告。这些功能运行在 serverless 基础设施上，无法用于访问私有 Capgo 基础设施，因此在我们环境中无法被利用。
- 用户拥有的应用 code 或项目配置，且 Capgo 不拥有、发布或控制这些内容，包括 capacitor.config.ts、config.capacitor.ts、应用源码 code 以及特定环境设置。
- 访问 Capgo bundle 文件，或证明 bundle 文件可被下载。bundle 文件是公开的 Web 资源，用户已被告知这一点，因此访问这些文件不被视为数据泄露。
- 按设计有意公开的未认证 Capgo plugin/API 端点——包括无需 API 密钥的 channel_self 设置和 update/stats 端点——不属于漏洞。请勿将其作为漏洞报告。
- 上传器或 UI 对通过 external_url 提供的 bundle 错误标注加密，这不属于 Capgo 漏洞（外部托管 bundle 的加密不在 Capgo 的控制范围内）。
Supabase 与第三方服务
如果根本原因是 Supabase 平台或服务本身的 bug，请向 Supabase 报告，而不是向 Capgo 报告。如果存在漏洞的逻辑、SQL、RPC、RLS 策略、Edge Function 或配置是由 Capgo 创建或选择的，并且我们能在自己的项目中修复，那么即使该端点由 Supabase 提供，也属于本次范围。对于涉及 Supabase 自身行为的发现，请提供可复现的案例，以及在配置与我们的项目类似的环境中可防止该问题的确切 Supabase 设置或配置更改。
示例
不属于本次范围
- 仅能由 Supabase 修复的 Supabase 平台 bug、服务中断或行为
- 无法复现的漏洞发现
- 未提供由 Capgo 控制的修复方案或确切的 Supabase 设置/配置更改，却将 Supabase 的行为归咎于 Capgo 的说法
属于本次范围
- 我们可以在项目设置中修复的、由 Capgo 控制的 Supabase 配置错误（需提供步骤）
- 由 Capgo 负责的 SQL、RPC、RLS、函数或集成问题，导致 Supabase 使用方式不安全
- 在 Capgo 的 Supabase 项目、schema 或策略中可复现的问题，即使它是通过 Supabase 端点暴露的
已知 Supabase Auth 限制（已报告）
有些发现会被反复报告，这些问题源于 Supabase Auth 的默认设置或平台行为，而不是 Capgo code 的问题。只有当这些问题能在与我们配置相同的共享 Supabase 演示项目中复现，并且修复方式是 Supabase 端的配置变更、无需修改 Capgo 安全规则时，我们才会审查。如果修复需要修改 Capgo 负责的 SQL、RPC、RLS 策略、函数或应用逻辑，请报告给我们，因为这属于受理范围。
- 请提供可复现的用例，并明确具体修复方案：要么是能解决 Supabase 行为问题的 Supabase 设置/配置变更，要么是需要修改的、由 Capgo 负责的 code/config 对象。
- 邮件验证行为应遵循你的 Supabase Auth 项目设置（例如是否禁用邮件确认，以及是否使用基于验证码的认证）。
- 如果 Supabase Auth 这样配置，密码更新和账号恢复流程可能并不总是需要重新输入旧密码或重新验证。
- 如果问题在此列表中，但你能在提供的项目中给出具体的 Supabase 端修复方案，或证明存在具体的、由 Capgo 负责的安全缺陷，我们仍可将其纳入范围。
有关我们漏洞赏金计划的问题，请通过我们的 GitHub Security Advisories 联系我们。