Laporan pentest sudah diterima. Temuan berisiko tinggi telah diperbaiki, pengujian ulang menunjukkan hasil yang baik, dan aplikasi mendapat persetujuan untuk diluncurkan. Pada titik ini, pertanyaan tentang keamanan sering dianggap selesai.

Padahal, ada satu hal yang belum tentu terjawab: apakah aplikasi yang akan digunakan pelanggan berjalan dalam kondisi yang sama dengan aplikasi yang diuji?

Pertanyaan tersebut menentukan seberapa jauh hasil pentest di staging dapat dijadikan dasar untuk menilai keamanan aplikasi di production. Ketika versi, konfigurasi, jalur akses, atau integrasinya berbeda, sebagian kesimpulan pengujian perlu diperiksa kembali.

Perusahaan tetap membutuhkan pentest staging. Namun, keputusan peluncuran akan lebih kuat jika disertai bukti bahwa kondisi penting yang sudah diuji benar-benar berlaku pada sistem operasional.

Laporan Pentest Memiliki Batas yang Perlu Dibaca

Hasil penetration testing menggambarkan pengujian terhadap target tertentu, dalam periode tertentu, dengan akses dan skenario yang disepakati. Karena itu, laporan selalu memiliki batas cakupan.

Jika pengujian dilakukan terhadap aplikasi staging dengan dua akun pengguna, hasilnya berkaitan dengan kondisi tersebut. Laporan itu belum otomatis mencakup seluruh role di production, integrasi yang hanya aktif setelah peluncuran, atau endpoint yang tidak tersedia saat pengujian.

Begitu pula dengan tidak ditemukannya kerentanan tertentu. Kesimpulan tersebut menunjukkan bahwa kerentanan tidak teridentifikasi dalam cakupan dan metode pengujian yang digunakan. Kesimpulannya tidak dapat diperluas menjadi jaminan bahwa aplikasi bebas dari seluruh celah keamanan.

Persoalan muncul ketika batas ini hilang dalam komunikasi internal. Pernyataan “aplikasi sudah menjalani pentest” kemudian dipahami sebagai “semua kondisi aplikasi sudah diperiksa”.

Bagi manajemen, perbedaan makna tersebut dapat memengaruhi keputusan go-live, penerimaan risiko, dan penentuan kebutuhan pengujian tambahan.

Kode yang Sama Bisa Berjalan dengan Perlindungan Berbeda

Kesamaan kode sumber sering menjadi alasan untuk menganggap staging cukup mewakili production. Padahal, perilaku keamanan aplikasi juga dipengaruhi oleh lingkungan tempat kode tersebut berjalan.

Staging mungkin hanya dapat diakses melalui VPN. Production dibuka melalui internet dan melewati CDN, reverse proxy, serta layanan lain. Perbedaan ini dapat mengubah jalur akses, pemrosesan request, dan layanan yang terlihat dari luar.

Konfigurasi browser juga perlu diperhatikan. Pengaturan cookie, CORS, dan HTTP Security Headers dapat berbeda karena domain maupun kebutuhan integrasi. Konfigurasi yang benar di staging belum membuktikan pengaturan yang sama telah diterapkan pada domain production.

Hal serupa berlaku untuk endpoint administratif, mode debug, penyimpanan berkas, dan hak akses layanan. Perubahan pada komponen tersebut dapat menambah risiko meskipun kode aplikasinya tidak berubah.

OWASP Web Security Testing Guide menempatkan konfigurasi infrastruktur dan deployment sebagai bagian dari pengujian keamanan aplikasi. Panduan tersebut menunjukkan bahwa penilaian keamanan perlu mencakup cara aplikasi diterapkan dan dilindungi oleh lingkungan pendukungnya.

Perbedaan lingkungan memang tidak selalu menghasilkan kerentanan. Namun, perusahaan perlu mengetahui perbedaan mana yang relevan terhadap hasil pentest, kemudian memvalidasinya.

Integrasi Production Dapat Mengubah Skenario Serangan

Bayangkan sebuah aplikasi pengadaan perusahaan. Saat diuji di staging, aplikasi menggunakan layanan simulasi untuk autentikasi dan pengiriman dokumen. Di production, aplikasi terhubung ke SSO perusahaan, penyimpanan bersama, dan sistem persetujuan internal.

Pengujian staging dapat menemukan celah pada fungsi pengadaan. Namun, hubungan kepercayaan antara aplikasi dan layanan aktif belum tentu terwakili.

Apakah identitas dari SSO dipetakan ke role yang tepat? Apakah akun layanan hanya memiliki izin yang dibutuhkan? Apakah dokumen tetap memerlukan pemeriksaan otorisasi ketika diakses melalui layanan penyimpanan?

Jawabannya bergantung pada implementasi integrasi yang benar-benar digunakan.

Karena itu, kesamaan tampilan dan fitur belum cukup untuk membuktikan kesetaraan keamanan. Dua lingkungan dapat terlihat identik bagi pengguna, tetapi memiliki mekanisme autentikasi, kredensial, serta hubungan antarsistem yang berbeda.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Akun Pengujian Menentukan Risiko yang Bisa Diperiksa

Keterbatasan representasi juga dapat muncul dari akun yang disediakan selama pentest aplikasi web.

Dua akun dengan role yang sama mungkin memadai untuk memeriksa sebagian akses antarpengguna. Namun, keduanya belum tentu cukup untuk menguji batas kewenangan antara staf, supervisor, administrator, dan mitra.

Pada aplikasi multi-tenant, pengujian perlu mempertimbangkan pemisahan akses antarorganisasi. Pada sistem persetujuan, penguji perlu memahami siapa yang dapat membuat, mengubah, menyetujui, atau membatalkan transaksi.

Penelitian Testing Access-Control Configuration Changes for Web Applications oleh Chengcheng Xiang dan rekan-rekannya, yang tersedia sebagai preprint pada 2025, membahas perlunya pengujian sistematis terhadap perubahan konfigurasi kontrol akses. Fokusnya relevan dengan persoalan ini: perubahan kebijakan akses dapat mengubah request yang diizinkan atau ditolak.

Staging tidak harus menggunakan salinan data pelanggan agar pengujiannya bermakna. Data sintetis dapat digunakan selama hubungan kepemilikan, variasi role, dan batas aksesnya mewakili skenario yang perlu diperiksa.

Yang menentukan adalah kualitas representasi skenario, bukan banyaknya data yang tersedia.

Retest di Staging Belum Membuktikan Perbaikan Sudah Terpasang

Perusahaan juga perlu membedakan keberhasilan perbaikan dengan keberhasilan penerapannya.

Sebagai ilustrasi, developer memperbaiki pemeriksaan otorisasi pada endpoint dokumen. Retest di staging memastikan pengguna tidak lagi dapat mengakses dokumen milik akun lain.

Namun, jika salah satu instance production masih menjalankan versi lama, risiko tersebut tetap ada pada instance itu. Laporan retest tidak keliru; lingkungan production belum sepenuhnya menerapkan perbaikan yang telah diverifikasi.

Kondisi serupa dapat terjadi ketika perbaikan membutuhkan perubahan konfigurasi, pembaruan izin, atau penonaktifan endpoint. Pembaruan kode saja belum tentu menyelesaikan seluruh penyebab temuan.

OWASP menekankan perlunya memeriksa perubahan setelah diterapkan dari lingkungan QA ke production untuk memastikan keamanan tidak terpengaruh. Verifikasi ini perlu menjadi bagian dari proses pengelolaan perubahan.

Dengan demikian, penutupan temuan sebaiknya mencakup kejelasan tentang apa yang diperbaiki, di mana perbaikannya diuji, dan bagaimana penerapannya pada lingkungan operasional diverifikasi.

Validasi Production Perlu Mengikuti Risiko Operasional

Kebutuhan memeriksa production sering menimbulkan kekhawatiran yang wajar. Sistem sudah melayani pengguna, menyimpan data penting, dan mendukung transaksi bisnis. Aktivitas pengujian harus mempertimbangkan kondisi tersebut.

Pendekatannya dapat disusun berdasarkan perbedaan yang ditemukan antara staging dan production.

Pengujian mendalam terhadap fungsi aplikasi dapat dilakukan di staging. Sementara itu, pemeriksaan di production difokuskan pada aspek yang membutuhkan bukti dari lingkungan aktif, seperti konfigurasi domain, jalur akses, integrasi autentikasi, paparan endpoint, dan penerapan perbaikan.

Cakupannya perlu disepakati secara tertulis. Akun uji, transaksi yang diperbolehkan, waktu pelaksanaan, batas aktivitas, serta kondisi penghentian membantu tim teknis menjaga pengujian tetap terkendali.

Tujuannya adalah mendapatkan bukti tambahan yang relevan dengan risiko, tanpa menganggap semua aktivitas pentest harus diulang dengan intensitas yang sama.

Keputusan Go-Live Memerlukan Bukti yang Lebih Tepat

Sebelum menjadikan hasil pentest staging sebagai dasar peluncuran, perusahaan perlu menjawab beberapa pertanyaan:

• Apakah versi aplikasi yang diuji sama dengan versi yang diterapkan?
• Apakah konfigurasi keamanan yang relevan sudah dibandingkan?
• Apakah role, integrasi, dan fitur aktif di production telah terwakili?
• Apakah seluruh perbaikan sudah diterapkan pada instance yang melayani pengguna?
• Perbedaan apa yang masih belum diuji, dan bagaimana risikonya ditangani?

Jawaban tersebut membantu manajemen memahami bagian yang sudah diperiksa dan bagian yang masih membutuhkan perhatian.

Jumlah temuan tetap penting, tetapi relevansi bukti terhadap kondisi operasional jauh lebih menentukan. Laporan dengan sedikit temuan tidak memberikan gambaran yang memadai jika komponen penting production berada di luar cakupan.

Pastikan Hasil Pentest Relevan dengan Sistem yang Dioperasikan

Pentest staging memberikan kesempatan untuk menemukan dan memperbaiki celah sebelum aplikasi digunakan secara luas. Manfaatnya akan lebih besar ketika perusahaan menjaga kesesuaian lingkungan dan memeriksa perubahan yang memengaruhi keamanan.

Keputusan go-live sebaiknya bertumpu pada pemahaman yang jelas tentang cakupan pengujian, penerapan perbaikan, dan risiko yang masih tersisa. Dengan dasar tersebut, laporan pentest dapat digunakan sebagai bukti teknis yang relevan untuk keputusan bisnis.

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk membantu perusahaan mengidentifikasi serta menilai kerentanan keamanan. Perusahaan dapat memulai kerja sama dengan mendiskusikan target, lingkungan pengujian, dan kebutuhan operasional agar ruang lingkup pemeriksaan sesuai dengan sistem yang digunakan.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]