バグバウンティープログラム

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

Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.

GitHub Organization: github.com/Cap-go

有効な報告の要件

Bug Bounty プログラムに参加するには、次の要件をすべて満たす必要があります。

• 報告された脆弱性が存在する GitHub リポジトリの正確なファイルと行番号を特定する必要があります。
• 報告は GitHub セキュリティ アドバイザリに提出する必要があります。
• 脆弱性とその潜在的な影響について明確な説明を含める必要があります。
• 問題を示す再現可能なステップを提供する必要があります。

対応時間と敬意

私たちは親切ですが、時間を尊重しない人々と協力することはできません。報告を提出する際は、冷静で礼儀正しく、プログラムに従ってください。

• 24-72 時間以内にセキュリティレポートや侵害に対応します。
• 私たちにスパムを送らないでください。1 日に 3 つ以上のメールを送るとスパムとみなされブロックされます。
• 侵害のルールを無視したりスパムのレポートを送った場合、報酬は支払いません。
• このバグバウティープログラムに従わないレポートやスパムのレポートは受け付けられません。
• ステータス更新の質問など「チェックしてみたか？」などの質問はしないでください。レポートを受け取ったことを確認した後、それ以上は必要ありません。

レポート方法

1. GitHub の関連リポジトリに移動してください。
2. セキュリティタブをクリックしてください。
3. 脆弱性を報告するには、セキュリティアドバイザリーを作成してください。
4. 脆弱性が存在するファイルパスと行番号を正確に記載してください。
5. 脆弱性の再現方法を詳細に記載し、セキュリティの影響を説明してください。

範囲外

• Reports without exact code line references in GitHub
• Reports not submitted through GitHub Security Advisory
• Theoretical vulnerabilities without proof of concept
• Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
• 社会工程学やフィッシング攻撃
• サービス拒否攻撃
• SSRFまたはDNSスプーフィングの報告は、ウェブホーキーまたはウェブサイトのプレビューに対して行われます。これらの機能はサーバーレスインフラストラクチャ上で実行され、プライベートCapgoインフラストラクチャにアクセスすることはできません。したがって、環境内では利用できません。
• ユーザーが所有するアプリケーション code またはプロジェクト設定が Capgo が所有、配布、または制御しないファイルなど、capacitor.config.ts、config.capacitor.ts、ソースコード code、環境固有の設定など。
• Capgo バンドルファイルへのアクセスまたはバンドルファイルがダウンロードできることを証明するもの。バンドルファイルはパブリックウェブアセットであり、ユーザーはこれを知っており、そこへのアクセスはデータ漏洩と見なされない。

Supabaseと第三者サービス

Supabaseプラットフォームまたはサービスに関するバグの場合は、Supabaseに報告してください。 Capgo に報告しないでください。 Capgo が作成または選択した脆弱性のロジック、SQL、RPC、RLSポリシー、エッジ関数、または構成がプロジェクトで修正できる場合は、スコープ内です。Supabaseがエンドポイントを提供している場合でも。Supabaseの動作に関するフィードバックについては、再現可能なケースと、プロジェクトの設定が ours のように設定されている場合に、フィードバックを防止するために必要な 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 の設定/構成変更が Supabase の動作問題を解決する場合、または Capgo 所有の code /構成オブジェクトが変更する必要がある場合
• メール確認の動作は、Supabase Auth プロジェクト設定に従って期待されます (たとえば、メール確認が無効になっている場合、キャプチャベースの認証が使用されている場合)。
• パスワードの更新とアカウントの回復フローは、常に古いパスワードの再入力または再検証が必要ではない場合があります。 ただし、Supabase Auth がそのように構成されている場合です。
• 問題がこのリストに含まれている場合でも、提供されたプロジェクトで明確な Supabase 側の修正を示すことができ、または明確な Capgo 所有のセキュリティ欠陥を示すことができれば、範囲内と考慮できます。

Bug Bounty プログラムに関する質問については、 GitHub セキュリティ アドバイザリを通じてご連絡ください。