バグバウンティープログラム
Capgo は、セキュリティと透明性に取り組んでいます。すべての code は、オープンソースであり、セキュリティリサーチャーに、コードベースの脆弱性を特定するのを支援することを歓迎しています。
オープンソース Code
Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.
GitHub ご組織: github.com/Cap-go
有効な報告の要件
バグ・バウティー・プログラムに参加するには、次の要件をすべて満たす必要があります。
- GitHub リポジトリで脆弱性が存在するファイルと行番号を正確に特定する必要があります
- GitHub
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
重要: 問題が存在する場所の GitHub の code の正確な行を提供できない場合は、バグ・バウティー・プログラムの対象外となります。レポートは GitHub セキュリティ・アドバイザリーのみで提出してください。支払いは Algora.io で行われます。アカウントを作成してください。
対応時間と敬意
私たちは親切で、有効なレポートに対して支払いをしますが、時間を尊重しない人々と協力することはできません。コミュニケーションは冷静で、プログラムに従ってください。
- 24-72 時間以内にセキュリティレポートや侵害に対して対応します。
- 私たちにスパムを送らないでください。1 日に 3 つ以上のメールを送るとスパムとみなされ、ブロックされます。
- 規則を無視したレポートやスパムのレポートに対して支払いは行いません。
- このルールを遵守した、インスコープのレポートのみを受け付けます。そうでないレポートはブロックされます。
- ステータス更新の質問を避けてください。レポートを受け取ったことを確認した後、それ以上は必要ありません。レポートを確認する作業には数日かかる可能性があります。
重要: Capgoは、非常に小規模な起業家精神のある会社なので、ベントの金額は大企業のプログラムよりも低くなります。レポートのない明確なエクスプロイトパスは、最大$30まで支払われます。実際の、再現可能な影響を持つエクスプロイトは、Capgoの最大$300まで支払われます。Capgoプラグインのセキュリティレポートを受け付けてレビューしていますが、codeプラグインの有料ベントは、@capgo/capacitor-アップデーターに制限されています。Other Capgoプラグインは、有料製品の提供とは関係ありませんので、レポートはレビューされますが、支払いはされません。支払いは、問題を特定し、修正をリリースし、修正が機能することを確認した後のみ行われます。プルリクエストを開くかリンクするだけでは、支払いは認められません。このプロセスは、重大度とリリースのペースに応じて、数日から数週間かかります。支払いを得るようにメッセージを送るようにしないでください。支払いは、リリースが公開され、修正がテストされ、検証された後のみ行われます。
脆弱性報告の方法
- GitHubの関連リポジトリに移動してください
- セキュリティタブをクリックしてください
- 脆弱性を報告するボタンをクリックしてください
- 脆弱性が存在するファイルパスと行番号を含めてください
- 脆弱性の詳細な再現方法とセキュリティの影響を説明してください
範囲外
- バグバウンティの報告は、正確なcode行の参照が含まれていないGitHub
- GitHubのセキュリティアドバイザリ以外のレポート
- 実証的な脆弱性の証拠が存在しない理論的な脆弱性
- Capgoの第三者プラットフォーム、依存関係、またはサービス内のバグは、Capgoが直接修正できないため (アップストリームに報告するなど、Supabase などに報告する)。
- 社会的エンジニアリングまたはフィッシング攻撃
- サービス拒否攻撃
- SSRFまたはDNSスパッフの報告は、Webhookまたはサイトプレビューに対して行われます。これらの機能はサーバーレスインフラストラクチャ上で実行され、Capgoのプライベートインフラストラクチャに到達することはできません。したがって、Capgoの環境ではこれらの機能は利用できません。
- ユーザー所有のアプリケーションcodeまたはプロジェクトの構成は、Capgoが所有、配布、または制御していないため、capacitor.config.ts、config.capacitor.ts、ソースコードcode、および環境固有の設定など、ファイルを含む。
- Capgoのバンドルファイルへのアクセスまたはバンドルファイルがダウンロードできる証拠。バンドルファイルはパブリックウェブアセットであり、ユーザーはこれを知っており、バンドルファイルへのアクセスはデータ漏洩と見なされません。
- 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.
- アップローダーまたはUIが、外部_urlを介して配信されるバンドルに対して暗号化を誤ってラベル付けしている場合、Capgoのバグではありません (外部ホストされたバンドルの暗号化はCapgoの制御外です)。
Supabaseと第三者サービス
Supabaseプラットフォームまたはサービスにおけるバグの根本原因があれば、Supabaseに報告してください。Capgoではなく、Supabaseに報告してください。もしも脆弱性のあるロジック、SQL、RPC、RLSポリシー、エッジ関数、または設定がCapgoによって作成または選択され、そして私たちがプロジェクト内で修正できる場合は、Supabaseがエンドポイントを提供している場合でも範囲内です。Supabaseの動作に関する発見については、再現可能なケースと、プロジェクトの設定や構成変更がこれを防ぐようにするための、Supabaseの設定または構成変更を含めてください。
例
ここでは有効ではありません
- Supabaseプラットフォームのバグ、ダウンタイム、または動作が、Supabaseのみが修正できるもの
- 再現できない問題
- CapgoがSupabaseの動作を非難する主張ですが、Capgoが制御する修正や、Supabaseの設定または構成変更を示していません。
ここでは有効
- Capgoが制御するSupabaseのミス設定が、プロジェクトの設定で修正できるもの (手順あり)
- Capgoが所有するSQL、RPC、RLS、関数、または統合問題が、不正なSupabase使用を引き起こします
- CapgoのSupabaseプロジェクト、スキーマ、またはポリシーにおける再現可能な問題、どちらかがSupabaseエンドポイントを通じて公開されている場合
既知のSupabase認証制限 (既に報告済み)
サブパースのデフォルト設定またはプラットフォームの動作ではなく、Capgo codeによって引き起こされる報告される結果は何度も報告されます。 これらの結果は、共有サブパースのデモプロジェクトで再現できる場合にのみ、サブパースのデモプロジェクトで設定されたように設定され、Capgo セキュリティ規則の変更が必要でない場合にのみ、サブパース側の設定変更が必要です。 Capgo 所有の SQL、RPC、RLS ポリシー、関数、またはアプリロジックの修正が必要な場合、報告するようにしてください。 これは範囲内です。
- サブパースの設定または構成変更がサブパースの動作問題を解決する場合、または Capgo 所有の code /構成オブジェクトが変更する必要がある場合、再現可能なケースを提供し、正確な修正を特定してください。
- メール確認の動作は、サブパースの認証プロジェクト設定に従って期待されます (例えば、メール確認が無効でキャプチャベースの認証が使用されている場合)。
- パスワードの更新とアカウントの復元フローは、サブパースの認証がそのように設定されている場合には常に古いパスワードの再入力または再確認が必要ではありません。
- 問題がこのリストに含まれている場合でも、提供されたプロジェクトまたは提供された Capgo 所有のセキュリティ欠陥の具体的なサブパース側の修正を示すことができれば、範囲内と考慮することができます。
Bug Bounty プログラムに関する質問については、GitHub セキュリティアドバイザリを通じてご連絡ください。