Program Hadiah Bug

Capgo berkomitmen untuk keamanan dan transparansi. Semua code kami adalah sumber terbuka, dan kami menyambut para peneliti keamanan untuk membantu kami mengidentifikasi kelemahan 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 Valid

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 Security Advisory pada 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 Tanggapan dan Hormat

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

• Kami akan merespons laporan keamanan dan insiden dalam waktu 24-72 jam.
• Jangan spam kami. Lebih dari tiga email dalam satu hari dianggap spam dan akan diblokir.
• Kami tidak membayar untuk laporan yang melanggar aturan ini atau spam.
• Hanya laporan yang relevan dan mengikuti program bug bounty ini yang diterima; apapun yang lain mungkin diblokir.
• Jangan bertanya tentang status update seperti "apakah Anda telah memeriksa?" atau pertanyaan serupa. Setelah kami mengonfirmasi bahwa laporan Anda telah diterima, 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 yang relevan di GitHub
2. Klik pada tab "Keamanan"
3. Klik "Laporkan kelemahan" untuk membuat advisory keamanan baru
4. Termasuk jalur file dan nomor baris yang tepat di mana kelemahan tersebut ada
5. Berikan langkah-langkah yang rinci untuk mereproduksi masalah dan jelaskan dampak keamanan

Luar Lingkup

• Laporan tanpa referensi baris code yang tepat di GitHub
• Laporan yang tidak disampaikan melalui GitHub Advisory Keamanan
• Kelemahan teoretis tanpa bukti konsep
• Bugs pada platform, dependensi, atau layanan pihak ketiga yang Capgo tidak dapat memperbaiki secara langsung (laporkan ke atas, misalnya ke Supabase)
• Upaya sosial atau serangan phising
• Serangan layanan penolakan
• Laporan SSRF atau DNS spoofing terhadap webhook atau pratinjau situs web. Fitur-fitur ini berjalan di infrastruktur serverless dan tidak dapat digunakan untuk mencapai infrastruktur Capgo pribadi, sehingga tidak dapat dimanfaatkan dalam lingkungan kami.
• Konfigurasi aplikasi atau proyek milik pengguna code yang Capgo tidak miliki, kirim, atau kendalikan, termasuk file seperti capacitor.config.ts, config.capacitor.ts, sumber kode 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.

Supabase dan Layanan Pihak Ketiga

Jika penyebab utama adalah bug atau kesalahan layanan Supabase, laporkan ke Supabase, bukan ke Capgo. Jika logika yang rentan, SQL, RPC, kebijakan RLS, fungsi Edge, atau pengaturan diciptakan atau dipilih oleh Capgo dan kami dapat memperbaikinya dalam 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 dikonfigurasi seperti kami.

Contoh

Beberapa temuan yang sering dilaporkan dan disebabkan oleh pengaturan default Supabase Auth atau perilaku platform bukan karena kesalahan __CAPGO_KEEP_0__ __CAPGO_KEEP_1__. Kami hanya memeriksa masalah ini ketika masalah tersebut dapat diulang-ulang di proyek demo Supabase yang dapat dibagi seperti kami dan ketika perbaikan yang diperlukan adalah perubahan pengaturan Supabase yang tidak memerlukan perubahan aturan keamanan __CAPGO_KEEP_2__. Jika perbaikan yang diperlukan adalah perubahan SQL, RPC, kebijakan RLS, fungsi, atau logika aplikasi yang dimiliki oleh __CAPGO_KEEP_3__, laporkanlah kepada kami karena itu dalam lingkup.

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.

• Provide a reproducible case and identify the exact fix: either the Supabase setting/config change that resolves a Supabase behavior issue, or the Capgo-owned code/config object that must change.
• Alur pembaruan kata sandi dan alur pemulihan akun mungkin tidak selalu memerlukan pengulangan kata sandi lama atau pengulangan verifikasi jika Supabase Auth dikonfigurasi seperti itu.
• __CAPGO_KEEP_0__
• Jika masalahnya ada dalam daftar ini tetapi Anda dapat menampilkan solusi konkrit dari sisi Supabase dalam proyek yang disediakan atau defek keamanan yang dimiliki Capgo, kita dapat mempertimbangkannya dalam lingkup.

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