Apa praktik terbaik untuk menangani PR yang menangani kerentanan keamanan dalam repo publik?

Bagaimana seharusnya proyek sumber terbuka dengan repositori publik menangani permintaan tarikan (PR) terbaik yang menangani dengan aman dilaporkan tetapi belum secara terbuka mengungkapkan kerentanan keamanan?

Saya terlibat dalam proyek sumber terbuka dengan beberapa ratus kontributor. Kami mempublikasikan pemberitahuan keamanan dan kerentanan beberapa kali setahun sebagai bagian dari rilis bulanan yang dijadwalkan secara rutin. Kami tidak mempublikasikan informasi tentang kerentanan sampai kami membuat versi tambalan tersedia. Kami dapat mengelola masalah keamanan dengan aman di sistem manajemen proyek kami (JIRA). Tetapi kami belum memiliki proses yang baik untuk mengaburkan PR yang memperbaiki kerentanan keamanan saat mereka dikirimkan ke GitHub. Kami khawatir orang-orang dapat menemukan perbaikan ini sebelum dirilis dan membuat eksploitasi nol hari.

Kami telah mempertimbangkan untuk menggunakan repo pribadi yang menggunakan repo utama, tetapi banyak dari kami saat ini meninjau dan alur kerja QA terjadi pada PR. Jika kami memindahkan alur kerja ke tim keamanan hanya repo pribadi, itu akan mengurangi jendela ketika perbaikannya publik hingga jam yang dibutuhkan untuk menghasilkan tarball dan mempublikasikannya di sourceforge, yang akan menjadi perbaikan besar. Kami juga kemungkinan harus menghindari menggabungkan PR ke dalam beta publik kami.

Sebelum pergi ke arah itu, saya ingin tahu apa praktik terbaik untuk menangani patch perbaikan bug keamanan pra-rilis dalam proyek open source dengan repo terbuka? Jika masalahnya dapat diatasi dengan menggunakan platform yang berbeda dari GitHub, saya harus menyebutkan kami sedang mengevaluasi migrasi ke GitLab.

— Joe Murray
sumber

Saya tidak yakin apakah ada pengaturan praktik terbaik. GitLab pada dasarnya adalah GitHub pribadi. Menyeimbangkan masalah open source dan perbaikan keamanan tidak mudah. Berapa banyak perbaikan keamanan Anda yang berasal dari orang-orang yang bukan dari tim keamanan Anda?

— Berin Loritsch

Sebagian besar masalah dilaporkan oleh orang lain, tetapi mungkin kurang dari seperlima dari perbaikan berasal dari mereka yang bukan dari tim keamanan.

— Joe Murray

Menurut pendapat saya, jika Anda memerlukan beberapa bagian dari proses Anda untuk menjadi pribadi, maka itu harus dilakukan di luar GitHub (karena GH adalah publik); setelah bagian spesifik ini selesai dan semua orang meninjau kodenya; Anda dapat membuat PR tentang GH yang akan digabungkan secepat mungkin, hanya untuk 'kembali' ke proses resmi. Anda bisa menggunakan alat lain untuk mengelola pengecualian tersebut dalam proses.

— Emerson Cardoso

Pengungkapan langsung sepenuhnya (yaitu pengungkapan publik tanpa penundaan) adalah hal yang sah untuk dilakukan.

— Miles Rout

Pertanyaan ini tampaknya mengasumsikan bahwa, selama masalah keamanan tidak diungkapkan oleh tim, itu tidak diketahui dunia. Itu tidak benar; setiap masalah keamanan yang ditemukan harus diasumsikan diketahui oleh seseorang dengan niat buruk di suatu tempat. Sekarang, jika Anda berasumsi bahwa orang lain sudah tahu tentang masalah ini dan mungkin mengeksploitasinya, Anda tidak dapat lagi menunda rilis perbaikan hingga rilis bulanan rutin Anda. Anda harus melepaskan ASAP. Itu berarti tidak ada masalah dengan mengikuti aliran PR biasa. Hanya PR terhadap cabang rilis terbaru, gabungkan, beri tag, lepaskan.

— Jory Geerts

Protokol untuk ini adalah untuk menentukan faktor risiko dalam menunjukkan kerentanan secara publik. Untuk masalah keamanan apa pun, PR tersebut harus berada dalam repo pribadi yang hanya dapat dilihat oleh tim keamanan Anda. Ini berdiri terlepas dari platform yang Anda gunakan untuk memproduksi dan menindaklanjuti Permintaan Tarik.

— Lloyd Moore
sumber