Penetration testing atau pentest bukan hanya tentang menemukan celah keamanan pada sebuah sistem. Ada bagian lain yang tidak kalah penting: bagaimana hasil pengujian tersebut didokumentasikan dan dikomunikasikan.

Bayangkan sebuah pengujian keamanan menemukan 20 vulnerability pada website, API, aplikasi mobile, atau perangkat IoT. Secara teknis, jumlah tersebut mungkin terlihat mengesankan. Namun, jika laporan hanya berisi daftar vulnerability, screenshot yang tidak memiliki konteks, serta rekomendasi seperti “segera perbaiki sistem”, report tersebut belum tentu membantu pemilik sistem.

Tim developer masih harus mencari tahu vulnerability mana yang paling berbahaya. Tim security perlu menentukan prioritas. Sementara itu, management membutuhkan jawaban yang lebih sederhana: seberapa besar risikonya terhadap bisnis dan apa yang harus dilakukan?

Apa Itu Pentest Report?

Pentest report adalah dokumen yang merangkum proses, cakupan, hasil pengujian, temuan keamanan, bukti pengujian, tingkat risiko, dampak, serta rekomendasi perbaikan dari sebuah penetration testing.

Report menjadi bentuk dokumentasi resmi dari apa yang ditemukan selama pengujian. Namun, pentest report bukan sekadar “daftar bug”.

Sebuah vulnerability yang ditemukan perlu dijelaskan secara lengkap agar pembaca dapat memahami:

• Apa vulnerability yang ditemukan?
• Di mana vulnerability tersebut berada?
• Bagaimana vulnerability dapat dieksploitasi?
• Apa bukti bahwa vulnerability tersebut benar-benar ada?
• Seberapa besar risikonya?
• Apa dampaknya terhadap sistem atau bisnis?
• Bagaimana cara memperbaikinya?
• Bagaimana memastikan perbaikannya sudah efektif?

Mengapa Pentest Report yang Profesional Penting?

1. Mendokumentasikan Kondisi Keamanan

Report memberikan gambaran mengenai kondisi keamanan sistem pada saat pengujian dilakukan. Misalnya, sebuah aplikasi memiliki vulnerability berupa broken access control. Report mendokumentasikan lokasi vulnerability, metode pengujian, bukti, dampak, serta rekomendasi perbaikannya.

2. Membantu Menentukan Prioritas

Tidak semua vulnerability memiliki tingkat risiko yang sama. Sebuah vulnerability yang memungkinkan akses tidak sah terhadap database pelanggan tentu perlu mendapatkan perhatian berbeda dibandingkan masalah konfigurasi dengan dampak terbatas.

3. Membantu Tim Teknis Melakukan Remediation

Developer, system administrator, DevOps, maupun security engineer membutuhkan informasi teknis yang cukup untuk memahami akar masalah dan memperbaikinya. Karena itu, sebuah finding seharusnya tidak berhenti pada nama vulnerability.

4. Menjelaskan Risiko kepada Management

Management tidak selalu membutuhkan detail payload atau HTTP request. Mereka lebih membutuhkan informasi seperti apakah vulnerability dapat menyebabkan kebocoran data, seberapa besar kemungkinan dieksploitasi, sistem apa yang terdampak, dan apa prioritas perbaikannya.

Struktur Pentest Report yang Profesional

Tidak ada satu format pentest report yang wajib digunakan untuk seluruh jenis pengujian. Struktur laporan dapat menyesuaikan scope, metodologi, jenis sistem, dan kebutuhan organisasi.

Namun, secara umum, report profesional dapat terdiri dari beberapa bagian berikut.

1. Executive Summary

Executive Summary memberikan gambaran tingkat tinggi mengenai hasil penetration testing. Bagian ini terutama ditujukan untuk management, business owner, atau pihak lain yang tidak membutuhkan detail teknis.

Beberapa informasi yang dapat dimasukkan antara lain:

• tujuan pengujian;
• sistem yang diuji;
• periode pengujian;
• gambaran umum hasil;
• jumlah temuan berdasarkan severity;
• risiko utama;
• rekomendasi prioritas.

Executive Summary sebaiknya menjawab satu pertanyaan sederhana: “Apa yang perlu diketahui organisasi dari hasil pentest ini?”

2. Scope dan Methodology

Bagian ini menjelaskan apa yang diuji dan bagaimana pengujian dilakukan.

Informasi yang dapat dicantumkan meliputi:

• aplikasi atau sistem yang diuji;
• domain atau endpoint yang termasuk scope;
• API;
• mobile application;
• perangkat IoT;
• jaringan atau infrastruktur;
• environment yang digunakan;
• periode pengujian;
• pendekatan atau metodologi;
• batasan pengujian.

3. Summary of Findings

Setelah scope dan methodology, report dapat memberikan ringkasan seluruh vulnerability yang ditemukan.

Tabel seperti ini membantu pembaca mendapatkan gambaran kondisi keamanan secara cepat. Namun, angka tersebut tidak seharusnya menjadi satu-satunya informasi.

Sepuluh vulnerability Low tidak otomatis lebih berisiko daripada satu vulnerability Critical. Konteks sistem, kemungkinan eksploitasi, dampak, serta nilai aset yang terdampak tetap perlu dipertimbangkan.

Bagaimana Menulis Vulnerability Finding yang Baik?

Bagian vulnerability finding merupakan salah satu bagian terpenting dalam pentest report. Finding yang baik harus mampu menceritakan sebuah vulnerability secara utuh.

Secara sederhana, gunakan alur:

What — Apa masalahnya?

Jelaskan vulnerability yang ditemukan. Contohnya: aplikasi ditemukan memiliki kelemahan pada mekanisme authorization yang memungkinkan pengguna mengakses resource milik pengguna lain.

Where — Di mana masalahnya?

Cantumkan informasi aset yang terdampak, misalnya URL, endpoint API, parameter, fitur, aplikasi, device, atau service.

How — Bagaimana vulnerability ditemukan?

Jelaskan secara ringkas bagaimana pengujian dilakukan. Fokus pada langkah yang membantu pembaca memahami bagaimana vulnerability dapat diverifikasi.

Evidence — Apa buktinya?

Berikan bukti yang mendukung temuan. Evidence harus cukup untuk menunjukkan bahwa vulnerability benar-benar dapat diverifikasi.

Impact — Apa dampaknya?

Jelaskan konsekuensi jika vulnerability berhasil dieksploitasi.

Recommendation — Bagaimana memperbaikinya?

Berikan langkah remediation yang relevan dengan akar masalah.

Severity: Jangan Hanya Memberikan Label Critical, High, atau Medium

Label seperti Critical / High / Medium / Low membantu pembaca, tetapi label saja tidak cukup. Severity perlu memiliki dasar penilaian yang jelas.

Salah satu pendekatan yang umum digunakan adalah CVSS (Common Vulnerability Scoring System).

Dalam praktiknya, penilaian risiko dapat mempertimbangkan berbagai faktor seperti:

• seberapa mudah vulnerability dieksploitasi;
• apakah attacker membutuhkan authentication;
• apakah serangan dapat dilakukan dari jaringan eksternal;
• tingkat privilege yang diperoleh;
• jenis data yang dapat diakses;
• dampak terhadap confidentiality, integrity, dan availability.

Namun, penting membedakan antara severity teknis dan risiko bisnis. Sebuah vulnerability mungkin memiliki severity teknis Medium, tetapi jika berada pada sistem yang menangani proses bisnis sangat kritis, organisasi dapat memilih memberikan prioritas remediation yang lebih tinggi.

Evidence: Bukti Harus Jelas, Bukan Sekadar Banyak

Screenshot yang memenuhi halaman report tidak otomatis membuat report terlihat lebih profesional. Evidence seharusnya membantu pembaca memverifikasi dan memahami vulnerability.

Evidence dapat berupa:

• screenshot;
• HTTP request dan response;
• endpoint;
• parameter;
• hasil command;
• log;
• PoC;
• informasi konfigurasi yang relevan.

Tester juga perlu memperhatikan informasi sensitif dalam evidence. Data seperti credential, token, personal data, API key, atau informasi internal sebaiknya disamarkan apabila tidak diperlukan untuk tujuan dokumentasi.

Jangan Berhenti di Finding: Jelaskan Impact

Salah satu pembeda antara report biasa dan report yang lebih profesional adalah cara menjelaskan impact.

Misalnya, menemukan vulnerability SQL Injection merupakan sebuah technical finding. Tetapi report yang baik tidak berhenti pada “SQL Injection ditemukan pada endpoint X.” Pembaca perlu mengetahui konsekuensinya.

Secara teknis, vulnerability tersebut mungkin memungkinkan attacker melakukan manipulasi query database atau mengakses data yang seharusnya tidak dapat diakses.

Dalam konteks bisnis, dampaknya dapat berkaitan dengan:

• paparan data pelanggan;
• manipulasi informasi;
• gangguan layanan;
• kerugian operasional;
• reputational risk;
• regulatory atau compliance concern.

Jangan melebih-lebihkan dampak yang tidak dapat dibuktikan. Report profesional harus tetap objektif.

Technical Impact vs Business Impact

Technical impact menjelaskan apa yang terjadi pada sistem. Business impact menjelaskan mengapa hal tersebut penting bagi organisasi.

Cara Menulis Remediation Recommendation yang Actionable

Setelah vulnerability ditemukan, pertanyaan terpenting berikutnya adalah: “Bagaimana cara memperbaikinya?”

Hindari rekomendasi yang terlalu umum seperti “Segera perbaiki vulnerability.” Recommendation seperti ini tidak memberikan cukup informasi kepada tim teknis.

Recommendation sebaiknya mengarah pada akar masalah. Misalnya, jika vulnerability terjadi karena aplikasi tidak melakukan authorization check pada setiap request, rekomendasi dapat mengarahkan developer untuk menerapkan server-side authorization dan memastikan setiap akses terhadap resource diverifikasi berdasarkan identity serta privilege pengguna.

Recommendation yang baik sebaiknya:

• spesifik;
• relevan dengan vulnerability;
• actionable;
• mempertimbangkan akar masalah;
• sesuai dengan arsitektur sistem.

Bagaimana Menentukan Prioritas Remediation?

Setelah seluruh finding ditulis, organisasi masih harus menentukan: “Mana yang harus diperbaiki terlebih dahulu?”

Vulnerability yang memiliki severity tinggi, dapat dieksploitasi dari internet, tidak membutuhkan authentication, dan berada pada sistem yang menyimpan data sensitif umumnya layak mendapatkan prioritas tinggi.

Dengan pendekatan tersebut, organisasi tidak sekadar mengejar jumlah vulnerability yang ditutup, tetapi berusaha mengurangi risiko yang paling signifikan terlebih dahulu.

Bagaimana dengan Sistem IoT?

Prinsip pentest report pada IoT pada dasarnya sama, tetapi scope-nya dapat lebih kompleks karena IoT terdiri dari beberapa komponen yang saling terhubung.

Sebuah ekosistem IoT dapat melibatkan:

Kerentanan pada satu komponen dapat berdampak pada komponen lain. Misalnya, kelemahan authentication pada API bukan hanya menjadi masalah API. Jika API tersebut mengendalikan fungsi penting pada perangkat IoT, vulnerability tersebut berpotensi memberikan dampak lebih luas terhadap ekosistem.

Karena itu, pentest report untuk IoT sebaiknya menjelaskan:

• komponen yang terdampak;
• hubungan antar-komponen;
• attack path yang relevan;
• dampak terhadap device maupun backend;
• rekomendasi perbaikan pada komponen yang menjadi akar masalah.

Kesalahan yang Sering Terjadi dalam Pentest Report

Executive Summary vs Technical Finding: Siapa yang Membaca?

Artinya, satu report dapat memiliki beberapa tingkat informasi. Management tidak perlu membaca setiap HTTP request. Sebaliknya, developer membutuhkan detail yang cukup untuk memahami dan memperbaiki vulnerability.

Setelah Remediation, Jangan Lupakan Retest

Pentest report bukan akhir dari proses keamanan. Setelah organisasi melakukan remediation, langkah berikutnya adalah memastikan bahwa vulnerability memang sudah diperbaiki.

Di sinilah retest berperan.

Retest digunakan untuk memverifikasi apakah perbaikan yang dilakukan sudah efektif. Misalnya, sebuah vulnerability ditemukan pada endpoint API. Setelah developer melakukan perubahan, tester dapat melakukan pengujian ulang untuk memastikan metode eksploitasi sebelumnya tidak lagi berhasil.

Scope retest biasanya berfokus pada vulnerability yang telah diperbaiki dan area yang relevan dengan perubahan tersebut.

Checklist Pentest Report yang Profesional

Sebelum report diselesaikan, gunakan checklist berikut:

• Tujuan pengujian jelas
• Scope terdokumentasi
• Environment dijelaskan
• Methodology dijelaskan
• Executive Summary tersedia
• Setiap finding memiliki judul jelas
• Severity memiliki dasar penilaian
• Evidence tersedia
• Technical impact dijelaskan
• Business impact dijelaskan
• Recommendation actionable
• Prioritas remediation jelas
• Informasi sensitif disamarkan
• Retest dapat dilakukan berdasarkan report

Pentest Report yang Baik Bukan yang Paling Tebal

Report yang profesional tidak selalu berarti report yang paling panjang. Report yang terlalu pendek dapat kehilangan informasi penting. Sebaliknya, report yang terlalu panjang dapat membuat pembaca kesulitan menemukan informasi yang paling penting.

Ukuran kualitasnya bukan pada jumlah halaman, tetapi pada apakah report mampu menjawab pertanyaan utama:

Jika pertanyaan tersebut dapat dijawab dengan jelas, terstruktur, dan berdasarkan bukti, maka report sudah menjalankan fungsi utamanya.

Pada akhirnya, pentest bukan sekadar aktivitas untuk menemukan vulnerability. Nilai sebenarnya muncul ketika hasil pengujian dapat dipahami, diprioritaskan, diperbaiki, dan diverifikasi kembali.

FAQ Pentest Report