Google memperkenalkan kerangka kerja SLSA (Supply-chain Levels for Software Artifacts), yang merangkum pengalaman yang ada dalam melindungi infrastruktur pengembangan dari serangan yang dilakukan pada tahap penulisan kode, pengujian, perakitan, dan pendistribusian suatu produk.
Proses pengembangan menjadi semakin kompleks dan bergantung pada alat pihak ketiga, yang menciptakan kondisi yang menguntungkan bagi kemajuan serangan yang tidak terkait dengan mengidentifikasi dan mengeksploitasi kerentanan dalam produk akhir, namun membahayakan proses pengembangan itu sendiri (serangan rantai pasokan, biasanya ditujukan untuk memperkenalkan perubahan berbahaya dalam proses penulisan kode, penggantian komponen terdistribusi dan dependensi).
Kerangka kerja ini memperhitungkan 8 jenis serangan yang terkait dengan ancaman membuat perubahan berbahaya pada tahap pengembangan kode, perakitan, pengujian, dan distribusi produk.
- A. Termasuk perubahan pada kode sumber yang mengandung backdoor atau kesalahan tersembunyi yang menyebabkan kerentanan.
Contoh serangan: “Hypocrite Commits” - upaya untuk mempromosikan patch yang memiliki kerentanan ke dalam kernel Linux.
Metode keamanan yang disarankan: tinjauan independen terhadap setiap perubahan oleh dua pengembang.
- B. Kompromi platform kontrol kode sumber.
Contoh serangan: injeksi komitmen jahat dengan pintu belakang ke dalam repositori Git proyek PHP setelah kata sandi pengembang bocor.
Metode perlindungan yang disarankan: Peningkatan keamanan platform manajemen kode (dalam kasus PHP, serangan dilakukan melalui antarmuka HTTPS yang jarang digunakan, yang memungkinkan perubahan dikirim saat masuk menggunakan kata sandi tanpa memeriksa kunci SSH, meskipun demikian fakta bahwa MD5 yang tidak dapat diandalkan digunakan untuk meng-hash kata sandi).
- C. Melakukan perubahan pada tahap pemindahan kode ke sistem build atau continuous integrasi (kode yang tidak sesuai dengan kode dari repositori yang dibangun).
Contoh serangan: Menginjeksi backdoor ke Webmin dengan melakukan perubahan pada infrastruktur build, sehingga mengakibatkan penggunaan file kode yang berbeda dengan file di repositori.
Metode perlindungan yang diusulkan: Memeriksa integritas dan mengidentifikasi sumber kode di server perakitan.
- D. Kompromi platform perakitan.
Contoh serangan: serangan SolarWinds, di mana pemasangan pintu belakang ke produk SolarWinds Orion dipastikan selama tahap perakitan.
Metode perlindungan yang diusulkan: penerapan langkah-langkah keamanan tingkat lanjut untuk platform perakitan.
- E. Promosi kode berbahaya melalui ketergantungan berkualitas rendah.
Contoh serangan: pengenalan pintu belakang ke dalam pustaka aliran peristiwa populer dengan menambahkan ketergantungan yang tidak berbahaya dan kemudian memasukkan kode berbahaya dalam salah satu pembaruan ketergantungan ini (perubahan berbahaya tidak tercermin dalam repositori git, tetapi terjadi hanya hadir dalam paket MNP yang sudah jadi).
Metode perlindungan yang disarankan: menerapkan persyaratan SLSA secara rekursif ke semua dependensi (dalam kasus aliran peristiwa, pemeriksaan akan mengungkapkan kumpulan kode yang tidak sesuai dengan konten repositori Git utama).
- F. Mengunggah artefak yang tidak dibuat di sistem CI/CD.
Contoh serangan: menambahkan kode berbahaya ke skrip CodeCov, yang memungkinkan penyerang mengekstrak informasi yang disimpan di lingkungan sistem integrasi berkelanjutan pelanggan.
Metode perlindungan yang diusulkan: kontrol atas sumber dan integritas artefak (dalam kasus CodeCov, dapat terungkap bahwa skrip Bash Uploader yang dikirim dari situs web codecov.io tidak sesuai dengan kode dari repositori proyek).
- G. Kompromi pada repositori paket.
Contoh serangan: Peneliti dapat menyebarkan mirror dari beberapa repositori paket populer untuk mendistribusikan paket berbahaya melalui mereka.
Metode perlindungan yang disarankan: Verifikasi bahwa artefak yang didistribusikan dikompilasi dari kode sumber yang dinyatakan.
- H. Membingungkan pengguna untuk menginstal paket yang salah.
Contoh serangan: menggunakan kesalahan ketik (NPM, RubyGems, PyPI) untuk menempatkan paket di repositori yang serupa secara tertulis dengan aplikasi populer (misalnya, skrip kopi, bukan skrip kopi).
Untuk memblokir ancaman yang ditandai, SLSA menawarkan serangkaian rekomendasi, serta alat untuk mengotomatiskan pembuatan metadata audit. SLSA merangkum metode serangan umum dan memperkenalkan konsep lapisan keamanan. Setiap tingkat memberlakukan persyaratan infrastruktur tertentu untuk memastikan integritas artefak yang digunakan dalam pembangunan. Semakin tinggi tingkat SLSA yang didukung, semakin banyak perlindungan yang diterapkan dan semakin baik infrastruktur terlindungi dari serangan umum.
- SLSA 1 mengharuskan proses pembangunan sepenuhnya diotomatisasi dan menghasilkan metadata (“asal”) tentang bagaimana artefak dibangun, termasuk informasi tentang sumber, dependensi, dan proses pembangunan (contoh generator metadata untuk audit disediakan untuk GitHub Actions). SLSA 1 tidak menyertakan elemen perlindungan terhadap modifikasi berbahaya, namun hanya mengidentifikasi kode dan menyediakan metadata untuk manajemen kerentanan dan analisis risiko.
- SLSA 2 - memperluas level pertama dengan mewajibkan penggunaan kontrol versi dan layanan perakitan yang menghasilkan metadata yang diautentikasi. Penggunaan SLSA 2 memungkinkan Anda melacak asal kode dan mencegah perubahan tidak sah pada kode dalam kasus layanan build tepercaya.
- SLSA 3 - mengonfirmasi bahwa kode sumber dan platform pembangunan memenuhi persyaratan standar yang menjamin kemampuan untuk mengaudit kode dan memastikan integritas metadata yang disediakan. Diasumsikan bahwa auditor dapat mensertifikasi platform terhadap persyaratan standar.
- SLSA 4 merupakan level tertinggi, melengkapi level sebelumnya dengan persyaratan sebagai berikut:
- Peninjauan wajib atas semua perubahan oleh dua pengembang berbeda.
- Semua langkah build, kode, dan dependensi harus dideklarasikan sepenuhnya, semua dependensi harus diekstraksi dan diverifikasi secara terpisah, dan proses build harus dilakukan secara offline.
- Menggunakan proses build yang dapat diulang memungkinkan Anda mengulangi proses build sendiri dan memastikan bahwa executable dibuat dari kode sumber yang disediakan.
Sumber: opennet.ru