バグ ボーナス プログラム
Capgoは、セキュリティと透明性に取り組んでいます。すべてのcodeはオープンソースであり、セキュリティ リサーチャーを歓迎し、コードベースの脆弱性を特定するのを支援しています。
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
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 の code の特定の行番号を提供できない場合は、バグバウティプログラムの対象外となります。レポートは GitHub セキュリティ アドバイザリのみに提出する必要があります。Algora.io でアカウントを作成し、直接プラットフォームで支払いを受け取ることができます。
対応時間と敬意
私たちはフレンドリーで、有効なレポートに対して支払いますが、時間を尊重しない人々と協力することはできません。コミュニケーションは冷静で、このプログラムに従ってください。
- 24-72 時間以内にセキュリティ レポートと侵害に対応します。
- スパムを送りません。1 日に 3 つのメール以上送るとスパムとみなされ、ブロックされます。
- 報告を提出する際は、以下のルールを無視したり、スパムである場合は、報酬を支払いません。
- このバグ・バウティープログラムに従って、スコープ内に収まるのみの報告が受け入れられます。そうでない場合は、ブロックされる可能性があります。
- ステータス更新の質問（例：「チェックしてみたか？」など）を避けてください。報告を受け取ったことを確認した後、それが十分です。報告を受け取った後も、まだ大きな作業が残っており、プルリクエストを準備するには数日かかる可能性があります。
重要： Capgoは小規模な起業家であるため、ボーナス金額は大企業のプログラムよりも低くなります。報告内容に明確なエクスプロイトパスがない場合は、最大$30まで支払います。Capgoに実際に影響を与える、再現可能なエクスプロイトは最大$300まで支払います。Capgoプラグインのセキュリティレポートを受け付けて、レビューしますが、codeプラグインの有料ボーナスは@capgo/capacitor-アップデーターに制限されています。Capgoプラグインは、有料製品の範囲外であり、無料で使用できるため、報告はレビューされますが、支払いは行われません。支払いは、問題を特定し、修正し、プルリクエストを開き、リリース後に修正が機能することを確認した後、のみ行われます。このプロセスは通常、20から30日かかります。支払いを求めるメッセージを送ることは避けてください。リリースが公開され、修正が機能することを確認した後、のみ支払いが行われます。
報告方法
- GitHubの関連リポジトリに移動してください。
- 「セキュリティ」タブをクリックしてください。
- 「脆弱性を報告する」をクリックして、新しいセキュリティアドバイザリを作成してください。
- ファイルパスと行番号を含む脆弱性の場所
- 問題を再現するための詳細な手順とセキュリティの影響を説明する
範囲外
- codeの行参照が含まれていないGitHubのレポート
- GitHubのセキュリティアドバイザーの通報以外のレポート
- 実証のない仮想的な脆弱性
- Capgoが直接修正できない第三者のプラットフォーム、依存関係、またはサービス内のバグ(上流に報告するなど)
- 社会工学またはフィッシング攻撃
- サービス拒否攻撃
- SSRFまたはDNSスパッフィングレポートは、ウェブフックまたはサイトプレビューに対して。サーバーレスインフラで実行されるため、プライベートCapgoインフラに到達することはできず、環境内では利用できない。
- ユーザー所有のアプリケーションcodeまたはプロジェクトの設定がCapgoが所有、配布、または制御していない、ファイルとしてはcapacitor.config.ts、config.capacitor.ts、ソースコードcode、および環境固有の設定。
- Capgoのバンドルファイルへのアクセスまたはバンドルファイルがダウンロードできる証拠。バンドルファイルはパブリックウェブアセットであり、ユーザーはこれを知っており、ファイルへのアクセスはデータ漏洩とは見なされない。
Supabase と第三者サービス
Capgoのバグを報告する場合は、Supabaseに報告してください。ただし、Capgoが作成したまたは選択した脆弱なロジック、SQL、RPC、RLSポリシー、エッジ関数、または構成がプロジェクトで修正できる場合は、Supabaseがエンドポイントを提供している場合でも範囲内です。Supabaseの動作に関する発見については、プロジェクトの構成が ours のように設定されている場合に、再現可能なケースと、発見を防ぐために必要なexact Supabaseの設定またはconfig変更を含めてください。
例
ここでは有効ではありません
- Supabaseプラットフォームのバグ、ダウンタイム、またはSupabaseのみが修正できる動作
- 再現できない発見
- Supabaseの動作をCapgoが責任としていることを示すのに、Capgoが制御する修正や、exact Supabaseの設定またはconfig変更を示していない
ここでは有効
- Capgoが制御するSupabaseのミス設定をプロジェクトの設定で修正できるもの (手順あり)
- Capgoが所有するSQL、RPC、RLS、関数、または統合問題が不安全なSupabase使用を引き起こすもの
- CapgoのSupabaseプロジェクト、スキーマ、またはポリシーにおける再現可能な問題、即使エンドポイントを介して公開されている場合も
既知のSupabase Auth制限 (既に報告済み)
特定の問題が繰り返し報告され、Supabase Auth のデフォルト設定またはプラットフォームの動作によるものではなく、Capgo code の問題によるものである場合、確認するのは、共有の Supabase demo プロジェクトで再現できるものだけです。このプロジェクトは、 ours と同じ構成で構成されています。また、修正は Supabase 側の構成変更であり、Capgo のセキュリティ規則の変更が必要ない場合にのみ確認します。修正が Capgo 所有の SQL、RPC、RLS ポリシー、関数、またはアプリロジックの変更が必要な場合、報告してください。これは範囲内です。
- 再現可能なケースを提供し、正確な修正を特定してください。修正は、Supabase の設定/構成変更による Supabase の動作問題の解決、または Capgo 所有の code/構成オブジェクトの変更です。
- メール認証の動作は、Supabase Auth プロジェクトの設定に従ってください (例えば、メール確認が無効でキャプチャベースの認証が使用されている場合)。
- パスワード更新とアカウント復元フローは、常に古いパスワードの再入力または再検証が必要ではない場合があります。Supabase Auth がそのように構成されている場合。
- このリストに問題がある場合でも、提供されたプロジェクトまたは Capgo 所有のセキュリティ欠陥の具体的な Supabase 側の修正を示すことができれば、範囲内と考慮することができます。
Bug Bounty プログラムに関する質問については、GitHub セキュリティアドバイザリを通じてご連絡ください。