Library JavaScript Terinfeksi Malware 2026: Daftar Insiden npm dan Panduan Mengamankan Proyek

Tanggal riset: 12 Oktober 2026, WIB. Cakupan kejadian: 1 Januari sampai batas waktu riset. Artikel ini merupakan rangkuman insiden terverifikasi dan panduan editorial, bukan daftar lengkap seluruh malware npm atau laporan setahun penuh.

Sebuah pembaruan dependency biasanya terlihat seperti pekerjaan rutin: nomor versi berganti, pengujian dijalankan, lalu aplikasi kembali dibangun. Namun, laporan sepanjang 2026 menunjukkan bahwa beberapa rilis npm yang tampak biasa justru membawa kode berbahaya. Axios, keluarga keyv/cacheable, dan AsyncAPI termasuk nama yang muncul dalam laporan peneliti keamanan. Yang bermasalah adalah rilis tertentu beserta jalur eksekusinya, bukan semua versi setiap proyek tersebut. Socket Axios (2026/03), Aikido Keyv (2026/08), JFrog AsyncAPI (2026/07).

Pertanyaan paling berguna setelah membaca berita seperti itu bukan hanya “library apa yang kena?”. Pertanyaan lanjutannya adalah: versi mana yang masuk ke proyek, kapan versi itu dipakai, di mesin mana kode dijalankan, dan akses apa yang tersedia pada mesin tersebut? Artikel ini mengajak pembaca menjawab pertanyaan itu secara berurutan. Bagian daftar insiden berisi fakta dari sumber. Bagian skenario dan rencana kerja berisi rekomendasi editorial yang perlu disesuaikan dengan lingkungan masing-masing.

Untuk pemilik website, pengembang aplikasi, dan tim kecil, tujuan artikel ini adalah membantu mengambil keputusan yang masuk akal. Anda tidak perlu menyimpulkan bahwa seluruh ekosistem JavaScript tidak aman. Anda juga tidak perlu menerima setiap pembaruan tanpa pemeriksaan. Kedua sikap tersebut terlalu jauh dari kebutuhan sehari-hari. Yang diperlukan adalah catatan dependency yang jelas, proses pembaruan yang dapat diperiksa, dan kemampuan membatasi akses ketika sesuatu benar-benar bermasalah.

Daftar isi

• Cara membaca artikel dan batas cakupannya
• Math_Symbol.js bukan nama library yang perlu dihapus sembarangan
• Dua kelompok ancaman yang harus dipisahkan
• Paket berbahaya sejak awal: jangan disamakan dengan proyek asli
• Mengapa tabel versi lebih berguna daripada daftar nama populer
• Memahami risiko tanpa mengarang angka korban
• Rilis yang perlu dicocokkan: Axios sampai Tensorlake
• Insiden tambahan dari Januari hingga September
• TanStack, AntV, dan Red Hat: skala kampanye perlu definisi yang tepat
• Cara menilai berita insiden dengan tepat
• Mulai dari pertanyaan yang benar
• Jangan mencampur tiga jenis tanggal
• Unduhan mengukur distribusi, bukan jumlah korban
• Nama file berbeda dari nama paket
• Bedakan kode bawaan berbahaya dan dependensi tambahan
• Kehadiran tidak selalu sama dengan eksekusi
• Kemampuan malware bukan bukti semua tindakan terjadi
• Hitung paket, versi, kampanye, dan korban secara terpisah
• Nilai sumber dan perubahan statusnya
• Setelah membaca daftar malware, bagaimana memeriksa proyek sendiri?
• 1. Mulai dari pertanyaan paparan, bukan dari tombol perbaikan
• 2. Jangan berhenti di package.json
• 3. Cari jalur masuk dependensi transitif
• 4. Lockfile adalah bukti versi, bukan janji bahwa kode aman
• 5. Bedakan informasi registry dari keadaan perangkat
• 6. Gunakan npm audit sesuai fungsinya
• 7. Pahami batas ignore-scripts
• 8. Build frontend juga perlu batas kepercayaan
• 9. Susun garis waktu sebelum menentukan cakupan pemulihan
• 10. Lindungi bukti sebelum membersihkan lingkungan
• 11. Pisahkan laptop, runner CI, dan server produksi
• 12. Rotasi secret dengan urutan yang membantu layanan pulih
• 13. Bangun kembali dari keputusan versi yang terdokumentasi
• 14. Buat review dependensi menjadi bagian dari review perubahan
• 15. Kurangi izin pipeline sebelum membutuhkan respons insiden
• 16. OIDC dan provenance membantu, dengan fungsi yang berbeda
• 17. Komunikasikan temuan dengan batas yang jelas
• 18. Laporkan indikasi baru melalui kanal yang tepat
• 19. Buat rutinitas yang sanggup dijalankan tim kecil
• Keterbatasan riset dan pembaruan artikel
• Bacaan dan alat terkait di Tumbas.in
• Daftar sumber

Cara membaca artikel dan batas cakupannya

Istilah “library terinfeksi malware” digunakan dalam judul sebagai bahasa yang mudah dikenali pembaca. Dalam isi, istilahnya diperinci menjadi paket sah yang rilisnya disusupi, paket berbahaya yang dibuat penyerang, dan berkas payload yang disisipkan ke paket. Pembedaan ini merupakan pilihan editorial agar pembaca tidak menggabungkan objek yang berbeda menjadi satu daftar panjang tanpa makna.

Tanggal kejadian juga dipisahkan dari tanggal artikel sumber. Contoh penting adalah laporan NodeCordRAT yang diterbitkan Zscaler pada 7 Januari 2026, tetapi menyebut penemuan paket pada November 2025. Paket bitcoin-main-lib, bitcoin-lib-js, dan bip40 dalam laporan itu tidak dimasukkan sebagai kejadian baru 2026. Zscaler NodeCordRAT (2026/01).

In November 2025, ThreatLabz identified three malicious packages

Pada November 2025, ThreatLabz mengidentifikasi tiga paket berbahaya.

[Zscaler NodeCordRAT (2026/01), Introduction]

Pilihan tersebut penting untuk kualitas artikel. Sebuah laporan yang baru terbit belum tentu membahas serangan yang baru terjadi. Sebaliknya, sebuah proyek bisa mengalami lebih dari satu insiden pada tahun berbeda. Nomor versi dan waktu kejadian harus tetap mengikuti masing-masing laporan. Untuk artikel ini, kata “2026” merujuk pada kejadian atau gelombang serangan yang sumbernya menempatkan pada 2026, dengan batas penelusuran 12 Oktober.

Tidak adanya baris untuk suatu bulan juga tidak berarti bulan itu bebas serangan. Artinya hanya bahwa daftar terpilih ini tidak menyediakan kejadian terverifikasi untuk setiap tanggal. Artikel tidak mencoba membuat kalender yang tampak penuh dengan memindahkan kasus lama, mengandalkan cuplikan pencarian, atau mengubah dugaan menjadi kepastian. Jika sumber belum menyediakan rincian, keterbatasan tersebut dipertahankan.

Math_Symbol.js bukan nama library yang perlu dihapus sembarangan

Dalam analisis ChainDrop, Elastic membedakan Math_Symbol.js sebagai nama payload pada paket awal dan math_init.js pada paket yang terinfeksi melalui penyebaran worm. Keduanya bukan nama library npm dalam daftar paket terdampak. Sumber tersebut mengaitkan berkas itu dengan keluarga keyv dan penyebaran ke paket lain. Elastic ChainDrop (2026/08).

The payload appears under two filenames

Payload muncul dengan dua nama berkas.

[Elastic ChainDrop (2026/08), How the CHAINDROP worm works]

Rekomendasi editorialnya adalah memeriksa konteks setiap temuan. Jika pencarian lokal menemukan berkas dengan nama mirip, catat lokasi lengkap, paket induk, versi, waktu pemasangan, dan hash berkas bila tersedia. Nama saja tidak layak dijadikan dasar menyatakan suatu mesin terinfeksi. Sebuah catatan investigasi yang hanya mengatakan “ada file math” akan sulit digunakan orang lain untuk memverifikasi kesimpulan.

Bayangkan dua pengembang hipotetis. Pengembang pertama menemukan nama berkas itu dalam salinan artikel riset yang disimpan sebagai teks. Pengembang kedua menemukannya di direktori dependency versi yang tercantum dalam advisory, disertai log proses pada waktu pemasangan. Keduanya memiliki hasil pencarian nama yang sama, tetapi kualitas bukti berbeda. Contoh ini bukan laporan korban tertentu. Tujuannya menunjukkan mengapa lokasi dan bukti pendukung perlu dicatat bersama nama berkas.

Ketika berdiskusi dengan tim, gunakan kalimat yang spesifik: “Kami menemukan paket X versi Y pada runner Z, dan sedang memastikan apakah pemicunya berjalan.” Kalimat tersebut lebih berguna daripada “JavaScript kita kena malware”. Bahasa yang jelas membantu pemilik layanan memahami apa yang sudah diketahui dan apa yang masih diperiksa, sekaligus mengurangi perubahan darurat yang tidak mempunyai dasar.

Dua kelompok ancaman yang harus dipisahkan

Kelompok pertama adalah paket yang memang mempunyai penggunaan sah, tetapi rilis tertentu dilaporkan disusupi. Axios memberi contoh konkret: Socket mengidentifikasi axios@1.14.1 dan axios@0.30.4 yang menarik dependency berbahaya plain-crypto-js@4.2.1. Kelompok kedua adalah paket yang sengaja dibuat sebagai umpan. Microsoft melaporkan kelompok paket peniru ekosistem OpenSearch/Elastic pada 28 Mei 2026. Socket Axios (2026/03), Microsoft Typosquat (2026/05).

Pembedaan tersebut mengubah tindakan yang diperlukan. Dalam skenario editorial pertama, sebuah tim memakai paket sah dan ingin mengetahui apakah pembaruan minggu lalu memasukkan versi berbahaya. Pemeriksaannya berpusat pada riwayat versi dan build. Dalam skenario kedua, seorang developer baru saja menambahkan paket yang namanya ditemukan dalam tutorial tanpa memeriksa sumbernya. Pemeriksaannya perlu mencakup asal nama, metadata paket, dan alasan pemilihan dependency itu.

Untuk pembaca nonteknis, perbedaan ini dapat dipahami seperti perbedaan antara produk asli dengan satu batch bermasalah dan produk tiruan yang sejak awal menipu pembeli. Analogi tersebut hanya membantu menjelaskan kategori. Ia tidak berarti mekanisme distribusi software sama dengan distribusi barang fisik. Kembali ke data yang dapat diperiksa: nama, versi, sumber, waktu, dan lingkungan yang menggunakannya.

Paket berbahaya sejak awal: jangan disamakan dengan proyek asli

Microsoft melaporkan 14 paket berbahaya yang dipublikasikan pada 28 Mei 2026, termasuk nama seperti opensearch-setup, opensearch-config-utility, dan env-config-manager. Laporan itu menjelaskan penggunaan metadata yang mengarah ke proyek sah untuk membangun kesan tepercaya. Temuan ini tidak membuktikan bahwa proyek OpenSearch atau Elasticsearch asli ikut disusupi dalam kampanye tersebut. Microsoft Typosquat (2026/05).

Dalam laporan terpisah bertanggal 29 Mei, Microsoft menjelaskan paket yang meniru namespace internal organisasi, antara lain scope @cloudplatform-single-spa, @payments-widget, dan @sber-ecom-core. Peneliti menempatkannya dalam teknik dependency confusion dan membahas reconnaissance. Artikel ini tidak menyajikan semua nama dalam scope tersebut sebagai paket jahat; penetapan berlaku pada paket yang diidentifikasi sumber. Microsoft Dependency Confusion (2026/05).

Sonatype juga melaporkan kampanye Flooding Dropper pada 5 Agustus 2026. Nama bigops-backend, bigops-api, dan dolyame-boxy-desktop-bnpl-card-gallery muncul sebagai contoh. Peneliti mencatat 846 komponen dalam pengamatan saat itu dan menyebut pemicu melalui pemasangan atau import. Angka komponen tersebut tidak disajikan di sini sebagai jumlah korban. Sonatype Flooding Dropper (2026/08).

Rekomendasi editorial untuk proses pemilihan paket adalah menuliskan alasan pemilihan sebelum pemasangan. Catatan sederhana dapat memuat fungsi yang dibutuhkan, dokumentasi resmi yang merekomendasikan paket, alternatif yang dipertimbangkan, dan orang yang menyetujui perubahan. Tujuannya bukan membuat birokrasi untuk setiap baris kode. Tujuannya membuat keputusan bisa ditelusuri ketika nama yang dipilih belakangan dipertanyakan.

Misalnya, dalam skenario hipotetis, seorang developer diminta menghubungkan fitur pencarian. Ia menemukan paket dengan nama yang terdengar seperti alat setup resmi, tetapi dokumentasi proyek yang ingin dipakai tidak pernah menyebutnya. Langkah kerja yang disarankan adalah berhenti sejenak dan meminta tautan dokumentasi yang menjadi dasar. Bila tidak ada dasar yang bisa diverifikasi, pilih pendekatan yang sudah didokumentasikan atau lakukan evaluasi paket di lingkungan terpisah yang disiapkan tim.

Contoh kedua adalah dependency internal perusahaan. Usulan editorialnya adalah membuat daftar pemilik namespace dan jalur distribusi yang diharapkan. Saat review melihat nama internal tetapi sumber unduhnya tidak sesuai harapan, review harus berhenti untuk memastikan konfigurasi. Jangan menebak bahwa versi yang lebih tinggi otomatis merupakan versi internal yang lebih baru. Keputusan harus mengikuti aturan distribusi organisasi, bukan penampilan metadata.

Mengapa tabel versi lebih berguna daripada daftar nama populer

Tabel insiden sebaiknya dipakai sebagai titik awal investigasi. Ia bukan daftar larangan permanen. Cara editorial yang disarankan adalah menambahkan empat kolom kerja pada salinan tabel: ditemukan di proyek mana, digunakan pada tanggal berapa, mesin atau runner yang terlibat, dan status eksekusi. Dengan demikian, daftar berita berubah menjadi daftar pekerjaan yang dapat ditutup satu per satu.

Bayangkan tim hipotetis dengan tiga website. Website pertama sudah menggunakan versi yang berbeda dari advisory. Website kedua menyimpan versi terdampak dalam branch eksperimen yang belum dibangun. Website ketiga membangun aplikasi dengan versi yang cocok pada runner yang menyimpan kredensial deployment. Ketiganya memerlukan pemeriksaan, tetapi hasil pemeriksaannya tidak pantas diringkas menjadi satu kalimat “semua website terinfeksi”.

Pada website pertama, tugasnya mungkin memastikan bahwa catatan versi dan build memang konsisten. Pada website kedua, tugasnya memastikan branch tersebut belum dipakai oleh proses lain dan menyiapkan pembaruan sebelum ada eksekusi. Pada website ketiga, tugasnya mencakup penanganan lingkungan build dan akses yang tersedia. Semua ini adalah ilustrasi pengambilan keputusan, bukan pernyataan bahwa kondisi tertentu selalu menghasilkan dampak tertentu.

Salah satu laporan yang memperlihatkan pentingnya pemicu adalah jscrambler. StepSecurity mencatat rilis 8.14.0, 8.16.0, dan 8.17.0 dengan preinstall, sedangkan 8.18.0 dan 8.20.0 menggunakan kode pada entry point modul. Karena itu, pemeriksaan yang hanya melihat keberadaan install hook tidak mencakup semua rilis yang disebut laporan tersebut. StepSecurity jscrambler (2026/07).

Rekomendasi editorialnya adalah menambahkan kolom “pemicu menurut sumber” pada daftar kerja. Kolom tersebut membantu investigator memutuskan log apa yang perlu dicari. Jika pemicu berupa pemasangan, periksa riwayat pemasangan dan konfigurasi yang berlaku saat itu. Jika pemicu berupa pemuatan modul, periksa proses yang menggunakan modul tersebut. Jika sumber masih menyelidiki, catat ketidakpastian dan jangan menggantikannya dengan dugaan.

Memahami risiko tanpa mengarang angka korban

Artikel ini sengaja tidak menjumlahkan angka unduhan bulanan atau mingguan dari berbagai laporan. Sebuah angka popularitas mungkin menjelaskan skala penggunaan paket, tetapi penggabungan lintas periode dan lintas paket tidak menghasilkan jumlah korban yang dapat dipercaya. Rekomendasi editorial untuk pembaca adalah menuntut definisi setiap angka: apa yang dihitung, selama periode apa, dan apakah angka itu menunjukkan unduhan, versi, komponen, atau perangkat yang benar-benar diamati.

Dalam skenario hipotetis, sebuah organisasi mengunduh dependency yang sama berkali-kali pada build otomatis. Organisasi itu mungkin menghasilkan banyak permintaan unduhan tetapi tidak mewakili banyak manusia berbeda. Skenario lain adalah satu paket yang hadir sebagai dependency transitif dalam beberapa aplikasi. Tanpa data yang membedakan pengulangan, angka popularitas tidak boleh diubah menjadi jumlah perusahaan terdampak.

Untuk artikel publik, usulan editorialnya adalah mengutamakan kalimat seperti “peneliti mengidentifikasi versi berikut” atau “laporan mencatat sejumlah komponen pada saat publikasi”. Hindari kalimat yang menyatakan “semua penggunanya diretas” jika sumber tidak menyediakan bukti tersebut. Judul yang kuat tetap dapat dibangun dari kejadian nyata tanpa memperbesar kepastian atau menyamakan risiko dengan dampak yang sudah terjadi.

Pola yang sama berlaku untuk kemampuan malware. Sebuah laporan bisa membedakan fitur dalam kode dengan fitur yang aktif pada sampel yang diteliti. JFrog, misalnya, menyebut sejumlah modul otomatis pada sampel AsyncAPI tidak aktif, sementara jalur remote shell tetap aktif. Artikel ini mengikuti pembedaan sumber tersebut dan tidak mengatribusikan semua kemampuan keluarga Miasma kepada setiap insiden. JFrog AsyncAPI (2026/07).

Ilustrasi dibuat dengan AI untuk menjelaskan konsep. Gambar bukan tangkapan layar insiden, bukti forensik, atau representasi jaringan korban tertentu.

Rilis yang perlu dicocokkan: Axios sampai Tensorlake

Daftar berikut adalah pilihan insiden yang sumber primernya telah dibaca. Tanggal pada kolom pertama adalah tanggal publikasi laporan atau tanggal kejadian yang disebut eksplisit, sebagaimana dijelaskan pada sel. Versi harus dibandingkan persis, termasuk scope, nomor mayor, dan akhiran prerelease. Daftar ini tidak menggantikan advisory yang dapat diperbarui.

Daftar tersebut sengaja menampilkan versi satu per satu. Pada jscrambler, sumber menyatakan rilis bersih dan rilis berbahaya tidak membentuk satu rentang kontinu. Menuliskan semua nomor antara versi pertama dan versi terakhir sebagai berbahaya akan melebihkan temuan. StepSecurity jscrambler (2026/07).

Socket mengaitkan rilis Tensorlake dengan ChainDrop/Shai-Hulud dan menjelaskan bahwa SDK dipasang pada mesin developer. Artikel ini membatasi temuan pada SDK npm tensorlake@0.5.144; temuan tersebut bukan pernyataan bahwa seluruh layanan sandbox Tensorlake atau semua aplikasi pelanggannya telah terinfeksi. Socket Tensorlake (2026/10).

Version 0.5.144 contains obfuscated malware

Versi 0.5.144 mengandung malware yang diobfuscate.

[Socket Tensorlake (2026/10), opening]

Untuk Bitwarden, sumber awal menggunakan bahasa penyelidikan yang belum final dan mengidentifikasi paket CLI. Pembaca perlu mempertahankan batas itu ketika menyampaikan berita: jangan menyatakan seluruh password vault pengguna atau semua produk Bitwarden terdampak hanya berdasarkan temuan CLI tersebut. Socket Bitwarden (2026/04).

Rekomendasi editorial untuk penggunaan tabel adalah menyimpannya bersama tanggal pemeriksaan. Bila advisory berubah, catat perubahan pada daftar kerja, lalu periksa kembali kecocokan versi. Jangan mengganti seluruh hasil sebelumnya tanpa riwayat, karena orang yang meninjau keputusan perlu mengetahui informasi yang tersedia pada waktu keputusan pertama dibuat.

Insiden tambahan dari Januari hingga September

Tabel berikut menambah cakupan di luar daftar sebelumnya. Tanggal laporan diberi label agar tidak tertukar dengan awal kejadian. Untuk versi atau daftar lengkap yang belum terambil, artikel mempertahankan batas tersebut.

TanStack, AntV, dan Red Hat: skala kampanye perlu definisi yang tepat

Postmortem resmi TanStack menyatakan bahwa insiden 11 Mei 2026 melibatkan 42 paket pada repository Router/Start dengan dua versi per paket, sehingga berjumlah 84 versi. Pengelola menyatakan keluarga lain, termasuk Query, Table, dan DB, tidak terdampak. Akar serangan dalam postmortem mencakup penyalahgunaan workflow, cache poisoning, dan pengambilan token OIDC dari runtime. Sumber secara eksplisit menyatakan tidak ada token npm yang dicuri dan workflow publikasi npm sendiri tidak terkompromi. TanStack Postmortem (2026/05).

Only the Router/Start repo was affected

Hanya repository Router/Start yang terdampak.

[TanStack Postmortem (2026/05), Status 2026-05-15]

Pada AntV, Socket mencatat 639 versi pada 323 nama paket dalam gelombang 19 Mei. Cakupannya termasuk nama di luar scope @antv. Contoh versi yang disebut adalah @antv/f2-site@4.2.42. Daftar dinamis lengkap tidak berhasil diambil dalam riset ini, sehingga artikel tidak menerbitkan rentang versi dugaan untuk setiap library visualisasi. Socket AntV (2026/05).

Advisory resmi Red Hat menjelaskan aktivitas awal pada 29 Mei 2026 melalui akun GitHub yang dikompromikan oleh ekstensi VS Code berbahaya. Investigasi vendor mengidentifikasi 32 paket npm @redhat-cloud-services yang disusupi dan dipublikasikan. Red Hat menyatakan tidak ada produk Red Hat yang dibangun atau dikirim dengan paket terkompromi tersebut. Pernyataan itu penting: nama namespace tidak boleh diperluas menjadi klaim bahwa semua layanan cloud Red Hat terdampak. Red Hat RHSB-2026-006 (2026/06, pembaruan dibaca 2026/10).

Rekomendasi editorial untuk membaca ketiga laporan adalah memulai dari definisinya. Angka versi tidak sama dengan angka nama paket, dan angka nama paket tidak sama dengan angka pengguna. Jika perlu membuat dashboard insiden internal, gunakan kolom terpisah untuk kampanye, nama paket, versi, proyek yang menggunakan, serta perangkat yang sudah diperiksa. Jangan membuat satu total besar dari unit yang berbeda.

Cara menilai berita insiden dengan tepat

Bagian berikut merupakan kerangka editorial orisinal, berisi contoh hipotetis untuk membantu pembaca menilai berita. Contoh paket generik tidak menunjuk insiden nyata. Bagian ini tidak menambahkan klaim baru tentang korban atau aktivitas operator.

Mulai dari pertanyaan yang benar

Ketika membaca daftar library yang pernah disusupi, pertanyaan paling berguna adalah apakah rilis yang dipakai dalam proyek termasuk rilis yang disebut laporan. Nama besar dapat membuat orang cemas, tetapi nama saja tidak menyelesaikan pemeriksaan. Kita membutuhkan nama paket lengkap, nomor versi, waktu pemasangan, dan titik eksekusi. Empat unsur tersebut menghasilkan keputusan yang jauh lebih konkret dibanding kesimpulan bahwa seluruh ekosistem JavaScript tidak dapat dipercaya.

Bayangkan sebuah laporan hipotetis menyebut paket contoh-utils versi 2.1.7. Sebuah proyek memiliki 2.1.6 yang terkunci sejak bulan sebelumnya, sedangkan proyek lain mengambil 2.1.7 melalui pembaruan otomatis. Kedua proyek sama-sama “menggunakan contoh-utils”, tetapi pemeriksaannya berbeda. Tim pertama perlu memverifikasi bahwa artefak memang cocok dengan versi terkunci. Tim kedua perlu menelusuri apakah script atau fungsi berbahaya sempat dijalankan. Informasi nama tanpa versi akan menyatukan dua keadaan tersebut secara keliru.

Karena itu, daftar ini sebaiknya dibaca sebagai peta pemeriksaan, bukan daftar hitam permanen. Rilis yang pernah disusupi tetap perlu dicatat, tetapi riwayat kompromi tidak cukup untuk menyatakan semua rilis terdahulu dan semua rilis perbaikan membawa payload yang sama. Kalimat yang tepat menunjuk batas bukti: versi tertentu ditemukan memiliki komponen berbahaya, menurut laporan bertanggal tertentu. Pembaca kemudian menghubungkan catatan tersebut dengan bukti dalam lingkungannya sendiri.

Jangan mencampur tiga jenis tanggal

Tanggal kejadian, tanggal ditemukan, dan tanggal artikel terbit menjawab pertanyaan berbeda. Tanggal kejadian membantu menentukan jendela paparan. Tanggal ditemukan menjelaskan kapan peneliti atau pengelola mulai menyadari masalah. Tanggal artikel terbit menjelaskan kapan informasi tersedia bagi publik. Ketiganya bisa berada pada hari yang sama, tetapi tidak harus demikian. Dalam penulisan rangkuman, memberi label pada tanggal lebih berguna daripada memilih salah satunya lalu membiarkan pembaca menebak artinya.

Contoh hipotetisnya: rilis berbahaya terbit 28 Januari, terdeteksi 29 Januari, lalu laporan panjang muncul 6 Februari. Untuk kronologi kejadian, tempatkan kasus pada Januari. Untuk daftar publikasi penelitian, Februari masuk akal. Kesalahan muncul ketika tanggal 6 Februari diubah menjadi klaim bahwa penyerang pertama kali menyerang 6 Februari. Pergeseran tersebut dapat menyebabkan tim memeriksa log pada rentang yang salah dan melewatkan pemasangan pada akhir Januari.

Catat juga zona waktu. Waktu 00.30 UTC berada pada pagi hari di Indonesia bagian barat. Apabila sebuah pengumuman menggunakan waktu lokal Amerika, tanggal kalendernya dapat berbeda dari UTC. Artikel pembaca umum cukup menampilkan tanggal yang jelas dan menambahkan UTC pada waktu teknis. Pemeriksa insiden membutuhkan waktu yang lebih presisi untuk membandingkan log instalasi, build, dan publikasi paket.

Batas waktu riset perlu terlihat sejak pembuka. Artikel yang ditulis 12 Oktober tidak dapat merangkum kejadian November atau Desember yang belum terjadi. Frasa “sepanjang 2026 hingga 12 Oktober” mempertahankan tujuan pengguna sekaligus menghindari kesan bahwa penelitian telah mencakup satu tahun lengkap. Pembaruan berikutnya bisa menambah temuan setelah batas tersebut dengan tanggal revisi yang transparan.

Unduhan mengukur distribusi, bukan jumlah korban

Angka unduhan sering menjadi pusat judul berita karena mudah dibandingkan. Namun pembaca sebaiknya bertanya apa yang sebenarnya dihitung: unduhan seluruh versi, unduhan versi berbahaya, unduhan mingguan paket, atau perkiraan potensi paparan dependensi. Keempatnya tidak dapat dipertukarkan. Popularitas sebuah library menjelaskan mengapa insiden penting, tetapi tidak otomatis menunjukkan jumlah mesin yang menjalankan payload.

Sebagai ilustrasi hipotetis, paket dengan satu juta unduhan mingguan dapat memiliki rilis berbahaya yang hanya tersedia dua jam. Sebagian unduhan mingguan terjadi sebelum rilis tersebut. Sebagian sistem masih menggunakan versi terkunci. Unduhan lain dapat berasal dari cache atau proses otomatis yang berulang pada mesin yang sama. Menulis “satu juta korban” dari angka tersebut akan melampaui bukti yang tersedia.

Sebaliknya, jumlah unduhan versi berbahaya juga bukan jumlah orang yang datanya pasti dicuri. Ada instalasi yang tidak menjalankan script, ada modul yang belum pernah diimport, dan ada lingkungan tanpa rahasia yang dicari payload. Kemungkinan tersebut bukan alasan untuk menyepelekan risiko. Itu alasan untuk membedakan luas distribusi, eksekusi, dan dampak yang sudah dikonfirmasi agar keputusan respons lebih akurat.

Prinsip yang sama berlaku ketika menjumlahkan library terkait. Apabila paketA bergantung pada paketB, satu pemasanganA bisa menghasilkan unduhanB. Menjumlahkan statistik keduanya dapat menghitung aktivitas yang tumpang tindih. Dalam artikel, lebih aman menampilkan angka masing-masing sebagai konteks dan menjelaskan bahwa angka tersebut tidak dijadikan total korban atau total pemasangan unik.

Nama file berbeda dari nama paket

Sebuah file JavaScript dapat menjadi payload dalam paket yang nama resminya berbeda. Nama sepertisetup.js, runtime.js, atauMath_Symbol.js adalah bagian struktur artefak. Registry mengidentifikasi paket melalui nama dan versi. Mencari nama file dapat membantu investigasi, tetapi mengira nama file sebagai library npm akan menghasilkan pencarian yang tidak tepat dan mungkin mengabaikan paket induk.

Dalam contoh hipotetis, contoh-sdk3.2.1 membawa lib/agent.js yang berbahaya. Proyek tidak akan memiliki dependensi bernamaagent.js dalam package.json. Pemeriksa perlu menemukancontoh-sdk dan versi 3.2.1, kemudian menilai isi artefaknya. Nama file tetap berguna sebagai indikator tambahan, terutama saat memeriksa hasil build atau jejak filesystem, tetapi bukan pengganti nama paket lengkap.

Perhatikan pula nama scoped. @perusahaan/sdk, sdk, dan@perusahaan/sdk-tools adalah identitas berbeda. Tanda@, garis miring, dan tanda hubung memiliki arti dalam nama. Penyederhanaan terlalu jauh dapat mengarahkan pembaca pada library yang tidak terkait. Tabel versi sebaiknya mempertahankan ejaan persis, sementara penjelasan umum boleh memakai nama produk yang lebih mudah dibaca.

Bedakan kode bawaan berbahaya dan dependensi tambahan

Rilis sah yang disusupi dapat menyimpan payload langsung di kode utama atau membawa paket lain melalui perubahan manifest. Pada bentuk kedua, kode fungsional library terlihat sama, tetapi dependensinya menambah jalur eksekusi. Karena itu, memeriksa hanya perbedaan file sumber dapat memberi gambaran yang belum lengkap. Dalam pembacaan laporan, lihat apakah peneliti menemukan modifikasi kode, dependency injection, atau kombinasi keduanya.

Contoh hipotetisnya adalah sebuah SDK yang mendapatkan dependensi baru bernamacontoh-date-extra. Fungsi SDK tetap berjalan seperti sebelumnya. Saat paket tambahan dipasang, hook miliknya menjalankan payload. Bagi pengguna, pintu masuknya tetap SDK yang mereka percaya. Bagi pencatatan penelitian, nama SDK yang terkompromi dan nama dependency pembawa payload perlu dibedakan agar pembaca mengetahui dua komponen yang harus diperiksa.

Tidak semua penambahan dependensi merupakan malware. Pembaruan normal juga dapat menambah library. Redaksi sebaiknya menyebut perilaku yang dibuktikan penelitian, misalnya pembacaan kredensial, eksekusi payload eksternal, atau pengiriman data ke infrastruktur yang tidak sesuai fungsi. Kebaruan sebuah dependensi merupakan sinyal untuk pemeriksaan, sedangkan kesimpulan malware membutuhkan bukti perilaku atau konfirmasi yang memadai.

Kehadiran tidak selalu sama dengan eksekusi

Paket bisa hadir di lockfile, tersimpan di cache, terpasang dalam node_modules, atau sudah dijalankan. Keempat keadaan ini membentuk jenjang bukti. Daftar dependency memberi tahu apa yang dipilih resolver. Log instalasi memberi petunjuk apakah lifecycle script diizinkan. Log build, test, dan aplikasi membantu menentukan apakah modul dimuat. Jejak proses dan jaringan membantu menilai aktivitas sesudahnya.

Untuk malware install-time, pemasangan dengan script diizinkan dapat menjadi peristiwa penting. Untuk malware import-time, mengunduh paket saja mungkin belum memicu payload, tetapi test atau build yang memuat modul dapat memicunya. Artikel perlu menjaga perbedaan ini. Pembaca yang hanya mematikan install script jangan dibuat merasa seluruh jenis implant sudah tertangani.

Ada pula payload yang aktif ketika fungsi tertentu menerima input sensitif. Dalam contoh hipotetis, fungsi pengelolaan wallet menyalin seed phrase saat dipanggil. Pengembang yang hanya menyimpan paket tanpa memakai fungsi tersebut menghadapi keadaan berbeda dari layanan yang mengolah wallet sungguhan. Bukti pemanggilan fungsi dan jenis data yang diberikan menjadi bagian penilaian, tanpa perlu menerbitkan data rahasia dalam laporan.

Kemampuan malware bukan bukti semua tindakan terjadi

Analisis kode dapat menunjukkan bahwa malware memiliki fungsi membaca SSH key, mencari kredensial cloud, atau menjalankan perintah jarak jauh. Temuan tersebut mendukung klaim kemampuan. Klaim bahwa rahasia tertentu benar-benar dicuri dari sebuah perusahaan membutuhkan bukti tambahan dari investigasi lingkungan korban. Artikel sebaiknya tidak mengubah daftar kemampuan menjadi cerita kerugian yang belum dikonfirmasi.

Pilihan kata membantu mempertahankan batas tersebut. “Dirancang untuk mencari token” menjelaskan fungsi kode. “Peneliti mengamati pengiriman token dalam sampel” menjelaskan observasi yang lebih kuat. “Perusahaan mengonfirmasi tokennya dicuri” membutuhkan pernyataan perusahaan atau bukti forensik terkait. Ketika statusnya masih belum diketahui, katakan demikian dan jelaskan apa yang perlu diperiksa.

Begitu pula atribusi. Kesamaan nama file, tema pesan, atau infrastruktur dapat mendukung hubungan teknis yang dibahas peneliti, tetapi tidak selalu mengidentifikasi operator yang sama. Gunakan kategori yang dinyatakan sumber: kemiripan keluarga malware, indikator kode yang sama, dugaan keterkaitan, atau atribusi dengan tingkat keyakinan tertentu. Tidak perlu menyederhanakan semuanya menjadi satu kelompok penyerang.

Hitung paket, versi, kampanye, dan korban secara terpisah

Satu paket dapat memiliki beberapa versi berbahaya. Satu kampanye dapat menjangkau beberapa nama paket. Satu penerbit dapat mengelola beberapa scope, sementara satu mesin dapat mengunduh beberapa paket dalam satu build. Karena unitnya berbeda, angka kampanye tidak boleh langsung dijumlahkan untuk menghasilkan total library atau total korban sepanjang tahun.

Misalnya, sebuah laporan hipotetis mencatat 20 nama paket dan 60 versi. Laporan berikutnya mencatat 50 versi tambahan, sebagian berasal dari 20 nama yang sama. Menjumlahkan menjadi 110 library salah dua kali: versi diperlakukan sebagai nama, dan paket yang berulang dihitung lagi. Penelitian yang ingin memberi total membutuhkan dataset versi lengkap serta deduplikasi identitas yang konsisten.

Untuk artikel yang bertujuan membantu pemeriksaan, daftar contoh terverifikasi sering lebih berguna daripada total besar yang tidak jelas. Tulis bahwa tabel merangkum kasus yang berhasil diverifikasi, cantumkan sumber daftar lengkap jika tersedia, dan hindari label “seluruh paket” ketika bagian tabel dinamis belum terambil. Batas kelengkapan yang jujur meningkatkan nilai praktis tulisan.

Nilai sumber dan perubahan statusnya

Laporan peneliti, advisory pengelola paket, dan berita media memiliki fungsi berbeda. Peneliti dapat memberi analisis perilaku yang rinci. Pengelola dapat memastikan cakupan sistem yang diperiksa dan rilis pemulihan. Media membantu merangkum respons publik. Ketika ada perbedaan, pembaca perlu melihat definisi dan waktu publikasi sebelum menyimpulkan salah satu pihak keliru.

Status “masih tersedia”, “latest berbahaya”, atau“investigasi berlangsung” perlu diberi waktu. Kalimat yang benar saat publikasi awal dapat menjadi usang sesudah paket diturunkan atau diperbaiki. Untuk artikel historis, gunakan frasa “pada saat laporan diterbitkan”. Untuk panduan pemasangan hari ini, verifikasi advisory terbaru dan jangan menganggap status awal masih berlaku.

Dengan cara baca tersebut, daftar insiden menjadi alat kerja yang jelas. Pembaca memperoleh identitas versi, konteks tanggal, jalur pemicu, batas observasi, dan sumber pemeriksaan. Tujuannya adalah membantu mengambil tindakan yang sesuai bukti, sambil tetap memisahkan risiko potensial dari dampak yang sudah diketahui.

Setelah membaca daftar malware, bagaimana memeriksa proyek sendiri?

Daftar paket berbahaya baru berguna ketika pembaca dapat menghubungkannya dengan proyek yang benar-benar dikelola. Nama yang muncul di berita belum menjawab apakah paket itu ada di laptop, pernah dipasang oleh pipeline, atau ikut menghasilkan berkas JavaScript yang sekarang disajikan kepada pengunjung. Karena itu, bagian ini menawarkan panduan defensif untuk mengubah informasi publik menjadi pemeriksaan yang tertata. Seluruh skenario organisasi, toko daring, blog, dan pengembang di bagian ini adalah contoh hipotetis. Skenario tersebut bukan laporan korban dari insiden yang dibahas sebelumnya.

Catatan editorial: alur kerja, pembagian tugas, prioritas, dan contoh keputusan berikut adalah rekomendasi penulis. Rekomendasi ini perlu disesuaikan dengan kewenangan tim, bukti yang tersedia, dan kebutuhan layanan. Klaim tentang perilaku perintah npm serta kemampuan platform diberi rujukan ke dokumentasi resmi. Tujuannya membantu pembaca membuat keputusan yang dapat ditelusuri, bukan menjanjikan bahwa satu alat mampu menemukan semua malware.

1. Mulai dari pertanyaan paparan, bukan dari tombol perbaikan

Rekomendasi editorial pertama adalah menulis pertanyaan pemeriksaan sebelum menjalankan alat. Pertanyaan awal yang baik berbunyi: apakah nama dan versi paket dalam advisory pernah hadir di lingkungan yang kami gunakan selama rentang waktu relevan? Pertanyaan berikutnya: apakah kode paket tersebut sempat dijalankan, dan akses apa yang tersedia pada lingkungan itu? Pertanyaan ketiga: apakah hasil pekerjaan dari lingkungan itu dipakai untuk merilis sesuatu kepada pengguna? Urutan ini membantu tim menghindari lompatan dari sebuah headline menuju kesimpulan bahwa seluruh server sudah terinfeksi.

Bayangkan sebuah tim hipotetis menerima kabar bahwa versi tertentu dari utilitas JavaScript telah disisipi kode berbahaya. Pengembang A membuka berkas proyek dan tidak menemukan nama utilitas itu di daftar dependensi utama. Pengembang B langsung memperbarui semua paket. Pengelola layanan kemudian bertanya apakah perubahan tersebut menyelesaikan risiko token deploy yang mungkin sudah terbaca. Ketiganya berbicara tentang objek berbeda: daftar dependensi, keadaan perangkat, dan kewenangan akun. Tanpa pertanyaan pemeriksaan yang jelas, aktivitas mereka dapat terlihat sibuk tetapi tetap menyisakan inti persoalan.

Saran kami adalah membuat catatan awal berisi nama paket persis, versi yang dilaporkan, sumber advisory, waktu publikasi, rentang waktu paparan yang diketahui, dan proyek yang akan diperiksa. Jangan menambahkan versi ke daftar terdampak hanya karena nomornya berdekatan. Jangan menganggap nama yang mirip sebagai paket yang sama. Tuliskan pula hal yang belum diketahui. Kolom kosong yang diberi label belum terverifikasi lebih berguna daripada tebakan yang kemudian dianggap fakta oleh anggota tim lain.

Gunakan tiga tingkat kesimpulan kerja: belum ditemukan dalam bukti yang diperiksa; ditemukan tetapi eksekusi belum diketahui; dan ditemukan dengan indikasi eksekusi atau penggunaan pada proses build. Ketiga tingkat tersebut adalah kategori editorial untuk mengatur pekerjaan, bukan kategori resmi npm. Catat juga cakupannya. Pernyataan tidak ditemukan pada lockfile cabang utama hari ini lebih sempit daripada tidak pernah digunakan dalam seluruh riwayat organisasi. Perbedaan kalimat tersebut menentukan apakah pemeriksaan berikutnya masih diperlukan.

2. Jangan berhenti di package.json

Dokumentasi resmi npm menjelaskan bahwa npm ls menampilkan versi paket yang terpasang dan dapat menampilkan seluruh dependensi dengan opsi --all. Tampilan tersebut merupakan pohon dependensi logis, bukan gambaran persis susunan direktori fisik. Opsi --package-lock-only membuat daftar didasarkan pada lockfile dan mengabaikan isi node_modules. Rujukan: npm Docs (diakses 2026/10), npm ls.

Saran kami adalah membandingkan sekurang-kurangnya dua sumber: keadaan yang dikunci untuk proyek dan keadaan instalasi yang sedang diperiksa. Daftar dependensi utama berguna untuk mengetahui keputusan langsung tim, sedangkan pohon lengkap membantu menemukan paket yang dibawa oleh paket lain. Ketika dua sumber berbeda, jangan buru-buru menyamakan keduanya. Simpan perbedaannya sebagai petunjuk. Bisa jadi instalasi belum diselaraskan, sebuah cabang memakai konfigurasi berbeda, atau ada keluaran pemeriksaan yang belum mencakup workspace tertentu.

Contoh perintah inventaris berikut membaca keadaan proyek. Jalankan dengan instalasi Node.js dan npm yang dipercaya, pada salinan bukti yang sesuai kewenangan. Perintah ini tidak dimaksudkan untuk memasang paket tersangka, mengimpor kodenya, atau mencoba menjalankan payload. Untuk monorepo, gunakan pemeriksaan pada workspace yang relevan dan dokumentasikan cakupannya.

npm ls --all --json
npm ls --all --package-lock-only --json
npm ls --global --depth=0 --json

Langkah berikutnya adalah membaca hasil sebagai inventaris, bukan sertifikat keamanan. Daftar paket yang lengkap belum mengatakan apakah suatu rilis dipercaya. Sebaliknya, paket yang tidak hadir di satu direktori sekarang belum membuktikan bahwa paket itu tidak pernah dipasang minggu lalu. Gabungkan inventaris dengan riwayat perubahan, catatan job, dan artefak rilis. Jika tujuan pemeriksaan adalah produksi, tulis dengan jelas apakah yang diperiksa instalasi produksi, lingkungan build, atau keduanya.

Tim kecil dapat memakai lembar kerja sederhana dengan kolom proyek, pemilik, paket yang dicari, versi ditemukan, sumber bukti, waktu bukti, dan langkah berikutnya. Rekomendasi ini sengaja tidak mewajibkan perangkat mahal. Yang lebih penting adalah setiap baris mempunyai pemilik dan bukti yang dapat dibuka kembali. Hindari jawaban lisan sudah dicek tanpa menyebut cakupan. Ketika beberapa orang bekerja bersamaan, jawaban tersebut sulit dibedakan dari belum ada masalah yang terlihat.

3. Cari jalur masuk dependensi transitif

Perintah npm explain dijelaskan npm sebagai alat untuk menampilkan rantai dependensi yang menyebabkan sebuah paket terpasang. Ia membantu menjawab mengapa paket tersebut ada di proyek. Rujukan: npm Docs (diakses 2026/10), npm explain.

npm explain nama-paket

Nama nama-paket di atas adalah placeholder yang harus diganti dengan nama yang sedang diperiksa. Saran kami adalah menyimpan keluaran pemeriksaan bersama versi dan proyeknya. Jangan menganggap satu jalur sebagai satu-satunya jalur. Jika paket muncul melalui beberapa dependensi induk, rencana pembaruan harus mempertimbangkan semuanya. Menghapus satu paket langsung dapat meninggalkan jalur lain yang masih memakai versi terkait. Tentukan siapa yang bertanggung jawab pada masing-masing induk sebelum mengubah konfigurasi.

Sebagai skenario hipotetis, sebuah website mempunyai alat bundling dan alat pengujian. Keduanya membawa utilitas yang sama, tetapi pada versi berbeda. Salah satu jalur berkaitan dengan build yang dipakai produksi; jalur lain hanya muncul ketika pengujian lokal dijalankan. Saran kami adalah mencatat kedua jalur secara terpisah. Keputusan terhadap rilis dapat membutuhkan tindakan segera pada jalur pertama, sedangkan pemeriksaan kredensial laptop tetap relevan terhadap jalur kedua jika kode pernah berjalan di perangkat pengembang.

Informasi jalur masuk juga berguna untuk komunikasi. Daripada menyuruh semua orang menghapus sebuah nama paket tanpa konteks, tim dapat mengatakan proyek tertentu membawanya melalui alat tertentu, versi tertentu, dan job tertentu. Pernyataan ini lebih mudah diuji. Pemilik alat tersebut dapat menilai pembaruan yang tersedia, kompatibilitas, serta cara menghasilkan ulang artefak. Pembaca yang bukan pengembang pun dapat mengikuti alasan mengapa sebuah perubahan dijadwalkan atau dipercepat.

4. Lockfile adalah bukti versi, bukan janji bahwa kode aman

Menurut dokumentasi npm, package-lock.json menggambarkan pohon dependensi yang dihasilkan sehingga instalasi berikutnya dapat memakai pohon yang sama. Dokumentasi tersebut juga menguraikan informasi seperti lokasi paket dan integritasnya. Rujukan: npm Docs (diakses 2026/10), package-lock.json.

Saran kami adalah memperlakukan lockfile sebagai catatan yang perlu ditinjau dan dipelihara. Saat ada perubahan dependensi, periksa versi, asal unduhan, dan perubahan yang tidak diharapkan. Jangan menekan tombol menerima perubahan hanya karena berkasnya panjang. Untuk perubahan besar, pecah review menjadi bagian yang dapat dibaca: paket langsung yang disengaja, dependensi transitif yang ikut berubah, dan pergantian sumber yang membutuhkan penjelasan. Tetapkan siapa yang memberi persetujuan untuk bagian terakhir.

Dalam konteks insiden, simpan lockfile sebelum perubahan pemulihan. Buat catatan commit yang menjadi sumber rilis terakhir dan commit yang dipakai pada build selama rentang paparan. Jika sebuah tim hanya menyimpan lockfile terbaru, ia dapat kehilangan konteks mengapa rilis terdahulu memakai versi yang berbeda. Rekomendasi editorial ini menekankan keterlacakan. Membuktikan keadaan masa lalu membutuhkan bukti masa lalu, bukan sekadar menghasilkan keadaan bersih hari ini.

Contoh perintah berikut membaca perubahan Git pada berkas yang relevan. Periksa hasil secara lokal dan hindari membagikan keluaran yang mengandung informasi internal ke forum publik.

git log --oneline -- package.json package-lock.json
git diff -- package.json package-lock.json
git status --short

Saran kami adalah mencatat keterbatasan riwayat. Riwayat repository tidak selalu mencakup semua instalasi manual di laptop atau job percobaan yang tidak menghasilkan commit. Karena itu, jangan mengubah tidak ada perubahan di Git menjadi tidak pernah terjadi pemasangan. Cocokkan informasi tersebut dengan catatan kerja dan log yang tersedia. Jika bukti tidak cukup, tulis tingkat keyakinan dan alasan. Catatan ketidakpastian yang jujur memungkinkan pemulihan dilakukan dengan proporsi yang masuk akal.

5. Bedakan informasi registry dari keadaan perangkat

Dokumentasi npm menyatakan npm view menampilkan informasi tentang sebuah paket di registry. Rujukan: npm Docs (diakses 2026/10), npm view. Metadata registry dapat membantu memeriksa versi, tetapi keluaran tersebut tidak membuktikan apa yang pernah terpasang pada perangkat tertentu.

Saran kami adalah menggunakan metadata sebagai pembanding. Sebelum menghubungi registry, pastikan nama yang ditanyakan tidak merupakan nama paket privat yang dilarang dibagikan ke layanan publik oleh kebijakan organisasi. Untuk informasi publik, periksa hanya bidang yang diperlukan. Jangan menyalin seluruh konfigurasi npm untuk mendapatkan satu jawaban karena konfigurasi dapat mempunyai informasi yang tidak perlu disebarluaskan. Prinsipnya adalah mengumpulkan bukti secukupnya tanpa menciptakan paparan baru.

Bayangkan paket tersangka sudah tidak tersedia untuk diunduh. Tim tetap dapat mempunyai lockfile, catatan job, atau arsip artefak yang menunjukkan pemakaiannya. Saran kami adalah melanjutkan pemeriksaan melalui bukti tersebut. Tidak tersedianya sebuah paket sekarang tidak otomatis menghapus kemungkinan paparan sebelumnya. Sebaliknya, jangan mencari salinan tersangka dari situs acak sekadar untuk mencoba sendiri. Bila diperlukan analisis sampel, pekerjaan itu sebaiknya dilakukan oleh pihak yang punya lingkungan dan kewenangan sesuai.

Saat membuat laporan bagi pemilik usaha, tulis sumber informasi dengan bahasa sederhana. Contohnya: registry saat diperiksa menunjukkan informasi tertentu, sedangkan lockfile dari rilis tertentu menunjukkan versi berbeda. Perbedaan ini tidak harus langsung diartikan sebagai serangan tambahan. Ia adalah temuan yang membutuhkan penjelasan. Penyajian demikian membantu menjaga ketepatan tanpa membuat pembaca merasa setiap ketidaksesuaian adalah bukti kompromi.

6. Gunakan npm audit sesuai fungsinya

Dokumentasi npm audit menerangkan pemeriksaan kerentanan dependensi serta berbagai pilihan keluarannya. Dokumentasi yang sama menyatakan bahwa npm audit fix menjalankan proses instalasi dan bahwa npm audit signatures dapat memverifikasi tanda tangan serta attestasi provenance paket yang diunduh. Rujukan: npm Docs (diakses 2026/10), npm audit.

npm audit --json

Perintah tersebut melakukan permintaan audit ke registry yang dikonfigurasi. Saran kami adalah memeriksa kebijakan organisasi sebelum mengirim data dependensi proyek privat. Audit juga perlu dijalankan dengan alat yang dipercaya dan pada keadaan proyek yang diketahui. Bila perangkat diduga telah dikompromikan, gunakan prosedur pengumpulan bukti dari lingkungan bersih yang sesuai. Jangan menganggap hasil perintah dari lingkungan tersangka sebagai satu-satunya dasar untuk menutup insiden.

Rekomendasi editorial yang paling penting: hasil tanpa temuan jangan ditafsirkan sebagai jaminan tidak ada malware. Gunakan hasil audit sebagai salah satu masukan, lalu cocokkan nama dan versi dengan advisory insiden yang relevan. Perhatikan juga waktu pemeriksaan. Sebuah hasil yang disimpan sebelum informasi publik tersedia menjawab keadaan pengetahuan pada saat itu. Ia tidak boleh dipakai untuk membantah bukti baru tanpa pemeriksaan ulang yang masuk akal.

Skenario hipotetisnya sederhana. Sebuah tim menemukan nol kerentanan pada audit, tetapi advisory resmi menyebut versi yang sama pernah berisi kode berbahaya. Saran kami adalah mengikuti bukti spesifik versi tersebut dan memeriksa paparan. Jangan mengakhiri investigasi hanya karena satu angka bernilai nol. Sebaliknya, angka kerentanan yang tinggi belum otomatis berarti malware sedang aktif. Pisahkan pekerjaan penanganan kerentanan umum dari respons terhadap paket berbahaya yang telah dikonfirmasi.

Hindari memakai npm audit fix --force sebagai langkah pertama respons malware. Dalam rekomendasi editorial artikel ini, perubahan versi harus melalui cabang kerja terpisah, review, dan pengujian yang relevan. Tujuannya mempertahankan bukti serta mengurangi risiko perubahan yang tidak dipahami. Pembaruan otomatis dapat berguna dalam pemeliharaan rutin, tetapi saat insiden tim memerlukan jawaban tentang keadaan sebelum dan sesudah perubahan. Perbaikan yang tidak tercatat menyulitkan penjelasan tersebut.

7. Pahami batas ignore-scripts

Dokumentasi npm tentang lifecycle menjelaskan adanya tahap seperti preinstall, install, postinstall, dan prepare dalam operasi terkait. Rujukan: npm Docs (diakses 2026/10), Scripts. Dokumentasi npm audit juga menjelaskan bahwa konfigurasi ignore-scripts tidak menghentikan skrip yang secara eksplisit diminta melalui perintah seperti npm run atau npm test, meskipun skrip sebelum dan sesudahnya tidak dijalankan. Rujukan: npm Docs (diakses 2026/10), npm audit.

Saran kami adalah menjadikan pembatasan skrip sebagai bagian dari rancangan build. Catat paket mana yang memerlukan skrip instalasi, alasan kebutuhannya, dan siapa yang menyetujui pengecualian. Jangan mengaktifkan semua skrip kembali hanya karena sebuah build gagal tanpa membaca penyebabnya. Berikan waktu untuk mencari apakah kegagalan berasal dari kebutuhan yang sah, ketidakcocokan konfigurasi, atau sesuatu yang belum dipahami.

Dalam artikel ini, contoh instalasi tanpa skrip bukan perintah audit read-only dan sengaja tidak diberikan sebagai langkah yang tinggal dijalankan pada perangkat tersangka. Proses pemasangan tetap mengubah lingkungan. Saran kami adalah menjalankannya hanya ketika tim telah memilih versi, lingkungan pemulihan, dan kontrol yang sesuai. Pemisahan ini mencegah pembaca menganggap sebuah flag membuat seluruh tindakan instalasi bebas risiko.

Skenario hipotetis lain: pengembang memblokir skrip instalasi lalu segera menjalankan alat build dari paket yang belum diperiksa. Ia merasa telah aman karena tahap pemasangan tidak menjalankan skrip. Saran kami adalah menilai kedua tahap secara terpisah. Persetujuan untuk mengunduh bukan persetujuan untuk menjalankan. Sebelum eksekusi berikutnya, pastikan paket yang akan dipakai, sumbernya, dan hak akses lingkungan sudah sesuai rencana. Pembatasan satu jalur eksekusi tidak boleh dijadikan alasan untuk mengabaikan jalur lainnya.

8. Build frontend juga perlu batas kepercayaan

Dokumentasi Node.js menjelaskan bahwa modul pihak ketiga berbahaya adalah risiko pada tingkat aplikasi dan bahwa kode dependensi yang dijalankan diperlakukan sebagai kode tepercaya. Dokumentasi tersebut juga mengingatkan tentang akses jaringan dan sistem berkas serta perbedaan yang mungkin ada antara kode repository dan paket yang dipublikasikan. Rujukan: Node.js (diakses 2026/10), Security Best Practices.

Saran kami adalah tidak mengecilkan risiko hanya karena paket terdaftar sebagai alat pengembangan. Pertanyaan yang perlu dijawab adalah di mana alat itu dijalankan dan apa yang tersedia baginya saat berjalan. Untuk laptop, catat apakah sesi build berlangsung bersamaan dengan akses kredensial kerja. Untuk CI, catat variabel dan izin job terkait. Untuk agen desain atau template, catat bagaimana berkas hasilnya masuk ke repository dan siapa yang meninjau dependensinya.

Dalam skenario hipotetis sebuah blog WordPress, pengelola menyewa pengembang untuk menyesuaikan tema. Repository tema mempunyai proses build JavaScript. Saran kami adalah memasukkan repository tersebut dalam daftar pemeriksaan walaupun server web memakai PHP. Pembagian yang berguna adalah tahap sumber, tahap build, dan tahap distribusi. Tim perlu mengetahui siapa yang mengelola masing-masing tahap, bukan berasumsi bahwa nama teknologi backend sudah menjawab seluruh risiko.

Untuk proyek Laravel hipotetis, lakukan hal serupa pada paket frontend dan pipeline aset. Pemeriksaan dapat mencakup sumber tema, komponen UI, alat bundling, serta cara berkas hasil build dipindahkan ke hosting. Ini adalah rekomendasi cakupan, bukan klaim bahwa Laravel atau WordPress pada insiden tertentu telah dikompromikan. Pendekatan yang baik adalah mengikuti proses nyata proyek. Jika suatu proyek tidak menggunakan npm sama sekali, catat fakta itu dan lanjutkan pemeriksaan hanya pada jalur JavaScript lain yang memang digunakan.

9. Susun garis waktu sebelum menentukan cakupan pemulihan

Saran kami adalah membuat garis waktu yang menghubungkan rilis paket, instalasi proyek, eksekusi job, dan distribusi artefak. Jangan mencampur waktu berita diterbitkan dengan waktu tim mulai terpapar. Catat zona waktu agar log dari laptop, CI, hosting, dan advisory tidak dibaca seolah-olah memakai jam yang sama. Jika hanya ada tanggal tanpa jam, gunakan presisi tersebut dan hindari menambahkan angka yang terlihat meyakinkan tetapi sebenarnya dibuat-buat.

Garis waktu sederhana dapat mencatat kejadian berupa pemasangan pertama yang diketahui, build pertama yang diketahui, deploy pertama yang diketahui, advisory yang diterima, penghentian job, pencabutan akses, dan rilis pemulihan. Saran kami adalah menambahkan kolom sumber bukti pada setiap kejadian. Kalimat menurut ingatan anggota tim masih dapat berguna sebagai petunjuk, tetapi harus dibedakan dari log yang tersimpan. Pembedaan ini membantu pembaca laporan memahami tingkat keyakinan tanpa meremehkan informasi manusia.

Tabel tersebut adalah kerangka kerja editorial. Tidak semua proyek akan memiliki seluruh bukti. Ketika satu bukti tidak tersedia, tulis kekosongan itu dan dampaknya terhadap keputusan. Misalnya, tidak adanya catatan instalasi lokal dapat membuat tim memilih pemulihan perangkat secara lebih hati-hati. Keputusan tersebut tidak harus diklaim sebagai bukti kompromi. Ia adalah pilihan mitigasi di tengah keterbatasan bukti, dan sebaiknya dijelaskan dengan bahasa demikian.

Ilustrasi konseptual dibuat dengan AI, bukan bukti insiden atau tampilan produk keamanan.

10. Lindungi bukti sebelum membersihkan lingkungan

Saran kami adalah meminta pemilik insiden menentukan bukti apa yang harus dipertahankan sebelum menghapus direktori atau mengulang job. Untuk proyek kecil, setidaknya pertahankan manifest, lockfile, definisi workflow, catatan versi Node.js dan npm, serta log yang relevan. Simpan informasi sensitif dalam tempat yang hanya dapat diakses pihak berwenang. Jangan menaruh salinan .env, token, atau private key dalam ZIP laporan publik demi membuat laporan terlihat lengkap.

Dokumentasi npm menjelaskan bahwa cache memeriksa integritas data ketika dimasukkan dan dikeluarkan, serta membedakan cache dari penyimpanan paket permanen yang dapat diandalkan. Rujukan: npm Docs (diakses 2026/10), npm cache. Integritas data pada cache tidak menjawab apakah isi paket memang layak dipercaya.

Saran kami adalah tidak menjadikan bersihkan cache sebagai sinonim selesaikan malware. Putuskan dulu apakah cache perlu disimpan sebagai bukti dan bagaimana lingkungan pemulihan akan mendapatkan dependensi yang telah dipilih. Catat keputusan itu. Kebiasaan menghapus segala sesuatu tanpa catatan dapat membuat tim kehilangan kesempatan menjelaskan versi yang dipakai. Kebiasaan memakai ulang semua cache tanpa pertimbangan pun dapat membuat proses pemulihan sulit dipertanggungjawabkan.

Skenario hipotetis: pengembang menghapus node_modules, menjalankan build lagi, lalu menyampaikan masalah selesai. Pemilik insiden perlu meminta bukti tambahan: apakah versi yang digunakan telah berubah, apakah job berjalan di lingkungan bersih, dan apakah kredensial terkait sudah ditangani? Rekomendasi editorial ini tidak menuntut pengembang mengetahui semua jawaban sendirian. Ia justru membantu membagi pekerjaan sehingga tindakan teknis kecil tidak disalahartikan sebagai penyelesaian seluruh risiko.

11. Pisahkan laptop, runner CI, dan server produksi

GitHub menjelaskan bahwa runner yang dikompromikan dapat menimbulkan risiko terhadap GITHUB_TOKEN serta secret yang dirujuk workflow. GitHub juga menyatakan penyamaran secret dalam log bukan batas keamanan yang sesungguhnya. Rujukan: GitHub Docs (diakses 2026/10), Compromised runners.

Saran kami adalah membuat daftar lingkungan, bukan satu label proyek aman atau proyek terinfeksi. Laptop pengembang, runner hosted, runner yang dikelola sendiri, server staging, dan server produksi perlu dinilai berdasarkan bukti masing-masing. Catat apakah suatu lingkungan menjalankan instalasi, menjalankan build, menerima artefak, atau hanya menyajikan berkas. Dengan begitu, keputusan pemulihan dapat diarahkan pada fungsi lingkungan tanpa memperluas klaim di luar bukti.

Untuk laptop hipotetis yang pernah menjalankan paket tersangka, hentikan pekerjaan sensitif pada perangkat itu dan libatkan pengelola perangkat bila ada. Saran kami adalah memakai perangkat lain yang dipercaya untuk administrasi akun dan rotasi kredensial. Jangan mengetik kredensial baru pada lingkungan yang statusnya masih belum jelas. Jika organisasi memilih instalasi ulang perangkat, dokumentasikan pemilihan itu sebagai tindakan pemulihan, lalu pulihkan proyek dari sumber dan dependensi yang telah ditinjau.

Untuk runner yang dipakai bersama, rekomendasi editorialnya adalah menghentikan pemakaian ulang lingkungan tersangka sampai penilaian dilakukan. Petakan job lain yang menggunakan runner tersebut dalam rentang waktu relevan. Untuk server produksi yang hanya menerima artefak, periksa jalur distribusi dan artefak yang disajikan. Jangan secara otomatis menyatakan server aman karena tidak menjalankan npm; jangan pula langsung menyatakan semua akun server dicuri tanpa bukti. Bedakan paparan kode, paparan kredensial, dan penerimaan artefak.

12. Rotasi secret dengan urutan yang membantu layanan pulih

npm menyediakan prosedur pencabutan access token melalui antarmuka akun maupun perintah yang dijelaskan dokumentasinya. Rujukan: npm Docs (diakses 2026/10), Revoking access tokens.

Saran kami adalah menyusun inventaris kredensial yang mungkin tersedia pada lingkungan terkait. Inventaris tersebut dapat meliputi token registry, akses repository, kunci deploy, akses cloud, dan kredensial layanan yang digunakan job. Jangan memasukkan nilai kredensial ke tabel. Catat pemilik, layanan, tingkat izin, lingkungan pemakaian, status pencabutan, serta pengganti yang diperlukan. Dengan cara ini, pembahasan tetap konkret tanpa menyebarkan secret yang sedang berusaha dilindungi.

Pencabutan dan pembuatan pengganti perlu dikoordinasikan. Dalam skenario hipotetis sebuah tim hosting kecil, token deploy yang dicabut dapat menghentikan rilis otomatis. Saran kami adalah memahami ketergantungan tersebut sebelum tindakan, sambil tetap memberi prioritas pada pembatasan akses yang berisiko. Tentukan pihak yang mencabut, pihak yang memasang pengganti, dan pihak yang menguji hasilnya. Jangan membiarkan token lama tetap aktif hanya karena belum ada pemilik pekerjaan penggantian.

Gunakan lingkungan bersih untuk administrasi kredensial dan verifikasi pengganti. Saran kami adalah meninjau kembali izin saat membuat pengganti, bukan menyalin seluruh kewenangan token lama. Tanyakan apakah akses tulis diperlukan, apakah cakupan repository dapat dipersempit, dan apakah penggunaan kredensial tetap harus berada pada tahap yang sama. Insiden dapat menjadi kesempatan memperbaiki rancangan akses tanpa mengubahnya menjadi proyek besar yang menunda pemulihan layanan.

Untuk secret yang tidak memiliki bukti pencurian tetapi tersedia pada lingkungan yang menjalankan kode berbahaya, tulis alasan tindakan rotasi secara jujur. Contohnya, rotasi dilakukan untuk mengurangi risiko karena akses mungkin tersedia dan bukti belum cukup untuk memastikan pemakaian. Kalimat tersebut berbeda dari secret dipastikan dicuri. Saran kami adalah menjaga perbedaan ini pada laporan internal dan komunikasi pelanggan agar pembaca memahami tindakan mitigasi serta batas pengetahuan tim.

13. Bangun kembali dari keputusan versi yang terdokumentasi

Dokumentasi npm menyatakan npm ci memerlukan lockfile yang sesuai, gagal ketika manifest dan lockfile tidak cocok, menghapus node_modules yang sudah ada, serta tidak menulis ulang manifest maupun lockfile. Rujukan: npm Docs (diakses 2026/10), npm ci.

Saran kami adalah memakai proses pemulihan yang dapat diulang setelah menentukan sumber dan versi yang dipercaya. Jangan memilih versi aman hanya berdasarkan asumsi lebih lama pasti aman atau paling baru pasti aman. Gunakan keterangan advisory serta komunikasi maintainer yang relevan, kemudian dokumentasikan dasar pemilihan. Bila sumber tidak menyediakan kesimpulan yang cukup jelas, jangan menyisipkan label aman di laporan. Gunakan ungkapan versi yang dipilih untuk pemulihan berdasarkan bukti yang tersedia.

Proses build pemulihan hipotetis sebaiknya mempunyai catatan commit, lockfile, versi alat, definisi job, dan artefak hasilnya. Saran kami adalah memisahkan pembuatan artefak dari penerbitan ke produksi. Tim dapat meninjau hasil lebih dulu, menjalankan pengujian relevan, dan menyiapkan rencana kembali ke keadaan sebelumnya bila terdapat regresi fungsional. Perubahan keamanan tidak harus mengorbankan keterlacakan rilis.

Jangan memakai berkas hasil build lama hanya karena source telah diperbaiki. Saran kami adalah menghasilkan ulang artefak yang relevan dari lingkungan dan dependensi yang dipilih, lalu memastikan proses deploy memang menggunakan keluaran tersebut. Catat apakah ada cache distribusi atau lokasi berkas lain yang perlu diperbarui. Pertanyaan editorial yang berguna adalah: ketika pengguna membuka website setelah pemulihan, dari mana JavaScript yang mereka terima berasal?

14. Buat review dependensi menjadi bagian dari review perubahan

GitHub menjelaskan bahwa dependency review membantu melihat dependensi yang ditambahkan, dihapus, atau diperbarui pada pull request, termasuk perubahan dependensi tidak langsung di lockfile dan informasi kerentanan yang diketahui. Rujukan: GitHub Docs (diakses 2026/10), Dependency review.

Saran kami adalah memasukkan perubahan dependensi dalam percakapan review yang sama dengan perubahan aplikasi. Reviewer dapat menanyakan manfaat paket, alternatif yang sudah tersedia, alasan versi dipilih, serta kebutuhan eksekusi skrip. Tidak semua utilitas memerlukan rapat panjang. Yang dibutuhkan adalah keputusan yang proporsional terhadap perubahan. Paket kecil dengan fungsi sederhana dapat ditinjau berbeda dari alat yang mengubah seluruh proses build atau mempunyai kewenangan publikasi.

Untuk tim yang sering menerima hasil generasi AI, rekomendasi editorialnya adalah memperlakukan nama paket yang disarankan sebagai kandidat. Verifikasi nama, dokumentasi, sumber, dan kecocokannya sebelum memasang. Jangan menganggap dependensi ada dan terpercaya hanya karena kode contoh tampak rapi. Jika fungsi yang dibutuhkan dapat dibuat dengan fasilitas yang sudah tersedia pada proyek, pertimbangkan pilihan itu dan catat alasannya. Rekomendasi ini bertujuan mengurangi keputusan pemasangan yang tidak diperiksa, bukan menyatakan semua saran AI berbahaya.

Buat template review ringkas yang mengumpulkan alasan perubahan, paket langsung baru, perubahan transitif yang menonjol, skrip yang diperlukan, dan cara pengujian. Saran kami adalah menjaga template cukup pendek agar benar-benar dipakai. Template yang terlalu panjang bisa berubah menjadi isian formal tanpa perhatian. Ukur manfaatnya melalui kualitas keputusan dan kemampuan menelusuri perubahan, bukan jumlah kotak yang diberi centang.

15. Kurangi izin pipeline sebelum membutuhkan respons insiden

GitHub merekomendasikan izin minimum untuk GITHUB_TOKEN dan menjelaskan bahwa kompromi action dalam workflow dapat berdampak besar. Panduan resminya juga membahas pinning action ke commit SHA penuh serta pengelolaan secret. Rujukan: GitHub Docs (diakses 2026/10), Secure use reference.

Saran kami adalah memisahkan job yang hanya memeriksa kode dari job yang dapat menerbitkan paket atau melakukan deploy. Jangan memberikan kredensial produksi ke seluruh tahap demi kemudahan konfigurasi. Tulis matriks sederhana yang menunjukkan tahap, data yang dibutuhkan, dan izin yang diberikan. Ketika seorang reviewer melihat sebuah job pengujian mempunyai akses publikasi, ia seharusnya dapat bertanya mengapa dan mendapatkan alasan yang terdokumentasi.

Rekomendasi editorial lainnya adalah meninjau alur perubahan workflow dengan perhatian yang sama seperti perubahan aplikasi. Sebuah permintaan kecil yang mengubah asal action, menambah secret, atau mengganti tahap publikasi dapat mengubah batas kepercayaan. Reviewer perlu melihat hasil akhir konfigurasi, bukan hanya nama file yang tampak teknis. Berikan pemilik jelas untuk perubahan tersebut agar keputusan tidak tersebar antara pengembang, pengelola hosting, dan admin akun tanpa koordinasi.

16. OIDC dan provenance membantu, dengan fungsi yang berbeda

GitHub mendokumentasikan OIDC sebagai mekanisme yang memungkinkan workflow memperoleh kredensial berumur pendek dari penyedia yang mendukungnya, melalui hubungan kepercayaan yang dikonfigurasi. Rujukan: GitHub Docs (diakses 2026/10), OpenID Connect. npm mendokumentasikan trusted publishing berbasis OIDC untuk publikasi paket dan menekankan penggunaan kredensial singkat yang dibatasi cakupannya. Rujukan: npm Docs (diakses 2026/10), Trusted publishing.

Saran kami adalah menilai OIDC untuk tahap publikasi yang memenuhi prasyarat platform. Petakan siapa yang boleh memicu workflow, repository yang dipercaya, dan batas izin yang diberikan penyedia tujuan. Jangan menganggap perubahan metode autentikasi menyelesaikan seluruh masalah. Pemilik sistem tetap perlu meninjau source yang dijalankan dan persetujuan rilis. Pilih konfigurasi yang sesuai dokumentasi platform pada saat implementasi karena dukungan penyedia dan persyaratan dapat berubah.

npm secara eksplisit menyatakan bahwa provenance tidak menjamin paket bebas kode berbahaya. Fungsinya menyediakan hubungan yang dapat diverifikasi ke source dan instruksi build agar pengguna dapat menilai kepercayaannya. Rujukan: npm Docs (diakses 2026/10), Generating provenance statements.

Saran kami adalah membaca provenance sebagai bukti asal, lalu menggabungkannya dengan review. Bayangkan sebuah paket hipotetis berasal dari workflow yang identitasnya dapat diverifikasi, tetapi perubahan source yang masuk tidak pernah ditinjau. Bukti asal tetap mempunyai nilai, namun belum menjawab apakah perubahan tersebut layak diterima. Sebaliknya, ketiadaan provenance bukan alasan otomatis menuduh paket sebagai malware. Jelaskan kedua keterbatasan tersebut agar fitur keamanan tidak berubah menjadi label pemasaran yang menyesatkan.

17. Komunikasikan temuan dengan batas yang jelas

Saran kami adalah membagi pembaruan insiden menjadi temuan, dampak yang diketahui, tindakan yang dilakukan, dan pekerjaan yang masih terbuka. Kalimat contoh yang baik: versi terkait ditemukan pada lockfile proyek A; eksekusi pada laptop B sedang diperiksa; job deploy dihentikan sementara; token tertentu sudah dicabut. Kalimat demikian menyampaikan kemajuan tanpa memaksakan kesimpulan sebelum bukti tersedia.

Untuk pemilik blog atau toko hipotetis, hindari istilah yang membuat semua risiko terlihat sama. Pembaca perlu memahami apakah masalah berhubungan dengan alat pembangunan website, kode yang diterima pengunjung, atau kredensial administrasi. Saran kami adalah menggunakan satu paragraf untuk masing-masing dampak yang memang didukung bukti. Jika belum ada bukti data pelanggan diakses, tulis belum ada bukti pada pemeriksaan yang telah dilakukan, bukan data pelanggan dipastikan aman selamanya.

Buat juga versi pembaruan untuk tim internal yang lebih teknis. Sertakan proyek, commit, job, waktu, dan rujukan advisory. Jangan menyalin secret atau detail akun ke pembaruan umum. Saran kami adalah menyimpan lampiran teknis sensitif terpisah dengan akses yang sesuai. Transparansi tentang proses tidak memerlukan pengungkapan semua konfigurasi. Tujuan komunikasi adalah membantu orang mengambil tindakan yang tepat sambil menjaga bukti dan informasi yang dilindungi.

18. Laporkan indikasi baru melalui kanal yang tepat

npm menyediakan kanal pelaporan malware dan meminta informasi seperti nama paket, versi terdampak, deskripsi, serta referensi yang membantu verifikasi. Dokumentasinya membedakan pelaporan malware dari pelaporan kerentanan yang sebaiknya dilakukan secara privat kepada maintainer sesuai kebijakan keamanan. Rujukan: npm Docs (diakses 2026/10), Reporting malware in an npm package.

Saran kami adalah membuat laporan yang berfokus pada bukti. Jelaskan apa yang diamati, di versi mana, dan bagaimana observasi tersebut diperoleh tanpa menjalankan sampel pada lingkungan kerja biasa. Bedakan perilaku mencurigakan dari hasil analisis yang telah mengonfirmasi malware. Jangan mempublikasikan tuduhan hanya berdasarkan nama paket aneh, ukuran berkas, atau kode yang sulit dibaca. Petunjuk awal bermanfaat, tetapi statusnya tetap petunjuk sampai ada verifikasi yang memadai.

Jika tim menemukan indikator yang juga terdapat pada proyek lain, koordinasikan pemeriksaan melalui pihak berwenang di organisasi. Saran kami adalah tidak mengirim sampel, kredensial, atau data proyek ke banyak layanan tanpa mempertimbangkan kebijakan. Catat pihak yang menerima laporan dan waktu pengiriman agar tindak lanjut dapat dilacak. Untuk pembaca umum, tindakan paling berguna sering kali berupa menyimpan advisory, memeriksa proyek yang dimiliki, dan menyerahkan analisis lanjutan kepada tim yang sesuai.

19. Buat rutinitas yang sanggup dijalankan tim kecil

Rekomendasi editorial penutup bagian praktis ini adalah membuat kebiasaan yang berulang dengan beban wajar. Setiap perubahan dependensi harus mempunyai alasan. Setiap rilis harus bisa dihubungkan dengan source dan lockfile. Setiap kredensial harus mempunyai pemilik. Setiap berita insiden perlu dinilai berdasarkan nama, versi, waktu, dan jalur pemakaian. Empat kebiasaan tersebut lebih mudah dipertahankan daripada program besar yang hanya dilakukan setelah ada kabar buruk.

Untuk tim satu atau dua orang hipotetis, jadwalkan waktu singkat untuk meninjau pembaruan dependensi dan akses akun. Simpan catatan di tempat yang mudah ditemukan saat terjadi masalah. Tentukan siapa yang dapat membantu ketika pemilik utama sedang tidak tersedia. Saran kami adalah menguji pemulihan pada proyek percobaan yang tidak memuat secret produksi. Latihan dapat memakai skenario paket yang harus diganti tanpa membuat atau menjalankan malware. Fokus latihan adalah komunikasi, bukti, dan keterlacakan rilis.

Untuk organisasi lebih besar, lakukan pembagian peran yang jelas antara pemilik aplikasi, pengelola infrastruktur, pengelola identitas, dan penanggung jawab keamanan. Saran kami adalah menetapkan titik koordinasi sehingga daftar proyek, status rotasi, dan status deploy tidak disimpan dalam percakapan terpisah yang saling bertentangan. Tetapkan kriteria penutupan: versi sudah diputuskan dan diverifikasi, artefak relevan sudah dibangun kembali, kredensial terkait sudah ditangani, serta ketidakpastian yang tersisa telah dicatat.

Daftar malware tahun 2026 seharusnya menjadi pintu masuk untuk keputusan yang lebih baik, bukan daftar nama yang menakutkan. Setelah membaca daftar, pembaca perlu dapat mengatakan paket mana yang relevan dengan proyeknya, bukti apa yang sudah diperiksa, tindakan apa yang sedang dilakukan, dan mengapa tindakan tersebut dipilih. Ketepatan bahasa serta disiplin terhadap bukti membantu menjaga kepercayaan. Pemulihan yang baik tidak berhenti pada pesan build sukses; ia menghasilkan keadaan baru yang dapat dijelaskan, diuji, dan ditelusuri.

Keterbatasan riset dan pembaruan artikel

Riset ini memeriksa sumber yang tersedia sampai 12 Oktober 2026 WIB. Daftar merupakan pilihan insiden yang berhasil diverifikasi, bukan sensus seluruh npm, seluruh CDN JavaScript, atau seluruh paket berbahaya yang pernah diterbitkan. Bulan tanpa entri tidak dapat diartikan sebagai bulan tanpa malware. Daftar historis juga tidak menyatakan status keamanan versi terbaru pada hari pembaca membuka artikel.

Beberapa laporan menyediakan tabel versi dinamis yang tidak ikut terambil. Untuk kasus tersebut, artikel hanya menampilkan versi yang tercantum dalam teks atau ringkasan sumber yang berhasil diverifikasi. Tidak dibuat rentang versi perkiraan. Angka paket, versi, artefak, unduhan, dan perangkat tidak dijumlahkan karena unit serta cakupannya berbeda. Laporan awal dapat berubah setelah investigasi lebih lanjut.

Sumber penelitian primer, pernyataan vendor, dan dokumentasi teknis dipisahkan dalam daftar sumber. Seluruh contoh organisasi dan proses kerja dalam panduan merupakan skenario hipotetis. Rekomendasi editorial bukan temuan forensik tentang korban tertentu. Gambar AI hanya ilustrasi. Artikel tidak menyertakan sampel malware, payload yang bisa dieksekusi, atau tautan unduh ke infrastruktur penyerang.

Bacaan dan alat terkait di Tumbas.in

Jelajahi tulisan lain melalui Explore Tumbas.in. Untuk kebutuhan pengelolaan tautan publik, kunjungi alat pemendek tautan dan pembuat QR Code. Tautan internal ini disertakan sebagai navigasi tambahan; alat tersebut bukan pemindai malware atau sarana pemulihan insiden.

Daftar sumber

Sumber berikut dibaca langsung atau diperiksa dalam riset. Tanggal dalam label merupakan bulan publikasi; dokumentasi tanpa tanggal menggunakan waktu akses. Nama tim merupakan afiliasi organisasi sumber.

• [Socket Axios (2026/03)] Socket Research Team, peneliti keamanan Socket. "Socket Axios". https://socket.dev/blog/axios-npm-package-compromised
• [Aikido Keyv (2026/08)] Ilyas Makari, Aikido. "Aikido Keyv". https://www.aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack
• [JFrog AsyncAPI (2026/07)] Guy Korolevski, JFrog Security Research. "JFrog AsyncAPI". https://research.jfrog.com/post/miasma-worm-returns-to-npm/
• [Zscaler NodeCordRAT (2026/01)] Satyam Singh dan Lakhan Parashar, Zscaler ThreatLabz. "Zscaler NodeCordRAT". https://www.zscaler.com/blogs/security-research/malicious-npm-packages-deliver-nodecordrat
• [Elastic ChainDrop (2026/08)] Elastic Security Labs. "Elastic ChainDrop". https://www.elastic.co/security-labs/threat-command/shai-hulud-chaindrop-npm-supply-chain
• [Microsoft Typosquat (2026/05)] Microsoft Threat Intelligence, Microsoft. "Microsoft Typosquat". https://www.microsoft.com/en-us/security/blog/2026/05/28/typosquatted-npm-packages-used-steal-cloud-ci-cd-secrets/
• [Microsoft Dependency Confusion (2026/05)] Microsoft Threat Intelligence, Microsoft. "Microsoft Dependency Confusion". https://www.microsoft.com/en-us/security/blog/2026/05/29/33-malicious-npm-packages-abuse-dependency-confusion-profile-developer-environments/
• [Sonatype Flooding Dropper (2026/08)] Sonatype Research Team, Sonatype. "Sonatype Flooding Dropper". https://www.sonatype.com/blog/flooding-dropper-hits-npm-with-850-malicious-packages
• [StepSecurity jscrambler (2026/07)] Rohan Prabhu, StepSecurity. "StepSecurity jscrambler". https://www.stepsecurity.io/blog/jscrambler-npm-package-publishes-malicious-preinstall-binary
• [Socket Bitwarden (2026/04)] Socket Research Team, peneliti keamanan Socket. "Socket Bitwarden". https://socket.dev/blog/bitwarden-cli-compromised
• [Socket Tensorlake (2026/10)] Socket Research Team, peneliti keamanan Socket. "Socket Tensorlake". https://socket.dev/blog/tensorlake-compromise
• [Socket-dYdX (2026/02), Compromised Versions dan npm Package] Kush Pandya, Socket Threat Research. "Socket-dYdX". https://socket.dev/blog/malicious-dydx-packages-published-to-npm-and-pypi
• [Socket-CanisterWorm (2026/03), Overview dan IOC] Socket Research Team, peneliti keamanan Socket. "Socket-CanisterWorm". https://socket.dev/blog/canisterworm-npm-publisher-compromise-deploys-backdoor-across-29-packages
• [Socket-CanisterSprawl (2026/04), Overview] Socket Research Team, peneliti keamanan Socket. "Socket-CanisterSprawl". https://socket.dev/blog/namastex-npm-packages-compromised-canisterworm
• [Socket-SAP (2026/04), Overview] Socket Research Team, peneliti keamanan Socket. "Socket-SAP". https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
• [Socket-Intercom (2026/04), Overview] Socket Research Team, peneliti keamanan Socket. "Socket-Intercom". https://socket.dev/blog/intercom-s-npm-package-compromised-in-supply-chain-attack
• [Socket-node-ipc (2026/05), Overview] Socket Research Team, peneliti keamanan Socket. "Socket-node-ipc". https://socket.dev/blog/node-ipc-package-compromised
• [Socket-art-template (2026/05), Repository Takeover dan npm Entry Point] Joseph Edwards, Socket Threat Research. "Socket-art-template". https://socket.dev/blog/coruna-respawned-compromised-art-template-npm-package
• [Socket-Mastra (2026/06), How Delivered] Socket Research Team, peneliti keamanan Socket. "Socket-Mastra". https://socket.dev/blog/mastra-npm-packages-compromised
• [Socket-Joyfill (2026/07), Affected Packages/Impact] Socket Research Team, peneliti keamanan Socket. "Socket-Joyfill". https://socket.dev/blog/joyfill-npm-beta-releases-compromised
• [Socket-OpenAPI (2026/08), Affected Versions] Socket Research Team, peneliti keamanan Socket. "Socket-OpenAPI". https://socket.dev/blog/openapi-react-query-codegen-npm-compromise
• [Socket-MemTensor (2026/09), Overview dan Guidance] Karlo Zanki, Socket Threat Research. "Socket-MemTensor". https://socket.dev/blog/memtensor-compromise
• [TanStack Postmortem (2026/05)] Tanner Linsley, TanStack. "TanStack Postmortem". https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
• [Socket AntV (2026/05)] Socket Research Team, peneliti keamanan Socket. "Socket AntV". https://socket.dev/blog/antv-packages-compromised
• [Red Hat RHSB-2026-006 (2026/06, pembaruan dibaca 2026/10)] Red Hat Product Security. "Red Hat RHSB-2026-006". https://access.redhat.com/security/vulnerabilities/RHSB-2026-006
• [npm Docs (diakses 2026/10), npm ls] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/commands/npm-ls/
• [npm Docs (diakses 2026/10), npm explain] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/commands/npm-explain/
• [npm Docs (diakses 2026/10), package-lock.json] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json/
• [npm Docs (diakses 2026/10), npm view] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/commands/npm-view/
• [npm Docs (diakses 2026/10), npm audit] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/commands/npm-audit/
• [npm Docs (diakses 2026/10), Scripts] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/using-npm/scripts/
• [Node.js (diakses 2026/10), Security Best Practices] Node.js, dokumentasi resmi. "Node.js". https://nodejs.org/en/learn/getting-started/security-best-practices
• [npm Docs (diakses 2026/10), npm cache] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/commands/npm-cache/
• [GitHub Docs (diakses 2026/10), Compromised runners] GitHub, dokumentasi resmi. "GitHub Docs". https://docs.github.com/en/actions/concepts/security/compromised-runners
• [npm Docs (diakses 2026/10), Revoking access tokens] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/revoking-access-tokens/
• [npm Docs (diakses 2026/10), npm ci] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/cli/v11/commands/npm-ci/
• [GitHub Docs (diakses 2026/10), Dependency review] GitHub, dokumentasi resmi. "GitHub Docs". https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review
• [GitHub Docs (diakses 2026/10), Secure use reference] GitHub, dokumentasi resmi. "GitHub Docs". https://docs.github.com/en/actions/reference/security/secure-use
• [GitHub Docs (diakses 2026/10), OpenID Connect] GitHub, dokumentasi resmi. "GitHub Docs". https://docs.github.com/en/actions/concepts/security/openid-connect
• [npm Docs (diakses 2026/10), Trusted publishing] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/trusted-publishers/
• [npm Docs (diakses 2026/10), Generating provenance statements] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/generating-provenance-statements/
• [npm Docs (diakses 2026/10), Reporting malware in an npm package] npm, dokumentasi resmi. "npm Docs". https://docs.npmjs.com/reporting-malware-in-an-npm-package/