Vendor telah menyelesaikan pekerjaan. UAT dinyatakan berhasil, seluruh fungsi utama berjalan, dokumentasi diberikan, dan Berita Acara Serah Terima akhirnya ditandatangani.

Dari sisi proyek, pekerjaan terlihat selesai.

Namun serah terima aplikasi sebenarnya menandai sesuatu yang lebih besar daripada perpindahan source code dan dokumentasi. Sejak aplikasi mulai digunakan untuk menjalankan proses bisnis, menyimpan data, menerima transaksi, atau memberikan akses kepada pengguna, konsekuensi dari kelemahan sistem juga mulai berada di tangan organisasi pemiliknya.

Jika keamanan aplikasi belum pernah diuji secara independen, ada kemungkinan organisasi menerima sesuatu yang tidak tercantum dalam dokumen serah terima: risiko keamanan yang belum diketahui.

Inilah mengapa penetration testing sebelum serah terima seharusnya tidak sekadar dipandang sebagai pemeriksaan tambahan. Untuk sistem dengan tingkat risiko tertentu, pengujian keamanan dapat menjadi bagian penting dari proses penerimaan.

Aplikasi Selesai Dibangun Tidak Sama dengan Risiko Sudah Selesai

Sebagian besar proyek pengembangan aplikasi memiliki indikator keberhasilan yang cukup jelas.

Fitur harus sesuai requirement.

Workflow harus berjalan.

Integrasi harus berfungsi.

Bug harus diperbaiki.

User Acceptance Testing harus selesai.

Semua indikator tersebut penting. Namun sebagian besar menjawab satu pertanyaan utama:

Apakah aplikasi dapat menjalankan fungsi yang diminta?

Keamanan mengajukan pertanyaan berbeda.

Apakah pengguna dapat mengakses fungsi yang sebenarnya bukan haknya?

Apakah parameter transaksi dapat dimanipulasi?

Apakah API dapat dipanggil secara langsung untuk melewati aturan pada antarmuka?

Apakah akun dengan role rendah dapat memperoleh privilege lebih tinggi?

Apakah workflow bisnis dapat dilewati?

Apakah beberapa kelemahan kecil dapat digabungkan menjadi jalur serangan?

Sistem dapat memenuhi seluruh requirement bisnis dan tetap memiliki vulnerability.

Karena itu, keberhasilan UAT tidak dapat otomatis diterjemahkan menjadi bukti bahwa aplikasi telah aman.

UAT dan Pentest Memeriksa Aplikasi dengan Pertanyaan yang Berbeda

UAT biasanya dimulai dari skenario yang seharusnya terjadi.

Pengguna login, membuka menu, memasukkan data, menyelesaikan proses, lalu sistem menghasilkan output yang diharapkan.

Penetration testing justru sering dimulai dari kemungkinan yang seharusnya tidak terjadi.

Bagaimana jika pengguna melewati tahapan tertentu?

Bagaimana jika identifier diganti?

Bagaimana jika request yang sama dikirim berulang kali?

Bagaimana jika endpoint administrator dipanggil oleh akun biasa?

Bagaimana jika nilai transaksi diubah sebelum mencapai server?

Bagaimana jika API digunakan tanpa melalui antarmuka aplikasi?

Perbedaan perspektif tersebut penting karena attacker tidak memiliki kewajiban mengikuti user journey yang dirancang oleh developer.

Mereka justru mencari kondisi ketika asumsi developer tidak berlaku.

Karena itu, aplikasi yang telah melalui QA dan UAT masih dapat membutuhkan security testing tersendiri sebelum dinyatakan siap diterima.

Vendor yang Membangun Sistem Tidak Harus Menjadi Satu-satunya Pihak yang Menilainya

Independent penetration testing bukan berarti organisasi tidak mempercayai vendor development.

Vendor yang baik justru seharusnya menerapkan secure development, code review, testing internal, dan perbaikan keamanan selama proses pembangunan.

Namun ada perbedaan antara membangun sistem dan memberikan assurance independen terhadap sistem tersebut.

Tim development mengenal bagaimana aplikasi dirancang.

Mereka mengetahui workflow yang benar.

Mereka memahami tujuan setiap endpoint.

Mereka mengetahui alasan sebuah role memperoleh permission tertentu.

Pengetahuan tersebut sangat berguna untuk membangun software, tetapi juga dapat menghasilkan blind spot.

Ketika seseorang terlalu memahami bagaimana sistem seharusnya bekerja, terkadang lebih sulit melihat bagaimana sistem dapat digunakan dengan cara yang tidak pernah direncanakan.

Tester independen datang dengan posisi yang berbeda.

Mereka tidak memiliki kewajiban mempertahankan asumsi desain. Mereka dapat mempertanyakan setiap trust relationship, mencoba melanggar workflow, menguji batas antar-role, dan mengevaluasi apakah kontrol benar-benar ditegakkan oleh sistem.

Independensi dalam konteks ini bukan soal ketidakpercayaan.

Independensi adalah mekanisme validasi.

Source Code Dapat Diserahkan, Vulnerability Juga Bisa Ikut Berpindah

Dalam proyek pengembangan, serah terima dapat mencakup banyak komponen.

Organisasi menerima aplikasi.

Source code.

Database.

Dokumentasi.

Credential.

Konfigurasi.

API.

Dependency.

Akses cloud atau server.

Kadang juga pipeline deployment dan berbagai komponen pendukung lainnya.

Jika seluruh komponen tersebut belum mendapatkan evaluasi keamanan yang memadai, organisasi mungkin sekaligus menerima kelemahan yang belum teridentifikasi.

Misalnya authorization yang terlalu longgar.

Credential yang tersimpan tidak aman.

API yang mengekspos data berlebihan.

Session management yang lemah.

Dependency dengan risiko keamanan.

Salah konfigurasi.

Business logic yang dapat dimanipulasi.

Atau hubungan antar-role yang tidak benar-benar dibatasi di sisi server.

Sebagian kelemahan seperti ini tidak akan terlihat ketika pengujian hanya memastikan fitur berjalan sesuai requirement.

Masalah baru muncul ketika seseorang secara aktif mencoba menyalahgunakan sistem.

Setelah Go-Live, Nama Pemilik Sistem yang Menghadapi Dampaknya

Pertanyaan mengenai keamanan sebelum handover bukan hanya masalah teknis.

Ada dimensi bisnis yang jauh lebih besar.

Setelah aplikasi beroperasi, sebuah insiden dapat menimbulkan konsekuensi berupa gangguan layanan, kebocoran data, biaya investigasi, remediasi darurat, downtime, kerugian operasional, temuan audit, hingga penurunan kepercayaan pengguna.

Vendor mungkin masih memiliki kewajiban berdasarkan kontrak atau periode warranty.

Namun bagi pengguna, regulator, pelanggan, atau manajemen perusahaan, sistem tersebut tetap merupakan sistem milik organisasi yang mengoperasikannya.

Karena itu, keputusan menerima aplikasi tanpa validasi keamanan juga berarti menerima tingkat ketidakpastian tertentu terhadap risiko yang berada di dalam sistem tersebut.

Di sinilah perspektif procurement, project management, risk management, dan cybersecurity perlu bertemu.

Serah terima tidak hanya seharusnya mempertanyakan apakah pekerjaan vendor selesai.

Organisasi juga perlu mempertanyakan apakah sistem yang diterima memiliki tingkat assurance yang sesuai dengan risiko bisnisnya.

Business Logic Menjadi Salah Satu Alasan Pentest Independen Dibutuhkan

Tidak semua vulnerability berbentuk bug teknis yang mudah ditemukan menggunakan scanner.

Sebagian berada dalam logika bisnis aplikasi.

Bayangkan sebuah sistem procurement yang menetapkan bahwa staf membuat pengajuan, manager memberikan approval, dan finance melakukan pembayaran.

Setiap fitur dapat bekerja dengan sempurna.

Namun apa yang terjadi jika staf dapat memanggil endpoint approval secara langsung?

Bagaimana jika identifier pengajuan milik departemen lain dapat diubah pada request?

Bagaimana jika proses pembayaran dapat dipanggil sebelum tahapan approval selesai?

Atau bagaimana jika transaksi yang sama dapat diproses beberapa kali?

Secara individual, fungsi aplikasi mungkin tidak rusak.

Masalahnya berada pada hubungan dan aturan diantara fungsi tersebut.

Pengujian business logic seperti ini membutuhkan pemahaman mengenai aturan yang seharusnya berlaku, kemudian mencoba menemukan cara untuk melanggarnya.

Itulah salah satu area di mana pentest aplikasi dapat memberikan perspektif yang berbeda dari functional testing.

“Sudah Dites oleh Vendor” Perlu Dijelaskan Lebih Jauh

Pernyataan bahwa aplikasi “sudah melalui security testing” merupakan hal positif.

Namun bagi organisasi yang akan menerima sistem, informasi tersebut sebaiknya tidak berhenti pada satu kalimat.

Beberapa pertanyaan perlu diajukan.

Siapa yang melakukan pengujian?

Apa ruang lingkupnya?

Apakah API termasuk di dalamnya?

Role apa saja yang diuji?

Apakah authentication dan authorization diperiksa?

Apakah business logic menjadi bagian pengujian?

Apakah hanya menggunakan automated scanner atau terdapat manual testing?

Apa saja temuan yang muncul?

Apakah temuan dengan risiko tinggi telah diperbaiki?

Apakah setelah perbaikan dilakukan retest?

Pertanyaan tersebut bukan bertujuan memperpanjang proses administratif.

Tujuannya adalah memahami berapa besar tingkat assurance yang sebenarnya telah diperoleh.

Pengujian internal vendor dan independent penetration testing juga tidak harus saling menggantikan.

Keduanya justru dapat menjadi lapisan yang melengkapi satu sama lain.

Security Acceptance Criteria Seharusnya Dibicarakan sebelum Aplikasi Selesai

Salah satu masalah yang sering membuat security testing menjadi sulit adalah waktunya.

Pentest baru dibicarakan beberapa hari sebelum go-live.

Project timeline sudah ketat.

Anggaran sudah hampir habis.

Vendor menganggap scope development sudah selesai.

Business owner ingin sistem segera digunakan.

Kemudian pentest menemukan vulnerability yang membutuhkan perubahan cukup besar.

Situasi seperti ini dapat dikurangi apabila security acceptance criteria sudah ditentukan sejak proyek dimulai.

Misalnya, kontrak atau Scope of Work dapat mengatur bahwa aplikasi harus melalui penetration testing sebelum final acceptance.

Temuan dengan tingkat risiko tertentu harus diperbaiki.

Perbaikan harus melalui retest.

Role kritis harus masuk ke dalam scope.

API yang relevan harus ikut diuji.

Vendor harus menyediakan credential dan environment yang diperlukan.

Perubahan signifikan setelah pentest perlu dikomunikasikan.

Dengan pendekatan tersebut, keamanan bukan permintaan tambahan yang muncul pada akhir proyek.

Ia menjadi bagian dari definisi aplikasi yang dianggap selesai.

Sistem yang Lebih Kritis Memerlukan Standar Penerimaan yang Lebih Tinggi

Tidak semua proyek membutuhkan perlakuan keamanan yang identik.

Website sederhana yang hanya menampilkan informasi publik memiliki profil risiko berbeda dengan aplikasi yang menangani data pelanggan.

Begitu pula aplikasi HR, procurement, ERP, customer portal, sistem pemerintahan, aplikasi pelayanan publik, sistem kesehatan, platform transaksi, atau aplikasi internal dengan privilege tinggi.

Semakin besar potensi dampak ketika sistem disalahgunakan, semakin kuat kebutuhan untuk memperoleh validasi keamanan sebelum sistem diterima.

Pertimbangannya dapat meliputi sensitivitas data, jumlah pengguna, exposure ke internet, tingkat privilege, koneksi dengan sistem lain, kompleksitas API, serta dampak bisnis jika terjadi gangguan.

Artinya, keputusan melakukan pentest tidak sebaiknya hanya berdasarkan nilai proyek.

Criticality sistem jauh lebih relevan daripada harga pengembangannya.

Temuan sebelum Handover Lebih Mudah Dikelola daripada Temuan setelah Sistem Beroperasi

Waktu pengujian juga memiliki konsekuensi komersial.

Ketika vulnerability ditemukan sebelum final acceptance, posisi proyek masih relatif jelas.

Vendor masih berada dalam proses delivery.

Developer yang mengerjakan aplikasi masih tersedia.

Remediasi dapat dimasukkan ke dalam penyelesaian proyek.

Retest dapat dilakukan sebelum sistem dinyatakan selesai.

Tanggung jawab terhadap perubahan juga lebih mudah ditelusuri.

Kondisinya dapat berbeda apabila masalah baru ditemukan berbulan-bulan setelah handover.

Tim developer mungkin sudah berpindah proyek.

Kontrak mungkin telah selesai.

Warranty dapat memiliki batas tertentu.

Aplikasi mungkin sudah mengalami perubahan.

Vendor dan pemilik sistem dapat memiliki pandangan berbeda mengenai siapa yang bertanggung jawab terhadap kelemahan tersebut.

Lebih buruk lagi apabila masalah pertama kali ditemukan bukan melalui pengujian, tetapi setelah terjadi insiden.

Karena itu, penetration testing sebelum serah terima memiliki nilai yang bukan hanya berkaitan dengan cybersecurity.

Ia juga dapat membantu memperjelas proses acceptance dan remediasi antara pemilik sistem dengan vendor.

Jangan Menunggu Audit Menemukan Masalah yang Bisa Ditemukan sebelum Go-Live

Ada organisasi yang baru melakukan pengujian keamanan ketika muncul kebutuhan audit, compliance, sertifikasi, atau permintaan dari pihak regulator.

Pengujian tetap bermanfaat pada tahap tersebut.

Namun dari perspektif risiko, lebih baik menemukan vulnerability ketika sistem masih dalam fase penerimaan daripada setelah aplikasi menjadi bagian penting dari operasional.

Temuan sebelum go-live dapat diperlakukan sebagai pekerjaan remediasi.

Temuan setelah sistem digunakan secara luas dapat memiliki konsekuensi lebih besar karena data, pengguna, dan proses bisnis sudah bergantung pada aplikasi tersebut.

Terlebih lagi, temuan setelah insiden tidak lagi hanya menjadi masalah development.

Ia dapat berubah menjadi masalah operasional dan bisnis.

Lima Pertanyaan sebelum Menandatangani Serah Terima Aplikasi

Sebelum final acceptance dilakukan, organisasi setidaknya dapat mengajukan lima pertanyaan sederhana.

1. Apakah aplikasi telah menjalani penetration testing yang independen?

Pengujian independen membantu memberikan perspektif selain developer yang membangun aplikasi.

2. Apakah seluruh role dan fungsi kritis sudah masuk scope?

Pengujian hanya memberikan assurance terhadap area yang benar-benar diperiksa.

3. Apakah API dan integrasi ikut diuji?

Attack surface aplikasi modern tidak berhenti pada halaman yang terlihat di browser.

4. Apakah temuan penting telah diperbaiki dan melalui retest?

Laporan pentest tanpa remediasi tidak otomatis menurunkan risiko.

5. Apakah terdapat perubahan signifikan setelah pentest selesai?

Perubahan besar setelah pengujian dapat menciptakan kondisi yang tidak pernah diuji sebelumnya.

Lima pertanyaan tersebut tidak menjamin bahwa aplikasi bebas dari seluruh risiko.

Namun pertanyaan tersebut membantu organisasi menghindari penerimaan sistem berdasarkan asumsi semata.

Development Dapat Dialihdayakan, Akuntabilitas Risiko Tidak Otomatis Ikut Berpindah

Menggunakan software house atau vendor IT development merupakan hal yang wajar.

Perusahaan tidak harus memiliki seluruh kemampuan pengembangan secara internal.

Namun outsourcing development tidak berarti organisasi dapat sepenuhnya mengalihdayakan akuntabilitas terhadap risiko sistem yang digunakannya.

Pemilik sistem tetap perlu mengetahui aset apa yang dimiliki, data apa yang diproses, siapa yang memiliki akses, bagaimana aplikasi terhubung dengan sistem lain, serta bagaimana kontrol keamanan telah diverifikasi.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Aplikasi dapat saja telah berfungsi dengan baik dan dinyatakan selesai dari sisi development. Namun ketika pengujian dilakukan dengan perspektif serangan, masih ditemukan skenario yang sebelumnya tidak tercakup dalam UAT ataupun pengujian fungsional.

Kondisi tersebut tidak selalu berarti vendor gagal.

Sering kali masalah muncul karena security assurance memang tidak pernah dimasukkan sebagai bagian formal dari acceptance proyek.

Serah Terima Seharusnya Menjadi Titik Validasi, Bukan Sekadar Administrasi

Penandatanganan BAST seharusnya tidak hanya menunjukkan bahwa aplikasi telah tersedia dan fiturnya dapat digunakan.

Untuk sistem dengan tingkat risiko yang memadai, proses penerimaan juga perlu memberikan keyakinan bahwa keamanan telah diuji dengan pendekatan yang sesuai.

QA memastikan fungsi bekerja.

UAT memastikan sistem memenuhi kebutuhan pengguna.

Secure development membantu developer mengurangi vulnerability sejak proses pembangunan.

Sedangkan independent penetration testing menambahkan perspektif ofensif terhadap sistem sebelum tanggung jawab operasional sepenuhnya berpindah.

Keempatnya menjawab kebutuhan yang berbeda.

Karena itu, pertanyaan terakhir sebelum aplikasi diterima sebaiknya tidak hanya:

“Apakah seluruh fitur sudah sesuai?”

Tambahkan satu pertanyaan lagi:

“Apakah kita sudah mengetahui risiko keamanan yang ikut kita terima bersama aplikasi ini?”

Sebab ketika serah terima selesai, organisasi bukan hanya menerima software.

Organisasi juga menerima konsekuensi dari bagaimana software tersebut dibangun dan diamankan.

Validasi Keamanan Aplikasi Bersama Fourtrezz

Bagi perusahaan yang sedang menyelesaikan proyek pengembangan aplikasi, bersiap melakukan go-live, atau akan menerima sistem dari software house maupun vendor teknologi, independent penetration testing dapat menjadi salah satu lapisan validasi sebelum final acceptance dilakukan.

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk membantu organisasi mengidentifikasi dan mengevaluasi kerentanan pada aplikasi, API, maupun infrastruktur.

Pengujian dapat disesuaikan dengan karakteristik sistem dan kebutuhan perusahaan, termasuk pengujian terhadap role, authentication, authorization, API, business logic, serta area lain yang menjadi bagian penting dari attack surface aplikasi.

Dengan memasukkan security testing ke dalam proses serah terima, organisasi memiliki kesempatan untuk menemukan dan memperbaiki kelemahan ketika proyek masih berada pada fase yang tepat untuk remediasi.

Jangan sampai aplikasi sudah resmi diterima, tetapi risiko yang tersembunyi di dalamnya belum pernah mendapatkan validasi independen.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]