Cara membaca laporan pentest dan hasil retest

Mulai dari lingkup, bukan jumlah temuan

Laporan pentest membantu tim memahami kelemahan yang ditemukan dan pekerjaan perbaikannya. Sebelum melihat jumlah temuan tinggi atau rendah, periksa apa yang diuji, kapan pengujian dilakukan, serta bagian yang tidak dapat diperiksa.

Cocokkan alamat aset, versi atau lingkungan, fitur, dan akses penguji dengan lingkup yang disepakati. Laporan yang hanya mencakup halaman publik tidak menjawab keamanan fitur admin atau seluruh API, yaitu antarmuka pertukaran data aplikasi.

Hasil tanpa temuan bukan jaminan bebas celah. Perubahan setelah pengujian juga dapat memengaruhi kesimpulan. Catat keterbatasan ini saat memakai laporan untuk keputusan peluncuran atau permintaan pelanggan.

Apa yang harus bisa dipahami dari satu temuan?

Periksa identitas temuan, aset yang terkena, kondisi saat masalah muncul, bukti, dampak, dan saran perbaikan. Informasi tersebut perlu cukup jelas untuk ditindaklanjuti tim teknis. Data pribadi dan rahasia dalam bukti perlu disamarkan.

Contoh fiktif Kompli. Baca satu temuan dari kondisi pengujian sampai bukti pengujian ulang.

01Lingkungan uji

Aplikasi uji dengan versi yang dicatat; akun pelanggan perusahaan A dan B.

02Yang seharusnya terjadi

Pelanggan A hanya dapat mengekspor pesanan A.

03Yang diamati

Pengujian berizin dengan data fiktif menunjukkan pesanan B ikut terbaca.

04Dampak

Pemisahan data pelanggan gagal pada fungsi ekspor yang diuji.

05Arah perbaikan

Tim aplikasi memeriksa pembatasan akses di layanan ekspor dan alur lain yang memakai komponen sama.

06Bukti retest

Catat versi perbaikan, akun, skenario yang diperiksa kembali, dan hasilnya.

Ini bukan hasil pengujian sistem nyata. Tiket perbaikan yang ditutup belum membuktikan bahwa perbaikan telah terverifikasi.

Rujukan: OWASP WSTG 4.2, bagian 3.

Dalam laporan sebenarnya, penguji perlu menyertakan bukti yang memadai melalui jalur terbatas. Contoh ini sengaja tidak memuat langkah eksploitasi atau angka tingkat keparahan yang seolah sudah dihitung.

Bagaimana memakai skor CVSS?

CVSS, singkatan dari Common Vulnerability Scoring System, membantu menyampaikan karakteristik dan tingkat keparahan kerentanan. Jika laporan memakainya, minta versi, nilai metrik atau vektor penilaian, dan alasan skornya; jangan membandingkan angka tanpa konteks.

FIRST menjelaskan bahwa skor dasar CVSS tidak cukup, sendirian, untuk menilai risiko. Lingkungan penggunaan dan keadaan ancaman juga perlu dipertimbangkan. Panduan versi 4.0 membedakan penilaian dasar, ancaman, dan lingkungan; halaman ini tidak menghitung ulang skor atau mewajibkan semua laporan memakai versi tersebut.

Untuk memutuskan urutan kerja, bahas juga data yang terpapar, keterjangkauan fitur, pengguna yang terdampak, pengamanan yang sudah ada, serta tanda penyalahgunaan. Sebagai contoh, temuan pada fitur ekspor pelanggan yang segera diluncurkan memerlukan keputusan sebelum fitur dibuka. Ini contoh keputusan tim, bukan tenggat hukum atau rumus prioritas universal.

Bagaimana mencatat tindak lanjut?

Buat catatan untuk setiap ID temuan. Contoh format kerja Kompli:

Temuan: PT-01
Pemilik pekerjaan: [nama penanggung jawab di tim aplikasi]
Tindakan sementara: akses fitur dibatasi sesuai keputusan pemilik layanan
Perbaikan: pembatasan akses diperbaiki dan diuji pada alur terkait
Target: tanggal yang disepakati berdasarkan risiko dan ketergantungan pekerjaan
Bukti: tiket perubahan, versi yang dipasang, dan hasil pemeriksaan
Status: menunggu pengujian ulang; belum ditutup

Jika perbaikan ditunda, catat alasan, pengamanan sementara, pihak yang menyetujui, dan tanggal peninjauan berikutnya. Keputusan menerima risiko tidak sama dengan memperbaiki kelemahan. Hindari mengganti status menjadi selesai hanya karena tiket pengembang ditutup.

Apa arti hasil retest?

Retest berarti pengujian ulang setelah perbaikan. Minta hasil yang merujuk ID temuan sebelumnya, mencatat versi atau lingkungan yang diperiksa, serta menjelaskan hasil dan batasnya.

Untuk catatan internal, tim dapat membedakan “perbaikan terverifikasi”, “masih ditemukan”, “sebagian diperbaiki”, dan “belum diuji ulang”. Ini contoh label; sepakati arti setiap status dengan penguji. Bagian yang belum diuji ulang tidak boleh dilaporkan sebagai perbaikan terverifikasi.

Retest pada satu temuan tidak otomatis mengulang seluruh pentest. Perubahan besar atau masalah baru mungkin memerlukan perluasan lingkup yang disepakati terpisah. Simpan laporan awal, perubahan, dan hasil retest agar riwayatnya tetap jelas.

Kapan perlu eskalasi?

Temuan mendesak perlu disampaikan melalui kontak yang sudah disepakati selama pengujian. Bila bukti mengarah pada akses tanpa izin atau kejadian nyata, gunakan rencana penanganan insiden data pribadi untuk menilai langkah berikutnya. Temuan pentest tidak otomatis membuktikan sudah terjadi kebocoran, dan retest tidak menggantikan penanganan insiden.

Batasi penerima laporan lengkap. Jika pelanggan memerlukan bukti, sepakati informasi yang boleh dibagikan dan batas penggunaan laporan. NIST, OWASP, dan FIRST di sini mendukung praktik teknis; bukan penetapan kepatuhan hukum perusahaan.

Lihat laporan terisi dan istilahnya

Gunakan contoh laporan pentest untuk mengikuti satu dokumen dari izin pengujian sampai retest. Contoh memakai dua temuan fiktif, mempertahankan ID yang sama, dan memisahkan perbaikan terverifikasi dari pekerjaan tersisa. Untuk membedakan pengenal, jenis kelemahan, serta tingkat keparahan, baca CVE, CWE, dan CVSS.