🧔 👩🏽‍🤝‍👨🏻 🤳🏾 (S) SDLC, atau Cara membuat pengembangan lebih aman. Bagian 1 💇 🧕🏻 🎡

Setiap tahun budaya pengembangan tumbuh, alat baru untuk memastikan kualitas kode dan ide-ide baru tentang cara menggunakan alat ini muncul. Kami sudah menulis tentang perangkat analisis statis , tentang aspek analisis apa yang perlu Anda perhatikan , dan, akhirnya, tentang bagaimana, dari sudut pandang organisasi, Anda dapat membangun proses berdasarkan analisis statis .

Berdasarkan pada masalah yang sering kita temui, kami menggambarkan seluruh proses memperkenalkan pemindai kode ke dalam proses pengembangan yang aman. Hari ini kita akan berbicara tentang bagaimana memilih penganalisa yang cocok untuk Anda.

Dengan satu atau lain cara, semua pengembang dihadapkan dengan analisis statis (analisis kode tanpa eksekusi). Misalnya, ketika kompiler menghasilkan beberapa kesalahan atau peringatan berdasarkan hasil perakitan, ini adalah hasil analisis statis. Kami sering menggunakan linter - ini juga merupakan analisis statis, meskipun seringkali sangat sederhana. Ada contoh yang lebih menarik - spotbugs (sebelumnya findbugs), yang memungkinkan Anda untuk menemukan kerentanan yang cukup menarik di bytecode Java, atau SonarQube yang terkenal - sebuah platform untuk memantau kualitas kode.

Namun, alat SAST lengkap masih jarang ditemukan. Pertama-tama, kita berbicara tentang alat yang dapat menemukan kerentanan yang kompleks. Ternyata dalam praktiknya, alat terbuka yang terkenal tidak dapat mengatasi tugas ini, setidaknya karena mereka fokus pada bidang lain (bug dan kerentanan sederhana). Alat SAST yang baik mengimplementasikan analisis aliran data interprocedural. Analisis tidak boleh terjadi pada teks program, tetapi pada presentasi internal - CFG, AST, dll. Baca lebih lanjut tentang ini di artikel sebelumnya .

SAST

Berikut adalah contoh - injeksi SQL yang terkenal. Dalam contoh ini, data dari pengguna masuk ke fungsi yang diselesaikan dari kueri, diteruskan ke fungsi injectableQuery, dan sudah ada di sana jatuh ke dalam query SQL, membuat aplikasi rentan terhadap injeksi SQL.

Untuk menemukan kerentanan seperti itu, Anda perlu memahami dari mana data "buruk" dapat berasal, bagaimana data tersebut dapat divalidasi, di mana data itu tidak dapat digunakan. Dan yang paling penting - Anda perlu memantau transfer data di seluruh aplikasi, ini adalah analisis aliran data. Contohnya sangat sederhana, dalam aplikasi nyata, data dapat melalui banyak fungsi dan modul, tugas dan sinonim.

Jelas bahwa pencarian teks tidak akan menemukan kerentanan seperti itu. Analisis intraprosedural juga tidak akan menemukan, dan dalam beberapa alat terbuka hanya diimplementasikan. Untuk menemukan kerentanan seperti itu (dan ini biasanya kerentanan paling kritis, yaitu, tujuan utama alat SAST), kita perlu algoritma yang dikembangkan dengan baik untuk analisis antar-prosedur aliran data dengan basis aturan yang besar.

Atas dasar kompleksitas algoritmik sejumlah masalah teknis muncul yang membedakan implementasi alat SAST dari analisis statis lainnya, misalnya, SonarQube. Kami akan membahas masalah ini dalam serangkaian artikel. Spoiler: konsumsi sumber daya, durasi analisis, positif palsu.

Perlu dicatat bahwa selain algoritma, alat yang baik membungkus semua matematika di shell antarmuka yang nyaman, memungkinkan Anda untuk menggunakan SAST tanpa persiapan serius. Alat-alat tersebut juga tertanam dalam CI / CD menggunakan plugins dan API, dengan demikian mengotomatiskan pencarian kerentanan dan memungkinkan Anda untuk membangun proses pengembangan yang aman.

Pada artikel pertama, kami mencoba untuk mengklasifikasikan masalah utama yang muncul selama studi SAST, serta setelah keputusan untuk mengimplementasikan alat tersebut. Kami akan berbicara tentang beberapa masalah di sini, beberapa akan pergi ke artikel berikut.

Ayo mulai

Mengapa SAST jika Anda sudah memiliki analisa statis gratis?

Kami menjawab sebagian pertanyaan ini di bagian sebelumnya. Tentu saja, kami sama sekali tidak mengurangi manfaat alat terbuka. Semua orang tahu SonarQube adalah alat yang hebat untuk mengotomatisasi penilaian kualitas kode, dengan sejumlah besar bahasa yang didukung, integrasi, dan plugin. SonarQube baik untuk ditanamkan dalam proses pengembangan, tetapi dimaksudkan lebih untuk menghitung berbagai metrik kode dan mencari kesalahan atau kerentanan yang cukup sederhana. Itu tidak menerapkan analisis interprocedural dari aliran data, sehingga tidak dapat digunakan untuk mencari kerentanan yang kompleks. Biasanya kami merekomendasikan menggunakan SonarQube dan alat SAST yang baik (ini dapat berguna di sini jika alat SAST dapat berintegrasi dengan SonarQube).

Ada analisa statis terbuka yang bagus lainnya. Anda dapat memanggil spotbugs (findbugs) untuk bytecode JVM dengan plugin find-sec-bugs, yang mengimplementasikan analisis dalam proses aliran data dengan seperangkat aturan kecil. Ada penganalisa bandit terkenal untuk Python. Orang tidak bisa tidak menyebutkan analisa statis yang dibangun ke dentang, yang memiliki mesin analisis yang baik dan basis aturan yang baik.

Masalah alat-alat tersebut adalah bahwa mereka biasanya terspesialisasi secara sempit (misalnya, cocok untuk satu bahasa), menerapkan algoritma sederhana (yaitu, mereka tidak memungkinkan menemukan kerentanan yang kompleks), dan memiliki basis aturan yang jauh lebih kecil daripada alat komersial. Selain itu, mereka memiliki serangkaian fungsi yang lebih kecil, baik antarmuka maupun integrasi. Kita bisa menyebutkan kurangnya dukungan.

Di sisi lain, alat SAST komersial yang baik (dan ada juga yang buruk) menerapkan algoritma spesifik yang kompleks dan memiliki basis aturan yang luas yang dapat mencakup ribuan catatan. Biasanya mereka mendukung banyak bahasa pemrograman, memiliki antarmuka yang kaya dan kemampuan integrasi (plugin, API). Di bawah ini saya berikan contoh integrasi seperti apa yang sedang kita bicarakan.

Dan lebih rendah lagi, lihat contoh skema integrasi yang dapat dibangun berdasarkan alat SAST. Secara umum, skema tidak berbeda dari pengenalan cara lain untuk kontrol kualitas kode. Pengembang menulis kode dan dapat segera menjalankan pemeriksaan SAST. Kode masuk ke repositori dan dari sana pada berbagai pemicu menggunakan CI / CD masuk ke SAST. Hasil pemindaian dapat dilihat di antarmuka SAST, atau berakhir di alat yang mendukung proses pengembangan (pelacak bug, surat, dll.).

Alat SAST mana yang harus dipilih?

Saya akan tinggal sedikit pada tahap memilih alat. Ada banyak alat SAST, biasanya beberapa potong disajikan di pasaran (3-4). Muncul pertanyaan, bagaimana memilih alat yang tepat, apa yang harus dicari? Di sini saya tidak akan terkejut, saya akan fokus pada tiga poin: perbandingan fungsional, perbandingan kualitas dan lisensi. Penting untuk mengambil alat pengujian (pilot) di sirkuit lokal Anda dan memeriksa kode Anda di infrastruktur Anda.

Akan menyenangkan untuk mencoba semua fitur antarmuka, untuk memahami bagaimana mereka berlaku untuk kasus Anda dan seberapa mudah mereka untuk digunakan. Saya merujuk ke salah satu artikel sebelumnya . Berikut adalah beberapa fitur yang bermanfaat:

peluncuran pemindaian paling otomatis (idealnya, tanpa pengaturan yang tidak perlu dalam dua tombol, Anda dapat menjalankan pemindaian);
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

Kemampuan integrasi sangat penting - dengan CI / CD, bugtracker, repositori, Direktori Aktif. Akan menyenangkan untuk mencoba mengotomatiskan tindakan sederhana menggunakan API, jika ada.

Untuk memeriksa kualitas Anda perlu memindai kode Anda. Sebaiknya pilih beberapa contoh berbeda dalam bahasa yang berbeda sehingga sampelnya representatif. Dari sudut pandang kualitas, Anda perlu melihat positif palsu (di mana jelas tidak ada kerentanan, tetapi alat menunjukkan) dan kelalaian (idealnya Anda perlu tahu di mana kerentanan berada, baik, atau membandingkan kerentanan yang ditemukan dalam alat yang berbeda). Saya akan sedikit kurang memperhatikan positif palsu, karena biasanya cukup untuk melalui hasil pemindaian sekali, tandai yang salah, dan kemudian mereka tidak akan mengganggu Anda.

Saya akan fokus pada dua poin penting. Pertama-tama, sangat penting untuk melihat semua ini dalam aplikasi untuk situasi Anda. Periksa persis kode Anda (SAST dapat bekerja secara berbeda pada berbagai jenis aplikasi). Cari fitur-fitur yang Anda butuhkan untuk menyematkan alat dalam proses pengembangan. Periksa integrasi dengan sistem yang Anda miliki.

Kedua, sangat penting selama pilot untuk berkomunikasi dengan vendor. SAST bukanlah hal yang paling mudah, dan seringkali cukup untuk mendapatkan saran dari vendor untuk dapat sepenuhnya menghargai kekuatan alat ini.

Kapan Anda mulai memindai?

Semakin cepat kerentanan ditemukan, semakin murah itu. Ada jadwal yang tidak jelas yang berkeliaran dari presentasi ke presentasi, saya bahkan tidak akan menambahkannya di sini. Namun pernyataan itu cukup jelas. Ini adalah satu hal untuk memperbaiki kerentanan sehari setelah dibuat, hal lain adalah membuat perubahan ke server tempur ketika sudah diretas. Oleh karena itu, perlu untuk mentransfer penggunaan SAST ke tahap awal pengembangan. Di sini dapat diperdebatkan bahwa pengenalan SAST dalam pengembangan itu sendiri merupakan peristiwa yang mahal dan mungkin tidak membuahkan hasil. Di sini saya akan berdebat: biasanya menemukan beberapa kerentanan kritis mencakup seluruh implementasi (Anda bahkan dapat melakukan penilaian dalam pilot).

Dengan pendekatan ini, kami juga mendapatkan bonus: pengembang, ketika mereka melihat hasil SAST "setiap hari", kemajuan dalam pengetahuan pemrograman yang aman, dengan demikian, secara umum, budaya pengembangan yang aman ditingkatkan dan kode menjadi lebih baik.

Tentu saja, ketika menerapkan SAST dalam proses pengembangan, perlu untuk mengimplementasikan dalam CI / CD, membangun DevSecOps. Tren mentransfer SAST dari cek kontrol sebelum dirilis ke proses pengembangan telah terlihat sejak lama, dan dalam 2-3 tahun terakhir ini telah menyusul pasar kami. Sekarang tidak ada pilot yang lulus tanpa menguji kemampuan integrasi.

Pada saat yang sama, saya akan meninggalkan kontrol sebelum rilis, idealnya, untuk rakitan biner (ini juga mungkin). Jadi, Anda dapat memastikan bahwa tidak ada kerentanan baru yang ditambahkan selama perakitan dan transfer aplikasi ke produk.

Masalah teknis

Dan kemudian saya akan membawa 4 pertanyaan segera.

Hubungkan SAST sebagai SonarQube, apa kesulitannya?
SAST bekerja untuk waktu yang lama, cara mengkonfigurasi DevSecOps?
SAST memberikan false positive, bagaimana cara mengkonfigurasi Quality Gate?
Dan tanpa positif palsu dalam laporan itu, beberapa ribu kerentanan, apa yang harus dilakukan dengan mereka?

Ini adalah masalah teknis utama yang muncul saat menerapkan SAST. Mereka muncul karena alasan berikut.

Karena sifat algoritmanya yang eksponensial, SAST dapat berjalan untuk waktu yang lama dan menghabiskan banyak sumber daya - lebih dari sekadar linter atau SonarQube.
Untuk alasan yang sama, SAST dapat memberikan banyak kesalahan positif - tidak mungkin pengembang ingin mengurai banyak jatuh setiap hari setelah pemindaian berikutnya.
Biasanya, SAST diluncurkan pada basis kode untuk pertama kalinya, dan jalankan pertama dapat menunjukkan banyak operasi, terutama jika ada banyak kode dan database tidak terlalu baru.

Semua masalah terpecahkan. Dalam artikel berikutnya dalam seri ini, kita akan memeriksa, menggunakan contoh nyata dari pengalaman kami, bagaimana menerapkan SAST sedemikian rupa untuk meratakan semua fitur teknisnya dan untuk membuat semua orang bahagia.

Masalah organisasi

Saya tidak akan melupakan masalah organisasi. Di perusahaan besar, banyak dari mereka muncul, dari proses implementasi itu sendiri, alokasi sumber daya untuk pembuatan peraturan dan replikasi proses.

Masalah organisasi dihasilkan oleh fitur teknis yang sama yang kami bahas pada paragraf sebelumnya. Selain itu, pembagian dan konfrontasi yang mapan secara historis antara pembangunan dan keamanan belum hilang. Saya juga merujuk ke artikel kami sebelumnya.

Bersambung

Terapkan SAST - perlu, biasanya dibenarkan. Tapi, mulai menerapkan, alangkah baiknya untuk berkenalan dengan semua jebakan yang muncul di jalan Anda. Pada artikel ini, kami mulai membongkar mereka, kami akan melanjutkan dengan aspek teknis berikut ini.

(S) SDLC, atau Cara membuat pengembangan lebih aman. Bagian 1