漏洞赏金计划
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
安全报告的要求
为了参加漏洞赏金计划，报告必须满足以下所有要求：
- 您必须在我们的GitHub仓库中找出确切的文件和行号，哪里存在漏洞
- 您的报告必须通过GitHub安全建议在相关仓库提交
- 您必须提供漏洞的清晰描述及其潜在影响
- 您必须提供可复现的步骤来演示问题
重要： 如果您无法提供GitHub中code的确切行号，报告将不符合漏洞赏金计划的要求。报告必须通过GitHub安全建议提交。通过Algora.io处理付款；请在该平台上创建一个账户，我们可以直接在该平台上为您支付。
响应时间和尊严
我们友好并且为有效报告支付报酬，但我们无法与不尊严对待我们的时间的人合作。请保持沟通平和，并遵循此程序。
- 我们在24-72小时内响应安全报告和泄露
- 不要向我们发送垃圾邮件。超过三封邮件在同一天被视为垃圾邮件并将被阻止。
- 我们不会为忽略这些规则或发送垃圾邮件的报告付款。
- 仅接受遵循此漏洞赏金计划的相关报告;其他任何内容都可能被阻止。
- 不要询问状态更新，如"您是否检查了？"或类似的问题。我们确认收到您的报告后即可。
重要： 仅在我们确定问题、修复它、打开拉取请求并您在发布后验证修复后才会发放付款。这通常需要20到30天的时间。请不要发送类似"发放付款"的消息；付款只在发布后并且您已测试和验证修复后才会发生。
如何报告
- 导航到相关存储库中的GitHub
- 点击"安全"标签
- 点击"报告漏洞"以创建新安全建议
- 包含漏洞存在的确切文件路径和行号
- 提供详细步骤来复现问题并解释安全影响
不在范围内
- 没有提供确切的code行引用在GitHub中的报告
- 没有通过GitHub安全建议提交的报告
- 理论上的漏洞没有概念证明
- 第三方平台、依赖项或服务中的漏洞，Capgo无法直接修复（例如，报告到Supabase）
- 社会工程或钓鱼攻击
- 拒绝服务攻击
Supabase和第三方服务
如果根源是Supabase平台或服务的bug，报告到Supabase，而不是Capgo。如果易受攻击的逻辑、SQL、RPC、RLS策略、边缘函数或配置是Capgo创建或选择的，我们可以在我们的项目中修复它，即使Supabase提供了端点。对于Supabase行为本身的发现，包括可复现的案例和在与我们配置类似的项目中预防它的确切Supabase设置或配置更改
示例
这里无效
- 仅有Supabase可以修复的Supabase平台bug、停机或行为
- 无法重现的发现
- 指控Capgo导致 Supabase 行为问题而没有显示Capgo控制的修复或具体的 Supabase 设置/配置更改
有效
- Capgo控制的 Supabase 配置错误，我们可以在项目设置（带步骤）中修复
- Capgo拥有的 SQL、RPC、RLS、函数或集成问题导致不安全的 Supabase 使用
- 在Capgo的 Supabase 项目、模式或策略中可重现的问题，即使它是通过 Supabase 端点暴露出来的
已知的 Supabase 身份验证限制（已报告）
有些发现反复报告，并且由 Supabase 身份验证默认值或平台行为引起，而不是Capgo code。我们只会在这些问题可以在一个配置类似我们的 Supabase 演示项目中重现，并且修复需要 Supabase 端的配置更改，而不需要更改Capgo安全规则时才会进行审查。如果修复需要更改Capgo拥有的 SQL、RPC、RLS 策略、函数或应用逻辑，请将其报告给我们，因为这在范围内
- 提供一个可重现的案例并标识具体的修复：要么是 Supabase 设置/配置更改来解决 Supabase 行为问题，要么是Capgo拥有的code/配置对象需要更改
- 电子邮件验证行为应遵循您的 Supabase 身份验证项目设置（例如，是否禁用电子邮件确认并使用捕获式身份验证）
- 密码更新和帐户恢复流程可能不需要老密码重新输入或重新验证，如果 Supabase Auth 配置为这样。
- 如果问题在此列表中，但您可以在提供的项目中显示一个具体的 Supabase-side 修复或一个具体的 Capgo-所有安全缺陷，我们可以考虑它在范围内。
关于我们的 Bug Bounty 计划的问题，请通过我们的 GitHub 安全公告联系我们。