# Cara membaca laporan pentest dan hasil retest Sumber diperiksa. Metode: https://kompli.id/metodologi/. Baca laporan mulai dari lingkup dan batas pemeriksaan, lalu hubungkan temuan dengan dampak pada layanan. Setiap tindak lanjut perlu pemilik, target, bukti perbaikan, dan hasil pengujian ulang. URL kanonis: https://kompli.id/panduan/keamanan/membaca-laporan-pentest/ Sumber diakses: 2026-09-28 Diperbarui: 2026-09-29 Penulis: Kompli Sumber diperiksa: 2026-09-29 ## 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](/panduan/keamanan/lingkup-pentest-website-api/). 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. **PT-01 · Ekspor pesanan memuat data perusahaan lain** Contoh fiktif Kompli. Baca satu temuan dari kondisi pengujian sampai bukti pengujian ulang. - **Lingkungan uji:** Aplikasi uji dengan versi yang dicatat; akun pelanggan perusahaan A dan B. - **Yang seharusnya terjadi:** Pelanggan A hanya dapat mengekspor pesanan A. - **Yang diamati:** Pengujian berizin dengan data fiktif menunjukkan pesanan B ikut terbaca. - **Dampak:** Pemisahan data pelanggan gagal pada fungsi ekspor yang diuji. - **Arah perbaikan:** Tim aplikasi memeriksa pembatasan akses di layanan ekspor dan alur lain yang memakai komponen sama. - **Bukti 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](https://wstg.owasp.org/v4.2/5-Reporting/). 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](/panduan/keamanan/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](/template/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](/panduan/keamanan/cve-cwe-cvss/). ## Sumber rujukan - [NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (2008)](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf) — Bagian 7.3–7.4 dan 8; analisis, penanganan data, pelaporan, dan perbaikan - [OWASP Web Security Testing Guide v4.2 — Reporting](https://wstg.owasp.org/v4.2/5-Reporting/) — Bagian 1.4–1.7, 2, dan 3; lingkup, batas, ringkasan, detail temuan, dan re-test - [FIRST — CVSS v4.0 User Guide](https://www.first.org/cvss/v4.0/user-guide) — CVSS Nomenclature; CVSS Base Score (CVSS-B) Measures Severity, not Risk ## Jalur belajar: Memahami pentest [Lihat urutan belajar](https://kompli.id/belajar/#memahami-pentest) ## Perlu membahas kebutuhan tim Anda? Ceritakan sistem yang ingin diuji, tujuan pengujian, dan rencana waktunya. [Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=pentest) ## Bacaan terkait - [Cara menentukan lingkup pentest website dan API](https://kompli.id/panduan/keamanan/lingkup-pentest-website-api/) - [Cara memilih vendor pentest dan membandingkan penawaran](https://kompli.id/panduan/keamanan/memilih-vendor-pentest/) - [Cara menyiapkan penanganan insiden data pribadi](https://kompli.id/panduan/keamanan/penanganan-insiden-data-pribadi/)