メインコンテンツにスキップ

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

Capgoは、セキュリティと透明性に取り組んでいます。すべてのcodeは、オープンソースであり、セキュリティ研究者を歓迎し、コードベースの脆弱性を特定するために協力してください。

オープンソースCode

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

GitHub Organization: https://github.com/Cap-go

Capgoバックエンド&ランディング

主なCapgoリポジトリ、バックエンドサービス、ランディングウェブサイトを含みます。

Capacitorアップデートプラグイン

The core Capacitor plugin that handles over-the-air updates on mobile devices

Requirements for Valid Reports

Bug Bounty programへの申し込みには、以下の要件を満たす必要があります。

  • You must identify the exact file and line number in our GitHub repository where the vulnerability exists
  • GitHub Security Advisoryを通じて、関連するリポジトリに報告する必要があります。
  • 脆弱性とその潜在的な影響について、明確な説明を含める必要があります。
  • 問題を再現するための手順を提供する必要があります。

重要な注意事項 If you cannot provide the exact line of code in GitHub where the problem exists, your report will not be eligible for the Bug Bounty program. Reports must be submitted through GitHub Security Advisory only. Payments are handled via Algora.io; please create an account there so we can pay you directly on the platform.

__CAPGO_KEEP_2__ Security Advisoryを通じてのみ報告する必要があります。Algora.ioを通じて支払いが行われます。

対応時間と敬意の重要性について

  • We respond to security reports and breaches within 24-72 hours.
  • メールを大量に送ることは禁止されています。1日あたり3件以上のメールはスパムとみなされ、ブロックされます。
  • We do not pay for reports that ignore these rules or are spam.
  • このバグ・バウティー・プログラムのルールに従った、スコープ内にあるのみのレポートが受け付けられます。そうでないものはブロックされる可能性があります。
  • Do not ask for status updates such as "have you checked?" or similar questions. Once we confirm we received your report, that is enough. After that, there is still significant work to do, and preparing a pull request can take several days.

重要: Capgoは小規模な起業家企業であるため、ボーナス金額は大企業のプログラムよりも低くなります。明確な攻撃パスが存在しないレポートは最大$30、実際にCapgoに影響を与える可能性のある攻撃は最大$300のボーナスが支払われます。問題を特定し修正し、プルリクエストを開き、リリース後に修正が機能することを確認した後のみ、支払いが行われます。このプロセスは通常20-30日かかります。支払いについてのメッセージを送ることはお控えください。リリースが公開され、修正が機能することを確認した後のみ支払いが行われます。

レポート方法

  1. GitHubの関連リポジトリに移動してください。
  2. セキュリティタブをクリックしてください。
  3. セキュリティアドバイザリを作成するには、"レポートする"をクリックしてください。
  4. レポートにファイルパスと行番号を含めてください。
  5. 問題の再現方法とセキュリティの影響を詳しく説明してください。

範囲外

  • code の特定の行参照が含まれない GitHub のレポート
  • GitHub セキュリティ アドバイザーの通報以外のレポート
  • 実証が存在しない理論的な脆弱性
  • 直接修正できない Capgo のプラットフォーム、依存関係、またはサービス内のバグ
  • 社会的工程学またはフィッシング攻撃
  • サービス拒否攻撃
  • SSRFまたはDNSスパッフォイニングレポートは、ウェブフックまたはウェブサイトプレビューに対して。ウェブフックやウェブサイトプレビューはサーバーレスインフラストラクチャ上で動作し、プライベートCapgoインフラストラクチャにアクセスすることはできません。したがって、環境内では利用可能ではありません。

Supabaseとサードパーティサービス

Capgo が作成したまたは選択した脆弱性のロジック、SQL、RPC、RLSポリシー、エッジ関数、または構成が存在し、プロジェクト内で修正できる場合は、範囲内です。ただし、Supabaseプラットフォームまたはサービス内のバグの場合は、Supabaseにレポートしてください。Capgo にレポートするのではなく。

サンプル

ここでは有効ではありません

  • サプバースのプラットフォームのバグ、停止、または __CAPGO_KEEP_0__ しか修正できない動作
  • 再現できない問題
  • Capgo がサプバースの動作を非難する申告ですが、サプバースの設定/構成変更や Capgo を制御する修正を示していません

ここでは有効です

  • Capgo を制御するサプバースのミス設定をプロジェクト設定で修正できます (手順あり)
  • Capgo 所有の SQL、RPC、RLS、関数、または統合問題が不正なサプバース使用を引き起こします
  • Capgo 所有のサプバースプロジェクト、スキーマ、ポリシー内で再現可能な問題です。サプバースエンドポイントを通じて表示される場合も含みます

既知のサプバース認証制限 (既に報告済み)

ある程度の問題は、サプバース認証のデフォルト値またはプラットフォームの動作ではなく、 Capgo code によって引き起こされるため、再現可能な場合にのみサプバースのデモプロジェクトを共有して設定し、サプバース側の設定変更が Capgo のセキュリティ規則の変更を必要としない場合にのみ確認します。 Capgo 所有の SQL、RPC、RLS ポリシー、関数、またはアプリロジックの変更が必要な場合、報告してください。そうすると、範囲内です。

  • 再現可能なケースを提供し、次のいずれかを特定してください: サプバースの設定/構成変更がサプバースの動作問題を解決するか、 Capgo 所有の code/config オブジェクトが変更する必要があります
  • メール確認の動作は、サプバース認証プロジェクトの設定に従うことが期待されます (例: メール確認が無効化され、キャプチャベースの認証が使用されている場合)
  • パスワードの更新とアカウントの回復フローは、Supabase Auth がそのように設定されている場合には常に古いパスワードの再入力または再検証が必要ではない場合があります。
  • このリストに問題がある場合でも、提供されたプロジェクトまたは Capgo 所有のセキュリティ欠陥の具体的な Supabase 側の修正が見つかれば、その範囲内で検討することができます。

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