Dalam metode Agile, pengembangan perangkat lunak dilakukan secara bertahap melalui serangkaian sprint. Setiap sprint memiliki target yang jelas, mulai dari menambahkan fitur baru, memperbaiki bug, hingga meningkatkan performa aplikasi. Pendekatan ini membuat tim dapat merespons perubahan dengan cepat tanpa harus menunggu seluruh proyek selesai.
Di balik kecepatan tersebut, ada satu hal yang sering luput dari perhatian, yaitu keamanan. Ketika fokus utama adalah menyelesaikan pekerjaan sesuai target sprint, pembahasan mengenai potensi ancaman kadang baru dilakukan menjelang aplikasi dirilis. Padahal, setiap perubahan pada sistem, sekecil apa pun, dapat menghadirkan risiko baru jika tidak dievaluasi dengan baik.
Karena itu, semakin banyak tim yang mulai memasukkan threat modelling ke dalam setiap sprint. Proses ini membantu tim mengenali potensi ancaman sejak awal sehingga keamanan dapat berjalan seiring dengan pengembangan, bukan menjadi pekerjaan tambahan di akhir proyek.
1. Mulai dari Sprint Planning
Penerapan threat modelling sebaiknya dimulai saat Sprint Planning. Ketika tim menentukan daftar pekerjaan yang akan dikerjakan, mereka juga perlu melihat apakah fitur baru membawa risiko keamanan tertentu.
Misalnya, jika sprint kali ini berfokus pada fitur login baru, tim dapat mendiskusikan beberapa pertanyaan sederhana seperti:
- Apakah proses autentikasi sudah cukup aman?
- Data apa saja yang akan diproses?
- Siapa yang boleh mengakses fitur tersebut?
- Apakah ada kemungkinan penyalahgunaan?
Diskusi singkat ini biasanya hanya membutuhkan beberapa menit, tetapi dapat membantu tim menemukan risiko sejak awal.
2. Pahami Perubahan yang Akan Dilakukan
Tidak semua sprint memiliki tingkat risiko yang sama. Ada sprint yang hanya berisi perbaikan tampilan, tetapi ada juga yang menambahkan fitur penting seperti pembayaran, manajemen pengguna, atau integrasi dengan layanan pihak ketiga.
Karena itu, sebelum pengembangan dimulai, tim perlu memahami perubahan apa saja yang akan dilakukan dan bagaimana perubahan tersebut memengaruhi sistem yang sudah ada.
Dengan mengetahui ruang lingkup pekerjaan, proses identifikasi ancaman menjadi lebih terarah dan tidak membahas hal-hal yang tidak relevan.
3. Identifikasi Ancaman pada Fitur Baru
Setelah memahami perubahan yang akan dilakukan, langkah berikutnya adalah mengidentifikasi ancaman yang mungkin muncul.
Beberapa hal yang dapat diperhatikan antara lain:
- akses tanpa izin ke fitur tertentu;
- kebocoran data pengguna;
- penyalahgunaan hak akses;
- kesalahan validasi data masukan;
- komunikasi data yang tidak terlindungi;
- integrasi API yang belum memiliki mekanisme keamanan yang memadai.
Fokuslah pada ancaman yang berkaitan langsung dengan pekerjaan dalam sprint tersebut agar proses analisis tetap sederhana dan efisien.
4. Tentukan Prioritas Risiko
Tidak semua ancaman harus ditangani sekaligus. Setelah daftar risiko dibuat, tim perlu menentukan mana yang paling penting untuk diselesaikan.
Biasanya, ancaman dengan dampak besar atau peluang terjadinya yang tinggi menjadi prioritas utama. Dengan cara ini, waktu dalam sprint dapat dimanfaatkan secara lebih efektif tanpa mengurangi kualitas keamanan.
Pendekatan ini juga membantu tim menjaga keseimbangan antara target pengembangan dan upaya perlindungan sistem.
5. Terapkan Mitigasi Selama Pengembangan
Hasil threat modelling sebaiknya langsung diterapkan ketika proses pengembangan berlangsung, bukan ditunda hingga sprint berikutnya.
Contohnya, developer dapat:
- menerapkan autentikasi yang lebih kuat;
- membatasi hak akses berdasarkan peran pengguna;
- melakukan validasi seluruh data masukan;
- mengenkripsi data sensitif;
- menambahkan pencatatan aktivitas (logging) untuk mempermudah pemantauan.
Dengan begitu, perlindungan sudah menjadi bagian dari implementasi fitur sejak awal.
6. Verifikasi pada Sprint Review
Ketika sprint selesai, tim biasanya mengadakan Sprint Review untuk menunjukkan hasil pekerjaan. Momen ini juga dapat dimanfaatkan untuk memastikan bahwa risiko yang sebelumnya telah diidentifikasi benar-benar sudah ditangani.
Jika masih ditemukan kekurangan, tim dapat mencatatnya sebagai pekerjaan pada sprint berikutnya. Pendekatan ini membuat peningkatan keamanan berlangsung secara bertahap tanpa mengganggu ritme pengembangan.
7. Dokumentasikan Hasilnya
Walaupun dilakukan secara sederhana, hasil threat modelling tetap perlu didokumentasikan.
Dokumentasi tersebut dapat berisi:
- ancaman yang ditemukan;
- tingkat risiko;
- langkah mitigasi yang dipilih;
- keputusan yang diambil selama sprint.
Catatan ini akan sangat membantu ketika tim melakukan pengembangan lanjutan atau saat anggota baru bergabung dalam proyek.
8. Contoh Penerapan
Sebuah tim sedang mengembangkan fitur unggah dokumen pada aplikasi administrasi perusahaan. Fitur tersebut dijadwalkan selesai dalam satu sprint.
Saat Sprint Planning, tim menyadari bahwa pengguna dapat mengunggah berbagai jenis berkas. Dari hasil threat modelling, muncul beberapa risiko, seperti kemungkinan mengunggah file berbahaya, akses dokumen oleh pengguna yang tidak berwenang, serta ukuran file yang terlalu besar hingga mengganggu layanan.
Selama proses pengembangan, developer menambahkan pembatasan jenis file, pemeriksaan ukuran berkas, pengaturan hak akses berdasarkan peran pengguna, dan pencatatan aktivitas unggah. Ketika sprint selesai, fitur tidak hanya berfungsi sesuai kebutuhan, tetapi juga memiliki perlindungan dasar terhadap beberapa ancaman yang telah diidentifikasi sebelumnya.
KESIMPULAN
Banyak tim menganggap threat modelling akan memperlambat proses pengembangan. Padahal, jika diterapkan secara sederhana dan fokus pada pekerjaan yang sedang dikerjakan, proses ini justru membantu mengurangi masalah di kemudian hari.
Dengan menjadikan threat modelling sebagai bagian dari setiap sprint, tim dapat mengenali risiko lebih awal, menentukan langkah mitigasi yang tepat, dan membangun kebiasaan untuk selalu mempertimbangkan keamanan dalam setiap perubahan. Pada akhirnya, sprint tidak hanya menghasilkan fitur baru, tetapi juga menghasilkan aplikasi yang lebih aman, lebih stabil, dan lebih siap digunakan dalam jangka panjang.
