VEX: Cara Menilai Dampak Kerentanan pada Produk Software

Ketika sebuah kerentanan baru diumumkan, pemindai keamanan bisa menghasilkan daftar panjang temuan dari berbagai pustaka dan komponen. Namun, tidak setiap temuan otomatis berarti aplikasi yang memakai komponen tersebut dapat diserang. Versi yang rentan mungkin tidak digunakan, kode yang bermasalah mungkin tidak ikut dibangun, atau konfigurasi produk dapat membuat jalur serangan tidak dapat dijangkau. Di sinilah Vulnerability Exploitability eXchange (VEX) membantu tim menjelaskan status kerentanan dalam konteks produk tertentu.

Apa Itu VEX?

VEX adalah pernyataan terstruktur yang menghubungkan kerentanan dengan produk atau komponen dan menyampaikan apakah produk tersebut terdampak, tidak terdampak, sudah diperbaiki, atau masih diselidiki. Pernyataan ini dapat dibuat oleh pemasok perangkat lunak maupun pihak lain yang memiliki bukti dan tanggung jawab penilaian yang jelas. VEX dirancang agar informasi dapat dipertukarkan dan diproses oleh alat, bukan hanya dibaca sebagai paragraf dalam buletin keamanan.

VEX tidak menghapus kerentanan dari pustaka, tidak menggantikan patch, dan bukan sertifikat bahwa produk aman. Fungsinya adalah memberi konteks agar tim tidak menyamakan keberadaan nama paket dalam inventaris dengan bukti bahwa jalur eksploitasi benar-benar tersedia.

Hubungan VEX dengan SBOM dan CVE

Software Bill of Materials (SBOM) menjelaskan komponen yang terdapat dalam sebuah produk. Informasi kerentanan seperti CVE kemudian dapat dicocokkan dengan nama dan versi komponen tersebut. VEX melengkapi proses itu dengan pernyataan mengenai dampak kerentanan terhadap produk tertentu, disertai alasan dan bukti pendukung bila tersedia.

Contohnya, pemindai menemukan pustaka versi lama di dalam aplikasi. SBOM membantu memastikan pustaka itu memang disertakan. Setelah memeriksa konfigurasi dan penggunaan kode, tim dapat menyatakan apakah produk terdampak, tidak terdampak dengan alasan yang dapat dipertanggungjawabkan, sudah diperbaiki pada versi tertentu, atau masih dalam penyelidikan. Untuk memahami inventaris komponennya, gunakan SBOM sebagai sumber awal dan cocokkan hasilnya dengan advisori serta versi produk yang benar-benar dirilis. Gambaran risiko yang lebih luas tersedia dalam artikel tentang serangan rantai pasok software.

Empat Status yang Perlu Dipahami

• Affected: produk terdampak dan memerlukan tindakan penanganan, seperti pembaruan, mitigasi, atau petunjuk khusus.
• Not affected: penilaian menyimpulkan produk tidak terdampak dalam konteks yang dinyatakan. Pernyataan ini perlu didukung alasan yang jelas, bukan sekadar asumsi.
• Fixed: perbaikan telah tersedia atau diterapkan pada versi produk yang disebutkan. Pembaca tetap perlu memeriksa versi mana yang memuat perbaikan.
• Under investigation: penilaian belum selesai sehingga dampaknya belum dapat dipastikan. Status ini sebaiknya disertai rencana tindak lanjut atau waktu pembaruan bila memungkinkan.

Nama status dapat berbeda menurut format VEX yang digunakan. Karena itu, sistem yang mengonsumsi dokumen harus mengikuti spesifikasi formatnya, bukan mengandalkan pencocokan teks sederhana.

Bagaimana Menyusun Pernyataan VEX yang Berguna?

1. Identifikasi produk dengan tepat. Cantumkan nama produk, versi atau rentang versi, serta identitas komponen yang relevan. Pernyataan yang hanya menyebut nama produk tanpa batas versi mudah disalahartikan.
2. Rujuk kerentanan yang spesifik. Sertakan ID CVE atau pengenal lain yang sesuai, serta tautan ke advisori atau sumber teknis yang mendasari penilaian.
3. Nyatakan status dan alasan. Jika produk tidak terdampak, jelaskan dasar teknisnya, misalnya komponen rentan tidak ada, kode rentan tidak disertakan, jalur eksekusi tidak dapat dicapai, atau mitigasi yang relevan telah diterapkan.
4. Catat bukti dan penanggung jawab. Simpan hasil pemeriksaan versi, konfigurasi, pengujian, atau analisis kode yang mendukung keputusan. Tetapkan siapa yang menyetujui pernyataan tersebut.
5. Kelola perubahan status. Perbarui dokumen ketika versi baru dirilis, bukti berubah, atau investigasi selesai. Status lama yang tidak diperbarui dapat menyebabkan tim menunda tindakan yang sebenarnya diperlukan.

Format dan Otomatisasi

Ekosistem VEX memiliki beberapa pendekatan, termasuk OpenVEX, VEX yang direpresentasikan melalui CycloneDX, dan penggunaan VEX dalam Common Security Advisory Framework (CSAF). Pilihan format bergantung pada perangkat yang digunakan, kebutuhan pertukaran dengan pelanggan, dan kemampuan sistem pengelolaan kerentanan. Rujukan awal dapat ditemukan pada panduan minimum VEX dari CISA, spesifikasi OpenVEX, serta kapabilitas VEX CycloneDX.

Untuk otomatisasi, hubungkan SBOM, pemindai kerentanan, inventaris versi produk, dan repositori advisori. Sistem dapat mengelompokkan temuan yang sama dan menampilkan status VEX yang masih berlaku. Meski demikian, keputusan “not affected” sebaiknya tidak dibuat hanya berdasarkan kecocokan nama paket otomatis; analisis konteks tetap dibutuhkan dan setiap pengecualian harus dapat diaudit.

Bukti yang Perlu Dicatat dalam Penilaian VEX

Setiap penilaian VEX sebaiknya menyertakan identitas produk dan versi, pengenal kerentanan seperti CVE, status yang dipilih, waktu penilaian, pihak yang bertanggung jawab, serta ringkasan alasan. Jika statusnya “not affected”, simpan bukti seperti konfigurasi yang menonaktifkan komponen, fungsi rentan yang tidak dipanggil, atau hasil pengujian yang relevan. Pisahkan fakta yang sudah diuji dari asumsi, dan tetapkan kapan penilaian harus ditinjau ulang—misalnya setelah rilis baru atau perubahan penggunaan komponen.

Kesalahan yang Harus Dihindari

• Menggunakan status “not affected” hanya karena belum ada laporan eksploitasi.
• Menerapkan satu pernyataan ke semua versi produk tanpa memeriksa perbedaan konfigurasi atau komponen.
• Membiarkan status “under investigation” tanpa pemilik tindak lanjut.
• Menganggap dokumen VEX yang valid secara format pasti benar secara teknis.
• Tidak menyimpan jejak bukti, waktu penilaian, dan riwayat perubahan.

Kesimpulan

VEX membantu organisasi mengubah daftar kerentanan menjadi penilaian yang lebih kontekstual dan dapat ditindaklanjuti. Ketika dipadukan dengan SBOM, advisori, dan proses respons insiden, VEX dapat mengurangi kebingungan, memprioritaskan perbaikan, serta menjelaskan alasan di balik keputusan keamanan. Mulailah dengan satu produk penting, gunakan format yang dapat diproses alat yang tersedia, dokumentasikan bukti, dan tinjau kembali status setiap kali versi atau informasi kerentanan berubah. Tujuannya bukan mengurangi jumlah temuan di laporan, melainkan membuat keputusan risiko lebih akurat dan transparan.