Masalahnya dalam satu kalimat.
Lain kali sebuah Asisten AI merekomendasikan paket untuk diinstal.Apakah Anda benar-benar akan memeriksa apakah paket tersebut ada? Sebagian besar pengembang belum melakukannya. Kesenjangan antara saran dan verifikasi inilah yang menjadi awal mula serangan slopsquatting, dan itulah mengapa pemahaman tentang evolusi slopsquatting dan pencegahan slopsquatting praktis telah menjadi prioritas utama bagi tim AppSec dan DevSecOps.
Apa itu serangan slopsquatting?
Serangan slopsquatting adalah varian dari kesalahan ketik (praktik mendaftarkan nama domain atau paket yang meniru nama domain atau paket yang sah melalui kesalahan ejaan umum, seperti permintaan alih-alih permintaan(dengan harapan kesalahan ketik pengguna sendiri akan mengarahkan mereka langsung ke sana), tetapi dengan perbedaan penting dalam asal kesalahan tersebut. Typosquatting mengeksploitasi kesalahan pengetikan manusia. Serangan slopsquatting mengeksploitasi kesalahan yang dibuat oleh model bahasa besar: sebuah LLM "menghalusinasi" nama paket yang terdengar sangat sah tetapi tidak ada di registri publik mana pun, dan penyerang mendapatkannya lebih dulu dengan mendaftarkan nama yang persis sama sebelum siapa pun dengan niat baik melakukannya.
Mekanisme di balik serangan slopsquatting yang khas itu sederhana, dan kesederhanaan itulah yang membuatnya efektif:
- Seorang pengembang meminta bantuan asisten AI untuk menyelesaikan masalah pemrograman.
- Model tersebut menghasilkan solusi yang mengimpor atau merekomendasikan pemasangan paket yang belum pernah ada.
- Seorang penyerang yang menyadari bahwa beberapa model terus mengulang nama yang sama (hasil halusinasi) mendaftarkan paket tersebut di npm, PyPI, atau registri publik lainnya, dengan kode berbahaya di dalamnya. Inilah saat halusinasi tersebut berubah menjadi serangan slopsquatting yang sebenarnya.
- Pengembang berikutnya yang mendapatkan saran yang sama dan tidak memverifikasinya, akan menginstal paket yang kini menjadi nyata, yang merupakan pintu belakang ke lingkungan mereka.
Istilah “slopsquatting” diciptakan oleh Seth Larson, Security Developer-in-Residence di Python Software Foundation, dan dipopulerkan oleh Andrew Nesbitt, untuk menggambarkan pola ini secara tepat: sebuah “halusinasi paket” yang berubah menjadi vektor serangan.
Evolusi praktik menempati lahan sembarangan: bagaimana rasa ingin tahu dalam penelitian berkembang menjadi ancaman nyata.
Yang menarik dari evolusi praktik slopsquatting bukan hanya konsepnya; tetapi juga seberapa cepat praktik ini berkembang dari pengamatan penelitian menjadi jenis serangan yang terdokumentasi dan terukur.
2023: Tanda peringatan pertama. Peneliti keamanan Bar Lanyado memperhatikan bahwa beberapa LLM berulang kali merekomendasikan sebuah paket bernama memeluk wajah-cli, yang tidak ada (paket sebenarnya diinstal dengan pip install -U “huggingface_hub[cli]”Untuk menunjukkan risikonya, ia mengunggah versi kosong dari paket tersebut ke registri publik. Dalam waktu tiga bulan, paket tersebut telah diunduh lebih dari 30,000 kali, tanpa promosi sama sekali. Nama fiktif tersebut bahkan muncul di README sebuah repositori yang terkait dengan penelitian dari Alibaba, menunjukkan sejak awal bagaimana nama-nama "palsu" ini dapat bocor ke dalam dokumentasi asli dan membuka jalan bagi serangan slopsquatting yang akan terjadi selanjutnya.
2024: Risiko tersebut beralih dari unggahan blog seorang peneliti ke liputan teknologi arus utama. Pada bulan Maret 2024, Pendaftaran Berita tersebut melaporkan bagaimana model AI dengan percaya diri menciptakan nama paket perangkat lunak yang kemudian diunduh oleh para pengembang, beberapa di antaranya berpotensi terinfeksi malware. Liputan tersebut lebih penting karena apa yang ditunjukkannya daripada apa yang diungkapkan secara teknis: kasus huggingface-cli bukan lagi sekadar kejadian aneh; itu adalah tanda pertama dari pola yang cukup serius sehingga media teknologi arus utama menyorotinya, sebelum studi akademis skala besar yang akan mengkonfirmasi cakupannya setahun kemudian.
2025: Pengukuran masalah yang pertama kali dilakukan secara teliti dan berskala besar. Makalah “Kami Punya Paket untuk Anda! Analisis Komprehensif tentang Halusinasi Paket oleh LLM Penghasil Kode” (Spracklen dkk., dipresentasikan pada Simposium Keamanan USENIX) menguji 16 model pembangkitan kode, baik komersial (GPT-4, GPT-3.5) maupun sumber terbuka (CodeLlama, DeepSeek, WizardCoder, Mistral), di seluruh 576,000 sampel kode Python dan JavaScript. Temuan tersebut menandai titik penting dalam evolusi praktik slopsquatting, mengubahnya dari anekdot menjadi data:
- 19.7% dari paket yang direkomendasikan oleh para model tidak ada.
- Model sumber terbuka mengalami halusinasi jauh lebih sering (rata-rata 21.7%) dibandingkan model komersial (5.2%).
- Di semua model yang diuji, para peneliti mencatat lebih dari 205,000 nama paket halusinasi unik, kumpulan yang cukup besar untuk memicu serangan slopsquatting berkelanjutan di berbagai ekosistem.
Detail penting dari penelitian ini, dan mungkin alasan mengapa evolusi slopsquatting semakin cepat daripada mereda, adalah bahwa nama-nama yang dihalusinasi bukanlah acak, dan tidak berubah pada setiap percobaan. Model yang sama cenderung mengulang nama-nama yang dibuat-buat ketika diberi perintah yang serupa, yang berarti penyerang tidak perlu menebak. Mereka hanya perlu mengamati perilaku model, mengidentifikasi nama-nama yang terus berulang, dan mendaftarkannya sebelum pengembang sebenarnya melakukannya. Analisis lanjutan dari pengulangan ini menemukan bahwa ketika para peneliti menjalankan kembali perintah yang identik sepuluh kali, 43% dari nama paket yang dihalusinasi muncul pada setiap percobaan, bukti bahwa sebagian besar halusinasi adalah artefak yang dapat diulang daripada gangguan sekali saja. Pengulangan itulah yang mengubah halusinasi sekali saja menjadi serangan slopsquatting yang dapat diskalakan.
2026: Dari paket terisolasi menjadi agen otonom. Dari paket terisolasi hingga agen otonom. Tahun ini telah menghasilkan bukti paling jelas bahwa slopsquatting tidak lagi terbatas pada pengembang yang menyalin dan menempelkan perintah instalasi pip atau instalasi npm yang disarankan. Pada Januari 2026, peneliti keamanan Charlie Eriksen menemukan bahwa agen pengkodean AI telah menyebarkan instruksi yang merujuk pada paket npm fiktif, react-codeshift (nama yang kemungkinan menggabungkan dua alat nyata, jscodeshift dan react-codemod), di 237 repositori, dengan agen masih mencoba menginstalnya setiap hari. Eriksen mendaftarkan nama tersebut sendiri, sebagai tindakan pencegahan, sebelum penyerang dapat menggunakannya sebagai senjata. Secara terpisah, paket berbahaya nyata bernama unused-imports, yang dihalusinasi sebagai pengganti eslint-plugin-unused-imports yang sah, masih mencatat sekitar 233 unduhan mingguan pada awal tahun 2026 meskipun npm telah menempatkannya di bawah penangguhan keamanan, sebuah tanda betapa lamanya serangan slopsquatting dapat terus menarik korban bahkan setelah ditandai. Baru-baru ini, pada Juli 2026, para peneliti menjelaskan teknik terkait, yang disebut "HalluSquatting," yang menggabungkan halusinasi AI dengan injeksi perintah sehingga agen pengkodean AI yang mengambil sumber daya hasil halusinasi atas nama pengguna dapat dibajak untuk menjalankan kode yang diberikan penyerang, memperluas evolusi slopsquatting dari risiko instalasi pasif menjadi vektor eksekusi kode jarak jauh aktif di dalam alur kerja pengembangan berbasis agen.
Mengapa “vibe coding” memperluas peluang serangan slopsquatting?
Serangan slopsquatting tidak akan terlalu berpengaruh jika kode yang dihasilkan AI merupakan praktik khusus. Namun kenyataannya tidak demikian. Munculnya asisten pengkodean, agen otonom, dan alur kerja "vibe coding", di mana pengembang semakin sedikit meninjau kode sebelum menjalankannya, telah menggeser permukaan serangan perangkat lunak dalam dua cara konkret, dan keduanya mempercepat evolusi slopsquatting:
- Titik masuknya bukan lagi hanya pengembang. Serangan typosquatting dulunya bergantung pada satu orang yang melakukan kesalahan pengetikan. Sekarang, kesalahan tersebut dapat berasal dari dalam model itu sendiri dan menyebar ke ratusan pengembang berbeda yang mengajukan pertanyaan serupa dan mendapatkan rekomendasi yang sama, sehingga memperluas jangkauan satu serangan typosquatting.
- Titik rawan serangan telah bergeser lebih jauh ke atas rantai. Tidak cukup lagi hanya mengamati kode yang ditulis manusia. Tim juga perlu mengamati dependensi yang disarankan oleh asisten AI, server MCP yang terhubung dengannya, dan agen yang menginstal paket secara otomatis tanpa tinjauan langsung dari manusia. Keamanan Aplikasi tradisional, yang dibangun untuk meninjau repositori dan manusia, commits, tidak pernah dirancang untuk mengamati interaksi baru antara pengembang, AI, dan registri paket, yang justru menjadi tempat persembunyian serangan slopsquatting.
Ini bukan berarti AI generatif secara inheren tidak aman. Artinya, AI generatif memperkenalkan jenis risiko rantai pasokan baru yang tidak dapat dideteksi oleh perangkat keamanan tradisional, dan risiko ini memerlukan prinsip verifikasi yang sama yang sudah kita terapkan pada setiap ketergantungan eksternal: jangan percaya begitu saja, verifikasi sumbernya, dan otomatiskan verifikasi tersebut daripada mengandalkan ingatan atau kewaspadaan setiap pengembang. Otomatisasi tersebut adalah fondasi dari strategi pencegahan slopsquatting yang sebenarnya.
Pencegahan pengosongan lahan tanpa izin: apa yang dapat dilakukan tim saat ini
Kabar baiknya adalah pencegahan slopsquatting tidak memerlukan alat-alat canggih. Yang dibutuhkan hanyalah penerapan sistematis praktik kebersihan dependensi yang sudah ada, tetapi banyak tim cenderung lengah begitu AI yang mereka percayai "menyarankan" kode tersebut. Pendekatan pencegahan slopsquatting yang efektif biasanya menggabungkan hal-hal berikut:
- Lakukan verifikasi manual pada setiap paket baru sebelum menginstalnya.Terutama jika saran tersebut berasal dari asisten AI. Konfirmasikan keberadaannya di registri resmi, siapa yang mengelolanya, kapan diterbitkan, dan apakah jumlah unduhannya terlihat nyata. Kebiasaan sederhana ini adalah bentuk pencegahan slopsquatting termurah yang tersedia untuk tim mana pun.
- Jangan pernah berasumsi bahwa kode yang dihasilkan AI aman secara default. Cuplikan kode yang "berfungsi" tidak berarti dependensinya sah. Peninjauan dependensi seharusnya menjadi bagian dari peninjauan kode, bukan pengecualian.
- Gunakan file kunci dan verifikasi hash. untuk menetapkan versi yang tepat dan menghentikan pembaruan diam-diam agar tidak mengganti paket yang berbeda dari yang awalnya diaudit.
- Terapkan pemindaian ketergantungan yang menandai pola risiko di luar CVE yang diketahui.: paket anomali, nama yang mencurigakan mirip dengan yang sudah ada, pengelola baru tanpa rekam jejak, atau skrip instalasi dengan perilaku yang tidak biasa. Paket yang baru diterbitkan dengan hampir tanpa riwayat yang sangat mirip dengan nama sesuatu yang "hampir" familiar adalah pola yang tepat di balik sebagian besar serangan slopsquatting yang telah didokumentasikan sejauh ini.
- Perlakukan registri publik dengan skeptisisme yang sama.cisseperti halnya sumber eksternal lain yang tidak terverifikasi. Kenyataan bahwa pemasangan pip or instalasi npm Tidak menampilkan kesalahan bukan berarti suatu hal itu sah.
- Melatih tim pengembangan Mengenai fakta bahwa pengkodean yang dibantu AI tidak menghilangkan tanggung jawab untuk memverifikasi apa yang diinstal; itu hanya menambahkan langkah yang perlu diintegrasikan ke dalam alur kerja sebagai bagian dari rencana pencegahan penyalahgunaan yang serius.
Tak satu pun dari langkah-langkah ini merupakan hal baru. Yang berubah adalah skalanya: ketika saran ketergantungan tidak lagi berasal dari Stack Overflow atau kolega, tetapi dari model yang dapat mengulangi kesalahan yang sama kepada ribuan pengembang yang berbeda, verifikasi manual, meskipun masih diperlukan, tidak lagi cukup dengan sendirinya. Itulah mengapa semakin banyak tim yang mengotomatiskan lapisan pencegahan penggunaan sumber daya yang tidak tepat ini di dalam sistem mereka. Analisis Komposisi Perangkat Lunak (SCA) perkakas, daripada menyerahkannya pada kebijakan masing-masing pengembang.
Ini adalah pracismengapa ASPM platform 'like' Xygeni Mengintegrasikan deteksi ketergantungan yang mencurigakan, meliputi typosquatting, kebingungan ketergantungan, dan paket berbahaya yang dikenal, ke dalam analisis ketergantungan sumber terbuka dan AI yang sama. pipelineJadi, pencegahan slopsquatting tidak bergantung pada setiap pengembang yang ingat untuk memeriksanya setiap kali asisten AI menyarankan dependensi baru.
FAQ (Pertanyaan Umum)
Apakah serangan slopsquatting sama dengan serangan typosquatting?
Tidak sepenuhnya benar. Keduanya melibatkan pendaftaran nama paket palsu untuk mengelabui siapa pun yang menginstalnya, tetapi sumber kesalahannya berbeda. Typosquatting memanfaatkan kesalahan pengetikan manusia. Serangan slopsquatting memanfaatkan nama paket yang diciptakan (dihalusinasi) oleh model AI, yang kemudian didaftarkan oleh penyerang sebelum paket tersebut benar-benar ada secara sah.
Bisakah pengelola paket secara otomatis mencegah jenis serangan ini?
Tidak sepenuhnya, dan itulah mengapa pencegahan slopsquatting tidak bisa berhenti di tingkat pengelola paket. Jika penyerang mendaftarkan paket fiktif sebelum pengembang mencoba menginstalnya, instalasi akan selesai tanpa kesalahan karena paket tersebut benar-benar ada, meskipun bersifat berbahaya. Pencegahan yang efektif membutuhkan verifikasi tambahan terhadap asal dan perilaku paket tersebut.
Apakah ini hanya memengaruhi model sumber terbuka?
Tidak. Studi Spracklen dkk. menemukan halusinasi di setiap model yang diuji, termasuk model komersial, meskipun dengan tingkat yang jauh lebih rendah (5.2% dibandingkan 21.7% untuk model sumber terbuka yang dievaluasi). Tidak ada model yang sepenuhnya bebas dari masalah ini, dan itulah sebagian alasan mengapa evolusi praktik "slopsquatting" (penggunaan perangkat lunak secara ilegal untuk mengakses sumber terbuka) terus berkembang seiring dengan pertumbuhan pengkodean yang dibantu AI secara keseluruhan.
Apakah ini risiko teoretis, atau sudah dieksploitasi?
The memeluk wajah-cli Dalam kasus ini, sebuah paket kosong yang diunggah oleh seorang peneliti dan diunduh lebih dari 30,000 kali dalam tiga bulan tanpa promosi sama sekali, menunjukkan bahwa risikonya bukan hanya teoritis: sebuah nama fiktif hanya perlu cukup konsisten di berbagai permintaan agar seseorang dapat mengubahnya menjadi serangan pencurian data ilegal yang nyata.
