Program Hadiah Bug

Capgo berkomitmen pada keamanan dan transparansi. Semua code kami adalah sumber terbuka, dan kami menyambut para peneliti keamanan untuk membantu kami mengidentifikasi kerentanan dalam basis kode kami.

Sumber Terbuka Code

Setiap repositori di organisasi Capgo adalah sumber terbuka. Anda dapat memeriksa, mengaudit, dan berkontribusi pada code kami.

Organisasi GitHub: github.com/Cap-go

Persyaratan untuk Laporan yang Sah

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

• Anda harus mengidentifikasi file dan nomor baris yang tepat di repositori GitHub di mana kelemahan tersebut ada
• Laporan Anda harus disampaikan melalui GitHub Advisory Keamanan di repositori yang relevan
• Anda harus mencantumkan deskripsi yang jelas tentang kelemahan dan potensi dampaknya
• Anda harus menyediakan langkah-langkah yang dapat diulang untuk menunjukkan masalah tersebut

Waktu Respons dan Hormat

Kami ramah dan kami membayar laporan yang valid, tetapi kami tidak dapat bekerja dengan orang-orang yang tidak menghormati waktu kami. Silakan menjaga komunikasi tetap tenang dan ikuti program ini.

• Kami akan merespons laporan keamanan dan pelanggaran dalam waktu 24-72 jam.
• Tidak spam kami. Lebih dari tiga email dalam satu hari dianggap spam dan akan diblokir.
• Kami tidak membayar laporan yang melanggar aturan-aturan ini atau spam.
• Hanya laporan yang sesuai dengan program bug bounty ini yang diterima; apapun yang lain mungkin diblokir.
• Tidak bertanya status update seperti "apakah Anda telah memeriksa?" atau pertanyaan serupa. Setelah kami mengkonfirmasi bahwa kami telah menerima laporan Anda, itu sudah cukup. Setelah itu, masih ada pekerjaan yang signifikan untuk dilakukan, dan membuat pull request dapat memakan waktu beberapa hari.

Cara Melaporkan

1. Navigasikan ke repositori relevan di GitHub
2. Klik tab "Keamanan"
3. Klik "Laporkan kelemahan" untuk membuat advisory keamanan baru
4. Termasuk jalur file dan nomor baris yang tepat di mana kelemahan ada
5. Berikan langkah-langkah detail untuk mengulangi masalah dan jelaskan dampak keamanan

Luar Jangkauan

• Laporan tanpa referensi garis code yang tepat di GitHub
• Laporan yang tidak disampaikan melalui GitHub Advisory Keamanan
• Kelemahan teori tanpa bukti konsep
• Bugs di dalam platform, dependensi, atau layanan pihak ketiga yang Capgo tidak dapat memperbaiki secara langsung (laporkan ke atas, misalnya ke Supabase).
• Pengusaha sosial atau upaya penipuan
• Pengusaha jasa layanan
• SSRF atau palsu DNS laporan terhadap webhook atau tampilan website. Fitur-fitur ini berjalan di infrastruktur serverless dan tidak dapat digunakan untuk mencapai infrastruktur Capgo pribadi, sehingga mereka tidak dapat dimanfaatkan dalam lingkungan kami.
• Konfigurasi aplikasi atau proyek milik pengguna code atau proyek yang Capgo tidak miliki, kirim, atau kendalikan, termasuk file seperti capacitor.config.ts, config.capacitor.ts, sumber aplikasi code, dan pengaturan spesifik lingkungan.
• Akses ke file-file Capgo bundle atau bukti bahwa file-file bundle dapat diunduh. File-file bundle adalah aset web publik, pengguna diinformasikan tentang hal ini, dan akses ke mereka tidak dianggap sebagai pelanggaran data.
• Plugin/API endpoint Capgo yang tidak terotentikasi yang sengaja terbuka oleh desain — termasuk channel_self set dan update/stats endpoint yang tidak memerlukan kunci API — tidak dianggap sebagai kerentanan. Jangan laporkan mereka sebagai kerentanan.
• Pengunggah atau UI yang salah labelkan enkripsi untuk bundle yang disajikan melalui external_url tidak dianggap sebagai kerentanan Capgo (enkripsi bundle yang dihosting secara eksternal di luar kendali Capgo).

Supabase dan Layanan Pihak Ketiga

Jika penyebab utama adalah bug platform atau layanan Supabase, laporkan ke Supabase, bukan Capgo. Jika logika yang rentan, SQL, RPC, kebijakan RLS, fungsi Edge, atau konfigurasi dibuat atau dipilih oleh Capgo dan kami dapat memperbaikinya di proyek kami, maka itu dalam lingkup bahkan ketika Supabase menyajikan endpoint. Untuk temuan tentang perilaku Supabase sendiri, termasuk kasus yang dapat diulang dan pengaturan Supabase yang tepat atau perubahan konfigurasi yang mencegahnya dalam proyek yang disesuaikan dengan kami.

Contoh

Keterbatasan Autentikasi Supabase yang Dikenal (Sudah Dilaporkan)

Some findings are repeatedly reported and are caused by Supabase Auth defaults or platform behavior rather than Capgo code. We review these only when they can be reproduced in a shared Supabase demo project configured like ours and when the fix is a Supabase-side configuration change that does not require changing Capgo security rules. If the fix requires changing Capgo-owned SQL, RPCs, RLS policies, functions, or app logic, report it to us because that is in scope.

• Berikan kasus yang dapat direproduksi dan identifikasi perbaikan yang tepat: baik pengaturan Supabase yang mengatasi masalah perilaku Supabase atau objek konfigurasi Capgo-milik code/konfigurasi yang harus berubah.
• Tindakan verifikasi email diharapkan mengikuti pengaturan project Supabase Auth (misalnya, apakah konfirmasi email diaktifkan dan apakah autentikasi berbasis tangkapan digunakan).
• Fluktuasi perbarui kata sandi dan alur pemulihan akun mungkin tidak selalu memerlukan pengulangan kata sandi lama atau verifikasi ulang jika Supabase Auth dikonfigurasi demikian.
• Jika masalah ada dalam daftar ini tetapi Anda dapat menunjukkan perbaikan konkrit Supabase sisi dalam proyek yang disediakan atau defek keamanan konkrit Capgo-milik, kami dapat mempertimbangkannya dalam lingkup.

Untuk pertanyaan tentang program Bug Bounty kami, silakan menghubungi kami melalui GitHub Security Advisories.