Serangan Supply Chain npm 2026: Kasus Axios dan @antv, Ancaman Pencurian Kredensial Developer

Kedua insiden memperlihatkan kelemahan yang sama: proses instalasi dependensi dapat memberikan kesempatan kepada kode pihak ketiga untuk berjalan dalam lingkungan yang memiliki akses sensitif.

Mengapa Serangan Supply Chain npm Berbahaya?

Serangan supply chain memiliki karakteristik berbeda dibandingkan eksploitasi kerentanan aplikasi tradisional.

Pada eksploitasi aplikasi, penyerang biasanya berusaha memanfaatkan kelemahan yang terdapat pada layanan yang sedang berjalan.

Sebaliknya, dalam serangan supply chain, penyerang dapat menyisipkan kode berbahaya ke komponen yang akan digunakan oleh aplikasi.

Akibatnya, kode tersebut mungkin dijalankan dalam lingkungan pengembangan atau deployment yang memiliki akses luas.

1. Memanfaatkan Kepercayaan terhadap Paket Populer

Paket populer cenderung dipercaya karena digunakan banyak pengembang dan memiliki riwayat pemeliharaan yang panjang.

Namun, reputasi sebuah paket tidak menjamin bahwa seluruh versi yang diterbitkan selalu aman.

2. Eksekusi Otomatis Selama Instalasi

Lifecycle script memungkinkan kode tertentu berjalan selama proses pemasangan paket.

Jika paket telah dikompromikan, mekanisme tersebut dapat digunakan untuk menjalankan kode tanpa interaksi tambahan dari pengembang.

3. Menargetkan Lingkungan dengan Hak Akses Tinggi

Server build dan CI/CD sering menyimpan token serta kredensial untuk mengakses layanan eksternal.

Jika lingkungan tersebut terkompromi, penyerang berpotensi memperoleh akses ke repositori dan infrastruktur deployment.

4. Penyebaran melalui Dependensi Transitif

Paket berbahaya dapat terpasang sebagai dependensi tidak langsung.

Hal ini membuat deteksi lebih sulit apabila organisasi hanya memeriksa daftar dependensi utama.

5. Potensi Kompromi Berantai

Kredensial yang dicuri dapat digunakan untuk mengakses proyek lain, menerbitkan paket tambahan, atau memodifikasi pipeline.

Karena itu, dampak supply chain attack dapat melampaui aplikasi yang pertama kali terinfeksi.

Cara Memeriksa Proyek dari Paket npm Berbahaya

Pengembang dapat melakukan pemeriksaan awal menggunakan beberapa perintah berikut.

1. Periksa Versi Axios

Untuk mengetahui versi Axios yang terpasang:

npm ls axios

Jika ditemukan versi yang pernah dilaporkan berbahaya, periksa riwayat instalasi dan lingkungan tempat paket tersebut digunakan.

Perlu diperhatikan bahwa versi yang saat ini terpasang tidak selalu mencerminkan versi yang pernah dijalankan sebelumnya.

2. Periksa Dependensi @antv

Untuk memeriksa paket tertentu:

npm ls @antv/g-components

Pengembang juga dapat mencari referensi paket @antv dalam file lock:

grep -n '"node_modules/@antv/' package-lock.json

Perintah tersebut ditujukan untuk proyek npm dengan format package-lock.json yang sesuai.

Pengguna pnpm atau Yarn perlu memeriksa lockfile masing-masing.

Tidak semua paket dalam namespace @antv berbahaya. Pemeriksaan harus mempertimbangkan nama paket dan versi spesifik yang tercantum dalam advisory.

3. Jalankan Audit Keamanan

npm audit

Perintah ini membantu mengidentifikasi kerentanan yang tercatat dalam basis data advisory yang digunakan npm.

Namun, hasil audit yang tidak menemukan masalah bukan jaminan bahwa seluruh dependensi bebas malware.

Serangan yang baru terjadi mungkin belum terdeteksi atau belum tercakup dalam basis data keamanan.

4. Periksa Riwayat Instalasi

Organisasi sebaiknya memeriksa log instalasi dependensi pada:

• Komputer developer.

• Server build.

• GitHub Actions.

• Sistem deployment.

• Container build.

• Artifact repository.

Pemeriksaan riwayat penting untuk menentukan apakah versi berbahaya pernah dijalankan, meskipun sekarang sudah diganti.

Langkah Mitigasi Supply Chain Attack npm

1. Gunakan Versi Dependensi yang Terverifikasi

Pastikan aplikasi menggunakan versi paket yang telah diperiksa dan tidak tercantum sebagai versi berbahaya dalam advisory resmi.

Untuk kasus Axios, versi aman yang direkomendasikan saat penanganan awal adalah 1.14.0 dan 0.30.3.

Pengembang sebaiknya memeriksa pembaruan resmi sebelum menentukan versi untuk penggunaan jangka panjang.

2. Gunakan npm ci pada Lingkungan CI/CD

Untuk proyek yang menggunakan npm dan memiliki lockfile:

npm ci

Perintah tersebut membantu memastikan instalasi mengikuti versi dan integritas paket yang tercatat dalam lockfile.

Namun, lockfile tidak otomatis melindungi sistem apabila versi berbahaya sudah tercatat di dalamnya.

Karena itu, perubahan lockfile tetap harus diperiksa melalui code review.

3. Pertimbangkan Menonaktifkan Lifecycle Script

Pada lingkungan yang memungkinkan, instalasi dapat dilakukan menggunakan:

npm ci --ignore-scripts

Opsi ini membantu mencegah eksekusi lifecycle script selama proses instalasi.

Namun, beberapa dependensi yang sah membutuhkan script instalasi agar berfungsi dengan benar.

Pengembang perlu melakukan pengujian kompatibilitas sebelum menerapkan opsi tersebut secara menyeluruh.

4. Batasi Akses Token CI/CD

Gunakan prinsip least privilege, yaitu memberikan izin minimum yang diperlukan untuk setiap proses.

Token yang digunakan untuk menjalankan pengujian sebaiknya tidak otomatis memiliki izin untuk menerbitkan paket atau mengubah konfigurasi produksi.

Selain itu, hindari penggunaan kredensial jangka panjang apabila tersedia mekanisme autentikasi sementara yang lebih aman.

5. Terapkan Multi-Factor Authentication

Akun pengelola paket, repositori, dan layanan deployment perlu menggunakan autentikasi multifaktor.

Untuk proses publikasi paket, penggunaan trusted publishing berbasis OpenID Connect (OIDC) dapat mengurangi ketergantungan pada token npm jangka panjang.

Namun, autentikasi multifaktor tidak sepenuhnya menghilangkan risiko apabila perangkat pengelola sudah dikompromikan.

6. Lakukan Rotasi Kredensial Jika Terindikasi Terpapar

Apabila sistem diketahui pernah menjalankan paket berbahaya, lakukan penilaian insiden dan rotasi kredensial yang mungkin telah terekspos.

Kredensial tersebut dapat mencakup:

• GitHub access token.

• npm access token.

• API key.

• Cloud access key.

• SSH key.

• Database credentials.

• Secret pada CI/CD.

Pencabutan token lama harus dilakukan agar kredensial yang telah dicuri tidak dapat digunakan kembali.

7. Periksa Persistensi Malware

Menghapus paket dari node_modules tidak selalu cukup.

Jika payload berbahaya sudah berjalan, malware mungkin telah membuat perubahan lain pada sistem.

Pemeriksaan perlu mencakup proses mencurigakan, konfigurasi startup, scheduled task, workflow CI/CD, serta koneksi jaringan yang tidak dikenal.

Untuk sistem dengan indikasi kompromi kuat, pemulihan dari lingkungan bersih yang telah diverifikasi dapat lebih aman daripada sekadar menghapus paket.

8. Gunakan Dependency Scanning dan Monitoring

Organisasi dapat menerapkan Software Composition Analysis (SCA) untuk memantau kerentanan dan paket berbahaya.

Selain itu, pembaruan dependensi sebaiknya melalui proses review, pengujian, dan validasi sebelum diterapkan pada sistem produksi.

Apa yang Harus Dilakukan Jika Pernah Memasang Versi Berbahaya?

Jika pengembang menemukan bukti bahwa versi Axios atau @antv berbahaya pernah dipasang, tindakan penanganan harus mempertimbangkan kemungkinan eksekusi malware.

Langkah yang disarankan adalah:

1. Identifikasi perangkat dan pipeline yang menjalankan paket tersebut.

2. Isolasi sistem yang menunjukkan indikasi kompromi.

3. Simpan log dan bukti yang relevan untuk analisis.

4. Periksa aktivitas jaringan dan perubahan sistem.

5. Cabut serta rotasi kredensial yang berpotensi terekspos.

6. Periksa perubahan tidak sah pada repositori dan workflow.

7. Pulihkan sistem terdampak dari lingkungan yang tepercaya.

8. Terapkan versi dependensi yang telah diverifikasi aman.

Pengembang tidak boleh menganggap bahwa pembaruan paket saja sudah cukup untuk menangani insiden yang melibatkan remote access trojan atau pencurian kredensial.

Pelajaran Penting bagi Pengembang JavaScript

Kasus Axios dan @antv menunjukkan bahwa keamanan aplikasi modern harus mencakup seluruh proses pengembangan perangkat lunak.

Pemeriksaan kode aplikasi saja tidak cukup apabila dependensi, akun pengelola, dan pipeline distribusi tidak mendapatkan perlindungan yang memadai.

Pengembang perlu memperlakukan pembaruan dependensi sebagai perubahan yang memiliki konsekuensi keamanan.

Setiap pembaruan sebaiknya dapat ditelusuri, diperiksa, dan diuji sebelum diterapkan.

Selain itu, sistem CI/CD perlu dirancang dengan asumsi bahwa dependensi pihak ketiga dapat menjadi sumber ancaman.

Pembatasan izin, isolasi lingkungan build, perlindungan secret, dan monitoring merupakan langkah penting untuk mengurangi dampak apabila salah satu komponen berhasil dikompromikan.

Kesimpulan

Serangan supply chain npm sepanjang 2026 memperlihatkan bagaimana paket perangkat lunak populer dapat dimanfaatkan sebagai sarana penyebaran malware.

Pada kasus Axios, penyerang menerbitkan dua versi berbahaya yang menambahkan dependensi plain-crypto-js untuk menyebarkan backdoor WAVESHAPER.V2.

Sementara itu, serangan terhadap ekosistem @antv dalam kampanye Mini Shai-Hulud menunjukkan ancaman pencurian kredensial dan penyalahgunaan lingkungan CI/CD melalui paket yang telah dikompromikan.

Kedua insiden tersebut memberikan pelajaran penting bahwa kepercayaan terhadap pustaka open-source harus disertai mekanisme verifikasi dan pengendalian keamanan.

Pengembang perlu memeriksa dependensi langsung maupun tidak langsung, menggunakan versi paket yang terverifikasi, melindungi kredensial, serta memantau aktivitas pada lingkungan pengembangan dan deployment.

Keamanan perangkat lunak tidak hanya dimulai ketika aplikasi dijalankan, tetapi sejak dependensi pertama kali dipasang.

---