banner large

Keamanan open source membutuhkan otomatisasi saat penggunaan meningkat di antara organisasi

Comment
X
Share

Dengan semakin banyaknya organisasi yang memanfaatkan kode sumber terbuka dalam aplikasi mereka sendiri, mereka harus mampu mengatasi kompleksitas lingkungan tersebut dengan alat otomatisasi sehingga mereka dapat dengan cepat merespons kerentanan baru.

Hampir semua perangkat lunak yang dikembangkan secara internal saat ini berisi beberapa kode sumber terbuka, kata Phillip Ivancic, kepala strategi solusi Asia-Pasifik di Synopsys Software Integrity Group.

Menurut laporan Keamanan dan Analisis Risiko Sumber Terbuka 2022 vendor keamanan, 97% basis kode komersial berisi setidaknya beberapa kode sumber terbuka. Dari jumlah tersebut, rata-rata 78% kode dalam basis kode adalah open source. Dirilis pada bulan Mei, penelitian ini menganalisis 2.409 basis kode komersial di 17 industri.

Sebagian besar organisasi tidak ingin membangun semuanya dari awal ketika mereka mengembangkan perangkat lunak mereka sendiri, kata Liu Yang, salah satu pendiri dan CEO Scantist, vendor keamanan aplikasi yang pada tahun 2016 memisahkan diri dari lab penelitian di Nanyang Technological University (NTU) Singapura. .

Sekarang ada banyak perpustakaan dan basis kode yang mapan dalam perangkat lunak sumber terbuka (OSS) yang dapat dimanfaatkan dan dibangun oleh organisasi, kata Liu dalam sebuah wawancara dengan ZDNet.

Andrew Martin, kepala Databricks Asia Selatan, sependapat, menambahkan bahwa open source memungkinkan perusahaan untuk berinovasi lebih cepat dan memanfaatkan kode yang sudah tersedia, daripada menghabiskan sumber daya membangun perangkat lunak berpemilik di rumah.

Teknologi open source juga memastikan transparansi dan visibilitas penuh ke dalam kode sumber, menawarkan tim data koneksi ke komunitas open source yang lebih luas, kata Martin.

Namun, kata Liu, penyadapan open source berarti bahwa setiap kerentanan dalam kode kemudian dapat diwarisi oleh aplikasi perusahaan host. Kerentanan open source, oleh karena itu, harus selalu diatasi terlebih dahulu, katanya.

Kegagalan untuk melakukannya dapat menyebabkan risiko keamanan yang serius bagi bisnis yang tidak tetap mendapat informasi tentang kerentanan tersebut dan memperbarui perangkat lunak mereka sesuai dengan itu, ia memperingatkan.

Studi Synopsys mengungkapkan bahwa 81% kode perangkat lunak mengandung setidaknya satu kerentanan open source yang diketahui, turun 3% dari tahun sebelumnya.

Meskipun mengetuk sumber terbuka tidak berarti perangkat lunak internal kurang aman, hal itu membawa pertimbangan utama yang harus ditangani dan dikelola, kata Ivancic kepada ZDNet. Pertama, perusahaan harus mengetahui semua komponen OSS termasuk versi aktual yang digunakan dalam basis kode proyek mereka.

Disebut sebagai Software Bill of Materials (SBOM), repositori pusat ini akan memastikan perusahaan dapat dengan cepat merespons ketika kerentanan baru ditemukan, seperti kesalahan zero-day Log4j yang terkenal tahun lalu. Dengan SBOM, mereka akan dapat mengidentifikasi aplikasi yang rentan dan menerapkan tindakan perbaikan yang diperlukan, katanya.

Mereka juga perlu mengetahui basis kode OSS yang tepat yang digunakan dalam proyek apa pun, sehingga mereka dapat menentukan apakah aplikasi akan terpengaruh ketika kerentanan berisiko tinggi baru ditemukan.

Cacat zero-day Log4j, khususnya, kemungkinan akan memunculkan lebih banyak kerentanan di tahun-tahun mendatang karena meningkatnya penggunaan OSS, kata Liu.

Lebih lanjut, ia mencatat bahwa perpustakaan Java untuk mencatat pesan kesalahan dalam aplikasi adalah kerangka kerja dasar yang digunakan oleh setengah dari aplikasi Java, yang berarti bahwa semua perangkat lunak sumber terbuka yang menggunakan perpustakaan berpotensi memiliki kerentanan yang parah.

Peretas dapat mengeksploitasi kelemahan Log4j untuk melakukan serangan jarak jauh dan menggunakan perpustakaan OSS perusahaan untuk mengontrol sistemnya.

Juga sulit menangani kerentanan seperti itu karena sifat pengembangan OSS yang berlapis, katanya.

“Jika Anda menggunakan perpustakaan OSS untuk satu aplikasi, perpustakaan itu kemungkinan menggunakan perpustakaan kedua dan, pada gilirannya, menggunakan perpustakaan ketiga,” jelas Liu. “Jika perpustakaan ketiga memiliki kerentanan kritis dan Anda menggunakan perpustakaan pertama, ada kerentanan intrinsik dalam rantai ketergantungan ini. Ini dapat menimbulkan risiko keamanan bagi Anda, bahkan jika Anda tidak menggunakan perpustakaan ketiga.”

Mengidentifikasi semua ketergantungan pasif dan tidak langsung jauh dari mudah, katanya, menambahkan bahwa mungkin sulit bagi perusahaan untuk mengakses pakar keamanan untuk melakukan pekerjaan seperti itu. Dia menunjuk perlunya alat otomatis untuk mendukung penilaian keamanan tersebut.

Ivancic menekankan perlunya organisasi untuk memahami risiko operasional dan lisensi yang terlibat dalam penggunaan kode sumber terbuka. Misalnya, ia mencatat bahwa basis kode OSS yang tidak memiliki komunitas kontributor aktif dapat menunjukkan potensi risiko, karena kerentanan baru mungkin tidak ditemukan dan ditambal secara tepat waktu.

Studi Synopsys mengungkapkan bahwa 88% basis kode menggunakan komponen yang bukan versi terbaru, sementara 84% memiliki kode sumber terbuka yang sudah lebih dari empat tahun kedaluwarsa. Selain itu, 53% dari basis kode yang diaudit memiliki konflik lisensi dan 20% berisi sumber terbuka tanpa lisensi atau lisensi khusus.

Ivancic mencatat bahwa proyek open source memiliki berbagai ketentuan lisensi yang berkisar dari yang sangat permisif hingga yang mungkin mengharuskan pengguna untuk menerbitkan karya turunan di bawah persyaratan lisensi yang sama. Sebuah SBOM kemudian akan lebih mampu organisasi untuk melacak kondisi perizinan yang berbeda, katanya.

“Jika organisasi tidak proaktif dalam memelihara dan meninjau pembaruan kerentanan mereka, mereka berisiko menjadi sasaran empuk bagi penyerang,” katanya. “Selain itu, jika mereka gagal mematuhi lisensi open source, mereka dapat menempatkan bisnis mereka pada risiko litigasi dan membuka diri terhadap ancaman terhadap kekayaan intelektual mereka.”

Seperti Liu, Ivancic menggarisbawahi pentingnya membangun otomatisasi ke dalam jalur pengembangan untuk mengurangi risiko berdasarkan kebijakan keamanan internal.

“OSS itu sendiri tidak aman… tantangannya adalah dengan semua versi dan komponen yang mungkin membentuk sebuah proyek perangkat lunak,” jelasnya. “Tidak mungkin untuk mengikuti tanpa otomatisasi dan prioritas.”

Dia mencatat bahwa komunitas OSS responsif dalam menangani masalah keamanan dan menerapkan perbaikan, tetapi organisasi yang mengetuk OSS harus menavigasi kompleksitas untuk memastikan perangkat lunak mereka memiliki basis kode yang benar dan terbaru.

Ini lebih diperparah oleh fakta bahwa sebagian besar organisasi harus mengelola banyak proyek secara bersamaan, katanya, menekankan pentingnya membangun strategi keamanan perangkat lunak holistik.

Dia lebih lanjut menunjuk ke Institut Standar dan Teknologi Nasional AS (NIST), yang menawarkan kerangka kerja rantai pasokan perangkat lunak yang dapat membantu organisasi dalam merencanakan respons keamanan OSS mereka.

Peraturan membantu, tetapi tidak cukup untuk memperbaiki semua

Ditanya apakah peraturan diperlukan untuk mendorong praktik keamanan yang lebih baik, Liu mengatakan sebagian besar perusahaan melihat keamanan siber sebagai biaya dan tidak ingin mengatasinya secara aktif tanpa adanya insentif apa pun.

Oleh karena itu, beberapa kebijakan tata kelola atau peraturan yang sesuai akan membantu dalam meningkatkan keamanan keseluruhan perangkat lunak sumber terbuka, katanya.

Dia mencatat bahwa telah ada diskusi di antara pengembang tentang risiko eksploitasi pintu belakang dan kode berbahaya, yang menunjukkan perlunya tata kelola yang lebih baik dalam hal keamanan dan tanggung jawab. Dia menambahkan bahwa tim penelitinya di NTU sedang mencari untuk mengusulkan seperangkat mekanisme dan aturan untuk mengatasi keamanan OSS.

Namun, kata dia, regulasi saja tidak akan menyelesaikan semuanya. Organisasi masih perlu mencari cara untuk mencapai keamanan yang lebih baik dengan cara yang hemat biaya.

Di sinilah, kata Liu, di mana ekosistem yang lebih luas dapat berkolaborasi. Dia menambahkan bahwa Scantist baru-baru ini menjalankan program karunia bug di mana peserta didorong untuk menggunakan analisis komposisi perangkat lunak untuk menemukan dan memperbaiki kerentanan.

Tujuannya di sini adalah untuk mempromosikan keamanan OSS serta mendorong kesadaran yang lebih besar di antara usaha kecil dan menengah, kata Liu. Scantist menawarkan alat analisis komposisi perangkat lunak, yang disebut Thompson, yang disebut-sebut untuk membantu perusahaan mengelola risiko keamanan dan kepatuhan dari perpustakaan sumber terbuka mereka.

Saat dihubungi, Badan Keamanan Siber Singapura (CSA) mengatakan saat ini pihaknya tidak berencana memberlakukan peraturan keamanan terkait penggunaan perangkat lunak sumber terbuka. Sebaliknya, lembaga pemerintah menganjurkan penerapan prinsip-prinsip nol kepercayaan dan bagi semua organisasi Singapura untuk membangun pertahanan siber mereka berdasarkan kerangka kerja ini.

Seorang juru bicara CSA mengatakan kepada ZDNet bahwa keamanan OSS harus dinilai sebagai bagian dari upaya perusahaan untuk mengurangi risiko dari mitra rantai pasokan mereka. Untuk membantu perusahaan melakukannya, CSA memperkenalkan beberapa langkah termasuk program untuk sektor CII (infrastruktur informasi penting) dan perangkat konsumen pintar.

Misalnya, program Rantai Pasokan CII diumumkan tahun lalu untuk menguraikan proses dan praktik terbaik yang dapat membantu operator CII dan vendor mereka mengelola risiko rantai pasokan dan meningkatkan postur keamanan siber rantai pasokan mereka.

CSA awal tahun ini juga memperkenalkan tanda sertifikasi Cyber ​​Essentials dan Cyber ​​Trust bahwa tindakan keamanan siber bersertifikat yang diadopsi organisasi untuk produk dan layanan mereka. Inisiatif ini bertujuan untuk memberikan “indikator yang terlihat” dari bisnis yang memprioritaskan keamanan siber serta meningkatkan tingkat kepercayaan dan keyakinan di antara organisasi yang bertransaksi dengan pemain bersertifikat, kata juru bicara CSA.

Dia menambahkan bahwa Skema Pelabelan Keamanan Siber, yang menilai perangkat pintar sesuai dengan tingkat ketentuan keamanan sibernya, dengan Level 3 dan 4 dua kategori tertinggi. Dia mencatat bahwa produk yang disertifikasi di bawah Skema Kriteria Umum Singapura akan melalui analisis biner untuk mengidentifikasi kerentanan yang diketahui di OSS.

Menurut studi Synopsys, industri Internet of Things (IoT) adalah salah satu pengguna open source tertinggi, dengan 100% basis kode di sektor ini berisi kode sumber terbuka. Namun, 64% dari basis kode IoT ditemukan mengandung kerentanan.

Martin mencatat bahwa open source tidak pernah dimaksudkan untuk bersaing dengan kode kepemilikan tradisional. “Saat ini, banyak pengembang perangkat lunak dan entitas yang ingin mengintegrasikan open source dengan sistem operasi dan aplikasi yang ada,” katanya. “Ini berbeda dengan inkompatibilitas yang bisa terjadi karena perbedaan elemen seperti format data. Pada akhirnya, integrasi open source bisa terjadi selama pengembangannya ada.”

Dia menambahkan bahwa bahkan industri yang paling diatur, seperti sektor publik dan lembaga keuangan, mengadopsi konsep bahwa open source adalah cara terbaik untuk mendorong inovasi, merekrut, dan mempertahankan talenta terbaik, dan platform teknologi masa depan.

CAKUPAN TERKAIT

Leave a Reply

Your email address will not be published. Required fields are marked *