Apa itu DevSecOps dan bagaimana cara menerapkannya?

Sebuah tim merilis pembaruan pada Jumat sore. Pekan berikutnya, sebuah pemindai yang berjalan di produksi menandai kunci API yang tertanam langsung di dalam kode yang sudah ter-deploy, ditambah sebuah pustaka usang yang membawa celah remote-code-execution yang sudah diketahui. Kedua masalah itu sudah ada sejak commit pertama. Keduanya bisa tertangkap dalam hitungan detik oleh pemeriksaan yang berjalan saat kode itu ditulis. Alih-alih, keduanya sampai ke produksi, dan kini perbaikannya berarti patch darurat, rotasi kunci, dan percakapan canggung soal bagaimana itu bisa terjadi. DevSecOps hadir untuk memindahkan penangkapan itu dari produksi kembali ke commit.

Apa itu DevSecOps

DevSecOps adalah praktik membangun keamanan ke dalam pipeline pengembangan perangkat lunak, bukan memperlakukannya sebagai gerbang terakhir sebelum rilis. Namanya menggabungkan development, security, dan operations, dan gagasan di baliknya adalah bahwa pekerjaan keamanan seharusnya berjalan berdampingan dengan pekerjaan menulis kode dan men-deploy, bukan mengantre terpisah yang baru terbuka setelah semuanya selesai.

Gagasan intinya sering disebut shift left. Bayangkan siklus hidup perangkat lunak sebagai garis yang membentang dari menulis kode di kiri hingga menjalankannya di produksi di kanan. Selama bertahun-tahun, pengujian keamanan berada jauh di kanan, sebuah tinjauan yang terjadi tepat sebelum peluncuran atau, lebih buruk lagi, setelah insiden. Menggeser ke kiri berarti memindahkan pemeriksaan itu lebih awal, sehingga sebuah kerentanan ditemukan saat commit ketika pengembang bisa memperbaikinya dalam hitungan menit, bukan berminggu-minggu kemudian saat ia terkubur di bawah ratusan perubahan lain.

Paruh kedua gagasannya adalah tanggung jawab bersama. Dalam model lama, pengembang menulis kode, melemparkannya melewati tembok, dan tim keamanan memutuskan di akhir apakah kode itu boleh rilis. DevSecOps mengganti serah-terima itu dengan tugas bersama. Pengembang, insinyur keamanan, dan operasi sama-sama memiliki keamanan atas apa yang mereka bangun, didukung otomatisasi yang mengerjakan pemeriksaan berulang untuk mereka.

Praktik yang membuatnya bekerja

DevSecOps berjalan di atas serangkaian pemeriksaan otomatis, masing-masing memeriksa lapisan sistem yang berbeda. Nilainya datang dari menjalankan semuanya bersama-sama dan lebih awal, sehingga tidak ada yang bergantung pada satu orang yang ingat untuk memeriksa. Tabel di bawah mencantumkan yang umum dan apa yang sebenarnya dilakukan masing-masing.

Perbedaan yang sering membingungkan orang adalah SAST versus DAST. SAST bersifat statis: ia menganalisis kode sebagaimana ditulis, tanpa menjalankannya, sehingga bisa menangkap cacat lebih awal tetapi kadang menandai hal yang sebenarnya tidak bisa dieksploitasi dalam praktik. DAST bersifat dinamis: ia butuh aplikasi yang berjalan untuk diuji, sehingga menemukan masalah yang nyata dan bisa dijangkau tetapi baru di tahap yang lebih akhir. Keduanya menangkap jenis masalah yang berbeda, itulah sebabnya pipeline yang matang menjalankan keduanya.

Mengapa ini penting di Indonesia

Tim perangkat lunak di Indonesia, terutama di fintech, berada di bawah dua tekanan sekaligus: merilis fitur dengan cepat untuk bersaing, dan memenuhi regulator yang mengharapkan keamanan yang bisa dibuktikan. Lembaga yang diawasi OJK dituntut memenuhi standar nyata tentang cara mereka membangun dan mengamankan sistem, dan kecepatan rilis tidak boleh datang dengan biaya mendorong kode rentan ke lingkungan yang teregulasi. DevSecOps adalah cara tim mendamaikan keduanya, karena bukti keamanan dihasilkan otomatis sebagai bagian dari proses rilis, bukan dirangkai manual menjelang audit. Tulisan kami tentang DevSecOps untuk fintech Indonesia di bawah OJK mengupas sisi regulasi itu lebih dalam.

Menerapkannya tanpa memperlambat rilis

Kekhawatiran yang dimiliki sebagian besar tim adalah bahwa menambah pemeriksaan keamanan akan menghentikan laju pengiriman. Itu hanya terjadi bila dilakukan sembarangan, dengan setiap pemindaian disetel memblokir build dan setiap temuan berkeparahan rendah diperlakukan sebagai rambu berhenti. Pengembang menanggapinya dengan menghindari pemeriksaan itu, yang justru menggagalkan tujuannya.

Ada tiga kebiasaan yang menjaga DevSecOps tetap cepat. Pertama, otomatiskan pemeriksaan agar berjalan di dalam continuous integration pada setiap commit, tanpa langkah manual yang harus diingat. Kedua, pakai gating berbasis risiko: gagalkan build hanya pada temuan yang benar-benar penting, seperti kerentanan dependensi kritis atau kunci yang bocor, dan biarkan item berkeparahan lebih rendah dicatat dan ditriase alih-alih memblokir rilis. Ketiga, tempatkan umpan balik di tempat pengembang sudah bekerja, di dalam pull request atau IDE, sehingga memperbaiki masalah menjadi bagian dari alur normal, bukan tugas terpisah.

Dilihat begitu, DevSecOps bukan pajak atas kecepatan. Menangkap cacat saat commit memakan beberapa menit; menangkapnya di produksi memakan sebuah insiden. Seiring waktu, tim yang membangun keamanan ke dalam pipeline merilis dengan lebih percaya diri, bukan sebaliknya.

Posisi Alpha Code

Alpha Code membantu tim di Indonesia membangun pemeriksaan ini ke dalam pipeline yang sudah mereka jalankan, sebagai bagian dari layanan Keamanan Cloud & DevSecOps. Artinya menyambungkan SAST, dependency scanning, secrets detection, dan pemindaian infrastruktur ke CI Anda dengan cara yang diterima pengembang, menyetel gerbangnya agar build gagal hanya pada yang penting, dan memetakan keluarannya ke bukti yang diharapkan kewajiban OJK dan UU PDP. Jika Anda ingin menambahkan keamanan ke proses pengiriman tanpa membuatnya tersendat, itulah percakapan yang layak didahulukan.