漏洞赏金计划
Capgo 致力于安全和透明度。我们所有的 code 都是开源的，我们欢迎安全研究人员帮助我们识别我们的代码库中的漏洞。
开源 Code
Capgo 组织中的每个仓库都是开源的。您可以审查、审计并为我们的 code 贡献。
GitHub 组织： github.com/Cap-go
Requirements for Valid Reports
To qualify for the Bug Bounty program, your report must meet ALL of the following requirements:
- You must identify the exact file and line number in our GitHub repository where the vulnerability exists
- Your report must be submitted through GitHub Security Advisory on the relevant repository
- You must include a clear description of the vulnerability and its potential impact
- You must provide reproducible steps to demonstrate the issue
Important: If you cannot provide the exact line of code in GitHub where the problem exists, your report will not be eligible for the Bug Bounty program. Reports must be submitted through GitHub Security Advisory only. Payments are handled via Algora.io; please create an account there so we can pay you directly on the platform.
Response Time and Respect
We are friendly and we do pay for valid reports, but we cannot work with people who do not respect our time. Please keep communication calm and follow this program.
- We respond to security reports and breaches within 24-72 hours.
- Do not spam us. More than three emails in a single day is considered spam and will be blocked.
- 我们不会为忽视这些规则或是垃圾邮件的报告付费。
- 仅接受遵循此漏洞赏金计划的在范围内的报告;其他任何内容可能会被阻止。
- 不要询问状态更新，如"你是否检查了?"或类似问题。 一旦我们确认收到了你的报告，那就足够了。 之后仍然有大量的工作要做，准备一个 pull 请求可能需要几天时间。
重要： Capgo 是一个小型的自举公司，所以我们的赏金金额比大公司计划要低。 没有明确的利用路径的报告最多可获得 $30。 利用有真正的、可重复的影响的 Capgo 最多可获得 $300。 我们接受并审查 Capgo 插件的安全报告，但 code 插件的付费赏金仅限于 @capgo/capacitor-updater。 其他 Capgo 插件是免费使用的，不属于我们的付费产品范围，因此报告它们将被审查但不付费。 只有在我们确定了问题、修复了它、打开了 pull 请求并且你在发布后验证了修复后，我们才会发放付款。 这个过程通常需要 20 到 30 天。 请不要发送类似"要获得付款"的消息；付款只会在发布后你测试并验证修复后才会发生。
如何报告
- 导航到相关的仓库在 GitHub 上
- 点击 "安全" 标签
- 点击 "报告漏洞" 来创建一个新的安全建议
- 包含具体的文件路径和行号（行号）来指出存在的漏洞
- 提供详细的步骤来复现问题，并解释安全影响
不在范围内
- 没有包含具体code行号参考的GitHub报告
- 没有通过GitHub安全建议提交的报告
- 没有实际的漏洞证明
- 第三方平台、依赖项或服务中的bug（例如Supabase），Capgo无法直接修复（请将其报告上游）
- 社会工程或钓鱼攻击
- 拒绝服务攻击
- SSRF或DNS欺骗报告针对Capgo webhook或网站预览。这些功能在无服务器环境中运行，无法用于访问私有Capgo基础设施，因此它们在我们的环境中不可利用。
- 用户拥有的应用code或项目配置，Capgo不拥有、不部署或不控制，包括文件如capacitor.config.ts、config.capacitor.ts、应用源code和环境特定的设置
- 访问Capgo打包文件或证明打包文件可以下载。打包文件是公共网络资产，用户已被告知这一点，访问它们并不被认为是数据泄露
与 Supabase 和第三方服务
如果根源原因是 Supabase 平台或服务的 bug,请向 Supabase 报告,而不是 Capgo. 如果易受攻击的逻辑、SQL、RPC、RLS 策略、边缘函数或配置由 Capgo 创建或选择,并且我们可以在项目中修复它,即使 Supabase 提供了端点,它仍然在范围内。 对于 Supabase 行为本身的发现,请包含可复现的案例和预防它的确切 Supabase 设置或配置更改,在我们的项目中配置类似。
示例
这里无效
- 仅有 Supabase 可以修复的 Supabase 平台 bug、停机或行为
- 无法复现的发现
- A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change
这里有效
- 我们项目设置中的 Capgo 控制的 Supabase 错误配置 (带有步骤)
- Capgo 所有 SQL、RPC、RLS、函数或集成问题,导致不安全的 Supabase 使用
- Capgo 的 Supabase 项目、模式或策略中的可复现问题,即使它是通过 Supabase 端点暴露的
已知 Supabase Auth 限制 (已报告)
某些发现反复报告并由 Supabase Auth 默认值或平台行为引起，而不是 Capgo code。我们只在这些问题可以在与我们的配置类似的共享 Supabase 演示项目中重现时才会审查它们，并且修复需要 Supabase 一侧的配置更改，而不需要更改 Capgo 安全规则。如果修复需要更改 Capgo 所有者 SQL、RPCs、RLS 策略、函数或应用逻辑，请向我们报告，因为这在范围内。
- 提供可复现的案例并确定具体的修复：要么是 Supabase 设置/配置更改来解决 Supabase 行为问题，要么是 Capgo 所有者 code/配置对象必须更改。
- 预期电子邮件验证行为将遵循您的 Supabase Auth 项目设置（例如，是否禁用电子邮件确认并使用捕获式身份验证）。
- 密码更新和帐户恢复流程可能并不总是需要旧密码重新输入或重新验证，如果 Supabase Auth 配置为这样。
- 如果问题在此列表中，但您可以在提供的项目中显示一个具体的 Supabase 一侧的修复或一个具体的 Capgo 所有者安全缺陷，我们可以考虑它在范围内。
有关我们的 Bug Bounty 计划的任何问题，请通过我们的 GitHub 安全咨询联系我们。