Berhentilah menendang hutang jaminan di ujung jalan
image source: freepik

Berhentilah menendang hutang jaminan di ujung jalan

Kurangi pengenalan cacat di SDLC dan kurangi hutang keamanan

Hidup di dunia yang penuh dengan ancaman dunia maya, peraturan kepatuhan yang sedang berlangsung, dan pelanggaran data (buka di tab baru) yang sering terjadi dapat menjadi hal yang menakutkan bagi organisasi mana pun. Hal ini dapat menjadi lebih menakutkan karena banyak organisasi berjuang untuk mengatasi hutang keamanan (terbuka di tab baru) secara memadai – biaya keterlambatan pekerjaan yang diperlukan untuk mengatasi kerentanan yang ada dalam perangkat lunak, sistem, atau aplikasi (terbuka di tab baru).

Untuk laporan tahunan Keamanan Perangkat Lunak 2023 kami, kami mengolah data selama lima belas tahun untuk lebih memahami mengapa pengenalan cacat terjadi selama siklus hidup aplikasi dan apa yang dapat dilakukan untuk mencegah atau memperlambat akumulasi hutang keamanan. Hasil studi ini akan membantu DevOps (buka di tab baru) dan tim keamanan aplikasi mengurangi risiko secara efisien sambil terus mempertajam praktik mereka.

Mengapa kekurangan menumpuk

Aplikasi rata-rata tumbuh sekitar empat puluh persen per tahun selama lima tahun pertama, terlepas dari ukuran aslinya. Menariknya, korelasi antara pertumbuhan aplikasi dan pengenalan cacat cukup kompleks, dan tidak ada korelasi langsung antara peningkatan ukuran aplikasi dan pengenalan cacat. Sementara itu, akumulasi cacat terus menumpuk hingga tanda sepuluh tahun dan seterusnya. Perlu juga dicatat bahwa ada kemungkinan 90 persen bahwa sebuah aplikasi memiliki setidaknya satu cacat pada saat berumur sepuluh tahun.

Tidak seperti ukuran aplikasi, kami tahu bahwa ada korelasi antara pengenalan cacat dan usia aplikasi. Seperti yang terlihat dalam laporan di atas, hampir sepertiga aplikasi memasuki tahap produksi dengan kelemahan keamanan. Persentase aplikasi dengan kelemahan baru turun tak lama setelah pemindaian keamanan awal sebelum mulai naik lagi sekitar satu setengah tahun, membentuk “fase bulan madu” ketika lebih sedikit kelemahan baru diperkenalkan. Setelah titik satu setengah tahun ini, pengenalan cacat kemudian terus menanjak lagi hingga tahun kelima.

Faktor apa yang mencegah akumulasi hutang keamanan

Pengenalan dan akumulasi kelemahan, dan dengan demikian utang jaminan, dipengaruhi oleh frekuensi pemindaian, jenis pemindaian, dan pendidikan pengembang. Pemeriksaan kami menunjukkan kepada kami bahwa, pada bulan tertentu, ada kemungkinan 27 persen bahwa aplikasi akan memperkenalkan satu atau lebih kelemahan baru setiap bulan. Itu juga menunjukkan kepada kita bahwa peluang 27 persen ini dapat dipengaruhi oleh faktor-faktor tertentu.

Secara khusus, frekuensi pemindaian dapat membuat peluang 27 persen bertambah atau berkurang tergantung pada irama. Misalnya, jika sebuah aplikasi telah dipindai pada bulan sebelumnya, kemungkinannya 0,4 persen lebih kecil untuk memperkenalkan satu atau lebih kelemahan bulan ini. Di sisi lain, untuk penundaan pemindaian setiap bulan, kemungkinan pengenalan cacat meningkat sebesar 1,3 persen, yang menumpuk dengan cepat. Pada enam bulan sejak pemindaian terakhir, kemungkinan munculnya cacat adalah +7,8 persen.

Selain itu, pemindaian aplikasi secara otomatis melalui Application Programming Interface (API) mengurangi kemungkinan munculnya cacat pada bulan tertentu sebesar dua persen. Pendidikan pengembang juga berperan besar dalam mencegah akumulasi utang jaminan; mereka yang menyelesaikan 10 sesi pelatihan keamanan aplikasi langsung dalam alat pelatihan pengembang imersif menggunakan kerentanan dunia nyata melihat pengurangan kemungkinan munculnya kelemahan keamanan saat mereka membuat kode sebesar 1,8 persen pada bulan tertentu.

Bagaimana perpustakaan sumber terbuka memasukkan gambar

Log4j berfungsi sebagai peringatan untuk risiko membangun aplikasi menggunakan pustaka sumber terbuka (terbuka di tab baru) yang berada di luar kendali pengembang. Itu juga merupakan peringatan tentang bagaimana membiarkan utang jaminan tidak terselesaikan dapat membuat masalah mendesak membutuhkan waktu yang sangat lama untuk diperbaiki. Mencoba menambal satu perpustakaan dapat menyebabkan yang lain rusak dan seterusnya.

Menentukan apakah pustaka open source aman digunakan atau tidak adalah masalah kompleks yang bergantung pada beberapa pertimbangan, termasuk repositori open source dan pemiliknya, frekuensi kontribusi, dan faktor tak berwujud lainnya. Dalam memeriksa hampir 30.000 repositori yang secara aktif digunakan dalam kode produksi, kami menemukan bahwa lima puluh persen tidak memiliki komitmen—perubahan pada kode sumber—pada tahun lalu, dan sepuluh persen tidak memilikinya selama hampir enam tahun. Separuh dari repositori yang dipindai memiliki lebih dari sepuluh kontributor, dan sepuluh persen memiliki lebih dari 72 pengembang. Data ini menunjukkan kepada kita bahwa masih banyak yang perlu kita pelajari tentang ekosistem open source untuk memenuhi syarat praktik terbaik. Apa yang kami ketahui adalah bahwa mengotomatiskan keamanan ke dalam proses pembangunan ketika datang ke kode sumber terbuka, khususnya Analisis Komposisi Perangkat Lunak (SCA) yang memanfaatkan banyak sumber untuk kekurangan, akan membuat penanganan Log4j berikutnya jauh lebih mudah dikelola.

Kesimpulan

Mengatasi hutang keamanan dan mengurangi risiko lebih mudah ketika pengembang dan tim keamanan diberdayakan untuk mengatasi kelemahan lebih awal dan sering kali menggunakan berbagai alat dan teknik. Bisnis harus memprioritaskan pelatihan keamanan untuk memberikan pemahaman tentang kerentanan mana yang paling mungkin diperkenalkan, serta cara untuk mencegah munculnya kelemahan sama sekali. Selain itu, menetapkan protokol untuk manajemen siklus hidup aplikasi yang menggabungkan transformasi, alokasi sumber daya, dan kontrol organisasi memungkinkan peninjauan terus-menerus terhadap tindakan yang terlibat dalam rekayasa produk berkelanjutan.

Aplikasi adalah hasil dari ribuan jam kerja dan dapat mewakili kesuksesan dan reputasi perusahaan. Melindungi keamanan aplikasi itu terlalu penting untuk diserahkan pada tindakan pasif. Alih-alih, dengan memanfaatkan teknologi yang tepat dan praktik DevSecOps, pengembang dapat mendedikasikan lebih banyak waktu untuk melakukan apa yang mereka sukai–membangun perangkat lunak daripada mengejar kelemahan.

Leave a Reply

Your email address will not be published. Required fields are marked *