バグバウンティープログラム
Capgoは、セキュリティと透明性に取り組んでいます。すべてのcodeは、オープンソースであり、セキュリティ研究者に、コードベース内の脆弱性を特定するために協力することを歓迎しています。
オープンソースCode
Capgo組織のすべてのリポジトリはオープンソースです。codeを確認、検査、そして貢献することができます。
GitHub組織 github.com/Cap-go
Capgoバックエンド & ランディング
Capgoの主なリポジトリ、バックエンドサービス、そしてランディングウェブサイト
Capacitor Updater Plugin
Capacitorのオーバー・ザー・アイルアップデートを管理するコアプラグイン
バグバウンティプログラムで有効な報告の要件
バグバウンティプログラムで有効な報告になるには、次の要件をすべて満たす必要があります:
- あなたは、脆弱性が存在するGitHubリポジトリの特定のファイルと行番号を特定する必要があります
- あなたの報告は、関連するリポジトリのGitHubセキュリティアドバイザーよりも提出する必要があります
- あなたは、脆弱性とその潜在的な影響について明確な説明を含める必要があります
- あなたは、問題を示すための再現可能なステップを提供する必要があります
重要な注意事項： code の GitHub の正確な行を提供できない場合は、バグバウンティプログラムの申請は受け付けられません。セキュリティアドバイザリのみを通じて GitHub への報告を提出する必要があります。Algora.io でアカウントを作成し、直接プラットフォームで支払いを受け取ることができます。
対応時間と敬意
私たちはフレンドリーで有効な報告に対して支払いを行いますが、時間を尊重しない人々と協力することはできません。報告の際は、感情を抑え、以下のプログラムに従ってください。
- 24-72 時間以内にセキュリティレポートと侵害に対処します。
- 私たちにスパムを送らないでください。1 日に 3 つのメール以上送るとスパムとしてブロックされます。
- 有効な報告に対して支払いを行うことはできますが、ルールを無視した報告やスパムは支払いしません。
- このバグバウンティプログラムに従った、スコープ内でのみ報告を受け付けます。
- 報告の際は、ステータス更新の質問を避けてください。たとえば、「確認してみたか？」などの質問は避けてください。報告を受け取ったことを確認した後、それ以上のことは行っていません。
重要な注意事項： Capgoは小規模な起業家企業であるため、ボーナス金額は大企業のプログラムよりも低くなります。明確な攻撃パスが存在しない報告は最大$30まで支払われます。実際の、再現可能な影響を持つCapgoに対する攻撃は最大$300まで支払われます。Capgoプラグインのセキュリティ報告を受け付けてレビューしていますが、codeプラグインの有料ボーナスは@capgo/capacitor-アップデーターの範囲内に限定されています。Capgoプラグインは無料で使用でき、有料製品の範囲外であるため、報告はレビューされますが支払われません。問題を特定し、修正し、プルリクエストを開き、リリース後、修正が機能することを確認するまで、支払いは発行されません。このプロセスは通常20から30日かかります。リリースが公開され、修正が機能することを確認するまで、支払いが発生することを確認しないでください。
セキュリティ報告の方法
- GitHubにアクセスし、関連するリポジトリに移動
- セキュリティタブをクリック
- 新しいセキュリティアドバイザリを作成するには、"セキュリティ報告"をクリック
- 脆弱性が存在するファイルパスと行番号を正確に記載
- 詳細な再現方法とセキュリティの影響を説明
範囲外
- Reports without exact code line references in GitHub
- Reports not submitted through GitHub Security Advisory
- __CAPGO_KEEP_0__のセキュリティアドバイザリを通じて報告しない報告
- Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
- 社会的エンジニアリングまたはフィッシング攻撃
- サービス拒否攻撃
- SSRFまたはDNSスパッフォッシングの報告は、Webhookまたはサイトのプレビューに対して行われます。これらの機能はサーバーレスインフラストラクチャ上で実行され、プライベートCapgoインフラストラクチャにアクセスすることはできません。したがって、環境内ではこれらの機能は利用できません。
- ユーザー所有のアプリケーションcodeまたはプロジェクトの構成がCapgoが所有、配送、または制御していない、ファイルなどcapacitor.config.ts、config.capacitor.ts、アプリケーションソースcode、および環境固有の設定。
- Capgoバンドルファイルへのアクセスまたはバンドルファイルがダウンロードできる証拠。バンドルファイルはパブリックウェブアセットであり、ユーザーはこれを知っており、バンドルファイルへのアクセスはデータ漏洩と見なされません。
Supabaseとサードパーティサービス
Capgoに報告するのではなく、Supabaseプラットフォームまたはサービスバグの場合は、Supabaseに報告してください。Capgoが作成または選択した脆弱なロジック、SQL、RPC、RLSポリシー、エッジ関数、または構成がプロジェクト内で修正できる場合は、Supabaseがエンドポイントを提供している場合でも範囲内です。Supabaseの動作に関する情報については、再現可能なケースとSupabaseの設定または構成変更を含めてください。
例
範囲外
- Supabaseプラットフォームのバグ、ダウンタイム、またはSupabaseのみが修正できる動作
- 再現できない発見
- CapgoがSupabaseの動作を責めるのは不正解であり、Capgoが制御する修正またはexact Supabaseの設定/構成変更を示す必要があります。
有効です
- プロジェクト設定 (手順) で修正できる Capgo が管理する Supabase の不正設定
- Capgo が所有する SQL、RPC、RLS、関数、または統合問題が不正な Supabase 使用を引き起こします
- Capgo の Supabase プロジェクト、スキーマ、ポリシー内で再現可能な問題、即使それが Supabase エンドポイントを通じて公開されている場合
既知の Supabase Auth 制限事項 (既に報告済み)
ある程度の特定の問題は、 Capgo の code のせいではなく、Supabase Auth のデフォルト設定またはプラットフォームの動作によるものです。 これらの問題は、共有 Supabase DEMO プロジェクトで設定が ours と同じで、修正が Supabase 側の設定変更である場合にのみ確認します。 ただし、 Capgo のセキュリティ規則の変更が必要な場合、修正が Capgo 所有の SQL、RPC、RLS ポリシー、関数、またはアプリロジックの変更である場合、報告してください。 その場合、それは範囲内です。
- 再現可能なケースを提供し、正確な修正を特定してください: または、Supabase の設定/構成変更が Supabase の動作問題を解決する場合、または Capgo 所有の code /構成オブジェクトが変更する必要がある場合
- Email 検証の動作は、Supabase Auth プロジェクト設定に従うことが期待されます (たとえば、Email 確認が無効でキャプチャベースの認証が使用されている場合)
- パスワード更新とアカウント復元フローは、Supabase Auth がそのように設定されている場合には、常に古いパスワードの再入力または再検証が必要ではない場合があります
- このリストに問題があるが、提供されたプロジェクトまたはCapgo所有のセキュリティ欠陥の具体的なSupabase側の修正を示すことができれば、その範囲内で検討することができます。
Bug Bountyプログラムに関する質問については、GitHubセキュリティアドバイザリを通じてご連絡ください。