Bug Bounty Program
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
Main Capgo repository including backend services and landing website
Capacitor Updater Plugin
The core Capacitor plugin that handles over-the-air updates on mobile devices
有効な報告の要件
バグバウンティプログラムに合格するには、次の要件をすべて満たす必要があります:
- 脆弱性が存在する GitHub リポジトリの正確なファイルと行番号を特定する必要があります
- GitHub セキュリティアドバイザリに GitHub の関連リポジトリで報告する必要があります
- 脆弱性とその潜在的な影響について明確な説明を含める必要があります
- 問題を示すための再現可能なステップを提供する必要があります
重要: GitHub の code の正確な行番号がわからない場合は、バグバウンティプログラムの対象外となります。 GitHub セキュリティアドバイザリのみで報告する必要があります。 Algora.io でアカウントを作成し、直接支払いを受け取ることができます。
対応時間と敬意
友好的で、有効な報告に対して支払いますが、時間を尊重しない人々と協力できません。 ここで説明されているプログラムに従って、コミュニケーションを冷静に保ちます。
- 24-72 時間以内にセキュリティレポートや侵害に対応します。
- __CAPGO_KEEP_0__にメールを送るのはスパムです。1 日に 3 つ以上のメールを送るとブロックされます。
- これらのルールを無視したりスパムであると判断したレポートに対しては報酬を支払いません。
- このバグバウティープログラムに従って、スコープ内のレポートのみを受け付けます。そうでないものはブロックされる可能性があります。
- 「確認してみたか?」などのステータス更新の質問はしないでください。レポートを受け取ったことを確認した後、それ以上は何も必要ありません。レポートを確認した後、プルリクエストを作成するまでに数日かかる可能性があります。
重要: Capgoは小規模な起業家企業なので、ボーナス金額は大企業のプログラムよりも低くなります。Capgoのレポートには、$30までの最大金額が支払われます。Capgoのプラグインに対するレポートには、$300までの最大金額が支払われます。codeのプラグインに対するレポートは、@capgo/capacitor-updaterで有効な場合にのみ支払われます。Capgoのプラグインは無料で使用でき、Capgoの有料製品の範囲外なので、レポートは受け付けますが支払いはされません。レポートを確認し、問題を修正し、プルリクエストを開き、問題が修正されたことを確認した後、支払いが行われます。このプロセスは通常、20-30 日かかります。支払いはリリースが公開された後、問題が修正されたことを確認した後のみ行われます。
レポート方法
- GitHubの関連リポジトリに移動してください
- セキュリティタブをクリックしてください
- 脆弱性を報告するには、脆弱性アドバイザリを作成してください
- 脆弱性が存在するファイルパスと行番号を正確に記載してください
- 問題を再現する詳細な手順と脆弱性の影響を説明してください
範囲外
- Reports without exact code line references in GitHub
- Reports not submitted through GitHub Security Advisory
- 実証が存在しない仮想的な脆弱性
- 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.
- Capgo バンドルファイルへのアクセスまたはバンドルファイルがダウンロードできる証明。バンドルファイルはパブリックなウェブアセットであり、ユーザーにこれを知らせ、そしてこれへのアクセスはデータ漏洩と見なされない。
Supabaseと第三者サービス
Supabaseプラットフォームまたはサービス障害の場合は、Supabaseに報告する。 Capgo に報告しない。 Capgo が作成または選択した脆弱性のロジック、SQL、RPC、RLSポリシー、エッジ関数、または設定がプロジェクト内で修正可能であれば、Supabaseがエンドポイントを提供している場合でも範囲内である。Supabaseの動作に関する発見については、再現可能なケースと、プロジェクトの設定が私たちのものと同じである場合に、発生しないようにするためのexact Supabase設定またはconfig変更を含める。
例
ここでは有効ではありません。
- Supabaseプラットフォームのバグ、障害、または挙動が __CAPGO_KEEP_0__ で修正できるもの
- 再現できないもの
- Capgo がSupabaseの挙動を責めるのは、 Capgo が制御する修正や、exact Supabase設定またはconfig変更を示さない。
ここでは有効です。
- Capgo が制御するSupabaseのミス設定がプロジェクトの設定で修正可能なもの (手順あり)。
- Capgo が所有するSQL、RPC、RLS、関数、または統合問題が不安全なSupabase使用を引き起こすもの
- 特定の Capgo の Supabase プロジェクト、スキーマ、ポリシー内で発生する再現可能な問題、どれもが Supabase エンドポイントを通じて公開されている場合でも
既知の Supabase Auth 制限事項 (既に報告済み)
ある特定の Capgo の code に関する特定の発見は、再度報告され、Supabase Auth のデフォルト設定またはプラットフォームの動作によるものであり、Capgo の code に関するものではない。 これらの問題は、共有 Supabase デモプロジェクトで、設定が私たちのものと同じである場合にのみ、再現可能な場合にのみ、確認します。 また、Supabase 側の設定変更が Capgo のセキュリティ規則の変更を必要としない場合にのみ、確認します。 ただし、Capgo 所有の SQL、RPC、RLS ポリシー、関数、またはアプリロジックの変更が必要な場合、報告してください。 その場合、それは範囲内です。
- Capgo 所有の code/config オブジェクトの変更または Supabase の設定/構成変更が、再現可能なケースを提供し、特定の修正を特定する必要があります。
- Email 検証の動作は、Supabase Auth プロジェクトの設定に従って期待されます (たとえば、Email 確認が無効で、キャプチャベースの認証が使用されている場合)。
- パスワードの更新とアカウントの復元フローは、常に古いパスワードの再入力または再検証が必要ではない場合があります。 ただし、Supabase Auth がそのように構成されている場合。
- このリストに問題がある場合でも、提供されたプロジェクトまたは Capgo 所有のセキュリティ欠陥の具体的な Supabase 側の修正を示すことができれば、範囲内と考慮することができます。
Bug Bounty プログラムに関する質問については、GitHub セキュリティ アドバイザリを通じてご連絡ください。