漏洞赏金计划
Capgo 致力于安全和透明度。所有我们的 code 都是开源的，我们欢迎安全研究人员帮助我们识别我们的代码库中的漏洞。
开源的Code
Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.
GitHub Organization: github.com/Cap-go
Capgo Backend & Landing
Capgo backend and product repository (capgo.app API, dashboard, and related services)
有效报告的要求
要符合漏洞赏金计划的要求，报告必须满足以下所有条件：
- 您必须在我们的 GitHub 仓库中准确标识出存在漏洞的文件和行号
- 报告必须通过 GitHub 的安全建议在相关仓库中提交
- 您必须提供漏洞的清晰描述及其潜在影响
- 您必须提供可复现的步骤来演示问题
重要： 如果您无法提供存在问题的 code 在 GitHub 中的准确行号，报告将不符合漏洞赏金计划的要求。报告必须通过 GitHub 的安全建议提交。支付将通过 Algora.io 处理；请在该平台上创建账户，我们可以直接在该平台上支付给您。
响应时间和尊严
我们友好且为有效报告支付报酬，但我们无法与不尊严我们的时间的人合作。请保持沟通平和，遵循此程序。
- 我们在24-72小时内响应安全报告和漏洞。
- 不要向我们发送垃圾邮件。单天超过三封邮件被视为垃圾邮件并将被阻止。
- 我们不为忽视这些规则或发送垃圾邮件的报告支付报酬。
- 仅接受遵循此漏洞赏金计划的范围内的报告；其他任何内容都可能被阻止。
- 不要询问状态更新，如"您是否检查了?"或类似问题。我们确认收到您的报告后，已经足够了。之后，还有大量工作要做，准备一个拉取请求可能需要几天时间。
重要: Capgo is a tiny bootstrapped company, so our bounty amounts are lower than large-company programs. Reports without a clear exploit path are paid up to $30 max. Exploits with real, reproducible impact on Capgo are paid up to $300 max. We accept and review security reports for Capgo plugins, but paid bounties for plugin code are limited to @capgo/capacitor-updater. Other Capgo plugins are free to use and are not part of our paid product offering, so reports for them are reviewed but unpaid. Payments are issued only after we have identified the issue, released the fix, and you have verified post-release that the fix works for you. Opening or linking a pull request alone does not qualify for payment. This process usually takes a few days to a few weeks depending on severity and release cadence. Please do not send messages like "to get paid"; payment happens only once the release is live and you've tested and validated the fix.
How to Report
- 前往 GitHub 相关仓库
- 点击 "Security" 标签
- 点击 "Report a vulnerability" 创建新安全建议
- 包含具体的文件路径和行号（行号）
- 提供详细的复现步骤并解释安全影响
Out of Scope
- 没有具体的 code 行号在 GitHub 中
- 报告未通过 GitHub 安全建议提交
- 理论性漏洞没有概念证明
- 第三方平台、依赖项或服务中的BUG，Capgo无法直接修复（请将其报告到上游，例如 Supabase）。
- 社会工程或钓鱼企图
- 拒绝服务攻击
- SSRF 或 DNS 欺骗报告针对 webhook 或网站预览。这些功能在无服务器基础设施上运行，无法用于访问私有Capgo基础设施，因此它们在我们的环境中不可利用。
- 用户拥有的应用code或项目配置，Capgo不拥有、不运送或不控制，包括文件如capacitor.config.ts、config.capacitor.ts、应用源code和环境特定的设置。
- 访问Capgo捆绑文件或证明捆绑文件可以下载。捆绑文件是公共网络资产，用户已知晓这一点，访问它们并不被认为是数据泄露。
- 未经认证的Capgo插件/API端点，旨在公开的设计 — 包括设置和更新/统计端点，不需要API密钥 — 不是漏洞。不要将其报告为漏洞。
- 通过外部_url 服务的捆绑的上传器或 UI 错误标记加密不是Capgo漏洞（外部托管捆绑的加密在Capgo的控制之外）。
Supabase 和第三方服务
如果根源问题是 Supabase 平台或服务的 bug，请向 Supabase 报告，而不是 Capgo。如果易受攻击的逻辑、SQL、RPC、RLS 策略、边缘功能或配置由 Capgo 创建或选择，我们可以在我们的项目中修复它，即使 Supabase 提供了端点。对于 Supabase 行为本身的发现，请包含可复现的案例和预防它的确切 Supabase 设置或配置更改，在我们的项目中配置类似 ours。
示例
不合法
- 仅 Supabase 可以修复的 Supabase 平台 bug、停机或行为
- 无法复现的发现
- 指控 Capgo 对 Supabase 行为负责而没有显示 Capgo 控制的修复或确切的 Supabase 设置/配置更改
合法
- Capgo 控制的 Supabase 配置错误，我们可以在项目设置中修复（带步骤）
- Capgo 所有 SQL、RPC、RLS、函数或集成问题，导致不安全的 Supabase 使用
- Capgo 的 Supabase 项目、模式或策略中的可复现问题，即使它是通过 Supabase 端点暴露的
已知 Supabase Auth 限制（已报告）
Some findings are repeatedly reported and are caused by Supabase Auth defaults or platform behavior rather than Capgo code. We review these only when they can be reproduced in a shared Supabase demo project configured like ours and when the fix is a Supabase-side configuration change that does not require changing Capgo security rules. If the fix requires changing Capgo-owned SQL, RPCs, RLS policies, functions, or app logic, report it to us because that is in scope.
- 请提供一个可重现的案例，并确定具体的修复：要么是 Supabase 设置/配置更改，要么是 Capgo-所有的 code/配置对象需要更改。
- 电子邮件验证行为应遵循您的 Supabase Auth 项目设置（例如，是否禁用电子邮件确认并使用捕获式认证）。
- 如果 Supabase Auth 配置为不要求旧密码重新输入或重新验证，则密码更新和帐户恢复流程可能不会始终要求旧密码重新输入或重新验证。
- 如果问题在此列表中，但您可以在提供的项目中展示一个具体的 Supabase 端修复或一个具体的 Capgo-所有的安全缺陷，我们可以考虑它在范围内。
有关我们的 Bug Bounty 计划的任何问题，请通过我们的 GitHub 安全咨询联系我们。