Oleh: Jonathan Knudsen, Ahli Strategi Keamanan Senior di Synopsys Software Integrity Group

Manufaktur tradisional adalah analogi yang berguna untuk membuat perangkat lunak. Saya biasanya menghubungkan perangkat lunak dengan mobil. Jika Anda ingin membangun mobil, Anda tidak pernah memulai dari awal. Tidak masuk akal untuk membuat busi atau bantalan rem Anda sendiri. Banyak, banyak bagian mobil berasal dari perusahaan lain, yang pada gilirannya kadang-kadang memperoleh bagian yang lebih kecil dari vendor mereka sendiri. Jaringan dependensi ini adalah rantai pasokan, analogi yang terbawa dengan sangat baik untuk pembuatan perangkat lunak.

Hampir tidak ada orang yang menulis perangkat lunak dari bawah ke atas. Sebagai gantinya, kami merakit komponen perangkat lunak, seringkali komponen sumber terbuka, menjadi produk lengkap, menciptakan beberapa persentase kode asli, atau pihak pertama, sebagai lem untuk menyatukan semuanya.

Misalnya, jika Anda membuat perangkat kecil yang berkomunikasi melalui SSL, Anda tidak akan menghabiskan waktu dan uang untuk membuat implementasi Anda sendiri. Sebagai gantinya, Anda akan menggunakan salah satu implementasi open source yang tersedia, seperti OpenSSL, WolfSSL, atau MatrixSSL. Demikian juga, Anda tidak akan membuat sistem operasi sendiri. Sebagai gantinya, Anda akan menggunakan sistem operasi open source yang tersedia, mungkin sesuatu yang dipetik dari pohon keluarga Linux.

Seperti bagian fisik yang digunakan dalam perakitan mobil, komponen perangkat lunak dapat memiliki hubungan bersarang, di mana satu komponen mungkin merupakan subassembly dari komponen yang lebih kecil.

Percaya, tetapi verifikasi

Salah satu alasan produsen mobil memproduksi mobil yang cukup aman adalah manajemen rantai pasokan mereka yang cermat. Setiap pabrikan menyimpan tagihan bahan, daftar setiap bagian yang masuk ke dalam mobil. Pabrikan juga menyimpan daftar setiap vendor yang memasok suku cadang. Pabrikan membangun hubungan kepercayaan dengan vendornya dan memiliki proses untuk memastikan kebenaran setiap bagian. Lagi pula, jika sebuah mobil terbakar karena bagian yang rusak, itu adalah produsen mobil yang harus disalahkan.

Rantai pasokan benar-benar rantai kepercayaan. Konsumen mempercayai produsen untuk menjual produk yang cukup aman dan andal. Pabrikan mempercayai vendornya untuk membuat suku cadang yang cukup aman dan andal. Pada gilirannya, vendor ini mempercayai vendor mereka sendiri untuk membuat subbagian yang cukup aman dan andal.

Pepatah Rusia kuno selalu tepat: “Percaya, tetapi verifikasi.”

Produsen mobil memastikan kualitas dan keamanan kendaraan mereka dengan secara aktif mengelola rantai pasokan mereka. Mereka melakukan ini dengan memeriksa vendor mereka dan suku cadang yang disediakan vendor.

Pada tingkat bisnis, produsen mobil ingin vendor menggambarkan bagaimana mereka membuat suku cadang yang tepat dan benar dan bagaimana vendor itu sendiri memastikan kualitas dan keamanan suku cadang yang mereka hasilkan. Terkadang kepercayaan juga didasarkan pada sejarah bersama. Jika pabrikan telah memiliki hubungan yang panjang dan sukses dengan vendor, kedua belah pihak mungkin berharap hal itu berlanjut.

Pabrikan juga harus melakukan pengujian khusus pada suku cadang yang diterimanya dari vendor. Jika mendapat kiriman 20.000 busi dari vendor, akan lebih bijaksana untuk memilih selusin secara acak dan memastikan ukurannya tepat dan berkinerja dengan benar.

Kebebasan tidak gratis

Produsen perangkat lunak harus mengikuti proses manajemen rantai pasokan yang serupa. Komponen open source seperti kotak penuh busi yang Anda temukan suatu hari di pinggir jalan dalam perjalanan Anda untuk bekerja di pabrik mobil. Anda tidak akan berkata, “Betapa beruntungnya! Aku akan menggunakan ini saja!” Anda mungkin menggunakannya, tetapi hanya setelah pengujian yang cermat untuk memastikan mereka bekerja dengan benar. Bahkan kemudian, Anda akan skeptis jika Anda tidak memiliki gagasan tentang siapa yang membuatnya dan dari mana asalnya.

Sayangnya, selama bertahun-tahun, terlalu banyak organisasi telah membangun perangkat lunak dari bagian-bagian yang mereka temukan di pinggir jalan. Komponen perangkat lunak open source menyediakan beberapa fungsi yang dibutuhkan produsen perangkat lunak. Selain itu, Anda menggunakan komponen open source tanpa membelinya — jadi bukankah itu berarti mereka gratis?

Kedengarannya terlalu bagus untuk menjadi kenyataan. Itu terlalu bagus untuk menjadi kenyataan. Tentu saja, komponen open source menyediakan fungsionalitas yang berguna. Tetapi mereka tidak datang secara gratis.

Sebelum menggunakan komponen open source, Anda harus memverifikasi bahwa itu tidak memperkenalkan tingkat risiko yang tidak dapat diterima ke dalam produk Anda. Risiko ini berasal dari adanya kerentanan yang diketahui (CVEs) dalam komponen open source, serta kemungkinan bahwa lisensi komponen tidak kompatibel dengan produk Anda.

Komponen perangkat lunak, bagaimanapun, hanyalah bagian dari perangkat lunak yang dibangun oleh tim lain. Anda mungkin tidak memiliki banyak visibilitas ke dalam tim-tim ini – siapa mereka, bagaimana mereka memastikan kualitas dan keamanan, dan sebagainya. Pengembang open source sama manusiawinya dengan kita semua, dan ketika mereka membuat kesalahan, mereka dapat memperkenalkan kerentanan ke dalam komponen perangkat lunak mereka. Biasanya, ketika peneliti menemukan kerentanan tersebut, yang dilacak sebagai CVE, tim komponen akan memperbaiki masalah dan merilis versi baru komponen.

Komponen open source juga memiliki lisensi perangkat lunak yang menetapkan aturan tentang bagaimana orang lain dapat menggunakan komponen tersebut. Lisensi berkisar dari permisif secara luas hingga restriktif, dengan beberapa mengharuskan pengembang yang menggunakan komponen mempublikasikan kode sumber mereka sendiri. Memahami lisensi yang mengatur komponen yang Anda gunakan sangat penting jika Anda ingin merilis produk Anda sendiri berdasarkan persyaratan lisensi yang Anda pilih.

Setelah Anda menggunakan komponen open source, Anda perlu mengawasinya. Para peneliti menemukan kerentanan baru dalam komponen open source sepanjang waktu. Anda harus siap untuk beraksi setiap kali kerentanan muncul dalam komponen yang telah Anda gunakan. Kecepatan adalah esensi. Anda harus memeriksa kerentanan untuk melihat apakah itu terkena dalam produk Anda sendiri. Jika demikian, Anda perlu memperbarui produk Anda dengan versi komponen tetap atau mengurangi kerentanan dengan cara lain. Pelanggan Anda kemudian harus memperbarui instalasi produk Anda sesegera mungkin.

Gunakan mesin

Terkadang, manajer produk yang terkepung menggunakan proses manual atau spreadsheet untuk melacak komponen open source, tetapi ini mirip dengan memindahkan tumpukan kotoran dengan sepasang pinset. Mengapa tidak menggunakan buldoser saja?

Produk perangkat lunak sering menggunakan ratusan komponen open source, sehingga tugas dasar membuat daftar komponen yang digunakan (tagihan bahan perangkat lunak) dapat menjadi hal yang menakutkan. Selain itu, nomor versi komponen berubah dengan setiap rilis. Meskipun lisensi biasanya stabil di beberapa rilis komponen, kerentanan berlaku untuk versi tertentu. Mengkorelasikan versi komponen yang Anda gunakan secara manual ke CVE terkait adalah tantangan besar.

Untungnya, alat analisis komposisi perangkat lunak (SCA) mengotomatiskan sebagian besar pekerjaan ini, membuat Anda bebas untuk tugas yang lebih penting, seperti menetapkan kebijakan tentang apa yang merupakan risiko komponen open source yang dapat diterima.