バグバウンティプログラム
Capgo はセキュリティと透明性に取り組んでいます。当社の code はすべてオープンソースで、コードベースの脆弱性特定にご協力いただけるセキュリティ研究者を歓迎します。
オープンソースの Code
Capgo 組織内のすべてのリポジトリはオープンソースです。当社の code をレビュー、監査、コントリビュートできます。
GitHub 組織: github.com/Cap-go
Capgo バックエンド & ランディング
Capgo のバックエンドおよびプロダクトリポジトリ (capgo.app API、dashboard、および関連サービス)
有効な報告の要件
バグバウンティプログラムの対象となるには、報告が以下の要件をすべて満たしている必要があります。
- 脆弱性が存在する GitHub リポジトリ内の正確なファイルと行番号を特定してください
- 報告は必ず、該当するリポジトリの GitHub Security Advisory を通じて提出してください
- 脆弱性の明確な説明と想定される影響を必ず含めてください
- 問題を再現する手順を必ず提供してください
重要： 問題が存在する GitHub 内の code の正確な行を提示できない場合、その報告は Bug Bounty プログラムの対象外となります。報告は GitHub Security Advisory 経由でのみ受け付けます。支払いは Algora.io で処理されます。プラットフォーム上で直接支払えるよう、Algora.io でアカウントを作成してください。
対応時間とマナー
私たちはフレンドリーで、有効な報告には報酬を支払いますが、私たちの時間を尊重しない方とは協力できません。冷静にコミュニケーションし、本プログラムに従ってください。
- セキュリティ報告と侵害には24〜72時間以内に対応します。
- スパムは送らないでください。1日に3通を超えるメールはスパムとみなし、ブロックします。
- これらのルールを無視した報告やスパムには報酬を支払いません。
- 本 Bug Bounty プログラムに従った対象範囲内の報告のみ受け付けます。それ以外はブロックされる場合があります。
- 「確認しましたか？」のような進捗確認の連絡は不要です。レポートを受け取ったことを確認できれば、それで十分です。その後もやるべき作業は多く残っており、プルリクエストの準備には数日かかることがあります。
重要： Capgo は自己資金で運営する小さな会社のため、賞金額は大手企業のプログラムより低めです。明確なエクスプロイトパスがないレポートへの支払いは最大30ドルまでです。Capgo に実際に再現可能な影響を与えるエクスプロイトには最大300ドルまで支払います。Capgo プラグインのセキュリティレポートも受け付けて調査しますが、プラグイン code の賞金は @capgo/capacitor-updater. に限定されます。その他の Capgo プラグインは無料で利用でき、有料製品には含まれないため、レポートは調査しますが報酬は支払われません。お支払いは、問題の特定、修正版のリリース、そしてリリース後に修正が機能することをご自身で確認いただいた後に行われます。プルリクエストを作成したりリンクを貼ったりするだけでは支払い対象になりません。このプロセスには通常、深刻度やリリース頻度に応じて数日から数週間かかります。「支払いを受けたい」といったメッセージは送らないでください。支払いはリリースが公開され、修正をテストして検証できた後にのみ行われます。
報告方法
- GitHub 上の該当するリポジトリに移動してください
- 「Security」タブをクリックします
- 「Report a vulnerability」をクリックして、新しいセキュリティアドバイザリを作成します
- 脆弱性が存在する正確なファイルパスと行番号を含めてください
- 問題の再現手順を詳細に記載し、セキュリティへの影響を説明してください
スコープ外
- GitHub 内の正確な code 行番号の記載がないレポート
- GitHub Security Advisory を通じて提出されていないレポート
- PoC（概念実証）のない理論上の脆弱性
- サードパーティのプラットフォーム、依存関係、または Capgo が直接修正できないサービスに関するバグ（Supabase など、アップストリームへの報告をお願いします）
- ソーシャルエンジニアリングまたはフィッシング行為
- DoS（サービス拒否）攻撃
- webhookやウェブサイトプレビューに対するSSRFやDNSスプーフィングの報告。これらの機能はサーバーレスインフラ上で動作しており、プライベートな Capgo インフラへの到達には使えないため、当社の環境では悪用できません。
- ユーザーが所有するアプリケーションの code やプロジェクト設定で、Capgo が所有・提供・管理していないもの。capacitor.config.ts、config.capacitor.ts、アプリのソースコード code、環境固有の設定などのファイルが含まれます。
- Capgo のbundleファイルへのアクセス、またはbundleファイルがダウンロード可能であることの証明。bundleファイルは公開されたWebアセットであり、その旨はユーザーに周知されているため、アクセスはデータ漏洩とはみなされません。
- 設計上意図的に公開されている、認証不要の Capgo プラグインや API エンドポイント（API キーを必要としないchannel_selfの設定やupdate/statsエンドポイントなど）は脆弱性ではありません。脆弱性として報告しないでください。
- external_url 経由で配信される bundle の暗号化について Uploader または UI が誤って表示することは、Capgo の脆弱性には該当しません（外部でホストされている bundle の暗号化は Capgo の制御外です）。
Supabase とサードパーティサービス
根本的な原因が Supabase プラットフォームまたはサービスのバグである場合は、Capgo ではなく Supabase に報告してください。脆弱性のあるロジック、SQL、RPC、RLS ポリシー、Edge Function、または設定が Capgo によって作成または選択されたものであり、当社のプロジェクト内で修正可能な場合は、Supabase がエンドポイントを提供している場合でも対象となります。Supabase の挙動自体に関する報告には、再現可能なケースと、当社と同様に構成されたプロジェクトでその挙動を防ぐ正確な Supabase 設定または構成変更を含めてください。
例
対象外
- Supabase プラットフォームのバグ、障害、または Supabase 側でしか修正できない挙動
- 再現できない報告
- Capgo 側で制御できる修正や、正確な Supabase の設定・構成変更を示さずに、Supabase の挙動を Capgo のせいにする主張
対象内
- 当社のプロジェクト設定で修正できる（手順付き）、Capgo が制御する Supabase の設定ミス
- Capgo が所有する SQL、RPC、RLS、関数、または統合に関する問題で、安全でない Supabase の利用を招くもの
- Supabase のエンドポイント経由で公開されている場合でも、Capgo の Supabase プロジェクト、スキーマ、またはポリシーにおける再現可能な問題
既知のSupabase Authの制限事項（報告済み）
一部の報告は、Capgo や code ではなく、Supabase Authのデフォルト設定やプラットフォームの挙動に起因するものが繰り返し報告されています。これらは、当社の構成と同様のSupabaseデモプロジェクトで再現可能であり、かつ、Capgo のセキュリティルールを変更せずにSupabase側の設定変更のみで解決できる場合に限り、検討対象とします。もし解決に Capgo 所有のSQL、RPC、RLSポリシー、関数、またはアプリロジックの変更が必要な場合は、当社のスコープ内となりますので、ぜひ報告してください。
- 再現手順を提示し、正確な修正方法を特定してください。具体的には、Supabaseの挙動問題を解決するためのSupabaseの設定・構成変更、または変更が必要な Capgo 所有の code/config オブジェクトを明示してください。
- メール認証の挙動は、Supabase Authプロジェクトの設定（例：メール確認の無効化やキャプチャベースの認証の使用など）に従う仕様となっています。
- Supabase Authの設定によっては、パスワード更新やアカウント復旧のフローにおいて、旧パスワードの再入力や再認証が常に必要とは限りません。
- 問題がこのリストに含まれていても、提供されたプロジェクト内でSupabase側の具体的な修正方法を示せる場合、あるいは Capgo 所有の具体的なセキュリティ欠陥であることが証明できる場合は、スコープ内として検討いたします。
Bug Bountyプログラムに関するお問い合わせは、GitHub Security Advisories までご連絡ください。