Satu Plugin Composer Bisa Menyalakan RCE di CI Kamu

Build PHP kamu bisa terlihat normal, test hijau, deploy mulus, lalu diam-diam menjalankan kode dari package yang baru saja masuk lewat dependency update. Masalahnya bukan cuma package berbahaya. Masalah yang lebih licin adalah Composer plugin, karena plugin memang punya hak untuk mengeksekusi kode saat composer install atau composer update.

Kalau kamu mengelola banyak project klien, CI runner, private package, atau monorepo PHP, fitur ini bukan sekadar opsi konfigurasi. Ini kontrol supply chain yang murah, cepat, dan sering menyelamatkan sebelum incident terjadi.

Kenapa Composer Plugin Lebih Berisiko dari Package Biasa?

Package PHP biasa umumnya baru berjalan ketika aplikasi memanggil class atau function-nya. Namun, Composer plugin bisa aktif selama proses dependency resolution, install, update, autoload dump, atau script event.

Dengan kata lain, risikonya muncul sebelum aplikasi kamu dijalankan. Karena itu, Composer plugin allow-listing membantu memblokir jalur eksekusi yang sering luput dari review kode.

Composer sendiri mendokumentasikan konfigurasi ini di Composer allow-plugins config. Selain itu, Composer 2.2 memperketat perilaku plugin supaya project eksplisit memilih plugin mana yang dipercaya.

Apa Itu Composer Plugin Allow-Listing?

Composer plugin allow-listing adalah mekanisme untuk menentukan plugin Composer mana yang boleh berjalan. Aturannya disimpan di composer.json, tepatnya di bagian config.allow-plugins.

Contoh sederhana:

{
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "dealerdirect/phpcodesniffer-composer-installer": true,
      "php-http/discovery": false
    }
  }
}

Artinya, dua plugin pertama boleh aktif. Sementara itu, php-http/discovery sengaja diblokir.

Masalah yang Diselesaikan: Eksekusi Kode Arbitrer Saat Install

Tanpa allow-list, dependency baru bisa membawa plugin yang menjalankan kode di mesin developer atau CI. Akibatnya, attacker dapat menargetkan token, secret env, file konfigurasi, atau kredensial deploy.

Risiko ini makin besar kalau pipeline kamu masih longgar. Misalnya, PR dari fork menjalankan Composer dengan akses secret. Kalau skenario itu terdengar familiar, baca juga cara memisahkan secret CI dari pull request berisiko.

Framework Praktis: Trust Plugin, Not Vendor

Banyak tim membuat kesalahan halus: mereka percaya vendor, lalu otomatis percaya semua plugin dari vendor itu. Padahal, yang perlu kamu nilai bukan nama besar vendornya saja, melainkan kapabilitas plugin.

Pakai framework kecil ini sebelum mengizinkan plugin:

• Purpose: plugin ini benar-benar dibutuhkan untuk build?
• Privilege: plugin menyentuh filesystem, network, autoload, atau script event?
• Persistence: plugin bisa mengubah file project atau generate kode?
• Publisher: maintainer aktif, rilis jelas, issue ditangani?
• Pipeline: plugin berjalan di laptop saja, CI saja, atau production build?

Ini bagian yang sering terasa aneh: plugin kecil untuk tooling bisa lebih berbahaya daripada library runtime besar. Sebab, tooling biasanya berjalan di tempat yang punya akses token dan secret.

Konfigurasi Aman untuk WordPress, Laravel, dan Symfony

1. Jangan Pakai Allow-All

Hindari ini kecuali kamu sedang debugging lokal yang benar-benar terisolasi:

{
  "config": {
    "allow-plugins": true
  }
}

Konfigurasi tersebut menghapus manfaat allow-list. Akibatnya, plugin baru bisa berjalan tanpa keputusan eksplisit dari tim.

2. Commit Aturan allow-plugins ke Repo

Masukkan konfigurasi ke composer.json, lalu commit. Dengan begitu, developer lokal dan CI memakai kebijakan yang sama.

Selanjutnya, pastikan lockfile juga diperlakukan sebagai kontrak. Untuk detailnya, lihat kenapa lockfile bisa bohong kalau CI masih pakai install biasa.

3. Audit Saat Dependency Berubah

Setiap PR yang mengubah composer.json atau composer.lock wajib menjawab satu pertanyaan: apakah ada plugin baru?

Jalankan:

composer show --plugins
composer validate --strict

Kemudian, review package baru lewat Packagist, repository source, changelog, dan issue tracker. Untuk referensi broader supply chain, cek panduan OWASP CI/CD Security Risks.

Contoh Kebijakan Tim yang Lebih Rapi

Untuk agency WordPress atau tim Laravel besar, jangan biarkan keputusan plugin tersebar di chat. Buat kebijakan ringan seperti ini:

• Plugin baru harus punya alasan teknis yang jelas.
• Plugin yang cuma membantu lokal dev tidak boleh berjalan di production build.
• Perubahan allow-plugins wajib lewat code review senior.
• CI memakai composer install --no-interaction --prefer-dist.
• PR dari fork tidak mendapat secret saat menjalankan Composer.

Kalau kamu memakai private package, jangan lupa bahaya lain: nama package internal bisa tertukar dengan registry publik. Baca lanjutannya di dependency confusion defense untuk Composer dan CI.

Checklist Cepat Composer Plugin Allow-Listing

• Cek plugin aktif dengan composer show --plugins.
• Tambahkan plugin yang dipercaya ke config.allow-plugins.
• Set plugin mencurigakan ke false, bukan dibiarkan abu-abu.
• Commit composer.json dan composer.lock.
• Blokir allow-all di review.
• Pisahkan CI untuk PR eksternal dari secret deploy.

FAQ

Apakah Composer plugin allow-listing wajib?

Untuk project profesional, iya. Composer plugin allow-listing menurunkan risiko eksekusi kode otomatis dari dependency yang belum kamu percaya.

Apakah ini akan merusak Laravel atau Symfony?

Biasanya tidak, selama plugin yang memang dibutuhkan kamu izinkan secara eksplisit. Kalau build gagal, Composer biasanya memberi tahu plugin mana yang perlu diputuskan.

Apakah WordPress agency perlu peduli?

Sangat perlu. Banyak agency memakai Composer untuk Bedrock, plugin premium, mu-plugin, coding standard, atau deployment tooling. Semua itu sering berjalan di CI yang punya akses sensitif.

Kesimpulan

Composer plugin allow-listing adalah kontrol kecil dengan dampak besar. Kamu tidak perlu membenci plugin Composer. Kamu hanya perlu memastikan plugin yang bisa menjalankan kode sudah benar-benar kamu pilih, review, dan batasi.

Kalau tim-mu mengelola WordPress, Laravel, Symfony, atau stack PHP lain, mulai dari satu PR sederhana: audit plugin, rapikan allow-plugins, lalu jadikan perubahan itu standar review.