Sebuah aplikasi menjalani penetration testing pada Januari. Pengujian selesai, temuan diperbaiki, retest dilakukan, dan laporan akhirnya ditutup.

Secara administratif, pekerjaan tersebut selesai.

Namun tim development tidak berhenti bekerja sampai Januari berikutnya.

Dalam beberapa bulan, mereka mungkin telah menambahkan fitur baru, membuat endpoint API, memperbarui dependency, mengubah konfigurasi cloud, memperluas role pengguna, mengintegrasikan layanan pihak ketiga, dan melakukan puluhan deployment.

Menjelang akhir tahun, muncul pertanyaan yang jarang diajukan: apakah laporan penetration testing pada Januari masih menggambarkan aplikasi yang berjalan sekarang?

Masalah sebenarnya bukan karena pentest tahunan tidak memiliki nilai. Masalah muncul ketika satu pengujian tahunan dianggap mampu memberikan keyakinan keamanan terhadap aplikasi yang terus berubah sepanjang tahun.

Kalender Berjalan Lambat, Development Tidak

Perkembangan software modern telah mengubah cara perusahaan merilis aplikasi.

Release yang dahulu dilakukan beberapa kali dalam setahun kini dapat berlangsung setiap bulan, setiap minggu, bahkan lebih sering. CI/CD memungkinkan perubahan kode melewati proses build, testing, dan deployment dengan jauh lebih cepat.

Kecepatan tersebut memberikan keuntungan bisnis.

Bug dapat diperbaiki lebih cepat. Fitur baru dapat segera digunakan. Respons terhadap kebutuhan pengguna menjadi lebih singkat.

Namun setiap perubahan juga membawa kemungkinan perubahan pada security posture aplikasi.

Tambahan satu endpoint dapat memperluas akses terhadap data.

Perubahan role dapat memengaruhi authorization.

Update authentication dapat mengubah cara session atau token dikelola.

Dependency baru membawa komponen perangkat lunak yang sebelumnya tidak ada.

Integrasi pihak ketiga dapat menciptakan aliran data dan hubungan kepercayaan baru.

Artinya, aplikasi pada minggu ke-40 mungkin secara substansial sudah berbeda dari aplikasi yang diuji pada minggu pertama.

Pentest Adalah Snapshot, Bukan Status Permanen

Penetration testing memiliki konteks.

Tester menguji target tertentu, pada environment tertentu, menggunakan versi aplikasi tertentu, konfigurasi tertentu, role tertentu, serta ruang lingkup yang telah disepakati.

Hasilnya sangat berguna untuk menunjukkan kelemahan yang dapat ditemukan dan dieksploitasi pada kondisi tersebut.

Namun laporan pentest tidak membekukan aplikasi.

Begitu sistem berubah, sebagian asumsi yang digunakan selama pengujian sebelumnya juga dapat berubah.

Karena itu, penetration testing lebih tepat dipahami sebagai snapshot keamanan pada suatu periode, bukan sertifikat yang menyatakan sebuah aplikasi akan tetap aman selama satu tahun berikutnya.

Prinsip secure software development yang dikembangkan NIST juga menempatkan keamanan sebagai praktik yang perlu terintegrasi dalam software development lifecycle. Pendekatan ini berbeda dengan model yang memperlakukan keamanan sebagai pemeriksaan terpisah setelah seluruh pekerjaan development selesai.

Untuk aplikasi yang terus berkembang, perbedaan tersebut sangat penting.

Satu Tahun Dapat Berarti Puluhan Versi Aplikasi

Istilah “pentest setahun sekali” terdengar cukup masuk akal apabila aplikasi yang diuji relatif stabil.

Namun perhitungannya berubah ketika software memiliki release cycle yang cepat.

Bayangkan sebuah aplikasi melakukan deployment satu kali setiap minggu.

Dalam satu tahun, terdapat puluhan kesempatan terjadinya perubahan.

Tidak berarti setiap deployment pasti menciptakan vulnerability. Namun setiap perubahan dapat mengubah asumsi keamanan yang sebelumnya telah diuji.

Perubahan tersebut dapat berupa:

• penambahan API baru;
• perubahan permission pengguna;
• penggantian library;
• perubahan alur autentikasi;
• integrasi payment gateway;
• penambahan webhook;
• perubahan konfigurasi cloud;
• penambahan fungsi upload;
• integrasi SSO;
• atau perubahan business logic.

Jika beberapa perubahan tersebut terjadi setelah pentest terakhir, maka laporan lama tidak pernah menguji implementasi barunya.

Dengan kata lain, pertanyaan mengenai keamanan tidak cukup berhenti pada:

“Apakah aplikasi pernah di pentest tahun ini?”

Perusahaan juga perlu mengetahui:

“Versi aplikasi yang mana yang sebenarnya di pentest?”

Ukuran Perubahan Kode Tidak Selalu Sama dengan Ukuran Risiko

Dalam development, perubahan dapat terlihat sangat kecil.

Beberapa baris kode ditambahkan.

Satu parameter diganti.

Permission untuk sebuah role diperluas.

Endpoint baru dibuat untuk memenuhi kebutuhan integrasi.

Namun dalam keamanan aplikasi, jumlah baris kode bukan ukuran risiko yang dapat diandalkan.

Satu perubahan authorization yang keliru dapat memungkinkan pengguna mengakses objek milik pengguna lain.

Satu endpoint API dengan validasi yang tidak konsisten dapat membuka data yang sebelumnya tidak terekspos.

Satu perubahan pada konfigurasi storage dapat membuat informasi sensitif dapat diakses secara publik.

Satu service account dengan hak akses berlebihan dapat memberikan jalur menuju sistem yang lebih kritis.

Karena itu, release kecil tidak selalu berarti risiko kecil.

Hal yang lebih penting adalah memahami kontrol keamanan apa yang berubah akibat release tersebut.

Developer Memperbaiki Sistem, tetapi Attack Surface Juga Ikut Bergerak

Sebagian besar perubahan aplikasi dilakukan dengan tujuan yang baik.

Developer memperbaiki bug.

Tim produk menambahkan fitur berdasarkan kebutuhan pengguna.

Arsitektur dirapikan.

Integrasi baru dibuat untuk meningkatkan efisiensi.

Masalah keamanan muncul bukan karena perubahan tersebut selalu salah, tetapi karena software merupakan sistem yang saling terhubung.

Perubahan authentication dapat memengaruhi authorization.

Perubahan API dapat memengaruhi exposure data.

Perubahan business flow dapat memengaruhi validasi transaksi.

Perubahan sistem identitas dapat memengaruhi seluruh role di belakangnya.

Dengan kata lain, attack surface bergerak bersama development.

Ketika attack surface berubah setiap beberapa minggu, jadwal security testing yang hanya mengikuti kalender tahunan mulai menciptakan kesenjangan.

Business Logic Membuat Automation Saja Tidak Cukup

Solusi terhadap masalah tersebut bukan sekadar menjalankan scanner lebih sering.

Automation memiliki peran besar dalam modern application security.

SAST dapat membantu memeriksa kode.

Dependency scanning dapat mendeteksi komponen dengan vulnerability yang diketahui.

Secret scanning dapat menemukan credential yang tidak seharusnya berada di repository.

DAST dapat membantu menguji perilaku aplikasi dari luar.

Configuration scanning dapat mengidentifikasi sejumlah kesalahan konfigurasi.

Namun terdapat area yang membutuhkan pemahaman terhadap konteks sistem.

Misalnya sebuah aplikasi menetapkan bahwa supervisor hanya dapat menyetujui transaksi dari cabangnya sendiri.

Secara teknis seluruh endpoint mungkin bekerja dengan benar.

Scanner juga belum tentu melihat sesuatu yang mencurigakan.

Masalah baru terlihat ketika tester mencoba menggunakan akun supervisor cabang A untuk mengakses atau menyetujui transaksi cabang B.

OWASP menempatkan authorization dan business logic sebagai area penting dalam web security testing karena kelemahan di dalamnya sering membutuhkan pemahaman mengenai bagaimana aplikasi seharusnya berperilaku.

Inilah mengapa automation dan manual penetration testing sebaiknya dipandang sebagai lapisan yang saling melengkapi.

Continuous Security Bukan Berarti Melakukan Full Pentest Setiap Minggu

Jika aplikasi release setiap minggu, bukan berarti perusahaan harus menjalankan full manual penetration testing setiap minggu.

Model tersebut tidak realistis untuk sebagian besar organisasi.

Pendekatan yang lebih masuk akal adalah membuat security testing mengikuti tingkat perubahan dan risiko.

Pengujian otomatis dapat dilakukan lebih dekat dengan pipeline development.

Code review dapat memasukkan pemeriksaan keamanan.

Dependency dan secret scanning dapat dijalankan secara rutin.

Perubahan tertentu dapat memicu targeted security testing.

Kemudian penetration testing yang lebih menyeluruh dilakukan pada titik yang memiliki dampak keamanan lebih besar.

Pendekatan ini sejalan dengan konsep DevSecOps: keamanan tidak menunggu seluruh proses development selesai, tetapi menjadi bagian dari proses pengembangan dan delivery software.

NIST juga terus mendorong implementasi praktik SSDF dalam pipeline DevSecOps modern. Pendekatan semacam ini membantu organisasi mengurangi jarak antara perubahan software dengan evaluasi terhadap risiko yang dibawa perubahan tersebut.

Pentest Sebaiknya Memiliki Trigger, Bukan Hanya Tanggal

Banyak perusahaan memiliki kebijakan sederhana:

“Pentest dilakukan setiap tahun.”

Sebagai baseline, kebijakan tersebut tetap dapat berguna.

Namun kalender tidak mengetahui bahwa perusahaan baru saja melakukan migrasi cloud.

Kalender juga tidak mengetahui bahwa authentication telah diganti, API publik baru diluncurkan, atau aplikasi baru saja terhubung dengan partner strategis.

Karena itu, perusahaan dapat mempertimbangkan trigger tambahan.

Penetration testing atau targeted security testing dapat dievaluasi ketika terjadi:

• major release;
• implementasi API baru;
• perubahan authentication;
• perubahan authorization;
• penerapan SSO;
• integrasi pihak ketiga;
• perubahan besar pada payment flow;
• migrasi cloud;
• perubahan arsitektur;
• penambahan role dengan privilege tinggi;
• atau penambahan fungsi yang memproses data sensitif.

Trigger berbasis perubahan membuat pengujian lebih dekat dengan risiko aktual dibanding sekadar menunggu tanggal yang sama pada tahun berikutnya.

Tidak Semua Release Perlu Diperlakukan Sama

Pendekatan berbasis perubahan juga tidak berarti setiap commit harus memperoleh perlakuan identik.

Mengubah warna tombol tentu memiliki implikasi berbeda dibanding mengganti mekanisme login.

Memperbaiki typo juga berbeda dengan membuka API kepada partner baru.

Karena itu, perusahaan memerlukan prioritas berbasis risiko.

Perubahan yang menyentuh authentication, authorization, transaksi, data sensitif, integrasi, API, privilege, atau infrastruktur umumnya membutuhkan perhatian keamanan lebih tinggi dibanding perubahan kosmetik.

Pendekatan seperti ini membuat sumber daya security testing lebih efektif.

Tim tidak perlu menguji seluruh sistem setiap kali ada perubahan kecil, tetapi tidak pula menunggu satu tahun ketika perubahan penting telah terjadi beberapa bulan sebelumnya.

Pentest Tahunan Tetap Dapat Menjadi Baseline

Judul artikel ini tidak berarti perusahaan harus menghapus pentest tahunan.

Pengujian tahunan masih dapat menjadi comprehensive assessment yang berguna.

Ia dapat memberikan baseline keamanan, mendukung kebutuhan audit atau compliance, serta memberikan kesempatan untuk melihat aplikasi secara lebih menyeluruh.

Namun bagi aplikasi yang sangat dinamis, pentest tahunan sebaiknya tidak berdiri sendiri.

Ia dapat dilengkapi dengan:

continuous security testing, automated security checks, targeted assessment setelah perubahan signifikan, security review, serta penetration testing tambahan ketika attack surface mengalami perubahan besar.

Dengan cara tersebut, pentest tahunan berubah fungsi.

Bukan lagi satu-satunya momen ketika keamanan diperiksa, tetapi menjadi salah satu lapisan dalam strategi application security yang lebih berkelanjutan.

Pertanyaan yang Lebih Berguna: Apa yang Berubah Sejak Pentest Terakhir?

Ketika mengevaluasi relevansi sebuah laporan pentest, tanggal tetap penting.

Namun ada pertanyaan yang jauh lebih informatif:

Apa saja yang berubah setelah pengujian tersebut selesai?

Apakah ada API baru?

Apakah role dan permission berubah?

Apakah ada integrasi pihak ketiga baru?

Apakah authentication diganti?

Apakah aplikasi berpindah infrastruktur?

Apakah terdapat major release?

Apakah dependency utama diperbarui?

Apakah aplikasi sekarang memproses jenis data yang berbeda?

Apakah muncul layanan baru yang dapat diakses dari internet?

Semakin banyak jawaban “ya”, semakin penting untuk menilai kembali apakah hasil pengujian lama masih cukup menggambarkan kondisi sistem saat ini.

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

Aplikasi dapat memiliki laporan pentest yang masih relatif baru, tetapi secara teknis telah mengalami cukup banyak perubahan sehingga sebagian permukaan serangannya tidak pernah masuk ke dalam scope pengujian sebelumnya.

Masalahnya bukan karena pentest gagal.

Sistem yang diuji sudah berubah.

Security Testing Perlu Bergerak Lebih Dekat dengan Development

Development modern tidak mungkin diperlambat hanya untuk menyesuaikan jadwal keamanan tahunan.

Perusahaan tetap membutuhkan kemampuan merilis fitur, memperbaiki sistem, dan merespons kebutuhan bisnis secara cepat.

Konsekuensinya, strategi security testing juga harus berkembang.

CISA melalui pendekatan Secure by Design mendorong keamanan menjadi pertimbangan inti sepanjang lifecycle produk. NIST melalui SSDF juga menempatkan praktik keamanan sebagai bagian dari proses pengembangan perangkat lunak, bukan pemeriksaan yang hanya dilakukan pada satu titik.

Ini bukan berarti manual penetration testing kehilangan peran.

Sebaliknya, pentest menjadi lebih bernilai ketika digunakan pada titik yang tepat, terhadap scope yang tepat, setelah perubahan yang memang relevan terhadap risiko.

Aplikasi yang hanya berubah beberapa kali setahun tentu memiliki kebutuhan berbeda dengan aplikasi yang melakukan deployment setiap minggu.

Karena itu, frekuensi security testing sebaiknya mengikuti karakter sistem, bukan menggunakan satu formula untuk seluruh aplikasi.

Jika software terus berubah setiap minggu, keamanan tidak seharusnya hanya muncul sekali dalam setahun.

Sesuaikan Strategi Penetration Testing Bersama Fourtrezz

Perusahaan dengan release cycle cepat membutuhkan pendekatan pengujian yang mempertimbangkan perubahan aplikasi, API, role, integrasi, dan infrastruktur.

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk membantu organisasi menemukan kerentanan dan mengevaluasi keamanan aplikasi maupun sistem yang digunakan perusahaan.

Fourtrezz juga memiliki kapabilitas cybersecurity dan IT development, sehingga kebutuhan pengujian dapat dilihat dalam konteks yang lebih luas, mulai dari aplikasi, API, hingga infrastruktur dan perubahan sistem yang menjadi bagian dari proses bisnis.

Bagi perusahaan yang melakukan deployment rutin, security testing dapat disesuaikan berdasarkan scope dan tingkat risiko. Pengujian tidak harus menunggu kalender tahunan ketika major release atau perubahan kritis telah lebih dahulu mengubah attack surface aplikasi.

Jika perusahaan Anda ingin mengevaluasi apakah jadwal penetration testing saat ini masih sesuai dengan ritme development dan tingkat risiko sistem, Fourtrezz dapat menjadi mitra dalam menentukan ruang lingkup pengujian yang lebih relevan.

Hubungi Fourtrezz:

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