Perangkat lunak adalah inti dari semua bisnis modern dan sangat penting dalam setiap aspek operasi. Hampir setiap bisnis akan menggunakan perangkat lunak sumber terbuka, secara sadar atau tidak, karena perangkat lunak berpemilik pun bergantung pada pustaka sumber terbuka. OpenUK's Laporan “State of Open” 2022 menemukan bahwa 89% bisnis mengandalkan perangkat lunak sumber terbuka, tetapi tidak semuanya jelas tentang detail perangkat lunak yang mereka andalkan.
Bisnis semakin menuntut lebih banyak informasi tentang perangkat lunak kritis operasi mereka. Bisnis yang bertanggung jawab menaruh perhatian besar pada rantai pasokan perangkat lunak mereka dan membuat tagihan bahan perangkat lunak (SBOM) untuk setiap aplikasi. Tingkat informasi ini sangat penting sehingga ketika kelemahan keamanan diidentifikasi dalam perangkat lunak mereka, mereka dapat segera memastikan perangkat lunak dan versi mana yang digunakan, dan sistem mana yang terpengaruh. Pengetahuan adalah kekuatan dalam situasi ini!
Ketergantungan pada Relawan
Pada akhir tahun 2021, kerentanan keamanan yang disebut Log4Shell diidentifikasi dalam kerangka logging Java yang banyak digunakan, Log4j. Karena ini adalah perpustakaan sumber terbuka yang banyak digunakan, kerentanan dipublikasikan dengan baik, dan perbaikan diharapkan. Namun, pengelola proyek adalah sukarelawan. Mereka memiliki pekerjaan harian dan tidak siap untuk melakukan perbaikan keamanan yang mendesak, bahkan jika sejumlah besar sistem terpengaruh. Kerentanan ini sendiri diperkirakan telah memengaruhi 93% lingkungan cloud perusahaan.
Pada saat itu, ada beberapa pers negatif tentang open source, tetapi kenyataannya adalah bahwa jika ini adalah komponen sumber tertutup, kerentanannya mungkin tidak akan pernah diketahui publik, membuat organisasi terbuka untuk diserang. Sifat perpustakaan yang open source berarti bahwa perpustakaan dapat diperiksa, masalah yang ditemukan, dan saran yang ditawarkan oleh orang lain. Jadi, ya, pengelola tidak dipanggil untuk masalah keamanan dalam proyek sukarela mereka. Pertanyaan besarnya, kemudian, adalah: Bagaimana kita masuk ke situasi di mana perusahaan besar bergantung pada perangkat lunak yang merupakan tanggung jawab seseorang yang melakukan sesuatu yang lain untuk membayar tagihan mereka?
Mengabaikan ketergantungan perangkat lunak adalah bisnis yang berisiko apa pun lisensi perangkat lunaknya, tetapi ketika itu open source dan sangat banyak digunakan, itu menjadi sangat berbahaya. Berpegang teguh pada cerita tentang satu kerentanan; masalahnya telah ada di basis kode selama bertahun-tahun, tetapi tidak terlihat. Alat yang digunakan secara luas, pada kenyataannya, tidak didukung secara luas — dan yang terjadi selanjutnya adalah sejarah.
Kisah ini berulang-ulang, di begitu banyak bisnis yang memiliki ketergantungan kritis tetapi tidak mengambil tindakan untuk mendukung pengelola atau proyek itu sendiri. Memiliki SBOM untuk perangkat lunak yang digunakan oleh bisnis berarti mereka memiliki informasi di tangan. Untuk organisasi yang memasok perangkat lunak kepada orang lain, harapan untuk memasok SBOM bersama kode semakin menjadi norma.
Ketahui Ketergantungan untuk Menilai Risiko
Membawa pengetahuan tentang dependensi membuatnya lebih mudah untuk menilai risiko yang terkait dengan masing-masing dependensi. Proyek open source ini adalah yang paling sederhana untuk dinilai: apakah masalah telah ditanggapi, dan apakah ada rilis baru-baru ini? Mampu melihat pengelola dan aktivitas proyek untuk setiap proyek memberikan wawasan yang baik tentang kesehatan proyek.
Bisnis dapat memainkan peran mereka untuk mengurangi risiko dengan mendukung proyek tempat mereka bergantung. Beberapa proyek menerima sponsor secara langsung melalui skema Sponsor GitHub, yang lain mungkin menghargai tawaran hosting, atau audit keamanan. Setiap proyek open source menghargai kontribusi. Jika bisnis Anda telah membuat perpustakaan ini sendiri, maka para insinyur di dalam perusahaan harus memperbaiki sendiri setiap bug.
Open source lebih seperti skema kepemilikan bersama. Kita semua tidak harus membangun hal yang sama berulang kali, tetapi lebih kepada dapat berkontribusi, yang lebih sedikit usaha dan menghasilkan kualitas yang lebih baik sebagai hasilnya. Salah satu hal paling berdampak yang dapat dilakukan bisnis adalah menggunakan sedikit sumber daya teknik mereka dan berkontribusi pada perbaikan bug atau fitur untuk proyek yang begitu inti untuk bisnis.
Menjaga insinyur Anda sendiri terlibat dalam sebuah proyek memiliki banyak manfaat. Mereka mengenalnya dan dapat mengawasi fitur-fitur baru, atau ketika rilis baru tersedia. Yang terpenting, bisnis memiliki wawasan tentang kesehatan dan status proyek yang bergantung dan merupakan bagian dari apa yang membuatnya tetap sehat, mengurangi risiko bisnis dari masalah dengan ketergantungan. Sejumlah organisasi, termasuk Aiven, memiliki OSPO (kantor program sumber terbuka), dengan staf yang berdedikasi untuk berkontribusi atau bahkan memelihara proyek yang digunakan oleh organisasi. Departemen-departemen ini sering berkontribusi pada kehadiran umum perusahaan di ekosistem open source dan memungkinkan karyawan lain untuk terlibat dengan open source.
Pendekatan lain adalah dengan mendukung organisasi yang ada untuk mendukung open source. Itu OpenSSF (Yayasan Keamanan Sumber Terbuka) bekerja untuk meningkatkan keamanan proyek sumber terbuka dan didanai oleh organisasi yang bergantung pada proyek tersebut. Ini juga menerbitkan sumber belajar yang sangat baik sehingga bisnis dapat mendidik diri mereka sendiri tentang risiko perangkat lunak yang mereka gunakan. Organisasi serupa lainnya adalah Pasang surut, yang bermitra dengan pengelola untuk memastikan persyaratan dasar tertentu terpenuhi, sekali lagi didanai oleh organisasi. Tidelift juga menyediakan peralatan dan pendidikan untuk membantu bisnis mengelola rantai pasokan perangkat lunak mereka dan mengadopsi praktik terbaik di bidang ini.
Mengamankan Masa Depan Perangkat Lunak yang Lebih Aman
Bisnis bergantung pada perangkat lunak, dan ini termasuk perangkat lunak sumber terbuka, yang digunakan secara luas dan biasanya lebih aman daripada alternatif berpemilik.
Ini adalah langkah yang cerdas, tetapi langkah yang lebih cerdas lagi adalah memiliki pengetahuan yang jelas tentang rantai pasokan perangkat lunak dan dependensinya. Ketika masalah memang muncul, bergantung pada proyek yang sehat dan memiliki perincian perangkat lunak Anda yang tersedia membantu setiap organisasi. Jika setiap organisasi melakukan ini, maka risiko kejadian seperti kerentanan Log4Shell akan berkurang.
