Sebuah sprint dapat berakhir dengan hasil yang terlihat meyakinkan. Fitur baru berhasil dijalankan, seluruh pengujian fungsional dinyatakan lulus, dan aplikasi siap dipindahkan ke lingkungan produksi.

Namun, keberhasilan tersebut belum menjawab satu pertanyaan penting: apakah perubahan yang baru dilakukan telah memengaruhi keamanan fungsi lain?

Aplikasi yang diperbarui bukan lagi aplikasi yang sama dengan versi sebelumnya. Perubahan pada kode, konfigurasi, API, dependensi, atau hak akses dapat mengubah cara sistem melindungi data. Masalahnya, banyak tim development masih menggunakan asumsi keamanan dari pengujian versi lama.

Aplikasi terus bergerak, tetapi bukti keamanannya tertinggal.

Perubahan Kecil Tidak Selalu Menghasilkan Risiko yang Kecil

Risiko keamanan tidak dapat dinilai hanya dari jumlah baris kode yang berubah. Penyesuaian sederhana pada satu komponen dapat memengaruhi banyak fungsi yang bergantung padanya.

Perubahan middleware autentikasi, misalnya, dapat berdampak pada seluruh endpoint yang menggunakan mekanisme tersebut. Penambahan satu role pengguna dapat mengubah batas akses pada sejumlah modul. Pembaruan library juga dapat memengaruhi validasi, pengelolaan sesi, atau cara aplikasi memproses input.

Risiko serupa dapat muncul ketika tim mengubah konfigurasi deployment, menambahkan integrasi pihak ketiga, atau memperbarui struktur data. Fitur yang tidak disentuh secara langsung tetap dapat terdampak karena aplikasi terdiri atas komponen yang saling terhubung.

Beberapa perubahan yang terlihat sederhana tetapi dapat membawa konsekuensi keamanan antara lain:

• penambahan fitur ekspor data;
• perubahan endpoint API;
• penerapan Single Sign-On;
• penyesuaian role dan permission;
• pembaruan framework atau library;
• perubahan konfigurasi cloud;
• penambahan mekanisme cache;
• refactoring pada modul autentikasi;
• perubahan sistem logging.

Inilah alasan mengapa perubahan kecil tetap membutuhkan analisis dampak. Yang perlu diperiksa bukan sekadar bagian yang diubah, tetapi juga kontrol keamanan lain yang bergantung pada bagian tersebut.

Fitur Lama Dapat Menjadi Celah Baru

Tidak semua kerentanan berasal dari fitur baru. Dalam banyak kasus, fitur lama menjadi tidak aman karena konteks di sekitarnya berubah.

Sebuah halaman administrasi mungkin sebelumnya hanya dapat diakses melalui jaringan internal. Ketika arsitektur aplikasi berubah, halaman tersebut tanpa sengaja ikut tersedia melalui internet. Fungsinya tidak berubah, tetapi tingkat paparannya berubah secara signifikan.

Hal yang sama dapat terjadi pada kontrol akses. Endpoint tertentu mungkin telah membatasi akses berdasarkan role. Ketika tim menambahkan role baru, aturan tersebut belum tentu langsung mengenali batas kewenangan yang seharusnya berlaku.

Pengujian fungsional umumnya hanya membuktikan bahwa fungsi dapat digunakan sesuai skenario normal. Pengujian tersebut belum tentu memeriksa apakah fungsi juga dapat digunakan oleh pengguna yang salah, melalui urutan proses yang tidak semestinya, atau dengan data milik pengguna lain.

Akibatnya, aplikasi dapat tetap berfungsi dengan baik sekaligus mengalami penurunan keamanan.

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

Status “Pernah Diuji” Memiliki Batas Waktu

Laporan penetration testing menggambarkan kondisi aplikasi berdasarkan versi, konfigurasi, akses, dan ruang lingkup tertentu. Hasil tersebut sangat penting untuk menemukan kelemahan yang tidak terlihat dalam pengujian rutin.

Namun, hasil pengujian tidak dapat dianggap berlaku tanpa batas.

Ketika aplikasi mengalami perubahan, sebagian kesimpulan keamanan sebelumnya mungkin tidak lagi relevan. Perbaikan yang sudah dilakukan juga dapat hilang akibat refactoring, konflik kode, perubahan dependensi, atau implementasi ulang pada modul yang sama.

Karena itu, terdapat perbedaan fungsi antara penetration testing, vulnerability retest, dan security regression test.

Penetration testing digunakan untuk mencari dan membuktikan kemungkinan eksploitasi dalam cakupan tertentu. Vulnerability retest berfokus pada verifikasi bahwa temuan yang telah dilaporkan benar-benar diperbaiki. Sementara itu, security regression test memastikan perubahan berikutnya tidak mengembalikan kelemahan lama atau merusak kontrol keamanan yang sebelumnya berfungsi.

Ketiganya bukan pilihan yang saling menggantikan. Security regression test menjaga kontrol yang sudah dikenal, sedangkan penetration testing membantu menemukan risiko baru yang belum pernah dipikirkan oleh tim.

Security Regression Test Menjadi Memori Keamanan Aplikasi

Setiap kerentanan yang pernah ditemukan seharusnya menghasilkan dua hal. Pertama, perbaikan pada aplikasi. Kedua, skenario pengujian yang memastikan masalah serupa tidak muncul kembali.

Jika penetration testing menemukan bahwa pengguna dapat mengakses data milik pengguna lain, tim tidak cukup hanya memperbaiki kondisi tersebut. Kasus yang sama perlu diterjemahkan menjadi security test case.

Pengujian kemudian harus memastikan bahwa:

• pengguna hanya dapat mengakses data miliknya;
• pengguna biasa tidak dapat menggunakan fungsi administrator;
• pengguna dari satu tenant tidak dapat membaca data tenant lain;
• token yang sudah berakhir tidak dapat digunakan kembali;
• endpoint tetap melakukan pemeriksaan otorisasi;
• data sensitif tidak muncul dalam respons atau log;
• input berbahaya tetap ditolak setelah perubahan aplikasi.

Dengan pendekatan ini, temuan keamanan tidak berhenti sebagai laporan. Temuan tersebut menjadi bagian dari memori teknis aplikasi.

Prinsip ini sejalan dengan OWASP Application Security Verification Standard yang menyediakan dasar untuk memetakan persyaratan keamanan menjadi kontrol yang dapat diverifikasi. OWASP juga menekankan pengujian berulang pada autentikasi, otorisasi, pengelolaan sesi, validasi input, dan perlindungan data.

Security regression testing membuat pengetahuan tersebut tetap bertahan meskipun anggota tim, arsitektur, dan kebutuhan bisnis berubah.

Tidak Semua Pengujian Harus Dijalankan pada Setiap Commit

Memasukkan pengujian keamanan ke dalam development tidak berarti seluruh pengujian harus dijalankan setiap kali developer mengubah kode.

Cara seperti itu justru berpotensi memperlambat pipeline, memperbanyak false positive, dan membuat tim mengabaikan hasil pengujian. Pendekatan yang lebih realistis adalah membagi pengujian berdasarkan risiko dan waktu pelaksanaannya.

Pada setiap pull request, tim dapat menjalankan pemeriksaan yang relatif cepat, seperti security unit test, pemeriksaan secret, Static Application Security Testing, validasi dependensi, dan pengujian kontrol akses pada komponen yang berubah.

Pada lingkungan staging atau build harian, cakupan dapat diperluas ke Dynamic Application Security Testing, pengujian autentikasi, pengelolaan sesi, matriks otorisasi, konfigurasi, serta integrasi API.

Untuk perubahan berisiko tinggi, tim tetap membutuhkan pengujian manual. Perubahan tersebut dapat mencakup sistem pembayaran, fungsi administratif, pemrosesan data sensitif, integrasi baru, perubahan arsitektur, atau penambahan role pengguna.

Pembagian ini membantu tim mempertahankan kecepatan development tanpa mengubah keamanan menjadi pemeriksaan simbolis.

Prioritas Harus Mengikuti Risiko, Bukan Ukuran Fitur

Menguji seluruh aplikasi dengan intensitas yang sama pada setiap sprint bukan pendekatan yang efisien. Tim perlu menentukan area yang tidak boleh berubah tanpa verifikasi keamanan.

Prioritas tinggi sebaiknya diberikan kepada perubahan yang menyentuh:

• autentikasi dan pengelolaan sesi;
• role, permission, dan otorisasi;
• fungsi administratif;
• data pribadi atau informasi sensitif;
• transaksi penting;
• API yang dapat diakses publik;
• integrasi pihak ketiga;
• upload dan download file;
• konfigurasi infrastruktur;
• dependensi kritis;
• batas akses antar pengguna atau antar tenant.

Setiap perubahan pada area tersebut perlu memicu pertanyaan yang lebih spesifik. Kontrol apa yang bergantung pada komponen ini? Siapa yang memperoleh akses baru? Jalur data mana yang berubah? Apakah threat model masih berlaku? Apakah perubahan tersebut dapat membatalkan perbaikan sebelumnya?

Pertanyaan semacam ini membuat security regression test lebih relevan daripada sekadar menjalankan daftar pemeriksaan yang sama pada semua perubahan.

Otomatisasi Tidak Dapat Memahami Seluruh Konteks Bisnis

Automated security testing berperan penting dalam pengembangan modern. Otomatisasi memberikan hasil yang konsisten, dapat dijalankan berulang kali, dan membantu mendeteksi masalah lebih awal.

Kajian sistematis terhadap berbagai penelitian DevSecOps juga menempatkan pengujian berkelanjutan, otomatisasi, dan integrasi keamanan sejak awal sebagai praktik penting dalam pengembangan perangkat lunak. NIST Secure Software Development Framework turut mendorong verifikasi keamanan di sepanjang siklus pengembangan, bukan hanya pada akhir proyek.

Meskipun demikian, otomatisasi memiliki keterbatasan.

Alat dapat menguji apakah pengguna biasa ditolak ketika mengakses endpoint administrator. Namun, alat belum tentu memahami bahwa dua fungsi yang sah dapat digabungkan untuk melewati proses persetujuan.

Keterbatasan serupa berlaku pada penyalahgunaan logika bisnis, manipulasi alur transaksi, konflik kewenangan, dan akses yang secara teknis valid tetapi tidak sesuai tujuan bisnis.

Oleh karena itu, pengujian otomatis perlu dipadukan dengan review manual, threat modeling, pengujian skenario penyalahgunaan, dan penetration testing. Otomatisasi menjaga konsistensi, sedangkan pemeriksaan manusia memahami konteks dan menemukan pola serangan baru.

Masukkan Keamanan ke Dalam Definition of Done

Keamanan akan terus tertinggal jika selalu ditempatkan sebagai pemeriksaan tambahan setelah sprint selesai.

Tim perlu menjadikannya bagian dari kriteria penyelesaian pekerjaan. Untuk perubahan yang memengaruhi area sensitif, sebuah pekerjaan belum layak dinyatakan selesai hanya karena fitur berjalan dan unit test lulus.

Definition of Done dapat mencakup ketentuan berikut:

• dampak keamanan perubahan telah ditinjau;
• security requirement telah diperbarui;
• skenario negatif telah diuji;
• security test case telah ditambahkan;
• kontrol akses telah diuji menggunakan role yang berbeda;
• temuan berisiko tinggi telah ditangani;
• pengecualian keamanan telah didokumentasikan;
• hasil pengujian dapat ditelusuri kembali.

Cara ini tidak harus menambah proses administrasi yang rumit. Tujuannya adalah memastikan setiap perubahan penting meninggalkan bukti bahwa aspek keamanannya telah diperiksa.

Keamanan Merupakan Tanggung Jawab Bersama

Security regression testing tidak seharusnya dibebankan sepenuhnya kepada tim security.

Product Owner memiliki pemahaman mengenai proses bisnis dan dampak penyalahgunaan. Developer mengetahui bagian kode yang berubah. QA Engineer memahami skenario pengujian dan perilaku aplikasi. DevOps Engineer mengelola pipeline serta lingkungan deployment. Tim security membantu menetapkan standar, memeriksa cakupan, dan menguji risiko yang lebih kompleks.

Kolaborasi tersebut membuat pengujian lebih dekat dengan sumber perubahan.

Developer dapat membuat security unit test untuk kontrol yang dibangunnya. QA Engineer dapat menambahkan skenario negatif ke dalam regression suite. Tim security kemudian memvalidasi apakah pengujian tersebut benar-benar mencerminkan risiko yang perlu dicegah.

Tanpa pembagian tanggung jawab, keamanan mudah berubah menjadi pekerjaan satu tim yang dilakukan menjelang rilis. Pada saat itu, biaya perbaikan sudah lebih tinggi dan jadwal peluncuran mulai menekan proses pengujian.

Jumlah Pemindaian Bukan Ukuran Keamanan

Pipeline yang menjalankan banyak alat belum tentu memberikan perlindungan yang memadai. Nilai security regression test ditentukan oleh kualitas skenario, bukan jumlah pemindaian.

Metrik yang lebih berguna antara lain:

• persentase kontrol kritis yang memiliki test case;
• jumlah temuan lama yang muncul kembali;
• perubahan berisiko yang belum diuji;
• waktu yang dibutuhkan untuk mendeteksi regression;
• cakupan pengujian role dan permission;
• jumlah security test yang tidak stabil;
• kerentanan yang lolos ke production;
• waktu penyelesaian kegagalan security gate.

Metrik tersebut membantu perusahaan melihat apakah proses pengujian benar-benar melindungi aplikasi atau hanya menghasilkan aktivitas teknis tanpa konteks.

Mulai dari Bagian yang Tidak Boleh Gagal

Perusahaan tidak perlu membangun security regression suite yang sangat besar sejak awal. Implementasi dapat dimulai dari fungsi yang memiliki dampak paling besar terhadap bisnis.

Langkah awalnya adalah mengidentifikasi alur kritis, data sensitif, role pengguna, fungsi administratif, dan integrasi utama. Temuan penetration testing serta insiden sebelumnya kemudian dapat diterjemahkan menjadi test case yang dapat dijalankan kembali.

Pengujian ringan ditempatkan pada pull request. Pengujian yang lebih luas dijalankan pada staging atau secara berkala. Perubahan dengan dampak tinggi harus memperoleh pemeriksaan manual sebelum dirilis.

Regression suite juga perlu berkembang. Ketika ditemukan kerentanan baru, skenario pengujiannya harus ditambahkan. Ketika arsitektur berubah, cakupannya perlu diperbarui. Ketika role baru dibuat, matriks otorisasinya harus diperiksa kembali.

Dengan demikian, security regression testing tidak menjadi proyek satu kali, melainkan bagian dari cara perusahaan mengelola perubahan aplikasi.

Keamanan Harus Bergerak Bersama Development

Setiap sprint dapat mengubah cara aplikasi mengenali pengguna, memberikan akses, memproses data, atau terhubung dengan sistem lain. Karena itu, status “pernah diuji” tidak cukup untuk menggambarkan keamanan versi aplikasi terbaru.

Security regression test membantu tim membuktikan bahwa kontrol yang sebelumnya berjalan masih tetap efektif. Namun, pengujian tersebut tetap harus dilengkapi dengan review manual dan penetration testing untuk menemukan ancaman yang belum tercakup dalam skenario lama.

Jika aplikasi berubah setiap sprint, bukti bahwa aplikasi tersebut tetap aman juga harus diperbarui setiap sprint. Dengan cara itulah keamanan berhenti menjadi asumsi dan berubah menjadi kondisi yang dapat diuji.

Perkuat Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz dapat membantu perusahaan mengevaluasi keamanan aplikasi, API, dan infrastruktur melalui layanan Penetration Testing dan Vulnerability Assessment. Fourtrezz juga menyediakan layanan IT Development untuk mendukung pengembangan sistem dengan mempertimbangkan kebutuhan bisnis dan keamanan.

Pengujian dapat disesuaikan dengan karakteristik aplikasi, perubahan sistem, role pengguna, integrasi, serta risiko yang dihadapi perusahaan.

Hubungi Fourtrezz:

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