Mengapa SBOM telah menjadi elemen penting dari manajemen risiko rantai pasokan [Q&A]

Dalam beberapa tahun terakhir, software bill of material (SBOM) telah menjadi elemen kunci keamanan perangkat lunak dan manajemen risiko rantai pasokan perangkat lunak.

Kami berbicara dengan Tim Mackey, kepala strategi risiko rantai pasokan perangkat lunak di Synopsys untuk mengetahui lebih lanjut tentang manfaat dan tantangan SBOM.

BN: Apa realisasi utama yang muncul sebagai akibat dari kerentanan Log4shell?

TM: Pengalaman Log4Shell menyoroti bahwa penggunaan sumber terbuka meluas di dalam organisasi. Bahkan perangkat lunak komersial ditemukan memiliki komponen open source sebagai dependensi. Hal ini membuat fokus lebih tajam bahwa proyek sumber terbuka dibuat dan dikelola oleh sukarelawan eksternal, dan bukan karyawan mereka sendiri atau vendor komersial pihak ketiga. Ini berarti TI tidak memiliki kendali atas penggunaan perangkat lunak sumber terbuka dalam perangkat lunak komersial — bahkan jika mereka memiliki proses tata kelola sumber terbuka yang matang untuk perangkat lunak sumber terbuka yang mereka unduh dan gunakan secara langsung, atau yang digunakan dalam upaya pengembangan perangkat lunak kustom mereka.

BN: Apa yang perlu dipahami organisasi tentang open source agar lebih siap menghadapi tantangan unik yang dibawanya?

TM: Langkah pertama seringkali hanya mengenali bahwa Anda menggunakan sumber terbuka dan dari sana Anda dapat menentukan alur kerja tata kelola yang dapat diterapkan. Karena tim sumber terbuka tidak mengetahui siapa yang mengunduh kodenya, Anda tidak memiliki mekanisme push untuk pembaruan; Anda memiliki mekanisme tarik. Jadi, ketika sebuah proyek ditinggalkan secara efektif, atau pada akhir masa pemeliharaannya, kami akan senang jika pengelola tersebut pergi dan berkata, “Hei, saya sudah selesai dengan proyek ini,” dan memberi sedikit pemberitahuan yang bagus di atasnya dengan mengatakan tidak akan ada pembaruan baru, tetapi itu biasanya tidak terjadi.

Sekarang, mampu mengidentifikasi proyek ‘ditinggalkan’ versus ‘selesai’ adalah masalah tersendiri. Anda tidak dapat membuat keputusan itu jika Anda tidak terlibat dengan proyek tersebut, jadi jika Anda tidak tahu bahwa Anda sedang menggunakan proyek, pergilah dan mulailah mengajukan pertanyaan-pertanyaan ini. Dan itulah bagian besar pertama dari teka-teki ini — terimalah bahwa Anda memiliki sumber terbuka, terimalah bahwa itu dikelola secara berbeda dan lakukan proses yang mencakup keterlibatan dengan proyek tersebut.

Di mana hal-hal menjadi sangat menantang adalah ketika Anda mengatakan, tiga atau empat tingkat dalam ketergantungan atau rantai pemasok yang Anda mungkin tidak perlu tahu bahwa Anda menjalankan kode sumber terbuka. Itulah salah satu pelajaran dari seluruh pengalaman Log4j, orang tidak tahu bahwa ada hal yang disebut Log4j sebelum masalah terjadi.

BN: Apa sebenarnya SBOM itu?

TM: SBOM pada dasarnya adalah file yang mencantumkan pustaka yang digunakan oleh suatu aplikasi. Ini adalah komponen kunci dari rencana tata kelola yang tidak hanya mencakup penggunaan sumber terbuka dalam rantai pasokan perangkat lunak, tetapi juga menjadi titik jangkar untuk elemen operasional lainnya. Elemen operasional paling umum yang dibahas saat ini adalah penggunaan SBOM untuk mengkomunikasikan paparan kerentanan di dalam komponen dalam rantai pasokan perangkat lunak untuk aplikasi yang diberikan.

BN: Apakah SBOM sendiri cukup untuk memitigasi risiko keamanan dan perizinan Sumber terbuka?

TM: Tidak. Karena SBOM ditampilkan dalam Perintah Eksekutif, banyak perhatian diberikan kepada, ‘Saya harus pergi dan memiliki SBOM.’ Untuk tujuan praktis, banyak organisasi saat ini membuat SBOM dan ini hanyalah sebuah tagihan material yang mengatakan, “Saya memiliki komponen ini yang berasal dari tempat ini, dan ini adalah versinya.”

Ini sebenarnya adalah hal yang statis. Ini mewakili seperti apa perangkat lunak itu ketika dikirimkan. Ini luar biasa dalam hal itu, tetapi tidak akan memberi tahu Anda apakah itu lebih aman atau kurang aman daripada yang lain. Ini benar-benar memberi tahu Anda seperti apa daftar bahan itu untuk perangkat lunak tertentu itu, dan di situlah orang-orang sedikit tertipu. SBOM yang dibicarakan semua orang bukanlah unicorn ajaib ini — ini adalah bagian dari alur kerja yang perlu diterapkan di dalam perusahaan.

‘SB’ di SBOM tidak berarti Silver Bullet.

Masalahnya adalah data SBOM perlu masuk ke alur kerja. Orang-orang yang menerima SBOM mungkin berkata, “Di sini, saya mendapatkan file ini yang saya tidak tahu apa yang harus dilakukan,” dan itu berbicara tentang alur kerja — serangkaian proses yang perlu dilakukan organisasi Cari tahu.

Dengan kata lain, pengetahuan yang diberikan oleh SBOM jelas berharga, tetapi jika organisasi Anda tidak memiliki proses untuk menggunakannya, maka manfaat minimal dari memiliki SBOM dan informasi kerentanan terkait. Kurangnya proses inilah yang menjadi tantangan terbesar sementara tim pengadaan dapat meminta SBOM dari semua pemasok mereka, jika tidak ada proses yang terdefinisi dengan baik untuk menindaklanjuti informasi di SBOM, maka semua yang terjadi adalah Anda telah sekarang punya satu file lagi di direktori.

BN: Seperti apa proses yang sukses dan terdefinisi dengan baik untuk mendapatkan nilai dari SBOM?

TM: Semua organisasi memiliki departemen TI yang bertanggung jawab memelihara tambalan dalam perangkat lunak yang ada di dalam organisasi tersebut. Semua perangkat lunak dibangun dari komponen. Kami tahu dari laporan Synopsys OSSRA bahwa penggunaan open source dalam perangkat lunak komersial rata-rata mencapai 78 persen. Jadi, Anda tahu akan ada komponen yang open source dan perlu diperbarui. SBOM mengomunikasikan informasi tersebut jika dilampirkan pada aset yang dikelola TI.

Sekarang, ketika saatnya tiba bahwa ada pengungkapan kerentanan baru, TI berada dalam posisi untuk pergi dan menanyakan sistem manajemen SBOM itu dan berkata, “A-ha – saya punya ini, tetapi dari mana tambalan saya berasal?” Tambalan tersebut berasal dari informasi asal SBOM — itulah peran SBOM. Itu bukan untuk memberi tahu Anda bahwa Anda memiliki kerentanan baru — ini adalah dokumen yang menjelaskan dengan tepat apa yang ada di artefak yang Anda coba jalankan, dan sekarang Anda dapat melakukan hal yang benar jika Anda memiliki alur kerja itu.

BN: Persyaratan apa yang harus dipenuhi oleh SBOM?

TM: Agar bermanfaat, SBOM harus akurat dan lengkap, dan itu adalah dua masalah yang berbeda tetapi menyelesaikan satu, bergantung pada menyelesaikan yang lain.

Untuk memulai, semua pustaka eksternal yang dikemas dalam aplikasi harus dicatat agar SBOM lengkap, termasuk perangkat lunak sumber terbuka, pustaka pihak ketiga komersial, dan perangkat lunak apa pun yang diperkenalkan melalui kontrak pihak ketiga. Idealnya, SBOM akan diambil dari kode sumber aplikasi, meskipun ini bisa menjadi proses yang sulit tergantung pada bagaimana proses pembuatan aplikasi ditentukan. Misalnya, Anda mungkin memerlukan dua SBOM berbeda saat menyusun aplikasi untuk dua platform berbeda; satu untuk Windows, dan satu untuk Linux.

Sama pentingnya, komponen harus diidentifikasi secara akurat, mengenali segala sesuatu dari titik asalnya hingga versinya. SBOM pihak pertama, yang diambil dari kode sumber aplikasi, paling akurat tetapi ada juga SBOM pihak ketiga. Dalam hal ini, aplikasi dan bukan kode sumber yang dipindai. Hal ini dapat mengakibatkan beberapa informasi hilang karena Anda tidak memiliki kemampuan untuk menentukan versi pustaka yang tepat; dengan demikian, menjadikan metode ini cocok hanya jika SBOM pihak pertama tidak tersedia atau sebagai alat untuk memeriksa ulang SBOM pihak pertama.

BN: Apa yang Anda lihat untuk masa depan SBOM dalam mengatasi kerentanan sumber terbuka dan risiko rantai pasokan perangkat lunak secara keseluruhan?

TM: Kami sangat awal di era SBOM. Sebagian besar vendor masih berupaya membuat SBOM dan itu akan berlanjut di masa mendatang. Namun demikian, sementara vendor yang dapat menyediakan SBOM merupakan indikator ketajaman keamanan open source, itu bukan satu-satunya indikator. Yang penting jika organisasi meminta SBOM dari vendor tetapi tidak memiliki alur kerja untuk memproses SBOM tersebut dan memperoleh nilai darinya, maka meminta vendor menyediakan SBOM menambah biaya tanpa keuntungan.

Menariknya, banyak yang gagal menyadari bahwa kasus penggunaan keamanan untuk SBOM sering sejalan dengan apa yang telah disediakan oleh solusi Software Composition Analysis (SCA). SBOM paling berguna sebagai bagian dari strategi mitigasi risiko secara keseluruhan. Ini kemudian menyiratkan bahwa ada proses untuk mengukur risiko yang disampaikan melalui SBOM dan kemudian beberapa proses untuk mengurangi risiko tersebut.

Kredit gambar: Momius/depositphotos.com