Mengapa Pengelola Proyek Sumber Terbuka Enggan Menggunakan Tanda Tangan Digital

Mengapa Pengelola Proyek Sumber Terbuka Enggan Menggunakan Tanda Tangan Digital – Kita semua setuju bahwa metode pengembangan open source membantu membuat kode yang lebih baik. Eric S. Raymond menunjukkan kepada kita alasannya dalam esai seminalnya, “ The Cathedral and the Bazaar ,” yang menjelaskan bagaimana metodologi keterbukaan bekerja di GCC , kernel Linux, dan proyek Fetchmail miliknya sendiri .

Mengapa Pengelola Proyek Sumber Terbuka Enggan Menggunakan Tanda Tangan Digital

signaturebar – Tapi, itu aturan umum. Open source masih dapat disalahgunakan oleh pengembang yang tidak bermoral. Jadi, mengapa kita tidak memastikan ketika seorang programmer mencoba menggabungkan kode ke dalam program bahwa mereka benar-benar seperti yang mereka katakan, dengan menggunakan otentikasi dua faktor (2FA) atau tanda tangan digital? Pertanyaan bagus.

Baca Juga : Perangkat Lunak Tanda Tangan Digital Gratis dan Sumber Terbuka Terbaik 2022

Anda mungkin tidak berpikir ini adalah masalah nyata. Sayangnya, itu. Misalnya, pada tahun 2019 versi berbahaya dari paket bootstrap-sass RubyGems yang populer diterbitkan di repositori resminya. Sebelum ditemukan dan dihilangkan, itu telah diunduh sebanyak 28 juta kali. Itu bukan kasus yang terisolasi. Malware CursedGrabber berhasil dipublikasikan ke repositori kode perangkat lunak open source JavaScript npm pada Januari 2021.

Jelas, ada kebutuhan untuk memastikan pengembang dapat dilacak kembali ke identitas dunia nyata. Namun, dalam Survei Kontributor FOSS 2020 dari Linux Foundation, ketika pengembang ditanya apakah proyek open source yang mereka kerjakan memerlukan penggunaan 2FA seperti dengan pengaturan organisasi GitHub “Memerlukan otentikasi dua faktor ,” jawabannya sangat rendah. Tidak cukup setengahnya, 47,55%, tidak menggunakan semuanya. Hanya 32,11% melaporkan bahwa beberapa proyek mereka melakukannya, sementara lebih dari seperlima, 20,34%, melaporkan semua proyek mereka membutuhkan 2FA.

“Alasan utama rendahnya adopsi faktor autentikasi sekunder adalah karena mengaktifkan autentikasi multi-faktor (MFA) apa pun merupakan langkah tambahan, karena jarang diaktifkan secara default untuk paket perangkat lunak apa pun.”

Kenapa tidak? Sebagian besar responden mengatakan tidak termasuk 2FA adalah kurangnya keputusan daripada keputusan. Banyak yang tidak menyadari bahwa itu adalah pilihan atau karena itu bukan perilaku default, itu tidak dipertimbangkan, atau dianggap terlalu membatasi untuk diminta. “Itu bukan keputusan, itu default.”

Beberapa jawaban terperinci dari survei tersebut menunjukkan bahwa keamanan bukanlah pekerjaan nomor satu bagi banyak pengembang. Mereka tidak melihat “kebutuhan untuk [2FA pada] proyek berisiko rendah.” Proyek lain, dengan beberapa kontributor, mengatakan bahwa mereka tidak melihat kebutuhan sama sekali. Dan, seperti halnya dengan begitu banyak rasionalisasi kegagalan keamanan, banyak yang menganggap 2FA terlalu sulit untuk digunakan. Seseorang bahkan berkata, “Menambahkan rintangan ekstra untuk melompat akan merugikan proyek secara umum. Tujuan kami adalah membuat proses kontribusi semudah mungkin.”

Adapun tanda tangan digital, di mana versi yang dirilis datang dengan tag git yang ditandatangani secara kriptografis (“ git tag -s”) atau paket rilis, sehingga pengguna dapat memverifikasi siapa yang merilisnya bahkan jika repo pendistribusian mungkin ditumbangkan, mereka tidak digunakan sesering mungkin. mereka harus baik. 41,53% tidak menggunakannya sama sekali sementara 35,97% menggunakannya sesekali. Hanya 22,5% yang menggunakannya sepanjang waktu.

Kenapa tidak? Inersia tua yang baik dan “kami tidak pernah menggunakannya” banyak muncul. Yang lain, tentu saja, tidak melihat perlunya tanda tangan digital. Seseorang menjelaskan, “Kepercayaan ditempatkan pada pengelola subsistem yang meninjau, menandatangani, dan meneruskan perubahan, dan dalam sistem peninjauan publik, daripada memercayai kontributor individu.”

Bagus, tapi itu tetap tidak akan menghentikan akun pengelola yang diretas untuk membuat kekacauan. Memang, setidaknya satu programmer melihat tidak perlu sama sekali “karena gesekan yang [itu] akan menyebabkan kontribusi tidak pernah sebanding dengan manfaat keamanan memilikinya.”

Jika lebih mudah untuk diterapkan, misalnya, “proses mudah yang dapat saya gunakan, pahami, dan minta kontributor untuk memasoknya melalui saluran seperti GitHub ,” beberapa akan lebih cenderung menggunakannya.

Bantuan datang dengan kedua metode. Patrick Toomey , direktur teknik keamanan produk GitHub , mencatat bahwa “Pengelola open source untuk proyek yang sudah mapan (lebih dari 100 kontributor) tiga hingga empat kali lebih mungkin menggunakan 2FA daripada pengguna rata-rata .”

Itu tidak mengejutkan karena “proyek yang lebih besar dan lebih populer menghargai posisi dan tanggung jawab mereka dalam rantai pasokan perangkat lunak sumber terbuka. Selain itu, proyek-proyek ini sering menjadi organisasi GitHub, dengan kemampuan untuk mengelola akses ke repositori mereka menggunakan tim dan menetapkan kebijakan keamanan, termasuk persyaratan untuk mengaktifkan 2FA.”

2FA, lanjut Toomey, juga semakin mudah digunakan. “Misalnya, GitHub adalah pengadopsi awal standar WebAuthn yang baru muncul . Dukungan awal kami menggunakan subset dari standar tersebut untuk mengaktifkan 2FA yang sangat kuat dengan kunci keamanan fisik.” Lebih baik lagi, “semua platform utama baru-baru ini menambahkan kemampuan untuk menggunakan perangkat yang sudah dimiliki pengguna (misalnya Face ID, Touch ID, Windows Hello, dll).

Ini menghilangkan kebutuhan akan kunci keamanan fisik atau aplikasi 2FA pihak ketiga. Seiring waktu kami optimis bahwa ini akan semakin meningkatkan adopsi 2FA karena WebAuthn memberikan kesempatan langka untuk memungkinkan pengguna mengautentikasi dengan lebih aman dan lebih mudah.”

Meski begitu, Mark Loveless , peneliti keamanan senior GitLab , mencatat “Alasan utama rendahnya adopsi faktor otentikasi sekunder adalah bahwa mengaktifkan otentikasi multifaktor (MFA) adalah langkah tambahan, karena jarang diaktifkan secara default untuk paket perangkat lunak apa pun.

Ini terutama karena sebagian besar vendor perangkat lunak ingin agar administrator sistem dapat menyesuaikan perangkat lunak yang baru diinstal untuk memenuhi kebutuhan spesifik. Selain itu, sebagian besar pengelola proyek sumber terbuka adalah pakar pengkodean dan bukan administrator sistem yang berpengalaman keamanan. Jadi menyalakan MFA tidak selalu menjadi yang utama.”

Yang mengatakan, Loveless berkata, “Kebanyakan perangkat lunak, termasuk GitLab, membuatnya cukup mudah untuk mengimplementasikan MFA. Saya tidak berpikir ini adalah masalah meyakinkan pengelola proyek open source tentang langkah-langkah keamanan dengan MFA, ini hanya masalah mengingatkan mereka bahwa itu harus dilakukan.

Tentu saja di dunia yang ideal, Loveless berbagi, “Skenario faktor kedua secara keseluruhan ada karena faktor utama — kata sandi itu sendiri — telah berulang kali terbukti tidak aman. Jika saya bisa melambaikan tongkat ajaib, kami tidak akan menggunakan kata sandi sama sekali dan akan menggunakan dua faktor seperti biometrik seperti sidik jari dan kunci FIDO U2F yang disimpan di kunci keamanan berbasis USB.”

Adapun tanda tangan digital Matt Sicker , anggota Apache Software Foundation dan insinyur keamanan senior CloudBees , berkomentar, “Aplikasi yang biasa digunakan untuk menandatangani perangkat lunak biasanya memiliki UI yang membingungkan dan memerlukan pembelajaran konsep kriptografi dasar agar dapat menggunakannya dengan benar. Tanpa semacam kebijakan penandatanganan kode untuk proyek sumber terbuka yang lebih besar, banyak pengembang tidak menyadari manfaat dari menandatangani perangkat lunak mereka.”

Di sisi lain, otentikasi multifaktor, lanjut Sicker, tampaknya lebih umum didukung daripada penandatanganan kode, tetapi ini juga merupakan area di mana peningkatan UX dan pendidikan kemungkinan akan memperbaiki situasi. Ketika Anda juga mempertimbangkan bahwa perangkat lunak open source cenderung lebih terdesentralisasi, metode umum untuk distribusi fisik kunci penandatanganan itu sendiri merupakan masalah yang sulit dalam arti kriptografi. Di situlah spesifikasi W3C WebAuthn semoga membantu.

Alex Karasulu , juga Anggota ASF dan CEO/Chief Technology Officer di OptDyn mengetahui 2FA dan tanda tangan digital dengan baik. Dia menciptakan One-Time Password (OTP) seluler pertama 2FA Apache Triple sec untuk tanda tangan digital dan penandatanganan kode. Karasulu berpikir “proses penandatanganan kode di komunitas open source dapat sangat ditingkatkan dengan prosedur 2FA yang diterapkan secara lebih konsisten.”

“Masalahnya bukan karena pengembang open source malas atau enggan,” kata Karasulu, “Mekanisme standar untuk 2FA khususnya seputar penandatanganan kode tidak ada. Ada beberapa teknik untuk mencapai hal ini: revisi git dapat ditandatangani dan prosesnya dilindungi secara longgar dengan akun 2FA yang diamanatkan di GitHub, atau kunci penandatanganan kode GPG dapat disimpan pada perangkat yang memerlukan faktor berbasis OTP kedua untuk menandatangani apa pun secara digital termasuk kode dan merilis checksum. Ada banyak cara untuk menguliti kucing ini — tetapi tidak ada standar yang membuat prosesnya konsisten. Ini pada dasarnya diskresi. ”

Sampai distandarisasi, Karasulu khawatir, “Hari ini mungkin tidak ada cara bagi organisasi open source untuk mengamanatkan bagaimana committer mengelola akses ke kode/kunci penandatanganan rilis mereka. Di ASF, kami menggunakan model Web of Trust dengan banyak penandatangan dan proses penandatanganan rilis wajib yang diamanatkan dan dipantau oleh tim Apache Security. Itu jauh lebih aman daripada menggunakan satu sertifikat penandatanganan kode yang diberikan oleh CA ke satu entitas.”

Gabungkan semuanya dan apa yang kita miliki adalah masalah keamanan bawaan, yang masih perlu dipecahkan. Beberapa bagian ada di sana, tetapi sampai ada lebih banyak kesepakatan tentang kebutuhan dan sarana untuk mengaktifkan 2FA dan keamanan tanda tangan digital dengan mudah, keduanya akan terus menjadi titik lemah dalam rantai pasokan perangkat lunak sumber terbuka.