Apa itu Software Bill of Materials (SBOM)?

Bill of Material perangkat lunak (SBOM) adalah daftar terperinci dan komprehensif dari semua komponen dalam aplikasi perangkat lunak, termasuk penggunaan perangkat lunak sumber terbuka, dependensi komponen, lisensi, dan kerentanan yang diketahui. SBOM menyediakan inventaris dari setiap komponen individu yang terdiri dari aplikasi, seperti daftar bahan dalam resep. SBOM mulai mendapatkan daya tarik pada tahun 2018 sebagai upaya kolaboratif oleh komunitas keamanan informasi dan sebagian besar telah didorong oleh Administrasi Telekomunikasi dan Informasi Nasional (NTIA) dan pemerintah AS dalam beberapa tahun terakhir.

SBOM adalah dokumen yang sangat penting yang memberikan informasi penting bagi organisasi yang ingin meminimalkan dan mengurangi risiko rantai pasokan operasional, hukum, dan perangkat lunak mereka, tetapi banyak organisasi masih menghadapi tantangan dalam menerapkan SBOM ke dalam proses yang ada atau tidak menyadari manfaatnya. Artikel ini akan membahas bagaimana SBOM dapat membantu organisasi menjadi lebih terinformasi tentang perangkat lunak yang mereka gunakan dan mengapa SBOM harus diadopsi sebagai praktik terbaik.

Cari tahu bagaimana UpGuard membantu bisnis mendapatkan visibilitas yang lebih baik tentang kerentanan perangkat lunak mereka >

Mengapa SBOM Penting?

Karena rata-rata bisnis menggunakan lebih dari 130 aplikasi SaaS dalam operasi sehari-hari dan perusahaan yang lebih besar dapat menggunakan lebih dari 200 aplikasi setiap hari, SBOM menjadi lebih penting untuk mengurangi risiko keamanan. Semakin banyak aplikasi yang digunakan organisasi setiap hari, semakin banyak eksposur risiko yang dihadapi organisasi. Jika satu aplikasi atau komponen dilanggar karena kerentanan, itu berpotensi membahayakan seluruh rantai pasokan perangkat lunak.

SBOM membantu organisasi mengidentifikasi risiko operasional dan keamanan yang terkait dengan perangkat lunak tertentu, serta mendapatkan visibilitas lebih lanjut ke dalam komposisi perangkat lunak. Organisasi dapat mengelola kerentanan dengan lebih baik, mematuhi lisensi, dan melakukan tugas manajemen perangkat lunak penting lainnya dengan mengetahui dengan tepat apa yang ada di dalam produk perangkat lunak. SBOM menjadi alat yang semakin penting dalam dunia keamanan siber, siklus hidup pengembangan perangkat lunak (SDLC), dan proses DevSecOps.

Pada Mei 2021, pemerintah federal AS mengeluarkan Perintah Eksekutif 14028, yang mewajibkan semua lembaga pemerintah AS untuk hanya berurusan dengan vendor perangkat lunak yang menyediakan SBOM. Undang-undang baru ini merupakan bagian dari upaya keamanan siber yang lebih besar untuk mengamankan infrastruktur digital negara dan mendorong lebih banyak vendor perangkat lunak untuk memastikan produk dibangun dengan aman. EO 14028 juga memberi insentif kepada vendor untuk memenuhi standar keamanan siber federal, karena kontrak pemerintah berpotensi menjadi peluang yang menguntungkan.

Aplikasi dan layanan perangkat lunak modern dibangun dengan komponen dan dependensi yang berbeda dari berbagai sumber. Komponen dan dependensi tersebut mungkin termasuk perangkat lunak sumber terbuka, kode berpemilik, API khusus, kerangka kerja bahasa pemrograman, dan pustaka perangkat lunak. Keseluruhan sumber yang membentuk aplikasi perangkat lunak dianggap sebagai bagian dari rantai pasokan perangkat lunak.

Bill of material perangkat lunak berbeda dari metadata perangkat lunak karena metadata perangkat lunak dapat memberikan informasi lebih lanjut tentang penggunaan dan tujuan aplikasi yang lebih luas, sementara SBOM berfokus pada masing-masing komponen dalam aplikasi dan dependensinya.

Organisasi juga mengandalkan SBOM mereka untuk mengatasi:

Kepatuhan hukum
Performa keamanan siber
Manajemen risiko
Respons insiden
Efisiensi operasional
Manajemen kerentanan

Apa yang Termasuk SBOM?

Administrasi Telekomunikasi dan Informasi Nasional (NTIA) mengeluarkan panduan yang merinci elemen minimum untuk SBOM, termasuk bidang-bidang dasar berikut:

Nama dan versi komponen: Setiap komponen perangkat lunak harus diidentifikasi dan dicantumkan, termasuk nama, nomor versi, informasi lisensi, nama pemasok, penulis, dan stempel waktu saat data SBOM dibuat. Informasi ini memungkinkan organisasi untuk memastikan bahwa mereka menggunakan versi terbaru dan paling aman dari setiap komponen. Jika komponen atau subkomponen diperbarui, SBOM harus diperbarui dan diterbitkan ulang.
Dependensi perangkat lunak: SBOM harus menyertakan pohon dependensi antara komponen perangkat lunak, termasuk dependensi transitif, untuk mempertahankan fungsionalitas perangkat lunak dan untuk mendukung praktik manajemen dependensi yang efisien. Jika dependensi berubah atau komponen menjadi usang, SBOM harus diperbarui untuk mencerminkan perubahan tersebut.
Otomasi: NTIA merekomendasikan tingkat otomatisasi minimum untuk pembuatan SBOM dan transfer data sehingga sistem lain dapat memahami dan menggunakan data SBOM yang dihasilkan. Karena aplikasi perangkat lunak bisa sangat kompleks, NTIA sangat menyarankan untuk tidak membuat SBOM menggunakan proses manual.
Proses: SBOM memerlukan proses pengumpulan data berkelanjutan yang menentukan bagaimana SBOM dihasilkan, bagaimana mereka diakses, dan siapa yang memiliki izin untuk mengaksesnya.
Lisensi perangkat lunak sumber terbuka: Jika perangkat lunak menggunakan lisensi perangkat lunak sumber terbuka, penting untuk mendokumentasikan jenis lisensi setiap komponen, serta syarat dan ketentuan, untuk mencegah masalah hukum. Organisasi dapat memastikan mereka mematuhi syarat dan ketentuan yang ditetapkan oleh pembuat komponen dengan melacak semua lisensi. Selain itu, data lisensi memungkinkan organisasi untuk melacak kerentanan atau eksploitasi kode sumber terbuka dan memperbaikinya sebelum dapat mengakibatkan pelanggaran dunia maya.
Kerentanan yang diketahui: Mencantumkan kerentanan keamanan yang diketahui untuk setiap komponen membantu organisasi mengurangi potensi risiko dan meningkatkan keamanan perangkat lunak mereka secara keseluruhan. Informasi ini memungkinkan tim TI untuk memprioritaskan pembaruan dan tambalan untuk menjaga lingkungan perangkat lunak yang aman.

Format SBOM Standar

Ada beberapa format standar untuk membuat dan berbagi SBOM. Format standar memberikan konsistensi untuk data SBOM di seluruh rantai pasokan perangkat lunak, mempromosikan transparansi penuh dan kolaborasi antara pemangku kepentingan yang berbeda. Format SBOM yang paling umum digunakan saat ini meliputi:

CycloneDX, dikembangkan oleh Open Web Application Security Project (OWASP)
Tag Identifikasi Perangkat Lunak (SWID), dikembangkan oleh NIST

Software Package Data Exchange (SPDX), dikembangkan oleh ISO/IEC di bawah ISO/IEC 5962

Manfaat Penerapan SBOM

Penerapan SBOM bisa menjadi proses yang sulit, tetapi dapat memberikan banyak manfaat yang dapat membantu organisasi menjaga keamanan mereka dengan lebih baik dan meminimalkan risiko jangka panjang, termasuk:

Postur keamanan yang ditingkatkan: SBOM memberikan kedalaman dan visibilitas lebih lanjut ke dalam komponen perangkat lunak, yang membantu organisasi mengidentifikasi, melacak, dan memulihkan kerentanan yang diketahui.
Kepatuhan lisensi: SBOM membantu organisasi memenuhi persyaratan lisensi dengan melacak semua komponen kepemilikan dan sumber terbuka yang digunakan. Informasi lisensi ini juga membantu organisasi memenuhi persyaratan hukum dan standar peraturan.
Transparansi rantai pasokan: Membangun transparansi perangkat lunak sangat penting bagi organisasi saat mereka mulai berkembang. Memahami sumber setiap produk perangkat lunak memungkinkan organisasi untuk menilai dengan benar kepercayaan dan keamanan setiap komponen.
Audit perangkat lunak yang efisien: Audit perangkat lunak harus dilakukan secara teratur untuk menilai kepatuhan, efektivitas, kekritisan, dan kebutuhan produk. SBOM membantu memfasilitasi proses ini dengan menyediakan daftar lengkap dari setiap komponen yang digunakan, menghemat waktu dan sumber daya yang diperlukan untuk menyelesaikan audit.
Manajemen risiko dan kerentanan yang efektif: Melacak setiap komponen yang digunakan dalam aplikasi perangkat lunak memungkinkan bisnis untuk mengidentifikasi potensi risiko dan mengurangi atau memperbaikinya sebelum dapat dieksploitasi.

Tantangan Penerapan SBOM

Meskipun SBOM dapat membantu ekosistem TI bisnis tetap teratur, banyak proses masih distandarisasi dan didefinisikan. Karena masih ada variasi dalam pembuatan dan penggunaan SBOM, organisasi mungkin mengalami beberapa tantangan dan inefisiensi awal, seperti:

Proses implementasi dan pemeliharaan yang kompleks: Perusahaan besar yang menggunakan berbagai macam dan jumlah produk perangkat lunak dan basis kode mungkin menghadapi tantangan yang signifikan dalam memperoleh SBOM untuk setiap aplikasi. Pada gilirannya, pemasok perangkat lunak juga ditugaskan dengan pekerjaan tambahan saat menghasilkan SBOM, terutama ketika perangkat lunak diperbarui. Produk perangkat lunak yang sering diperbarui berarti SBOM juga harus sering diperbarui.
Kurangnya standarisasi: Karena SBOM masih merupakan praktik yang relatif baru, masih ada masalah standarisasi, yang dapat menyebabkan inkonsistensi antara format dan masalah kompatibilitas antara jenis alat dan platform yang digunakan selama pembuatan data.
Sangat intensif sumber daya: Banyaknya pekerjaan yang diperlukan untuk menghasilkan dan memelihara SBOM berarti bahwa pemasok harus mendedikasikan waktu dan sumber daya yang signifikan untuk tugas tersebut. Selain itu, personel khusus dalam setiap tim keamanan perlu dilatih, yang dapat menjadi tantangan bagi organisasi yang lebih kecil dengan prioritas yang lebih tinggi. Organisasi yang menggunakan perangkat lunak juga akan membutuhkan tim atau individu khusus untuk melacak SBOM untuk memasukkannya ke dalam proses pengadaan dan audit.
Keamanan data SBOM: Setiap dokumen SBOM berisi informasi penting tentang komponen perangkat lunak, yang dapat menyebabkan peluang pelanggaran baru bagi pemasok dan organisasi yang menggunakan aplikasi. Data SBOM harus dijaga kerahasiaan dan aman, dengan proses keamanan internal baru yang menentukan keamanan datanya.
Kurangnya kemampuan integrasi: Karena SBOM masih belum menjadi praktik umum, mengintegrasikan prosesnya dengan pengembangan dan penerapan perangkat lunak yang ada mungkin tidak mungkin atau bisa sangat menantang. Namun, lebih banyak kemampuan integrasi perangkat lunak dapat dicapai karena semakin banyak organisasi mengadopsi SBOM ke dalam proses mereka.
Partisipasi vendor: Dengan organisasi yang berpotensi bekerja dengan ratusan atau ribuan vendor yang memasok aplikasi perangkat lunak, mendapatkan penyedia pihak ketiga untuk mengadopsi proses baru dan menghasilkan SBOM yang diperbarui dan akurat dapat terbukti sulit, terutama jika mereka tidak melihat manfaatnya atau merasa bahwa pekerjaan ekstra tidak diperlukan. Selain itu, penyedia perangkat lunak mungkin tidak ingin memberikan detail komponen jika mereka merasa bahwa mereka mengungkapkan informasi rahasia dan berpemilik.