Dependensi Tidak Boleh Dibiarkan Tumbuh Sendiri: Cara Menjaga Proyek Tetap Aman

Banyak proyek software tidak dibangun dari nol. Aplikasi web, layanan internal, bahkan skrip kecil biasanya memakai puluhan hingga ribuan komponen pihak ketiga—mulai dari library untuk login, pemrosesan gambar, koneksi database, sampai alat pengujian.

Masalahnya, dependensi bukan sekadar potongan kode yang tinggal dipasang. Setiap paket membawa versi, dependensi lain, lisensi, dan kemungkinan celah keamanan. Ketika salah satu komponen berubah tanpa pemeriksaan yang baik, aplikasi bisa gagal dibangun, perilakunya berubah, atau membuka risiko baru.

Kabar baiknya, pengelolaan dependensi tidak harus rumit. Beberapa kebiasaan sederhana dapat membuat proyek lebih mudah dipahami dan lebih aman dirawat.

Dependensi langsung dan tidak langsung

Dependensi langsung adalah paket yang sengaja Anda tambahkan ke proyek. Misalnya, aplikasi Node.js memasang Express untuk membuat server web.

Sementara itu, dependensi tidak langsung adalah paket yang dipakai oleh dependensi lain. Anda mungkin hanya menambahkan satu library, tetapi library tersebut bisa membawa beberapa paket tambahan. Rantai inilah yang sering membuat perubahan terasa mengejutkan.

Contohnya, Anda memperbarui satu library untuk mendapatkan fitur baru. Di balik pembaruan itu, versi parser, utility, atau modul jaringan juga ikut berubah. Aplikasi masih terlihat sama dari luar, tetapi kode yang dijalankan sebenarnya tidak lagi identik dengan versi sebelumnya.

Lockfile bukan file sampah

File seperti package-lock.json, yarn.lock, atau pnpm-lock.yaml sering dianggap sebagai berkas teknis yang bisa diabaikan. Padahal, lockfile mencatat versi pasti dan struktur dependensi yang digunakan proyek.

Dokumentasi npm menjelaskan bahwa package-lock.json membantu memastikan rekan satu tim, server deployment, dan pipeline CI memasang pohon dependensi yang sama. Tanpa lockfile, dua orang dapat menjalankan npm install pada waktu berbeda dan memperoleh kombinasi versi yang tidak persis sama.

Karena itu, lockfile sebaiknya disimpan di repository. Jangan menghapusnya hanya karena ukurannya besar atau isinya terlihat sulit dibaca. Ia berfungsi seperti daftar belanja yang sangat rinci: bukan hanya menyebut “beli tepung”, tetapi juga merekam merek dan ukuran yang benar-benar dipakai.

Gunakan perintah instalasi yang sesuai

Dalam pipeline CI atau deployment, gunakan perintah yang menghormati isi lockfile, misalnya:

npm ci

Untuk memperbarui metadata lockfile tanpa memasang seluruh isi node_modules, npm juga menyediakan:

npm install --package-lock-only

Perintah tersebut tetap perlu digunakan dengan hati-hati. Jangan menganggap semua pembaruan aman hanya karena proses instalasinya berhasil.

Bedakan pembaruan keamanan dan pembaruan fitur

Tidak semua update harus diperlakukan sama. Pembaruan patch mungkin berisi perbaikan bug, sedangkan pembaruan minor atau major dapat membawa perubahan perilaku dan kompatibilitas.

Untuk proyek penting, buat jalur pembaruan yang jelas:

• Pembaruan keamanan: diprioritaskan setelah dampaknya dipahami.
• Pembaruan rutin: dijadwalkan, misalnya setiap minggu atau dua minggu.
• Pembaruan major: dilakukan sebagai pekerjaan terencana dengan pengujian dan catatan perubahan.

Kesalahan umum adalah menunggu terlalu lama, lalu melakukan pembaruan besar-besaran dalam satu pull request. Cara ini membuat tim kesulitan mengetahui paket mana yang menyebabkan masalah. Perubahan kecil yang sering diperiksa biasanya lebih mudah dipulihkan.

Periksa perubahan sebelum kode digabungkan

Review kode tidak cukup jika perhatian hanya diarahkan pada file aplikasi. Perubahan di package.json atau lockfile juga perlu dibaca.

Perhatikan beberapa hal berikut:

• Apakah ada paket baru yang tidak dikenal oleh tim?
• Apakah versi paket berubah jauh lebih besar dari yang diperkirakan?
• Apakah dependensi produksi bertambah padahal fitur hanya untuk pengembangan?
• Apakah sumber paket berubah atau menggunakan registry yang tidak biasa?
• Apakah lisensinya sesuai dengan kebutuhan proyek?

GitHub menyediakan fitur dependency review yang dapat menunjukkan dependensi yang ditambah, dihapus, atau diperbarui dalam sebuah pull request, termasuk informasi kerentanan yang diketahui. Fitur ini juga dapat dipasang sebagai pemeriksaan otomatis melalui Dependency Review Action.

Contoh workflow sederhananya:

name: Dependency Review

on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/dependency-review-action@v4

Konfigurasi tersebut bukan pengganti review manusia. Ia lebih mirip pagar otomatis yang membantu menangkap masalah umum sebelum perubahan digabungkan.

Inventaris komponen membantu saat terjadi insiden

Ketika sebuah library dinyatakan memiliki celah keamanan, pertanyaan pertama biasanya sederhana: “Apakah kita memakainya?” Tanpa inventaris yang rapi, jawabannya bisa membutuhkan pencarian manual di banyak repository dan server.

Di sinilah konsep Software Bill of Materials atau SBOM berguna. CISA mendeskripsikan SBOM sebagai catatan formal mengenai komponen dan hubungan dependensi yang membentuk sebuah software. Sederhananya, SBOM adalah daftar bahan penyusun aplikasi.

SBOM tidak otomatis membuat software aman. Namun, ia mempercepat proses pemetaan dampak. Tim dapat melihat versi komponen yang digunakan, lokasi pemakaiannya, dan produk mana yang perlu diperbarui ketika ada masalah.

Apa artinya bagi kita?

Untuk proyek pribadi, Anda mungkin belum perlu membangun sistem SBOM yang kompleks. Tetapi kebiasaan dasarnya tetap relevan:

1. Simpan lockfile di repository.
2. Gunakan versi runtime dan package manager yang konsisten.
3. Jalankan audit dependensi secara berkala.
4. Periksa perubahan pada lockfile dalam setiap pull request.
5. Hapus dependensi yang sudah tidak digunakan.
6. Jangan memasang paket hanya karena namanya terlihat mirip dengan paket populer.

Untuk tim, tambahkan pengujian otomatis, aturan minimal review, dan pemantauan dependensi. Tool seperti Dependabot dapat membuat pull request pembaruan, tetapi keputusan untuk menggabungkan perubahan tetap sebaiknya mempertimbangkan pengujian aplikasi dan konteks bisnis.

Yang bisa dilakukan sekarang

Mulailah dari proyek yang paling sering di-deploy. Pastikan lockfile sudah dilacak Git, jalankan pemeriksaan dependensi, lalu lihat lima perubahan dependensi terakhir. Apakah tim tahu mengapa setiap paket diperbarui? Apakah ada paket lama yang tidak lagi digunakan?

Tujuannya bukan menghindari semua dependensi pihak ketiga. Library open source dan ekosistem package manager justru membuat software bisa dikembangkan lebih cepat. Tujuannya adalah memastikan setiap komponen yang masuk ke proyek dapat dilihat, diuji, dan diperbarui dengan alasan yang jelas.

Fakta: lockfile, dependency review, dan SBOM membantu meningkatkan visibilitas terhadap komponen software. Analisis: manfaat terbesar dari praktik tersebut bukan hanya mencegah celah keamanan, tetapi juga mengurangi waktu yang terbuang ketika build tiba-tiba berbeda atau sebuah library bermasalah.

Sumber & bacaan lebih lanjut

• npm Docs: package-lock.json
• npm Docs: npm install
• GitHub Docs: Dependency review
• GitHub Docs: Configuring the dependency review action
• CISA: SBOM FAQ

– Rio Yotto @rioyotto