Untuk memulainya, secara umum tentang proyek. Kami telah membangun proses pengembangan yang aman di sebuah perusahaan perdagangan besar di mana departemen TI memiliki banyak staf dan dibagi menjadi banyak area yang berkorelasi minimal satu sama lain. Secara konvensional, kawasan ini dapat dibagi menjadi 3 kelompok utama. Yang pertama, kelompok yang sangat besar, adalah software mesin kasir, yang sebagian besar ditulis di Jawa (90% proyek). Grup sistem kedua yang paling luas dalam hal jumlah kode adalah aplikasi SAP. Dan terakhir, blok ketiga adalah "gado-gado" portal dan aplikasi seluler: berbagai situs eksternal untuk klien perusahaan, aplikasi seluler untuk situs ini, serta sumber daya internal - aplikasi seluler dan portal web untuk staf pengecer.
Pelanggan proyek - departemen keamanan informasi - merumuskan tugas umum dengan cara yang cukup standar untuk ketiga kelompok: "kami ingin mengurangi kerentanan pada keluaran dan mengamankan pengembangan semua sistem yang dibuat di dalam perusahaan". Namun dalam praktiknya, di setiap departemen tertentu, semuanya tampak sangat berbeda dari kolega lainnya, karena di setiap langkah penerapan pengembangan yang aman, kami harus membuat jutaan kompromi yang berbeda. Beberapa nuansa membantu membangun proses, sementara yang lain, sebaliknya, ikut campur. Pada akhirnya, kami masih berhasil membuat pendekatan yang kurang lebih umum untuk sebagian besar proyek.
Kami merumuskan pendekatan ini sesederhana mungkin: kode yang paling relevan untuk semua pengembang dipindai. Jika kita berbicara tentang Gitflow, dan semua grup proyek, kecuali SAP, memiliki cabang pengembangan di Gitflow, cabang pengembangan utama dipindai pada jadwal.
Namun, seperti biasa, ada pengecualian untuk aturan apa pun: pendekatan umum tidak dapat diterapkan di mana pun "sebagaimana adanya" karena sejumlah alasan. Pertama, alat kami (penganalisis kode) memiliki beberapa keterbatasan karena kami ingin dapat, jika perlu, melakukan analisis paling mendalam dari beberapa bahasa pemrograman. Jadi, dalam kasus Java, bytecode analisis jauh lebih dalam daripada kode sumber. Oleh karena itu, memindai proyek Java memerlukan perakitan awal bytecode dan baru kemudian mengirimkannya untuk dianalisis. Dalam kasus aplikasi C ++, Objective C dan iOS, penganalisis dibangun ke dalam proses pada tahap pembuatan. Kami juga harus mempertimbangkan berbagai persyaratan individu dari pengembang semua proyek. Di bawah ini adalah cara kami membangun proses untuk portal dan aplikasi seluler.
Portal dan aplikasi seluler
Tampaknya semua aplikasi ini digabungkan menjadi satu kelompok logis, tetapi pada kenyataannya mereka berantakan. Ada lebih dari 120 portal (!). Perusahaan ini sangat besar, dengan banyak departemen bisnis, administrasi, dan teknis, dan dari waktu ke waktu masing-masing memutuskan bahwa mereka membutuhkan portal dan aplikasi selulernya sendiri. Portal dan aplikasi ini dibuat, digunakan selama beberapa waktu, dan kemudian ditinggalkan dengan aman. Akibatnya, pada tahap awal, kami harus melakukan inventarisasi untuk pelanggan, karena bahkan pengembang aplikasi ini tidak memiliki satu pun daftar basis kode. Misalnya, untuk mengelola repositori di grup ini, pengembang menggunakan dua GitLab dengan administrator berbeda. Selain itu, di antara portal dan aplikasi seluler, sebagian besar proyek diimplementasikan menggunakan pengembangan eksternal.Oleh karena itu, ketika waktu rilis semakin dekat, kontraktor sering kali mentransfer kode sumber versi baru ke perusahaan hampir di flash drive USB. Akibatnya, perusahaan memiliki kebun binatang yang terdiri dari berbagai aplikasi dan kode mereka berantakan. Kami harus membuat daftar semua proyek, menemukan semua yang bertanggung jawab untuknya - pemilik teknis, pimpinan tim, dan kemudian setuju dengan pelanggan utama - departemen keamanan informasi, yang mana di antaranya akan kami analisis.
Akibatnya, kami memilih sistem produksi dan perangkat lunak pendukung untuk analisis, dan sama sekali tidak menyentuh sistem pengarsipan. Sejumlah aplikasi internal dianggap tidak kritis, karena tidak dapat menyebabkan kerugian finansial bagi perusahaan, dan tidak dipilih untuk analisis. Misalnya, sistem manajemen untuk pengemas dalam satu gudang atau pemuat. Tidak ada yang rentan terhadap klien eksternal perusahaan di dalamnya, dan peretasan mereka oleh salah satu karyawan internal hanya akan menyebabkan ketidaknyamanan internal kecil ke sejumlah departemen.
Layanan IS telah merumuskan pengenalan analisis kode untuk kerentanan sebagai tugas prioritas untuk grup perangkat lunak ini, dan pengembang - untuk membangun proses verifikasi yang mudah diintegrasikan ke dalam siklus pengembangan.
Integrasi sesuai dengan skema standar
GitLab dari dua versi berbeda digunakan sebagai sistem kontrol versi dalam grup portal dan aplikasi seluler.
Menyiapkan integrasi dengan GitLab
Tidak semua aplikasi menggunakan CI / CD, dan jika tidak, kami harus bersikeras menggunakannya. Karena jika Anda ingin benar-benar mengotomatiskan proses pemeriksaan kode untuk menemukan kerentanan (dan tidak hanya mengunggah tautan secara manual untuk analisis) sehingga sistem itu sendiri mengunduhnya ke repositori dan dengan sendirinya memberikan hasil kepada spesialis yang diperlukan, maka Anda tidak dapat melakukannya tanpa menginstal pelari. Pelari dalam hal ini adalah agen yang secara otomatis menghubungi sistem kontrol versi, mendownload kode sumber dan mengirimkannya ke Solar appScreener untuk dianalisis.
Pengembang Portal dan Grup Aplikasi Seluler ingin mengatur pengembangan aman sebagai proses semi-otomatis sehingga kode dipindai untuk menemukan kerentanan tanpa keterlibatan mereka. Untuk petugas keamanan untuk memverifikasi hasil analisis untuk kerentanan dan memberikan tugas kepada pengembang di Jira, jika dia menganggap kerentanan itu kritis, atau mengirimkannya ke pengembang untuk klarifikasi. Pengembang akan memutuskan apakah akan segera memperbaiki kerentanan atau tidak. Dan jika perlu, mereka akan merencanakan rilis mana yang dapat menyertakan perbaikan.
Jira terutama digunakan sebagai pelacak bug, di mana penganalisis kode secara otomatis memberikan informasi tentang kerentanan yang ditemukan.
Penyiapan integrasi Jira
Dalam kasus yang jarang terjadi, pimpinan tim melihat sendiri hasil perayapan dan memulai tugas di Jira secara manual.
Membuat tugas di Jira
Kami juga mendaftarkan kasus seperti itu di regulasi sebagai fitur terpisah. Di beberapa proyek, secara umum, semua perbaikan dibahas di Slack atau Telegram, dan tugas ditetapkan secara real time.
Hasilnya, proses pengembangan yang aman setelah penerapan Solar appScreener mulai terlihat seperti ini: portal diperiksa setiap hari untuk perubahan kode cabang pengembangan utama. Jika cabang utama dan paling relevan belum diperbarui dalam 24 jam, maka tidak ada yang terjadi. Jika telah diperbarui, maka cabang ini dikirim untuk dianalisis ke proyek terkait untuk repositori ini. Repositori di GitLab terkait dengan proyek tertentu di penganalisis kode, dan di proyek inilah cabang utama dipindai. Setelah itu, petugas keamanan meninjau hasil analisis, melakukan verifikasi, dan memulai tugas pembenahan di Jira.
Hasil analisis dan tugas perbaikan kerentanan dibuat di Jira
Kami mulai memperbaiki kerentanan, sebagai aturan, dari kerentanan kritis, yang perlu segera dihilangkan. Ketika kerentanan seperti itu berakhir, tim melanjutkan untuk memperbaiki kesalahan baru yang ditemukan dalam kode. Dan sudah di tahap ketiga, misalnya, dalam rangka menutup beberapa utang teknis, kerentanan lama yang tersisa juga dihilangkan.
Non-standar sebagai standar
Sekilas, proses yang tidak begitu rumit ini memiliki dua batasan serius. Pertama, untuk menganalisis aplikasi Android (yaitu yang ditulis di Java), kami membutuhkan perakitan. Dan kedua, iOS membutuhkan mesin macOS tempat agen kami akan diinstal dan akan ada lingkungan yang memungkinkan kami membangun aplikasi. Kami menangani aplikasi Android dengan cukup sederhana: kami menulis bagian kami ke dalam skrip yang sudah tersedia untuk pengembang, yang juga diluncurkan sesuai jadwal. Bagian skrip kami telah meluncurkan pembuatan proyek sebelumnya dalam konfigurasi terluas, yang dikirim ke Solar appScreener untuk dianalisis. Untuk memeriksa aplikasi iOS, kami menginstal agen MacOS kami di mesin Mac, yang mengumpulkan kode dan juga mengirimkan kode tersebut ke penganalisis untuk dipindai melalui GitLab CI. Lebih lanjut, seperti halnya dengan jenis perangkat lunak lainnya,Petugas keamanan meninjau hasil analisis, memverifikasi, dan menyerahkan perbaikan masalah kepada Jira.
Kami juga menyebut portal dan aplikasi seluler sebagai proyek apa pun yang ditulis di Java - kami mengumpulkan dan menganalisisnya dengan cara yang serupa.
Dalam proyek di mana tidak ada CI / CD, yang merupakan prasyarat bagi kami, kami hanya berkata: “Teman-teman, jika Anda ingin menganalisis, kumpulkan secara manual dan muat sendiri ke pemindai. Jika Anda tidak memiliki bahasa seperti Java atau JVM - Scala, Kotlin, dan lainnya, Anda cukup mengunggah kode ke repositori dari tautan, dan semuanya akan baik-baik saja. "
Kompleksitas proyek
Seperti yang Anda lihat di atas, dalam tumpukan aplikasi ini, masalah utama adalah kurangnya CI / CD di banyak proyek. Pengembang sering kali membangun dengan tangan. Kami mulai mengintegrasikan penganalisis kami dengan portal Sharepoint di C #. Sekarang C # telah lebih atau kurang beralih ke sistem Linux, meskipun tidak sepenuhnya lengkap. Dan saat proyek berjalan lancar, bahasa ini masih berfungsi di Windows, dan kami harus menginstal agen di Windows untuk GitLab. Ini adalah tantangan nyata karena spesialis kami terbiasa menggunakan perintah Linux. Solusi khusus diperlukan, misalnya, dalam beberapa kasus perlu menentukan path lengkap ke file exe, di beberapa tidak, ada sesuatu yang harus di-escape, dll. Dan setelah implementasi integrasi dengan Sharepoint, tim proyek aplikasi seluler di PHP berkata,bahwa mereka juga tidak memiliki pelari dan mereka ingin menggunakan C #. Saya harus mengulangi operasi untuk mereka.
Ringkasan
Hasilnya, terlepas dari berbagai macam teknologi, tim, dan proses yang begitu beragam, kami berhasil mengelompokkan kasus utama kasus ini ke dalam beberapa jalur pipa, mengotomatiskan pelaksanaannya, jika sesuai, dan mengimplementasikannya. Dalam contoh kami, kami dapat memastikan bahwa:
- Solusi yang kami terapkan sudah cukup tua untuk memberikan fleksibilitas yang Anda butuhkan untuk membangun proses DevSecOps di lingkungan penerapan yang sangat berbeda. Fleksibilitas dicapai karena sekumpulan besar integrasi bawaan dan kustom, yang tanpanya biaya tenaga kerja untuk implementasi akan meningkat secara signifikan atau membuatnya tidak mungkin;
- . 3-4 ;
- DevSecOps DevOps , , . win-win - .
Ingat: ini adalah bagian pertama dari rangkaian artikel tentang membangun proses pengembangan yang aman di pengecer besar. Di posting berikutnya, kami akan mengungkapkan detail implementasi proyek ini dalam grup aplikasi keluarga SAP.
Apakah Anda pernah memiliki pengalaman sendiri dalam melaksanakan proyek serupa? Kami akan senang jika Anda berbagi dengan kami kasus Anda dalam menerapkan praktik pengembangan aman di komentar!
Penulis: Ivan Staroselsky, Kepala Departemen Operasi dan Otomasi Sistem Informasi