バグバウンティープログラム
Capgoは、セキュリティと透明性に取り組んでいます。すべてのcodeは、オープンソースであり、セキュリティ研究者に、コードベース内の脆弱性を特定するために協力することを歓迎しています。
オープンソースCode
Capgo組織のすべてのリポジトリはオープンソースです。codeを確認、検査、そして貢献することができます。
GitHub組織 github.com/Cap-go
有効な報告の要件
バグバウンティプログラムに合格するには、次の要件をすべて満たす必要があります:
- 脆弱性が存在する GitHub リポジトリの正確なファイルと行番号を特定する必要があります
- 脆弱性が存在する GitHub リポジトリの __CAPGO_KEEP_1__ セキュリティアドバイザリに報告する必要があります
- 脆弱性とその潜在的な影響について明確な説明を含める必要があります
- 問題を示すための再現可能なステップを提供する必要があります
重要: GitHub の code の正確な行番号がわからない場合は、バグバウンティプログラムの対象外となります。 GitHub セキュリティアドバイザリのみで報告する必要があります。 Algora.io でアカウントを作成し、直接プラットフォームで支払いを受け取ることができます。
対応時間と敬意
私たちはフレンドリーで、有効な報告に対して支払いますが、時間を尊重しない人々と協力することはできません。 ため息が少なく、プログラムに従ってください。
- 24-72 時間以内にセキュリティレポートや侵害に対応します。
- 1 日に 3 つのメール以上送信するとスパムとみなされブロックされます。
- これらのルールを無視したりスパムであると判断したレポートに対しては報酬を支払いません。
- このバグバウティープログラムに従って報告したものに限り受け付けており、他のものはブロックされる可能性があります。
- ステータス更新の質問は避けてください。報告を受け取ったことを確認した後、それ以上のことは必要ありません。
重要: Capgoは小規模な起業家企業なので、ボーナス金額は大企業のプログラムよりも低くなります。報告された脆弱性の明確な攻撃パスがなければ、最大 30 ドルまで支払います。実際に Capgo に影響を与える、再現可能な攻撃が報告された場合、最大 300 ドルまで支払います。Capgo プラグインのセキュリティレポートを受け付けてレビューしていますが、code プラグインの有料ボーナスは、@capgo/capacitor-アップデーターに限定されています。Capgo プラグインは無料で使用でき、有料製品の範囲外なので、レポートはレビューされますが支払いはされません。支払いは、問題を特定し修正し、プルリクエストを開き、リリース後に修正が機能することを確認した後のみ行われます。このプロセスは通常 20-30 日かかります。支払いを要求するようなメッセージを送信してください。支払いはリリースが公開され、修正が機能することを確認した後のみ行われます。
レポート方法
- GitHubの関連リポジトリに移動してください
- Click on the "Security" tab
- Vulnerabilityを報告するには、"Security Advisoryを提出する"をクリックしてください
- 脆弱性が存在するファイルのパスと行番号を正確に記載してください
- 問題を再現するための詳細な手順と脆弱性の影響を説明してください
範囲外
- codeの行番号が正確に記載されていないGitHubの報告
- GitHubのSecurity Advisory経由で提出されていない報告
- 実証が不可能な脆弱性
- Capgoが直接修正できない第三者プラットフォーム、依存関係、またはサービス内のバグ(例えば、Supabaseに報告するなど)
- 社会工程攻撃またはフィッシング攻撃
- サービス拒否攻撃
- SSRFまたはDNSスパッフォッシング攻撃は、Webhookまたはサイトのプレビューに対して報告することはできません。これらの機能はサーバーレスインフラストラクチャ上で実行され、プライベートCapgoインフラストラクチャにアクセスすることはできません。
- 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と第三者サービス
Capgo が Supabase のプラットフォームまたはサービス バグである場合、Supabase に報告する。 Capgo に報告しない。 Capgo が作成したまたは選択した脆弱性のロジック、SQL、RPC、RLS ポリシー、エッジ関数、または構成がプロジェクト内で修正可能な場合、スコープ内です。 Supabase がエンドポイントを提供する場合でも。 Supabase の動作に関する発見については、再現可能なケースと、プロジェクトが ours のように設定されている場合にそれを防止するために必要な Supabase の設定または構成変更を含める。
例
ここでは有効ではありません
- Supabase のプラットフォーム バグ、ダウンタイム、または動作が __CAPGO_KEEP_0__ によって修正できるもの
- 再現できない問題
- Capgo が Supabase の動作を責める主張が Capgo が制御する修正または Supabase の設定/構成変更の具体的なものを示していない
ここでは有効
- Capgo が制御する Supabase のミス設定 (手順あり)
- Capgo が所有する SQL、RPC、RLS、関数、または統合問題が不安全な Supabase の使用を引き起こす
- A reproducible issue in CapgoのSupabaseプロジェクト、スキーマ、またはポリシー、即使それがSupabaseエンドポイントを通じて公開されている場合でも
既知のSupabase認証制限(既に報告)
ある発見は繰り返し報告され、Supabase Authのデフォルト設定またはプラットフォームの動作によるものではなく、Capgo codeによるものである。 これらの問題は、共有Supabaseデモプロジェクトで、設定が私たちのものと同じである場合にのみ、再現できる場合にのみ、レビューされます。 また、修正がSupabase側の設定変更であり、Capgoのセキュリティ規則の変更が必要ない場合にのみ、レビューされます。 ただし、修正がCapgo所有のSQL、RPC、RLSポリシー、関数、またはアプリロジックの変更が必要な場合、報告してください。 その場合、それは範囲内です。
- 再現可能なケースを提供し、正確な修正を特定する: または、Supabase設定/構成変更がSupabase動作問題を解決する場合、またはCapgo所有のcode/構成オブジェクトが変更する必要がある場合。
- メール確認の動作は、Supabase認証プロジェクトの設定に従うことが期待されます (例: メール確認が無効で、キャプチャベースの認証が使用されている場合)。
- パスワード更新とアカウント復元フローは、常に古いパスワードの再入力または再確認が必要ではない場合があります。 ただし、Supabase認証がそのように設定されている場合。
- 問題がこのリストに含まれている場合でも、提供されたプロジェクトまたは具体的なCapgo所有のセキュリティ欠陥で、具体的なSupabase側の修正を示すことができる場合は、範囲内と考慮できます。
Bug Bountyプログラムに関する質問については、GitHubセキュリティアドバイザリを通じてご連絡ください。