Sebuah perusahaan mengganti tim pengembang aplikasi internalnya. Repository sudah diserahkan, akses server sudah tersedia, dan aplikasi tetap beroperasi. Secara administratif, proses transisi terlihat selesai.

Beberapa minggu kemudian, tim baru menyederhanakan proses ekspor laporan. Pemeriksaan tambahan yang dianggap memperlambat pekerjaan dihapus. Fitur berjalan lebih cepat, tetapi pengguna kini dapat mengambil data dari cabang yang seharusnya berada di luar kewenangannya.

Ilustrasi tersebut menunjukkan persoalan yang mudah terlewat saat pergantian tim developer: kode berpindah, tetapi alasan di balik keputusan keamanan belum tentu ikut dipindahkan.

Perusahaan biasanya menaruh perhatian pada kelanjutan pekerjaan dan kecepatan adaptasi tim baru. Padahal, kemampuan mempertahankan batas akses, memahami risiko yang belum diselesaikan, dan mengenali bagian sistem yang sensitif sama pentingnya dengan kemampuan menambahkan fitur.

Kode Tidak Selalu Menjelaskan Mengapa Sebuah Pembatasan Dibuat

Tim baru dapat membaca fungsi, menelusuri alur aplikasi, dan memahami hubungan antar komponen. Namun, pemahaman tersebut belum tentu menjawab mengapa suatu pemeriksaan dibuat atau mengapa sebuah integrasi dibatasi.

Sebagian keputusan lahir dari pengalaman yang tidak tercatat dengan baik. Pemeriksaan akses mungkin ditambahkan setelah ditemukan kelemahan. Sebuah endpoint mungkin sengaja dibatasi karena terhubung dengan data sensitif. Proses persetujuan tertentu mungkin dibuat untuk mencegah pengguna menyelesaikan transaksi tanpa kewenangan.

Ketika konteksnya hilang, kontrol tersebut dapat terlihat sebagai kode berulang, proses yang terlalu panjang, atau pengaturan yang tidak diperlukan.

Penelitian Balanced Knowledge Distribution among Software Development Teams—Observations from Open- and Closed-Source Software Development, yang diterbitkan dalam Journal of Software: Evolution and Process pada 2024, membahas kehilangan pengetahuan dan beban adaptasi akibat pergantian developer. Temuan ini memberi dasar untuk melihat transisi tim sebagai persoalan keberlanjutan pengetahuan, bukan sekadar penggantian tenaga kerja.

Dalam konteks keamanan aplikasi, konsekuensinya dapat muncul ketika tim penerus mengubah bagian sistem tanpa memahami perlindungan yang sebelumnya diterapkan.

Celah Dapat Muncul dari Perubahan yang Terlihat Wajar

Pergantian tim developer tidak otomatis membuat aplikasi menjadi rentan. Risiko meningkat ketika hilangnya pengetahuan bertemu dengan kebutuhan untuk segera memperbaiki atau mengembangkan sistem.

Tim baru mungkin diminta mempercepat aplikasi, merapikan kode, atau mengatasi keluhan pengguna. Semua itu merupakan pekerjaan yang wajar. Namun, perubahan yang terlihat sederhana dapat memengaruhi keamanan apabila asumsi dasarnya keliru.

Misalnya, pemeriksaan hak akses pada setiap permintaan dianggap berlebihan karena pengguna sudah melewati proses login. Padahal, login hanya memastikan identitas pengguna. Hak untuk membaca, mengubah, atau menghapus data tetap perlu diperiksa sesuai kewenangannya.

Contoh lain muncul saat tim menambahkan informasi ke dalam log untuk mempermudah penelusuran kesalahan. Jika karakter data tidak dipahami, token akses atau informasi pribadi dapat ikut tercatat.

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

Persoalannya dapat berupa kontrol yang hilang, penerapan yang tidak konsisten, atau perlindungan yang hanya berlaku pada jalur tertentu. Aplikasi masih berjalan, tetapi batas keamanannya berubah tanpa disadari.

Akses Tim Lama Bisa Bertahan Setelah Tanggung Jawabnya Berakhir

Pemindahan pengetahuan perlu berjalan bersama penataan akses. Tim baru membutuhkan kewenangan untuk bekerja, sementara akses tim sebelumnya perlu ditinjau sesuai berakhirnya tanggung jawab mereka.

Dalam praktiknya, perhatian sering berpusat pada akun aplikasi. Padahal, pengelolaan sistem juga melibatkan repository, layanan cloud, VPN, pipeline deployment, penyimpanan cadangan, dan akun integrasi.

Apabila inventaris akses tidak lengkap, perusahaan dapat kehilangan kepastian mengenai siapa yang masih mampu mengubah sistem atau mengambil data.

Kredensial bersama memperbesar kesulitan tersebut. Ketika beberapa orang memakai akun yang sama, perusahaan akan lebih sulit menelusuri tindakan kepada individu tertentu. Mengganti kata sandi satu akun juga belum menyelesaikan masalah apabila token, kunci akses, atau sesi lain masih aktif.

Karena itu, serah terima sistem perlu mencakup pemeriksaan kepemilikan akun, pencabutan akses yang tidak lagi diperlukan, dan penggantian kredensial yang sebelumnya dibagikan. Pelaksanaannya harus terencana agar integrasi yang masih dibutuhkan tetap berfungsi.

Risiko yang Belum Selesai Memerlukan Pemilik Baru

Tidak semua kelemahan langsung diperbaiki ketika ditemukan. Sebagian membutuhkan perubahan besar, menunggu jadwal pemeliharaan, atau bergantung pada pihak lain.

Masalah muncul ketika tim penerus tidak mengetahui kondisi tersebut. Perbaikan sementara dapat dianggap sebagai solusi permanen. Temuan lama kehilangan penanggung jawab. Pengecualian keamanan terus berlaku karena tidak ada yang mengetahui kapan keputusan itu perlu dievaluasi kembali.

NIST melalui Secure Software Development Framework dalam SP 800-218 menekankan pentingnya memelihara kebutuhan keamanan, risiko, dan keputusan desain perangkat lunak. Catatan tersebut membantu menjaga pertimbangan keamanan sepanjang siklus hidup aplikasi.

Penerapannya pada pergantian tim cukup konkret. Tim baru perlu menerima daftar temuan beserta statusnya, alasan penundaan perbaikan, pengendalian sementara, dan pihak yang bertanggung jawab.

Informasi bahwa suatu kelemahan “sudah ditangani” juga perlu diperjelas. Apakah kode sudah diperbaiki? Apakah perbaikannya sudah masuk ke lingkungan produksi? Apakah hasilnya sudah diuji ulang? Tanpa kejelasan tersebut, risiko dapat dinyatakan selesai terlalu cepat.

Dokumentasi Harus Membantu Tim Mengambil Keputusan

Banyaknya dokumen tidak selalu menunjukkan kualitas serah terima. Diagram lama, panduan instalasi yang tidak sesuai, dan daftar akses yang belum diperbarui justru dapat memberikan gambaran keliru.

Dokumentasi sistem perlu menjelaskan kondisi aktual dan membantu tim penerus memahami konsekuensi perubahan. Untuk keamanan aplikasi, informasi penting mencakup:

• Arsitektur sistem dan aliran data, termasuk hubungan dengan layanan eksternal.
• Peran pengguna serta aturan akses terhadap fitur dan data.
• Keputusan keamanan dan alasan pembatasan tertentu diterapkan.
• Pengelolaan akun, kredensial, dan akses lingkungan pengembangan maupun produksi.
• Temuan keamanan, status perbaikan, dan risiko yang masih terbuka.
• Prosedur deployment, pemulihan, serta penanganan gangguan.

Pengetahuan tersebut sebaiknya disertai contoh. Penjelasan bahwa “data dibatasi per cabang” akan lebih berguna jika dilengkapi skenario pengguna yang boleh dan tidak boleh mengakses laporan tertentu.

Dengan begitu, dokumentasi menjadi dasar untuk menilai apakah perubahan berikutnya masih mempertahankan aturan sistem.

Serah Terima Selesai Ketika Pemahaman Sudah Dibuktikan

Sesi presentasi dapat membantu, tetapi kehadiran tim baru belum membuktikan kesiapan mereka mengelola aplikasi.

Perusahaan perlu memberi ruang untuk praktik dan pemeriksaan. Tim penerus dapat diminta menjelaskan kembali alur data, memperagakan deployment di lingkungan pengujian, serta menjalankan skenario akses yang penting.

Misalnya, pengguna cabang A mencoba membaca data cabang B. Akun dengan kewenangan terbatas mencoba menggunakan fungsi administrator. Permintaan ke API dilakukan tanpa identitas yang sesuai.

Tujuannya adalah memastikan bahwa pengetahuan yang disampaikan dapat diterapkan. Ketidakjelasan yang ditemukan perlu dicatat, ditetapkan penanggung jawabnya, dan diselesaikan sebelum perubahan berisiko diterapkan.

Jika waktu transisi terbatas, prioritaskan bagian yang memproses data sensitif, mengatur kewenangan, atau terhubung dengan layanan eksternal. Kedalaman serah terima perlu mengikuti dampak sistem terhadap bisnis.

Pengujian Keamanan Membantu Memeriksa Asumsi Tim Baru

Dokumentasi menjelaskan bagaimana sistem seharusnya bekerja. Pengujian membantu memeriksa apakah perilaku aktualnya sesuai dengan penjelasan tersebut.

Setelah pergantian tim, peninjauan konfigurasi dapat membantu menemukan akses yang tertinggal atau pengaturan yang berubah. Peninjauan kode membantu memeriksa implementasi kontrol. Sementara itu, penetration testing dapat digunakan untuk menguji apakah kelemahan tertentu dapat dimanfaatkan dalam cakupan yang disepakati.

Perhatian perlu diarahkan pada area yang berubah, seperti autentikasi, otorisasi, ekspor data, integrasi API, dan fungsi administratif. Temuan sebelumnya juga perlu ditinjau agar tim baru tidak mengulang masalah yang sama.

Pengujian tidak dapat memulihkan seluruh pengetahuan yang hilang. Namun, hasilnya dapat membantu perusahaan memeriksa asumsi, menentukan prioritas perbaikan, dan membangun pemahaman bersama mengenai kondisi keamanan aplikasi.

Pengetahuan Sistem Perlu Menjadi Aset Perusahaan

Pergantian developer merupakan bagian dari perjalanan sistem. Orang dapat berpindah, kontrak dapat berakhir, dan vendor dapat diganti. Perusahaan perlu memastikan bahwa kemampuan menjaga aplikasi tetap bertahan melewati perubahan tersebut.

Hal ini membutuhkan kebiasaan mencatat keputusan penting, memperbarui dokumentasi saat sistem berubah, dan membagi pemahaman kepada lebih dari satu orang. Kebutuhan serah terima juga perlu ditetapkan sejak awal kerja sama.

Aplikasi yang tetap beroperasi belum cukup menjadi bukti keberhasilan transisi. Perusahaan perlu memastikan tim penerus memahami batas akses, mengetahui risiko yang masih terbuka, dan mampu mempertahankan kontrol ketika pengembangan dilanjutkan.

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk berbagai target, termasuk aplikasi web, aplikasi mobile, API, serta jaringan dan server. Layanan tersebut dapat membantu perusahaan mengevaluasi kelemahan keamanan sesuai kebutuhan dan cakupan pengujian.

Jika perusahaan Anda sedang mengganti tim developer atau vendor pengembangan, bekerja sama dengan Fourtrezz dapat menjadi langkah untuk memeriksa kondisi keamanan sistem dan menentukan prioritas perbaikan sebelum perubahan berikutnya diterapkan.

Hubungi Fourtrezz:

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