Strategi verifikasi dependensi perlu diperlakukan sebagai bagian dari workflow engineering, bukan sekadar kontrol tambahan dari tim keamanan. Kasus kompromi paket komunitas seperti di ekosistem AUR menunjukkan pola yang relevan untuk tim aplikasi/backend: perubahan pada sumber, skrip build, atau metadata paket bisa terlihat sah pada permukaan, tetapi membawa perilaku baru yang berbahaya atau setidaknya memicu regresi keamanan.

Masalah utamanya bukan hanya paket berbahaya, melainkan trust model yang terlalu longgar: update dependensi masuk ke branch, CI hanya menjalankan test fungsional, lalu perubahan dirilis tanpa verifikasi bahwa artefak, lockfile, install script, dan sumber unduhan masih sesuai ekspektasi. Solusinya adalah menambah guardrail di CI agar setiap perubahan dependensi diperlakukan sebagai perubahan berisiko yang harus lolos verifikasi teknis sebelum merge atau release.

Apa yang dimaksud regresi supply chain?

Regresi supply chain adalah perubahan pada dependensi atau proses instalasinya yang menurunkan posture keamanan atau integritas build, meski aplikasi utama tidak berubah. Contohnya:

  • Package manager menarik versi baru yang menambahkan post-install script tak terduga.
  • Lockfile berubah karena dependency resolution ulang, bukan karena perubahan yang disengaja.
  • Sumber artefak bergeser ke mirror atau registry yang tidak diizinkan.
  • Checksum atau integrity metadata berubah tanpa penjelasan yang jelas.
  • Build membutuhkan akses jaringan tambahan yang sebelumnya tidak ada.
  • Dependensi transitive baru masuk dan membuka jalur eksekusi saat install atau runtime.

Yang perlu dipahami: test aplikasi yang lulus tidak membuktikan supply chain aman. Endpoint bisa tetap merespons normal sementara proses install diam-diam mengeksekusi skrip yang tidak semestinya, mengunduh biner tambahan, atau memodifikasi artefak build.

Prinsip dasar verifikasi dependensi di CI

1. Perlakukan update dependensi sebagai perubahan kode

Perubahan pada package-lock.json, poetry.lock, go.sum, Cargo.lock, atau file serupa harus diperlakukan setara dengan perubahan source code. Jangan izinkan update dependensi masuk lewat commit yang tidak menjelaskan alasan, ruang lingkup, dan dampaknya.

2. Bedakan trust terhadap registry, package, dan artefak

Registry resmi bukan jaminan mutlak. Yang perlu diverifikasi adalah:

  • asal unduhan: dari registry atau host yang memang diizinkan,
  • integritas artefak: checksum, signature, atau metadata lockfile,
  • perilaku instalasi: apakah ada script, binary fetch, atau network egress baru.

3. Verifikasi harus otomatis, bukan hanya review manual

Review manual penting, tetapi tidak cukup untuk skala tim. CI perlu memaksa beberapa pemeriksaan dasar sebelum merge, dan release pipeline perlu punya gate tambahan untuk update yang menyentuh dependensi.

Guardrail yang layak ditambahkan ke CI

Smoke test untuk dependency update

Smoke test di konteks ini bukan test bisnis yang lengkap, melainkan verifikasi cepat bahwa aplikasi masih bisa dibangun, start, dan menjalankan alur kritis minimum setelah perubahan dependensi. Tujuannya:

  • mendeteksi breakage langsung setelah instalasi,
  • mengungkap perubahan perilaku startup,
  • memastikan artefak hasil build masih valid.

Contoh smoke test yang berguna untuk backend:

  • install dependensi dari lockfile di environment bersih,
  • jalankan build/compile,
  • start service dalam mode test,
  • cek health endpoint,
  • eksekusi 1-2 alur API utama,
  • pastikan proses exit cleanly.

Smoke test tidak menggantikan verifikasi keamanan, tetapi penting sebagai lapisan awal untuk membatasi blast radius update yang salah.

Integrity check terhadap lockfile dan artefak

Lockfile adalah titik kontrol terpenting karena ia mendefinisikan versi dan sering kali metadata integritas. CI sebaiknya memeriksa:

  • apakah lockfile berubah tanpa perubahan manifest yang sah,
  • apakah perubahan versi sesuai dengan PR,
  • apakah hash/integrity berubah secara konsisten,
  • apakah ada penambahan package transitive yang tidak wajar.

Untuk ekosistem yang mendukung mode deterministik, gunakan instalasi yang memaksa kecocokan dengan lockfile. Hindari pipeline yang diam-diam memperbarui dependency graph saat build.

# Contoh pola umum di CI: fail jika lockfile tidak sinkron atau berubah diam-diam
# Pilih perintah sesuai ekosistem proyek Anda.

# Node.js (contoh umum)
npm ci

# Python (contoh pendekatan)
pip install --require-hashes -r requirements.txt

# Go
go mod verify

Nama perintah berbeda per ekosistem, tetapi prinsipnya sama: install harus reproducible dan mengikuti lockfile/metadata yang sudah direview, bukan melakukan resolution baru secara diam-diam.

Review lockfile yang difokuskan pada sinyal penting

Masalah umum pada review lockfile adalah ukurannya besar sehingga reviewer melewatkan hal penting. Solusinya bukan mengabaikan lockfile, tetapi mengekstrak sinyal yang relevan:

  • package baru yang masuk,
  • perubahan source URL atau registry,
  • perubahan integrity/checksum,
  • lompatan versi mayor,
  • munculnya install script atau dependency optional baru,
  • jumlah dependensi transitive yang bertambah signifikan.

Buat bot atau skrip CI yang merangkum perubahan lockfile ke komentar PR. Reviewer manusia tidak perlu membaca seluruh file mentah jika sistem sudah menyorot perbedaan berisiko.

Pinning versi dan pembatasan update

Pinning tidak membuat supply chain aman, tetapi mengurangi perubahan tak terduga. Strateginya:

  • pin exact version untuk dependency kritis,
  • batasi update otomatis hanya ke patch/minor jika sesuai kebijakan tim,
  • pisahkan PR dependency update dari perubahan fitur,
  • gunakan jadwal update teratur agar review lebih fokus.

Trade-off-nya jelas: pinning terlalu ketat bisa memperlambat patch keamanan. Karena itu, pinning sebaiknya dipadukan dengan proses update berkala dan rollback yang cepat, bukan menjadi alasan untuk menunda pembaruan terus-menerus.

Allowlist registry dan kontrol asal paket

CI sebaiknya menolak instalasi dari host yang tidak dikenal. Ini penting karena beberapa ekosistem mengizinkan pengalihan sumber, custom index, mirror, atau pengunduhan biner tambahan saat install.

Praktiknya:

  • tetapkan daftar registry/index yang diizinkan,
  • blokir akses ke domain lain selama fase install jika tidak diperlukan,
  • catat semua network egress dari job build dependency,
  • bedakan allowlist untuk development dan production build.

Jika sebuah package tiba-tiba membutuhkan unduhan dari domain baru, CI harus menandainya untuk review manual.

Sandbox build untuk mengisolasi efek samping

Build yang memproses dependency update sebaiknya dijalankan di environment yang terisolasi dan minim privilege. Tujuannya bukan hanya keamanan host CI, tetapi juga observabilitas: Anda bisa melihat apakah proses install mencoba menulis ke lokasi yang tidak relevan, mengakses credential, atau membuka koneksi jaringan yang tidak diharapkan.

Karakteristik sandbox build yang baik:

  • filesystem ephemeral,
  • credential minimal,
  • secret tidak tersedia pada tahap install biasa,
  • network bisa dibatasi atau dimonitor,
  • tidak menggunakan cache global yang sulit diaudit.

Kesalahan umum adalah menjalankan install dependency di job yang juga memiliki akses ke secret deployment. Jika ada install script berbahaya, blast radius-nya langsung besar.

Scan perubahan install script dan hook serupa

Ini salah satu guardrail paling penting dan sering terlewat. Banyak serangan supply chain memanfaatkan fase install/build, bukan runtime utama. CI perlu memeriksa apakah dependency baru atau yang diperbarui memperkenalkan:

  • preinstall, install, postinstall,
  • hook build yang menjalankan shell command,
  • download biner saat instalasi,
  • script yang menulis ke path di luar workspace,
  • script yang membaca environment variable sensitif.

Untuk ekosistem yang memungkinkan, jalankan mode instalasi tanpa script sebagai langkah inspeksi awal, lalu bandingkan hasilnya dengan instalasi normal di sandbox. Bila sebuah package benar-benar membutuhkan script build, reviewer harus tahu mengapa dan apa yang dijalankan.

# Pseudocode CI untuk menandai perubahan script instalasi
if dependency_changes_detected:
  extract_package_metadata_before_after()
  if new_install_hooks_found or install_hook_changed:
    mark_pr_for_security_review()
    fail_if_unapproved()

Rollback cepat dan artefak yang bisa direproduksi

Verifikasi terbaik pun tidak menjamin semua masalah tertangkap. Karena itu, tim perlu kemampuan rollback yang cepat:

  • simpan artefak build yang sudah lolos verifikasi,
  • pastikan release bisa dipin ke commit dan lockfile tertentu,
  • hindari rebuild dari source saat rollback jika tidak perlu,
  • dokumentasikan prosedur revert dependency dan redeploy.

Jika rollback mengharuskan install ulang semua dependency dari registry publik saat insiden berlangsung, Anda masih bergantung pada supply chain yang sama. Menyimpan artefak terverifikasi jauh lebih aman dan cepat.

Membedakan test fungsional, security verification, dan regression gate

Test fungsional

Menjawab pertanyaan: apakah aplikasi masih bekerja sesuai kebutuhan?

  • unit test, integration test, API test, end-to-end kritis, smoke test aplikasi

Ini penting, tetapi tidak cukup untuk memvalidasi keamanan supply chain.

Security verification

Menjawab pertanyaan: apakah perubahan dependensi masih berasal dari sumber yang dipercaya, utuh, dan tidak memperkenalkan perilaku build/install yang mencurigakan?

  • integrity check, review lockfile, scan install script, allowlist registry, sandbox observation, signature/checksum verification bila tersedia

Fokusnya bukan fungsi bisnis, melainkan integritas dan perilaku supply chain.

Regression gate

Menjawab pertanyaan: apakah perubahan ini cukup aman dan stabil untuk lewat ke tahap berikutnya?

Regression gate adalah keputusan pipeline yang menggabungkan sinyal dari test fungsional dan security verification. Contohnya:

  • blok merge jika lockfile berubah tanpa approval,
  • blok release jika dependency baru menjalankan install script yang belum direview,
  • wajibkan security review untuk package dari registry non-default.

Kesalahan umum adalah mencampur semua hal ini dalam satu job test sehingga alasan kegagalan tidak jelas. Lebih baik pisahkan job dan tampilkan hasil per kategori.

Contoh checklist pipeline verifikasi sebelum merge dan release

Sebelum merge PR yang mengubah dependensi

  1. PR hanya berisi update dependensi atau perubahan terkait yang jelas.
  2. Manifest dan lockfile konsisten; tidak ada resolution ulang yang tidak disengaja.
  3. Semua package baru terdeteksi dan diringkas otomatis di PR.
  4. Source registry/package index sesuai allowlist.
  5. Integrity/checksum/metadata valid dan berubah sesuai update yang diharapkan.
  6. Install script baru atau yang berubah ditandai untuk review manual.
  7. Build dan smoke test lulus di environment bersih.
  8. Job install tidak memiliki akses ke secret sensitif.
  9. Jika ada lompatan versi mayor, reviewer memverifikasi changelog dan dampak API/runtime.
  10. Jika dependency bersifat kritis, approval tambahan dari owner komponen atau security champion diwajibkan.

Sebelum release

  1. Artefak release dibangun dari commit yang sama dengan hasil verifikasi.
  2. Dependency graph final sama dengan yang lolos di PR/CI.
  3. Tidak ada network fetch tambahan saat packaging final selain yang sudah diizinkan.
  4. Hasil scan install/build behavior tersimpan sebagai bukti audit.
  5. SBOM atau daftar dependency final tersedia jika workflow tim mendukung.
  6. Rollback target dan artefak release sebelumnya siap dipakai.

Contoh struktur pipeline CI

Berikut contoh pembagian job yang lebih mudah dioperasikan daripada satu job besar:

stages:
  - detect
  - verify-deps
  - build
  - test
  - release-gate

jobs:
  detect_dependency_changes:
    purpose: mendeteksi perubahan manifest/lockfile

  verify_lockfile_integrity:
    purpose: memastikan install reproducible dan metadata konsisten

  verify_registry_allowlist:
    purpose: menolak sumber unduhan di luar daftar izin

  inspect_install_scripts:
    purpose: menandai hook install/build baru atau berubah

  sandbox_install:
    purpose: menjalankan install di environment terisolasi dan mencatat network/file access penting

  build_application:
    purpose: compile/package aplikasi setelah dependency lolos verifikasi awal

  smoke_test:
    purpose: memastikan startup, health check, dan alur kritis minimum berfungsi

  release_gate:
    purpose: menggabungkan hasil verifikasi dan menentukan boleh merge/release atau tidak

Struktur ini memudahkan debugging. Jika pipeline gagal, tim langsung tahu apakah masalahnya ada pada integritas dependency, perilaku install, atau fungsi aplikasi.

False positive yang umum dan cara menanganinya

Package legitimate yang memang memakai build script

Tidak semua install script berbahaya. Beberapa package perlu mengompilasi native module, menghasilkan kode, atau menyesuaikan binary untuk platform tertentu. Tanda bahwa ini mungkin false positive:

  • script sudah lama ada dan hanya berubah minor,
  • perubahannya sesuai changelog resmi,
  • tidak ada network egress tambahan,
  • aksi script terbatas pada workspace/build directory.

Solusinya bukan mematikan rule, melainkan membuat pengecualian yang terdokumentasi per package, idealnya dengan masa berlaku dan owner review.

Perubahan lockfile besar karena tool atau OS berbeda

Beberapa ekosistem menghasilkan lockfile yang sensitif terhadap platform atau versi tool. Ini bisa memicu diff besar yang tampak mencurigakan. Penanganan yang benar:

  • standarkan toolchain di CI dan local dev,
  • gunakan container build yang sama,
  • pisahkan PR normal dari PR regenerasi lockfile,
  • minta ringkasan perubahan dependency graph, bukan hanya diff file mentah.

Network access yang valid saat build native dependency

Ada package yang mengambil toolchain atau binary pendukung saat build. Ini tetap berisiko, tetapi tidak selalu malicious. Jika memang dibutuhkan, pertimbangkan:

  • mirror internal,
  • prebuilt artifact yang diverifikasi,
  • allowlist domain yang sempit dan terdokumentasi,
  • cache artefak yang diaudit.

Kesalahan implementasi yang sering terjadi

  • Hanya mengandalkan scanner CVE. Scanner kerentanan berguna, tetapi tidak mendeteksi semua masalah supply chain seperti install script berbahaya atau perubahan asal artefak.
  • Mengizinkan auto-merge dependency update tanpa guardrail. Otomasi boleh, tetapi harus dibatasi oleh gate yang jelas.
  • Menjalankan install dependency dengan secret aktif. Ini memperbesar dampak jika terjadi kompromi.
  • Tidak membedakan dependency runtime dan dev/build. Dev dependency juga bisa berbahaya karena sering dieksekusi di CI.
  • Tidak punya jalur rollback sederhana. Saat insiden terjadi, waktu respons lebih penting daripada pipeline yang terlihat rapi.

Tips debugging saat gate verifikasi gagal

  • Bandingkan dependency tree sebelum dan sesudah update, bukan hanya versi top-level.
  • Lihat apakah ada perubahan host unduhan atau registry fallback.
  • Inspeksi metadata package untuk script lifecycle yang baru muncul.
  • Jalankan instalasi ulang di container bersih tanpa cache untuk memisahkan efek cache dari perubahan nyata.
  • Jika smoke test gagal, tentukan dulu apakah breakage berasal dari API package, binary native, atau langkah install.
  • Simpan log network dan file access dari job sandbox agar investigasi tidak bergantung pada reproduksi manual.

Penutup

Strategi verifikasi dependensi yang efektif tidak bergantung pada satu alat atau satu scanner. Yang dibutuhkan adalah rangkaian guardrail di CI: install reproducible, integrity check, review lockfile yang fokus, pinning yang masuk akal, allowlist registry, sandbox build, inspeksi install script, dan mekanisme rollback cepat.

Untuk tim aplikasi/backend, pendekatan ini realistis karena bisa diterapkan bertahap. Mulailah dari tiga kontrol paling berdampak: lockfile review yang dipaksa di CI, isolasi install dependency dari secret, dan penandaan otomatis untuk install script yang berubah. Setelah itu, tambahkan observabilitas network/build dan gate release yang lebih ketat. Intinya sederhana: update dependency adalah perubahan berisiko, jadi harus diverifikasi, bukan dipercaya otomatis.