Contoh Laporan Pentest yang Baik:
Apa Saja Isinya?

Laporan yang panjang belum tentu berguna. Dokumen terbaik membuat pembaca memahami tiga hal: kontrol apa yang gagal, bagaimana kegagalan dibuktikan, dan tindakan apa yang perlu dilakukan. Semua klaim harus dapat ditelusuri kembali ke evidence.

1. Ringkasan Eksekutif

Ringkasan Eksekutif ditujukan kepada pengambil keputusan. Bagian ini menjelaskan aset yang diuji, periode, tujuan, pola risiko utama, batas pengujian, serta prioritas tindakan. Hindari menumpuk istilah teknis atau sekadar menghitung jumlah finding.

Ringkasan yang baik membedakan dampak yang benar-benar dijalankan dari blast radius yang hanya diturunkan. Jika tidak ada boundary crossing, hasil itu perlu dinyatakan sebagai sinyal, observasi, atau rekomendasi hardening—bukan vulnerability tervalidasi.

2. Ruang Lingkup dan Rules of Engagement

Laporan harus mencatat domain, aplikasi, API, environment, role, akun uji, data yang diizinkan, tanggal, teknik terlarang, rate limit, stop condition, dan kontak darurat. Tanpa batas ini, pembaca tidak dapat menilai apa yang sudah atau belum tercakup.

Daftar out-of-scope sama pentingnya. Misalnya social engineering, denial of service, pembayaran nyata, data pihak ketiga, atau integrasi vendor dapat dikecualikan. Ketiadaan pengujian pada area tersebut tidak boleh diterjemahkan sebagai “aman”.

3. Metodologi dan Evidence Standard

Metodologi sebaiknya menjelaskan bagaimana kandidat naik menjadi finding. CyberSecAudit menggunakan alur baseline sukses, satu mutasi, matched negative control, reproduksi, authoritative readback, eliminasi penjelasan benign, impact minimum, dan cleanup.

Standar ini membantu reviewer membedakan bukti discovery dari bukti impact. Reflection, error, timing, HTTP status, output model, atau tool-call JSON dapat menjadi sinyal, tetapi belum membuktikan keputusan server atau perubahan state.

4. Security Invariant

Setiap finding membutuhkan Security Invariant yang jelas:

Aktor mana boleh melakukan tindakan apa, terhadap objek mana, dalam state, konteks, dan waktu apa?

Untuk API, invariant dapat memuat actor, tenant, role, object, parent, operation, state, transport, dan lifecycle. Untuk payment, tambahkan amount, currency, processor, environment, expiry, dan single-use. Invariant membuat expected behavior dapat diperiksa.

5. Prasyarat

Prasyarat menentukan exploitability. Laporan harus menyatakan apakah penyerang memerlukan akun, role tertentu, object identifier, interaksi korban, network position, konfigurasi, atau state khusus. Prasyarat tidak boleh disembunyikan demi severity yang lebih tinggi.

Jika pengujian hanya menggunakan akun dan objek uji milik peneliti atau klien, nyatakan itu. Pembaca kemudian memahami bahwa impact dibuktikan tanpa mengakses data pengguna nyata.

6. Langkah Reproduksi

Langkah Reproduksi harus dapat diikuti reviewer berwenang dengan data uji yang sesuai. Urutannya perlu menunjukkan baseline, mutation, response, dan readback—bukan hanya satu request yang dianggap menarik.

Credential, cookie, token, PII, dan identifier sensitif harus disensor. Redaksi tidak boleh menghilangkan informasi yang diperlukan untuk memahami mekanisme.

7. Bukti Teknis

Bukti dapat berupa request/response teredaksi, screenshot, audit log, database canary, inbox penerima uji, inventory, ledger, atau before/after state. Pilih evidence paling otoritatif dan minimum yang cukup.

Untuk XSS, DOM atau origin-context execution lebih kuat daripada reflection. Untuk authorization, owner readback lebih kuat daripada HTTP 200. Untuk AI agent, tool execution dan API acceptance lebih kuat daripada respons chat. Untuk transaksi, ledger lebih kuat daripada toast “berhasil”.

8. Expected vs Actual

Bagian ini menempatkan bukti terhadap invariant. Expected menjelaskan kontrol yang seharusnya berlaku. Actual menjelaskan perilaku runtime yang direproduksi. Jangan menggunakan standar produk lain atau CVE sebagai pengganti expected behavior target.

9. Dampak dan Batas Klaim

Dampak harus konkret: unauthorized read, write, action, privilege, durable state, financial control, atau lifecycle failure. Severity tidak boleh melampaui dampak yang dibuktikan.

Batas klaim sama pentingnya. Bila hanya satu objek disposable yang diubah, jangan mengklaim penghapusan massal. Bila credential terbukti memiliki capability tertentu, blast radius lanjutan hanya boleh disebut jika jalurnya reachable dan tidak ada kontrol belum diuji yang memutus rantai.

10. Negative Controls dan Counterevidence

Negative control menunjukkan mekanisme bukan kebetulan. Contohnya: secret dengan satu karakter berbeda gagal, role pembanding ditolak, token revoked tidak berfungsi, object A berhasil tetapi object B yang tidak diizinkan ditolak, atau durable state tidak berubah walau respons 200.

Counterevidence juga perlu dipertahankan. Jika ledger tidak berubah, itu dapat membantah dugaan manipulasi saldo. Laporan yang jujur akan menutup kandidat tersebut sebagai NOT_FINDING, bukan memaksanya menjadi severity rendah.

11. Rekomendasi dan Remediation Blueprint

Rekomendasi harus menyasar trust decision yang gagal. “Validasi input” terlalu umum bila akar masalahnya object authorization. Rekomendasi yang baik menyebut server-side ownership check, permission terpisah, parameter-bound approval, credential lineage, cascade revocation, atau idempotency sesuai mekanisme.

Sertakan defense-in-depth bila berguna, tetapi pisahkan perbaikan akar masalah dari hardening tambahan. Developer perlu mengetahui kontrol mana yang wajib agar invariant pulih.

12. Cleanup dan Retest

Cleanup mencatat objek, marker, token, draft, atau konfigurasi yang dikembalikan. Untuk state-changing proof, verifikasi cleanup melalui sumber authoritative.

Retest menjalankan ulang reproduksi terhadap perbaikan. Hasil dapat berupa fixed, partially fixed, not fixed, atau tidak dapat diverifikasi beserta alasannya. Retest bukan sekadar menerima screenshot perubahan kode.

Checklist menilai contoh laporan vendor

• Apakah scope dan out-of-scope eksplisit?
• Apakah finding memiliki invariant dan prasyarat?
• Apakah baseline serta negative control terlihat?
• Apakah impact diverifikasi melalui state otoritatif?
• Apakah batas klaim dinyatakan?
• Apakah reproduksi dapat diikuti?
• Apakah credential dan data sensitif disensor?
• Apakah rekomendasi menyasar akar mekanisme?
• Apakah cleanup dan Retest dicatat?

Tanda laporan berkualitas rendah

Waspadai laporan yang hanya menyalin output scanner, menggunakan severity tanpa alasan, tidak memiliki bukti before/after, menyebut kemungkinan sebagai fakta, atau memberikan rekomendasi generik. Jumlah finding yang banyak tidak selalu berarti coverage atau kualitas lebih baik.

Temuan yang dibantah juga bukan kegagalan audit. Negative result yang terdokumentasi mempersempit ruang risiko dan mencegah remediasi yang salah sasaran.

Kesimpulan

Contoh Laporan Pentest yang Baik menghubungkan Security Invariant, Langkah Reproduksi, bukti teknis, Authoritative verification, dampak, batas klaim, perbaikan, cleanup, dan Retest. Dokumen harus berguna bagi pimpinan sekaligus cukup presisi untuk developer dan reviewer.