Sebuah aplikasi internal dapat lahir tanpa proyek formal, tanpa antrian pengembangan, bahkan tanpa keterlibatan tim IT sejak awal.

Seorang staf operasional melihat proses persetujuan yang masih bergantung pada lembar kerja, surat elektronik, dan percakapan melalui aplikasi pesan. Ia kemudian menggunakan platform low-code untuk membuat formulir, menghubungkannya dengan penyimpanan data, menambahkan automasi persetujuan, lalu membagikannya kepada rekan kerja.

Dalam hitungan hari, proses yang sebelumnya manual menjadi lebih cepat.

Aplikasi tersebut dianggap berhasil karena dapat digunakan. Pengguna bertambah, data yang diproses semakin banyak, dan aplikasi perlahan menjadi bagian penting dari kegiatan operasional perusahaan.

Namun, tidak ada yang memeriksa apakah hak aksesnya sudah dibatasi dengan benar. Tidak ada klasifikasi terhadap data yang disimpan. Tidak ada pengujian terhadap integrasi yang digunakan. Tim keamanan bahkan mungkin baru mengetahui keberadaan aplikasi tersebut setelah muncul masalah.

Di sinilah persoalan low-code dimulai.

Masalahnya bukan terletak pada kemampuan pengguna bisnis membangun aplikasi. Persoalan sebenarnya muncul ketika perusahaan memberikan kemampuan tersebut tanpa menetapkan batas keputusan yang boleh mereka ambil.

Low-code memang mempercepat digitalisasi. Pada saat yang sama, teknologi ini juga memindahkan sebagian keputusan mengenai data, akses, integrasi, konfigurasi, dan distribusi aplikasi kepada pengguna bisnis yang belum tentu memiliki pemahaman keamanan aplikasi.

Kecepatan Development Tidak Pernah Benar-Benar Gratis

Low-code menawarkan jawaban terhadap salah satu persoalan paling umum dalam transformasi digital: kebutuhan bisnis berkembang lebih cepat daripada kapasitas tim developer.

Divisi operasional membutuhkan aplikasi pencatatan. Tim sumber daya manusia menginginkan automasi persetujuan. Bagian pemasaran membutuhkan dashboard. Tim keuangan ingin mengurangi proses manual. Sementara itu, tim IT harus menangani pemeliharaan sistem, integrasi, permintaan pengguna, keamanan, dan berbagai proyek prioritas lainnya.

Dalam situasi tersebut, low-code terlihat sebagai jalan keluar yang rasional.

Pengguna bisnis dapat membangun aplikasi sederhana tanpa menunggu proses development konvensional. Mereka dapat menerjemahkan pengetahuan operasional menjadi formulir, dashboard, workflow, atau automasi dengan lebih cepat.

Namun, percepatan pada tahap pembangunan tidak menghilangkan kebutuhan engineering.

Aplikasi tetap membutuhkan pengelolaan identitas, kontrol akses, perlindungan data, dokumentasi, pemantauan, pengujian, pengelolaan perubahan, dan mekanisme pemulihan. Perbedaannya, kebutuhan tersebut tidak selalu terlihat karena kompleksitas teknis disembunyikan di balik antarmuka visual.

Perusahaan kemudian berisiko menyamakan sedikitnya kode dengan sedikitnya risiko.

Padahal, aplikasi yang dibangun melalui drag-and-drop tetap dapat terhubung dengan basis data, API, akun layanan, penyimpanan cloud, surat elektronik, sistem keuangan, dan data pelanggan. Dampaknya dapat sama seriusnya dengan aplikasi yang dikembangkan menggunakan kode secara konvensional.

Low-code menurunkan hambatan untuk membangun aplikasi. Teknologi ini tidak otomatis menurunkan konsekuensi ketika aplikasi tersebut salah dikonfigurasi atau disalahgunakan.

Ketika Pengguna Bisnis Menjadi Developer, Keputusan Keamanan Ikut Berpindah

Citizen developer biasanya memahami proses bisnis dengan sangat baik.

Mereka mengetahui tahapan persetujuan, pihak yang terlibat, informasi yang diperlukan, serta masalah operasional yang ingin diselesaikan. Pengetahuan tersebut membuat mereka mampu menghasilkan aplikasi yang relevan dengan kebutuhan sehari-hari.

Namun, membangun aplikasi tidak hanya berarti menyusun formulir dan workflow.

Dalam proses tersebut, citizen developer dapat membuat sejumlah keputusan yang memiliki konsekuensi keamanan, antara lain:

• data apa yang akan dikumpulkan;
• tempat data akan disimpan;
• pihak yang dapat membaca atau mengubah data;
• aplikasi dan konektor yang dapat mengakses informasi;
• akun yang digunakan untuk menjalankan automasi;
• cara aplikasi dibagikan kepada pengguna;
• pihak eksternal yang memperoleh akses;
• sistem internal yang akan diintegrasikan;
• tindakan yang dapat dilakukan oleh setiap peran;
• kondisi yang memicu persetujuan atau transaksi.

Keputusan tersebut mungkin terlihat sederhana pada layar konfigurasi. Akan tetapi, setiap pilihan dapat memengaruhi kerahasiaan, integritas, dan ketersediaan informasi.

Sebuah tombol “bagikan kepada seluruh organisasi” dapat membuka data lebih luas daripada yang dibutuhkan. Sebuah konektor dapat memperoleh akses terhadap kotak surat atau penyimpanan dokumen. Sebuah akun layanan dapat memiliki hak yang terlalu besar. Sebuah kesalahan logika dapat memungkinkan pengguna melewati tahapan persetujuan.

Pengguna bisnis tidak dapat disalahkan apabila perusahaan tidak pernah memberikan batasan, standar, atau pelatihan yang memadai.

Persoalannya bukan bahwa mereka tidak layak membangun aplikasi. Persoalannya adalah organisasi memindahkan keputusan berisiko tinggi ke tangan pengguna tanpa selalu memindahkan pengetahuan dan kontrol yang diperlukan.

Antarmuka Sederhana Dapat Menyembunyikan Arsitektur yang Rumit

Salah satu daya tarik utama platform low-code adalah kesederhanaannya.

Pengguna dapat melihat formulir, tabel, tombol, kondisi, dan alur kerja secara visual. Kompleksitas teknis yang biasanya dihadapi developer disederhanakan menjadi pilihan konfigurasi.

Kesederhanaan tersebut sangat membantu produktivitas. Namun, ia juga dapat menciptakan persepsi yang keliru bahwa aplikasi yang dibuat memiliki arsitektur sederhana.

Di balik sebuah formulir internal dapat terdapat hubungan dengan beberapa sistem sekaligus. Data mungkin disimpan pada layanan cloud, diteruskan melalui API, diproses oleh automasi, dikirim melalui surat elektronik, lalu digunakan sebagai dasar pengambilan keputusan.

Semakin banyak koneksi yang dibuat, semakin luas pula permukaan serangannya.

Kesalahan pada satu komponen dapat memengaruhi keseluruhan proses. Konektor dengan izin berlebihan dapat membuka akses ke data lain. Akun yang digunakan bersama dapat menyulitkan audit. API tanpa kontrol yang memadai dapat dieksploitasi. Automasi yang berjalan dengan hak istimewa dapat digunakan untuk melakukan tindakan yang seharusnya tidak tersedia bagi pengguna biasa.

Karena itu, kemudahan membangun tidak boleh disamakan dengan kemudahan mengamankan.

Platform dapat menyederhanakan pekerjaan teknis, tetapi tidak dapat menggantikan seluruh proses penilaian risiko.

Risiko Terbesar Tidak Selalu Berasal dari Kerentanan Platform

Ketika membahas keamanan low-code, perusahaan sering berfokus pada satu pertanyaan: apakah platform yang digunakan aman?

Pertanyaan tersebut penting, tetapi belum cukup.

Platform enterprise umumnya telah menyediakan berbagai fitur keamanan, seperti pengelolaan identitas, kontrol akses, pemisahan environment, audit log, pemantauan, perlindungan data, dan kebijakan penggunaan konektor.

Namun, tersedianya fitur keamanan tidak selalu menghasilkan aplikasi yang aman.

Risiko low-code dapat dibagi menjadi tiga lapisan.

Risiko pada Platform

Risiko ini berkaitan dengan layanan utama yang digunakan untuk membangun dan menjalankan aplikasi. Di dalamnya termasuk pengaturan tenant, pemisahan environment, autentikasi administrator, konfigurasi jaringan, kebijakan konektor, pencatatan aktivitas, dan pengelolaan pembaruan.

Kesalahan pada tingkat platform dapat berdampak terhadap banyak aplikasi sekaligus.

Risiko pada Aplikasi

Risiko ini muncul dari cara pengguna merancang aplikasi, workflow, hak akses, serta integrasi.

Contohnya meliputi otorisasi yang tidak tepat, data sensitif yang tampil kepada pengguna yang tidak berhak, validasi input yang lemah, kesalahan business logic, konfigurasi API yang tidak aman, dan akun layanan dengan hak akses berlebihan.

Aplikasi dapat berfungsi sesuai harapan, tetapi tetap memiliki celah keamanan.

Risiko pada Organisasi

Lapisan ini sering menjadi persoalan terbesar.

Perusahaan mungkin tidak mengetahui berapa banyak aplikasi low-code yang aktif, siapa pemiliknya, data apa yang diproses, atau sistem apa yang dihubungkan. Aplikasi dapat tetap berjalan setelah pembuatnya berpindah divisi atau meninggalkan perusahaan.

Tidak ada pihak yang secara aktif bertanggung jawab atas pembaruan, evaluasi akses, pengujian, dan penghentian aplikasi.

Dalam kondisi tersebut, keamanan tidak gagal karena platform tidak memiliki fitur yang memadai. Keamanan gagal karena perusahaan tidak memiliki tata kelola yang mampu mengikuti pertumbuhan aplikasi.

Low-Code Dapat Mengubah Shadow IT Menjadi Shadow Application Portfolio

Shadow IT biasanya merujuk pada penggunaan perangkat lunak atau layanan teknologi tanpa persetujuan maupun pengawasan tim IT.

Low-code membawa persoalan tersebut ke tingkat yang lebih kompleks.

Pengguna tidak hanya menggunakan alat yang tidak diketahui oleh perusahaan. Mereka dapat membangun aplikasi, membuat basis data, menyusun automasi, dan mengintegrasikan berbagai layanan.

Apabila aktivitas ini berlangsung tanpa inventory dan governance, perusahaan dapat memiliki portofolio aplikasi yang tidak terlihat.

Beberapa aplikasi mungkin hanya digunakan untuk eksperimen kecil. Sebagian lainnya dapat berkembang menjadi sistem operasional yang memproses data penting. Masalahnya, perusahaan tidak selalu dapat membedakan keduanya.

Aplikasi yang awalnya dibuat untuk lima orang dapat digunakan oleh satu divisi. Workflow sederhana dapat berkembang menjadi proses persetujuan utama. Penyimpanan sementara dapat berubah menjadi sumber data operasional.

Pertumbuhan semacam ini sering terjadi secara bertahap sehingga tidak dianggap sebagai proyek teknologi.

Akibatnya, perusahaan dapat menghadapi aplikasi yang:

• tidak memiliki pemilik resmi;
• tidak tercatat dalam inventory aset;
• tidak mempunyai dokumentasi;
• menggunakan konektor yang belum disetujui;
• memproses data sensitif tanpa klasifikasi;
• memberikan akses terlalu luas;
• bergantung pada akun milik individu;
• tidak memiliki rencana pemulihan;
• tidak pernah menjalani security review;
• tetap aktif meskipun sudah tidak diperlukan.

Pada tahap ini, low-code tidak lagi sekadar menghasilkan shadow IT. Ia menghasilkan shadow application portfolio, yaitu kumpulan aplikasi bisnis yang memiliki nilai operasional tetapi berada di luar kendali formal organisasi.

Keamanan Tidak Dapat Sepenuhnya Diserahkan kepada Fitur Bawaan

Platform low-code modern dapat menyediakan kontrol keamanan yang cukup lengkap.

Perusahaan mungkin dapat membatasi konektor, menetapkan kebijakan data, memisahkan lingkungan development dan production, menerapkan autentikasi berlapis, mencatat aktivitas, serta mengatur siapa yang dapat membuat atau menerbitkan aplikasi.

Namun, kontrol tersebut tidak bekerja hanya karena tersedia.

Kontrol harus dikonfigurasi, diuji, dipantau, dan diperbarui sesuai perubahan kebutuhan perusahaan.

Kebijakan konektor tidak akan membantu apabila semua konektor masih diizinkan. Audit log tidak akan memberikan nilai apabila tidak pernah diperiksa. Kontrol akses tidak akan efektif apabila setiap pengguna memperoleh peran yang terlalu tinggi. Pemisahan environment tidak berarti banyak apabila aplikasi dapat dipindahkan ke production tanpa proses persetujuan.

Dengan kata lain, fitur keamanan bukanlah hasil keamanan.

Perusahaan tetap memerlukan keputusan tata kelola untuk menentukan bagaimana fitur tersebut digunakan. Mereka juga membutuhkan pengawasan untuk memastikan konfigurasi tidak berubah menjadi terlalu longgar seiring bertambahnya permintaan bisnis.

Kepercayaan berlebihan terhadap platform dapat menciptakan rasa aman yang keliru.

Platform mungkin aman secara teknis, tetapi aplikasi yang dibangun di atasnya tetap dapat memiliki kelemahan pada logika, akses, integrasi, maupun pengelolaan data.

Tidak Semua Aplikasi Low-Code Membutuhkan Kontrol yang Sama

Governance tidak seharusnya membuat seluruh inisiatif low-code bergerak selambat proyek aplikasi berskala besar.

Apabila setiap prototipe harus melewati proses panjang, pengguna akan mencari jalan lain di luar pengawasan perusahaan. Sebaliknya, membiarkan semua aplikasi diterbitkan tanpa pemeriksaan juga bukan pilihan yang dapat dipertanggungjawabkan.

Pendekatan yang lebih tepat adalah menerapkan kontrol berdasarkan tingkat risiko.

Aplikasi Berisiko Rendah

Aplikasi berisiko rendah biasanya digunakan oleh individu atau kelompok kecil, tidak memproses data sensitif, tidak terhubung ke sistem kritis, dan tidak memengaruhi keputusan penting.

Contohnya dapat berupa pencatatan tugas internal atau formulir sederhana menggunakan data non-rahasia.

Aplikasi seperti ini dapat diberikan jalur pembangunan yang lebih fleksibel, dengan standar minimum dan pencatatan dasar.

Aplikasi Berisiko Menengah

Aplikasi berisiko menengah digunakan oleh satu atau beberapa divisi, memproses data internal, memiliki integrasi tertentu, serta memengaruhi kegiatan operasional rutin.

Aplikasi pada kategori ini sebaiknya memiliki pemilik yang jelas, dokumentasi, review hak akses, pemeriksaan konektor, serta proses persetujuan sebelum digunakan secara luas.

Aplikasi Berisiko Tinggi

Aplikasi berisiko tinggi memproses data pribadi atau rahasia, digunakan oleh pelanggan maupun mitra, terhubung ke sistem kritis, mengatur transaksi, atau menjadi bagian dari proses utama perusahaan.

Aplikasi ini harus diperlakukan sebagai aset teknologi penting.

Pengujian keamanan, pemisahan tugas, pengelolaan perubahan, monitoring, dokumentasi, dan peninjauan akses perlu diterapkan sebelum aplikasi masuk ke lingkungan production.

Governance yang baik bukan berarti menerapkan kontrol maksimal terhadap semua aplikasi. Governance yang baik berarti memastikan tingkat kontrol sebanding dengan potensi dampaknya.

Perusahaan Memerlukan Jalur Aman, Bukan Larangan

Melarang citizen development sepenuhnya bukan strategi yang realistis.

Kebutuhan bisnis yang melahirkan aplikasi tersebut tetap ada. Apabila jalur resmi dianggap terlalu lambat, pengguna dapat beralih ke perangkat lunak lain, membuat automasi pribadi, atau memproses data perusahaan melalui layanan yang tidak disetujui.

Larangan sering kali tidak menghilangkan risiko. Larangan hanya memindahkan risiko ke tempat yang lebih sulit terlihat.

Perusahaan sebaiknya menyediakan jalur resmi yang memungkinkan inovasi berjalan dalam batas yang dapat dikendalikan.

Jalur tersebut dapat mencakup:

• platform low-code yang telah disetujui;
• lingkungan sandbox untuk eksperimen;
• daftar konektor yang boleh digunakan;
• template yang telah melewati pemeriksaan;
• komponen reusable dengan konfigurasi aman;
• klasifikasi aplikasi berdasarkan risiko;
• proses approval yang proporsional;
• katalog aplikasi terpusat;
• dokumentasi minimum;
• pelatihan keamanan bagi citizen developer;
• jalur eskalasi menuju tim IT dan cybersecurity.

Pendekatan ini memungkinkan perusahaan mempertahankan kecepatan tanpa kehilangan visibility.

Tujuan governance bukan mengambil seluruh kendali dari pengguna bisnis. Tujuannya adalah memastikan mereka mengetahui batas keputusan yang dapat dibuat secara mandiri dan kondisi yang membutuhkan keterlibatan pihak lain.

Citizen Developer Tetap Memerlukan Batas Kewenangan

Demokratisasi development tidak berarti semua keputusan teknologi dapat didemokratisasi tanpa batas.

Pengguna bisnis dapat diberi keleluasaan untuk membuat prototipe, membangun aplikasi berisiko rendah, menggunakan data non-sensitif, serta memanfaatkan komponen yang telah disetujui.

Namun, keputusan tertentu tetap memerlukan review.

Keterlibatan tim IT, data owner, atau cybersecurity sebaiknya diwajibkan apabila aplikasi:

• mengakses data pribadi;
• menyimpan informasi rahasia;
• menggunakan akun layanan;
• membuka akses kepada pihak eksternal;
• terhubung dengan sistem kritis;
• memproses transaksi;
• mengendalikan persetujuan penting;
• menggunakan API eksternal;
• memindahkan data ke layanan pihak ketiga;
• diterbitkan untuk penggunaan lintas divisi;
• menjadi bagian dari proses bisnis utama.

Batas kewenangan semacam ini tidak dimaksudkan untuk memperlambat pengguna.

Sebaliknya, batas tersebut melindungi citizen developer agar mereka tidak harus menanggung keputusan keamanan yang berada di luar kompetensi dan tanggung jawab pekerjaannya.

Perusahaan tidak dapat memberikan alat yang mampu mengakses berbagai sistem, lalu menyerahkan seluruh konsekuensinya kepada pengguna.

Security Review Harus Mengikuti Risiko, Bukan Jenis Platform

Aplikasi tidak menjadi kurang penting hanya karena dibuat dengan sedikit kode.

Jika aplikasi mengendalikan proses pembayaran, menyimpan data pelanggan, atau digunakan untuk mengambil keputusan operasional, dampaknya tetap besar. Oleh karena itu, kebutuhan security review harus ditentukan berdasarkan fungsi dan risiko aplikasi, bukan berdasarkan alat pembuatannya.

Review keamanan terhadap aplikasi low-code dapat mencakup:

• mekanisme autentikasi;
• pembagian peran pengguna;
• otorisasi terhadap fungsi dan data;
• validasi input;
• keamanan session;
• konfigurasi konektor;
• penggunaan akun layanan;
• perlindungan data sensitif;
• keamanan API;
• business logic;
• segregasi data;
• audit trail;
• eksposur endpoint;
• konfigurasi environment;
• kemampuan pengguna memanipulasi workflow.

Salah satu risiko yang perlu mendapat perhatian adalah business logic flaw.

Platform mungkin secara otomatis menangani sebagian persoalan teknis. Namun, platform tidak selalu dapat mengetahui bahwa urutan persetujuan yang dibuat pengguna dapat dilewati, nilai transaksi dapat dimanipulasi, atau pengguna dapat menyetujui permintaannya sendiri.

Permasalahan semacam ini hanya dapat ditemukan melalui pemahaman terhadap proses bisnis dan pengujian yang mensimulasikan penyalahgunaan nyata.

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

Aplikasi terlihat berjalan dengan baik dalam skenario normal, tetapi menunjukkan kelemahan ketika diuji dari sudut pandang pengguna yang mencoba memperoleh akses lebih tinggi, membaca data milik pihak lain, mengubah parameter, atau memanipulasi tahapan proses.

Itulah sebabnya functional testing tidak dapat menggantikan security testing.

Tanggung Jawab Keamanan Harus Dibagi secara Eksplisit

Salah satu penyebab kegagalan governance low-code adalah ketidakjelasan tanggung jawab.

Pengguna bisnis menganggap platform telah diamankan oleh tim IT. Tim IT menganggap aplikasi merupakan tanggung jawab divisi pembuatnya. Tim keamanan tidak mengetahui keberadaan aplikasi. Manajemen menganggap seluruh aktivitas digitalisasi sudah berada dalam pengawasan.

Pada akhirnya, semua pihak merasa pihak lain telah menangani risiko.

Pembagian tanggung jawab harus ditetapkan secara eksplisit.

Pengguna bisnis bertanggung jawab menjelaskan tujuan aplikasi, proses yang dijalankan, data yang digunakan, dan dampak apabila aplikasi gagal.

Citizen developer bertanggung jawab mengikuti standar pembangunan, mendokumentasikan aplikasi, menggunakan komponen yang disetujui, dan melaporkan perubahan penting.

Tim IT bertanggung jawab terhadap platform, environment, identitas, konektor, integrasi, ketersediaan, dan lifecycle aplikasi.

Tim cybersecurity menetapkan baseline keamanan, metode klasifikasi risiko, proses security review, pengujian, dan pemantauan.

Data owner menentukan apakah suatu data boleh digunakan, dibagikan, atau diintegrasikan.

Manajemen menentukan risk appetite, tingkat investasi, serta pihak yang memiliki akuntabilitas akhir.

Internal audit memastikan kebijakan tidak hanya tersedia dalam dokumen, tetapi benar-benar dijalankan dan dapat dibuktikan.

Tanpa pembagian ini, low-code dapat berkembang menjadi wilayah abu-abu yang berada di antara bisnis, IT, dan keamanan.

Inventory Menjadi Fondasi Low-Code Governance

Perusahaan tidak dapat melindungi aplikasi yang tidak diketahui keberadaannya.

Oleh karena itu, langkah pertama dalam low-code governance bukan selalu menambah aturan. Langkah pertama adalah membangun visibility.

Perusahaan perlu mengetahui:

• aplikasi apa yang sedang aktif;
• siapa yang membangunnya;
• siapa pemilik bisnisnya;
• siapa penggunanya;
• data apa yang diproses;
• konektor apa yang digunakan;
• sistem apa yang terhubung;
• tingkat kritikalitas aplikasi;
• kapan aplikasi terakhir diperbarui;
• apakah aplikasi masih diperlukan;
• apakah aplikasi telah menjalani review.

Inventory juga harus mencakup automasi dan workflow, bukan hanya aplikasi dengan antarmuka pengguna.

Sebuah automasi yang berjalan di belakang layar dapat memiliki akses luas dan melakukan tindakan penting tanpa terlihat oleh pengguna. Apabila automasi menggunakan akun mantan karyawan atau kredensial yang tidak lagi dikelola, proses operasional dapat berhenti atau disalahgunakan.

Dengan inventory yang baik, perusahaan dapat memprioritaskan aplikasi berdasarkan risiko dan menghentikan aplikasi yang tidak lagi dibutuhkan.

Keberhasilan Low-Code Tidak Boleh Diukur dari Jumlah Aplikasi

Banyak organisasi mengukur keberhasilan program low-code melalui jumlah aplikasi, jumlah citizen developer, kecepatan pembangunan, atau waktu kerja yang berhasil dihemat.

Metrik tersebut penting, tetapi dapat memberikan gambaran yang terlalu optimistis.

Semakin banyak aplikasi yang dibuat, semakin besar pula kebutuhan untuk mengelola kepemilikan, akses, integrasi, data, dan pemeliharaannya.

Program low-code yang menghasilkan ratusan aplikasi belum tentu berhasil apabila sebagian besar tidak terdokumentasi, tidak memiliki pemilik, dan tidak pernah ditinjau.

Perusahaan perlu menambahkan ukuran yang menggambarkan tingkat kendali, seperti:

• persentase aplikasi yang telah terinventarisasi;
• jumlah aplikasi tanpa pemilik aktif;
• jumlah aplikasi berdasarkan klasifikasi risiko;
• persentase aplikasi kritis yang telah diuji;
• jumlah konektor tidak terotorisasi;
• jumlah akses berlebihan;
• jumlah aplikasi tidak aktif;
• temuan keamanan yang belum diperbaiki;
• waktu rata-rata remediasi;
• jumlah insiden yang melibatkan aplikasi low-code.

Kecepatan hanya menjadi keunggulan apabila hasilnya dapat dipelihara dan dikendalikan.

Tanpa governance, perusahaan mungkin tidak sedang mempercepat transformasi digital. Perusahaan hanya mempercepat produksi aset teknologi yang suatu saat harus ditata ulang.

Low-Code Harus Masuk ke Dalam Secure Development Lifecycle

Perusahaan tidak perlu memaksakan seluruh tahapan pengembangan konvensional kepada setiap aplikasi low-code. Namun, prinsip Secure SDLC tetap perlu diterapkan secara proporsional.

Sebelum pembangunan, perusahaan perlu menentukan tujuan, data yang digunakan, pengguna, integrasi, dan tingkat risiko.

Selama pembangunan, citizen developer harus menggunakan komponen yang disetujui, menerapkan prinsip least privilege, serta menghindari penggunaan akun bersama atau kredensial pribadi.

Sebelum production, aplikasi harus melalui pemeriksaan sesuai klasifikasinya. Pemeriksaan dapat berupa review konfigurasi, validasi hak akses, pengujian business logic, hingga penetration testing untuk aplikasi berisiko tinggi.

Setelah production, aplikasi perlu dipantau, ditinjau aksesnya, diperbarui, dan dihentikan ketika tidak lagi diperlukan.

Dengan pendekatan tersebut, low-code tidak diperlakukan sebagai pengecualian dari praktik keamanan. Low-code ditempatkan sebagai bagian dari ekosistem pengembangan perusahaan.

Yang Didemokratisasi Seharusnya Kemampuan Membangun, Bukan Risiko

Low-code memberikan peluang besar bagi perusahaan untuk mempercepat digitalisasi, mengurangi pekerjaan manual, dan menjawab kebutuhan bisnis yang selama ini tertunda.

Namun, nilai tersebut hanya dapat dipertahankan apabila perusahaan mampu melihat, mengklasifikasikan, mengendalikan, dan menguji aplikasi yang dihasilkan.

Citizen developer bukan ancaman. Pengguna bisnis juga bukan titik lemah yang harus dibatasi secara berlebihan.

Risiko muncul ketika organisasi memberikan kemampuan membangun tanpa menyediakan standar, guardrail, ownership, dan proses eskalasi yang jelas.

Low-code seharusnya mendemokratisasi kemampuan untuk berinovasi. Teknologi ini tidak seharusnya mendemokratisasi kebebasan untuk mengakses data, menghubungkan sistem, atau menerbitkan aplikasi tanpa pertanggungjawaban.

Perusahaan tidak harus memilih antara kecepatan dan keamanan. Namun, perusahaan harus berhenti menganggap bahwa kecepatan dapat berjalan tanpa kepemilikan, batas kewenangan, dan governance yang jelas.

Pastikan Kecepatan Low-Code Tidak Menciptakan Risiko yang Tidak Terlihat

Aplikasi low-code yang telah terhubung dengan data penting, sistem internal, API, atau proses operasional perlu dinilai dengan tingkat kehati-hatian yang sama seperti aplikasi bisnis lainnya.

Fourtrezz membantu perusahaan mengidentifikasi kelemahan keamanan melalui layanan Vulnerability Assessment dan Penetration Testing. Pengujian dilakukan untuk menilai kontrol akses, autentikasi, konfigurasi, API, integrasi, business logic, serta kemungkinan penyalahgunaan yang tidak terlihat dalam pengujian fungsional.

Fourtrezz juga menyediakan layanan keamanan siber dan pengembangan sistem untuk membantu perusahaan membangun aplikasi yang lebih aman, terukur, dan selaras dengan kebutuhan operasional.

Bangun inovasi dengan cepat, tetapi pastikan setiap aplikasi tetap berada dalam kendali perusahaan.

Hubungi Fourtrezz:

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