Mindset “asal jadi” jadi risiko dalam organisasi, melepaskan tanggung jawab, dan membuat biaya tidak terduga dimasa depan. Apalagi AI memperkeruh mindset ini. Blog ini membahas bagaimana idealnya organisasi dapat berjalan terus-menerus dan tumbuh lewat mindset install library.
Faktanya rata-rata lebih dari 100 dependencies di ekosistem NPM. Sulit untuk monitor dan menjaga software dari banyaknya dependency yang diinstall. PyCon AU menjelaskan dengan detail, tidak hanya risiko tetapi juga solusi dari masalah ketergantungan.
Library Open Source sangat berguna untuk aplikasi untuk mempercepat development. NPM contohnya memudahkan proses instalasi, dan siapapun bisa membuat library open-source.
Berbagai library mungkin menggunakan library yang sama, tapi dengan versi yang berbeda. Ini tanggung jawab si-pembuat aplikasi untuk memilih versi library yang tepat, biasanya sudah diatur otomatis (Resolution) oleh npm, yarn atau pnpm.
Resiko terjadi supply-chain attack tidak dapat dipungkiri, pemilik software harus analisa dan menggunakan library dengan seksama. Memahami apa yang dipasang (install) penting untuk keamanan aplikasi.
Review library, anak-anak library, siapa berelasi ke siapa, sulit dibuat manual. Maka dibuat standard Dokumen SBOM untuk mengumpulkan komponen/library apa saja yang diinstall, relasi antar library, versi, hingga Hash library yang dipakai. Biasanya SBOM dipakai oleh perusahaan atau para auditor untuk memahami tingkat keamanan aplikasi.
Ketika terjadi supply-chain attack, dapat dilihat apa saja yang terdampak dari dokumen SBOM dan bagaimana mitigasinya. Tujuan SBOM adalah untuk mengatasi risiko, mempercepat proses discovery, recovery, perbaikan dan patching.
Analisa relasi library dapat dilakukan bahkan sebelum aplikasi dibuat, website deps.dev dapat melihat relasi antar library, security advisor, hingga komparasi antar versi.
Alur berpikir untuk install library apapun adalah, lisensi apa yang dipakai?, relasi ke library apa saja?, kapan terakhir kali update?, seberapa sering update?, apakah ada masalah keamanan?, apakah open source?, apakah yakin ingin install sebanyak ini?.
Pertanyaan-pertanyaan banyak ini jadi beban hanya untuk install library. Apakah layak install library untuk masalah kecil? melatih Mindset ke-hati-hati-an dalam pengembangan, lebih baik copy-paste kode dan jadikan beban library kepada pembuat aplikasi, bukan pada pembuat library. Fitur fork di git repository memudahkan debugging library yang besar.
Selain itu, manajemen dependensi juga dapat digunakan pada projek legacy. analisa dan audit perlu dilakukan untuk manajemen resiko. Projek legacy pasti memiliki celah dimana-mana karena beban manajemen yang berat, dan sering diabaikan saja. Tetapi, memahami risiko lebih penting daripada mengabaikan sepenuhnya. Jika diabaikan, kita tidak punya pemahaman jika risiko terjadi, tetapi jika memahami risiko dapat dikontrol dan antisipasi dimasa depan. Mengabaikan risiko malah akan membuat biaya lebih mahal dimasa depan, pemahaman risiko bisa membuat keputusan lebih baik dan biaya lebih efisien.
Dalam manajemen software, manajemen risiko jadi bagian krusial bagi perusahaan manapun yang menggunakan software. Data digital sama pentingnya dengan data fisik, bahkan lebih bermakna. Sebagai developer, mindset ke-hati-hati-an perlu jadi tanggung jawab masing-masing.
Saran dari AI saat ini dipengaruhi banyak oleh data masa lalu. Konten React lebih banyak dibanding lainnya, AI akan lebih besar kemungkinan untuk menyarankan kode React dibanding library lainnya. Saran library akan sangat bias tanpa analisa kondisi library masa kini, mungkin saja penuh dengan CVE tanpa, atau mati ditinggalkan oleh developer.
Dunia penuh dengan AI akan lebih mudah menerima saran dari AI tanpa review yang mendalam—karena terlihat cepat dan instan. Celah keamanan jadi lebih besar. Metode review yang berubah dan menjadi ketergantungan dengan AI. Pada akhirnya developer si-penulis kode bertanggung-jawab atas aplikasi yang dibuatnya, bukan AI.
Add a comment