{'text': '当則网络求会起给'}

Capgo is committed to security and transparency. All our code is open source, and we welcome security researchers to help us identify vulnerabilities in our codebase.

Open Source Code

每个在Capgo组织中的仓库都是开源的。您可以浏览、审计并为我们的code贡献。

GitHub 组织: github.com/Cap-go

Bug Bounty 报告要求

要符合 Bug Bounty 计划，报告必须满足以下所有要求：

• 您必须在我们的 GitHub 仓库中准确标识出存在漏洞的文件和行号
• 您的报告必须通过 GitHub 在相关仓库的安全公告提交
• 您必须提供清晰的漏洞描述及其潜在影响
• 您必须提供可复现的步骤来演示问题

响应时间和尊严

我们友好，我们会支付有效报告，但我们无法与不尊严我们时间的人合作。请保持沟通平和，遵循这个程序。

• 我们在 24-72 小时内响应安全报告和漏洞。
• 不要向我们发送垃圾邮件。超过三封邮件在同一天被视为垃圾邮件并将被阻止。
• 我们不会支付忽视这些规则或是垃圾邮件的报告。
• 只有遵循这个 Bug Bounty 程序的在范围内的报告才被接受；其他任何报告都可能被阻止。
• 不要询问状态更新，如 "您已经检查了吗？" 或类似的问题。一旦我们确认收到您的报告，那就足够了。之后，还有大量工作需要做，准备 pull 请求可能需要几天时间。

如何报告

1. 前往相关的 GitHub 仓库
2. 点击“安全”标签
3. 点击“报告漏洞”以创建新安全建议
4. 包含具体的文件路径和行号（们）
5. 提供详细的复现步骤并解释安全影响

不在范围内

• 没有提供具体的 code 行号的 GitHub 报告
• 没有通过 GitHub 安全建议提交的报告
• 理论性漏洞没有概念证明
• Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
• 社会工程或钓鱼企图
• 拒绝服务攻击
• SSRF or DNS spoofing reports against webhooks or website preview. These features run on serverless infrastructure and cannot be used to reach private Capgo infrastructure, so they are not exploitable in our environment.
• User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
• Access to Capgo bundle files or proof that bundle files can be downloaded. Bundle files are public web assets, users are informed of this, and access to them is not considered a data breach.
• Unauthenticated Capgo plugin/API endpoints that are intentionally public by design — including channel_self set and update/stats endpoints that do not require an API key — are not vulnerabilities. Do not report them as such.
• Uploader or UI incorrectly labeling encryption for bundles served via external_url is not a Capgo vulnerability (encryption of externally hosted bundles is outside Capgo’s control).

Supabase 和第三方服务

如果根源是 Supabase 平台或服务的 bug，请向 Supabase 报告，而不是 Capgo。如果易受攻击的逻辑、SQL、RPC、RLS 策略、边缘功能或配置由 Capgo 创建或选择，我们可以在我们的项目中修复它，即使 Supabase 提供了端点。对于 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 安全公告联系我们。