Transcript
00:00:00Jika Anda menginstal paket NPM, Anda adalah target. Mungkin tidak hari ini, mungkin tidak minggu ini, tapi itu
00:00:05pasti akan terjadi. Kami mengalami ratusan paket yang dikompromikan dalam beberapa bulan terakhir saja,
00:00:09dan jumlahnya tidak melambat. Jadi daripada khawatir setiap kali salah satu dari ini muncul,
00:00:14saya sebenarnya sudah mengunci pengaturan saya sendiri di NPM, PMPM, dan BUN, dan ternyata sebagian
00:00:18besar hal yang akan menyelamatkan Anda hanya butuh 30 detik untuk diatur. Jadi dalam video ini,
00:00:23saya akan membawa Anda melalui tujuh perubahan yang saya buat, mulai dari perubahan satu baris konfigurasi yang
00:00:27langsung mematikan serangan paling umum, hingga alat gratis yang dikirimkan oleh penyerang itu sendiri
00:00:30yang akan menangkap mereka bahkan sebelum paket tersebut mencapai mesin Anda. Mari kita mulai.
00:00:39Yang pertama dan paling sederhana adalah berhenti mengunduh paket baru. Sebagian besar serangan rantai pasokan
00:00:44ini ketahuan dalam hitungan jam, jadi jika Anda tidak menginstal versi yang benar-benar baru saat
00:00:48dirilis, Anda sebenarnya menghindari sebagian besar serangan rantai pasokan ini sepenuhnya. Semua manajer paket
00:00:52Node.js utama kini menawarkan semacam pengaturan usia rilis (release age gating). Untuk NPM, Anda mengaturnya di file NPM
00:00:57RC, dan diatur dalam hitungan hari. Untuk PMPM, Anda bisa mengaturnya secara global di file PMPM config.yaml,
00:01:03atau Anda bisa mengaturnya per proyek dengan menggunakan file workspace PMPM, dan nilai ini sebenarnya
00:01:08diatur dalam hitungan menit. Dan perlu dicatat bahwa sejak PMPM 11, secara default ini sudah diatur ke satu hari,
00:01:14jadi meskipun Anda tidak mengaturnya, Anda tetap memiliki perlindungan. Untuk BUN, Anda mengaturnya di
00:01:17file bumfig.toml, baik secara global atau per proyek, dan yang ini sebenarnya diatur dalam hitungan detik.
00:01:23Sungguh menakjubkan bagi saya bahwa untuk tiga manajer paket dengan pengaturan yang sama, kita mendapatkan
00:01:27tiga nilai yang berbeda, dan itu cukup merangkum ekosistem ini. Setelah Anda mengaturnya,
00:01:32jika Anda kemudian menginstal paket seperti react start milik tanstack, Anda bisa melihat paket itu tidak menginstal
00:01:36versi tersebut, melainkan menginstal versi terbaru yang memenuhi kriteria usia rilis saya, yang bagi saya
00:01:41adalah satu minggu yang lalu. Sekarang jika Anda perlu melewati ini, mungkin ada masalah keamanan dengan
00:01:45paket yang Anda instal, dan Anda perlu menginstal versi terbaru, Anda masih bisa melakukannya
00:01:49dari command line, tetapi waspadalah terhadap LLM juga di sini, karena saya pernah melihat kasus di mana LLM
00:01:54hanya menggunakan ini untuk memintas dan tetap menginstal versi terbaru. Hal lain yang perlu diingat adalah
00:01:59bahwa MPX dan BUNX tidak mematuhi pengaturan ini, mereka tetap menginstal versi terbaru,
00:02:03dan ada PR terbuka di BUN untuk memperbaiki ini. Sekarang selagi kita berada di pengaturan ini, mari kita
00:02:07matikan juga skrip instalasi untuk NPM. PMPM dan BUN sebenarnya memiliki perilaku ini secara default,
00:02:12jadi tidak ada yang perlu diatur untuk mereka. Jika Anda belum tahu, ketika Anda menginstal paket, paket itu
00:02:16sebenarnya diizinkan untuk menjalankan kodenya sendiri tepat setelah diinstal, dan ini dilakukan untuk kasus penggunaan
00:02:20yang sah seperti mengompilasi kode native atau mengunduh biner, tetapi masalahnya hampir setiap
00:02:26serangan rantai pasokan telah menggunakan metode ini untuk menjalankan kode berbahaya di mesin Anda tepat setelah instalasi.
00:02:30Jika Anda menemukan paket yang benar-benar membutuhkan salah satu skrip ini, Anda masih bisa mengaktifkannya
00:02:34secara eksplisit. Di PMPM, ketika Anda menginstal paket yang memiliki skrip pasca-instalasi, ia akan memberi tahu Anda,
00:02:39seperti esbuild di sini, dan kemudian Anda dapat menjalankan PMPM approved builds untuk memilih mana yang akan diizinkan,
00:02:44dan ini sebenarnya menetapkan konfigurasi allow builds workspace PMPM Anda, dan Anda juga bisa menggunakan
00:02:48flag allow build pada perintah instalasi untuk melakukan hal yang sama. Untuk BUN, seperti yang saya katakan, ia menghentikan
00:02:52skrip instalasi secara default juga, tetapi perlu diketahui bahwa ia sebenarnya memiliki daftar kurasi
00:02:56paket yang diizinkan untuk menjalankan skrip ini, dan itu termasuk yang sudah saya instal seperti
00:03:00esbuild. Anda bisa menolak ini dengan menambahkan dependensi tepercaya (trusted dependencies) ke package.json Anda,
00:03:04dengan cara ini hanya paket yang Anda izinkan secara eksplisit yang dapat menjalankan skrip pasca-instalasi.
00:03:09Dikatakan juga bahwa jika Anda mengatur array ke kosong, itu harus menggantikan daftar default
00:03:12tersebut juga, tetapi sepertinya tidak berfungsi untuk saya, dan tampaknya ini adalah bug yang saya temukan di GitHub
00:03:17juga. Solusinya saat ini adalah dengan memasukkan satu nilai ke dalam daftar tersebut, sehingga daftar defaultnya
00:03:21diabaikan. Dengan BUN, Anda juga bisa menjalankan BUN PM untrusted untuk melihat paket mana yang ingin menjalankan
00:03:26skrip tetapi belum dipercaya, lalu Anda bisa menjalankan BUN PM trust untuk mengizinkan satu, atau menambahkannya ke
00:03:30array trusted dependencies. Anda juga bisa menonaktifkan skrip sepenuhnya di BUN dengan mengatur install scripts ke
00:03:35false di BUN fig global Anda. Untuk NPM, ini sedikit lebih sulit. Jujur saja, jangan gunakan
00:03:40NPM, gunakan PNPM, tapi jika Anda benar-benar harus menggunakan NPM karena suatu alasan, Anda bisa mendapatkan perilaku daftar izin
00:03:45yang serupa dengan menggunakan paket NPM Lavamote allow scripts. Dengan cara ini, itu hanyalah daftar izin di
00:03:50package.json Anda juga. Tips ketiga adalah memblokir dependensi berbasis git. Dengan NPM, sebuah dependensi
00:03:55sebenarnya bisa dideklarasikan sebagai URL git, yang memintas registry, dan bahkan bisa mengirimkan NPM RC-nya sendiri yang
00:04:01mengaktifkan kembali skrip siklus hidup. Ini sebenarnya salah satu trik yang digunakan dalam serangan rantai pasokan NPM
00:04:05baru-baru ini yang menyerang tan stack. Anda bisa menghentikan ini dengan mengatur allow git ke none di konfigurasi NPM Anda,
00:04:10yang memblokirnya sepenuhnya, dan pilihan lainnya adalah mengaturnya ke root, yang memungkinkan dependensi berbasis git
00:04:15untuk diinstal, tetapi hanya jika dideklarasikan di package.json root Anda, jadi kemungkinan
00:04:19diatur secara eksplisit oleh Anda. Untuk PNPM, opsi ini adalah block exotic sub-dependencies. Ketika diatur ke true,
00:04:25hanya dependensi langsung, yaitu yang Anda cantumkan di package.json root Anda, yang bisa menggunakan sumber eksotis
00:04:29seperti repo git atau URL tabel langsung. Opsi ini belum ada di Bun, tapi ada PR terbuka
00:04:35untuk menambahkannya, jadi mungkin kita akan segera melihatnya. Sebagai bonus untuk mengakhiri tips yang melibatkan perubahan
00:04:40konfigurasi, PNPM sebenarnya memiliki pengaturan kebijakan kepercayaan (trust policy), yang bisa kita atur ke no downgrade, dan ini berarti
00:04:45bahwa PNPM akan gagal jika tingkat kepercayaan paket telah menurun dibandingkan dengan rilis sebelumnya. Jadi jika
00:04:50paket sebelumnya dipublikasikan oleh penerbit tepercaya, tetapi sekarang hanya memiliki bukti asal (provenance) atau
00:04:55tidak ada bukti kepercayaan, instalasi akan gagal. Ini seharusnya membantu menangkap serangan yang menemukan cara untuk
00:05:00memintas proses penerbitan yang biasa. Tips nomor empat adalah yang paling kuat, yaitu
00:05:04menggunakan alat yang benar-benar melihat paket yang Anda instal dan dapat mengauditnya sebelum mereka
00:05:08pernah menyentuh mesin Anda. Untuk itu, kita punya dua alat yang sangat kuat dan sepenuhnya gratis. Yang pertama adalah
00:05:14MPQ. Anda bisa mengaturnya dengan membuat alias untuk perintah NPM, PNPM, atau Bun biasa Anda,
00:05:18sehingga setiap kali Anda menjalankan instalasi, ia benar-benar memeriksa beberapa hal. Ia akan memindai kerentanan yang diketahui
00:05:23terhadap database Snyk, dan menandai paket apa pun yang berusia kurang dari 22 hari. Ia akan
00:05:28menangkap typo squatting, yaitu ketika seseorang memublikasikan paket seperti express dengan 1s, dengan harapan
00:05:32bahwa Anda akan salah ketik dan menginstal yang itu. Ia akan memverifikasi tanda tangan registry dan
00:05:37bukti asal build. Ia akan memperingatkan Anda ketika paket memiliki skrip pra dan pasca instalasi, dan di atas semua
00:05:41itu, ia memeriksa hal-hal dasar seperti jumlah unduhan, apakah ada readme, lisensi, URL repo,
00:05:46dan siapa email maintainernya, dan apakah domain itu bahkan masih terdaftar. Ia melakukan semua ini
00:05:51dan kemudian memberi Anda laporan interaktif tentang paket Anda, di mana Anda masih bisa memutuskan apakah
00:05:55Anda ingin menginstalnya. Yang kedua adalah socket firewall. Ini sebenarnya yang saya gunakan,
00:05:59dan lagi, Anda membuat alias ini untuk semua manajer paket Anda yang biasa, dan yang ini sebenarnya mendukung
00:06:03paket di luar JavaScript juga, seperti Python dan Rust. Mirip dengan MPQ, saat Anda menjalankan instalasi dengan
00:06:08ini, ia akan memeriksa socket dan memblokir paket berbahaya yang telah dikonfirmasi manusia, dan juga akan memperingatkan
00:06:12Anda tentang ancaman yang terdeteksi AI, yaitu yang belum ditinjau oleh manusia. Sejujurnya,
00:06:16saya terutama memilih socket firewall karena itu yang pertama kali saya dengar, tetapi saya juga memercayai socket karena mereka
00:06:21telah menangkap banyak paket berbahaya baru-baru ini, dan para penyerang bahkan melakukan wawancara di mana mereka mengatakan
00:06:25bahwa socket akan mendeteksi malware sebelum paket tersebut mencapai mesin Anda, yang merupakan iklan yang cukup bagus
00:06:30untuk mereka, dan saya juga suka bahwa itu mendukung lebih dari sekadar JavaScript dengan UV pip dan cargo.
00:06:35Jika Anda menginstal salah satu dari ini, Anda harus memastikan untuk menghapus cache manajer paket Anda
00:06:38hanya untuk memastikan bahwa setiap paket yang diinstal diperiksa oleh firewall. Tips lima adalah tentang file kunci Anda (lock files).
00:06:42File kunci Anda adalah tempat URL unduhan sebenarnya untuk setiap paket berada, dan masalahnya,
00:06:47hampir tidak ada yang meninjau file kunci mereka dalam PR. Jadi jika seseorang membuka PR terhadap repo Anda,
00:06:51mereka bisa diam-diam mengedit URL yang terselesaikan untuk menunjuk ke paket yang mereka kendalikan, dan juga mengatur
00:06:56hash integritas yang cocok sehingga tidak ada yang terlihat aneh. Sekarang saat Anda menjalankan instalasi, Anda menarik
00:07:01kode dari server penyerang. Kabar baiknya, jika Anda menggunakan PMPM, Anda tidak rentan
00:07:05terhadap ini. Ia tidak menyimpan sumber tabel yang bisa ditukar, dan juga tidak akan menginstal
00:07:09apa pun yang ada di file kunci, tetapi tidak dideklarasikan di package.json Anda. Saya tidak dapat menemukan
00:07:14informasi konkret tentang bun, jadi mungkin itu masih rentan terhadap ini. Perbaikannya jika Anda tidak
00:07:18menggunakan PMPM adalah menggunakan alat bernama lockfileLint. Anda menginstal ini sebagai dependensi dev, dan itu memvalidasi
00:07:23file kunci Anda, memeriksa setiap paket diselesaikan dari host tepercaya, seperti registry NPM. Ia memeriksa
00:07:28URL yang terselesaikan benar-benar cocok dengan nama paketnya, dan ia juga memeriksa hash integritasnya asli juga.
00:07:32Jika mencurigai sesuatu telah dirusak, itu akan menggagalkan instalasi. Tips 6 adalah berhenti
00:07:37menggunakan instalasi NPM di CI dan produksi, dan sebagai gantinya gunakan instalasi bersih (clean install). Perintah untuk ini di NPM adalah
00:07:42hanya NPM CI, dan untuk bun dan PMPM, Anda sebenarnya menambahkan flag frozen lockfile, tetapi mereka juga memiliki perintah CI
00:07:47sebagai alias yang melakukan hal yang sama. PMPM sebenarnya menggunakan ini secara default jika mendeteksi bahwa
00:07:52sedang berjalan di lingkungan CI. Perintah instalasi bersih menginstal persis apa yang ada di file kunci,
00:07:57tidak ada yang lain, dan jika file kunci dan package.json tidak setuju, ia berhenti dan memberikan kesalahan,
00:08:01daripada menebak dan tetap menginstal. Jadi ini seharusnya mencegah penyerang menyelipkan
00:08:05versi yang ditukar. Tidak ada dari ini yang berfungsi jika Anda tidak melakukan commit pada file kunci Anda di tempat
00:08:09pertama, jadi pastikan itu ada dalam kontrol versi dan tidak ada di gitignore Anda, dan saya akui ketika saya
00:08:13pertama kali mulai belajar coding sebagai anak kecil, saya pikir Anda seharusnya mengabaikan ini, jadi saya senang
00:08:17saya belajar untuk melakukan commit. Jadi enam tips itu sebagian besar adalah konfigurasi dan alat, tetapi ada juga beberapa
00:08:21kebiasaan yang bisa Anda adopsi untuk membantu Anda menghindari serangan. Yang pertama adalah berhenti secara membabi buta memperbarui
00:08:25segalanya. Anda mungkin pernah menjalankan NPM update atau versi lain dari perintah ini sebelumnya, dan hanya
00:08:30memperbarui setiap dependensi ke versi terbarunya sekaligus, tetapi itu adalah jenis perilaku yang tepat yang diharapkan oleh para
00:08:35penyerang ini, jadi periksalah peningkatan ini dan tanyakan pada diri sendiri mengapa Anda perlu
00:08:39meningkatkannya. Kebiasaan kedua menjadi semakin relevan, gunakan saja lebih sedikit paket. Setiap
00:08:43dependensi yang Anda tambahkan adalah permukaan serangan lain, dan sebagian besar serangan ini menyebar melalui dependensi
00:08:48dari sebuah dependensi, jadi sangat layak untuk bertanya mengapa Anda membutuhkan pustaka itu. Beberapa contoh umum yang saya lihat dari
00:08:53ini adalah hal-hal seperti Lodash untuk fungsi yang bisa dilakukan dengan sedikit potongan kode, atau Axios ketika
00:08:58fetch bisa melakukan hal yang sama. Alasan saya mengatakan ini menjadi semakin relevan adalah di era agentic
00:09:03coding, cukup mudah untuk meminta AI menulis beberapa fungsi untuk Anda daripada menggunakan dependensi.
00:09:08Kebiasaan ketiga adalah menyematkan (pinning) dependensi ke versi yang tepat, sehingga peningkatan selalu menjadi
00:09:12pilihan yang disengaja, tetapi ketahuilah bahwa ini sebenarnya hanya mengunci paket yang Anda pilih di package.json Anda,
00:09:17dan dependensi dari dependensi Anda masih bisa menggunakan rentang mereka sendiri, yang justru mengapa cooldown
00:09:21dari tips 1 itu penting. Semua ini digabungkan seharusnya memberi Anda ketenangan pikiran bahwa Anda tidak akan
00:09:25secara tidak sengaja menginstal paket yang dikompromikan. Mereka tidak kebal, tapi jauh lebih baik daripada
00:09:29tidak sama sekali. Tips pamungkasnya hanyalah menjalankan semuanya di dalam dev container yang diperkeras, tapi saya selalu menemukan
00:09:34itu sedikit merepotkan, jadi saya akhirnya kembali ke pengembangan lokal. Jika Anda tahu cara lain
00:09:38untuk melindungi diri Anda dari jenis serangan ini, beri tahu saya di kolom komentar di bawah, selagi Anda di sana
00:09:42berlangganan, dan seperti biasa sampai jumpa di video berikutnya.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video