Jawaban singkat: jika organisasi memakai ServiceNow AI Platform, mulai dari konfirmasi instance, versi/patch status, owner aplikasi, dan exposure integration sebelum mengambil keputusan perubahan. Advisory ServiceNow untuk CVE-2026-6875 menyebut risiko remote code execution tanpa autentikasi; ServiceNow menyatakan tidak mengetahui eksploitasi aktif pada saat advisory. Itu berarti ini adalah prioritas patch dan validasi, bukan bukti bahwa instance organisasi sudah compromise.
Untuk siapa checklist ini dibuat?
Untuk IT Manager, ServiceNow platform owner, security operations, dan application owner di Indonesia yang mengelola workflow, ticketing, automation, atau integrasi ServiceNow. Tujuannya adalah membuat respons vulnerability dapat dibuktikan: siapa yang mengecek, perubahan apa yang dilakukan, dan evidence apa yang disimpan.
Apa yang perlu dipastikan dari advisory
Gunakan advisory ServiceNow sebagai sumber versi, patch, dan cakupan affected deployment. Jangan hanya mengandalkan ringkasan pihak ketiga atau mengasumsikan seluruh konfigurasi terkena dampak yang sama. Catat instance, environment, version/build, plugin atau capability terkait, serta jadwal maintenance yang realistis.
| Keputusan | Bukti minimum | Tindakan aman |
|---|---|---|
| Instance terdampak? | Inventory instance, versi, dan advisory mapping | Tentukan scope patch berdasarkan bukti vendor. |
| Patch siap diterapkan? | Owner, window, dependency, rollback note | Uji pada non-production bila proses organisasi memungkinkan. |
| Ada sinyal anomali? | Admin audit, integration activity, perubahan konfigurasi | Eskalasi ke incident process bila ada evidence, bukan asumsi. |
Checklist 30 menit pertama
- Tetapkan satu owner teknis dan satu owner bisnis untuk setiap instance.
- Bandingkan release/build dengan advisory dan dokumentasikan hasilnya.
- Identifikasi integration account, API, admin role, dan workflow yang berisiko terganggu oleh perubahan.
- Siapkan maintenance window, rollback note, dan acceptance check untuk workflow utama.
- Simpan evidence patch: waktu, owner, versi sebelum/sesudah, dan hasil smoke test.
Patch tidak menggantikan hardening
Patch menutup exposure yang diketahui, tetapi tim tetap perlu meninjau akses admin, token integrasi, monitoring perubahan konfigurasi, dan log untuk aktivitas yang tidak selaras dengan operasi normal. Pembatasan privilege dan ownership yang jelas mempercepat investigation ketika ada alert berikutnya.
FAQ
Apakah CVE ini berarti instance kami sudah disusupi?
Tidak. Advisory adalah sinyal untuk validasi dan patch. Kesimpulan compromise memerlukan evidence dari log, activity review, atau proses incident response.
Apakah patch harus langsung dilakukan tanpa review?
Prioritas tinggi tidak berarti mengabaikan dependency. Tetapkan window yang proporsional, uji bila memungkinkan, dan pastikan owner proses bisnis mengetahui dampaknya.
Bukti apa yang perlu disimpan?
Scope instance, versi, keputusan patch, waktu perubahan, owner, hasil smoke test, dan temuan monitoring setelah perubahan.
Mulai dari exposure review yang terukur
myBATICloud dapat membantu menata asset ownership, access review, monitoring, dan hardening backlog agar patching tidak berhenti pada checklist. Mulai dari assessment security dan managed operations yang terarah.
Sumber utama: ServiceNow Support, CVE-2026-6875.
Urutan perubahan yang aman
Rencanakan perubahan sebagai rangkaian yang dapat dihentikan. Sebelum patch, pastikan backup konfigurasi, daftar dependency, kontak owner bisnis, dan kriteria sukses tercatat. Saat window dimulai, lakukan perubahan pada scope yang telah disetujui dan hindari memperluas hak akses hanya untuk mempercepat troubleshooting. Setelah patch, uji fungsi yang mewakili alur kerja penting: login admin, pembuatan ticket, integration yang berizin, dan alert yang dipakai tim operasi.
Jika smoke test gagal, gunakan rollback atau escalation path yang telah disepakati. Catat waktu, gejala, versi, dan keputusan. Catatan ini lebih berguna daripada kesimpulan umum bahwa patch berhasil karena membantu tim memahami perubahan pada environment berikutnya.
Monitoring setelah perubahan
Setelah maintenance, pantau error rate aplikasi, perubahan role, API calls, dan audit event yang relevan dengan instance tersebut. Tidak semua anomali adalah compromise, namun perubahan yang tidak memiliki owner atau tidak konsisten dengan workflow sebaiknya ditinjau. Hubungkan hasil review ke asset register dan backlog hardening agar tindakan tidak hilang setelah incident window selesai.
Untuk organisasi dengan banyak instance atau vendor integration, gunakan review berkala untuk memastikan account service, token, dan scope masih dibutuhkan. Pendekatan ini mengurangi risiko akses yang tetap aktif hanya karena tidak ada owner yang memutuskan untuk menutupnya.
Catatan untuk manajemen
Prioritas teknis perlu diterjemahkan menjadi keputusan yang dapat dijalankan: scope, owner, waktu perubahan, risiko layanan, dan bukti selesai. Hindari status selesai tanpa catatan versi, hasil uji, serta tindak lanjut yang memiliki penanggung jawab. Dengan cara ini, vulnerability response tetap membantu kontinuitas operasi sekaligus memperkuat kesiapan audit.
Rencana tindak lanjut dan ownership
Setelah perubahan awal selesai, buat tiket tindak lanjut yang menghubungkan owner platform, owner keamanan, dan owner layanan bisnis. Tulis keputusan yang dapat diuji: apakah scope sudah selesai, kontrol apa yang perlu dipantau, kapan review berikutnya, dan siapa yang menyetujui penutupan. Jika ditemukan celah proses, masukkan ke backlog dengan prioritas dan tanggal evaluasi. Pendekatan ini membuat patch response menjadi praktik operasional yang berulang, bukan tindakan satu kali saat berita muncul.
Untuk environment yang dikelola mitra, pastikan kontrak eskalasi, jam respons, dan bukti perubahan dipahami bersama. Jangan menganggap vendor atau provider otomatis melakukan semua tindakan tanpa receipt yang dapat diverifikasi.