Memilih Jasa Pembuatan Sistem: Bukti Uji Keamanan

Ketika membandingkan jasa pembuatan sistem, calon pembeli sering menerima pernyataan bahwa aplikasi akan dibuat aman. Namun, kata “aman” saja belum menjelaskan bagian apa yang diperiksa, bagaimana hasilnya dicatat, atau apa yang terjadi bila ditemukan kelemahan. Sebelum menandatangani penerimaan sistem custom, mintalah kesepakatan yang membuat proses verifikasi dan tindak lanjut dapat dipahami kedua pihak.

Panduan ini bukan pengganti pengujian keamanan profesional dan tidak menyatakan bahwa setiap proyek membutuhkan metode atau sertifikasi yang sama. Tujuannya membantu pemilik bisnis, tim operasional, dan pengadaan mengajukan pertanyaan yang jelas, membandingkan penawaran secara setara, serta mengetahui bukti apa yang perlu dibahas sebelum serah terima.

Apa arti pengujian keamanan dalam penawaran jasa pembuatan sistem?

Pengujian keamanan bukan satu aktivitas tunggal. Cakupannya dapat berbeda menurut jenis aplikasi, data yang diproses, arsitektur, lingkungan, dan risiko bisnis. Karena itu, dua vendor yang sama-sama menulis “security testing” belum tentu menawarkan pekerjaan yang sebanding.

Bedakan tiga hal berikut:

• Klaim: pernyataan umum, misalnya sistem dirancang dengan memperhatikan keamanan.
• Ruang lingkup: komponen, fungsi, lingkungan, dan jenis pemeriksaan yang memang disepakati.
• Bukti dan tindak lanjut: catatan hasil, keterbatasan, temuan, keputusan perbaikan, dan pemeriksaan ulang bila disepakati.

Minta vendor menjelaskan istilah yang mereka gunakan dengan bahasa yang dapat dipahami pemilik produk. Jangan menganggap satu pemindaian otomatis memeriksa semua risiko, atau bahwa tidak ditemukannya temuan berarti sistem bebas risiko.

Cara membandingkan verifikasi keamanan vendor

1. Pastikan sistem dan bagian yang diuji disebutkan

Tanyakan apakah pemeriksaan mencakup aplikasi web, API, panel administrasi, alur autentikasi, integrasi pihak ketiga, atau komponen lain yang relevan. Pastikan pula batas lingkungan uji: misalnya lingkungan staging atau versi tertentu. Apabila ada modul atau fungsi yang dikecualikan, minta pengecualian itu ditulis secara eksplisit.

Ruang lingkup yang konkret membantu menghindari salah paham. Sebuah pemeriksaan mungkin hanya mencakup satu aplikasi dan satu versi, bukan infrastruktur hosting atau layanan pihak ketiga. Jangan mengasumsikan bagian yang tidak disebutkan ikut diuji.

2. Tanyakan metode dan siapa yang menjalankannya

Minta penjelasan ringkas mengenai pendekatan verifikasi: pemeriksaan otomatis, peninjauan manual, uji pada alur tertentu, atau kombinasi yang relevan. Tanyakan siapa pelaksananya dan apakah pemeriksaan dilakukan sebagai bagian dari pengembangan atau oleh pihak independen. Tidak ada satu jawaban yang selalu tepat untuk semua proyek; yang penting, peran, batas, dan hasil yang dijanjikan transparan.

Untuk menyusun persyaratan, organisasi dapat mempertimbangkan kerangka seperti OWASP Application Security Verification Standard (ASVS) sebagai bahan acuan tingkat verifikasi. Penggunaannya perlu disesuaikan dengan risiko dan disepakati dalam konteks proyek. Menyebut ASVS tidak dengan sendirinya berarti sistem tersertifikasi, seluruh kontrol telah dipenuhi, atau keamanan terjamin.

3. Samakan dasar perbandingan antarpenawaran

Gunakan pertanyaan yang sama kepada setiap calon vendor. Jangan membandingkan penawaran yang satu hanya menyebut “uji keamanan” dengan penawaran lain yang merinci objek dan keluaran tanpa meminta klarifikasi.

Bukti yang perlu dibahas sebelum serah terima

Bukti tidak harus berupa dokumen tebal. Bentuk dan tingkat detailnya perlu disepakati sesuai kebutuhan organisasi, sensitivitas data, serta kontrak. Yang penting, pembeli dapat memahami apa yang diperiksa dan apa yang belum termasuk.

Ringkasan ruang lingkup dan hasil

Minta catatan yang menunjukkan versi atau lingkungan yang diperiksa, tanggal atau tahap pelaksanaan, area yang termasuk, dan batas pemeriksaan. Ringkasan hasil sebaiknya membedakan temuan dari risiko yang belum diperiksa. Hindari menerima kalimat “lulus semua” tanpa penjelasan tentang kriteria dan cakupan yang mendasarinya.

Daftar temuan dan keputusan

Jika ada temuan, tanyakan bagaimana temuan dideskripsikan, siapa yang menilai prioritasnya, dan bagaimana keputusan penanganan dicatat. Tidak semua temuan berarti harus ditangani dengan cara yang sama, tetapi keputusan menerima, memperbaiki, atau menunda perlu memiliki alasan dan penanggung jawab yang jelas. Risiko yang tersisa sebaiknya tidak hilang dari catatan serah terima.

Bukti tindak lanjut dan pemeriksaan ulang

Jika perbaikan termasuk dalam lingkup, sepakati bagaimana perubahan diverifikasi. Tanyakan apakah pemeriksaan ulang mencakup temuan yang diperbaiki saja atau bagian lain yang mungkin terdampak. Jangan menganggap perubahan telah diverifikasi hanya karena kode sudah diperbarui; mintalah bukti sesuai proses yang disepakati.

Masukkan persyaratan keamanan ke proses pengadaan

Semakin awal kebutuhan penerimaan dibicarakan, semakin kecil kemungkinan istilah keamanan baru muncul di akhir proyek tanpa definisi bersama. Dalam dokumen kebutuhan atau kontrak, pertimbangkan untuk memperjelas:

1. Bagian sistem dan lingkungan yang menjadi cakupan.
2. Jenis bukti atau ringkasan hasil yang akan diserahkan.
3. Bagaimana temuan dikategorikan dan dibahas.
4. Siapa yang menyetujui tindakan serta perubahan lingkup.
5. Apakah perbaikan dan verifikasi ulang termasuk, terpisah, atau harus disepakati dahulu.
6. Kriteria penerimaan, termasuk cara mencatat risiko yang belum ditangani.

Gunakan rumusan yang bisa diperiksa, bukan janji absolut seperti “bebas celah” atau “100% aman”. Apabila organisasi memiliki persyaratan internal atau regulasi khusus, minta pihak yang kompeten meninjau kesesuaiannya. Artikel ini tidak memberi penilaian hukum ataupun sertifikasi.

Kapan mempertimbangkan pemeriksaan independen?

Pemeriksaan independen dapat dipertimbangkan jika sistem memproses data sensitif, mendukung operasi kritis, melibatkan banyak integrasi, atau memiliki kebutuhan kepatuhan dan tata kelola khusus. Keputusan sebaiknya didasarkan pada risiko, bukan sekadar label vendor. Tentukan tujuan, ruang lingkup, akses, jadwal, serta cara mengelola temuan sebelum pihak ketiga mulai bekerja.

Untuk proyek yang lebih sederhana, pembeli tetap dapat meminta penjelasan dan bukti proses yang sebanding dengan risikonya. Pemeriksaan independen bukan pengganti praktik pengembangan yang baik, dan satu pemeriksaan tidak menjamin tidak ada kelemahan yang dapat muncul kemudian.

Checklist singkat untuk calon pembeli

• Apakah vendor menjelaskan bagian yang diuji dan dikecualikan?
• Apakah metode dan pelaksana pemeriksaan diterangkan dengan jelas?
• Apakah bentuk bukti hasil ditetapkan sebelum proyek berjalan?
• Apakah ada proses untuk mencatat, memprioritaskan, dan menyepakati tindak lanjut temuan?
• Apakah pemeriksaan ulang dan biaya/lingkup perbaikan dijelaskan tanpa asumsi?
• Apakah kriteria penerimaan mengakui keterbatasan dan risiko tersisa?
• Apakah istilah “aman” tidak dipakai sebagai jaminan absolut?

Untuk menyiapkan kebutuhan dan pertanyaan awal kepada vendor, lihat juga checklist kebutuhan sistem informasi sebelum meminta penawaran. Jika proyek melibatkan beberapa jenis pengguna, artikel matriks hak akses sistem informasi dan cara mengujinya dapat membantu merumuskan peran serta izin yang perlu dipertimbangkan.

Diskusikan ruang lingkup, kriteria penerimaan, dan bukti yang dibutuhkan saat mengevaluasi jasa pembuatan website dan sistem. Detail pekerjaan tetap perlu dikonfirmasi untuk setiap proyek; jangan menganggap semua bentuk pengujian atau dokumentasi otomatis termasuk dalam suatu penawaran.

Pertanyaan yang sering diajukan

Apakah semua vendor wajib memberikan laporan uji keamanan?

Bentuk keluaran bergantung pada kebutuhan dan kesepakatan. Pembeli sebaiknya menetapkan sejak awal bukti minimum yang diperlukan, misalnya ringkasan ruang lingkup, hasil, batas pemeriksaan, dan tindak lanjut yang disepakati.

Apakah OWASP ASVS merupakan sertifikasi keamanan?

ASVS dapat dijadikan acuan persyaratan verifikasi, tetapi penyebutannya saja bukan bukti sertifikasi atau jaminan bahwa seluruh kontrol telah dipenuhi. Jelaskan tingkat dan persyaratan yang benar-benar disepakati.

Apakah hasil tanpa temuan berarti aplikasi aman?

Tidak. Hasil harus dibaca bersama ruang lingkup, metode, lingkungan, dan keterbatasan pemeriksaan. Hasil tanpa temuan hanya berbicara tentang pemeriksaan yang dilakukan, bukan seluruh risiko yang mungkin ada.

Haruskah pembeli meminta pentest sebelum menerima sistem?

Tidak ada kebutuhan universal yang berlaku untuk setiap proyek. Pertimbangkan sensitivitas data, dampak gangguan, integrasi, dan kebijakan organisasi, lalu tentukan jenis pemeriksaan yang proporsional bersama pihak kompeten.

Apa yang harus dilakukan jika ada temuan menjelang serah terima?

Catat temuan, dampaknya, keputusan penanganan, penanggung jawab, serta apakah pemeriksaan ulang diperlukan. Jangan menganggap temuan selesai tanpa bukti tindak lanjut yang telah disepakati.

Langkah berikutnya

Serah terima yang baik berangkat dari definisi yang jelas: apa yang dibangun, apa yang diperiksa, apa yang menjadi bukti, dan bagaimana risiko yang tersisa dikelola. Dengan pertanyaan tersebut, pembeli dapat membandingkan vendor secara lebih adil tanpa mengandalkan klaim umum semata.

Jika Anda sedang merencanakan sistem untuk kebutuhan bisnis, hubungi Sahabat Sistem untuk membicarakan kebutuhan dan ruang lingkup proyek Anda.

Kredit gambar: Jakub Zerdzicki — sumber gambar — Pexels License
Deskripsi gambar: Laptop, buku catatan, dan catatan tempel di meja kerja untuk peninjauan daftar periksa.
Relevansi: Ilustrasi suasana kerja untuk meninjau checklist sebelum serah terima; bukan dokumentasi atau bukti bahwa pengujian keamanan nyata telah dilakukan.