バグバウンティープログラム
Capgoは、セキュリティと透明性に取り組んでいます。すべてのcodeは、オープンソースであり、セキュリティリサーチャーに、コードベースの脆弱性を特定するために協力してください。
オープンソース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_KEEP_0__のバグバウンティープログラムの要件
__CAPGO_KEEP_0__のバグバウンティープログラムに参加するには、次の要件をすべて満たす必要があります。
- GitHubのリポジトリ内の特定のファイルと行番号を特定する必要があります。
- GitHubのセキュリティーアドバイザリに、関連するリポジトリでGitHubを提出する必要があります。
- __CAPGO_KEEP_0__の脆弱性とその潜在的な影響について明確な説明を含める必要があります。
- __CAPGO_KEEP_0__の問題を再現可能なステップを提供する必要があります。
重要: codeのGitHubの特定の行番号を提供できない場合は、バグバウンティープログラムの対象外となります。GitHubセキュリティーアドバイザリのみで報告する必要があります。Algora.ioを通じて支払いが行われます。支払いを受け取るには、そこでアカウントを作成してください。
対応時間と敬意
私たちはフレンドリーで、有効な報告に対して支払いますが、時間を尊重しない人々と協力することはできません。報告の際は、感情を抑えてこのプログラムに従ってください。
- 24-72時間以内にセキュリティー報告と侵害に対応します。
- 私たちに迷惑をかけないでください。1日あたり3件以上のメールは迷惑メールとしてブロックされます。
- 報告がルールを無視したり迷惑メールである場合、報酬は支払われません。
- このバグ修正プログラムの範囲内に収まる報告のみを受け付けております。そうでないものはブロックされる可能性があります。
- 報告後、ステータスを確認するような質問（「チェックしてみたか？」など）を送るのはやめにしてください。報告を受け取ったことを確認した後は十分です。報告後、修正の準備に時間がかかります。プルリクエストの準備には数日かかる場合があります。
重要： 問題が発見され修正され、プルリクエストが作成され、修正がリリースされた後、修正が機能することを確認したあとにのみ、支払いが行われます。このプロセスは通常20から30日かかります。リリースが公開され、修正が機能することを確認したあとに支払いを求めるメッセージを送るのはやめにしてください。
報告方法
- Navigate to the relevant repository on GitHub
- __CAPGO_KEEP_0__の「セキュリティ」タブをクリックしてください。
- セキュリティアドバイザリーを作成するには、「セキュリティ」タブの「脆弱性を報告する」をクリックしてください。
- 脆弱性が存在するファイルパスと行番号を正確に記載してください。
- 問題を再現する手順と脆弱性のセキュリティ的影響を詳細に説明してください。
範囲外
- codeの精確なGitHub行参照が含まれていない報告
- GitHubセキュリティアドバイザリを通じて報告されていない報告
- 実証実験的な脆弱性
- 第三者プラットフォーム、依存関係、またはサービスでCapgoが直接修正できないバグ
- 社会的engineeringまたはフィッシング攻撃
- サービス拒否攻撃
Supabaseと第三者サービス
If the root cause is a Supabase platform or service bug, report it to Supabase, not Capgo. If the vulnerable logic, SQL, RPC, RLS policy, Edge Function, or configuration was created or chosen by Capgo and we can fix it in our project, it is in scope even when Supabase serves the endpoint. For findings about Supabase behavior itself, include a reproducible case and the exact Supabase setting or config change that prevents it in a project configured like ours.
例
ここでは有効ではありません
- Supabaseプラットフォームのバグ、ダウンタイム、または動作が__CAPGO_KEEP_0__が修正できるものではありません
- 再現できない問題
- CapgoがSupabaseの動作を非難する申し立てが、Capgoで修正された設定または正確なSupabase設定/構成変更を示していない
有効
- Capgoで管理されるSupabaseの構成ミスをプロジェクトの設定で修正できます (手順あり)
- Capgoが所有するSQL、RPC、RLS、関数、または統合問題が不正なSupabase使用を引き起こします
- CapgoのSupabaseプロジェクト、スキーマ、ポリシー内で再現可能な問題、即使それがSupabaseエンドポイントを介して公開されている場合
既知のSupabase認証制限 (既知の問題)
ある程度の問題は、Supabase Authのデフォルトまたはプラットフォームの動作によるものであり、Capgo codeによるものではないため、再現可能な場合にのみ確認します。修正がSupabase側の構成変更である場合、Capgoのセキュリティ規則を変更する必要がなく、Capgo所有のSQL、RPC、RLSポリシー、関数、またはアプリロジックを変更する必要がある場合、報告する必要があります。
- 再現可能なケースを提供し、正確な修正を特定してください: または、Supabaseの動作の問題を解決するためのSupabaseの設定/構成変更、またはCapgoが所有するcode/構成オブジェクト
- メール確認の動作は、Supabase Authプロジェクトの設定に従って期待されます (例えば、メール確認が無効でキャプチャベースの認証が使用されている場合)
- パスワードの更新とアカウントの回復フローは、Supabase Auth がそのように設定されている場合、常に古いパスワードの再入力または再検証が必要ではない場合があります。
- このリストにある問題ですが、提供されたプロジェクトまたは Capgo 所有のセキュリティ欠陥の具体的な Supabase 側の修正が示されている場合、スコープ内に考慮することができます。
Bug Bounty プログラムに関する質問は、GitHub セキュリティ アドバイザリを通じてお問い合わせください。