Iki episode kaping telu ing seri artikel babagan jinis serangan rantai pasokan piranti lunak sing paling umum: sing nyalahgunakake registri umum Open-sumber komponen piranti lunak. Sawise nganalisis ing episode sadurunge "Anatomi Paket Jahat: Apa Tren sing Ana?"Kepiye carane pelaku jahat nyuntikake prilaku jahat menyang komponen anyar utawa sing wis diterbitake, kita wis siyap nganggo jaket pemadam kebakaran lan mriksa kepiye carane bisa mblokir piranti lunak jahat sing dikirim kanthi cara iki, utawa, nangani kedadeyan siber sing bisa uga serius amarga kita njupuk pendekatan sing salah."
Umume profesional sing ngerti keamanan duwe ide babagan carane nangani ancaman iki. Kita wis krungu manajer keamanan ngomong tanpa ragu-ragu yen SCA Piranti wis ngandhani sampeyan nalika versi paket kasebut minangka malware. Utawa yen piranti kasebut gumantung marang komponen piranti lunak sing wis dikenal lan diulas kanthi apik, ing ngendi malware apa wae bakal langsung dideteksi lan dibusak. Piranti kasebut nggunakake versi minor/patch terbuka kanggo entuk perbaikan kerentanan kanthi otomatis, lan iku cara sing tepat lan disaranake kanggo nyuda risiko ing dependensi sumber terbuka, miturut "nambal luwih awal, nambal asring"Asas.
Ing episode iki, kita bakal ngrembug kenapa ide-ide iki salah, lan kepiye salah paham kasebut nyumbang marang popularitas mekanisme serangan iki, lan risiko gedhe sing dialami organisasi. Kita bakal mungkasi karo apa sing efektif, lan endi upaya lan sumber daya sing digunakake.
Kesalahpahaman umum
Sajrone lelampahan kita karo keamanan piranti lunak, kita weruh teknik serangan berkembang lan macem-macem ide saka wong-wong sing sadar keamanan. Organisasi asring salah paham apa sing bisa nglawan ancaman iki, mula dhisik kita bakal mriksa apa sing ora bisa, diringkes ing dhaptar salah paham ing ngisor iki, sing ora lengkap.
Salah Paham #1: SCA piranti wis nglaporake komponen sing mbebayani
Pancen! Nanging sawise kasunyatan… Nalika mbokmenawa wis kasep yen elemen kasebut digunakake ing pembangunan piranti lunak, lan pelaku jahat wis entuk pijakan ing pangembang utawa CI/CD host. Rahasia bisa uga wis diekstrak, malware tambahan diunduh lan diinstal, lan bisa uga mungsuh obah menyamping lan wis entuk akses menyang papan liya.
Analisis Komposisi Piranti Lunak (SCA) piranti dirancang kanggo ngenali kerentanan potensial sing dikenal. Piranti modern nindakake tugas sing apik kanthi nambah rasio sinyal-gangguan, nemtokake manawa kerentanan kasebut pancen bisa digayuh utawa dieksploitasi. Nanging ora ana gunane nglawan malware anyar. Bayangake komponen jahat minangka kerentanan zero-day: Mung nalika prilaku jahat dideteksi, komponen kasebut dilaporake menyang registri sing nyekel, sing sawise ditinjau dening tim keamanan dikonfirmasi minangka jahat lan dibusak saka registri. [1].
Ing wektu iku, jagad iki (kalebu SCAs) ngerti yen nginstal utawa nggunakake komponen (utawa sawetara versi saka komponen sing wis ana) dudu perkara sing apik. Nanging iki kedadeyan nalika komponen kasebut ora kasedhiya saka registriNgerti yen aku duwe kerentanan ing komponen pihak katelu, utawa malah komponen sing dikategorikake minangka mbebayani dening registri iku apik, nanging sayangé SCA utawa piranti audit umum ora mbantu ing konteks iki. Kajaba saka SCAPiranti /audit pancen bisa ngerti luwih dhisik yen komponen kasebut mbebayani sadurunge digunakake ing organisasi sampeyan.
Elinga, solusi apa wae kanggo komponen sumber terbuka sing mbebayani kudu ndeteksi on-the-fly, antarane nalika komponen diterbitake ing registri lan nalika komponen (versi) pisanan digunakake ing organisasi sampeyan. Lan iku kalebu komponen transitif.
Kesalahpahaman #2: Ngontrol skrip instalasi nalika mbangun nyegah prilaku jahat saka komponen sumber terbuka
Maneka warna manajer paket nawakake kemampuan kanggo mbukak skrip (kalebu ing komponen tarball [2]), amarga alesan sing sah, kayata ngompilasi item sing dibutuhake ing platform sing beda-beda, nggawe kode, utawa mbukak tes, lan kita kabeh kudu ngerti manawa item kasebut bisa disalahgunakake dening aktor ala yen skrip jahat kalebu ing tarball, utawa yen penyerang bisa nggawe skrip jahat mlaku tinimbang sing apik.
Ngerti iki, kita bisa ngonfigurasi manajer paket supaya ora nggatekake skrip. Contone, nganggo NPM, –nglirwakake-skrip flag (utawa properti konfigurasi ing .npmrc file) nglewati skrip nalika instalasi. Iki bisa nyebabake sawetara masalah amarga mbukak skrip umum ing akeh ekosistem: Sawetara manajer paket malah ora ngidini mateni eksekusi skrip (pitunjuk: prompt "Manajer paket endi sing ora ngidini mateni eksekusi skrip instalasi?"ing AI favoritmu). Nanging iki ora nglindhungi sacara umum (kita kudu ngetrapake manawa konfigurasi skip disable ana ing endi-endi).
Lan nalika prilaku jahat ora dumunung ing skrip instalasi nanging ing piranti lunak kanggo dieksekusi nalika runtime, opsi iki wae ora nglindhungi kita.
Kesalahpahaman #3: Pinning versi nyegah komponen mbebayani diinstal
Ana kompromi antarane ndandani luwih awal lan asring nganggo versi mbukak (ngidini manajer paket nginstal nganyari anyar kanthi otomatis nalika kasedhiya kanggo ndandani keamanan) lan versi penyematan (nduwèni kabèh dependensi langsung lan transitif kanggo piranti lunak ing versi tetep). Prinsip keamanané angel lan kadhangkala kontradiktif, kaya sing kedadeyan karo "patch awal, patch asring" lan "Peningkatan kualitas ora kena dianggep entheng"Sawetara manajer paket nggawe pembaruan otomatis nganggo rentang server kanthi cara sing disaranake. Apik yen sampeyan uga pengin nampa pembaruan sing mbebayani! Ya, komponen kudu dianyari kanggo nampa perbaikan keamanan sing nutup kerentanan sanalika bisa, nanging ... aja nganti manajer paket nindakake iki kanthi otomatis.
Kesalahpahaman #4: Nggunakake komponen sing dipercaya iku aman. Versi angkoro bakal langsung ditemokake, diungkapake, lan dibusak.
Apa sebabé komponen iki dipercaya? Mungkin amarga populer banget, karo akèh wong sing nggoleki kerentanan, akèh kontributor kanggo pangopènan, karo akèh pangopèn inti sing sregep mriksa kabèh. pull requestsKasunyatane beda banget. Sawetara komponen penting dikelola dening siji pangembang sing ora dibayar. Kerangka kerja sing digunakake sacara wiyar wis sawetara kontributor reguler, kanthi jumlah sing saya suda kanthi cepet commits saben pangopèn (proyèk populer duwé kontributor sing dawa sing nindakaké sawetara drive-by commit lan ora bakal bali maneh). Lan proyèk populer kanthi siji pangopènan akèh banget.
Bayangna awakmu ngomong "Oh, kita nggunakake Spring Boot / Angular / React / PyTorch / gambar Docker basis resmi, mula risiko sing sampeyan omongake cukup sithik." Mungkin kuwi bener, kita para vendor keamanan sing tansah nggawe wedi, lan ngganggu tim pangembangan kanggo nyuda risiko sing bisa diperdebatkan iku omong kosong. Sampeyan bisa uga kepengin mlumpat menyang paragraf panampa risiko (ing bagean sabanjure) lan kabeh wis rampung. Sayange, komponen sing paling populer minangka target kanggo aktor ala, lan contone, sing populer Perpustakaan PyTorch diserang jaman dhisik.
"Ditemokake kanthi cepet, diungkapake, lan dicopot." Butuh pirang-pirang dina kanggo mbusak komponen jahat anyar saka registri umum. Registri ati-ati babagan mbusak versi komponen, kanggo kabecikan. Pengalaman kita yaiku yen wis dilaporake saka pihak kita, wektu rata-rata kanggo registri kanggo mbusak versi sing kena pengaruh yaiku 39 jam, luwih saka sedina setengah. Ana komponen jahat sing seminggu sawise laporan awal kita ing registri sadurunge dibusak. Lan ing sawetara kasus, komponen kasebut dibusak mung sawise korban utawa perusahaan respon kedadeyan nglaporake kedadeyan sing nglibatake komponen kasebut.
Apa sing ORA Bisa Digunakake kanggo Nglawan Komponen sing Ngapusi
Pendekatan sing ora spesifik bakal gagal total. Iki wis mesthi, sampeyan ora nyedhiyakake langkah-langkah penanggulangan sing efektif kanggo risiko sing ana gandhengane karo ancaman iki.
Traditional SCA Piranti kasebut ngandhani sampeyan babagan malware sing dikenal nanging duwe jendela paparan sing amba. Kajaba dheweke proaktif nindakake deteksi malware kanthi mblokir komponen jahat kanthi paksa, dheweke ora bisa nglawan ancaman iki.
Mateni skrip instalasi bisa mbantu nanging kudu dileksanakake ing endi wae komponen kudu diinstal. Padha karo penyematan versi, amarga versi ora bisa disemat saka kahanan awal sing aman selawase.
Nganggep komponen populer entuk perhatian sing cukup saengga ora bisa diinjeksi prilaku sing ora dikarepake ing serangan rantai pasokan tanpa deteksi meh langsung kanggo nyegah kerusakan iku naif lan beboyo. Sampeyan mesthi ora pengin urip ing pinggir dalan, ta?
Yen sampeyan mandheg ing titik iki, mula panampa risiko mung siji-sijine sing bisa koklakoni: Iki minangka decision sing kudu didokumentasikake ing model ancaman/penilaian risiko sampeyan, kalebu alesan kanggo nampa risiko lan implikasi potensiale. Ningkatake kesadaran kanthi menehi informasi marang manajemen lan pihak liyane sing relevan. Sawetara kontingensi bisa direncanakake nalika komponen mbebayani diinstal utawa kalebu ing piranti lunak sampeyan, nanging iki angel amarga penyerang duwe akeh dalan sing kudu ditindakake. Rincian serangan rantai pasokan adhedhasar panggunaan komponen mbebayani bakal ngowahi kanthi drastis pengungkapan umum kedadeyan kasebut, sing mbokmenawa wajib miturut kerangka peraturan organisasi sampeyan. Sampeyan uga bisa ngatasi kontrol kompensasi or risiko transfer contone karo asuransi.
Nanging, ana kontrol sing ngatasi ancaman kasebut lan kudu ditimbang yen sampeyan ora marem karo panampa risiko. Mangga terus maca.
Apa sing Bisa Digunakake kanggo Nglawan Serangan Nggunakake Komponen Angkoro
Penanganan Versi Solid
Nyemat versi nganggo bump versi sing dikontrol lan diinformasikake minangka cara sing kudu ditindakake, kanggo ngimbangi kabutuhan kanggo mbusak kerentanan tanpa nampa malware. Nanging elinga salah paham #3: Nyemat versi wae ora cukup kanggo mblokir kode angkoro sing asale saka versi anyar, amarga sampeyan kudu nganyari versi ing mangsa ngarep kanthi katergantungan langsung utawa ora langsung. Ing wektu kasebut sampeyan butuh bukti sing cukup kuwat supaya kabeh versi sing dimodifikasi ora ngemot malware.
Awas Wiwitan
Salah sawijining pendekatan kanggo masalah komponen mbebayani yaiku sistem peringatan dini (sing dijenengi ing kene minangka Peringatan Dini Malware utawa MEW), ing ngendi versi anyar sing diterbitake (kanggo komponen anyar utawa sing wis ana) dianalisis dening mesin deteksi, sing nalika cukup bukti ditemokake bisa nglasifikasikake versi anyar minangka potensial mbebayani.
Otomatisasi iku penting banget ing kene, amarga ora mungkin kanggo mriksa kabeh komponen anyar kanthi manual kanthi kecepatan penerbitan saiki. Dadi mesin deteksi kudu nggabungake macem-macem teknik, bisa uga kalebu analisis statis, dinamis, lan kemampuan, reputasi pangguna, lan bukti sing asale saka bedane antarane metadata komponen lan isi tarball, utawa antarane tarball lan repositori sumber saka ngendi komponen kasebut mesthine asale.
Ana zona peteng antarane wektu penerbitan lan nalika mesin nganalisa isi komponen, nanging ora kena ngluwihi sawetara menit. Skema kasebut bisa diowahi, contone kanthi ngenteni komponen anyar dianalisis sadurunge ngidini diinstal lan digunakake ing pembangunan piranti lunak. pipelines, utawa nganalisis miturut panyuwunan nalika dibutuhake. Komponen ing versi tartamtu ora bisa diowahi [3], dadi mung perlu dianalisis sapisan.
Otomatisasi lengkap ora bisa ditindakake, lan tinjauan keamanan kanggo komponen sing bisa uga mbebayani dibutuhake. Ati-ati karo para pendukung obat mujarab digitalAI lan Machine Learning durung cukup dikembangake kanggo njupuk tembung pungkasan nalika nerangake konfirmasi manawa komponen sing dicurigai duwe malware. Mesthi, machine learning nduweni peran penting ing mesin deteksi kanggo nglasifikasikake komponen input saka bukti mentah sing dijupuk, nanging sawise komponen kasebut "karantina", tembung pungkasan ana ing review manual dening tim keamanan sing duwe pengalaman ing komponen mbebayani. Iki ngonfirmasi potensial malware utawa nglasifikasikake maneh minangka aman. Lan periode wektu kasebut ana ing kisaran jam.
Registri nglaporake versi/komponen sing mbebayani; registri banjur nindakake review kanggo ngonfirmasi lan nerusake menyang pambocoran umum lan mbusak saka registri. Sawetara registri nyimpen paket panyimpenan keamanan. Rentang wektu ing kene yaiku dina utawa minggu wiwit publikasi, yaiku 'manggon wektu'utawa'jendela eksposur' kanggo umume komponen sing mbebayani.
Apa bisa ngerti yen versi komponen iku mbebayani?
Dadi kanggo peringatan awal, kita kudu menehi jawaban sing marem kanggo pitakonan iki: Kepiye carane aku bisa ngerti manawa perpustakaan utawa paket iku (ora) mbebayani? Kepiye carane ngumpulake bukti sing cukup babagan prilaku jahat? Bisa, nanging angel, amarga mungsuh nggunakake akeh kepinteran kanggo ngindhari deteksi. Ana macem-macem pendekatan, saben duwe pro lan kontra.
Analisis statis bisa mriksa kabeh jalur eksekusi, mriksa teknik sing digunakake dening penyerang tanpa mbukak komponen kasebut, lan nindakake tugas pra-pemrosesan kaya de-obfuscation utawa deciphering. Nalika penyerang nyoba ndhelikake kerusakan, upaya obfuscation pancen minangka bukti malware (nanging elinga yen komponen sing sah ngaburkan kode kanggo njaga properti intelektual, sing bertentangan karo "mbukak sumber"). Mung sawetara serangan canggih kanthi obfuscation sing kuwat sing butuh sandboxing, nanging obfuscation sing kuwat kaya ngono minangka tandha saka niat jahat. Elinga yen konvensional SAST Piranti dirancang kanggo kerentanan sing ora disengaja, dudu kanggo niat jahat kaya backdoors.
Analisis dinamis mbukak komponen lan mriksa respon kanthi menehi instrumen runtime, biasane kanthi nyedhiyakake lingkungan sandboxed. Prilaku ala sing dipicu ing kahanan tartamtu bisa uga ora dideteksi: elinga yen malware bisa uga nggunakake teknik evasion kaya Virtualisasi/Penghindaran Kotak Pasir kanggo diaktifake mung nalika ora ana ing pengawasan, lan uga minangka tandha aktivitas jahat kanggo mesin analisis statis apa wae.
Analisis kemampuan nimbang apa sing ditindakake komponen kasebut: menyang ngendi nyambung, file endi sing diakses, printah utawa program endi sing dilakokake, terminal utawa piranti I/O sing ditindakake, utawa panggilan sistem endi sing diundang. Sidik jari prilaku iki bisa dibandhingake (kanggo komponen sing wis ana) ing antarane versi, mula nalika prilaku sing ora dikarepke dideteksi, bukti kasebut bisa nuwuhake kecurigaan babagan aktivitas mbebayani potensial sing diinjeksi ing versi anyar. Pendekatan iki ngetutake langkah-langkah triase sing ditindakake analis keamanan nalika ngadhepi malware potensial: inspeksi nggunakake senar utawa piranti sing padha. Pendekatan iki ndeteksi prilaku jahat preduli saka kahanan pemicu lan bisa digunakake nalika ora ana kode sumber sing kasedhiya.
Analisis konteks Ngumpulake informasi babagan kepiye komponen kasebut diterbitake lan dening sapa. Kampanye aktor ala asring nggunakake akun pangguna anyar sing ora tundhuk karo proses pemeriksaan sing ketat. Nlacak aktivitas kepungkur bisa menehi wawasan babagan pangguna sing ndasari, biasane kanggo anomali sing bisa menehi pitunjuk babagan potensi kompromi. Reputasi angel banget dipikolehi lan gampang banget ilang! Pangguna sing ora duwe aktivitas kepungkur iku netral, nanging karma ngoyak sing jahat. Hacktivist, utawa pangguna biasa sing kredensial penerbitane dicolong kudu dilacak kanthi ati-ati.
Informasi kontekstual liyané yaiku anané bédané antara repositori sumber sing konon digunakaké kanggo nggawé tarball komponen lan isi tarball kasebut dhéwé. Lan uga ngetutaké praktik sing apik, kaya nggawé tag utawa rilis ing repositori sumber sing cocog karo versi komponen sing diterbitake ing registri umum. Nalika repositori sumber ing tartamtu commit ditandhani karo rilis, banjur dumadakan ana siji versi sing ora ngetutake, iku wae wis dadi bukti kuwat yen komponen kasebut bisa uga kena pengaruh: aktor ala bisa uga wis ngganggu akun sing digunakake kanggo nerbitake komponen kasebut, nanging ora duwe ijin nulis ing repositori kode sumber). Akeh serangan sing rutin dideteksi nggunakake aturan kasebut: contone, Serangan buku besar bisa gampang dideteksi kaya ngene. Mulane, analisis konteks ngenali anomali kasebut ing proses penerbitan.
Firewall Ketergantungan
Pendekatan sing beda yaiku nduwe dhaptar putih komponen sing lengkap kanggo kabeh grafik dependensi sing digunakake ing piranti lunak sampeyan, saengga ing sembarang bangunan pipeline mung versi komponen sing disetujoni sing bisa diinstal lan digunakake ing organisasi sampeyan. "firewall"dileksanakake nggunakake registri internal ing ngendi tarball kanggo versi komponen sing diidini dilayani (di-cache utawa di-proxy). Elinga yen dhaptar putih apa wae ora bakal bisa digunakake kajaba sampeyan duwe teknologi kanggo nglasifikasikake versi anyar minangka cukup aman supaya bisa ditambahake menyang dhaptar putih.
Elinga yen peringatan awal (deteksi cepet sanalika sawise publikasi versi anyar) kudu digabungake karo sawetara cara kanggo nggunakake informasi kasebut kanthi proaktif kanggo mblokir komponen sing mengaruhi pembangunan. pipelineutawa mesin-mesin pangembang [4]Kita nyebut iki "firewall ketergantungan": mekanisme karantina kanggo nglindhungi bangunan otomatis saka paket sing mbebayani. Paket internal lan registri gambar apik kanggo nglindhungi organisasi saka kejahatan njaba, nanging bukti sing cukup kuwat dibutuhake kanggo nggawe karantina efektif.
Sandboxing Runtime
Pendekatan alternatif kanggo deteksi nalika wektu penerbitan yaiku nganalisis prilaku nalika runtime. Idené yaiku kanggo nangkep prilaku sing diarepake saka piranti lunak lan ndeteksi (utawa mblokir) anomali sing ditemokake. Tindakan iki nduweni masalah kudu nginstrumen runtime kanggo ngawasi utawa mblokir, lan iki minangka ide sing njanjeni sing bakal ditambahake menyang gudang mekanisme perlindungan nglawan hama komponen sing mbebayani.
Nyetel Strategi sing Komprehensif
Strategi sing disaranake kudu nggabungake macem-macem teknik ing proses pangembangan piranti lunak, ngontrol pembaruan versi kanggo mblokir komponen mbebayani sing mlebu. Kita kudu ngakomodasi penyematan versi kanggo nyegah infeksi otomatis kanthi nganyari versi kanggo entuk perbaikan kanggo kerentanan sing penting; penilaian sing cepet lan efisien babagan katergantungan langsung lan ora langsung sajrone pembaruan versi supaya duwe bukti sing cukup yen piranti lunak kasebut ora kebak malware. Build piranti lunak sing gumantung marang komponen mbebayani sing dikenal kudu diblokir. Lan kabeh kudu dileksanakake.
Gunakna pinning versi, yen bisa, amarga iki ndadekake versi luwih bisa direproduksi. Penyematan versi nganggo bump versi sing dikontrol lan disetujoni kanthi manual, Lan dibantu karo teknologi pembantu, kudune netepake apa pembaruan kasebut nggawa malware utawa ngrusak piranti lunak, lan nyelarasake pembaruan kanggo ndandani kerentanan karo nyegah infeksi malware. Tooling bisa mbantu ing kene, kanthi (1) menehi prioritas kerentanan endi sing penting (bisa digayuh lan dieksploitasi, kanthi risiko dhuwur dadi target penyerang), (2) milih versi target sing kompatibel karo panggunaan komponen saiki lan ora ngrusak piranti lunak, (3) milih versi target sing ora ngemot prilaku jahat, lan (4) nggawe pembaruan versi kanggo dependensi langsung lan ora langsung dadi cepet, kanthi menehi saran pangowahan ing file manifes sing bisa disetujoni kanthi cepet. Langkah (3) mbutuhake informasi khusus babagan komponen jahat sing cedhak karo wektu publikasi sabisa-bisane.
Proses nganyari dependensi iki kudu dileksanakake lan Diverifikasi ing kabeh panggonan. Proses kasebut kudu didokumentasikake, lan kabeh pihak sing terlibat kudu dilatih, amarga asring pangembangan lan pambangunan/panyebaran piranti lunak dieksternalisasi. Ing CI/CD pipelines kudu diowahi miturut kabutuhan, supaya otomatisasi ora ngidini katergantungan ora langsung sing ala mlebu ing build: guardrails Mblokir build yen ana cukup bukti malware potensial ing dependensi minangka cara sing disaranake.
Yen organisasi sampeyan duwe registri internal sing tumindak minangka proxy keamanan kanggo nyimpen versi komponen sing diidini, sampeyan kudu entuk intelijen babagan komponen sing mbebayani (saliyane kritéria liyane) kanggo mriksa komponen sing dijaluk sadurunge nambahake menyang dhaptar sing diidini.
Nggunakake piranti lunak sumber terbuka kanthi aman iku ora gampang, lan faktor malware kudu digatekake kanthi lengkap, kanthi upaya sing padha ditindakake kanggo nangani kerentanan.
Siji cathetan pungkasan: Asal-usul sumber, awujud atestasi piranti lunak, sing digawe nalika wektu mbangun komponen, minangka bagean penting liyane ing upaya kanggo nglacak artefak (tarball komponen) karo sumber lan proses mbangun sing ngasilake. Elinga yen pranala antarane snapshot sumber + lingkungan mbangun lan artefak piranti lunak sing ana gandhengane (ditandatangani dening sistem mbangun sing dipercaya) ora nyegah per-se yen komponen kasebut ora ngemot prilaku jahat, nanging ndadekake luwih angel kanggo wong jahat nyuntikake malware. Lan nggawe validasi asal-usul minangka syarat umum kanggo ngonsumsi komponen sumber terbuka bakal mbutuhake wektu sing suwe, lan mung bubar ditambahake menyang NPMNggawe sistem mbangun lan nyebar sing dipercaya supaya ora gampang diganggu, utawa ngaktifake deteksi gangguan ing mbangun iku crita sing beda, ora kalebu ing ruang lingkup kiriman iki.
Cathetan suku
Episode sabanjure Paket Malicious Sumber Terbuka: Pendekatan Xygeni bakal nampilake strategi sing kita tindakake ing Xygeni kanggo kita Peringatan Dini Malware Sistem (MEW). Versi paket anyar ing paket umum lan registri gambar dipindai lan bukti dipikolehi nggunakake kombinasi kemampuan statis, dinamis, lan analisis kontekstual. Bukti kasebut, digabungake karo reputasi pangguna lan riwayat owah-owahan ing repositori kode sumber, ngidini klasifikasi komponen kanthi otomatis menyang kategori berisiko tinggi lan kemungkinan mbebayani. Sistem kasebut sinau saka bukti kepungkur sing diklumpukake saka paket kanggo nyuda positif palsu seminimal mungkin.
Organisasi sing langganan nampa kabar peringatan kanggo komponen sing digunakake, kanthi langsung utawa ora langsung, nalika versi mbebayani dikategorikake. Banjur analisis manual ditindakake dening analis kita, sing ngonfirmasi utawa nolak klasifikasi kasebut. Kanggo malware sing wis dikonfirmasi, registri umum diwenehi kabar supaya bisa nindakake analisis dhewe lan biasane mbusak versi mbebayani utawa njupuk tindakan tambahan, kayata mblokir utawa mbusak akun pangguna sing dimaksud.
Kita bakal nerangake kepiye carane mbantu NPM, PyPI, GitHub, lan infrastruktur utama liyane ing ekosistem sumber terbuka kanggo nyuda wektu tunggu komponen jahat anyar sing diterbitake tetep aktif nganti dikonfirmasi minangka malware lan dibusak saka registri. Lan kepiye organisasi bisa entuk manfaat saka sistem MEW kanggo duwe perlindungan sing luwih apik marang serangan rantai pasokan piranti lunak sing nglibatake komponen sumber terbuka.
- [1] Nanging, panganggo komponen kudu mriksa apa tarball komponen disimpen ing cache utawa kadhaptar ing endi wae, contone ing registri internal, supaya penyakit kasebut bisa dibasmi.
- [2] Komponen sing wis dikemas kalebu manifes sing nyatakake isi lan metadata, kode sumber utawa sing wis dikompilasi, skrip instalasi, lan item tambahan kayata suite tes, miturut format kemasan lan biasane ing bentuk sing dikompres. Iki diarani "tarball komponen".
- [3] Sanajan aktor jahat bisa ngowahi komponen sing diterbitake amarga ana pelanggaran ing registri kasebut, digest kriptografi biasa bisa ndeteksi owah-owahan ing tarball sawise analisis rampung.
- [4] Elinga yen sawetara komponen mbebayani mlaku nalika instalasi, mula bisa mengaruhi node pangembang sing tanpa disadari mbukak "npm install X" karo X minangka komponen mbebayani.
