Setiap kali insiden kebocoran data menghantam sebuah perusahaan, narasi yang muncul selalu sama: ada hacker jahat diluar sana yang berhasil membobol sistem. Nama-nama kelompok peretas disebut, anggaran keamanan dipertanyakan, dan tim IT menjadi sorotan. Tapi ada satu pertanyaan yang jarang diajukan — siapa yang membangun pintu yang bisa dibobol itu?

Jawabannya tidak nyaman: dalam banyak kasus, masalahnya bukan di luar sistem. Masalahnya ditulis baris demi baris oleh tim developer sendiri.

Ketika Statistik Berbicara Lebih Keras dari Asumsi

Laporan State of Software Security 2025 yang diterbitkan oleh Veracode mencatat bahwa separuh dari seluruh organisasi yang disurvei menanggung critical security debt — artinya, mereka memiliki kerentanan dengan tingkat eksploitabilitas tinggi yang dibiarkan tanpa penanganan selama bertahun-tahun.

Lebih mengkhawatirkan lagi, 70% dari utang keamanan kritis itu bersumber dari kode pihak ketiga dan rantai pasok perangkat lunak. Bukan dari serangan canggih yang membutuhkan keahlian tinggi. Bukan dari operasi intelijen yang terencana. Tapi dari library yang ditarik begitu saja ke dalam proyek tanpa pemeriksaan keamanan yang memadai.

Rata-rata waktu yang dibutuhkan untuk memperbaiki celah keamanan dalam kode telah meningkat 47% sejak tahun 2020, kini mencapai 252 hari. Lebih dari delapan bulan. Selama itulah sebuah kerentanan dibiarkan terbuka — dan siapapun yang menemukan celah tersebut lebih dulu akan menentukan apa yang terjadi selanjutnya.

Hacker Tidak Membobol Sistem. Mereka Masuk Lewat Pintu yang Sudah Terbuka.

Ada kesalahpahaman mendasar tentang cara kerja sebagian besar serangan siber. Masyarakat membayangkan seorang peretas duduk di depan layar, mengetikkan perintah-perintah rumit untuk "menembus" sistem pertahanan yang kokoh. Kenyataannya jauh lebih sederhana — dan jauh lebih memalukan bagi industri teknologi.

Laporan Data Breach Investigations Report (DBIR) 2025 dari Verizon, yang menganalisis lebih dari 22.000 insiden siber, menemukan bahwa eksploitasi kerentanan perangkat lunak telah menjadi vektor akses awal dalam 20% dari seluruh pelanggaran data yang dikonfirmasi — meningkat 34% dibandingkan tahun sebelumnya.

Para penyerang tidak menunggu momen yang sempurna. Mereka secara aktif memburu kelemahan apa pun dalam perangkat lunak atau sistem — baik itu cacat pada kode itu sendiri maupun pada cara perangkat edge dan VPN dikelola.

Ini bukan soal kehebatan teknis penyerang. Ini soal kelengahan pada sisi yang membangun sistemnya.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia — pola yang berulang: bukan karena sistemnya diserang dengan cara yang sangat canggih, tetapi karena ada celah yang sudah ada sejak kode pertama kali ditulis dan tidak pernah ditangani.

OWASP Top 10: Daftar Dosa yang Sama, Bertahun-tahun

Sudah lebih dari dua dekade OWASP (Open Worldwide Application Security Project) menerbitkan daftar sepuluh kerentanan aplikasi web paling kritis. Daftar ini diperbarui secara berkala berdasarkan data nyata dari ribuan aplikasi yang diuji di seluruh dunia.

Yang memprihatinkan bukan konten daftarnya — tapi fakta bahwa daftar ini tidak banyak berubah.

SQL Injection, Broken Access Control, autentikasi yang lemah, Security Misconfiguration, dan paparan data sensitif terus muncul dari tahun ke tahun. Bukan karena teknik serangannya yang baru. Tapi karena praktik penulisan kode yang buruk terus direproduksi — dari satu proyek ke proyek berikutnya, dari satu generasi developer ke generasi berikutnya.

Sebuah studi dari Veracode yang mengevaluasi lebih dari 100 model kecerdasan buatan dalam menghasilkan kode menemukan bahwa hampir separuh dari sampel kode yang dihasilkan gagal dalam pengujian keamanan dan mengandung kerentanan dari kategori OWASP Top 10 — termasuk SQL injection, cross-site scripting, log injection, dan kriptografi yang lemah.

Artinya, bahkan alat bantu yang diklaim mempercepat produktivitas developer pun mewariskan kerentanan yang sama.

Tiga Kasus yang Tidak Bisa Disalahkan ke Hacker

Log4Shell (2021) menjadi salah satu kerentanan paling dahsyat dalam sejarah perangkat lunak modern. Celah ini ditemukan pada Log4j — sebuah library logging berbasis Java yang tertanam di ratusan ribu sistem di seluruh dunia. Penyerang tidak perlu membangun infrastruktur serangan yang rumit. Mereka cukup memanfaatkan kode yang sudah tertanam jauh di dalam tumpukan aplikasi yang bahkan banyak tim pengembang sendiri tidak menyadari keberadaannya.

Equifax (2017) adalah kasus yang bahkan lebih telak. Perusahaan informasi kredit terbesar di Amerika Serikat kehilangan data lebih dari 147 juta penduduk. Penyebabnya? Celah pada Apache Struts yang patch-nya telah tersedia dua bulan sebelum insiden terjadi. Tim teknis tidak menerapkan pembaruan tersebut tepat waktu. Tidak ada senjata rahasia, tidak ada teknik infiltrasi yang canggih — hanya patch yang terlambat diaplikasikan.

API Key Exposed di Repository Publik adalah skenario yang terjadi berulang kali di berbagai perusahaan: seorang developer secara tidak sengaja meng-commit kredensial akses, token autentikasi, atau kunci API langsung ke repositori kode yang dapat diakses publik. Tidak ada yang perlu "meretas" sistem tersebut — informasinya sudah tersedia secara terbuka.

Ketiga kasus ini memiliki satu kesamaan: ada jendela waktu di mana tindakan dari sisi pengembangan dan operasional bisa mencegah semuanya.

Ekosistem yang Mengajarkan Developer untuk Bergerak Cepat, Bukan Bergerak Aman

Masalahnya tidak semata-mata soal individu developer yang lalai. Ada tekanan sistemik yang jauh lebih besar.

Dalam sebagian besar siklus pengembangan perangkat lunak saat ini, keamanan diperlakukan sebagai fase terakhir — sesuatu yang akan "ditangani nanti" setelah fitur utama selesai. Sprint dua minggu diukur berdasarkan fitur yang berhasil dikirimkan, bukan berdasarkan berapa banyak celah keamanan yang berhasil dicegah. Code review difokuskan pada keterbacaan dan performa, bukan pada threat modeling.

Sejak tahun 2020, rata-rata waktu yang dibutuhkan tim untuk memperbaiki kelemahan keamanan telah meningkat 47% — sebuah sinyal bahwa tim tidak mampu mengimbangi skala kerentanan yang terus diproduksi.

Di sisi lain, rata-rata penyerang hanya membutuhkan 19,5 hari untuk menjadikan sebuah kerentanan sebagai senjata, sementara organisasi rata-rata membutuhkan 30,6 hari untuk menerapkan patch — menciptakan celah eksposur selama 11 hari.

Sebelas hari. Itulah jendela yang dimanfaatkan.

Apa yang Harus Berubah: Bukan Sekadar Checklist, Tapi Perubahan Cara Berpikir

Merespons tantangan ini tidak cukup dengan menambahkan satu langkah security review di akhir pipeline. Dibutuhkan pergeseran mendasar dalam cara keamanan diposisikan dalam proses pengembangan.

Shift Left Security adalah pendekatan di mana pertimbangan keamanan dimasukkan sejak fase desain sistem — bukan setelah kode selesai ditulis. Ini berarti setiap keputusan arsitektur, setiap pilihan library, dan setiap endpoint yang dirancang sudah mempertimbangkan potensi ancamannya.

Threat Modeling perlu menjadi kebiasaan rutin dalam sesi perencanaan sprint, bukan dokumen formal yang hanya dibuat setahun sekali. Pertanyaan sederhana seperti "siapa yang bisa menyalahgunakan fitur ini?" seharusnya menjadi bagian dari diskusi teknis sehari-hari.

Penggunaan Static Analysis Tools seperti Semgrep, Snyk, atau SonarQube perlu diintegrasikan ke dalam pipeline CI/CD sebagai gerbang wajib, bukan sebagai alat opsional yang dijalankan sesekali. Kode yang tidak lolos pemeriksaan keamanan otomatis tidak boleh masuk ke tahap produksi.

Audit Dependensi Secara Rutin harus dilakukan tanpa menunggu ada CVE (Common Vulnerability and Exposure) yang viral di media. Setiap library pihak ketiga yang masuk ke dalam proyek adalah potensi risiko yang perlu dikelola secara aktif.

DevSecOps bukan sekadar tren penamaan ulang — ini adalah model operasional di mana tim keamanan tidak bekerja terpisah dari tim pengembang, melainkan terintegrasi langsung dalam setiap tahap siklus hidup pengembangan perangkat lunak.

Kode yang Ditulis Hari Ini adalah Attack Surface Esok Hari

Selama industri teknologi terus menempatkan keamanan sebagai tanggung jawab tim lain — tim keamanan, tim IT, tim compliance — angka-angka ini tidak akan bergerak ke arah yang lebih baik.

Manusia masih menjadi faktor penyumbang dalam 60% insiden pelanggaran data, dan kerentanan perangkat lunak yang tidak ditambal dalam batas waktu yang memadai terus menjadi salah satu vektor masuk utama bagi penyerang.

Tidak ada sistem yang sempurna. Tapi ada perbedaan besar antara sistem yang dirancang dengan kesadaran penuh terhadap risiko keamanan, dan sistem yang dibuat dengan asumsi bahwa keamanan bisa diurus belakangan.

Pertanyaannya bukan lagi apakah aplikasi yang sedang dikembangkan memiliki celah. Pertanyaannya adalah: sudah seberapa lama celah itu ada, dan siapa yang akan menemukannya lebih dulu?

Lindungi Sistem Anda Sebelum Orang Lain Menemukannya

Fourtrezz adalah perusahaan keamanan siber Indonesia di bawah naungan PT Tiga Pilar Keamanan yang berspesialisasi dalam membantu organisasi mengidentifikasi dan menutup celah keamanan sebelum dapat dieksploitasi. Layanan utama Fourtrezz mencakup Penetration Testing, Vulnerability Assessment, dan Garda Siber — yang dirancang untuk menguji ketahanan sistem, aplikasi, dan infrastruktur secara menyeluruh dengan metodologi yang mengacu pada standar keamanan internasional.

Selain layanan keamanan siber, Fourtrezz juga menyediakan layanan IT Development untuk membantu perusahaan membangun sistem dan aplikasi yang tidak hanya fungsional, tetapi juga dirancang dengan mempertimbangkan keamanan sejak awal — bukan sebagai tambahan di akhir.

Jika organisasi Anda ingin mengetahui seberapa kuat pertahanan digital yang dimiliki saat ini, atau ingin membangun sistem baru dengan fondasi keamanan yang solid, Fourtrezz siap menjadi mitra teknis Anda.

Hubungi Fourtrezz:

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