5 Kesalahan Umum DevSecOps

Belakangan ini, DevSecOps menjadi bagian tidak terpisahkan dari program AppSec perusahaan. Munculnya transformasi digital dan semakin cepatnya proses pengembangan perangkat lunak memerlukan keamanan yang lebih cepat juga dan solusinya adalah menyematkan tes keamanan langsung ke dalam SDLC.

Namun, kami melihat beberapa kesalahan umum ketika perusahaan mencoba merancang proses DevSecOps mereka yang dapat menyebabkan kompleksitas tak terduga kemudian.

Mari kita bahas 5 kesalahan paling umum yang kami amati saat ini.

Otomasi yang Tidak Direncanakan

Mari kita mulai dengan kesalahan paling umum yang juga paling mudah diperbaiki.

Meskipun otomasi sangat penting untuk adopsi DevSecOps yang sukses, kami melihat pendekatan yang sedikit cacat dalam praktik.

Memulai pemindaian dalam pipa tidak lagi menjadi masalah karena hampir semua vendor keamanan sekarang menawarkan integrasi asli dengan pipa.

Namun, hanya memicu pemindaian dalam pipa dengan cara otomatis dianggap sebagai pencapaian DevSecOps sedangkan sedikit perhatian dibayar pada tahap optimal SDLC di mana pemindaian akan dimulai.

Dalam banyak kasus, solusi intuitif adalah memicu pemindaian secara otomatis dan memeriksa kerentanan pada setiap push code ke repositori tanpa memikirkan banyak tentang keberlanjutan pendekatan ini.

Dengan pendekatan ini, tidak lama sebelum para pengembang mulai merasa terbatas dan frustrasi dan memulai pemberontakan. Ini cepat mempengaruhi adopsi DevSecOps karena mustahil mencapai titik tersebut tanpa memiliki pengembang di pihak Anda.

Pendekatan yang tepat adalah mengotomatisasi tes keamanan hanya setelah memeriksa dengan hati-hati kebutuhan aplikasi dan setuju dengan pendekatan yang tepat dengan tim pengembangan.

Menjaga tim pengembangan keluar dari lingkaran saat merancang otomasi adalah ide buruk dan menghambat keberhasilan adopsi DevSecOps jangka panjang.

Tooling yang tidak akurat

Di bawah tekanan manajemen untuk memulai program AppSec, tim AppSec sering mengeluarkan uang yang signifikan untuk alat mahal tanpa melakukan proses PoV yang tepat untuk memahami bagaimana alat itu cocok dengan kebutuhan mereka dan berharap bahwa alat tersebut akan menunjukkan mereka ke arah yang benar.

Pada akhir hari, bukan memilih alat yang tepat yang bekerja dengan baik dengan proses yang ada di organisasi, proses ditentukan berdasarkan kemampuan alat yang dipilih, yang jauh dari pendekatan vendor-agnostik yang dibutuhkan dalam DevSecOps.

Jangan lupa bahwa alat mungkin dan berubah seiring waktu. Oleh karena itu, bukan membuat proses baru setiap kali alat baru diterima, lebih baik memilih alat yang tepat berdasarkan proses yang disetujui.

Performa luar biasa dari alat keamanan open source dalam beberapa bahasa pemrograman dan lingkungan membuat mereka opsi terpercaya untuk mengatasi rasa tidak sabar sebelum membawa alat komersial dan memulai membangun proses tanpa harus membelanjakan fortune.

Pendekatan satu-alat-cocok-semua tidak bekerja dalam DevSecOps dan Anda perlu memahami stack teknologi Anda sendiri dan cara kerja tim pengembangan Anda untuk tooling yang sehat untuk proses DevSecOps Anda.

Miskonfigurasi

Setelah sebuah kesepakatan ditutup, kebanyakan vendor keamanan mengambil pendekatan dukungan pelanggan yang reaktif dan fokus pada menjawab pertanyaan pelanggan daripada bekerja proaktif dalam mengkonfigurasi alat untuk memaksimalkan kinerjanya dalam lingkungan pelanggan.

Sebagian besar waktu, sangat membingungkan melihat seberapa banyak kualitas temuan dapat membaik dengan konfigurasi yang lebih baik. Penurunan signifikan dalam jumlah positif salah adalah hasil yang sangat mungkin yang menjadi kunci untuk mengurangi gesekan dengan tim pengembangan.

Oleh karena itu, sebagai gantinya fokus pada pemindaian secara otomatis dilakukan dalam pipa, langkah pertama selalu harus mengkonfigurasi pemindai yang membayar dividen jangka panjang dengan mengurangi jumlah kerentanan untuk ditangani.

Tanpa konfigurasi yang tepat, harus menghapus ratusan bahkan ribuan kerentanan yang tidak relevan menjadi overwhelming dan mengecewakan baik untuk tim keamanan maupun tim pengembangan.

Kekurangan Metrix

Akibat kekurangan metrik, pertanyaan "Seberapa aman kami?" adalah pertanyaan paling sulit untuk dijawab dalam dunia TI. Karena alasan yang sama, sulit untuk menunjukkan ROI dari program AppSec, sementara selalu ada tekanan organisasi untuk mengukur kesuksesan.

Meskipun sulit untuk menilai tingkat postur keamanan Anda, tanpa metrik yang terpikir dengan baik, juga mustahil untuk mengukur efektivitas program keamanan secara keseluruhan.

Menciptakan metrik seperti waktu untuk merespons atau memperbaiki kerentanan dan mendefinisikan KPI untuk setiap metrik membantu memahami sejauh mana proses diambil secara serius seluruh organisasi.

DevSecOps adalah maraton bukan lari cepat dan Anda harus tahu apa yang Anda lakukan dengan baik dan apa yang perlu ditingkatkan untuk sampai pada keadaan yang diinginkan dalam jangka waktu.

Mengabaikan Filosofi DevSecOps

Sebagai topik teknis, DevSecOps juga merupakan konsep budaya yang membutuhkan usaha kerjasama dan dukungan dari semua tim keamanan, pengembangan, dan DevOps. Jika tidak, hanya akan destinasi untuk gagal.

Dalam dunia nyata, sangat umum melihat konflik muncul antara tim pengembangan dan keamanan seperti pertarungan tali dimana setiap tim mencoba untuk memegang garis mereka dan menyalahkan tim lain baik karena membawa keamanan cacat atau tidak memperbaiki cacat dengan cepat.

Hal ini terutama terjadi ketika tim keamanan bekerja dalam silo dan membuat keputusan tanpa berkoordinasi dengan tim pengembangan atau DevOps untuk membrief mereka tentang manfaat DevSecOps untuk aplikasi berkualitas tinggi dan risiko potensial dari tidak melakukannya.

Selalu ada ide yang baik untuk mengadakan sesi perencanaan dimana semua pemangku kepentingan terlibat dimana proses, metrik, dan KPI diputuskan bersama. Hanya setelah itu pihak yang terlibat dapat bertanggung jawab atas tidak mematuhi aturan yang ditentukan bersama.