Sebuah perusahaan meminta tim pengembang membuat fitur pemulihan kata sandi. Instruksinya terlihat sederhana: pengguna memasukkan alamat email, kemudian sistem mengirimkan tautan untuk membuat kata sandi baru.

Dengan bantuan AI coding assistant, endpoint, formulir, token, dan fungsi pengiriman email dapat dibuat dalam waktu singkat. Pengujian fungsional menunjukkan bahwa fitur tersebut bekerja sesuai permintaan. Pengguna berhasil menerima email dan dapat mengganti kata sandinya.

Namun, tidak ada requirement yang mengatur masa berlaku token, pembatasan percobaan, penggunaan token hanya satu kali, pencabutan sesi lama, perlindungan terhadap account enumeration, maupun pencatatan aktivitas mencurigakan.

Dalam kondisi tersebut, AI tidak gagal mengikuti instruksi. AI justru menjalankan instruksi dengan tepat. Persoalannya terletak pada requirement yang hanya menjelaskan fungsi, tetapi tidak menjelaskan risiko.

Situasi ini memperlihatkan batas penting dalam penggunaan AI coding assistant. Teknologi tersebut dapat mempercepat penulisan kode, tetapi tidak secara otomatis mengetahui keamanan seperti apa yang dibutuhkan oleh perusahaan. AI dapat menghasilkan implementasi berdasarkan konteks yang diberikan, tetapi tidak dapat menjamin bahwa konteks tersebut telah mewakili kebutuhan bisnis, risiko operasional, dan ancaman yang sebenarnya.

Karena itu, perdebatan mengenai apakah AI akan menggantikan developer sering kali dimulai dari pertanyaan yang keliru. Persoalan utama bukan sekadar siapa yang menulis kode. Persoalan yang lebih menentukan adalah siapa yang memahami sistem, mempertanyakan requirement, mengenali asumsi, dan bertanggung jawab atas konsekuensi dari setiap keputusan teknis.

Kecepatan Menulis Kode Bukan Kemampuan Membangun Sistem

AI coding assistant telah mengubah cara banyak tim pengembangan bekerja. Potongan kode yang sebelumnya membutuhkan waktu berjam-jam kini dapat dibuat dalam hitungan menit. Dokumentasi, unit test, konfigurasi, struktur basis data, hingga integrasi API dapat disusun dari instruksi bahasa alami.

Kemampuan tersebut memberikan manfaat produktivitas yang nyata. Developer dapat mengurangi pekerjaan repetitif dan mengalokasikan lebih banyak waktu untuk tugas yang membutuhkan penalaran lebih dalam.

Masalah muncul ketika peningkatan kecepatan dianggap sama dengan peningkatan kemampuan membangun sistem.

Kode hanyalah salah satu bagian dari sebuah aplikasi. Di balik kode terdapat keputusan mengenai arsitektur, kepemilikan data, aturan akses, integrasi, kondisi kegagalan, pemisahan wewenang, mekanisme audit, dan dampak bisnis apabila sistem disalahgunakan.

AI dapat membantu menerjemahkan keputusan tersebut menjadi implementasi. Namun, AI tidak dapat membuat keputusan yang tepat apabila kebutuhan dasarnya tidak pernah dirumuskan secara jelas.

Laporan dan penelitian mengenai AI-assisted development menunjukkan adanya pergeseran hambatan kerja. Ketika produksi kode semakin cepat, beban justru berpindah ke proses pemeriksaan, validasi, dan tata kelola. Organisasi dapat menghasilkan lebih banyak perubahan, tetapi tidak selalu memiliki kapasitas yang memadai untuk memastikan bahwa seluruh perubahan tersebut aman, konsisten, dan dapat dipelihara.

Produktivitas yang hanya diukur dari jumlah kode atau kecepatan penyelesaian tiket berisiko menciptakan gambaran yang menyesatkan. Sebuah fitur dapat selesai lebih cepat, tetapi menghasilkan technical debt, kesalahan arsitektur, dan kerentanan yang baru diketahui setelah aplikasi digunakan secara luas.

AI Tidak Memahami Risiko yang Tidak Pernah Dijelaskan

AI coding assistant bekerja berdasarkan instruksi, konteks repository, pola yang dipelajari, dan batas akses yang diberikan. Teknologi ini dapat mengenali praktik umum, tetapi tidak secara otomatis memahami karakter khusus sebuah perusahaan.

AI tidak mengetahui data mana yang dianggap paling sensitif oleh organisasi. AI juga tidak mengetahui bahwa perubahan tertentu harus disetujui oleh dua pihak, transaksi tertentu tidak boleh dilakukan oleh pengguna yang sama, atau aktivitas tertentu wajib meninggalkan audit trail yang tidak dapat diubah.

Pertimbangkan requirement berikut:

Administrator dapat mengubah rekening pencairan milik mitra.

AI dapat menghasilkan halaman formulir, endpoint pembaruan, validasi nomor rekening, serta fungsi penyimpanan ke basis data. Dari sisi fungsional, pekerjaan tersebut terlihat selesai.

Namun, apakah perubahan rekening harus memerlukan autentikasi ulang? Apakah pemilik akun perlu menerima notifikasi? Apakah perubahan harus menunggu persetujuan pengguna lain? Apakah rekening lama harus tetap tersimpan untuk kebutuhan audit? Apakah aktivitas tersebut perlu ditunda selama periode tertentu untuk mengurangi risiko pengambilalihan akun?

Tanpa jawaban atas pertanyaan tersebut, aplikasi mungkin berjalan tetapi tetap membuka peluang terjadinya penipuan.

AI tidak memiliki dasar untuk menerapkan kontrol yang tidak pernah diminta. Bahkan ketika AI menambahkan mekanisme keamanan secara mandiri, perusahaan tidak dapat bergantung pada asumsi bahwa mekanisme tersebut selalu sesuai dengan profil risiko bisnis.

Kualitas keamanan akhirnya tetap ditentukan oleh kemampuan manusia dalam mengenali aset, ancaman, konsekuensi, serta batas kepercayaan di dalam sistem.

Requirement Fungsional yang Benar Belum Tentu Aman

Banyak requirement aplikasi ditulis untuk menjelaskan hasil yang harus dilihat pengguna. Pengguna dapat masuk ke akun, mengunggah dokumen, mengekspor laporan, mengubah profil, atau menyetujui transaksi.

Format tersebut diperlukan, tetapi belum cukup.

Requirement “pengguna dapat mengunggah dokumen PDF”, misalnya, dapat menghasilkan fitur yang berfungsi dengan baik. Namun, kalimat itu belum menjelaskan batas ukuran berkas, validasi tipe konten, penggantian nama berkas, lokasi penyimpanan, pemindaian malware, pembatasan frekuensi, dan pihak yang dapat mengakses hasil unggahan.

Requirement yang lebih matang perlu menjelaskan perilaku keamanan secara konkret. Contohnya, hanya pengguna yang telah terautentikasi yang dapat mengunggah berkas. Sistem harus memvalidasi isi berkas, bukan sekadar ekstensinya. Berkas perlu disimpan di luar direktori publik, diberi nama baru oleh sistem, dipindai, dan dicatat dalam audit log.

Kedua requirement tersebut membahas fitur yang sama, tetapi menghasilkan tingkat risiko yang sangat berbeda.

Hal serupa berlaku untuk autentikasi. Requirement “pengguna dapat login menggunakan email dan kata sandi” belum mengatur pembatasan percobaan, kebijakan kata sandi, pengelolaan sesi, multi-factor authentication, perlindungan brute force, atau prosedur pemulihan akun.

Masalahnya bukan sekadar ketidaklengkapan dokumentasi. Requirement yang tidak memuat security requirement dapat mengarahkan developer maupun AI untuk membangun sistem berdasarkan jalur penggunaan normal dan mengabaikan jalur penyalahgunaan.

Inilah alasan keamanan tidak dapat ditambahkan hanya melalui satu kalimat seperti “sistem harus aman”. Keamanan harus diterjemahkan menjadi perilaku yang spesifik, dapat diterapkan, dan dapat diuji.

Prompt yang Baik Tidak Dapat Menyelamatkan Requirement yang Buruk

Kemampuan menulis prompt sering dipandang sebagai jawaban terhadap berbagai keterbatasan AI. Semakin rinci instruksinya, semakin baik pula hasil yang diharapkan.

Dalam konteks coding, anggapan tersebut hanya benar sebagian.

Prompt dapat membantu AI memahami framework, bahasa pemrograman, pola desain, format keluaran, dan batas tugas. Namun, prompt engineering tidak menggantikan requirement engineering.

Instruksi “buat API autentikasi yang aman” masih menyimpan terlalu banyak ruang interpretasi. Kata “aman” tidak menjelaskan metode autentikasi, masa berlaku token, rotasi refresh token, proteksi brute force, pengelolaan perangkat, mekanisme logout, pencabutan sesi, maupun kebutuhan audit.

AI mungkin menerapkan pendekatan yang umum digunakan. Namun, pendekatan umum belum tentu sesuai dengan kebutuhan aplikasi kesehatan, sistem pemerintahan, platform pendidikan, aplikasi keuangan, atau sistem internal perusahaan.

Requirement bukan sekadar instruksi untuk menghasilkan kode. Requirement merupakan kesepakatan mengenai siapa yang dapat melakukan sesuatu, dalam kondisi apa tindakan tersebut diizinkan, data apa yang terlibat, bagaimana kegagalan ditangani, dan risiko apa yang tidak dapat diterima.

Prompt menjelaskan pekerjaan kepada AI. Requirement menjelaskan tanggung jawab sistem kepada organisasi dan penggunanya.

Menyamakan keduanya akan membuat perusahaan merasa telah memberikan konteks yang cukup, padahal sebagian besar keputusan penting belum pernah dibahas.

Requirement yang Kabur Membuat Asumsi Menyebar Lebih Cepat

Developer manusia juga dapat salah memahami requirement. Kesalahan asumsi bukan persoalan baru dalam software development.

Perbedaannya terletak pada kecepatan dan skala.

Tanpa AI, sebuah asumsi yang keliru mungkin berkembang secara bertahap ketika developer menulis kode, berdiskusi dengan tim, dan menjalani proses review. Dengan AI coding assistant, asumsi yang sama dapat dengan cepat diterjemahkan menjadi berbagai fungsi, test case, dokumentasi, konfigurasi, skema basis data, dan integrasi.

Hasilnya terlihat lengkap sehingga tim dapat terlambat menyadari bahwa fondasi awalnya salah.

AI dapat menghasilkan unit test yang membuktikan bahwa kode bekerja sesuai implementasi. Akan tetapi, unit test tersebut belum tentu membuktikan bahwa implementasi sesuai dengan kebutuhan bisnis yang sebenarnya.

Jika requirement hanya menggambarkan happy path, AI dapat membantu membangun happy path dengan sangat efisien. Sementara itu, kondisi kegagalan, penyalahgunaan fitur, konflik hak akses, serta manipulasi logika bisnis tetap tidak terpetakan.

Dengan kata lain, AI bukan selalu pencipta kesalahan baru. Dalam banyak kasus, AI menjadi pengganda terhadap kelemahan lama dalam proses pengembangan.

Requirement yang buruk dahulu menghasilkan kode buruk secara perlahan. Kini, requirement yang sama dapat menghasilkan lebih banyak kode sebelum organisasi menyadari bahwa masalahnya tidak berada pada sintaks, tetapi pada keputusan awal.

Developer Tetap Dibutuhkan karena Sistem Memerlukan Penilaian

Nilai developer tidak seharusnya diukur hanya dari jumlah baris kode yang dapat ditulis. Ketika AI semakin mampu mengambil alih aktivitas implementasi tertentu, peran developer justru bergeser menuju wilayah yang lebih kritis.

Developer perlu memahami proses bisnis, mengidentifikasi asumsi, merancang arsitektur, menentukan trust boundary, mengevaluasi dependency, dan memastikan bahwa keluaran AI sesuai dengan standar organisasi.

Developer juga harus mampu menolak requirement yang secara fungsional terlihat sederhana tetapi mengandung risiko besar.

Misalnya, permintaan agar pengguna tertentu dapat mengekspor seluruh data pelanggan bukan hanya persoalan menambahkan tombol dan fungsi unduh. Developer perlu mempertanyakan siapa yang boleh menggunakan fitur tersebut, data apa yang boleh diekspor, apakah diperlukan persetujuan, bagaimana aktivitas dicatat, dan bagaimana mencegah ekspor massal oleh akun yang telah diambil alih.

Kemampuan tersebut tidak dapat digantikan hanya dengan code generation.

Sejumlah penelitian terbaru tentang praktik AI-assisted development memperlihatkan bahwa pekerjaan developer mulai bergerak menuju supervisory engineering. Developer semakin banyak mengarahkan, mengevaluasi, mengoreksi, dan memvalidasi hasil AI.

Perubahan ini tidak menghilangkan kebutuhan terhadap developer. Sebaliknya, perubahan tersebut mengurangi nilai pekerjaan yang hanya berfokus pada sintaks dan meningkatkan nilai penalaran teknis, pemahaman bisnis, serta kemampuan menilai risiko.

Semakin murah kode diproduksi, semakin penting kemampuan menentukan kode apa yang seharusnya dibuat dan kode apa yang seharusnya tidak pernah diterapkan.

Keamanan Berisiko Bergeser Menjadi Aktivitas Reaktif

Penelitian terhadap perilaku software engineer dalam menggunakan AI coding assistant menemukan gejala yang patut diperhatikan. Keamanan cenderung bergeser dari pertimbangan saat menulis kode menjadi aktivitas pemeriksaan setelah kode dihasilkan.

Developer mungkin memiliki pengetahuan mengenai keamanan, tetapi tidak selalu memasukkan security requirement ke dalam instruksi awal. Setelah AI menghasilkan kode fungsional, barulah mereka memeriksa apakah terdapat masalah.

Pola ini mengubah keamanan dari pendekatan preventif menjadi reaktif.

Ketika kode sudah terlihat bekerja, tim dapat mengalami bias konfirmasi. Perhatian lebih mudah diarahkan pada penyempurnaan implementasi daripada mempertanyakan apakah desain awalnya benar.

Kondisi tersebut semakin berbahaya apabila tekanan penyelesaian proyek tinggi. Hasil AI yang tampak rapi dapat segera dianggap sebagai fondasi yang layak, meskipun belum melalui threat modeling atau penilaian security requirement.

Penelitian lain terhadap coding agent menemukan adanya tindakan tidak aman dalam sebagian proses penyelesaian tugas. Risiko yang ditemukan mencakup paparan informasi dan keputusan implementasi yang tidak aman. Temuan semacam ini tidak berarti seluruh kode buatan AI pasti rentan, tetapi membuktikan bahwa kecepatan dan kecanggihan model tidak dapat digunakan sebagai pengganti pengawasan.

AI perlu diperlakukan sebagai kontributor yang hasilnya harus diperiksa, bukan sebagai otoritas keamanan.

Code Review Tidak Cukup Jika Hanya Memeriksa Kerapian Kode

Banyak organisasi mengandalkan code review sebagai kontrol utama terhadap kode yang dihasilkan AI. Pendekatan tersebut diperlukan, tetapi efektivitasnya bergantung pada apa yang sebenarnya diperiksa.

Review yang hanya menilai struktur kode, konsistensi penamaan, performa, error handling, dan keberhasilan unit test tidak cukup untuk menemukan risiko pada logika bisnis.

Kerentanan seperti broken access control, privilege escalation, kebocoran data lintas tenant, manipulasi transaksi, atau konflik pemisahan tugas membutuhkan pemahaman terhadap konteks sistem.

Reviewer perlu mengetahui siapa yang seharusnya memiliki akses, data apa yang boleh dilihat, tindakan apa yang memerlukan persetujuan, serta bagaimana sistem merespons skenario penyalahgunaan.

Tanpa security requirement dan threat model, reviewer hanya dapat menilai apakah kode terlihat masuk akal. Mereka tidak memiliki tolok ukur yang cukup untuk membuktikan bahwa kode telah menjalankan aturan keamanan yang benar.

Studi mengenai kemampuan AI untuk melakukan code review juga menunjukkan bahwa alat berbasis AI dapat melewatkan kerentanan kritis dan lebih banyak memberikan perhatian pada persoalan dengan tingkat risiko rendah. Hal ini menegaskan bahwa AI code review tidak dapat menjadi satu-satunya lapisan kontrol.

Static application security testing, dependency scanning, dan secret scanning tetap diperlukan. Namun, kontrol otomatis tersebut juga tidak sepenuhnya memahami risiko bisnis.

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

Aplikasi dapat memiliki struktur kode yang rapi dan lolos pemindaian otomatis, tetapi tetap mengandung kelemahan pada otorisasi, alur persetujuan, pengelolaan sesi, atau pemisahan data pengguna.

Security Requirement Harus Dapat Dibuktikan

Kalimat seperti “sistem harus aman”, “data harus dienkripsi”, atau “hanya pengguna berwenang yang dapat mengakses” terdengar benar, tetapi belum cukup menjadi requirement.

Sebuah security requirement perlu ditulis agar dapat diterapkan dan diuji.

Alih-alih menyatakan bahwa hanya pengguna berwenang yang dapat mengakses data, requirement perlu menentukan hubungan antara identitas pengguna, peran, organisasi, dan objek data yang dapat diakses.

Alih-alih menyatakan bahwa aktivitas penting harus dicatat, requirement perlu menjelaskan aktivitas apa yang dicatat, informasi apa yang disimpan, siapa yang dapat membaca log, berapa lama log dipertahankan, dan bagaimana log dilindungi dari perubahan.

Requirement yang dapat diuji juga perlu mencakup kondisi negatif. Sistem tidak hanya harus membuktikan bahwa pengguna yang tepat dapat melakukan suatu tindakan, tetapi juga bahwa pengguna yang salah tidak dapat melakukannya.

Prinsip tersebut penting dalam pengembangan dengan AI. Semakin jelas acceptance criteria yang diberikan, semakin kecil ruang bagi AI untuk mengisi kekosongan dengan asumsi.

Keamanan yang tidak dapat diuji pada akhirnya hanya menjadi harapan.

Secure SDLC Menjadi Semakin Relevan

Kehadiran AI tidak membuat secure software development life cycle kehilangan relevansinya. Sebaliknya, AI membuat disiplin tersebut semakin penting.

NIST melalui Secure Software Development Framework menekankan bahwa praktik keamanan perlu diintegrasikan ke dalam seluruh siklus pengembangan. Keamanan tidak cukup ditempatkan sebagai pemeriksaan tambahan sebelum aplikasi dirilis.

Sebelum coding dimulai, organisasi perlu melakukan pemetaan proses bisnis, klasifikasi data, penyusunan security requirement, threat modeling, dan identifikasi abuse case.

Selama tahap pengembangan, perusahaan membutuhkan secure coding guideline, dependency governance, peer review, static analysis, secret scanning, dan kebijakan penggunaan AI coding assistant.

Sebelum aplikasi masuk ke lingkungan produksi, diperlukan pengujian dinamis, pengujian API, pemeriksaan konfigurasi, penetration testing, remediasi, serta re-test.

Kerangka seperti OWASP Top 10 dapat membantu tim mengenali kategori risiko umum, tetapi tetap perlu diterjemahkan sesuai dengan arsitektur dan konteks aplikasi.

Secure SDLC juga harus mengatur data apa yang boleh dikirimkan ke layanan AI. Developer dapat tanpa sengaja memasukkan source code, konfigurasi, informasi pelanggan, secret, atau detail arsitektur ke dalam prompt. Dengan demikian, risikonya tidak hanya berasal dari kode yang dihasilkan, tetapi juga dari informasi yang diberikan kepada alat tersebut.

AI Coding Assistant Membutuhkan Guardrail Organisasi

Mengandalkan kehati-hatian setiap developer bukan strategi tata kelola yang memadai. Perusahaan perlu menetapkan guardrail yang berlaku konsisten bagi seluruh tim.

Kebijakan tersebut setidaknya perlu menjelaskan AI coding assistant yang boleh digunakan, jenis repository yang dapat diakses, klasifikasi data yang tidak boleh dimasukkan, serta siapa yang bertanggung jawab memeriksa hasilnya.

Organisasi juga perlu menentukan kapan AI-generated code harus melalui review tambahan. Perubahan yang berkaitan dengan autentikasi, otorisasi, kriptografi, pembayaran, data sensitif, dan konfigurasi infrastruktur seharusnya mendapatkan perhatian lebih tinggi.

Hak akses AI coding agent harus mengikuti prinsip least privilege. Agent tidak seharusnya memperoleh akses luas ke repository, secret, terminal, layanan produksi, atau pipeline tanpa pembatasan dan pencatatan yang memadai.

Semakin otonom sebuah coding agent, semakin besar kebutuhan terhadap approval, isolasi lingkungan, audit log, dan kemampuan menghentikan tindakan yang tidak diinginkan.

Perusahaan juga perlu menetapkan bahwa hasil AI bukan bukti bahwa sebuah kontrol telah diterapkan dengan benar. Setiap kontrol penting harus dapat diverifikasi melalui pengujian.

Guardrail tidak bertujuan menghambat inovasi. Guardrail diperlukan agar peningkatan kecepatan tidak mengorbankan keamanan, maintainability, dan akuntabilitas.

Risiko Terbesar Terletak pada Kepercayaan yang Tidak Diuji

Ancaman terbesar dari AI coding assistant bukan hanya kemungkinan model menghasilkan kode rentan. Risiko yang lebih sulit terlihat adalah munculnya kepercayaan diri berlebihan.

Kode yang dihasilkan AI sering terlihat terstruktur, lengkap, dan meyakinkan. AI juga dapat memberikan penjelasan yang terdengar logis mengenai alasan di balik implementasi tersebut.

Namun, kerapian keluaran tidak membuktikan bahwa desainnya aman.

Keberhasilan unit test tidak membuktikan bahwa aturan akses telah dirancang dengan tepat. Hasil pemindaian tanpa temuan kritis tidak membuktikan bahwa logika bisnis tidak dapat dimanipulasi. Klaim bahwa suatu implementasi mengikuti best practice juga tidak membuktikan bahwa praktik tersebut sesuai dengan kebutuhan perusahaan.

Keamanan aplikasi tidak dapat dinilai hanya dari cara kode ditulis. Keamanan harus dilihat dari hubungan antara requirement, arsitektur, implementasi, konfigurasi, integrasi, dan perilaku sistem ketika menghadapi penyalahgunaan.

Perusahaan perlu mempertahankan sikap kritis terhadap setiap keluaran AI. Bukan karena AI selalu salah, tetapi karena keputusan penting tidak boleh dipercayakan kepada sistem yang tidak menanggung konsekuensi dari kesalahannya.

Masa Depan Developer Ditentukan oleh Kualitas Keputusan

AI coding assistant akan terus berkembang. Teknologi ini akan semakin mampu membuat fitur, memperbaiki bug, menghasilkan test case, membaca repository, dan mengajukan perubahan secara mandiri.

Perkembangan tersebut tidak seharusnya ditolak. AI dapat menjadi alat yang sangat berharga ketika ditempatkan dalam proses pengembangan yang matang.

Namun, semakin mudah kode diproduksi, semakin penting kualitas keputusan sebelum kode tersebut ditulis.

Developer tetap dibutuhkan untuk memahami proses bisnis, menilai risiko, menyusun requirement yang dapat diuji, merancang arsitektur, dan memastikan setiap keluaran AI sesuai dengan kepentingan organisasi.

Perusahaan juga tetap membutuhkan proses pengujian independen untuk melihat aplikasi dari sudut pandang penyerang, bukan hanya dari sudut pandang pembuatnya.

AI dapat membantu menjawab bagaimana sebuah fitur dibangun. Developer, business analyst, security engineer, dan pemilik sistem tetap harus menentukan fitur apa yang layak dibangun, siapa yang boleh menggunakannya, risiko apa yang harus dikendalikan, dan bukti apa yang diperlukan untuk menyatakan bahwa sistem tersebut aman.

Dalam era ketika kode semakin murah untuk diproduksi, kualitas requirement, ketepatan arsitektur, dan kedalaman pengujian justru menjadi bagian yang paling menentukan.

Bangun Aplikasi yang Tidak Hanya Cepat, tetapi Juga Aman

Penggunaan AI coding assistant perlu diimbangi dengan requirement yang matang, secure SDLC, pengawasan developer, dan pengujian keamanan yang menyeluruh. Tanpa fondasi tersebut, percepatan pengembangan justru dapat memperbesar risiko yang tersembunyi di dalam aplikasi.

Fourtrezz membantu perusahaan membangun dan menguji sistem digital melalui layanan penetration testing, vulnerability assessment, pengembangan aplikasi, serta layanan keamanan siber yang disesuaikan dengan kebutuhan organisasi. Pendekatan berbasis keamanan membantu memastikan bahwa aplikasi tidak hanya berfungsi, tetapi juga dirancang dan diuji dengan mempertimbangkan risiko sejak awal.

Untuk mendiskusikan kebutuhan penetration testing, pengujian keamanan aplikasi, maupun pengembangan sistem berbasis secure by design, hubungi Fourtrezz melalui:

Hubungi Fourtrezz:

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