PHP Foundation: Satu Staf Penuh Waktu untuk 70 Persen Situs Dunia

PHP Foundation menjalankan operasinya dengan satu staf penuh waktu dan 14 kontraktor yang sebagian besar paruh waktu, padahal PHP disebut menopang hingga 70 persen situs di dunia. Angka itu disampaikan Executive Director Elizabeth Barron kepada Reuters dalam wawancara yang terbit 23 Oktober 2026. Anggota dewan tidak dibayar, dan pendanaan berasal dari donasi serta hibah.

Angka-angka itu penting karena menjelaskan mengapa perbaikan keamanan pada proyek sebesar PHP bergantung pada koordinasi, bukan pada jumlah baris kode yang bisa ditulis dalam sehari.

TL;DR

• Satu staf penuh waktu, 14 kontraktor paruh waktu, dewan tanpa bayaran.
• PHP dipakai hingga 70 persen situs global menurut laporan Reuters.
• Usulan perubahan kode hampir dua kali lipat dibanding setahun lalu, tanpa kenaikan jumlah kontributor.
• Dua kerentanan kritis yang ditemukan pekan itu sudah ada selama satu dekade.

Berapa sebenarnya kapasitas PHP Foundation?

Kapasitasnya satu orang penuh waktu ditambah 14 kontraktor, dengan dewan pengurus yang bekerja tanpa upah. Barron menyebut dirinya sendiri sebagai satu-satunya staf penuh waktu, dan menyatakan pendanaan berasal dari donasi serta hibah.

Angka itu perlu dibaca bersama konteksnya. Yayasan ini bukan perusahaan yang mempekerjakan seluruh kontributor PHP, dan struktur organisasinya bisa diperiksa di situs resmi PHP Foundation. Sebagian besar kode PHP ditulis oleh relawan dari berbagai perusahaan, dan yayasan berperan sebagai koordinator, pemberi hibah untuk pekerjaan tertentu, serta penghubung ketika ada masalah keamanan yang harus ditangani bersama.

Tetapi peran koordinator itulah yang paling terasa ketika insiden terjadi. Ketika dua kerentanan kritis ditemukan, yayasan harus menghubungi peneliti, menyepakati jadwal pengungkapan, menyiapkan patch, dan berkoordinasi dengan perusahaan keamanan. Pekerjaan itu tidak bisa dilakukan oleh relawan yang muncul sesekali. Ia butuh orang yang bisa dihubungi hari itu juga.

Menurut laporan yang sama, yayasan bekerja bersama peneliti eksternal dan perusahaan keamanan, termasuk Wiz, untuk menyelidiki cacat tersebut dan mengoordinasikan perbaikan. Patch dirilis pada Rabu pekan itu, dan situs pemerintah di sejumlah negara Eropa sempat gelap pada 21 Oktober 2026 ketika operator berlomba menambal.

Mengapa AI justru menambah beban maintainer?

Karena AI membantu menemukan cacat lama sekaligus melipatgandakan jumlah usulan perubahan yang harus ditinjau manusia. Barron menyebut proyek PHP menerima hampir dua kali lipat usulan perubahan kode dibanding setahun sebelumnya, sementara jumlah kontributor tidak ikut berlipat.

Dua efek itu bergerak berlawanan arah. Di satu sisi, AI mempercepat penemuan bug. Dua kerentanan yang menjadi sorotan pekan itu disebut sudah ada selama satu dekade, dan alat bantu berbasis AI berperan dalam menemukannya. Itu kabar baik, karena bug yang bertahan sepuluh tahun berarti lolos dari tinjauan manusia selama sepuluh tahun.

Di sisi lain, AI juga menurunkan biaya untuk menghasilkan patch. Kalau dulu seorang kontributor harus memahami konteks kode sebelum mengirim usulan, sekarang usulan bisa dibuat dalam hitungan menit. Hasilnya, antrean tinjauan membengkak. Setiap usulan tetap harus dibaca, dipahami, diuji, dan diputuskan oleh manusia yang mengerti konsekuensinya.

Di sinilah argumen ekonomi yayasan menjadi jelas. Menambah alat tidak menambah kapasitas peninjauan. Yang menambah kapasitas adalah orang, dan orang butuh pendanaan yang stabil. Tanpa itu, satu-satunya cara menyerap lonjakan usulan adalah memperlambat tinjauan, dan memperlambat tinjauan pada proyek yang dipakai puluhan juta situs berarti memperlambat perbaikan keamanan.

Aspek	Angka	Sumber
Staf penuh waktu	1 orang	Reuters, 23 Oktober 2026
Kontraktor	14, sebagian besar paruh waktu	Reuters, 23 Oktober 2026
Dewan pengurus	Relawan tanpa bayaran	Reuters, 23 Oktober 2026
Perkiraan pangsa situs global	Hingga 70 persen	Reuters, 23 Oktober 2026
Usulan perubahan kode	Hampir 2 kali lipat dalam setahun	Reuters, 23 Oktober 2026

Apa risikonya bagi perusahaan yang bergantung pada PHP?

Risikonya bukan bahwa PHP akan hilang, melainkan bahwa perbaikan keamanan datang lebih lambat daripada laju eksploitasi. Ketika kapasitas peninjauan terbatas, setiap tahap dari penemuan sampai patch dirilis berjalan dengan antrean.

Konteks pekan itu menunjukkan skalanya. Menurut laporan Reuters, Cloudflare mencatat jutaan upaya peretasan, dan situs pemerintah di sejumlah negara Eropa sempat gelap pada 21 Oktober 2026 ketika operator berlomba menambal. Barron menyatakan yayasan tidak memiliki bukti bahwa kerentanan dieksploitasi sebelum diungkapkan, atau pada sistem yang sudah ditambal.

Bagi perusahaan, artinya sederhana: kecepatan menambal di sisi pengguna harus mengasumsikan bahwa jendela antara pengungkapan dan eksploitasi sangat sempit. Menunggu panduan internal selesai, atau menunggu jadwal pemeliharaan bulanan, adalah pilihan yang mahal. Untuk komponen yang menghadap internet, penambalan harus bisa dilakukan di luar jadwal normal.

Ada juga risiko yang lebih tidak langsung. Dokumentasi, ekstensi, dan tooling di sekitar PHP banyak dirawat oleh orang yang sama. Kalau waktu maintainer habis untuk meninjau usulan, pekerjaan lain seperti memperbarui dokumentasi keamanan dan menutup laporan bug lama akan tertunda. Dampaknya tidak langsung terlihat, tetapi terasa ketika tim butuh jawaban yang jelas di tengah insiden.

Bagaimana model pendanaan proyek infrastruktur seperti ini?

Modelnya bergantung pada donasi dan hibah, dengan dewan yang bekerja tanpa bayaran. Itu model yang lazim untuk proyek open source infrastruktur, dan justru karena lazimnya, masalahnya sering diabaikan sampai ada insiden.

Ketidakcocokan strukturalnya mudah dijelaskan. Nilai ekonomi yang dihasilkan sebuah bahasa pemrograman tersebar ke jutaan situs, ribuan perusahaan, dan puluhan penyedia hosting. Sementara itu, kemampuan untuk mengumpulkan dana terkonsentrasi pada sedikit organisasi yang bersedia menyumbang, dan pada beberapa perusahaan besar yang merasa berkepentingan langsung.

Dalam kasus PHP, ketergantungan itu tidak merata. Banyak perusahaan memakai PHP lewat kerangka kerja dan platform siap pakai, sehingga mereka tidak merasa berurusan langsung dengan PHP. Padahal setiap perbaikan keamanan di lapisan bahasa tetap harus melewati proses yang sama, dan proses itu dijalankan oleh tim kecil.

Angka pangsa situs biasanya dilacak oleh layanan seperti W3Techs. Cara membaca angka 70 persen dengan tepat: itu perkiraan pangsa situs, bukan pangsa anggaran atau pangsa kontributor. Dua hal itu tidak berbanding lurus. Justru kombinasi pangsa besar dengan tim kecil adalah definisi infrastruktur digital, yaitu sesuatu yang dipakai semua orang, dirawat oleh sedikit orang, dan gagal bersamaan ketika bermasalah.

Apakah ada bukti eksploitasi sebelum patch dirilis?

Tidak ada, menurut pernyataan yayasan. Barron menyebut tidak ada indikasi tambahan dari pihak yang terlibat bahwa kerentanan dieksploitasi sebelum diungkapkan atau pada sistem yang sudah ditambal.

Ketidakhadiran bukti itu layak dicatat, tetapi tidak boleh dibaca sebagai jaminan. Untuk kerentanan yang sudah ada selama satu dekade, ketiadaan laporan bisa berarti tidak ada yang mengeksploitasi, atau bisa berarti eksploitasi terjadi tanpa terdeteksi. Dua kemungkinan itu tidak bisa dibedakan hanya dari pernyataan bahwa tidak ada indikasi.

Yang bisa diambil sebagai pelajaran adalah soal deteksi. Kalau sebuah cacat bertahan sepuluh tahun, itu bukan kegagalan satu orang. Itu tanda bahwa tinjauan kode, pengujian otomatis, dan fuzzing belum menjangkau jalur tersebut. Menambah alat bantu berbasis AI membantu menemukan, tetapi tidak menggantikan pengujian yang berjalan terus-menerus.

Untuk tim yang mengelola layanan, kesimpulannya praktis. Periksa apakah versi PHP yang dipakai sudah menerima patch pekan itu, dengan melihat catatan rilis di repositori php-src, dan periksa juga dependensi yang membundel komponen terkait. Jangan menunggu pengumuman berikutnya untuk memastikan jalur pembaruan bisa dijalankan cepat.

Bagaimana perusahaan bisa membantu tanpa mengubah kode?

Caranya dengan mendanai kapasitas tinjauan, bukan hanya menulis patch. Beban terbesar dalam proyek sebesar PHP bukan menghasilkan perubahan, melainkan memverifikasi bahwa perubahan itu benar dan tidak merusak kompatibilitas.

Ada tiga bentuk dukungan yang bisa dijalankan tanpa menyentuh kode sama sekali. Pertama, hibah tanpa earmark yang memberi yayasan keleluasaan mempekerjakan peninjau. Kedua, penugasan engineer perusahaan untuk beberapa jam per minggu khusus meninjau usulan, dengan target yang jelas dan waktu yang dilindungi dari pekerjaan lain. Ketiga, pendanaan pengujian berkelanjutan, termasuk fuzzing yang berjalan terus-menerus, karena cacat yang bertahan satu dekade menunjukkan pengujian statis tidak cukup.

Ketiganya punya satu kesamaan: hasilnya tidak terlihat di dasbor perusahaan. Tidak ada fitur baru, tidak ada pengumuman produk, dan tidak ada metrik yang naik. Itulah alasan pendanaan infrastruktur selalu tertinggal dibanding pendanaan fitur, meskipun nilai ekonominya jauh lebih besar ketika terjadi kegagalan.

Bagi tim engineering, ada satu langkah yang bisa diambil minggu ini tanpa anggaran: pastikan jalur pembaruan PHP berjalan cepat di semua layanan, dan catat versi yang terpasang per layanan. Ketika patch keamanan berikutnya dirilis, waktu dari pengumuman sampai semua layanan diperbarui adalah metrik yang bisa diukur, dan metrik itu jauh lebih berguna daripada pernyataan bahwa sistem sudah patuh.

Ada satu detail yang mudah terlewat dari laporan itu: patch dirilis pada Rabu pekan yang sama ketika cacat ditemukan. Jarak selama itu terlihat cepat, dan memang cepat untuk ukuran proyek besar. Tetapi kecepatan itu hanya mungkin karena ada orang yang bisa dihubungi, jadwal pengungkapan yang disepakati, dan koordinasi dengan peneliti di luar yayasan.

FAQ

Berapa jumlah staf PHP Foundation?

Satu staf penuh waktu, yaitu executive director, ditambah 14 kontraktor yang sebagian besar bekerja paruh waktu. Anggota dewan pengurus adalah relawan tanpa bayaran, dan pendanaan berasal dari donasi serta hibah.

Berapa pangsa situs yang memakai PHP?

Reuters menyebut PHP dapat menopang hingga 70 persen situs secara global. Angka itu adalah perkiraan pangsa situs, bukan pangsa anggaran, dan tidak berkorelasi langsung dengan jumlah kontributor aktif.

Mengapa usulan perubahan kode naik drastis?

Menurut Barron, AI membuat pemrogram lebih efisien sehingga usulan perubahan hampir dua kali lipat dibanding setahun sebelumnya, sementara jumlah kontributor tidak ikut berlipat. Tinjauan tetap membutuhkan manusia yang memahami konteks kode.

Apakah kerentanan pekan itu sudah dieksploitasi?

Yayasan menyatakan tidak ada bukti eksploitasi sebelum pengungkapan maupun pada sistem yang sudah ditambal. Cloudflare mencatat jutaan upaya peretasan pada periode yang sama, menurut laporan Reuters.

Bagaimana cara mendukung proyek seperti ini?

Dukungan paling langsung adalah donasi atau hibah yang memberi yayasan kemampuan mempekerjakan peninjau tetap. Dukungan lain adalah kontribusi tinjauan kode dan pengujian, karena beban terbesar bukan menulis patch melainkan memverifikasinya.