Bagaimana menghindari mimpi buruk keamanan open source
Security

Bagaimana menghindari mimpi buruk keamanan open source

Ada beberapa masalah keamanan profil tinggi dengan perangkat lunak sumber terbuka. Pengembang yang tidak puas baru-baru ini mengirimkan rilis yang sengaja dimodifikasi dari paket faker.js dan colors.js miliknya, yang merusak “ribuan proyek” yang mengandalkannya. Beberapa orang bertanya-tanya apakah aman menggunakan perangkat lunak open source sama sekali. Gedung Putih tentu saja — mereka telah meminta perusahaan teknologi besar untuk berkomentar tentang keamanan perangkat lunak setelah masalah Log4j, yang mengekspos server yang tak terhitung jumlahnya untuk eksploitasi jarak jauh.

Apakah kode yang ditulis oleh sukarelawan kurang aman dibandingkan kode yang ditulis oleh pengembang profesional? Apakah Anda perlu menuntut seseorang jika suatu produk gagal? Apakah Anda benar-benar mendapatkan apa yang Anda bayar?

Apa itu Sumber Terbuka?

Sama seperti kesalahan untuk mengatakan bahwa semua proyek sumber tertutup bebas bug, adalah kesalahan untuk mengatakan bahwa semua proyek sumber terbuka adalah risiko keamanan. Proyek yang berbeda memiliki fokus yang berbeda; beberapa dari mereka jauh lebih peduli dengan keamanan rilis mereka.

Josh Berkus telah mengidentifikasi lima jenis proyek open source berdasarkan strukturnya:

  • SEBUAH solo proyek adalah hasrat dari satu individu atau, paling banyak, beberapa orang yang berdedikasi dengan visi yang sama.

  • SEBUAH kerajaan adalah proyek solo yang sukses seperti Linux yang mendapat dukungan dari komunitas besar kontributor, sehingga pembuat aslinya bertindak sebagai tiran yang baik hati.

  • SEBUAH masyarakat proyek seperti PostgreSQL muncul di antara rekan-rekan dengan tujuan yang sama dan didorong oleh konsensus.

  • SEBUAH perusahaan project sering dirilis sebagai fork dari proyek komersial, seperti ketika Sun merilis OpenOffice sebagai fork open source StarOffice. Arahnya dipandu oleh perusahaan yang merilisnya.

  • SEBUAH dasar, yang paling formal, adalah struktur bisnis yang berdiri sendiri — di mana Apache mungkin adalah contoh terbaiknya. Di sana, dewan kemudi membuat keputusan.

Secara umum, proyek solo adalah yang paling rentan terhadap risiko keamanan. Sama seperti seorang penulis dapat memperbarui halaman webnya dengan konten apa pun, pengembang solo dapat memperbarui kodenya dengan cara yang sama. Seringkali, tidak ada cukup minat dalam komunitas untuk melakukan proyek solo, sehingga mereka menjadi standar de facto. Kami melihat ini dengan faker.js dan colors.js, ketika Marak Squires memodifikasi kodenya untuk mencetak flag dan memasukkan infinite loop.

Keamanan proyek sumber terbuka dan tertutup bergantung pada fokus kontributornya, bukan pada strukturnya. Kami beruntung Linus Torvalds memiliki keamanan sebagai salah satu perhatiannya. Theo de Raadt, telah sadar akan keamanan OpenBSD sejak awal. Sebaliknya, baik StarOffice (komersial) dan OpenOffice memiliki lubang keamanan yang memungkinkan eksekusi kode arbitrer dari jarak jauh dalam dokumen XML.

Banyak mata terfokus di tempat lain?

Salah satu ironi open source adalah anggapan bahwa banyak mata meningkatkan keamanan. Selama bertahun-tahun, kami mendengar klaim bahwa open source lebih aman karena “komunitas” dapat meninjau kodenya. Masalahnya: “Komunitas” jarang meninjau kode, dan semua orang hanya berasumsi bahwa orang lain yang melakukannya. Rasa aman yang salah itu benar-benar meledak selama Heartbleed — kenyataan bahwa terlalu banyak kode dan terlalu sedikit mata berarti bahwa kita memerlukan proses dan otomatisasi yang lebih baik untuk meningkatkan keamanan sumber terbuka.

Namun, ada rasa aman lain yang salah: Jangan berasumsi bahwa perangkat lunak sumber tertutup memiliki proses yang lebih baik hanya karena Anda tidak dapat melihatnya. Dalam kasus Heartbleed, “komunitas” akhirnya meninjau lubang di OpenSSL, dan solusinya adalah … lebih banyak open source. LibreSSL, cabang dari OpenSSL, memiliki fokus pada keamanan daripada kompatibilitas ke belakang.

Open Source membutuhkan akuntabilitas bersama

Meskipun Anda tidak membayar uang saat menggunakan perangkat lunak sumber terbuka, bukan berarti Anda tidak memiliki kewajiban — terhadap bisnis Anda, pelanggan Anda, dan komunitas. Bertanggung jawab saat menggunakan perangkat lunak open source:

  • Ketahui apa yang Anda gunakan. Salah satu bahaya terbesar dari beberapa ekosistem adalah kemudahan dimana satu proyek open source dapat menyertakan yang lain. Banyak proyek saat ini memasukkan proyek lain sebagai komponen. Sistem seperti npm memudahkan untuk memasukkan kode tanpa disadari. Ada alat untuk membantu menghasilkan tagihan perangkat lunak (SBOM) dan untuk memindai kode Anda untuk melihat apakah Anda bergantung pada sesuatu yang tidak Anda ketahui.

  • Hindari proyek solo dan terbengkalai. Pengembang jahat tunggal dapat menyuntikkan banyak bahaya — terutama jika Anda mengupgrade secara otomatis. Bahaya menggunakan proyek yang ditinggalkan adalah bahwa mereka mungkin tidak memperhitungkan kerentanan modern. Evaluasi status proyek yang Anda gunakan dengan setiap rilis.

  • Uji sebelum Anda merilis. Sebagian besar bahaya dengan proyek sumber terbuka berasal dari peningkatan tanpa pengujian. Jika kode Anda menyertakan pustaka sumber terbuka dengan eksploitasi, pengguna Anda akan meminta pertanggungjawaban Anda. Sertifikasi dengan versi proyek tertentu dan tetap perbarui. Garpu pustaka sumber terbuka yang Anda gunakan dan persembahkan sumber daya untuk meninjau apa yang telah dilakukan.

  • Rencanakan pembaruan. Kerentanan Log4j sangat berbahaya karena memungkinkan eksekusi kode arbitrer pada platform yang memiliki perangkat lunak yang dimasukkan ke dalam ROM. Untuk beberapa perangkat internet-of-things, tidak ada cara untuk memutakhirkan perpustakaan Log4j untuk memperbaikinya. Ini meninggalkan kerentanan terus-menerus yang tidak dapat diatasi. Jangan menempatkan produk Anda dalam kesulitan yang sama. Berikan jalur upgrade (dan downgrade!) untuk setiap komponen. Jangan menunggu masalah keamanan untuk memutakhirkan kode Anda — rencanakan untuk memperbarui secara teratur ke versi yang lebih baru untuk meningkatkan kebersihan kode Anda.

  • Berkontribusi pada proyek sumber terbuka. Banyak proyek open source memberikan kode yang berguna dengan sedikit sumber daya. Berkomitmen untuk berkontribusi baik secara finansial atau dengan menyediakan sumber daya pengembangan atau QA ke pustaka sumber terbuka yang Anda gunakan. Jangan batasi kontribusi open source Anda pada hari Anda menarik perpustakaan — open source membutuhkan dukungan berkelanjutan, jadi sertakan kontribusi open source dalam anggaran tahunan dan perencanaan jangka panjang Anda. Anda ingin memastikan rilis terbaru seaman yang pertama kali Anda tarik.

  • Berinvestasi di DevSecOps. Asumsikan bahwa pembaruan yang sering adalah norma, bukan pengecualian. Baik itu kode yang dibuat oleh tim Anda sendiri atau kode yang Anda bawa dari proyek sumber terbuka, sadari bahwa bug akan terjadi, pembaruan akan diperlukan, dan bahwa, dalam beberapa kasus, iterasi cepat akan diperlukan untuk mengikuti perubahan. DevOps, dalam bentuk CI/CD, sekarang menjadi taruhan meja; up the ante dengan menambahkan “Sec” — kemampuan untuk menggeser pemeriksaan keamanan otomatis ke kiri langsung ke siklus dev sehingga ketika pembaruan tersebut masuk, Anda lebih siap untuk menyelesaikannya dengan lebih sedikit begadang dan banyak lagi kurang kerja keras dan stres.

Bangun dari mimpi buruk

Jika Anda takut menggunakan open source, sudah terlambat. Anda tidak mungkin menggunakan produk hari ini tanpa komponen open source. Hampir pasti Anda membaca ini dengan browser berbasis teknologi open source, dilayani oleh web server yang memiliki inti open source — semua dibangun dengan alat open source. Meskipun mimpi buruk bukanlah kenyataan, itu mungkin merupakan respons terhadap kecemasan yang sah. Gunakan perangkat lunak open source secara bertanggung jawab untuk menghindari merinding.

Posting ini ditulis oleh Analis Senior Andrew Cornwall dan awalnya muncul di sini.

Posted By : togel hari ini hongkong