Banyak perusahaan merasa telah mengambil langkah besar dalam menjaga keamanan aplikasi setelah menyelesaikan penetration testing. Pengujian telah dilakukan, presentasi hasil telah disampaikan, dan laporan teknis telah diterima oleh manajemen. Namun, beberapa bulan kemudian, kerentanan yang sama masih berada di dalam sistem.

Masalahnya bukan selalu terletak pada kualitas pengujian. Dalam banyak kasus, laporan pentest berhenti sebagai dokumen yang tersimpan di folder internal, diteruskan melalui email, atau dicatat dalam spreadsheet yang tidak terhubung dengan pekerjaan tim development.

Padahal, laporan pentest tidak secara langsung mengurangi risiko. Dokumen tersebut hanya menunjukkan bagian sistem yang dapat disalahgunakan, dampak yang mungkin terjadi, dan rekomendasi perbaikan yang perlu dilakukan.

Risiko baru mulai berkurang ketika temuan tersebut diterjemahkan menjadi pekerjaan teknis, memiliki penanggung jawab, memperoleh prioritas, masuk ke development backlog, dikerjakan, dan divalidasi kembali.

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

Laporan Pentest Bukanlah Hasil Akhir

Salah satu kesalahpahaman yang masih sering terjadi adalah menganggap penyerahan laporan sebagai penanda bahwa proses penetration testing telah selesai sepenuhnya.

Dari sisi pelaksanaan proyek, pengujian mungkin memang telah berakhir. Namun, dari sisi manajemen risiko, pekerjaan baru saja dimulai.

Temuan seperti broken access control, SQL injection, Stored XSS, kelemahan autentikasi, konfigurasi yang tidak aman, atau kebocoran informasi tetap dapat dieksploitasi selama belum ada perubahan pada kode, konfigurasi, arsitektur, maupun kontrol keamanan.

Laporan hanya memberikan visibilitas. Laporan tidak dapat memperbaiki source code, mengubah aturan akses, memperbarui dependency, atau menutup endpoint yang rentan.

Karena itu, efektivitas penetration testing tidak seharusnya hanya diukur berdasarkan jumlah temuan atau kelengkapan dokumen. Pengukuran yang lebih relevan adalah seberapa banyak risiko yang berhasil ditindaklanjuti hingga benar-benar tertutup.

Perusahaan dapat memiliki laporan yang sangat rinci, tetapi tetap menyimpan risiko tinggi apabila tidak mempunyai proses remediasi vulnerability yang terhubung dengan aktivitas pengembangan.

Temuan Pentest Sering Berhenti di Antara Dua Tim

Tim security dan tim development biasanya bekerja dengan sudut pandang yang berbeda.

Pentester menjelaskan kelemahan berdasarkan skenario serangan. Laporan biasanya memuat nama vulnerability, tingkat keparahan, bukti eksploitasi, aset yang terdampak, risiko, serta rekomendasi perbaikan.

Sementara itu, developer membutuhkan informasi yang lebih operasional. Mereka perlu mengetahui komponen yang harus diubah, repository yang terkait, fungsi yang terdampak, akar masalah, dependensi, acceptance criteria, serta cara memastikan perbaikan telah berhasil.

Perbedaan tersebut menciptakan celah komunikasi.

Tim security merasa telah memberikan penjelasan yang memadai. Di sisi lain, tim development belum tentu dapat langsung mengubah penjelasan tersebut menjadi engineering task yang siap dikerjakan.

Ketika tidak ada proses penerjemahan yang jelas, temuan keamanan mudah berhenti sebagai informasi. Temuan tersebut diketahui, tetapi tidak pernah masuk ke sistem kerja yang digunakan sehari-hari oleh tim pengembang.

Menyalin Laporan ke Ticket Belum Tentu Menyelesaikan Masalah

Memindahkan isi laporan pentest ke aplikasi project management merupakan langkah awal yang baik. Namun, sekadar menyalin deskripsi dan rekomendasi belum cukup untuk menghasilkan backlog keamanan yang dapat dikerjakan.

Sebagai contoh, laporan dapat memberikan rekomendasi berikut:

Terapkan validasi input dan output encoding yang sesuai.

Rekomendasi tersebut benar dari sisi keamanan, tetapi masih terlalu umum untuk langsung dikerjakan. Developer perlu mengetahui input mana yang harus divalidasi, konteks output yang terdampak, komponen aplikasi yang harus diperbarui, serta pengujian apa yang harus dilakukan.

Backlog item yang lebih operasional dapat memuat pekerjaan berikut:

• mengidentifikasi seluruh halaman yang menampilkan input pengguna;
• menerapkan context-aware output encoding;
• memperbarui komponen template yang digunakan bersama;
• menambahkan unit test untuk karakter dan payload berbahaya;
• memastikan Content Security Policy tidak terganggu;
• menguji fungsi lain yang menggunakan komponen serupa;
• menyerahkan hasil perbaikan untuk proses retest.

Dengan struktur tersebut, tim development tidak hanya menerima informasi mengenai masalah. Mereka memperoleh pekerjaan yang dapat diestimasi, ditugaskan, diuji, dan diselesaikan.

Severity Tinggi Tidak Otomatis Menjadi Prioritas Pertama

Laporan pentest umumnya menggunakan tingkat keparahan seperti critical, high, medium, low, atau informational. Klasifikasi tersebut penting untuk memberikan gambaran awal mengenai besarnya risiko teknis.

Namun, tingkat keparahan tidak seharusnya menjadi satu-satunya dasar dalam menentukan urutan remediasi.

Temuan high pada aplikasi internal yang hanya dapat diakses melalui jaringan terbatas mungkin memiliki prioritas berbeda dari temuan medium pada aplikasi publik yang memproses data pelanggan.

Penentuan prioritas perlu mempertimbangkan beberapa konteks, antara lain:

• tingkat eksposur aplikasi;
• sensitivitas data;
• hak akses yang dibutuhkan penyerang;
• kemungkinan eksploitasi;
• fungsi bisnis sistem;
• jumlah pengguna yang terdampak;
• keberadaan kontrol pengganti;
• ketergantungan terhadap sistem lain;
• jadwal rilis;
• kompleksitas perbaikan.

Skor teknis memberikan sinyal, tetapi keputusan akhir tetap membutuhkan konteks bisnis.

Tanpa proses triage, perusahaan dapat menghabiskan kapasitas development untuk memperbaiki temuan yang kurang mendesak, sementara kelemahan yang lebih mudah dieksploitasi justru tertahan di dalam antrean.

Temuan yang Tidak Masuk Backlog Akan Kehilangan Pemilik

Kerentanan tanpa pemilik merupakan salah satu penyebab utama lambatnya remediasi.

Tim security dapat menganggap bahwa developer akan memperbaiki temuan. Developer menunggu product owner memasukkan pekerjaan ke sprint. Product owner belum memahami dampak bisnisnya. Sementara itu, manajemen mengira risiko telah ditangani karena laporan pentest sudah diterima.

Akhirnya, tidak ada pihak yang benar-benar memegang tanggung jawab.

Setiap temuan seharusnya memiliki setidaknya dua jenis kepemilikan.

Pertama, remediation owner, yaitu pihak yang bertanggung jawab melaksanakan perbaikan teknis.

Kedua, risk owner, yaitu pihak yang berwenang menerima, menunda, atau menentukan perlakuan terhadap risiko berdasarkan kepentingan bisnis.

Selain pemilik, setiap temuan juga perlu memiliki target penyelesaian, status pekerjaan, bukti implementasi, serta keputusan yang terdokumentasi apabila perbaikan belum dapat dilakukan.

Kerentanan yang tidak memiliki pemilik bukan sekadar masalah administrasi. Kondisi tersebut pada dasarnya menjadi keputusan tidak tertulis untuk mempertahankan risiko di dalam sistem.

Temuan Keamanan Harus Bersaing dengan Target Produk

Tim development tidak hanya menangani masalah keamanan. Mereka juga menghadapi permintaan fitur, bug pengguna, integrasi sistem, peningkatan performa, perubahan regulasi, technical debt, dan target peluncuran.

Karena itu, temuan pentest tidak otomatis dikerjakan hanya karena memiliki label high.

Instruksi seperti “mohon segera diperbaiki” biasanya tidak cukup. Tanpa alokasi kapasitas, target sprint, dan dukungan product owner, pekerjaan keamanan akan terus kalah oleh kebutuhan yang dianggap lebih dekat dengan pendapatan atau operasional.

Di sinilah keamanan perlu masuk ke proses pengelolaan produk.

Product owner perlu mendapatkan penjelasan mengenai dampak bisnis, bukan hanya istilah teknis. Tim security juga perlu memahami bahwa perbaikan dapat memiliki dependensi, membutuhkan perubahan arsitektur, atau berisiko mengganggu fungsi yang sedang berjalan.

Perusahaan dapat menyediakan kapasitas khusus untuk security remediation, menentukan security sprint, atau membuat jalur darurat untuk kerentanan kritis. Mekanismenya dapat berbeda, tetapi temuan harus memiliki tempat yang nyata dalam perencanaan development.

Cara Mengubah Temuan Pentest Menjadi Development Backlog

Melakukan Triage Bersama

Triage sebaiknya tidak dilakukan oleh tim security seorang diri. Proses tersebut perlu melibatkan pentester atau application security, technical lead, developer pemilik komponen, dan product owner.

Pertemuan triage digunakan untuk memastikan validitas temuan, memahami akar masalah, menentukan cakupan dampak, memilih strategi perbaikan, serta menyepakati prioritas.

Diskusi ini juga membantu mencegah dua kesalahan.

Kesalahan pertama adalah menurunkan prioritas hanya karena perbaikan dianggap sulit. Kesalahan kedua adalah meminta perubahan besar tanpa memahami konsekuensinya terhadap aplikasi.

Memecah Temuan Menjadi Pekerjaan yang Terukur

Satu laporan pentest tidak seharusnya dimasukkan sebagai satu ticket besar. Setiap temuan perlu dipecah menjadi pekerjaan yang dapat dikelola.

Dalam beberapa kasus, satu temuan bahkan dapat menghasilkan beberapa backlog item. Misalnya, satu masalah authorization dapat membutuhkan perubahan pada API, antarmuka pengguna, middleware, database, dan automated testing.

Ticket yang baik memiliki hasil akhir yang jelas. Pekerjaan tersebut dapat diestimasi, diberikan kepada tim tertentu, serta ditutup berdasarkan bukti yang objektif.

Menyertakan Konteks Teknis yang Memadai

Security ticket sebaiknya memuat:

• ringkasan kelemahan;
• aset atau fungsi yang terdampak;
• skenario serangan;
• bukti teknis;
• dampak terhadap bisnis;
• akar masalah awal;
• rekomendasi perbaikan;
• komponen yang perlu ditinjau;
• acceptance criteria;
• target penyelesaian;
• kebutuhan retest.

Informasi sensitif, seperti credential, token, atau data hasil pengujian, tetap perlu disimpan melalui mekanisme yang aman. Tidak seluruh bukti harus ditempatkan secara terbuka di dalam aplikasi project management.

Membedakan Perbaikan Sementara dan Akar Masalah

Perusahaan sering memilih perbaikan cepat untuk menurunkan eksposur. Langkah ini dapat diperlukan, khususnya untuk temuan kritis.

Namun, perbaikan cepat tidak selalu menyelesaikan akar masalah.

Memblokir satu payload tidak sama dengan memperbaiki mekanisme validasi. Menonaktifkan satu endpoint tidak sama dengan memperbaiki desain authorization. Mengubah satu konfigurasi server juga belum tentu memperbaiki baseline deployment yang digunakan oleh seluruh aplikasi.

Backlog perlu membedakan antara mitigation dan root-cause remediation.

Mitigation bertujuan mengurangi risiko dalam waktu dekat. Root-cause remediation bertujuan mencegah kelemahan yang sama muncul kembali pada komponen atau sistem lain.

Contoh Struktur Ticket Remediasi

Berikut contoh struktur ticket untuk temuan Stored XSS.

Judul

[High] Stored XSS pada Fitur Unggah Dokumen Pengguna

Deskripsi Masalah

Nama file yang diunggah oleh pengguna ditampilkan kembali pada halaman administrator tanpa output encoding yang sesuai.

Skenario Risiko

Pengguna dengan hak akses unggah dapat memasukkan nama file berisi script berbahaya. Payload dijalankan ketika administrator membuka halaman pengelolaan dokumen.

Komponen Terdampak

• modul unggah dokumen;
• halaman daftar dokumen;
• halaman pratinjau administrator;
• komponen antarmuka yang menampilkan nama file.

Dampak Bisnis

Eksploitasi dapat menyebabkan pencurian sesi administrator, manipulasi fungsi aplikasi, atau penyalahgunaan akses dengan hak istimewa lebih tinggi.

Rekomendasi Teknis

• menerapkan context-aware output encoding;
• membatasi karakter pada nama file;
• menyimpan file menggunakan nama internal yang dibuat sistem;
• meninjau seluruh fungsi lain yang menggunakan komponen tampilan serupa;
• menambahkan automated test untuk payload berbahaya.

Acceptance Criteria

• payload HTML dan JavaScript tidak dieksekusi;
• nama file ditampilkan sebagai teks biasa;
• pengujian mencakup beberapa variasi payload;
• fungsi unggah lain tidak menggunakan pola rentan yang sama;
• perbaikan berhasil melewati code review;
• temuan dinyatakan tertutup setelah retest.

Struktur seperti ini memberikan batas yang jelas antara temuan, pekerjaan, dan hasil yang harus dibuktikan.

Definition of Done Harus Memuat Validasi Keamanan

Developer dapat menyelesaikan perubahan kode, tetapi hal tersebut belum otomatis membuktikan bahwa kerentanan telah tertutup.

Security finding seharusnya tidak langsung dinyatakan selesai hanya karena perubahan sudah di-commit, berhasil di-build, atau diterapkan pada staging.

Definition of Done untuk temuan keamanan perlu mencakup:

• akar masalah telah ditangani;
• perubahan melewati code review;
• unit test atau regression test telah ditambahkan;
• komponen serupa telah diperiksa;
• perubahan telah diterapkan pada environment yang disepakati;
• bukti perbaikan terdokumentasi;
• pengujian ulang berhasil;
• status temuan diperbarui.

Tanpa validasi, perusahaan hanya mengubah status administratif. Risiko teknisnya belum tentu benar-benar berkurang.

Retest Bukan Formalitas Penutup

Retest diperlukan untuk memastikan bahwa jalur eksploitasi telah tertutup dan perbaikan tidak hanya bekerja pada satu payload yang tercantum dalam laporan.

Developer verification, regression testing, dan security retest memiliki tujuan berbeda.

Developer verification memastikan perubahan berjalan sesuai rancangan. Regression testing memastikan perubahan tidak merusak fungsi lain. Security retest memastikan kelemahan tidak lagi dapat dieksploitasi.

Retest juga dapat menemukan bypass. Sebuah input mungkin telah diperbaiki pada satu halaman, tetapi masih diproses secara tidak aman pada endpoint lain. Kontrol akses dapat bekerja melalui antarmuka pengguna, tetapi masih dapat dilewati dengan mengirimkan permintaan langsung ke API.

Oleh karena itu, status “fixed by developer” seharusnya menjadi awal tahap validasi, bukan dasar otomatis untuk menutup temuan.

Tidak Semua Temuan Harus Langsung Diperbaiki

Dalam kondisi tertentu, perusahaan mungkin belum dapat memperbaiki sebuah kerentanan karena keterbatasan teknologi, ketergantungan vendor, sistem lama, atau risiko gangguan operasional.

Penundaan dapat dilakukan, tetapi harus menjadi keputusan sadar dan terdokumentasi.

Risk acceptance sebaiknya memuat:

• pihak yang menyetujui;
• alasan penundaan;
• dampak yang masih tersisa;
• kontrol pengganti;
• batas waktu penerimaan risiko;
• jadwal evaluasi ulang;
• rencana perbaikan jangka panjang.

Tanpa batas waktu, risk acceptance dapat berubah menjadi tempat permanen bagi temuan yang sulit diselesaikan.

Risiko juga perlu ditinjau kembali ketika terjadi perubahan sistem, penambahan akses, integrasi baru, peningkatan jumlah pengguna, atau perubahan tingkat ancaman.

Metrik Pentest Harus Mengukur Pengurangan Risiko

Jumlah temuan bukan satu-satunya indikator keberhasilan penetration testing.

Banyaknya vulnerability yang ditemukan dapat menunjukkan cakupan pengujian yang luas. Namun, angka tersebut belum menjelaskan apakah organisasi mampu menindaklanjutinya.

Metrik yang lebih relevan mencakup:

• persentase temuan yang telah masuk backlog;
• waktu rata-rata dari pelaporan menuju triage;
• waktu rata-rata penyelesaian remediasi;
• persentase temuan yang melewati SLA;
• jumlah temuan tanpa pemilik;
• persentase perbaikan yang lolos retest;
• jumlah temuan berulang;
• usia security backlog;
• jumlah risk acceptance yang kedaluwarsa;
• persentase akar masalah yang telah ditangani.

Metrik tersebut membantu perusahaan melihat hambatan yang sebenarnya.

Masalah mungkin tidak terletak pada kemampuan menemukan vulnerability, melainkan pada proses persetujuan yang panjang, kapasitas developer yang terbatas, ownership yang tidak jelas, atau kualitas ticket yang belum memadai.

Temuan Berulang Menunjukkan Masalah yang Lebih Dalam

Apabila jenis kerentanan yang sama terus muncul pada setiap penetration testing, perusahaan tidak cukup hanya memperbaiki lokasi yang disebutkan di dalam laporan.

Temuan berulang biasanya menunjukkan adanya masalah sistemik.

Stored XSS yang muncul pada beberapa modul dapat menunjukkan belum adanya standar output encoding. Broken access control yang berulang dapat menunjukkan bahwa pemeriksaan hak akses diterapkan secara terpisah pada setiap fungsi. Penggunaan dependency rentan dapat menunjukkan belum adanya pengelolaan komponen pihak ketiga.

Dalam kondisi tersebut, hasil pentest seharusnya digunakan untuk memperbaiki proses pengembangan, bukan hanya satu bagian aplikasi.

Perusahaan dapat mengubah temuan menjadi:

• secure coding guideline;
• komponen keamanan yang dapat digunakan kembali;
• security requirement;
• checklist code review;
• automated security testing;
• quality gate pada CI/CD;
• materi pelatihan developer;
• pembaruan desain arsitektur.

Dengan pendekatan ini, satu temuan dapat menghasilkan perbaikan yang melindungi lebih dari satu aplikasi.

Pentest yang Baik Harus Mengubah Cara Sistem Dikembangkan

Penetration testing sering diposisikan sebagai aktivitas yang dilakukan menjelang audit atau peluncuran aplikasi. Pendekatan tersebut membuat pengujian terpisah dari proses development.

Akibatnya, temuan datang ketika roadmap telah penuh, arsitektur sulit diubah, dan tim sedang mengejar target rilis.

Pentest akan memberikan nilai yang lebih besar apabila hasilnya digunakan untuk memperkuat Secure SDLC.

Temuan mengenai hardcoded credential dapat mendorong penerapan secret scanning. Kelemahan security header dapat diubah menjadi baseline konfigurasi otomatis. Masalah authorization dapat mendorong penggunaan middleware terpusat. Dependency rentan dapat mendorong penerapan Software Composition Analysis.

Dengan demikian, hasil penetration testing tidak hanya memperbaiki kerentanan yang ditemukan hari ini. Hasil tersebut membantu mengurangi peluang munculnya kelemahan serupa pada pengembangan berikutnya.

Risiko Berkurang ketika Temuan Menjadi Perubahan Nyata

Nilai laporan pentest tidak terletak pada jumlah halaman, banyaknya bukti, atau tingkat keparahan yang tercantum di dalamnya.

Nilainya terletak pada perubahan yang dihasilkan.

Selama temuan belum mempunyai owner, prioritas, target waktu, acceptance criteria, dan proses retest, laporan tersebut baru membuktikan bahwa perusahaan mengetahui risikonya. Laporan itu belum membuktikan bahwa risiko sedang dikurangi.

Karena itu, proses penetration testing harus dihubungkan langsung dengan development backlog. Temuan keamanan perlu diperlakukan sebagai pekerjaan engineering yang memiliki konteks teknis dan bisnis.

Ketika hubungan tersebut berjalan dengan baik, pentest tidak lagi berhenti sebagai kewajiban audit. Pentest menjadi mekanisme yang membantu perusahaan memperbaiki kode, memperkuat arsitektur, meningkatkan proses pengembangan, dan mengurangi risiko secara terukur.

Tindak Lanjuti Temuan Keamanan Bersama Fourtrezz

Fourtrezz membantu perusahaan memahami dan menguji risiko keamanan pada aplikasi, API, jaringan, serta infrastruktur melalui layanan penetration testing dan vulnerability assessment.

Dengan pendekatan yang mempertimbangkan bukti teknis serta dampak terhadap bisnis, Fourtrezz dapat membantu perusahaan memperoleh gambaran keamanan yang lebih jelas. Layanan retest juga dapat digunakan untuk memvalidasi apakah perbaikan yang dilakukan telah menutup jalur eksploitasi yang sebelumnya ditemukan.

Selain pengujian keamanan, Fourtrezz menyediakan layanan cybersecurity dan IT development berbasis security mindset. Pendekatan ini membantu perusahaan menghubungkan kebutuhan pengembangan sistem dengan prinsip keamanan sejak tahap perencanaan, implementasi, hingga pengujian.

Bangun proses pengelolaan temuan yang tidak berhenti pada laporan. Jadikan setiap hasil penetration testing sebagai dasar untuk memperkuat aplikasi dan mengurangi risiko bisnis secara nyata.

Hubungi Fourtrezz:

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