Kalau kamu satu-satunya orang yang mengurus infrastruktur di perusahaan kecil, pengumuman tiga celah kritis dalam dua hari bukan situasi teoretis. Itu Selasa pagi yang buruk. Dan nasihat "segera patch semuanya" tidak membantu ketika waktu yang tersedia cuma satu jam di antara dua rapat.
Artikel ini bukan daftar lengkap semua yang ideal. Ini urutan yang bisa dieksekusi satu orang dalam satu jam, dengan asumsi yang paling penting: kamu memilih berhenti di titik yang aman, bukan mengerjakan semuanya setengah jalan.
Aturan Pertama: Kerjakan yang Paling Terbuka, Bukan yang Skornya Tertinggi
Naluri pertama biasanya mengerjakan celah dengan skor tertinggi lebih dulu. Untuk kasus pekan ini, itu berarti GitLab (10,0) sebelum PHP (9,2). Tapi GitLab hanya berbahaya kalau kamu menjalankan GitLab self-managed, sementara PHP dipakai hampir semua situs.
Urutan yang lebih baik memakai tiga pertanyaan:
- Apakah saya benar-benar memakai perangkat lunak ini?
- Apakah layanan itu bisa dijangkau dari internet tanpa VPN?
- Apakah celahnya butuh autentikasi?
Jawaban "ya, ya, tidak butuh" adalah kombinasi paling mendesak. Itu urutan pertama, apa pun skornya.
Menit 0–10: Susun Daftar, Jangan Patch Dulu
Sepuluh menit pertama untuk menulis daftar. Isinya: nama layanan, versi saat ini, apakah publik atau internal, dan nama orang yang bisa memberi akses.
Cara cepat mengisinya:
- Cek riwayat deploy dan Dockerfile untuk melihat versi runtime yang dipakai.
- Buka panel hosting untuk situs yang dikelola di sana.
- Jangan lupa layanan yang "dulu pernah dipakai": panel internal, staging yang masih terbuka, aplikasi lama yang masih jalan.
Daftar ini terasa seperti pekerjaan administratif yang menunda. Sebenarnya sebaliknya: tanpa daftar, kamu akan menghabiskan 40 menit berikutnya berpindah-pindah tanpa menyelesaikan satu pun.
Menit 10–35: Eksekusi Berurutan, Satu Per Satu
Aturan kedua: selesaikan satu layanan sampai terverifikasi sebelum pindah. Jangan memulai upgrade GitLab sambil menunggu container PHP selesai dibangun.
Urutan yang biasanya paling efisien untuk tim kecil:
1. PHP di situs publik (10–15 menit). Kalau di shared hosting, ini hanya soal mengubah pilihan versi di panel dan menguji halaman penting. Versi aman: 8.5.12, 8.4.27, 8.3.36, atau 8.2.35. Kalau server sendiri, perbarui paket lewat manajer paket distribusi. Rincian per CMS ada di panduan cek PHP2Shell.
2. Node.js (5–10 menit). Ubah versi di build config, deploy, uji satu endpoint. Versi aman: 26.12.1, 24.22.1, 22.23.4.
3. GitLab self-managed (15–20 menit). Ini yang paling berat karena bisa ada migrasi basis data. Kalau sisa waktu kurang dari 20 menit, jangan mulai. Jadwalkan ulang ke slot khusus, dan sementara itu batasi akses ke jalur login dari luar. Detail versi dan aturan deteksi ada di artikel GitLab CVE-2026-110264.
Menit 35–50: Verifikasi yang Tidak Boleh Dilewati
Untuk setiap layanan yang sudah disentuh, lakukan tiga cek cepat:
- Baca nomor versi dari sistem yang berjalan, bukan dari catatan. Pada container, pastikan container baru benar-benar aktif.
- Buka satu alur nyata: beranda, login, satu form.
- Lihat log error 5 menit terakhir. Cari error yang belum pernah muncul sebelumnya.
Kalau salah satu gagal, rollback layanan itu dan tandai sebagai belum selesai. Lebih baik satu layanan tidak dipatch tapi berjalan normal, daripada tiga layanan dalam kondisi tidak jelas.
Menit 50–60: Catat dan Kirim Satu Pesan
Tulis empat kolom: layanan, versi sebelum, versi sesudah, status verifikasi. Simpan di tempat yang bisa dibaca orang lain, bukan di chat pribadi.
Lalu kirim satu pesan singkat ke tim atau atasan:
"Tiga celah kritis dirilis pekan ini. PHP dan Node.js sudah dipatch dan diuji. GitLab dijadwalkan Kamis 21.00 karena butuh downtime 20 menit. Selama menunggu, akses login GitLab dibatasi ke IP kantor."
Pesan seperti ini mengubah laporan teknis menjadi informasi yang bisa dipakai orang lain untuk mengambil keputusan. Itu yang dicari atasan, bukan daftar CVE.
Kalau Waktunya Cuma 20 Menit
Versi paling minimal, untuk hari yang benar-benar kacau:
- Patch PHP di situs publik yang punya form login atau transaksi. Lewati sisanya.
- Catat apa yang belum dikerjakan dalam satu baris.
- Kirim pesan bahwa sisanya dijadwalkan besok pagi.
Yang tidak boleh dilakukan: mengerjakan tiga hal sekaligus lalu tidak menyelesaikan satu pun, tanpa catatan tentang apa yang sudah dan belum.
Kesalahan yang Sering Terjadi di Tim Kecil
Menunggu "waktu tenang". Untuk celah yang sedang dieksploitasi di alam liar, waktu tenang tidak akan datang. Kerjakan bagian kecilnya sekarang.
Menganggap staging aman. Staging yang bisa diakses dari internet adalah produksi dengan nama lain.
Menunda karena takut merusak. Risikonya nyata, tapi bisa dikelola dengan backup dan uji alur utama. Bandingkan dengan risiko server yang sudah diambil alih.
Tidak mencatat. Enam bulan kemudian, saat audit, ingatan tidak berguna.
Pertanyaan yang Sering Muncul
Apakah semua ini harus hari ini? PHP yang terbuka dengan mod_php, ya. Sisanya, selesaikan dalam 24–48 jam dan catat jadwalnya.
Bagaimana kalau tidak ada yang bisa memberi akses? Itu blocker organisasi, bukan teknis. Laporkan sebagai risiko dengan nama layanan dan dampaknya, lalu minta keputusan.
Apakah perlu memberi tahu pengguna? Kalau ada downtime, ya. Kalau tidak ada, cukup catat internal.
Penutup
Satu jam tidak cukup untuk menyelesaikan semua celah di semua layanan, dan tidak perlu. Yang perlu adalah menyelesaikan yang paling terbuka, memverifikasinya, mencatat sisanya, dan mengomunikasikan dengan jelas. Tiga hal itu yang membedakan tim kecil yang kewalahan dari tim kecil yang terkendali, dan hanya satu di antaranya yang bisa dilatih dalam satu jam.
Untuk urutan yang lebih lengkap lintas tiga perangkat lunak, lihat panduan patch 30 menit. Untuk latar belakang teknis celahnya, mulai dari PHP2Shell.
Komentar 0