Para pengembang secara rutin memanfaatkan kode pihak ketiga untuk mengembangkan aplikasi mereka demi efisiensi dan penghematan waktu. Namun, ketergantungan pada komponen eksternal ini, terutama perangkat lunak sumber terbuka (OSS), menimbulkan risiko yang signifikan, termasuk kerentanan dan masalah lisensi. Menurut survei GitHub tahun 2023, 31% pengembang menganggap menemukan dan memperbaiki kerentanan keamanan sebagai tugas terpenting kedua mereka, tepat setelah menulis kode (32%).
Akibatnya, banyak organisasi merasa khawatir akan ketergantungan mereka pada OSS karena perangkat lunak tersebut sering menjadi sasaran para peretas. Organisasi-organisasi tersebut menghadapi tantangan berupa meningkatnya kerentanan di seluruh rantai pasokan perangkat lunak serta kesulitan dalam memahami cara memitigasi risiko secara efektif pasca serangkaian serangan besar-besaran yang terjadi belakangan ini.
Sebuah laporan penelitian dari ESG mengungkapkan bahwa 91% organisasi telah mengalami insiden rantai pasokan perangkat lunak dalam 12 bulan terakhir. Insiden yang paling umum antara lain:
Kerentanan-kerentanan menonjol seperti Log4J, Curl, Apache Struts, dan OpenSSL semuanya telah menyebabkan banyak kasus kerugian operasional. Hal ini menyoroti dampak serius yang dihadapi organisasi ketika satu kelemahan dalam rantai pasokan perangkat lunak dimanfaatkan. Menanggapi risiko yang semakin meningkat ini, badan-badan pengatur di seluruh dunia semakin menekankan transparansi dan keamanan perangkat lunak. Penerapan Software Bill of Materials (SBOM) semakin menjadi strategi kunci dalam mengelola risiko rantai pasokan perangkat lunak.
Peraturan SBOM Semakin Mendapat Dukungan
Peraturan terkait SBOM semakin meluas. Banyak pemerintah telah menerbitkan rekomendasi mengenai penerapan SBOM. Di AS, rekomendasi terkait SBOM dimuat dalam beberapa pedoman pemerintah, antara lain:
Di Eropa, Badan Keamanan Siber Uni Eropa (ENISA) telah menerbitkan “Pedoman untuk Mengamankan Rantai Pasokan Perangkat Lunak ( Supply Chain ) untuk Internet of Things,” yang memberikan wawasan berharga kepada organisasi dalam meningkatkan keamanan siber dan mengelola risiko rantai pasokan yang terkait dengan perangkat lunak.
Negara-negara lain juga telah menerbitkan pedoman serupa, antara lain:
Merekomendasikan agar organisasi menggunakan SBOM untuk menilai risiko yang terkait dengan komponen perangkat lunak yang mereka gunakan serta untuk mengidentifikasi dan menangani kerentanan pada komponen-komponen tersebut.
Dalam “Panduan Keamanan Informasi: Pedoman Pengembangan Daftar Komponen Perangkat Lunak ( Software ),” ACSC merekomendasikan penggunaan SBOM untuk meningkatkan transparansi rantai pasok siber, sehingga memudahkan identifikasi dan pengelolaan risiko keamanan yang terkait dengan masing-masing komponen perangkat lunak yang digunakan dalam aplikasi.
Bagaimana PCI DSS Mengharuskan Pembuatan SBOM
Menyadari meningkatnya risiko terhadap data kartu pembayaran, Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) telah menjadi pendorong utama dalam penerapan SBOM. Versi terbaru, PCI DSS 4.0, mewajibkan penggunaan SBOM, yang menegaskan peran krusialnya dalam melindungi informasi sensitif. Dengan menyediakan inventarisasi terperinci mengenai komponen perangkat lunak, SBOM memungkinkan organisasi untuk mengidentifikasi dan menangani kerentanan secara proaktif, sehingga mengurangi risiko kebocoran data yang merugikan dan kerugian finansial.
Ditetapkan pada tahun 2004, PCI DSS merupakan standar keamanan komprehensif yang dirancang untuk melindungi informasi kartu kredit. Standar ini menetapkan serangkaian persyaratan ketat bagi perusahaan yang menangani transaksi kartu kredit, yang disesuaikan dengan volume transaksi yang diproses setiap tahun. Rilis PCI DSS v4.0 tahun 2022 memperkenalkan perubahan signifikan, termasuk kewajiban SBOM, untuk mengatasi ancaman yang terus berkembang. Kepatuhan terhadap PCI DSS v4.0 wajib dipenuhi paling lambat April 2024, dengan persyaratan tertentu yang akan diberlakukan secara bertahap hingga 31 Maret 2025.
Sumber: Sekilas tentang PCI DSS V4.0
Dengan mewajibkan penggunaan SBOM, PCI DSS memberdayakan organisasi untuk memperoleh pemahaman menyeluruh mengenai ekosistem perangkat lunak mereka, sehingga memungkinkan mereka mengidentifikasi dan menangani kerentanan secara proaktif. Pendekatan ini secara signifikan mengurangi risiko kebocoran data yang merugikan dan kerugian finansial.
Versi terbaru PCI DSS, yaitu versi 4.0.1, telah dirilis pada pertengahan tahun 2024. Hal ini berarti versi sebelumnya, yaitu 4.0, tidak akan berlaku lagi setelah 31 Desember 2024. Namun, versi baru ini tidak menambahkan maupun menghapus aturan apa pun dan tidak mengubah tenggat waktu yang berlaku. Oleh karena itu, informasi mengenai persyaratan SBOM dalam blog ini berlaku untuk kedua versi, yaitu versi 4.0 dan 4.0.1.
Mematuhi Persyaratan PCI DSS 6.3.2
Persyaratan SBOM dalam PCI DSS v4.0 merupakan bagian dari penyempurnaan yang lebih luas yang dilakukan terhadap PCI DSS dalam versi terbarunya. Diperkenalkan sebagai bagian dari 64 persyaratan baru yang ditambahkan dalam versi 4.0, persyaratan SBOM secara khusus menyoroti kebutuhan organisasi untuk menyimpan daftar inventaris komponen perangkat lunak, dengan fokus khusus pada perangkat lunak yang dibuat khusus dan disesuaikan.
Persyaratan ini termasuk dalam Persyaratan PCI DSS Nomor 6 yang mewajibkan pembuatan dan pemeliharaan sistem serta aplikasi yang aman melalui penerapan langkah-langkah keamanan yang ketat serta pelaksanaan penilaian kerentanan dan pembaruan secara berkala. Persyaratan ini sangat penting untuk mengurangi risiko yang ditimbulkan oleh kerentanan perangkat lunak dan melindungi data pemegang kartu. Bagian 6 mencakup lima bidang utama:
- 6.1 Proses dan mekanisme untuk mengembangkan serta memelihara sistem dan perangkat lunak yang aman telah ditetapkan dan dipahami.
- 6.2 Perangkat lunak yang dirancang khusus dan sesuai pesanan dikembangkan dengan aman.
- 6.3 Kerentanan keamanan telah diidentifikasi dan ditangani.
- 6.4 Aplikasi web yang dapat diakses publik terlindungi dari serangan.
- 6.5 Perubahan pada semua komponen sistem dikelola dengan aman.
Secara lebih spesifik, persyaratan 6.3.2 merupakan pembaruan penting yang muncul sebagai akibat dari beberapa insiden pelanggaran, di mana kerentanan pada komponen pihak ketiga, atau pelanggaran yang dialami oleh penyedia komponen pihak ketiga, mengakibatkan kebocoran data pemegang kartu. Persyaratan tersebut berbunyi sebagai berikut:
6.3.2.b Periksa dokumentasi perangkat lunak, termasuk untuk perangkat lunak yang dikembangkan khusus dan perangkat lunak kustom yang mengintegrasikan komponen perangkat lunak pihak ketiga, serta bandingkan dengan daftar inventaris untuk memastikan bahwa daftar inventaris tersebut mencakup perangkat lunak yang dikembangkan khusus dan perangkat lunak kustom serta komponen perangkat lunak pihak ketiga tersebut.
Organisasi harus mendokumentasikan dan mengelola komponen serta layanan spesifik yang digunakan dalam aplikasi mereka secara menyeluruh. Meskipun sebagian informasi ini mungkin telah tercakup dalam diagram alur data, persyaratan baru menuntut dokumentasi yang jauh lebih rinci. Melacak detail-detail ini bisa menjadi tantangan seiring dengan pembaruan dan perubahan komponen. Disarankan untuk menggunakan templat standar guna mencatat informasi ini. Selain itu, beberapa repositori kode sumber, seperti GIT, mungkin menyediakan alat untuk mengekspor daftar komponen yang sedang digunakan. Setidaknya, inventaris Anda harus mencakup:
- Komponen Aplikasi (biasanya berupa proyek repositori)
- Daftar komponen pihak ketiga
- Daftar dependensi aplikasi (misalnya Tomcat, JBoss, .NET, middleware)
- Daftar Skrip Halaman Pembayaran yang Diizinkan
Bagaimana SBOM dari OPSWAT Dapat Membantu Memenuhi Persyaratan PCI DSS
Peraturan semakin mewajibkan penggunaan SBOM untuk menjamin keamanan rantai pasokan perangkat lunak. Namun, berbagai organisasi masih mengalami kesulitan dalam menyusun inventarisasi yang akurat mengenai komposisi kode perangkat lunak mereka.
Sumber: Laporan EGS 2024
Namun, penyusunan SBOM yang akurat dan komprehensif menjadi tantangan besar bagi organisasi. Dokumen-dokumen ini menuntut inventarisasi komponen perangkat lunak yang cermat, sehingga memerlukan informasi terperinci mengenai asal-usul, versi, dan saling ketergantungan di antara komponen-komponen tersebut. Tanpa SBOM yang akurat, organisasi akan kesulitan untuk secara efektif mengidentifikasi, menilai, dan memitigasi risiko yang melekat dalam rantai pasokan perangkat lunak mereka.
Pedoman untuk Membuat SBOM
OPSWAT SBOM mengotomatiskan pembuatan SBOM baik untuk kode maupun kontainer, sehingga meningkatkan keamanan dan mendukung kepatuhan dalam rantai pasokan perangkat lunak.
- Identifikasi Semua Komponen dan Ketergantungan
Identifikasi secara akurat semua komponen perangkat lunak, termasuk pustaka sumber terbuka dan pihak ketiga, beserta versi dan ketergantungannya. Hal ini menjadi dasar bagi SBOM yang kokoh. - Menilai Risiko OSS
Evaluasi risiko potensial yang terkait dengan komponen OSS. Pertimbangkan faktor-faktor seperti kepatuhan lisensi, kerentanan keamanan, dan status pemeliharaan. Prioritaskan komponen berdasarkan tingkat kritisitasnya terhadap perangkat lunak. - Pemindaian Kerentanan OSS
Gunakan alat pemindaian kerentanan dan alat pembuat SBOM untuk mengidentifikasi kerentanan yang diketahui dalam komponen OSS. Prioritaskan kerentanan berdasarkan tingkat keparahan dan potensi dampaknya terhadap perangkat lunak.
Menggunakan SBOM dari OPSWAT
OPSWAT SBOM mengotomatiskan pembuatan SBOM baik untuk kode maupun kontainer, sehingga meningkatkan keamanan dan mendukung kepatuhan dalam rantai pasokan perangkat lunak.
Berikut ini cara memanfaatkan SBOM OPSWAT untuk membuat SBOM secara efektif:
Dengan menyediakan daftar lengkap semua pustaka dan komponen sumber terbuka yang digunakan dalam suatu aplikasi, SBOM OPSWAT membantu mengelola kerentanan ketergantungan dalam rantai pasokan perangkat lunak, sehingga memungkinkan pengguna untuk mengidentifikasi dan memperbaiki kerentanan dalam aplikasi secara efisien.
Selain mengidentifikasi kerentanan, SBOM dari OPSWAT juga memverifikasi lisensi yang terkait dengan setiap komponen perangkat lunak. Hal ini memastikan kepatuhan terhadap ketentuan lisensi dan mencegah potensi masalah hukum. Pelajari lebih lanjut tentang peran penting deteksi lisensi dalam perangkat lunak sumber terbuka (OSS).
OPSWAT SBOM mendukung lebih dari 10 bahasa pemrograman, termasuk Java, JavaScript, Go, PHP, dan Python. Dukungan yang luas ini memastikan pelacakan asal-usul perangkat lunak ( vulnerability detection ) yang komprehensif di berbagai ekosistem pengembangan perangkat lunak.
Sanksi atas Ketidakpatuhan
Organisasi yang tidak mematuhi standar PCI DSS, termasuk persyaratan SBOM, dapat dikenai sanksi finansial sebesar $5.000 hingga $100.000 per bulan. Denda ini dapat meningkat seiring berjalannya waktu jika masalah kepatuhan tetap tidak terselesaikan.
Selain sanksi finansial, ketidakpatuhan terhadap PCI DSS dapat menimbulkan tantangan hukum dan operasional yang signifikan. Konsekuensi hukumnya dapat mencakup gugatan hukum, biaya pembelaan, dan pembayaran ganti rugi yang besar. Selain itu, ketidakpatuhan dapat memicu audit federal oleh lembaga-lembaga seperti Komisi Perdagangan Federal (FTC), yang berujung pada sanksi tambahan.
Langkah-Langkah Selanjutnya untuk Kepatuhan terhadap PCI DSS 4.0
Integrasi SBOM ke dalam kerangka kerja PCI DSS 4.0 menandai perubahan penting menuju rantai pasokan perangkat lunak yang lebih aman. Dengan memanfaatkan alat canggih seperti OPSWAT SBOM, organisasi dapat mengelola risiko perangkat lunak sumber terbuka secara efektif, meningkatkan kepatuhan, dan melindungi diri dari kebocoran data yang merugikan.
Pemanfaatan SBOM bukan lagi sekadar pilihan, melainkan suatu keharusan. Dengan mengambil langkah-langkah proaktif untuk memahami dan menangani ketergantungan perangkat lunak, organisasi dapat membangun fondasi keamanan yang kokoh yang melindungi operasional mereka dan membangun kepercayaan pelanggan.
Tingkatkan Keamanan dan Postur
Anda dengan OPSWAT
Mulailah mengelola dependensi open-source
sekarang juga.
