Program Bug Bounty

Capgo berkomitmen terhadap keamanan dan transparansi. Seluruh code kami open source, dan kami mengundang peneliti keamanan untuk membantu mengidentifikasi kerentanan di codebase kami.

Code Open Source

Setiap repositori di organisasi Capgo bersifat open source. Anda dapat meninjau, mengaudit, dan berkontribusi pada code kami.

Organisasi GitHub: github.com/Cap-go

Syarat Laporan yang Valid

Agar memenuhi syarat program Bug Bounty, laporan Anda harus memenuhi SEMUA persyaratan berikut:

• Anda harus mengidentifikasi file dan nomor baris yang tepat di repositori GitHub kami tempat kerentanan berada
• Laporan Anda harus dikirim melalui GitHub Security Advisory pada repositori terkait
• Anda harus menyertakan deskripsi yang jelas mengenai kerentanan dan potensi dampaknya
• Anda harus memberikan langkah-langkah reproduksi untuk menunjukkan masalah tersebut

Waktu Respons dan Rasa Hormat

Kami ramah dan kami memang membayar laporan yang valid, tetapi kami tidak bisa bekerja sama dengan orang yang tidak menghargai waktu kami. Mohon jaga komunikasi tetap tenang dan ikuti program ini.

• Kami merespons laporan keamanan dan pelanggaran dalam waktu 24-72 jam.
• Jangan spam kami. Mengirim lebih dari tiga email dalam satu hari akan dianggap sebagai spam dan akan diblokir.
• Kami tidak membayar laporan yang mengabaikan aturan ini atau yang spam.
• Hanya laporan in-scope yang mengikuti program bug bounty ini yang diterima; selain itu dapat diblokir.
• Jangan menanyakan status seperti "sudah dicek belum?" atau pertanyaan serupa. Setelah kami mengonfirmasi laporan Anda sudah diterima, itu sudah cukup. Setelah itu, masih ada banyak pekerjaan yang harus dilakukan, dan menyiapkan pull request bisa memakan waktu beberapa hari.

Cara Melapor

1. Buka repositori terkait di GitHub
2. Klik tab "Security"
3. Klik "Report a vulnerability" untuk membuat security advisory baru
4. Sertakan path file dan nomor baris persis tempat kerentanan berada
5. Berikan langkah-langkah detail untuk mereproduksi masalah dan jelaskan dampak keamanannya

Di Luar Cakupan

• Laporan tanpa referensi baris code yang tepat di GitHub
• Laporan yang tidak dikirim melalui GitHub Security Advisory
• Kerentanan teoretis tanpa proof of concept
• Bug pada platform pihak ketiga, dependensi, atau layanan yang tidak bisa diperbaiki langsung oleh Capgo (laporkan ke upstream, misalnya ke Supabase).
• Social engineering atau upaya phishing
• Serangan denial of service
• Laporan SSRF atau DNS spoofing terhadap webhook atau preview website. Fitur-fitur ini berjalan di infrastruktur serverless dan tidak dapat digunakan untuk mengakses infrastruktur privat Capgo, sehingga tidak dapat dieksploitasi di lingkungan kami.
• Aplikasi code atau konfigurasi proyek milik pengguna yang tidak dimiliki, tidak dirilis, atau tidak dikontrol oleh Capgo, termasuk file seperti capacitor.config.ts, config.capacitor.ts, source aplikasi code, dan pengaturan khusus environment.
• Akses ke file bundle Capgo atau bukti bahwa file bundle dapat diunduh. File bundle adalah aset web publik, pengguna telah diinformasikan soal ini, dan akses ke file tersebut tidak dianggap sebagai kebocoran data.
• Endpoint plugin Capgo/API tanpa autentikasi yang memang sengaja publik — termasuk set channel_self dan endpoint update/stats yang tidak memerlukan API key — bukanlah kerentanan. Jangan laporkan sebagai kerentanan.
• Uploader atau UI yang salah melabeli enkripsi untuk bundle yang disajikan via external_url bukan merupakan kerentanan Capgo (enkripsi bundle yang dihosting secara eksternal berada di luar kendali Capgo).

Supabase dan Layanan Pihak Ketiga

Jika akar masalahnya adalah bug platform atau layanan Supabase, laporkan ke Supabase, bukan ke Capgo. Jika logika, SQL, RPC, kebijakan RLS, Edge Function, atau konfigurasi yang rentan dibuat atau dipilih oleh Capgo dan kami dapat memperbaikinya di proyek kami, maka hal tersebut masuk dalam scope meskipun Supabase yang menyajikan endpoint-nya. Untuk temuan terkait perilaku Supabase itu sendiri, sertakan kasus yang dapat direproduksi serta pengaturan atau perubahan konfigurasi Supabase spesifik yang mencegahnya pada proyek yang dikonfigurasi seperti milik kami.

Contoh

Batasan Supabase Auth yang Diketahui (Sudah Dilaporkan)

Beberapa temuan dilaporkan berulang kali dan disebabkan oleh default Supabase Auth atau perilaku platform, bukan karena Capgo code. Kami hanya meninjau temuan tersebut jika dapat direproduksi dalam proyek demo Supabase yang dikonfigurasi seperti milik kami, dan jika perbaikannya berupa perubahan konfigurasi di sisi Supabase yang tidak memerlukan perubahan aturan keamanan Capgo. Jika perbaikan memerlukan perubahan SQL, RPC, kebijakan RLS, fungsi, atau logika aplikasi milik Capgo, silakan laporkan kepada kami karena hal tersebut masuk dalam scope.

• Berikan kasus yang dapat direproduksi dan identifikasi perbaikan pastinya: baik itu perubahan setting/konfigurasi Supabase yang menyelesaikan masalah perilaku Supabase, atau objek code/config milik Capgo yang harus diubah.
• Perilaku verifikasi email akan mengikuti pengaturan proyek Supabase Auth Anda (misalnya, apakah konfirmasi email dinonaktifkan dan menggunakan capture-based auth).
• Alur pembaruan kata sandi dan pemulihan akun mungkin tidak selalu memerlukan input ulang kata sandi lama atau verifikasi ulang jika Supabase Auth dikonfigurasi demikian.
• Jika masalah ada dalam daftar ini tetapi Anda dapat menunjukkan perbaikan konkret di sisi Supabase pada proyek yang disediakan atau cacat keamanan konkret milik Capgo, kami dapat mempertimbangkannya masuk dalam scope.

Untuk pertanyaan mengenai program Bug Bounty kami, silakan hubungi melalui GitHub Security Advisories kami.