Lockfile Kamu Bohong Kalau CI Masih Pakai Install Biasa

Build lokal hijau, CI hijau, deploy jalan, lalu seminggu kemudian bug aneh muncul tanpa ada perubahan kode aplikasi. Kedengarannya mistis, padahal sering kali penyebabnya sederhana: dependency bergerak diam-diam karena lockfile tidak diperlakukan sebagai kontrak keamanan.

Untuk tim JavaScript, PHP, dan plugin WordPress, lockfile integrity npm Composer bukan sekadar urusan reproducible build. Ini pagar awal untuk mencegah silent dependency drift, update transitif berbahaya, dan perubahan package yang belum pernah kamu review.

Kenapa Lockfile Bisa Jadi Garis Pertahanan Supply Chain

package-lock.json, npm-shrinkwrap.json, dan composer.lock menyimpan versi final yang benar-benar dipasang. Namun, banyak tim masih memperlakukannya seperti file sampingan. Akibatnya, dependency bisa berubah walau package.json atau composer.json tampak aman.

Masalahnya makin besar saat kamu punya plugin WordPress dengan build asset npm, library PHP Composer, dan pipeline rilis otomatis. Satu transitive package yang naik versi bisa mengubah output bundle, menambah script install, atau menarik dependency baru yang belum kamu pahami.

Kesalahan Umum: CI yang “Terlalu Pintar”

Banyak pipeline rusak bukan karena kurang tool security, melainkan karena command install yang terlalu permisif. Misalnya, npm install di CI dapat memperbarui lockfile jika metadata berubah. Sementara itu, Composer bisa melakukan resolusi berbeda kalau lockfile hilang, tidak sinkron, atau flag platform diabaikan.

Gunakan pola ini sebagai baseline:

• npm: pakai npm ci, bukan npm install, untuk pipeline build dan test.
• Composer: pakai composer install --no-interaction --prefer-dist, bukan composer update, di CI.
• Repository: commit lockfile, lalu blokir merge jika lockfile berubah tanpa alasan jelas.
• Review: minta reviewer membaca perubahan dependency transitif, bukan cuma file source.

Framework 3 Lapis: Freeze, Explain, Rebuild

Cara paling efektif bukan “jangan update dependency”. Justru sebaliknya, update tetap rutin, tetapi jalurnya harus eksplisit. Pakai framework sederhana: Freeze, Explain, Rebuild.

1. Freeze: Jadikan Lockfile Kontrak

Lockfile harus menjadi sumber kebenaran untuk build. Kalau lockfile berubah, anggap itu perubahan aplikasi. Jadi, perubahan satu baris dependency punya bobot review yang sama seperti perubahan auth middleware atau query database.

npm ci
composer install --no-interaction --prefer-dist --no-progress

2. Explain: Paksa Setiap Perubahan Punya Alasan

Setiap PR yang menyentuh package-lock.json atau composer.lock perlu catatan singkat. Apa yang berubah? Kenapa perlu? Apakah ada package baru, maintainer baru, script install baru, atau versi major transitif?

Ini terdengar birokratis, tetapi sangat murah dibanding investigasi incident. Apalagi kalau timmu mengelola plugin WordPress yang dipasang di banyak website klien.

3. Rebuild: Verifikasi Output, Bukan Cuma Install

Bagian yang sering dilupakan: dependency yang sama harus menghasilkan artifact yang bisa dipercaya. Karena itu, setelah install, bandingkan output penting seperti bundle JS, vendor tree, checksum artifact, atau SBOM. Kalau hasil berubah tanpa perubahan source, pipeline harus memberi sinyal merah.

Checklist CI untuk npm dan Composer

• Fail build jika lockfile berubah setelah install.
• Fail build jika lockfile tidak sinkron dengan manifest.
• Blokir composer update dan npm install di job release.
• Audit package dengan npm audit dan composer audit.
• Gunakan registry policy, token scoped, dan 2FA untuk akun publish.
• Generate SBOM saat release, idealnya CycloneDX atau SPDX. Referensi format bisa kamu cek di CycloneDX.

Untuk Tim Plugin WordPress, Risikonya Lebih Nyata

Plugin WordPress modern sering punya dua dunia: PHP di backend dan npm untuk asset build. Karena itu, satu PR kecil bisa menyentuh Composer, npm, Webpack/Vite, dan ZIP release sekaligus. Tanpa lockfile integrity, kamu mungkin merilis paket yang berbeda dari yang reviewer lihat.

Kalau kamu sedang memperkuat supply chain plugin, baca juga panduan internal kami tentang risk scoring plugin WordPress, SBOM yang benar-benar dipakai, dan rollback cepat saat dependency terkontaminasi.

Aturan Praktis yang Bisa Kamu Terapkan Minggu Ini

Mulai dari yang paling kecil, lalu naikkan kontrolnya. Pertama, ubah command CI. Kedua, pasang guard yang memeriksa diff lockfile. Ketiga, buat template PR dependency update.

git diff --exit-code package-lock.json composer.lock

Command sederhana ini bisa menangkap install yang mengubah lockfile tanpa sengaja. Selain itu, kamu bisa menambahkan job khusus yang hanya berjalan saat lockfile berubah, lalu menampilkan daftar package baru, versi naik, dan advisory security.

FAQ

Apakah lockfile harus selalu di-commit?

Ya, untuk aplikasi, plugin, dan service yang kamu deploy. Lockfile membuat build lebih konsisten dan memudahkan review perubahan dependency.

Kapan boleh menjalankan composer update atau npm update?

Jalankan hanya di PR khusus dependency update, bukan di job release. Setelah itu, review perubahan lockfile, audit advisory, lalu rebuild artifact.

Apakah lockfile integrity cukup untuk menghentikan package berbahaya?

Belum cukup, tetapi sangat penting. Kamu tetap perlu audit, registry control, SBOM, review maintainer risk, dan monitoring artifact.

Penutup: Jangan Biarkan Dependency Mengambil Keputusan Sendiri

Lockfile integrity npm Composer memberi timmu satu hal yang sangat mahal dalam supply chain security: kepastian. Dengan versi yang terkunci, review yang eksplisit, dan CI yang disiplin, dependency tidak lagi berubah diam-diam di belakang layar.

Kalau kamu ingin checklist praktis soal security engineering, WordPress, dan CI yang aman, gabung newsletter Google kami lewat blok di bawah ini.