Pegud – Linux ada di mana-mana. itu saja Awan, bahkan Microsoft Azure, berfungsi. itu Apa yang membuat semua 500 dari 500 superkomputer teratas berfungsi?. Heck, bahkan desktop Linux berkembang jika Anda percaya Pornhub, yang mengklaim pengguna Linux telah tumbuh sebesar 28% Pengguna Windows turun 3%.
Perangkat lunak open source juga berkembang pesat. berdasarkan Kursus Hype Gartner 2021 untuk Perangkat Lunak Sumber Terbuka (OSS): “Pada tahun 2025, lebih dari 70% organisasi akan meningkatkan pengeluaran TI mereka untuk OSS, dibandingkan dengan pengeluaran TI mereka saat ini. Selain itu, pada tahun 2025, Software as a Service (SaaS) akan menjadi model konsumsi pilihan untuk OSS karena kemampuannya untuk menghadirkan kesederhanaan, keamanan, dan skalabilitas operasional yang lebih baik.”
Pikirkan database, daging sapi dan kentang dalam perangkat lunak perusahaan, Gartner Diharapkan lebih dari 70% aplikasi in-house baru akan dikembangkan pada database open source. Pada saat yang sama, 50% dari instance database relasional berpemilik yang ada akan dikonversi atau dikonversi ke DBMS open source.
Saya akan membeli angka-angka ini. Saya telah mengikuti Linux dan perangkat lunak open source sejak hari pertama. Ke mana pun saya pergi dan semua orang yang saya ajak bicara mengakui bahwa pasangan itu menjalankan dunia perangkat lunak.
Tetapi dengan kekuatan besar juga datang tanggung jawab besar seperti yang diketahui Spider-Man. Dan seperti yang baru-baru ini ditemukan oleh banyak pengembang ketika itu banyak Kerentanan dengan masuk ke perpustakaan open source Apache Java log4j2 Itu ditemukan, dan itu juga datang sebagai sakit kepala yang besar.
masalah log4j2 seburuk yang bisa mereka dapatkan. Menurut benchmark National Vulnerability Database (NVD), itu dinilai 10,0 CVSSv3 yang benar-benar mengejutkan.
Masalah sebenarnya bukanlah open source itu sendiri. di sana Tidak ada yang ajaib tentang metodologi dan keamanan open source. Bug keamanan masih dapat memasukkan kode. Hukum Linus adalah bahwa diberi bola mata yang cukup, semua serangga dangkal. Tetapi, jika pengembang tidak cukup meneliti, kerentanannya akan tetap tidak diperhatikan. Seperti sekarang saya menyebutnya hukum Schneier, “Keamanan adalah proses, bukan produkIni menunjukkan bahwa kewaspadaan konstan diperlukan untuk mengamankan semua program.
Namun, masalah sebenarnya dengan log4j adalah bagaimana Java menyembunyikan perpustakaan yang menggunakan kode sumber dan binari di banyak Arsip Java (JAR) perbedaan. Hasil? Mungkin Anda menggunakan versi log4j yang lemah dan Anda tidak tahu sampai dieksploitasi.
Seperti Josh Presser, jangkar VP of Security baru-baru ini menjelaskan, “Salah satu tantangan dari kerentanan log4j sebenarnya adalah menemukannya. Biasanya aplikasi dan dependensi Java berada dalam semacam format paket yang membuat distribusi dan pengoperasian menjadi sangat mudah, tetapi dapat membuat pencarian tahu apa yang sulit di dalamnya. paket perangkat lunak.” ”
Untungnya, ada pemindai log4j Ini dapat membantu Anda mendeteksi pustaka log4j yang salah yang digunakan. Tapi mereka tidak sempurna.
Masalah lain di balik kekacauan log4j adalah “Bagaimana Anda tahu komponen open source mana yang digunakan program Anda?” Misalnya, log4j2 telah digunakan sejak 2014. Anda tidak dapat mengharapkan siapa pun untuk mengingat jika mereka menggunakan versi pertama di beberapa perangkat lunak yang masih Anda gunakan sampai sekarang.
Jawabannya adalah salah satu yang mulai dianggap serius oleh komunitas open source dalam beberapa tahun terakhir: Buat Tagihan bahan perangkat lunak (SBOM). SBOM menunjukkan dengan tepat perpustakaan perangkat lunak, prosedur, dan kode lain mana yang digunakan dalam program mana. Berbekal ini, Anda dapat memeriksa versi komponen yang digunakan dalam perangkat lunak Anda.
Seperti David A. Wheeler, Yayasan Linux Manajer Keamanan Rantai Pasokan Sumber Terbuka Dijelaskan, Menggunakan SBOM dan Pembuatan klon terverifikasi, Anda pasti tahu apa yang ada di perangkat lunak Anda. Dengan cara ini, jika kerentanan ditemukan dalam suatu komponen, Anda dapat dengan mudah menambalnya daripada mencari-cari kode masalah potensial sebelum Anda dapat memperbaikinya.
Secara kebetulan, Wheeler menjelaskan bahwa “bangunan yang dapat direproduksi” adalah “yang selalu menghasilkan keluaran yang sama dengan input yang sama yang diberikan sehingga hasil pembangunan dapat diverifikasi. Pembuatan berulang yang divalidasi adalah proses di mana organisasi independen menghasilkan bangunan dari kode sumber dan verifikasi bahwa hasilnya adalah yang dibangun berasal dari kode sumber yang diklaim.
Untuk melakukan ini, Anda dan pengembang Anda perlu melacak perangkat lunak Anda di SBOM menggunakan Linux Foundation Format Pertukaran Data Paket Perangkat Lunak (SPDX). Kemudian, untuk lebih melindungi bahwa kode Anda benar-benar sesuai dengan klaimnya, Anda perlu mendokumentasikan dan memverifikasi SBOM Anda dengan layanan seperti Layanan Sertifikasi Komunitas Codenotary Dan Katalog Tidelift.
Semua ini mudah untuk dikatakan. Lakukan dengan sangat keras. Pada tahun 2022, hampir semua pengembang open source akan menghabiskan banyak waktu untuk memeriksa masalah kode mereka, dan kemudian membangun SBOM berdasarkan SPDX. Pengguna, lebih peduli tentang Bencana Angin Matahari Dan masalah keamanan log4j, itu akan meminta.
Pada saat yang sama, pengembang Linux meningkatkan keamanan sistem operasi dengan membuat file Bahasa kedua Rust Linux. mengapa? Karena, tidak seperti C, bahasa utama Linux, Rust lebih aman. Secara khusus, Rust jauh lebih aman daripada C dalam menangani kesalahan memori.
Seperti yang dijelaskan Ryan LeVeque, pengembang cloud utama dari Microsoft, “Karat benar-benar aman untuk memori. “Ini adalah masalah besar, karena, seperti yang dicatat oleh pengembang kernel Linux Alex Gaynor dan Geoffrey Thomas pada Linux Security Summit 2019, Dua pertiga dari kerentanan di kernel Linux Itu berasal dari masalah keamanan memori. Dan dari mana mereka berasal? Masalah yang melekat pada C dan C++.
Sekarang Linux akan ditulis ulang di Rust. Setidaknya tidak dekade ini, periksa dengan saya kembali pada tahun 2030, tetapi banyak driver Linux dan kode lainnya akan ditulis dalam Rust.
Seperti yang dikatakan Linus Torvalds kepada saya sementara dia sama sekali tidak “membayar” untuk Rust, “dia” terbuka untuk itu mengingat manfaat yang dijanjikan dan menghindari beberapa risiko keamanan. Namun, ia menyimpulkan, “Saya juga tahu bahwa terkadang janji tidak berhasil.”
Kita akan melihat bagaimana semuanya bekerja. Tidak peduli bagaimana detailnya, ada satu hal yang saya tahu pasti. Kita akan melihat bahwa keamanan kode telah menjadi isu terpenting bagi Linux dan pengembang open source pada tahun 2022. Keduanya menjadi sangat penting bagi mereka dengan cara lain.