Dependency Security

Satu perintah npm install menambahkan kode yang ditulis orang asing ke dalam aplikasi toko Budi — pustaka format mata uang, komponen kalender, utilitas tanggal. Kode itu berjalan dengan hak yang sama seperti kode kita sendiri: di halaman pengguna, tanpa kotak pasir tambahan. Ketika sebuah celah ditemukan di dalam pustaka, celah itu menjadi celah aplikasi yang memasangnya, apa pun kualitas kode kita. Cara npm menyederhanakan pemasangan inilah yang membuat menjaga dependensi menjadi kebiasaan keamanan yang wajib.

Kabar baiknya, npm menyediakan hampir semua alat yang dibutuhkan — penentuan versi, rekaman lockfile, dan pemeriksaan basis data advisories. Chapter ini membedah masing-masing dan menutup dengan rutinitas pembaruan yang berjalan tanpa drama. Pembahasan npm yang lebih lengkap menyusul di section Tooling dan Code Quality; fokus kita di sini adalah sisi keamanannya.

Versi dalam package.json: Caret dan Pinned #

Dua anggota penting di package.json kita:

{
  "dependencies": {
    "format-angka": "^1.2.0",
    "keranjang-ui": "1.4.2"
  }
}

Versi mengikuti pola semantic versioning: MAJOR.MINOR.PATCH. Tanda caret (^) berarti “versi ini dan perbaikan di atasnya, tetapi jangan menaikkan major” — rentang yang lazim dipilih karena perbaikan celah biasanya datang sebagai patch atau minor:

Satu pengecualian yang patut diingat: pada versi 0.x, caret lebih ketat — ^0.2.3 berarti >= 0.2.3 dan < 0.3.0, karena pada fase 0.x kenaikan minor dianggap perubahan besar. Pilihan caret atau pinned sama-sama sah; yang tidak sah adalah tidak tahu rentang mana yang sedang dipakai aplikasi.

Lockfile: Rekaman yang Menjaga Konsistensi #

Rentang ^1.2.0 menyebut batasan, bukan versi persis — maka npm menuliskan versi yang benar-benar terpasang ke berkas package-lock.json, lengkap dengan integrity hash untuk memverifikasi isi package. Mekanismenya:

• npm install membaca lockfile lebih dulu. Bila berkas ada, npm memasang persis versi yang tercatat — dua mesin yang berbeda mendapatkan hasil yang sama.
• Tanpa lockfile, setiap pemasangan menyelesaikan ulang rentang. Hari ini ^1.2.0 bisa berarti 1.2.0, minggu depan 1.7.10 — perubahan yang tidak pernah kita putuskan sendiri.
• Lockfile ikut di-commit. Rekaman ini adalah bagian dari kode sumber: reviewer bisa melihat kenaikan versi di diff, dan tim bisa menelusuri versi persis yang berjalan saat insiden.

Untuk lingkungan seperti CI, npm ci memasang bersih sesuai lockfile dan menghentikan proses bila package.json tidak sinkron dengan rekamannya — pilihan yang lebih tegas daripada npm install.

Satu hal yang sering mengejutkan: package.json kita hanya mencantumkan dependensi langsung, tetapi setiap package membawa dependensinya sendiri, dan begitu seterusnya berlapis-lapis di node_modules. Rentang caret milik pustaka lain menyelesaikan versi pustaka yang belum pernah kita lihat namanya — dan itulah tempat banyak advisory ditemukan. Lockfile merekam seluruh pohon ini, sehingga npm audit bisa memeriksa bukan hanya pilihan kita, tetapi juga pilihan setiap pustaka yang kita pasang. Bila laporan menyebut package yang tidak kita kenal, npm ls <nama-package> menunjukkan rantai siapa-memakai-siapa sampai ke dependensi langsung kita.

npm audit: Pemeriksaan Rutin #

Dua perintah dasar yang kita jalankan di terminal. Versi npm di lingkungan kerja kita:

npm --version

Output yang Dihasilkan:

11.19.0

Perintah pemeriksaan membaca lockfile, membandingkan setiap versi terpasang dengan basis data advisories keamanan npm, lalu melaporkan hasilnya:

npm audit

Contoh keluaran (ilustrasi — isi laporan bergantung pada package dan versi terpasang):

# npm audit report

format-angka  1.0.0 - 1.0.4
Severity: moderate
format-angka memproses masukan tanpa batas

fix available via `npm audit fix`

1 moderate severity vulnerability

To address all issues, run:
  npm audit fix

Perintah perbaikan dan pendampingnya:

npm audit fix      # perbarui ke versi yang memperbaiki celah, tanpa menaikkan major
npm audit --json   # hasil pemeriksaan dalam bentuk JSON untuk alat otomatis
npm outdated       # daftar package yang tertinggal dari versi terbaru
npm ci             # pasang bersih persis sesuai package-lock.json

Mari kita bedah satu per satu:

1. Perintah 1 (npm --version): menampilkan versi npm yang terpasang. Keluaran di atas dicatat nyata di lingkungan kerja kita (Node v24.21.0).
2. Perintah 2 (npm audit): laporan berisi nama package, rentang versi yang terdampak, tingkat keparahan (severity), dan tautan advisory. Tingkat keparahan membantu menentukan urutan: critical dan high ditangani lebih dulu.
3. Perintah 3 (npm audit fix): npm menaikkan versi dalam batas rentang yang sudah disepakati package.json, lalu memperbarui lockfile. Tanpa --force, major tidak pernah naik — perubahan tetap berada di dalam kontrak versi.
4. Perintah 4–5 (--json dan npm outdated): bentuk JSON berguna bila pemeriksaan dijalankan alat otomatis; npm outdated memperlihatkan versi terpasang, versi yang diinginkan, dan versi terbaru berdampingan.
5. Perintah 6 (npm ci): memastikan mesin mana pun memasang persis rekaman lockfile — cara paling aman untuk menyalin keadaan yang sudah teruji.

Tingkat keparahan pada laporan membantu menentukan urutan kerja, tetapi konteksnya tetap perlu dibaca: advisory moderate pada package yang menyentuh semua halaman bisa lebih mendesak daripada high pada package yang hanya dipakai skrip build. Deskripsi dan tautan advisory di laporan menjelaskan kondisi pemicunya — versi mana yang terdampak, dan kode seperti apa yang memicunya — sehingga keputusan perbaikan menjadi terukur, bukan sekadar reaksi terhadap angka.

Rutinitas Pembaruan yang Berjalan #

Alat di atas hanya berguna bila dijalankan berkala. Rutinitas yang ringan dan cukup:

• Jadwal tetap — misalnya dua minggu sekali — jalankan npm audit dan npm outdated, bukan hanya saat teringat.
• Patch dan minor lebih dulu: risikonya rendah dan biasanya menutup celah. Kenaikan major dibaca changelog-nya dulu, diuji di cabang terpisah, baru digabung.
• Commit lockfile hasil setiap pembaruan bersama perubahan package.json, sebagai satu commit.
• Periksa kesehatan package baru sebelum memasangnya: tanggal rilis terakhir, aktif atau tidaknya perawatan, jumlah pengguna — package yang ditinggalkan pemiliknya jarang menerima perbaikan celah.
• Lepas dependensi yang tidak terpakai lewat npm uninstall; permukaan yang lebih kecil lebih mudah dijaga.
• Bagi pekerjaannya di tim: satu orang menjalankan pembaruan, semua orang meninjau diff lockfile-nya — kenaikan versi yang tidak disengaja langsung terlihat di review.

Dependensi yang terjaga menutup satu pintu masuk. Pintu berikutnya lebih sering luput: rahasia yang ikut tertulis di kode klien.