Sistem VP Berbasis Klasifikasi Menargetkan Perubahan Kode Berisiko Tinggi dalam Proyek Hulu

Tabel Tautan

ABSTRAK

I. PENDAHULUAN

II. LATAR BELAKANG

III. DESAIN

• DEFINISI
• TUJUAN DESAIN
• KERANGKA KERJA
• EKSTENSI

IV. PEMODELAN

• PENGKLASIFIKASI
• FITUR

V. PENGUMPULAN DATA

VI. KARAKTERISASI

• LATENSI PERBAIKAN KERENTANAN
• ANALISIS PERUBAHAN PERBAIKAN KERENTANAN
• ANALISIS PERUBAHAN PENYEBAB KERENTANAN

VII. HASIL

• VALIDASI N-FOLD
• EVALUASI MENGGUNAKAN MODE PENERAPAN ONLINE

VIII. DISKUSI

• IMPLIKASI PADA MULTI-PROYEK
• IMPLIKASI PADA KARYA KEAMANAN ANDROID
• ANCAMAN TERHADAP VALIDITAS
• PENDEKATAN ALTERNATIF

IX. KARYA TERKAIT

KESIMPULAN DAN REFERENSI

\ \

III. DESAIN

Bagian ini menguraikan desain kerangka kerja VP (Pencegahan Kerentanan). Desain ini didasarkan pada analisis persyaratan desain esensialnya.

A. DEFINISI

Mari kita definisikan titik peninjauan kode aman dan taksonomi untuk mengklasifikasikan perubahan kode dalam studi ini.

==Titik Peninjauan Kode Aman.== Ini menunjukkan tiga jenis peristiwa yang dapat digunakan untuk memicu pengklasifikasi kita secara otomatis:

(1) perubahan kode awalnya dikirim untuk peninjauan kode (atau ditandai siap untuk ditinjau atau pengujian pra-kirim);

(2) set patch baru dikirim;

(3) dan perubahan kode dikirimkan. Penggunaannya dapat disempurnakan dengan kondisi tambahan (misalnya, pemicu hanya ketika peninjau ditentukan). Pengklasifikasi juga dapat dipicu secara manual dengan beberapa cara (misalnya, dengan menambahkan tag ke deskripsi perubahan, mengklik tombol UI atau kotak centang di layanan

peninjauan kode, atau mengeksekusi perintah shell untuk perubahan kode tertentu yang tersedia di layanan peninjauan kode).

\ ==Klasifikasi Perubahan Kode==. Dalam studi ini, kami mengklasifikasikan perubahan kode ke dalam kategori berikut:

ViC (Perubahan Penyebab Kerentanan) untuk perubahan kode yang awalnya menyebabkan kerentanan.

VfC (Perubahan Perbaikan Kerentanan) untuk perubahan kode yang memperbaiki kerentanan yang ada.

LNC (Perubahan Normal yang Mungkin) untuk perubahan kode yang tidak mungkin menyebabkan kerentanan. Terutama, ini termasuk perubahan yang belum diidentifikasi sebagai ViC yang diketahui pada saat analisis.

Selain itu, VfLs (Baris Perbaikan Kerentanan) adalah subset spesifik dari baris kode sumber yang diedit oleh VfC di mana pengeditan sangat penting untuk menyelesaikan kerentanan.

\ B. TUJUAN DESAIN

Pendekatan kami dirancang untuk kasus penggunaan yang memenuhi kondisi berikut:

Proyek target mengalami kerentanan perangkat lunak yang sering dengan konsekuensi potensial tinggi (misalnya, perbaikan mahal, kerusakan reputasi produk, dan dampak pada pengguna).

Proyek target berfungsi sebagai sumber hulu untuk proyek perangkat lunak hilir yang digunakan untuk membangun banyak produk atau layanan pengguna akhir terintegrasi (misalnya, AOSP untuk smartphone dan TV Android).

Proyek hilir sering kekurangan pengujian keamanan yang ketat (misalnya, fuzzing sistem dengan penganalisis dinamis [19]) karena biaya terkait, keahlian teknis, dan kendala alat.

\ Dengan mendeteksi dan memblokir perubahan kode rentan di proyek target hulu, biaya rekayasa keamanan dikurangi untuk proyek hilir. Pengurangan ini mendorong penggunaan berkelanjutan dari proyek hulu dan menarik adopsi hilir tambahan, mendorong pemilik proyek hulu untuk berinvestasi dalam praktik pencegahan kerentanan.

\ Di bawah kondisi yang ditargetkan, pengklasifikasi yang memperkirakan kemungkinan kerentanan dalam perubahan kode tertentu terbukti efektif. Ketika perkiraan kemungkinan melebihi ambang batas, perubahan kode masing-masing ditandai untuk pengawasan lebih lanjut melalui peninjauan kode aman atau pengujian keamanan yang ketat. Pendekatan kami memfasilitasi deteksi perubahan kode rentan (misalnya, dengan tes keamanan yang gagal) dan akibatnya mencegah integrasi mereka ke dalam repositori.

\ Pendekatan kami juga menawarkan integrasi mulus ke dalam proses peninjauan kode aman pasca-kirim. Perubahan kode yang ditandai oleh pengklasifikasi menjalani peninjauan offline tambahan oleh insinyur keamanan atau pakar domain. Ini meningkatkan kemungkinan deteksi kerentanan dalam perubahan tersebut. Dengan menerapkan pengklasifikasi pasca-pengiriman tetapi pra-rilis, peninjauan keamanan yang ditargetkan dapat fokus pada perubahan kode berisiko tertinggi (berdasarkan perkiraan kemungkinan). Pendekatan kami, dengan demikian, mengoptimalkan proses peninjauan kode aman, mengurangi biaya keamanan secara keseluruhan, sambil mempertahankan postur keamanan yang kuat.

\ Mempertimbangkan kasus penggunaan tersebut, tujuan desain utama untuk pengklasifikasi ditetapkan sebagai berikut:

Recall yang wajar (>75% untuk ViCs). Ini memastikan bahwa mayoritas signifikan (>75%) perubahan kode rentan terdeteksi, secara substansial mengurangi risiko keamanan secara keseluruhan.

Presisi tinggi (>90% untuk ViCs). Karena perubahan kode rentan jarang terjadi, menandai secara keliru 1 dari 10 perubahan kode umumnya dapat diterima untuk peninjau keamanan.

Rasio positif palsu rendah (<2%). Perubahan kode normal seharusnya jarang ditandai untuk mempertahankan proses peninjauan yang efisien bagi pengembang.

Waktu inferensi cepat (misalnya, <1 menit). Ini untuk memungkinkan integrasi yang lancar ke dalam layanan peninjauan kode tanpa menyebabkan penundaan yang terlihat oleh pengembang.

Biaya inferensi rendah. Untuk beroperasi dalam anggaran proyek sumber terbuka tipikal untuk infrastruktur dan alat keamanan, inferensi harus dilakukan tanpa harus menggunakan perangkat keras ML yang kuat atau khusus.

Pelatihan ulang yang jarang. Karena biaya untuk pelatihan ulang model juga penting, pelatihan ulang bulanan hingga sekitar satu juta sampel dianggap dapat diterima. Ini untuk menyeimbangkan pemeliharaan akurasi (vs. pelatihan ulang harian) dengan keterjangkauan untuk sebagian besar proyek sumber terbuka.

\ C. KERANGKA KERJA

Kerangka kerja VP kami berlaku untuk tiga kasus penggunaan berbeda:

==Peninjauan Keamanan Pra-kirim== adalah untuk memanfaatkan VP untuk menilai setiap perubahan kode yang dikirim untuk peninjauan kode dan mengidentifikasi perubahan kode yang kemungkinan rentan untuk peninjauan kode aman tambahan oleh pakar domain keamanan.

==Pengujian Keamanan Pra-kirim== adalah untuk menggunakan VP untuk menilai setiap perubahan kode yang dikirim untuk peninjauan kode dan mengidentifikasi perubahan kode yang kemungkinan rentan untuk pengujian keamanan tambahan (misalnya, analisis statis, analisis dinamis, atau fuzzing) sebelum pengiriman.

==Peninjauan Keamanan Pasca-kirim== adalah untuk menerapkan VP ke semua perubahan kode yang dikirimkan dalam periode yang telah ditentukan (misalnya, harian atau mingguan) dan mengisolasi serangkaian perubahan kode yang kemungkinan rentan untuk inspeksi kode aman mendalam tambahan oleh pakar domain keamanan. Kasus penggunaan ini berbeda dari waktu pasca-kirim yang ada, pengujian keamanan.

\ Skenario kasus penggunaan peninjauan keamanan pra-kirim memiliki kompleksitas tertinggi. Dibandingkan dengan kasus penggunaan pasca-kirim, kasus penggunaan pra-kirim memiliki persyaratan yang lebih ketat untuk waktu inferensi dan pelatihan ulang online (misalnya, langsung terlihat oleh penulis perubahan kode vs. tim jaminan kualitas). Dibandingkan dengan kasus penggunaan pengujian keamanan pra-kirim, kasus penggunaan peninjauan keamanan pra-kirim memiliki persyaratan akurasi yang lebih ketat

(misalnya, positif palsu untuk pengujian keamanan sebagian besar berarti biaya pengujian tambahan). Dengan demikian, ini digunakan sebagai target utama untuk desain kerangka kerja. Untuk mengatasi kasus penggunaan yang dipilih, kerangka kerja VP (Pencegahan Kerentanan) memanfaatkan subsistem kuncinya berikut seperti yang digambarkan dalam Gambar 1:

\ ==Layanan Peninjauan Kode.== Penulis memulai proses peninjauan kode dengan mengunggah perubahan kode mereka ke layanan peninjauan kode yang ditentukan. Mereka kemudian menugaskan peninjau untuk perubahan mereka (lihat langkah 1 dalam Gambar 1). Layanan peninjauan secara otomatis memicu satu atau lebih bot peninjauan sebagai respons terhadap permintaan penulis atau peninjau, atau ketika perubahan kode yang diunggah memenuhi kondisi yang telah ditentukan.

\ ==Bot Peninjauan.== Bot peninjauan yang dipicu mengakses pengeditan spesifik yang dibuat oleh perubahan kode sumber, bersama dengan metadata relevan dari perubahan kode dan kode sumber dasar. Untuk melakukan analisis mendalam, bot biasanya memanfaatkan layanan backend untuk kompilasi, analisis, dan pengujian perubahan terhadap dasar. Bot peninjauan VP baru memanfaatkan kemampuan tersebut dan meneruskan data yang dikumpulkan ke layanan pengklasifikasi. Layanan pengklasifikasi kemudian menentukan apakah perubahan kode sumber yang diberikan kemungkinan rentan atau tidak.

\ ==Layanan Pengklasifikasi.== Ketika layanan pengklasifikasi dipicu, ia menggunakan ekstraktor fitur dan data dari bot peninjauan VP untuk mengekstrak fitur yang relevan dari perubahan kode yang diberikan. Selanjutnya, ia melakukan inferensi menggunakan model untuk memperkirakan seberapa mungkin perubahan kode memiliki kerentanan.

\ Model pengklasifikasi menggunakan fitur yang diekstrak sebagai input dan menghasilkan sinyal output biner (yaitu, '1' menunjukkan kemungkinan rentan dan '0' menunjukkan kemungkinan normal). Sinyal output memandu apakah peninjauan keamanan tambahan (atau pengujian keamanan) bermanfaat untuk perubahan kode. Layanan pengklasifikasi memiliki opsi untuk menggunakan beberapa model, menggabungkan hasil mereka (misalnya, melalui operator logis atau pemungutan suara mayoritas) untuk akurasi yang lebih baik.

\ ==Layanan Notifikasi==. Ketika perubahan kode diklasifikasikan sebagai perubahan yang kemungkinan rentan, layanan notifikasi memposting komentar pada perubahan kode di layanan peninjauan kode. Komentar tersebut memperingatkan penulis perubahan kode dan peninjau yang ada tentang potensi keberadaan kerentanan, mendesak pengawasan ekstra.

\ Jika proyek target mempertahankan kumpulan peninjau keamanan khusus, layanan notifikasi dapat secara otomatis menugaskan anggota kumpulan sebagai peninjau yang diperlukan untuk perubahan kode target. Peninjau yang dipilih dapat menjadi insinyur utama pada rotasi atau dipilih melalui heuristik (misalnya, round robin) untuk distribusi beban kerja peninjauan keamanan yang seimb