Bumiayu.id – Selama dekade terakhir migrasi cloud, model ancaman terhadap aplikasi Java dan cara yang kita butuhkan untuk mempertahankannya telah berubah.
Open JDK telah membuat satu perubahan positif di area ini dengan tidak lagi menggunakan SecurityManager lama , peninggalan yang melindungi CD dan peta kertas AOL di masa lalu.
Perubahan positif berikutnya dalam keamanan adalah memperkuat rantai pasokan komponen perangkat lunak, mengetahui apa yang berjalan dan apa yang rentan, dan mengomunikasikan informasi ini dengan pakar non-teknis yang datanya berisiko.
Bagian dari model ancaman ini didorong oleh pustaka yang rentan seperti Log4j tahun lalu . Meskipun Log4j adalah pustaka logging yang bagus dan aktif dalam patching, banyak tim yang bergegas untuk mengidentifikasi di mana mereka perlu menerapkan patch tersebut.
Untuk pengembang atau tim Java individu yang mengetahui kode mereka dan dapat menerapkannya, tambalannya sederhana — Anda memperbarui perpustakaan dan hanya itu. Kenyataannya adalah bahwa perangkat lunak bergerak cepat dan jauh, seringkali meninggalkan pusat kendali para ahli teknis ini kepada pemangku kepentingan yang tidak memiliki keahlian untuk mengelola masalah pada tingkat ini.
Dalam perebutan, tim yang tidak tahu Java-spesifik mencari di mana-mana termasuk perangkat lunak .NET dan forum Python . Pemerintah Quebec menutup layanansampai mereka tahu di mana Log4j tidak berada. Pengacakan ini tidak efektif dan tidak melindungi data kami.
Bagian utama dari model ancaman aplikasi Java sekarang melibatkan kemampuan untuk melacak komponen dan memahami di mana aplikasi kita mengandung komponen yang diketahui rentan seperti Log4j.
Apa itu Rantai Pasokan Aplikasi Java Umum?
Cara sederhana untuk melihat rantai pasokan adalah bahwa sebagian besar peserta adalah produsen dan/atau konsumen. Arsitek perusahaan mungkin sudah akrab dengan analogi ini, karena rantai pasokan bergerak seperti antrian dan dengan demikian dapat menggunakan terminologi serupa. Contoh rantai pasokan ini meliputi:
Repositori seperti Maven Central adalah produsen file JAR. Mereka menyediakan komponen ini untuk pengembang atau membangun sistem, yang merupakan konsumen dari file JAR ini.
Pengembang menggunakan file JAR dan menghasilkan kode baru yang menyatukan aplikasi. Beberapa pengembang menghasilkan perpustakaan yang dikirim kembali ke Maven Central, yang merupakan konsumen.
Lingkungan build menggunakan kode kustom pengembang dan pustaka repo untuk menghasilkan aplikasi, wadah, atau bundel lainnya. Ketika aplikasi disebarkan ke lingkungan atau dikirim ke pelanggan, ini biasanya mengakhiri rantai pasokan.
Untuk perangkat lunak COTS yang dibeli, vendor adalah produsen dan operator umumnya adalah konsumen. Secara internal vendor memiliki rantai pasokan sendiri tentang bagaimana mereka membuat perangkat lunak.
Tujuan utamanya adalah memindahkan aplikasi ke produksi dan menjalankannya — lingkungan produksi ini hanya untuk konsumen karena tidak menghasilkan artefak baru (dalam siklus DevOps, keluaran produksi adalah umpan balik).
Tingkatkan Kontrol Keamanan Anda Dengan Mempercepat Java
Ketika JVM melakukan pekerjaan untuk melacak komponen, manfaat utama adalah kemampuan untuk mendeteksi semua beban kerja yang berjalan di JVM, bukan hanya beban kerja yang digunakan oleh kontrol keamanan.
Tim yang saat ini menggunakan pendekatan lain untuk komponen inventaris harus terus melakukannya dengan tujuan untuk proses pertahanan yang mendalam di mana setiap kontrol bekerja sama untuk menangkap sesuatu yang mungkin terlewatkan oleh yang lain.
Dengan bekerja pada kecepatan produksi, teknologi yang lebih baru seperti Azul Vulnerability Detection “bergeser ke kanan” untuk menawarkan verifikasi kecepatan produksi item yang mungkin terlewatkan, atau untuk menghemat pekerjaan pada integrasi dan pemindaian setiap bagian dari perangkat lunak Java di mana saja.
