Dalam banyak kasus, setelah kerentanan keamanan berisiko tinggi teridentifikasi dalam suatu produk, tantangan yang lebih besar muncul: bagaimana mengidentifikasi komponen atau produk yang terpengaruh dengan nama yang ditetapkan di National Vulnerability Database (NVD). Itu karena produk perangkat lunak diidentifikasi dalam NVD dengan a enumerasi platform umum (CPE), yang diberikan oleh National Institute of Standards and Technology (NIST), bagian dari Departemen Perdagangan AS.
NVD menggunakan CPE untuk mengidentifikasi komponen perangkat keras dan perangkat lunak berdasarkan string vendor, produk, dan versi. Ketika pengguna perangkat lunak ingin menentukan, melalui NCD, apakah komponen dari produk yang mereka gunakan memiliki kerentanan terkait, mereka harus mengetahui nama CPE yang tepat dari komponen tersebut. Namun, seringkali tidak mungkin menemukan CPE untuk komponen tertentu, baik itu open source atau proprietary.
Dalam kebanyakan kasus, masalah ini membuat tidak mungkin untuk mengotomatisasi banyak proses yang diperlukan untuk keamanan perangkat lunak, seperti menghasilkan bill of material perangkat lunak (SBOM).
Mengapa Sulit Menemukan Kerentanan di NVD
Untuk memahami ruang lingkup masalah, pertimbangkan enam kondisi berikut yang membuatnya sangat sulit, jika bukan tidak mungkin, untuk mencari kerentanan komponen dan produk di NVD, karena ketergantungannya pada CPE sebagai satu-satunya pengidentifikasi.
1. Kerentanan diidentifikasi dalam NVD dengan nomor kerentanan dan paparan umum (CVE), misalnya, "CVE-2022-12345," dan Sistem Penilaian Kerentanan Umum (CVSS) digunakan untuk menetapkan tingkat ancaman pada setiap CVE. CPE biasanya tidak dibuat untuk produk perangkat lunak sampai CVE ditugaskan padanya. Namun, banyak pemasok perangkat lunak tidak pernah melaporkan kerentanan (yang akan menghasilkan CVE), sehingga CPE tidak pernah dibuat untuk produk di NVD.
Ini belum tentu karena produk tidak pernah memiliki kerentanan, namun karena pengembang mungkin tidak melaporkan kerentanan yang ada ke NVD.
Akibatnya, pencarian NVD akan menghasilkan respons "Tidak ada data yang cocok" di kedua skenario berikut:
(i) kerentanan tidak ada pada produk tertentu
(ii) ada kerentanan tetapi tidak pernah dilaporkan oleh pengembang
2. Karena tidak ada pemeriksaan kesalahan yang dilakukan saat nama CPE baru dimasukkan ke dalam NVD, dimungkinkan untuk membuat CPE produk yang tidak mengikuti konvensi penamaan yang konsisten. Akibatnya, saat pengguna menelusuri produk menggunakan CPE yang ditentukan dengan benar, mereka akan menerima pesan kesalahan "Ada 0 data yang cocok". Ini adalah pesan yang sama yang akan mereka terima jika nama CPE asli (di luar spesifikasi) digunakan tetapi tidak ada CVE yang dilaporkan menentangnya.
Saat pengguna menerima pesan ini, bisa berarti ada CPE yang valid untuk produk yang mereka telusuri, tetapi CVE belum pernah dilaporkan untuk produk tersebut, tetapi bisa juga berarti CPE yang mereka masukkan tidak cocok dengan CPE di NVD, dan sebenarnya ada CVE yang dilampirkan pada nama CPE (di luar spesifikasi) yang diserahkan ke NVD.
Pesan kesalahan "Ada 0 catatan yang cocok" juga dapat terjadi jika pengguna salah mengeja nama CPE di bilah pencarian. Dalam hal ini, pengguna tidak memiliki cara untuk mengetahui bahwa pesan tersebut dihasilkan oleh salah ketik, dan sebagai gantinya dapat berasumsi bahwa produk tersebut tidak memiliki kerentanan yang dilaporkan.
3. Seiring waktu, nama produk atau pemasok dapat berubah karena merger atau akuisisi, dan nama CPE untuk produk tersebut juga dapat berubah. Dalam hal ini, jika pengguna menelusuri CPE asli, bukan CPE baru, mereka tidak akan mempelajari tentang kerentanan baru. Seperti sebelumnya, mereka akan menerima pesan “Ada 0 catatan yang cocok”.
4. Ini juga berlaku untuk variasi nama pemasok atau produk yang berbeda, seperti "Microsoft" dan "Microsoft Inc.," atau "Microsoft Word" dan "Microsoft Office Word," dll. Pencarian NVD akan memberikan hasil yang salah.
5. Produk yang sama dapat memiliki beberapa nama CPE di NVD jika dimasukkan oleh orang berbeda yang masing-masing menggunakan iterasi berbeda. Ini dapat membuat hampir tidak mungkin untuk menentukan nama mana yang benar. Lebih buruk lagi, jika CVE telah dimasukkan untuk masing-masing varian CPE, ini akan mengakibatkan tidak adanya nama yang "benar". Salah satu contohnya adalah OpenSSL (mis., "OpenSSL" versus "OpenSSL Framework"). Karena tidak ada satu nama CPE yang mengandung semua kerentanan OpenSSL, pengguna harus mencari secara terpisah untuk setiap variasi nama produk.
6. Dalam banyak kasus, kerentanan hanya akan memengaruhi satu modul perpustakaan. Namun, karena nama CPE ditetapkan berdasarkan produk, bukan modul individual yang dikandungnya, pengguna perlu membaca laporan CVE lengkap untuk menentukan modul mana yang rentan. Jika tidak, hal ini dapat mengakibatkan penambalan atau mitigasi yang tidak perlu, seperti saat modul yang rentan tidak dipasang di produk perangkat lunak yang sedang digunakan, tetapi modul pustaka lainnya dipasang.
Untungnya, grup lintas industri bernama Forum SBM yang mencakup anggota OWASP, The Linux Foundation, Oracle, dan lainnya sedang menangani masalah tersebut dan telah mengembangkan proposal untuk meningkatkan akurasi NVD dengan fokus pada kasus penggunaan otomatis dan modern.
Rekomendasi grup, termasuk adopsi URL paket (purl) untuk perangkat lunak dan Standar GS1 untuk perangkat keras, dirancang untuk membuat cara standar untuk menanyakan NVD secara andal dan menerima informasi akurat tentang kerentanan.
- Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
- Platoblockchain. Intelijen Metaverse Web3. Pengetahuan Diperkuat. Akses Di Sini.
- Sumber: https://www.darkreading.com/vulnerabilities-threats/how-naming-can-change-the-game-in-software-supply-chain-security
