Ito ang ikatlong episode sa isang serye ng mga artikulo tungkol sa pinakalaganap na uri ng mga pag-atake sa supply chain ng software: iyong mga umaabuso sa isang pampublikong rehistro ng open-source mga bahagi ng software. Matapos suriin sa nakaraang episode na "Anatomiya ng mga Malisyosong Pakete: Ano ang mga Uso?"Kung paano ipinapasok ng masasamang aktor ang malisyosong pag-uugali sa mga bago o umiiral nang nai-publish na mga bahagi, handa na kaming isuot ang aming mga firefighting jacket at suriin kung paano namin matagumpay na mahaharang ang malisyosong software na inihahatid sa ganitong paraan, o kaya naman, haharapin ang isang potensyal na malubhang insidente sa cyber dahil mali ang aming pamamaraan."
Karamihan sa mga propesyonal na may kamalayan sa seguridad ay may mga ideya kung paano haharapin ang bantang ito. Narinig na natin ang mga security manager na nagsasabing walang pag-aalinlangan na SCA Sinasabi na sa iyo ng mga tool kung kailan malware ang isang bersyon ng package. O kaya naman ay umaasa sila sa mga kilalang at masusing nasuring bahagi ng software, kung saan ang anumang malware ay agad na matutukoy at maaalis. Gumagamit sila ng mga open minor/patch na bersyon para sa awtomatikong pagkuha ng mga pag-aayos ng kahinaan, at iyon ang tama at inirerekomendang paraan upang mabawasan ang panganib sa mga open source dependencies, kasunod ng "patch nang maaga, patch nang madalas" prinsipyo.
Sa episode na ito, susuriin natin kung bakit mali ang mga ideyang ito, at kung paano nakakatulong ang mga maling akala na ito sa kasikatan ng mekanismong ito ng pag-atake, at sa napakalaking panganib na nararanasan ng mga organisasyon. Magtatapos tayo sa kung ano ang gumagana, at kung alin ang pagsisikap at mga mapagkukunang kasangkot.
Mga Karaniwang maling kuru-kuro
Sa aming paglalakbay sa seguridad ng software, nasaksihan namin ang pag-unlad ng mga pamamaraan ng pag-atake at ang malawak na hanay ng mga ideya mula sa mga taong may kamalayan sa seguridad. Kadalasang hindi nauunawaan ng mga organisasyon kung ano ang epektibo laban sa banta na ito, kaya susuriin muna natin kung ano ang hindi epektibo, na pinaikli sa sumusunod, hindi kumpleto, na listahan ng mga maling akala.
Maling Akala #1: SCA nag-uulat na ang mga tool ng mga malisyosong bahagi
Sa katunayan! Ngunit pagkatapos ng katotohanan… Kapag malamang na huli na ang lahat kung ang elemento ay ginamit sa isang software build, at ang mga masasamang aktor ay nakakuha na ng puwesto sa isang developer o CI/CD host. Maaaring na-exfiltrate ang mga sikreto, na-download at na-install ang karagdagang malware, at marahil ay gumalaw nang pahilig ang kalaban at nakakuha na ng access sa ibang lugar.
Pagsusuri ng Komposisyon ng Software (SCA) ay dinisenyo upang matukoy ang mga potensyal na kilalang kahinaan. Mahusay ang ginagawa ng mga modernong kagamitan sa pamamagitan ng pagpapahusay sa signal-noise ratio, na tumutukoy kung ang kahinaan ay talagang maaabot o magagamit. Ngunit wala silang silbi laban sa bagong malware. Isipin ang isang malisyosong bahagi bilang isang zero-day na kahinaan: Kapag natukoy lamang ang malisyosong pag-uugali nito, saka lamang iniuulat ang bahagi sa holding registry, na pagkatapos ng pagsusuri ng isang security team ay kinukumpirma bilang malisyoso at inalis mula sa registry. [1].
Sa puntong iyon, ang mundo (kabilang ang SCAAlam ni s) na ang pag-install o paggamit ng component (o ilang bersyon ng isang umiiral na component) ay hindi isang magandang bagay. Ngunit ito ay kapag ang component ay hindi magagamit mula sa registryMabuti na malaman na mayroon akong mga kahinaan sa mga third-party na bahagi, o kahit na mga bahagi na ikinategorya bilang malisyoso ng registry, ngunit sa kasamaang palad SCA o ang mga karaniwang tool sa pag-audit ay hindi nakakatulong sa kontekstong ito. Maliban sa SCAAng /audit tool ay talagang makakaalam nang maaga na ang isang component ay malisyoso bago pa man ito gamitin sa iyong organisasyon.
Tandaan, dapat matukoy ng anumang solusyon laban sa mga malisyosong open-source na bahagi ang mga ito. on-the-fly, sa pagitan ng kung kailan nailathala ang component sa registry at kung kailan unang ginamit ang component (bersyon) sa iyong organisasyon. At kabilang dito ang mga transitive component.
Maling Akala #2: Ang pagkontrol sa mga script ng pag-install sa oras ng pagbuo ay pumipigil sa malisyosong pag-uugali mula sa mga open-source na bahagi
Nag-aalok ang iba't ibang package manager ng kakayahang magpatakbo ng mga script (kasama sa component na tarball [2]), para sa mga lehitimong dahilan, tulad ng pag-compile ng mga kinakailangang item sa iba't ibang platform, pagbuo ng code, o pagpapatakbo ng mga pagsubok, at dapat nating malaman na maaari itong abusuhin ng masasamang aktor kung ang mga malisyosong script ay kasama sa tarball, o kung ang attacker ay maaaring magpagana ng isang malisyosong script sa halip na ang mabuti.
Dahil dito, maaari nating i-configure ang package manager para hindi pansinin ang mga script. Halimbawa, sa NPM ang –Hindi pansinin-ang mga script bandila (o isang katangian ng pagsasaayos sa .npmrc file) ay nilalaktawan ang mga script habang ini-install. Maaari itong magdulot ng ilang isyu dahil karaniwan ang pagpapatakbo ng mga script sa maraming ecosystem: Hindi pinapayagan ng ilang package manager ang pag-disable ng script execution (pahiwatig: prompt "Aling mga package manager ang hindi nagpapahintulot sa pag-disable ng execution ng mga install script?"sa paborito mong AI). Ngunit hindi nito pinoprotektahan sa pangkalahatan (kailangan nating ipatupad na ang skip disable configuration ay nasa lahat ng dako).
At kapag ang malisyosong pag-uugali ay wala sa mga install script kundi sa software na isasagawa habang tumatakbo, ang opsyong ito lamang ay hindi tayo mapoprotektahan.
Maling Akala #3: Pinipigilan ng pag-pin ng bersyon ang pag-install ng mga malisyosong bahagi
Mayroong kompromiso sa pagitan ng maagang pag-patch at madalas na paggamit ng mga bukas na bersyon (nagpapahintulot sa package manager na awtomatikong mag-install ng mga bagong update kapag available para sa mga pag-aayos sa seguridad) at pag-pin ng bersyon (mayroon ng lahat ng direkta at palipat na dependency para sa isang software sa isang nakapirming bersyon). Ang mga prinsipyo ng seguridad ay matigas ang ulo at kung minsan ay magkasalungat, tulad ng nangyayari sa "patch nang maaga, patch nang madalas" at "Hindi dapat ipagwalang-bahala ang pag-upgrade"Ang ilang mga package manager ay gumagawa ng mga awtomatikong pag-update gamit ang mga saklaw ng server sa inirerekomendang paraan. Mahusay kung gusto mo ring makatanggap ng mga malisyosong update! Oo, dapat i-update ang mga component upang makatanggap ng mga pag-aayos sa seguridad na nagsasara ng mga kahinaan sa lalong madaling panahon, ngunit ... huwag hayaang awtomatikong gawin ito ng package manager.
Maling Akala #4: Ligtas ang paggamit ng mga pinagkakatiwalaang bahagi. Anumang malisyosong bersyon ay agad na mahahanap, ibubunyag, at aalisin.
Bakit pinagkakatiwalaan ang isang component? Posible dahil ito ay lubos na popular, na may maraming eyeball na naghahanap ng mga kahinaan, isang malaking bilang ng mga kontribyutor para sa maintenance, na may maraming core maintainer na masigasig na sinusuri ang lahat pull requests. Iba ang realidad. Ang ilang mahahalagang bahagi ay pinapanatili ng iisang developer na walang bayad. Malawakang ginagamit na mga framework ang ilang regular na kontribyutor, na may mabilis na pagbaba ng bilang ng commits bawat tagapanatili (ang mga sikat na proyekto ay may mahabang hanay ng mga kontribyutor na nagsasagawa ng ilang drive-by commit at hindi na babalik). At napakarami ng mga sikat na proyekto na iisa lang ang tagapangalaga.
Isipin mo ang iyong sarili na nagsasabing "Ah, gumagamit kami ng Spring Boot / Angular / React / PyTorch / opisyal na base na mga imahe ng Docker, kaya medyo mababa ang panganib na tinutukoy mo." Marahil totoo iyan, kaming mga security vendor ay laging nananakot, at ang pakikialam sa mga development team upang mabawasan ang isang maaaring pagtalunan na panganib ay kalokohan. Maaari kang matukso na tumalon sa talata ng pagtanggap ng panganib (sa susunod na seksyon) at tapos na ang lahat. Sa kasamaang palad, ang mga pinakasikat na bahagi ay mga target para sa masasamang aktor, at halimbawa, ang sikat Inatake ang library ng PyTorch sa nakaraan.
"Agad na natagpuan, isiniwalat, at inalis". Inaabot ng ilang araw bago maalis ang isang bagong malisyosong component mula sa pampublikong registry. Maingat ang mga registry sa pag-alis ng isang bersyon ng component, para sa ikabubuti nito. Ayon sa aming karanasan, kapag naiulat na ito mula sa amin, ang median na oras para maalis ng registry ang apektadong bersyon ay 39 na oras, mahigit sa isang araw at kalahati. May mga malisyosong component na isang linggo pagkatapos ng aming unang pag-uulat sa registry bago maalis. At sa ilang mga kaso, ang component ay inaalis lamang pagkatapos mag-ulat ang isang biktima o isang kumpanya ng pagtugon sa insidente ng isang insidente na kinasasangkutan ng component.
Ano ang HINDI Gumagana Laban sa mga Malisyosong Bahagi
Anumang hindi tiyak na pamamaraan ay lubos na mabibigo. Ito ay isang katiyakan, hindi ka nagbibigay ng mabisang mga panlaban para sa panganib na kaugnay ng bantang ito.
Tradisyonal SCA Sinasabi sa iyo ng mga tool ang tungkol sa kilalang malware ngunit mayroon silang malaking exposure window. Maliban na lang kung proactive silang nagsasagawa ng pagtukoy ng malware sa pamamagitan ng sapilitang pagharang sa mga malisyosong bahagi, hindi sila gumagana laban sa banta na ito.
Maaaring makatulong ang pag-disable ng mga installation script ngunit kailangang ipatupad ito sa lahat ng lugar na kailangang i-install ang isang component. Ganito rin sa pag-pin ng bersyon, dahil hindi maaaring i-pin ang mga bersyon mula sa isang ligtas na panimulang estado magpakailanman.
Ang pag-aakalang ang mga sikat na bahagi ay nakakakuha ng sapat na atensyon na hindi maaaring mabigyan ng hindi sinasadyang pag-uugali sa isang pag-atake sa supply chain nang walang halos agarang pagtuklas upang maiwasan ang anumang pinsala ay isang inosente at mapanganib. Hindi mo gugustuhing mabuhay sa bingit, hindi ba?
Kung titigil ka sa puntong ito, kung gayon pagtanggap sa panganib ay ang tanging bagay na magagawa mo: Ito ay isangcision na kailangang idokumento sa iyong modelo ng banta/pagtatasa ng panganib, kabilang ang katwiran para sa pagtanggap ng panganib at mga potensyal na implikasyon nito. Itaas ang kamalayan sa pamamagitan ng pagpapabatid nito sa pamamahala at iba pang mga kaugnay na partido. Ang ilan kawalang-hanggan maaaring planuhin kapag ang isang malisyosong bahagi ay naka-install o kasama sa iyong software, ngunit mahirap ito dahil ang mga umaatake ay maraming landas na dapat tahakin. Ang mga detalye ng isang pag-atake sa supply chain batay sa paggamit ng isang malisyosong bahagi ay lubhang magbabago sa pampublikong pagsisiwalat ng insidente, na marahil ay mandatory sa ilalim ng balangkas ng regulasyon ng iyong organisasyon. Maaari mo ring tugunan mga kontrol sa pagbabayad or panganib sa paglipat hal. may insurance.
Gayunpaman, may mga kontrol na tumutugon sa banta at dapat isaalang-alang kung hindi ka nasiyahan sa pagtanggap sa panganib. Pakibasa pa.
Ano ang Gumagana Laban sa mga Pag-atake Gamit ang mga Malicious Component
Matibay na Paghawak ng Bersyon
Ang pag-pin ng bersyon gamit ang kontrolado at may kaalamang mga version bump ang dapat gawin, upang balansehin ang pangangailangang alisin ang mga kahinaan nang hindi nakakatanggap ng malware. Ngunit tandaan ang maling akala #3: Ang pag-pin ng bersyon lamang ay hindi sapat upang harangan ang malisyosong code na nagmumula sa mga bagong bersyon, dahil kakailanganin mo sa hinaharap na i-update ang mga bersyon sa anumang direkta o hindi direktang dependency. Sa sandaling iyon, kailangan mo ng sapat na matibay na ebidensya upang ang lahat ng binagong bersyon ay hindi naglalaman ng malware.
Maagang Babala
Ang isang paraan upang matugunan ang problema ng mga malisyosong bahagi ay ang isang early warning system (pinangalanan dito bilang Maagang Babala sa Malware o MEW), kung saan ang mga bagong bersyong inilathala (para sa mga bago o umiiral na mga bahagi) ay sinusuri ng isang detection engine, na kapag may sapat na ebidensyang natagpuan ay maaaring uriin ang bagong bersyon bilang potensyal na nakakahamak.
Mahalaga ang automation dito, dahil imposibleng manu-manong suriin ang lahat ng mga bagong bahagi sa kasalukuyang bilis ng paglalathala. Kaya kailangang pagsamahin ng detection engine ang iba't ibang pamamaraan, marahil kabilang ang static, dynamic, at capability analysis, reputasyon ng user, at ebidensya na nagmumula sa mga pagkakaiba sa pagitan ng metadata ng bahagi at ng mga nilalaman ng tarball, o sa pagitan ng tarball at ng source repository kung saan umano nagmula ang bahagi.
May ay isang madilim na sona sa pagitan ng oras ng paglalathala at kapag sinusuri ng engine ang mga nilalaman ng bahagi, ngunit hindi ito dapat lumagpas sa ilang minuto. Maaaring baguhin ang iskema, halimbawa sa pamamagitan ng paghihintay na masuri ang mga bagong bahagi bago payagang mai-install at magamit ang mga ito sa pagbuo ng software. pipelines, o suriin ang mga ito kapag kinakailangan. Ang isang bahagi sa isang partikular na bersyon ay hindi mababago [3], kaya kailangan itong suriin nang isang beses lamang.
Hindi posible ang ganap na automation, at kinakailangan ang isang pagsusuri sa seguridad para sa mga potensyal na mapaminsalang bahagi. Mag-ingat sa mga tagapagtaguyod ng digital na lunasAng AI at Machine Learning ay hindi pa sapat ang pagkakabuo para maging huling salita pagdating sa pagkumpirma kung ang isang pinaghihinalaang bahagi ay may malware. Oo nga, ang machine learning ay may mahalagang papel sa detection engine sa pag-uuri ng input component mula sa mga nakuhang hilaw na ebidensya, ngunit kapag ang bahagi ay "na-quarantine," ang huling salita ay nasa manu-manong pagsusuri ng isang security team na may karanasan sa mga malisyosong bahagi. Kinukumpirma nito ang anumang potensyal na malware o muling inuuri ito bilang ligtas. At ang tagal ng panahon ay nasa hanay ng oras.
Ang registry ay nag-uulat tungkol sa malisyosong bersyon/bahagi; pagkatapos ay isinasagawa ng registry ang pagsusuri nito upang kumpirmahin at magpapatuloy sa pampublikong pagsisiwalat at pag-alis mula sa registry. Ang ilang mga registry ay nagpapanatili ng isang pakete ng security holding. Ang saklaw ng oras dito ay ang mga araw o linggo mula noong publikasyon, na siyang 'tumira oras'o'bintana ng pagkakalantad' para sa karamihan ng mga mapaminsalang bahagi.
Posible bang malaman kung ang isang bersyon ng bahagi ay malisyoso?
Kaya para sa maagang babala, kailangan nating magbigay ng kasiya-siyang sagot sa tanong na ito: Paano ko malalaman na ang isang library o package ay (hindi) malisyoso? Paano makakalap ng sapat na ebidensya ng malisyosong pag-uugali? Posible, ngunit mahirap, dahil ang mga kalaban ay gumagamit ng labis na talino upang maiwasan ang pagtuklas. Mayroong iba't ibang mga pamamaraan, bawat isa ay may mga kalamangan at kahinaan.
Static na pagsusuri maaaring suriin ang lahat ng execution path, suriin ang mga pamamaraan na ginagamit ng mga attacker nang hindi pinapatakbo ang component, at magsagawa ng mga preprocessing task tulad ng de-obfuscation o deciphering. Habang sinusubukan ng mga attacker na itago ang kanilang kalokohan, ang mga pagtatangka sa obfuscation ay talagang ebidensya ng malware (ngunit tandaan na ang mga lehitimong component ay nagpapalabo sa code para sa pagpapanatili ng intelektwal na ari-arian, na sumasalungat sa "open source"). Iilang bulto lamang ng mga sopistikadong pag-atake na may matinding obfuscation ang nangangailangan ng sandboxing, ngunit ang gayong matinding obfuscation ay isang palatandaan ng malisya. Pakitandaan na ang kumbensyonal SAST Ang mga tool ay dinisenyo para sa mga hindi sinasadyang kahinaan, hindi para sa malisyosong layunin tulad ng mga backdoor.
Dynamic na pagsusuri Pinapatakbo ang component at sinusuri ang tugon sa pamamagitan ng pag-instrument sa runtime, kadalasan sa pamamagitan ng pagbibigay ng sandboxed environment. Ang malisyosong pag-uugali na na-trigger sa ilalim ng ilang partikular na kundisyon ay maaaring hindi matukoy: pakitandaan na ang malware ay maaaring gumamit ng mga diskarte sa pag-iwas tulad ng Virtualization/Sandbox Evasion para lamang i-activate kapag hindi sinusuri, at isa ring senyales ng malisyosong aktibidad para sa anumang static analysis engine.
Pagsusuri ng mga kakayahan isinasaalang-alang kung ano ang ginagawa ng component: kung saan ito kumokonekta, kung aling mga file ang ina-access nito, kung aling mga command o programa ang pinapatakbo, ang terminal o device I/O na isinasagawa, o kung aling mga system call ang ginagamit. Ang fingerprinting na ito ng kilos ay maaaring ihambing (para sa isang umiiral na component) sa iba't ibang bersyon, kaya kapag natukoy ang hindi inaasahang kilos, ang ebidensyang iyon ay maaaring magdulot ng hinala sa potensyal na malisyosong aktibidad na ipinasok sa bagong bersyon. Sinusundan ng pamamaraang ito ang mga hakbang sa triage na sinusunod ng mga security analyst kapag nahaharap sa potensyal na malware: isang inspeksyon gamit ang string o mga katulad na tool. Natutukoy ng pamamaraang ito ang malisyosong pag-uugali anuman ang mga kondisyon ng pag-trigger at gumagana kapag walang magagamit na source code.
Pagsusuri ng konteksto Nangongolekta ng impormasyon tungkol sa kung paano inilathala ang bahagi at kung sino ang naglathala. Ang mga kampanya ng masasamang aktor ay kadalasang gumagamit ng mga bagong user account na hindi sumasailalim sa anumang mahigpit na proseso ng pagsusuri. Ang pagsubaybay sa nakaraang aktibidad ay maaaring magbigay ng mga insight sa pinagbabatayan na user, kadalasan para sa mga anomalya na maaaring magpahiwatig ng isang potensyal na kompromiso. Napakahirap kumita ng reputasyon at napakadaling mawala! Ang isang user na walang nakaraang aktibidad ay neutral, ngunit ang karma ay humahabol sa masasamang loob. Ang mga hacktivist, o mga normal na user na ninakaw ang kanilang mga kredensyal sa pag-publish, ay dapat na maingat na subaybayan.
Ang isa pang impormasyong kontekstwal ay ang anumang pagkakaiba sa pagitan ng source repository na sinasabing ginamit upang likhain ang component tarball at ang mga nilalaman ng tarball mismo. At ang pagsunod din sa mga mabubuting kasanayan, tulad ng paglikha ng mga tag o release sa source repository na tumutugma sa mga bersyon ng component na inilathala sa pampublikong rehistro. Kapag ang source repository sa isang partikular na commit ay may tag na release, at pagkatapos ay biglang may isang bersyon na hindi sumunod dito, iyon pa lamang ay matibay na ebidensya na maaaring nadungisan ang component: maaaring nakompromiso ng masamang aktor ang account na ginamit para sa pag-publish ng component, ngunit walang mga pahintulot sa pagsulat sa source code repository). Maraming pag-atake ang karaniwang natutukoy gamit ang mga panuntunang ito: halimbawa, ang Pag-atake ng Ledger madaling matukoy sa ganitong paraan. Samakatuwid, natutukoy ng pagsusuri ng konteksto ang mga ganitong anomalya sa proseso ng paglalathala.
Firewalling ng Dependency
Ang ibang paraan ay ang pagkakaroon ng komprehensibong whitelist ng mga bahagi para sa lahat ng dependency graph na ginagamit sa iyong software, para sa anumang build pipeline patakbuhin sa iyong organisasyon, tanging ang mga aprubadong bersyon ng component lamang ang maaaring i-install at gamitin. Ang "pader laban sa sunog"ay ipinapatupad gamit ang isang internal registry kung saan ang mga tarball para sa mga pinapayagang bersyon ng component ay inihahain (naka-cache o naka-proxy). Pakitandaan na ang anumang whitelist ay hindi gagana maliban kung mayroon kang teknolohiya para sa pag-uuri ng anumang bagong bersyon bilang makatwirang ligtas upang maidagdag ito sa whitelist.
Pakitandaan na ang maagang babala (mabilis na pagtuklas sa lalong madaling panahon pagkatapos mailathala ang bagong bersyon) ay kailangang pagsamahin sa ilang paraan upang magamit ang impormasyong iyon nang maagap upang harangan ang bahaging nakakaapekto sa build. pipelinemga makina ng mga developer [4]Tinatawag namin itong “firewall para sa dependency": isang mekanismo ng kuwarentenas para sa pagprotekta sa mga automated build mula sa mga malisyosong pakete. Ang mga panloob na pakete at mga registri ng imahe ay mahusay upang protektahan ang mga organisasyon mula sa panlabas na kasamaan, ngunit kinakailangan ang sapat na matibay na ebidensya upang maging epektibo ang kuwarentenas.
Sandboxing sa Oras ng Pagtakbo
Ang alternatibong paraan para sa pagtuklas sa oras ng paglalathala ay ang pagsusuri ng kilos sa oras ng pagpapatakbo. Ang ideya ay makuha ang inaasahang kilos mula sa software at matukoy (o harangan) ang anumang mga anomalya na matatagpuan. Ang linyang ito ng aksyon ay may problema sa pagkakaroon ng instrumento sa oras ng pagpapatakbo para sa pagsubaybay o pagharang, at ito ay isang promising na ideya na idadagdag sa arsenal ng mga mekanismo ng proteksyon laban sa malisyosong peste ng bahagi.
Pagtatakda ng Komprehensibong Istratehiya
Kailangang pagsamahin ng inirerekomendang estratehiya ang iba't ibang pamamaraan sa proseso ng pagbuo ng software, na kontrolin ang mga pag-update ng bersyon upang harangan ang mga papasok na malisyosong bahagi. Dapat nating pagbigyan ang pag-pin ng bersyon upang maiwasan ang awtomatikong impeksyon sa pamamagitan ng pag-update ng mga bersyon upang makakuha ng mga pag-aayos para sa mahahalagang kahinaan; isang mabilis at mahusay na pagtatasa ng direkta at hindi direktang mga dependency sa panahon ng mga pag-update ng bersyon upang magkaroon ng sapat na ebidensya na hindi sila puno ng malware. Ang mga build ng software na umaasa sa mga kilalang malisyosong bahagi ay dapat harangan. At lahat ay dapat ipatupad.
Gamitin ang version pinning, kung maaari, dahil ginagawa nitong mas madaling kopyahin ang mga build. Pag-pin ng bersyon gamit ang kontrolado at manu-manong inaprubahang mga bump ng bersyon, at tinutulungan ng teknolohiyang pantulong, dapat suriin kung ang update ay may dala na malware o sumisira sa software, at pagtugmain ang pag-update para sa pag-aayos ng mga kahinaan sa pag-iwas sa impeksyon ng malware. Makakatulong dito ang tooling, sa pamamagitan ng (1) pagbibigay-priyoridad kung aling mga kahinaan ang talagang mahalaga (maaabot at magagamit, na may mataas na panganib na ma-target ng mga umaatake), (2) pagpili ng mga target na bersyon na tugma sa kasalukuyang paggamit ng component at hindi sumisira sa software, (3) pagpili ng mga target na bersyon na walang malisyosong pag-uugali, at (4) paggawa ng pag-update ng bersyon para sa direkta at hindi direktang mga dependency nang mabilis, sa pamamagitan ng pagmumungkahi ng mga pagbabago sa mga manifest file na maaaring mabilis na maaprubahan. Ang hakbang (3) ay nangangailangan ng tiyak na impormasyon tungkol sa mga malisyosong bahagi na malapit sa kanilang oras ng paglalathala hangga't maaari.
Ang prosesong ito ng pag-update ng mga dependency ay dapat ipinatupad at napatunayan na sa lahat ng lugar. Dapat idokumento ang proseso, at dapat sanayin ang lahat ng partidong kasangkot, dahil kadalasan ang pagbuo at pagbuo/pag-deploy ng software ay inilalabas sa labas. Ang CI/CD pipelineDapat baguhin nang naaayon ang s, para hindi makapasok sa build ang isang malisyosong indirect dependency dahil sa automation: guardrails Ang inirerekomendang paraan ay ang pagharang sa build kung mayroong sapat na ebidensya ng potensyal na malware sa isang dependency.
Kung ang iyong organisasyon ay may internal registry na nagsisilbing security proxy para sa pag-iingat ng mga pinapayagang bersyon ng component, dapat kang kumuha ng impormasyon tungkol sa mga malisyosong component (bukod sa iba pang pamantayan) para sa pagsusuri sa isang hiniling na component bago ito idagdag sa allowance list.
Hindi madaling gamitin ang open-source software nang may kaligtasan, at ang salik ng malware ay dapat na lubos na isaalang-alang, na may katulad na pagsisikap na gagawin sa paghawak ng mga kahinaan.
Isang huling tala: Pinagmulan, sa anyo ng mga pagpapatunay ng software, na nabuo sa oras ng pagbuo ng component, ay isa pang mahalagang bahagi sa pagsisikap na masubaybayan ang artifact (component tarball) kasama ang mga source at proseso ng pagbuo na gumawa nito. Tandaan na ang ugnayan na ito sa pagitan ng source snapshot + build environment at ang nauugnay na software artifact (na nilagdaan ng pinagkakatiwalaang build system) ay hindi pumipigil mismo na ang component ay hindi naglalaman ng malisyosong pag-uugali, ngunit ginagawang mas mahirap para sa mga kontrabida na magpasok ng malware. At ang paggawa ng provenance validation bilang isang karaniwang kinakailangan para sa pagkonsumo ng mga open source na component ay aabutin ng mahabang panahon, at tanging kamakailan lamang idinagdag sa NPMAng paggawa ng mga pinagkakatiwalaang sistemang iyon na hindi tinatablan ng pakikialam, o pagpapagana ng pagtukoy ng anumang pakikialam sa build ay ibang usapan, na wala sa saklaw ng post na ito.
Higit pang pagbabasa
Ang susunod na episode Mga Open Source na Malicious Package: Ang Xygeni Approach ipapakita ang estratehiyang sinusunod namin sa Xygeni para sa aming Maagang Babala sa Malware (MEW) na sistema. Ang mga bagong bersyon ng pakete sa pampublikong pakete at mga rehistro ng imahe ay ini-scan at ang ebidensya ay kinukuha gamit ang kombinasyon ng static, dynamic, na kakayahan, at kontekstwal na pagsusuri. Ang ebidensya, kasama ang reputasyon ng gumagamit at ang kasaysayan ng mga pagbabago sa mga repositoryo ng source code, ay nagbibigay-daan para sa isang awtomatikong pag-uuri ng isang bahagi sa mga kategoryang may mataas na peligro at malamang na malisyosong. Natututo ang sistema mula sa mga nakaraang ebidensya na nakalap mula sa mga pakete upang mabawasan ang mga maling positibo sa pinakamababa.
Ang mga naka-subscribe na organisasyon ay makakatanggap ng babala para sa mga bahaging ginagamit nila, direkta man o hindi direkta, kapag ang isang malisyosong bersyon ay ikinategorya. Pagkatapos, isang manu-manong pagsusuri ang ginagawa ng aming mga analyst, na kumukumpirma o tumatanggi sa klasipikasyon. Para sa nakumpirmang malware, inaabisuhan ang pampublikong rehistro upang maisagawa nito ang sarili nitong pagsusuri at karaniwang alisin ang malisyosong bersyon o gumawa ng karagdagang aksyon, tulad ng pagharang o pag-alis ng pinag-uusapang user account.
Ipapaliwanag namin kung paano namin tinutulungan ang NPM, PyPI, GitHub, at iba pang mahahalagang imprastraktura sa open source ecosystem na mabawasan ang dwell time kung saan ang isang bagong malisyosong component na inilathala ay mananatiling aktibo hanggang sa ito ay makumpirmang malware at maalis sa registry. At kung paano makikinabang ang mga organisasyon mula sa MEW system upang magkaroon ng mas mahusay na proteksyon laban sa mga pag-atake sa supply chain ng software na kinasasangkutan ng mga open source component.
- [1] Gayunpaman, kailangang suriin ng mga gumagamit ng component kung ang component tarball ay naka-cache o nakarehistro sa isang lugar, halimbawa sa isang internal registry, upang maalis ang sakit.
- [2] Kasama sa naka-package na component ang isang manifest na nagdedeklara ng mga nilalaman at metadata nito, source o compiled code, mga installation script, at mga karagdagang item tulad ng mga test suite, ayon sa isang packaging format at karaniwang nasa compressed form. Ito ay tinatawag na "component tarball".
- [3] Kahit na mabago ng malisyosong aktor ang isang nai-publish na component dahil sa isang paglabag sa mismong registry, maaaring matukoy ng isang simpleng cryptographic digest ang anumang pagbabago sa tarball pagkatapos magawa ang pagsusuri.
- [4] Tandaan na ang ilang malisyosong bahagi ay tumatakbo sa oras ng pag-install, kaya maaari nitong maapektuhan ang mga developer node na hindi sinasadyang nagpapatakbo ng "npm install X" kung saan ang X ay isang malisyosong bahagi.
