7 Tips Menghindari Peretasan (npm, pnpm & bun)

Bahasa IndonesiaالعربيةDeutschEnglishEspañolFrançaisहिन्दी日本語한국어PortuguêsРусский中文
BBetter Stack
컴퓨터/소프트웨어AI/미래기술

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.

Key Takeaway

Keamanan rantai pasokan perangkat lunak dapat ditingkatkan secara signifikan dengan menerapkan pembatasan usia rilis paket, menonaktifkan skrip pasca-instalasi, dan menggunakan firewall pihak ketiga seperti Socket untuk memindai dependensi sebelum instalasi.

Highlights

  • Pengaturan usia rilis (release age gating) pada npm, pnpm, dan Bun membantu menghindari sebagian besar serangan rantai pasokan dengan mencegah instalasi paket yang terlalu baru.

  • Menonaktifkan skrip pasca-instalasi (post-install scripts) membatasi eksekusi kode berbahaya yang otomatis berjalan saat instalasi paket.

  • Alat seperti Socket Firewall dan Socket MPQ memindai paket sebelum mencapai mesin dengan mendeteksi malware, typo-squatting, dan tanda tangan registry.

  • Penggunaan perintah 'npm ci' atau 'frozen-lockfile' untuk pnpm dan Bun memastikan instalasi paket yang identik dengan file kunci, mencegah modifikasi URL oleh penyerang.

  • Penggunaan dependensi yang lebih sedikit mengurangi permukaan serangan secara keseluruhan, karena setiap dependensi tambahan berpotensi menjadi celah keamanan.

Timeline

Pembatasan Usia Paket dan Skrip Instalasi

  • Pengaturan usia rilis mencegah instalasi paket yang baru dipublikasikan, yang sering kali merupakan paket berbahaya.
  • Skrip instalasi otomatis dapat dinonaktifkan atau dibatasi untuk mencegah eksekusi kode berbahaya tepat setelah instalasi.
  • pnpm dan Bun memiliki keamanan bawaan yang lebih baik terkait skrip instalasi dibandingkan npm secara default.

Serangan rantai pasokan sering kali terdeteksi dalam hitungan jam setelah dirilis. Menggunakan fitur usia rilis pada manajer paket memastikan hanya paket yang sudah teruji waktu yang diinstal. Selain itu, skrip pasca-instalasi yang sah untuk kompilasi kode native sering disalahgunakan untuk menjalankan malware, sehingga membatasi eksekusi skrip ini secara eksplisit meningkatkan keamanan mesin.

Mitigasi Dependensi Git dan Kebijakan Kepercayaan

  • Dependensi berbasis Git dapat memintas registry dan memicu skrip siklus hidup yang berbahaya.
  • Opsi konfigurasi seperti 'allow git' atau 'block exotic sub-dependencies' membatasi sumber dependensi yang tidak aman.
  • Kebijakan 'no downgrade' pada pnpm mencegah instalasi jika tingkat kepercayaan atau bukti asal paket menurun.

Penggunaan URL Git untuk dependensi memungkinkan penyerang memintas mekanisme keamanan standar. Membatasi dependensi hanya dari sumber tepercaya atau yang terdaftar secara eksplisit di file root package.json memitigasi risiko ini. Kebijakan kepercayaan tambahan memastikan integritas paket tetap terjaga di setiap rilis baru.

Audit Otomatis dan Integritas File Kunci

  • Alat audit seperti Socket Firewall dan MPQ memindai paket untuk mendeteksi ancaman sebelum instalasi.
  • Peninjauan file kunci sangat penting untuk mencegah modifikasi URL unduhan yang mengarah ke server penyerang.
  • Perintah instalasi bersih seperti 'npm ci' memastikan konsistensi antara file kunci dan hasil instalasi.

Alat eksternal seperti Socket Firewall menyediakan lapisan perlindungan tambahan dengan memindai paket untuk malware yang dikonfirmasi manusia atau terdeteksi AI. Selain itu, penggunaan perintah instalasi bersih yang bergantung pada file kunci memastikan bahwa tidak ada paket yang diubah atau disisipkan selama proses instalasi di lingkungan produksi.

Adopsi Kebiasaan Pengembangan yang Aman

  • Pembaruan dependensi harus dilakukan secara sengaja, bukan melalui pembaruan massal otomatis.
  • Pengurangan jumlah dependensi secara langsung mengecilkan permukaan serangan pada proyek.
  • Pemanfaatan AI untuk menulis fungsi sederhana dapat menggantikan kebutuhan akan pustaka pihak ketiga yang berisiko.

Mengurangi ketergantungan pada pustaka pihak ketiga yang tidak perlu, seperti mengganti Lodash atau Axios dengan fungsi bawaan, merupakan cara efektif untuk meminimalkan risiko. Kebiasaan meninjau setiap pembaruan dependensi memastikan pengembang memiliki kendali penuh atas kode yang diintegrasikan ke dalam proyek mereka.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video