6 Praktik DevSecOps Terbaik yang Perlu Anda Lakukan!

Organisasi yang mengintegrasikan keamanan ke dalam alur DevOps mereka harus mengadopsi alat dan praktik yang menyatukan pengembangan aplikasi, operasi TI, pengujian QA, dan tim keamanan di bawah rubrik DevSecOps umum.

Tujuannya adalah untuk menjadikan keamanan sebagai bagian dari alur kerja pengembangan perangkat lunak, dengan praktik terbaik pengkodean yang aman dan otomatisasi pengujian, daripada menguncinya di kemudian hari dalam siklus, seperti yang terjadi pada model pengembangan air terjun.

Pergeseran ini membalikkan gagasan tradisional tentang bagaimana, kapan, dan di mana kontrol keamanan harus diintegrasikan ke dalam perangkat lunak. Merupakan tantangan bagi kelompok yang pernah berdiri sendiri untuk menemukan cara bekerja sama untuk memberikan rilis kode yang cepat namun aman.

"DevSecOps telah mengalami peningkatan popularitas yang stabil," kata Ryan O'Leary, kepala peneliti keamanan di WhiteHat Security. Perusahaan yang telah menggabungkan tim pengembangan dan operasi di bawah model DevOps dalam beberapa tahun terakhir umumnya merilis kode pada tingkat yang jauh lebih cepat.

Namun tren telah meningkatkan kebutuhan akan keamanan untuk diintegrasikan ke dalam proses karena semakin cepat Anda merilis kode, semakin cepat pula kerentanan dapat dilepaskan, katanya.

Berikut adalah praktik terbaik yang penting bagi organisasi yang ingin menerapkan DevSecOps.

Jadikan otomatisasi sebagai teman Anda

Kecepatan adalah salah satu prinsip utama DevOps. Dalam lingkungan continuous integration dan continuous deployment (CI/CD), seberapa cepat Anda bisa mengeluarkan kode dan masuk ke produksi mengalahkan hampir semua hal lainnya. Agar keamanan menjadi bagian dari alur kerja ini, itu perlu diotomatisasi, kata Chris Romeo, CEO, konsultan utama, dan salah satu pendiri Security Journey.

Itu harus menyematkan kontrol dan pengujian keamanan lebih awal dan di mana saja dalam siklus hidup pengembangan. Mereka perlu terjadi secara otomatis karena organisasi mendorong versi kode baru ke dalam produksi 50 kali per hari untuk satu aplikasi.

"Dengan DevOps, Anda harus bergerak sangat cepat. Tidak ada 'manual' dalam proses itu. Jika Anda tidak memiliki otomatisasi, Anda tidak akan pernah berhasil."

—Chris Romeo

Otomatisasi telah menjadi karakteristik utama DevSecOps dalam organisasi dengan praktik DevOps yang sangat matang. Sekitar 40% responden dalam survei Sonatype terhadap hampir 2.300 profesional TI menjalankan tes keamanan otomatis awal tahun ini sepanjang siklus pengembangan. Alih-alih apa yang terjadi dengan model pengembangan air terjun, ini adalah saat tes keamanan otomatis dijalankan tepat sebelum produksi.

Semakin banyak alat otomatisasi pengujian dengan berbagai kemampuan telah tersedia untuk analisis dan pengujian keamanan di seluruh siklus pengembangan perangkat lunak, mulai dari penelitian kode sumber hingga integrasi dan pemantauan pasca penerapan. Ini termasuk Checkmarx, Splunk, Keamanan Kontras, Sonatype, Tanium, InSpec, FireEye, dan Metasploit.

Otomatiskan dengan cermat

Saat mengotomatiskan pengujian keamanan, lakukan dengan hati-hati, kata Romeo. Jika Anda melakukan pengujian keamanan aplikasi statis (SAST) pada build malam, misalnya, pastikan Anda hanya memindai hal-hal yang menarik dalam perubahan kode Anda yang telah dilakukan untuk hari itu.

Mencoba menjalankan pemindaian otomatis pada seluruh kode sumber aplikasi Anda setiap hari dapat menghabiskan banyak waktu dan merusak kemampuan Anda untuk mengikuti perubahan harian.

Selain itu, pertimbangkan untuk menyematkan pengujian keamanan aplikasi dinamis otomatis (DAST) ke dalam siklus pengembangan perangkat lunak Anda. Tidak seperti analisis statis, yang berfokus pada menemukan potensi masalah keamanan dalam kode itu sendiri, DAST mencari kerentanan secara real-time saat aplikasi berjalan.

Otomatiskan pemindaian DAST dan jalankan mereka terhadap perubahan kode terbaru atau baru untuk menangkap kerentanan keamanan yang tercantum pada daftar Open Web Application Security Project (OWASP) dari kelemahan paling umum, seperti kesalahan injeksi SQL, yang mungkin Anda lewatkan selama analisis statis Anda kode aplikasi, kata Romeo. Anda membutuhkan keduanya secara otomatis karena Anda tidak pernah tahu apa yang mungkin Anda lewatkan hanya dengan satu rangkaian tes.

Menambahkan analisis keamanan otomatis dalam platform CI dapat membatasi pengenalan kode rentan lebih awal dalam siklus pengembangan perangkat lunak, kata Manish Gupta, salah satu pendiri, dan CEO ShiftLeft.

Otomatisasi dapat digabungkan dengan agen tertanam yang ringan untuk memberikan analisis runtime terkait tentang masalah yang terdeteksi dari analisis keamanan otomatis Anda. Secara bersamaan, pendekatan ini memudahkan pengembang untuk memprioritaskan masalah kode apa yang perlu mereka perbaiki, kata Gupta.

Periksa dependensi kode Anda

Terlepas dari kekhawatiran yang berkembang tentang risiko penggunaan komponen perangkat lunak pihak ketiga, perusahaan menggunakan lebih banyak perangkat lunak sumber terbuka dalam aplikasi, tidak kurang, menurut survei Black Duck Software yang dilakukan awal tahun 2017.

Audit terpisah yang dilakukan perusahaan pada lebih dari 1.000 aplikasi komersial menunjukkan bahwa 96% di antaranya menyertakan komponen sumber terbuka. Lebih dari 6 dari 10 aplikasi mengandung kerentanan keamanan yang diketahui dalam komponen tersebut, dan beberapa telah ada selama empat tahun. Meskipun demikian, hanya 27% responden yang mengatakan bahwa mereka memiliki identifikasi otomatis dan proses pelacakan perbaikan untuk kelemahan yang diketahui dalam perangkat lunak sumber terbuka.

Gupta mengatakan bahwa memahami penggunaan sumber terbuka adalah kunci untuk adopsi yang lebih luas dari praktik DevSecOps. "Cloud telah memicu inovasi dengan cara yang belum pernah terjadi sebelumnya, memungkinkan perusahaan untuk memenuhi kebutuhan pelanggan lebih cepat. Laju inovasi ini juga membawa peningkatan penggunaan perangkat lunak sumber terbuka untuk merakit aplikasi, daripada mengembangkannya dari awal."

Gupta mengatakan bahwa pengembang sering tidak memiliki waktu untuk meninjau kode di perpustakaan sumber terbuka mereka atau membaca dokumentasi, sehingga proses otomatis untuk mengelola komponen sumber terbuka dan pihak ketiga merupakan persyaratan mendasar untuk DevSecOps. Anda perlu tahu apakah penggunaan sumber terbuka Anda menyebabkan kerentanan kontekstual dan lainnya dalam kode Anda dan apa dampak kerentanan tersebut pada kode dependen.

Pemeriksaan ketergantungan kode sangat penting bagi DevSecOps, dan utilitas seperti OWASP Dependency-Check dapat membantu memastikan bahwa Anda tidak menggunakan kode dengan kerentanan yang diketahui dalam perangkat lunak Anda, kata Romeo dari Security Journey.

Utilitas OWASP bekerja dengan memindai kode Anda dan pustaka komponen sumber terbuka yang bergantung untuk melihat apakah mereka mengandung kelemahan mendasar OWASP. Ini bekerja melawan basis data yang terus diperbarui dari semua kerentanan yang diketahui dalam perangkat lunak sumber terbuka.

Lakukan pengembangan keamanan secara step-by-step

Alat SAST memungkinkan pengembang memindai kode saat mereka menulisnya untuk menerima umpan balik instan tentang masalah yang mungkin menyebabkan masalah keamanan. Alat tersebut membantu pengembang mengidentifikasi dan memulihkan potensi kerentanan keamanan sebagai bagian dari alur kerja umum dan, oleh karena itu, harus menjadi komponen penting dari praktik DevSecOps Anda.

Kuncinya ketika memperkenalkan alat tersebut, bagaimanapun, adalah untuk berpikir kecil. Seringkali, ketika tim keamanan mengimplementasikan alat pengujian statis dalam rantai CI/CD, grup tersebut cenderung mengaktifkan pemeriksaan untuk seluruh masalah keamanan dan akhirnya hanya menciptakan masalah bagi pengembang, kata Romeo.

Alih-alih, jauh lebih baik untuk mengaktifkan satu atau dua pemeriksaan keamanan sekaligus dan membuat pengembang Anda terbiasa dengan gagasan untuk memasukkan aturan keamanan ke dalam alur kerja mereka.

"Anda perlu membangun kepercayaan pada alat ini sebelum Anda mengaktifkan lebih banyak aturan." misalnya, saat memperkenalkan alat SAST dalam pengembangan, Anda dapat mulai dengan hanya mengaktifkan aturan untuk menangkap kesalahan injeksi SQL. Setelah pengembang Anda melihat bagaimana alat membantu mereka menangkap kesalahan selama pengkodean, mereka cenderung ingin bekerja dengannya.

Saat membangun kapabilitas DevSecOps, bagilah menjadi beberapa bagian yang dapat dikelola. "Cara terbaik untuk mendekati ini adalah dengan melihat rangkaian holistik dari semua aktivitas berbeda yang masuk ke dalam pembangunan DevSecOps," kata Romeo. Pilih satu untuk memulai dan buktikan itu berhasil sebelum pindah ke hal berikutnya.

Dia mengatakan bahwa profesional keamanan yang mengganggu akan memperlambat segalanya dan mengalami konflik dengan pengembang. Berpikir kecil pada awalnya, dan letakkan beberapa kesuksesan di belakang Anda sebelum mengambil langkah berikutnya.

Gunakan Tools yang Tepat

Banyak alat yang diperlukan untuk memasukkan keamanan ke dalam DevOps yang gesit masih muncul, jadi ingatlah beberapa pertimbangan utama saat berbelanja.

Integrasi, misalnya, sangat penting, kata O'Leary dari WhiteHat Security. "Produk keamanan harus dapat diintegrasikan ke dalam jalur pengembangan dan memungkinkan tim pengembangan dan keamanan untuk bekerja sama, bukan hanya saling melempar barang," katanya.

Jika pengembang harus keluar dari jalan mereka untuk memulai pemindaian, ada kemungkinan besar mereka akan meninggalkan alat pemindaian. "Produk keamanan perlu memudahkan pengembang untuk memulai pemindaian dengan cepat dan mendapatkan hasil tanpa harus meninggalkan perangkat yang sudah ada," kata O'Leary.

Persyaratan penting lainnya adalah kecepatan dan akurasi. Alat keamanan harus bekerja dengan cepat. Tapi positif palsu bisa menjadi pembunuh mutlak di lingkungan DevOps, O'Leary memperingatkan.

Alat yang mengharuskan pengembang atau insinyur keamanan meluangkan waktu untuk memverifikasi temuan pemindaian tidak banyak membantu. Hasil yang dihasilkan alat Anda harus cepat, akurat, dan segera dapat ditindaklanjuti.

Alat keamanan untuk model pengembangan air terjun tidak banyak digunakan di dunia DevSecOps. Anda memerlukan alat yang dapat membantu pengembang Anda mengidentifikasi dan memprioritaskan kerentanan saat mereka menulis perangkat lunak, kata Gupta dari ShiftLeft. Identifikasi kerentanan kode harus didasarkan pada pemahaman tentang perangkat lunak itu sendiri daripada mencocokkannya dengan tanda tangan.

Gupta memiliki beberapa saran tentang apa yang perlu dipikirkan oleh organisasi saat berbelanja alat semacam itu. Alat apa pun yang Anda pilih akan melindungi Anda tidak hanya dari kerentanan yang diketahui, tetapi juga ancaman yang tidak diketahui dan 10 risiko utama OWASP.

Alat tersebut juga akan membantu Anda mengidentifikasi dan mengatasi risiko dalam komponen perangkat lunak sumber terbuka yang Anda gunakan dan mengidentifikasi masalah dengan cara yang memungkinkan Anda mengurangi waktu penyelesaian.

"Tantangan dari adopsi DevSecOps yang meluas adalah untuk menghasilkan alat dan proses yang tidak membuat hambatan pada siklus rilis dan penerapan."

—Manish Gupta

Lakukan Threat Modelling

SANS Institute merekomendasikan pemodelan ancaman dan penilaian risiko sebelum beralih ke DevSecOps. Latihan pemodelan ancaman dapat membantu organisasi keamanan Anda mendapatkan gagasan yang lebih baik tentang ancaman terhadap aset Anda, jenis, dan sensitivitas pembelian Anda, kontrol yang ada untuk melindungi aset tersebut, dan setiap celah dalam kontrol Anda yang perlu diatasi.

Penilaian tersebut dapat membantu mengidentifikasi kekurangan dalam arsitektur dan desain aplikasi Anda yang mungkin terlewatkan oleh pendekatan keamanan lainnya.

Melakukan pemodelan ancaman di lingkungan DevOps dapat menjadi tantangan karena gagasan bahwa itu dapat memperlambat kecepatan lingkungan CI/CD, kata Romeo.

"DevOps lebih tentang mendesain dengan cepat. Beberapa orang DevOps tidak melakukan desain apa pun dan mengatakan bahwa kodenya adalah desain mereka. Itu berbahaya."

—Chris Romeo

Anda tidak dapat mengotomatiskan proses pemodelan ancaman dengan cara yang sama seperti yang Anda lakukan untuk hampir semua aspek DevOps lainnya. Tetapi pemodelan ancaman masih penting untuk keberhasilan keseluruhan upaya DevOps Anda karena membuat pengembang Anda memikirkan perangkat lunak mereka dari perspektif penyerang, kata Romeo.

Latih pengembang Anda tentang pengkodean yang aman

Anda akan menghadapi banyak tantangan saat mengadopsi DevSecOps. Salah satu yang terbesar adalah mendapatkan dukungan dari pemangku kepentingan Anda. O'Leary mengatakan bahwa tim pengembangan, keamanan, dan operasi sering kali beroperasi dalam silo dan memiliki agenda serta tugas masing-masing. "Membuat kasus kepada perusahaan bahwa mereka dapat menggabungkan organisasi-organisasi ini terkadang sedikit sulit."

Mendapatkan investasi dan waktu yang dibutuhkan untuk melatih tim pengembangan dalam pengkodean aman adalah tantangan besar lainnya. "Pengembang sering tidak tahu bahwa mereka mengkodekan dengan cara yang tidak aman. Itu masih jarang diajarkan dan bukan prioritas bagi tim pengembangan," kata O'Leary. Investasi harus dilakukan dalam melatih pengembang tentang keamanan, katanya.

Keamanan adalah tema umum lainnya, kata Gupta. Banyak praktik dan alat DevSecOps masih muncul, dan masih ada sedikit konsensus tentang definisi DevSecOps saat ini. Namun terbukti bahwa dalam dunia integrasi berkelanjutan dan siklus rilis cepat, Anda tidak dapat mengabaikan keamanan aplikasi lagi.

Implementasi proteksi keamanan yang lebih baik kemungkinan besar akan mengurangi masalah pada aplikasi yang sedang dikembangkan. Mengurangi downtime, berarti kita menghasilkan user experience dan lingkungan pengembangan yang lebih baik. Juga dengan keamanan yang mumpuni, aplikasi menjadi ebih terjamin keamanannya dari serangan oknum luar yang ingin mengganggu stabilistas aplikasi ataupun mengambil data penting. Maka dari itu #keamanan sangat penting untuk ditumbuhkan dalam lingkungan aplikasi Anda.

Bila ada kebutuhan tentang DevSecOps atau kebutuhan lainnya, Kamu bisa menghubungi kami di +62-811-1123-242 atau sales@btech.id untuk info lebih lanjut.