Satu Huruf Salah, CI Kamu Bisa Install Malware

Kamu mengetik cross-env, tapi yang masuk malah paket mirip dengan satu huruf beda. Review lewat sekilas, lockfile berubah, CI hijau, lalu kredensial build mulai bocor. Serangan seperti ini bukan teori jauh. Typosquatting detection membantu menangkap nama package npm atau Packagist yang kelihatan sah, padahal sengaja dibuat mirip sebelum sempat di-install.

Jawaban Singkat / Key Takeaways

Typosquatting detection membandingkan nama dependency baru dengan package populer, package internal, dan allowlist timmu. Jadi, CI bisa memblokir paket lookalike sebelum npm install atau composer install menjalankan kode asing.

• Fokus utama: nama package baru, bukan cuma CVE.
• Tempat terbaik: PR, pre-merge CI, dan dependency bot review.
• Rule paling efektif: gabungkan similarity score, registry trust, maintainer signal, dan konteks repo.

Kenapa Typosquatting di npm dan Packagist Berbahaya?

Typosquatting terjadi saat attacker menerbitkan package dengan nama yang mirip package asli. Misalnya typo kecil, huruf tertukar, tambahan dash, namespace palsu, atau transliterasi karakter yang susah dibedakan.

Masalahnya, package manager memperlakukan nama itu sebagai paket sah. Kalau package tersebut punya install script, dependency tambahan, atau payload tersembunyi, damage bisa muncul sebelum aplikasimu jalan.

Karena itu, typosquatting detection npm Packagist harus masuk ke alur review dependency. Terutama untuk tim yang sering menerima PR eksternal, memakai Renovate atau Dependabot, atau mengelola banyak repo.

Pola Nama yang Harus Kamu Curigai

1. Edit Distance Kecil

Nama baru yang hanya beda 1 sampai 2 karakter dari package populer wajib masuk antrean review. Contohnya typo huruf, huruf hilang, atau susunan huruf tertukar.

2. Namespace yang Menipu

Di npm, scope seperti @org/pkg sering memberi rasa aman palsu. Di Composer, vendor name juga bisa dimanfaatkan. Jadi, jangan cuma cek nama package, cek juga siapa pemilik namespace-nya.

3. Popularitas Tidak Seimbang

Paket baru dengan nama sangat mirip paket besar, tapi download rendah, maintainer baru, dan repo minim aktivitas, perlu diblokir dulu. Selain itu, cek apakah package itu tiba-tiba muncul setelah issue, blog, atau CVE ramai dibahas.

Framework Praktis: NAME-GATE Sebelum Install

Banyak tim memasang scanner setelah dependency masuk. Itu terlambat. Cara lebih aman adalah membuat gerbang nama sebelum install berjalan.

• N, Normalize: ubah nama ke bentuk standar, lower-case, buang noise, cek homoglyph.
• A, Allowlist: cocokkan dengan daftar package resmi, internal, dan approved vendor.
• M, Match: hitung kemiripan dengan package populer dan package yang sudah dipakai repo.
• E, Evidence: cek repo source, maintainer, umur package, publish history, dan download trend.
• GATE: blokir otomatis jika skor risiko tinggi, minta approval security jika abu-abu.

Bagian yang sering dilupakan: bandingkan package baru dengan dependency historis repo-mu, bukan cuma daftar package populer global. Sebab attacker biasanya menargetkan kebiasaan internal tim, bukan seluruh internet.

Contoh Rule CI untuk npm dan Composer

Kamu bisa mulai sederhana. Ambil diff dari package.json, package-lock.json, composer.json, dan composer.lock. Lalu, hanya analisis package baru.

# npm
npm install --package-lock-only --ignore-scripts
npm audit signatures

# Composer
composer install --no-scripts --no-plugins --dry-run
composer audit

Perintah di atas bukan detektor typosquatting penuh, namun bagus sebagai baseline aman. Setelah itu, tambahkan script custom untuk memeriksa Levenshtein distance, Jaro-Winkler, atau daftar blocklist internal.

Untuk konteks supply chain yang lebih luas, kamu juga bisa membaca artikel terkait tentang dependency confusion defense, npm lifecycle scripts di CI, dan lockfile integrity npm Composer.

Sinyal Teknis yang Layak Jadi Blocker

• Nama mirip package populer dengan jarak edit sangat kecil.
• Package baru punya preinstall, install, atau postinstall.
• Repo source tidak jelas, kosong, atau berbeda dari metadata registry.
• Maintainer baru, email mencurigakan, atau publish history terlalu tipis.
• Package meminta dependency transitif yang aneh untuk fungsinya.
• Vendor Composer terlihat seperti tiruan vendor resmi.

Rujukan teknis yang bagus: dokumentasi npm, Composer, dan panduan SLSA supply chain security. Namun, jangan berhenti di checklist. Gabungkan sinyal teknis dengan konteks repo.

Workflow Review yang Ringan, Tapi Nendang

Atur policy seperti ini:

1. Dependency baru masuk PR.
2. CI menjalankan install tanpa script.
3. Bot menghitung similarity score nama package.
4. Jika aman, PR lanjut ke test.
5. Jika mencurigakan, reviewer harus memberi approval eksplisit.
6. Jika package masuk blocklist, PR gagal otomatis.

Dengan begitu, developer tetap cepat. Sementara itu, package aneh tidak langsung menyentuh runner, secret, atau build artifact.

FAQ Typosquatting Detection npm Packagist

Apa itu typosquatting detection?

Typosquatting detection adalah proses mendeteksi nama package yang mirip package sah. Tujuannya mencegah developer atau CI meng-install paket palsu karena typo atau nama yang menipu.

Apakah lockfile cukup untuk mencegah typosquatting?

Belum tentu. Lockfile mengunci versi setelah package masuk. Namun, kalau package palsu sudah telanjur ditambahkan ke lockfile, lockfile justru ikut menyimpan risiko itu.

Di mana deteksi paling ideal dijalankan?

Jalankan di PR dan pre-merge CI, sebelum install script aktif. Selain itu, aktifkan review manual untuk dependency baru yang mirip package populer atau package internal.

Penutup: Jangan Tunggu Malware Jalan Dulu

Typosquatting terasa sepele karena cuma soal nama. Namun, di npm dan Packagist, nama package adalah pintu masuk ke build system, runner CI, dan kadang secret. Jadi, pasang typosquatting detection sebelum install, bukan setelah incident.

Mau checklist keamanan dependency yang lebih praktis untuk tim dev dan CI owner? Subscribe newsletter Google lewat blok di bawah ini.