Auto-Merge Dependency Tanpa Jadi Korban Supply Chain

Patch dependency harus cepat. Tapi satu update kecil yang terlihat aman bisa membuka pintu supply chain attack, bikin build hijau palsu, lalu produksi ikut kena. Kalau timmu pakai Renovate atau Dependabot, masalahnya bukan “perlu auto-merge atau tidak”, melainkan update mana yang boleh melaju sendiri, dan update mana yang wajib ditahan.

Kenapa Auto-Merge Dependency Terasa Perlu, Tapi Menakutkan?

Tim modern punya terlalu banyak dependency. Paket npm, Composer, Docker image, GitHub Actions, plugin tooling, library testing, semuanya terus berubah. Karena itu, Renovate auto merge dan Dependabot security update sering jadi penyelamat.

Namun, update minor atau patch tidak selalu aman. Semver hanya janji sosial, bukan pagar beton. Paket bisa typo-squatted, maintainer bisa dibajak, token bisa bocor, atau release baru membawa kode post-install yang aneh.

Jadi, targetmu sederhana: patch cepat untuk celah nyata, lambat untuk perubahan yang belum terbukti aman.

Prinsip Utama: Auto-Merge Itu Hak Istimewa, Bukan Default

Banyak tim salah mulai dari pertanyaan, “Dependency mana yang bisa di-auto-merge?” Lebih aman kalau kamu balik pertanyaannya: “Dependency mana yang layak mendapat hak auto-merge?”

Dengan cara ini, setiap paket harus lolos kriteria. Akibatnya, kebijakanmu jadi defensif sejak awal, tetapi tetap cepat untuk update yang jelas aman.

Checklist Hak Auto-Merge

• Patch version boleh auto-merge jika semua test hijau.
• Minor version hanya boleh auto-merge untuk paket allowlist.
• Major version wajib review manual.
• Dependency runtime lebih ketat daripada dev dependency.
• Paket dengan script install wajib ditahan.

Framework 4 Lapis untuk Safe Auto-Merge Policy

Pakai empat lapis ini supaya Renovate atau Dependabot tidak sekadar cepat, tetapi juga punya rem yang jelas.

1. Risiko Paket

Kelompokkan dependency berdasarkan dampak. Library auth, crypto, payment, build tool, GitHub Actions, dan paket yang berjalan di production harus masuk zona ketat. Sementara itu, formatter atau test helper bisa mendapat jalur lebih cepat.

2. Risiko Versi

Patch biasanya lebih aman, tetapi tetap perlu test. Minor sering terlihat kecil, padahal bisa membawa behavior baru. Karena itu, minor update sebaiknya pakai delay minimal 2 sampai 7 hari, khususnya untuk package publik yang populer.

3. Risiko Pipeline

CI wajib lebih dari sekadar unit test. Tambahkan lint, type check, vulnerability scan, lockfile diff, smoke test, dan kalau bisa ephemeral environment. Jika salah satu gagal, auto-merge berhenti.

4. Risiko Waktu

Jangan merge otomatis saat tim tidur. Batasi auto-merge pada jam kerja, misalnya Senin sampai Kamis. Dengan begitu, kalau update memicu error, tim bisa rollback cepat.

Aturan Praktis untuk Renovate

Renovate unggul karena konfigurasinya granular. Kamu bisa mengatur packageRules, schedule, automergeType, minimumReleaseAge, dan grouping. Dokumentasi resminya bisa kamu cek di Renovate Docs.

{
  "extends": ["config:recommended"],
  "timezone": "Asia/Jakarta",
  "schedule": ["before 3pm on monday through thursday"],
  "dependencyDashboard": true,
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "matchDepTypes": ["devDependencies"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "matchUpdateTypes": ["minor"],
      "matchPackageNames": ["eslint", "prettier", "phpunit/phpunit"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["needs-human-review"]
    }
  ]
}

Advanced tip: jangan group semua dependency jadi satu PR besar. Grouping memang mengurangi noise, tetapi saat gagal, kamu susah tahu sumber masalahnya. Group hanya paket sekeluarga, misalnya ESLint ecosystem atau PHPUnit stack.

Aturan Praktis untuk Dependabot

Dependabot lebih sederhana, tetapi tetap bisa aman jika kamu kombinasikan dengan branch protection dan GitHub Actions. Panduan resminya tersedia di GitHub Dependabot Docs.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 5
    groups:
      dev-tools:
        dependency-type: "development"
        update-types:
          - "patch"
          - "minor"

Setelah itu, buat workflow auto-merge hanya untuk PR Dependabot yang memenuhi syarat. Misalnya, patch dev dependency, CI hijau, tanpa perubahan lockfile mencurigakan, dan bukan paket sensitif.

Guardrail Wajib untuk Tim WordPress Maintenance

Untuk WordPress, risikonya sering datang dari Composer package, build asset npm, GitHub Actions, dan tooling deployment. Karena itu, safe auto-merge policy perlu menyentuh repo, staging, serta proses rilis.

• Wajibkan staging smoke test untuk halaman login, checkout, form, dan admin.
• Jangan auto-merge update yang mengubah dependency production tanpa review.
• Aktifkan branch protection, required checks, dan signed commits bila memungkinkan.
• Scan vulnerability memakai GitHub Advanced Security, npm audit, OSV, atau Snyk.
• Simpan changelog ringkas di PR supaya reviewer cepat paham dampaknya.

Kalau kamu mengelola banyak situs, kebijakan ini juga membantu mengurangi kerja repetitif. Namun, kamu tetap punya kontrol saat paket berisiko menyentuh auth, cache, payment, atau deployment.

Sinyal Merah yang Harus Membatalkan Auto-Merge

• Paket baru punya maintainer baru mendadak.
• Release baru muncul terlalu cepat setelah akun maintainer berubah.
• Lockfile berubah terlalu besar untuk update kecil.
• Ada postinstall script baru.
• PR menyentuh file build, workflow, atau deployment.
• Package jarang dipakai, tetapi meminta permission luas.

Untuk referensi ancaman supply chain, baca juga publikasi OWASP CI/CD Security Risks dan database kerentanan OSV. Dua sumber ini bagus untuk membentuk aturan internal yang lebih tajam.

Template Kebijakan yang Bisa Kamu Pakai

Mulai dari aturan sederhana ini, lalu sesuaikan dengan risk appetite timmu.

• Auto-merge langsung: patch dev dependency, CI hijau, minimum release age 3 hari.
• Auto-merge tertunda: patch runtime dependency, CI hijau, smoke test lolos, delay 5 sampai 7 hari.
• Review manual: minor runtime dependency, paket auth, crypto, payment, cache, deployment.
• Blokir otomatis: major update, perubahan GitHub Actions sensitif, paket dengan script install baru.

FAQ

Apakah patch dependency selalu aman untuk auto-merge?

Belum tentu. Patch lebih rendah risiko, tetapi tetap perlu CI, delay window, dan pengecekan lockfile.

Lebih baik Renovate atau Dependabot?

Renovate lebih fleksibel untuk policy kompleks. Dependabot lebih simpel dan cocok jika timmu sudah nyaman dengan GitHub native workflow.

Berapa lama delay update yang ideal?

Untuk patch dev dependency, 3 hari biasanya cukup. Untuk runtime dependency atau minor update, pakai 5 sampai 7 hari agar komunitas sempat menemukan masalah awal.

Kesimpulan: Cepat Boleh, Ceroboh Jangan

Safe auto-merge policy bukan rem inovasi. Justru, kebijakan ini bikin timmu patch lebih cepat tanpa menyerahkan produksi ke setiap release baru di internet. Kuncinya adalah klasifikasi risiko, CI kuat, delay window, dan review manual untuk area sensitif.

Kalau kamu memimpin tim DevOps atau maintenance WordPress, mulai minggu ini dengan satu repo dulu. Aktifkan dependency dashboard, pilih paket yang layak auto-merge, lalu ukur berapa banyak PR rutin yang hilang tanpa menambah risiko.