Ini adalah episode ketiga dalam sebuah serangkaian artikel tentang jenis serangan rantai pasokan perangkat lunak yang paling umum: serangan yang menyalahgunakan registri publik dari open-source komponen perangkat lunak. Setelah menganalisis di episode sebelumnya “Anatomi Paket Berbahaya: Apa Saja Trennya?“Mengetahui bagaimana pelaku kejahatan menyuntikkan perilaku berbahaya ke dalam komponen yang baru atau yang sudah ada yang telah dipublikasikan, kami siap mengenakan jaket pemadam kebakaran dan memeriksa bagaimana kami dapat berhasil memblokir perangkat lunak berbahaya yang dikirimkan dengan cara ini, atau sebaliknya, menangani insiden siber yang berpotensi serius karena kami mengambil pendekatan yang salah.”
Sebagian besar profesional yang sadar akan keamanan memiliki gagasan tentang cara menangani ancaman ini. Kami telah mendengar para manajer keamanan mengatakan tanpa ragu bahwa SCA Alat-alat tersebut sudah memberi tahu Anda kapan suatu versi paket adalah malware. Atau bahwa paket tersebut bergantung pada komponen perangkat lunak yang terkenal dan memiliki ulasan yang baik, di mana malware apa pun akan segera terdeteksi dan dihapus. Mereka menggunakan versi minor/patch terbuka untuk mendapatkan perbaikan kerentanan secara otomatis, dan itu adalah cara yang tepat dan direkomendasikan untuk menurunkan risiko pada ketergantungan sumber terbuka, mengikuti prinsip “Lakukan pembaruan sedini mungkin, lakukan pembaruan sesering mungkin." prinsip.
Dalam episode ini, kita akan meninjau mengapa gagasan-gagasan ini salah, dan bagaimana kesalahpahaman tersebut berkontribusi pada popularitas mekanisme serangan ini, dan pada risiko luar biasa yang dialami organisasi. Kita akan mengakhiri dengan apa yang berhasil, serta upaya dan sumber daya yang dibutuhkan.
Kesalahpahaman Umum
Selama perjalanan kami di bidang keamanan perangkat lunak, kami melihat teknik serangan terus berkembang dan berbagai macam ide dari orang-orang yang sadar akan keamanan. Organisasi sering kali salah paham tentang apa yang efektif melawan ancaman ini, jadi pertama-tama kita akan meneliti apa yang tidak efektif, yang diringkas dalam daftar kesalahpahaman berikut ini (daftar ini tidak lengkap).
Kesalahpahaman #1: SCA Alat-alat tersebut sudah melaporkan komponen berbahaya.
Memang! Namun setelah kejadian itu… Ketika mungkin sudah terlambat jika elemen tersebut digunakan dalam pembuatan perangkat lunak, dan pelaku kejahatan telah mendapatkan pijakan di dalam sistem pengembang atau CI/CD host. Rahasia mungkin telah dibocorkan, malware tambahan diunduh dan diinstal, dan mungkin musuh bergerak secara lateral dan telah memperoleh akses di tempat lain.
Analisis Komposisi Perangkat Lunak (SCAAlat-alat (atau perangkat lunak) dirancang untuk mengidentifikasi potensi kerentanan yang diketahui. Alat-alat modern bekerja dengan baik dengan meningkatkan rasio sinyal-kebisingan, menentukan apakah kerentanan tersebut benar-benar dapat dijangkau atau dieksploitasi. Tetapi alat-alat tersebut tidak berguna melawan malware baru. Anggaplah komponen berbahaya sebagai kerentanan zero-day: Hanya ketika perilaku berbahayanya terdeteksi, komponen tersebut dilaporkan ke registri penampung, yang setelah ditinjau oleh tim keamanan dikonfirmasi sebagai berbahaya dan dihapus dari registri. [1].
Pada saat itu, dunia (termasuk SCAs) mengetahui bahwa menginstal atau menggunakan komponen (atau beberapa versi dari komponen yang sudah ada) bukanlah hal yang baik. Namun, ini terjadi ketika komponen tersebut tidak tersedia dari registri.Mengetahui bahwa saya memiliki kerentanan pada komponen pihak ketiga, atau bahkan komponen yang dikategorikan sebagai berbahaya oleh registri, memang bagus, tetapi sayangnya... SCA atau alat audit umum tidak membantu dalam konteks ini. Kecuali jika SCAAlat audit dapat mengetahui terlebih dahulu bahwa suatu komponen bersifat berbahaya sebelum digunakan di organisasi Anda..
Ingat, solusi apa pun untuk melawan komponen sumber terbuka yang berbahaya harus dapat mendeteksinya. dengan cepat, antara saat komponen dipublikasikan di registri dan saat komponen (versi) pertama kali digunakan di organisasi Anda. Dan itu termasuk komponen transisi.
Kesalahpahaman #2: Mengontrol skrip instalasi pada saat pembuatan mencegah perilaku berbahaya dari komponen sumber terbuka
Berbagai pengelola paket menawarkan kemampuan untuk menjalankan skrip (termasuk dalam tarball komponen). [2]), untuk alasan yang sah, seperti mengkompilasi item yang dibutuhkan pada platform yang berbeda, menghasilkan kode, atau menjalankan pengujian, dan kita semua harus tahu bahwa hal itu dapat disalahgunakan oleh pihak yang tidak bertanggung jawab jika skrip berbahaya disertakan dalam tarball, atau jika penyerang dapat menjalankan skrip berbahaya sebagai pengganti skrip yang baik.
Dengan mengetahui hal ini, kita dapat mengkonfigurasi pengelola paket untuk mengabaikan skrip. Misalnya, dengan NPM, –Abaikan-skrip bendera (atau properti konfigurasi di .npmrc file) melewati skrip selama instalasi. Ini dapat menimbulkan beberapa masalah karena menjalankan skrip adalah hal umum di banyak ekosistem: Beberapa pengelola paket bahkan tidak mengizinkan penonaktifan eksekusi skrip (petunjuk: prompt “Manajer paket mana yang tidak mengizinkan penonaktifan eksekusi skrip instalasi?” di AI favorit Anda). Tetapi ini tidak memberikan perlindungan secara umum (kita perlu memastikan bahwa konfigurasi penonaktifan lewati ada di mana-mana).
Dan ketika perilaku berbahaya tersebut tidak terdapat pada skrip instalasi tetapi pada perangkat lunak yang dijalankan saat runtime, opsi ini saja tidak melindungi kita.
Kesalahpahaman #3: Pembatasan versi mencegah pemasangan komponen berbahaya
Ada pertimbangan antara melakukan patching sedini dan sesering mungkin dengan versi terbuka (membiarkan pengelola paket menginstal pembaruan baru secara otomatis saat tersedia untuk perbaikan keamanan) dan penyematan versi (memiliki semua ketergantungan langsung dan transisi untuk perangkat lunak pada versi tetap). Prinsip-prinsip keamanan itu keras kepala dan terkadang kontradiktif, seperti yang terjadi dengan "tambal sedini mungkin, tambal sesering mungkin" dan “Peningkatan kualitas tidak boleh dianggap enteng”Beberapa pengelola paket menjadikan pembaruan otomatis dengan rentang server sebagai cara yang direkomendasikan. Bagus jika Anda juga ingin menerima pembaruan berbahaya! Ya, komponen harus diperbarui untuk menerima perbaikan keamanan yang menutup kerentanan sesegera mungkin, tetapi… jangan pernah membiarkan pengelola paket melakukan ini secara otomatis.
Kesalahpahaman #4: Menggunakan komponen tepercaya itu aman. Versi berbahaya apa pun akan segera ditemukan, diungkapkan, dan dihapus.
Mengapa suatu komponen dipercaya? Mungkin karena komponen tersebut sangat populer, dengan banyak orang yang mencari kerentanan, sejumlah besar kontributor untuk pemeliharaan, dan beberapa pengelola inti yang dengan tekun meninjau semuanya. pull requestsKenyataannya sangat berbeda. Beberapa komponen penting dikelola oleh satu pengembang yang tidak dibayar. Kerangka kerja yang banyak digunakan memiliki beberapa kontributor tetap, dengan jumlah yang menurun dengan cepat commits per pengelola (proyek populer memiliki banyak kontributor yang melakukan kontribusi secara asal-asalan) commit dan tidak pernah kembali). Dan proyek-proyek populer dengan satu pengelola saja sangat banyak.
Bayangkan Anda berkata “Oh, kami menggunakan Spring Boot / Angular / React / PyTorch / image Docker resmi, jadi risiko yang Anda bicarakan cukup rendah.” Mungkin memang benar, kami para vendor keamanan selalu menakut-nakuti, dan ikut campur dengan tim pengembang untuk mengurangi risiko yang masih diperdebatkan adalah hal yang tidak masuk akal. Anda mungkin tergoda untuk langsung menuju paragraf penerimaan risiko (di bagian selanjutnya) dan selesai. Sayangnya, komponen yang paling populer menjadi target para pelaku kejahatan, dan misalnya, yang populer Pustaka PyTorch diserang. di masa lalu.
“Segera ditemukan, diungkapkan, dan disingkirkan”. Dibutuhkan waktu berhari-hari untuk menghapus komponen berbahaya baru dari registri publik. Registri berhati-hati dalam menghapus versi komponen, demi kebaikan. Pengalaman kami menunjukkan bahwa setelah dilaporkan dari pihak kami, waktu rata-rata bagi registri untuk menghapus versi yang terpengaruh adalah 39 jam, lebih dari satu setengah hari. Ada komponen berbahaya yang masih ada di registri seminggu setelah pelaporan awal kami sebelum dihapus. Dan dalam beberapa kasus, komponen tersebut baru dihapus setelah korban atau perusahaan penanggulangan insiden melaporkan insiden yang melibatkan komponen tersebut.
Apa yang TIDAK Berhasil Melawan Komponen Berbahaya
Pendekatan yang tidak spesifik akan gagal total. Ini sudah pasti, Anda tidak memberikan tindakan penanggulangan yang efektif terhadap risiko yang terkait dengan ancaman ini.
Tradisional SCA Alat-alat tersebut memberi tahu Anda tentang malware yang dikenal tetapi memiliki jendela paparan yang besar. Kecuali jika mereka secara proaktif melakukan deteksi malware dengan pemblokiran komponen berbahaya yang diberlakukan, mereka tidak efektif melawan ancaman ini.
Menonaktifkan skrip instalasi dapat membantu, tetapi perlu diterapkan di mana pun komponen perlu diinstal. Sama halnya dengan penguncian versi, karena versi tidak dapat dipertahankan dari keadaan awal yang aman selamanya.
Menganggap bahwa komponen populer mendapatkan cukup perhatian sehingga tidak dapat disuntikkan perilaku yang tidak diinginkan dalam serangan rantai pasokan tanpa deteksi yang hampir instan untuk mencegah kerusakan apa pun adalah hal yang naif dan berisiko. Anda tidak ingin hidup di ujung tanduk, bukan?
Jika Anda berhenti di titik ini, maka penerimaan risiko Ini satu-satunya hal yang bisa kamu lakukan: Ini adalah sebuah decisInformasi yang perlu didokumentasikan dalam model ancaman/penilaian risiko Anda, termasuk alasan untuk menerima risiko tersebut dan implikasi potensialnya. Tingkatkan kesadaran dengan mengkomunikasikannya kepada manajemen dan pihak-pihak terkait lainnya. Beberapa kemungkinan Serangan dapat direncanakan ketika komponen berbahaya dipasang atau disertakan dalam perangkat lunak Anda, tetapi ini sulit karena penyerang memiliki banyak jalur untuk diikuti. Detail serangan rantai pasokan berdasarkan penggunaan komponen berbahaya akan secara drastis mengubah pengungkapan publik atas insiden tersebut, yang mungkin wajib dilakukan berdasarkan kerangka peraturan organisasi Anda. Anda juga dapat membahas hal ini. kontrol kompensasi or risiko transfer misalnya dengan asuransi.
Namun, ada langkah-langkah pengendalian yang dapat mengatasi ancaman tersebut dan perlu dipertimbangkan jika Anda tidak puas dengan penerimaan risiko. Silakan baca selanjutnya.
Apa yang Efektif Melawan Serangan yang Menggunakan Komponen Berbahaya?
Penanganan Versi Solid
Penguncian versi dengan peningkatan versi yang terkontrol dan berdasarkan informasi adalah cara yang tepat untuk menyeimbangkan kebutuhan penghapusan kerentanan tanpa menerima malware. Tetapi ingat kesalahpahaman #3: Penguncian versi saja tidak cukup untuk memblokir kode berbahaya yang berasal dari versi baru, karena di masa mendatang Anda perlu memperbarui versi pada setiap ketergantungan langsung atau tidak langsung. Pada saat itu, Anda membutuhkan bukti yang cukup kuat bahwa semua versi yang dimodifikasi tidak mengandung malware.
Peringatan Dini
Salah satu pendekatan untuk mengatasi masalah komponen berbahaya adalah sistem peringatan dini (disebut di sini sebagai Peringatan Dini Malware atau MEW), di mana versi baru yang diterbitkan (untuk komponen baru atau yang sudah ada) dianalisis oleh mesin pendeteksi, yang jika ditemukan cukup bukti dapat mengklasifikasikan versi baru tersebut sebagai berpotensi berbahaya.
Otomatisasi sangat penting di sini, karena tidak mungkin untuk meninjau semua komponen baru secara manual dengan laju penerbitan saat ini. Oleh karena itu, mesin pendeteksi perlu menggabungkan berbagai teknik, mungkin termasuk analisis statis, dinamis, dan kemampuan, reputasi pengguna, dan bukti yang berasal dari perbedaan antara metadata komponen dan isi tarball, atau antara tarball dan repositori sumber tempat komponen tersebut seharusnya berasal.
Ada zona gelap Jeda waktu antara saat publikasi dan saat mesin menganalisis isi komponen, tetapi seharusnya tidak melebihi beberapa menit. Skema ini dapat dimodifikasi, misalnya dengan menunggu komponen baru dianalisis sebelum mengizinkannya diinstal dan digunakan dalam pembuatan perangkat lunak. pipelineatau menganalisisnya sesuai permintaan bila diperlukan. Komponen pada versi tertentu bersifat tetap (immutable). [3], jadi hanya perlu dianalisis sekali saja.
Otomatisasi penuh tidak mungkin dilakukan, dan diperlukan tinjauan keamanan untuk komponen yang berpotensi berbahaya. Waspadalah terhadap para pendukung solusi digital yang mujarab.AI dan Machine Learning belum cukup berkembang untuk mengambil keputusan akhir dalam hal mengkonfirmasi apakah suatu komponen yang dicurigai mengandung malware. Tentu, machine learning memainkan peran kunci dalam mesin deteksi untuk mengklasifikasikan komponen input dari bukti mentah yang ditangkap, tetapi setelah komponen tersebut "dikarantina", keputusan akhir ada pada tinjauan manual oleh tim keamanan yang berpengalaman dalam komponen berbahaya. Ini akan mengkonfirmasi potensi malware atau mengklasifikasikannya kembali sebagai aman. Dan jangka waktunya berkisar beberapa jam.
Registry melaporkan versi/komponen berbahaya; registry kemudian melakukan peninjauan untuk mengkonfirmasi dan melanjutkan ke pengungkapan publik dan penghapusan dari registry. Beberapa registry menyimpan paket penyimpanan keamanan. Rentang waktu di sini adalah hari atau minggu sejak publikasi, yaitu 'waktu tinggal' atau 'jendela paparan' untuk sebagian besar komponen berbahaya.
Apakah mungkin untuk mengetahui apakah suatu versi komponen bersifat berbahaya?
Jadi untuk peringatan dini, kita perlu memberikan jawaban yang memuaskan untuk pertanyaan ini: Bagaimana saya bisa tahu bahwa sebuah pustaka atau paket (bukan) berbahaya? Bagaimana cara mengumpulkan cukup bukti perilaku berbahaya? Mungkin, tetapi sulit, karena para penyerang menggunakan banyak kecerdikan untuk menghindari deteksi. Ada berbagai pendekatan, masing-masing dengan kelebihan dan kekurangannya.
Analisis statis dapat memeriksa semua jalur eksekusi, memeriksa teknik yang digunakan oleh penyerang tanpa menjalankan komponen, dan melakukan tugas pra-pemrosesan seperti de-obfuscation atau dekripsi. Karena penyerang mencoba menyembunyikan kejahatan mereka, upaya obfuscation memang merupakan bukti adanya malware (tetapi perlu dicatat bahwa komponen yang sah melakukan obfuscation kode untuk melindungi kekayaan intelektual, yang bertentangan dengan “open sourceHanya sebagian kecil serangan yang sangat canggih dengan pengaburan yang kuat yang membutuhkan sandboxing, tetapi pengaburan yang kuat seperti itu merupakan tanda yang jelas dari niat jahat. Harap dicatat bahwa konvensional SAST Alat-alat tersebut dirancang untuk kerentanan yang tidak disengaja, bukan untuk tujuan jahat seperti pintu belakang (backdoor).
Analisis dinamis Menjalankan komponen dan memeriksa respons dengan menginstrumentasi runtime, biasanya dengan menyediakan lingkungan sandbox. Perilaku berbahaya yang dipicu dalam kondisi tertentu mungkin tidak terdeteksi: harap dicatat bahwa malware dapat menggunakan teknik penghindaran seperti Virtualisasi/Penghindaran Kotak Pasir hanya aktif ketika tidak dalam pengawasan, dan juga merupakan tanda yang jelas dari aktivitas berbahaya bagi mesin analisis statis mana pun.
Analisis kemampuan Pendekatan ini mempertimbangkan apa yang dilakukan komponen tersebut: ke mana ia terhubung, file mana yang diaksesnya, perintah atau program apa yang dijalankan, I/O terminal atau perangkat yang dilakukan, atau panggilan sistem mana yang dipanggil. Pengenalan perilaku ini dapat dibandingkan (untuk komponen yang sudah ada) di berbagai versi, sehingga ketika perilaku yang tidak terduga terdeteksi, bukti tersebut dapat menimbulkan kecurigaan terhadap potensi aktivitas berbahaya yang disuntikkan dalam versi baru. Pendekatan ini mengikuti langkah-langkah triase yang dilakukan analis keamanan ketika dihadapkan dengan potensi malware: inspeksi menggunakan... string atau alat serupa. Pendekatan ini mendeteksi perilaku berbahaya tanpa memandang kondisi pemicu dan berfungsi meskipun tidak ada kode sumber yang tersedia.
Analisis konteks Mengumpulkan informasi tentang bagaimana komponen tersebut dipublikasikan dan oleh siapa. Kampanye pelaku jahat sering menggunakan akun pengguna baru yang tidak melalui proses verifikasi ketat. Melacak aktivitas masa lalu dapat memberikan wawasan tentang pengguna yang mendasarinya, terutama untuk anomali yang mungkin mengindikasikan potensi pelanggaran keamanan. Reputasi sangat sulit diperoleh dan sangat mudah hilang! Pengguna tanpa aktivitas masa lalu bersifat netral, tetapi karma akan mengejar orang jahat. Aktivis peretas, atau pengguna biasa yang kredensial publikasinya dicuri, harus dilacak dengan cermat.
Informasi kontekstual lainnya adalah setiap perbedaan antara repositori sumber yang seharusnya digunakan untuk membuat tarball komponen dan isi tarball itu sendiri. Dan juga mengikuti praktik yang baik, seperti membuat tag atau rilis di repositori sumber yang sesuai dengan versi komponen yang diterbitkan di registri publik. Ketika repositori sumber pada titik tertentu commit Jika suatu komponen diberi label rilis, dan kemudian tiba-tiba satu versi gagal mengikutinya, itu saja sudah menjadi bukti kuat bahwa komponen tersebut mungkin terkontaminasi: pelaku jahat mungkin telah membobol akun yang digunakan untuk menerbitkan komponen tersebut, tetapi tidak memiliki izin tulis di repositori kode sumber. Banyak serangan secara rutin terdeteksi menggunakan aturan ini: misalnya, Serangan buku besar Hal ini dapat dengan mudah dideteksi melalui cara-cara tersebut. Oleh karena itu, analisis konteks mengidentifikasi anomali semacam itu dalam proses penerbitan.
Pembatasan Ketergantungan (Dependency Firewalling)
Pendekatan lain adalah dengan memiliki daftar putih komponen yang komprehensif untuk semua grafik ketergantungan yang digunakan dalam perangkat lunak Anda, sehingga dalam setiap proses build pipeline Hanya versi komponen yang disetujui yang dapat diinstal dan digunakan di organisasi Anda. “firewall"Penerapan aturan ini dilakukan menggunakan registri internal tempat arsip tar untuk versi komponen yang diizinkan disajikan (di-cache atau diproksikan). Harap dicatat bahwa daftar putih apa pun tidak akan berfungsi kecuali Anda memiliki teknologi untuk mengklasifikasikan versi baru apa pun sebagai cukup aman sehingga dapat ditambahkan ke daftar putih."
Harap dicatat bahwa peringatan dini (deteksi cepat sesegera mungkin setelah publikasi versi baru) perlu dikombinasikan dengan cara untuk menggunakan informasi tersebut secara proaktif guna memblokir komponen yang memengaruhi proses build. pipelineatau mesin pengembang [4]Kami menyebut ini “firewall ketergantungan”: sebuah mekanisme karantina untuk melindungi build otomatis dari paket berbahaya. Registri paket dan citra internal bagus untuk melindungi organisasi dari kejahatan eksternal, tetapi bukti yang cukup kuat diperlukan agar karantina efektif.
Pembatasan Ruang Berkelanjutan (Runtime Sandboxing)
Pendekatan alternatif untuk deteksi pada saat publikasi adalah dengan menganalisis perilaku saat runtime. Idenya adalah untuk menangkap perilaku yang diharapkan dari perangkat lunak dan mendeteksi (atau memblokir) anomali apa pun yang ditemukan. Pendekatan ini memiliki masalah karena harus menginstrumentasi runtime untuk pemantauan atau pemblokiran, dan ini merupakan ide menjanjikan yang akan ditambahkan ke dalam persenjataan mekanisme perlindungan terhadap gangguan komponen berbahaya.
Menyusun Strategi Komprehensif
Strategi yang direkomendasikan perlu menggabungkan berbagai teknik dalam proses pengembangan perangkat lunak, dengan mengendalikan pembaruan versi untuk memblokir komponen berbahaya yang masuk. Kita harus mengakomodasi pembatasan versi (version pinning) untuk menghindari infeksi otomatis dengan memperbarui versi untuk mendapatkan perbaikan bagi kerentanan yang penting; penilaian yang cepat dan efisien terhadap ketergantungan langsung dan tidak langsung selama pembaruan versi untuk memiliki cukup bukti bahwa perangkat lunak tersebut tidak mengandung malware. Versi perangkat lunak yang bergantung pada komponen berbahaya yang diketahui harus diblokir. Dan semua itu harus ditegakkan.
Gunakan pembatasan versi (version pinning) jika memungkinkan, karena hal ini membuat proses build lebih mudah direproduksi. Penetapan versi dengan peningkatan versi yang terkontrol dan disetujui secara manual., dan dibantu oleh teknologi pendukung, harus menilai apakah pembaruan tersebut membawa malware atau merusak perangkat lunak, dan menyelaraskan pembaruan untuk memperbaiki kerentanan dengan menghindari infeksi malware. Alat bantu dapat membantu di sini, dengan (1) memprioritaskan kerentanan mana yang benar-benar penting (dapat dijangkau dan dieksploitasi, dengan risiko tinggi menjadi sasaran penyerang), (2) memilih versi target yang kompatibel dengan penggunaan komponen saat ini dan tidak merusak perangkat lunak, (3) memilih versi target yang tidak mengandung perilaku berbahaya, dan (4) membuat pembaruan versi untuk dependensi langsung dan tidak langsung menjadi mudah, dengan menyarankan perubahan dalam file manifes yang dapat disetujui dengan cepat. Langkah (3) membutuhkan informasi spesifik tentang komponen berbahaya sedekat mungkin dengan waktu publikasinya.
Proses pembaruan dependensi ini harus dilakukan ditegakkan ke diverifikasi di semua tempat. Prosesnya harus didokumentasikan, dan semua pihak yang terlibat harus dilatih, karena seringkali pengembangan dan pembuatan/penyebaran perangkat lunak dilakukan secara eksternal. CI/CD pipelines harus dimodifikasi sesuai kebutuhan, sehingga otomatisasi tidak memungkinkan ketergantungan tidak langsung yang berbahaya untuk masuk ke dalam proses build: guardrails Memblokir proses build jika terdapat cukup bukti potensi malware dalam sebuah dependensi adalah cara yang direkomendasikan.
Jika organisasi Anda memiliki registri internal yang bertindak sebagai proksi keamanan untuk menyimpan versi komponen yang diizinkan, Anda harus memperoleh informasi tentang komponen berbahaya (selain kriteria lain) untuk memeriksa komponen yang diminta sebelum menambahkannya ke daftar yang diizinkan.
Menggunakan perangkat lunak sumber terbuka dengan aman bukanlah hal mudah, dan faktor malware harus sepenuhnya diperhitungkan, dengan upaya serupa yang dilakukan untuk penanganan kerentanan.
Satu catatan terakhir: Asal usul sumberDalam bentuk pengesahan perangkat lunak, yang dihasilkan pada saat pembuatan komponen, ini merupakan bagian penting lainnya dalam upaya melacak artefak (tarball komponen) dengan sumber dan proses pembuatan yang menghasilkannya. Perlu dicatat bahwa tautan antara snapshot sumber + lingkungan pembuatan dan artefak perangkat lunak terkait (ditandatangani oleh sistem pembuatan tepercaya) ini tidak secara otomatis mencegah komponen tersebut mengandung perilaku berbahaya, tetapi mempersulit penjahat untuk menyuntikkan malware. Dan menjadikan validasi asal usul sebagai persyaratan umum untuk menggunakan komponen sumber terbuka akan memakan waktu lama, dan hanya baru saja ditambahkan ke NPMMembuat sistem build dan deploy tepercaya tersebut tahan terhadap perubahan atau memungkinkan deteksi terhadap perubahan apa pun dalam proses build adalah cerita yang berbeda, di luar cakupan postingan ini.
Bacaan lebih lanjut
Episode selanjutnya Paket Berbahaya Sumber Terbuka: Pendekatan Xygeni akan mempresentasikan strategi yang kami ikuti di Xygeni untuk kami Peringatan Dini Malware Sistem (MEW). Versi paket baru di registri paket dan citra publik dipindai dan bukti diperoleh menggunakan kombinasi analisis statis, dinamis, kemampuan, dan kontekstual. Bukti tersebut, dikombinasikan dengan reputasi pengguna dan riwayat perubahan di repositori kode sumber, memungkinkan klasifikasi komponen secara otomatis ke dalam kategori berisiko tinggi dan kemungkinan berbahaya. Sistem ini belajar dari bukti masa lalu yang dikumpulkan dari paket untuk mengurangi kesalahan positif seminimal mungkin.
Organisasi yang berlangganan akan menerima pemberitahuan peringatan untuk komponen yang mereka gunakan, secara langsung atau tidak langsung, ketika versi berbahaya dikategorikan. Kemudian, analisis manual dilakukan oleh analis kami, yang mengkonfirmasi atau menolak klasifikasi tersebut. Untuk malware yang terkonfirmasi, registri publik akan diberitahu sehingga dapat melakukan analisis sendiri dan biasanya menghapus versi berbahaya atau mengambil tindakan tambahan, seperti memblokir atau menghapus akun pengguna yang bersangkutan.
Kami akan menjelaskan bagaimana kami membantu NPM, PyPI, GitHub, dan infrastruktur kunci lainnya dalam ekosistem sumber terbuka untuk mengurangi waktu aktif komponen berbahaya baru yang dipublikasikan hingga dipastikan sebagai malware dan dihapus dari registri. Dan bagaimana organisasi dapat memperoleh manfaat dari sistem MEW untuk memiliki perlindungan yang jauh lebih baik terhadap serangan rantai pasokan perangkat lunak yang melibatkan komponen sumber terbuka.
- [1] Bagaimanapun, pengguna komponen perlu memeriksa apakah file tarball komponen tersebut di-cache atau terdaftar di suatu tempat, misalnya di registri internal, sehingga masalah tersebut dapat diatasi.
- [2] Komponen yang dikemas mencakup manifes yang menyatakan isi dan metadata, kode sumber atau kode yang telah dikompilasi, skrip instalasi, dan item tambahan seperti rangkaian pengujian, sesuai dengan format pengemasan dan biasanya dalam bentuk terkompresi. Ini disebut "tarball komponen".
- [3] Sekalipun pelaku jahat dapat memodifikasi komponen yang telah dipublikasikan karena adanya pelanggaran pada registri itu sendiri, digest kriptografi biasa dapat mendeteksi setiap perubahan pada tarball setelah analisis selesai.
- [4] Ingatlah bahwa beberapa komponen berbahaya berjalan saat instalasi, sehingga dapat memengaruhi node pengembang yang tanpa sadar menjalankan "npm install X" dengan X sebagai komponen berbahaya.
