Mengalihkan DevOps ke DevSecOps

Saat Anda membuat atau memodernisasi disiplin Keamanan Pengembangan, artikel ini menguraikan cara mengintegrasikan keamanan ke dalam praktik pengembangan memungkinkan pergeseran dari operasi pengembang (DevOps) ke operasi keamanan pengembang (DevSecOps), dan membantu mengamankan pengiriman aplikasi.

Organisasi modern mengandalkan pengembangan perangkat lunak yang cepat untuk memberikan inovasi, menanggapi perubahan persyaratan bisnis, dan mempertahankan keunggulan kompetitif. DevOps memungkinkan kelincahan ini melalui integrasi dan pengiriman berkelanjutan. Namun, peningkatan kecepatan juga memperkenalkan risiko keamanan baru.

Siklus rilis berkelanjutan mengurangi waktu antara keputusan desain dan penyebaran produksi, meningkatkan kemungkinan bahwa kelemahan diperkenalkan ke dalam lingkungan produksi, termasuk:

• Kelemahan desain aplikasi
• Dependensi yang rentan
• Kesalahan konfigurasi
• Kelemahan otomatisasi infrastruktur
• Manajemen rahasia atau kebersihan yang buruk.

Risiko DevOps

Lingkungan DevOps modern memperluas permukaan serangan di seluruh sistem pengembangan, alur, dan produksi. Alat DevOps seperti repositori kode sumber, alur, dan sistem otomatisasi adalah target bernilai tinggi untuk penyerang.

Jika kode berbahaya diperkenalkan lebih awal, kode tersebut mungkin melewati pemeriksaan keamanan yang ada dan menjangkau sistem produksi.

Tujuan serangan umum meliputi:

• Menyuntikkan kode berbahaya ke dalam artefak hasil build.
• Mengorbankan identitas pengembang atau akun layanan.
• Mengakses atau menyelundupkan data produksi.

Penyerang sering menargetkan aplikasi kustom dan lingkungan pengembangan untuk mendapatkan akses ke:

• Data organisasi atau pelanggan yang sensitif.
• Logika bisnis dan kekayaan intelektual proprietari.
• Infrastruktur produksi melalui sistem pengembangan yang telah disusupi.
• Pelanggan di hilir melalui kompromi rantai pasokan perangkat lunak.

Potensi risiko keamanan dirangkum dalam diagram berikut:

Risiko aplikasi dan pengembangan

Beban kerja aplikasi dapat dikompromikan melalui kelemahan yang diperkenalkan selama pengembangan atau melalui dikompromikannya infrastruktur yang digunakan untuk membangun dan menerapkannya.

Risk	Target	Potensi hasil
Desain/implementasi aplikasi	Masalah keamanan yang diperkenalkan selama desain atau pengembangan dapat mengekspos beban kerja ke teknik serangan seperti: - Validasi input yang tidak tepat - Logika autentikasi atau otorisasi yang tidak aman - Kriptografi yang lemah atau tidak diimplementasikan dengan benar - Paparan data sensitif melalui logika aplikasi	Kelemahan ini mungkin memungkinkan penyerang untuk: - Mengakses atau memanipulasi data aplikasi - Jalankan operasi yang tidak sah - Pertahankan akses persisten melalui kelemahan logika yang ditanamkan.
Infrastruktur/otomatisasi pengembangan	Serangan mungkin menargetkan: - Repositori kode sumber - Membangun alur - Otomatisasi penerapan - Templat infrastruktur sebagai kode (IaC) - Mengembangkan titik akhir atau identitas layanan	Kompromi mungkin memungkinkan penyerang untuk: - Sisipkan kode berbahaya ke dalam artefak build - Mengubah konfigurasi penyebaran - Mempertahankan akses persisten melalui kelemahan logika yang ditanamkan - Dapatkan kredensial atau rahasia yang digunakan di lingkungan produksi.
Rantai pasokan perangkat lunak pengembangan	Aplikasi biasanya mengandalkan: - Pustaka pihak ketiga - Paket sumber terbuka - Gambar kontainer - Layanan platform	Kerentanan atau kode berbahaya yang diperkenalkan melalui dependensi ini dapat memengaruhi: - Beban kerja produksi organisasi - Lingkungan pelanggan atau mitra

Mengintegrasikan keamanan ke dalam proses pengembangan mengurangi kemungkinan risiko ini disebarluaskan ke dalam rilis produksi.

Pergeseran ke kiri

Shift left adalah pendekatan rekayasa keamanan yang mengintegrasikan keamanan lebih awal ke dalam siklus hidup pengembangan.

Alih-alih memvalidasi keamanan di tahap akhir proses, organisasi mengintegrasikannya ke dalam:

• Membayangkan
• Design
• Pengembangan
• Operations

Ini mengurangi biaya remediasi dan paparan risiko.

Untuk mendukung pendekatan ini, organisasi harus

• Gunakan praktik terbaik terstruktur seperti Siklus Hidup Pengembangan Keamanan (SDL) di awal proses, daripada terlambat ketika masalah menjadi mahal dan sulit diperbaiki.
• Untuk mempertahankan pendekatan ini, integrasikan tata kelola, risiko, dan kepatuhan (GRC) ke dalam strategi pengembangan.

Apa itu DevSecOps?

DevSecOps memberikan pendekatan Shift Left dengan memperluas DevOps dan menyematkan keamanan ke dalam setiap tahap siklus hidup pengembangan perangkat lunak - dari awal ide melalui desain, pengembangan, dan operasi.

• Dalam pendekatan pengembangan tradisional, validasi keamanan sering dilakukan sebagai gerbang kualitas akhir sebelum rilis. Ini menciptakan penundaan, peningkatan biaya remediasi, dan memungkinkan kerentanan bertahan hingga akhir siklus hidup.

• DevSecOps menggeser keamanan lebih awal dan menyematkannya terus menerus ke dalam proses pengembangan dan operasional.

• DevSecOps mengurangi gesekan antara tim pengembangan, operasi, dan keamanan, menyelaraskannya di sekitar tujuan bersama kecepatan inovasi, keandalan, dan ketahanan keamanan, dan memungkinkan tim untuk mengatasi masalah yang paling penting dini dan terus menerus.

• DevSecOps mengintegrasikan keamanan ke dalam:

  • Desain Arsitektur
  • Implementasi aplikasi
  • Otomatisasi infrastruktur
  • Proses penyebaran dan operasional

Benefits

DevSecOps memungkinkan tim pengembangan, keamanan, dan operasi untuk:

• Identifikasi dan remediasi masalah sebelumnya dalam siklus hidup.
• Kurangi keterpaparan di lingkungan produksi.
• Pertahankan kecepatan pengiriman sambil mengelola risiko.

Keamanan menjadi bagian dari bagaimana perangkat lunak dibangun dan dikirimkan, daripada kontrol yang diterapkan setelah pengiriman.

Siklus hidup inovasi yang aman

Inovasi biasanya berkembang melalui dua tahap siklus hidup:

Panggung	Rincian
Inkubasi ide	Kemampuan dirancang, diimplementasikan, dan divalidasi untuk penggunaan produksi awal. Dimulai dengan ide baru
Rilis awal	Rilis produksi pertama memenuhi kriteria produk minimum untuk penggunaan produk yang aman. - Pengembangan: Fungsionalitas memenuhi persyaratan bisnis minimum. - Keamanan: Kemampuan memenuhi persyaratan kepatuhan peraturan, keamanan, dan keselamatan untuk penggunaan produksi. - Operasi: Fungsionalitas memenuhi persyaratan kualitas, performa, dan dukungan minimum untuk menjadi sistem produksi.

Setelah rilis awal, pengembangan menjadi berulang saat beban kerja berkembang dengan:

• Mengubah toleransi risiko
• Persyaratan dan kematangan aplikasi
• Kewajiban peraturan
• Kondisi ancaman

Mengintegrasikan keamanan ke dalam pengembangan

Pendekatan pengembangan tradisional memvalidasi keamanan terlambat dalam siklus hidup, sebagai gerbang akhir sebelum rilis setelah desain dan implementasi selesai. Di lingkungan pengembangan modern, penundaan validasi meningkat:

• Kompleksitas kerentanan
• Biaya remediasi
• Penundaan dan gangguan operasional
• Peningkatan eksposur risiko terhadap eksploitasi aktif

DevSecOps mengintegrasikan keamanan secara terus menerus di seluruh pengembangan dan operasi, untuk mengatasi masalah sebelumnya, mengurangi risiko, dan meningkatkan konsistensi.

Praktik utama

Keamanan harus disematkan ke dalam proses pengembangan yang ada agar efektif, dapat diskalakan, dan berkelanjutan. Ini harus diintegrasikan langsung ke dalam bagaimana aplikasi dirancang, dibangun, disebarkan, dan dioperasikan, tidak diimplementasikan dalam alur kerja terpisah atau paralel. Kami merekomendasikan:

• Memetakan alur kerja secara menyeluruh mulai dari ide, pengembangan, penerapan, hingga operasional berkelanjutan.
• Menentukan peran, alat, dan tanggung jawab yang jelas untuk keamanan pada setiap tahap siklus hidup.
• Menetapkan jalur remediasi yang konsisten untuk kerentanan, cacat, dan masalah desain.

Menyesuaikan praktik keamanan berdasarkan risiko beban kerja. Aplikasi penting bisnis memerlukan kekakuan yang lebih besar, sementara skenario berisiko lebih rendah dapat mengikuti pendekatan yang disederhanakan.

Minimal, pastikan Anda:

• Identifikasi tahapan, orang, dan teknologi yang terlibat dalam siklus hidup pengembangan Anda.
• Tentukan bagaimana aktivitas keamanan terintegrasi ke dalam setiap tahap, daripada memperlakukannya sebagai titik pemeriksaan terpisah.
• Tetapkan proses untuk menangani perubahan besar dan perbaikan rutin sepanjang siklus hidup.

Mengotomatiskan keamanan ke dalam pengembangan dan penyebaran

Automation sangat penting untuk memberlakukan keamanan secara konsisten dan dalam skala besar di seluruh pengembangan dan operasi.

• Integrasikan kontrol dan alat keamanan langsung ke alur CI/CD.
• Mengotomatiskan aktivitas utama seperti pemodelan ancaman, pemindaian kode, validasi, dan penegakan kebijakan.
• Gunakan Infrastructure as Code (IaC) untuk mengaktifkan penyebaran yang dapat diulang dan aman.

Fondasi platform seperti landing zone Azure dapat mendukung pendekatan ini dengan

Fondasi platform seperti zona pendaratan Azure dapat mendukung pendekatan ini dengan menyediakan pola standar untuk keamanan, tata kelola, dan integrasi DevOps.

Hasil yang diharapkan

Organisasi yang beralih dari DevOps ke DevSecOps dapat:

• Mengurangi kemungkinan kerentanan dimasukkan ke dalam beban kerja produksi
• Membatasi kemampuan penyerang untuk mengeksploitasi infrastruktur atau otomatisasi pengembangan
• Meningkatkan ketahanan aplikasi untuk mengembangkan teknik serangan
• Mendukung persyaratan kepatuhan terhadap peraturan dan organisasi
• Mempertahankan kecepatan inovasi tanpa meningkatkan risiko operasional atau keamanan

Tips menavigasi perjalanan

Mengadopsi DevSecOps memerlukan perubahan organisasi dan budaya.

Perubahan pendidikan dan budaya

Ini adalah langkah-langkah awal yang penting. Tim yang Anda miliki harus mengembangkan keterampilan baru dan mengadopsi perspektif baru untuk memahami model DevSecOps.

Perubahan pendidikan dan kebudayaan membutuhkan waktu, fokus, sponsor eksekutif, dan menindaklanjuti secara teratur untuk membantu individu sepenuhnya memahami dan melihat nilai perubahan.

Mengubah budaya dan keterampilan secara drastis terkadang dapat memanfaatkan identitas profesional individu, menciptakan potensi ketahanan yang kuat. Sangat penting untuk memahami dan mengekspresikan mengapa, apa, dan bagaimana perubahan untuk setiap individu dan situasi mereka.

Perubahan membutuhkan waktu

Anda hanya dapat bergerak secepat tim Anda dapat beradaptasi dengan implikasi melakukan hal-hal dengan cara baru. Tim harus tetap menjalankan tugas yang sudah ada sambil bertransformasi.

Sangat penting untuk memprioritaskan dengan hati-hati apa yang paling penting dan untuk mengelola harapan seberapa cepat perubahan ini dapat terjadi.

Berfokus pada strategi bertahap “merangkak, berjalan, lalu berlari”, di mana elemen yang paling penting dan mendasar didahulukan, akan sangat bermanfaat bagi organisasi Anda.

Perubahan menyebabkan hambatan (sementara)

Semua teknologi, metodologi, dan perubahan baru lainnya menimbulkan gesekan dan kebingungan. Sangat penting untuk fokus pada gesekan sehat yang mendorong pemikiran kritis untuk mengurangi risiko sekaligus menghindari gesekan yang tidak sehat yang memperlambat proses dengan manfaat terbatas atau pengurangan risiko.

Sumber daya terbatas

Tantangan yang biasanya dihadapi organisasi sejak dini adalah menemukan bakat dan keterampilan dalam pengembangan keamanan dan aplikasi.

Ketika organisasi mulai berkolaborasi lebih efektif, mereka mungkin menemukan bakat tersembunyi, seperti pengembang dengan pola pikir keamanan atau profesional keamanan dengan latar belakang pengembangan.

Pergeseran yang sedang berlangsung

Aplikasi berubah dengan cepat. Selain fitur baru, definisi teknis dan komposisi aplikasi pada dasarnya berubah dengan pengenalan teknologi seperti cloud, tanpa server, dan AI.

Pergeseran ini mengubah praktik pengembangan, keamanan aplikasi, dan bahkan memberdayakan nondeveloper untuk membuat aplikasi.

Pertimbangkan model SRE

Beberapa implementasi DevSecOps menggabungkan operasi dan tanggung jawab keamanan ke dalam peran teknisi keandalan situs (SRE ).

Meskipun model seperti itu dapat berfungsi, sering kali merupakan perubahan ekstrem dari budaya dan praktik perusahaan yang ada.

Jika Anda sedang mempertimbangkan model SRE, kami menyarankan agar Anda memulai dengan mengintegrasikan keamanan ke dalam DevOps menggunakan langkah-langkah praktis yang memberikan hasil cepat dan kemajuan bertahap yang diuraikan dalam panduan ini, untuk memastikan bahwa Anda memperoleh laba atas investasi (ROI) yang baik dan memenuhi kebutuhan mendesak.

Hal ini secara bertahap menambah tanggung jawab keamanan bagi personel operasional dan pengembangan Anda, sehingga membawa tim semakin dekat ke kondisi akhir SRE.

Langkah berikutnya

Pelajari tentang praktik terbaik pengembangan yang aman.