Hau hirugarren atala da artikulu sorta software hornikuntza-kateko eraso mota ohikoenei buruz: erregistro publiko bat gaizki erabiltzen dutenak Kode irekiko software osagaiak. Aurreko atalean aztertu ondoren “Pakete gaiztoen anatomia: Zeintzuk dira joerak?"Eragile gaiztoek nola txertatzen duten portaera gaiztoa argitaratutako osagai berrietan edo lehendik daudenetan, prest gaude suhiltzaileen jakak janzteko eta modu honetan bidalitako software gaiztoa nola blokeatu dezakegun aztertzeko, edo, bestela, ziberintzidente larri bati nola aurre egin diezaiokegun ikuspegi okerra hartu dugulako."
Segurtasun-arloko profesional gehienek badute mehatxu honi nola aurre egin. Segurtasun-arduradunek zalantzarik gabe esaten entzun ditugu SCA tresnek dagoeneko esaten dizute noiz den pakete bertsio bat malwarea. Edo software osagai ezagun eta oso berrikusietan oinarritzen direla, non edozein malware berehala detektatu eta kenduko litzatekeen. Bertsio txiki/adabaki irekiak erabiltzen dituzte ahultasun konponketak automatikoki lortzeko, eta hori da kode irekiko menpekotasunen arriskua murrizteko modu egokia eta gomendatua, "" jarraituzadabaki goiz, adabaki maiz”Printzipioa.
Atal honetan, ideia hauek zergatik diren okerrak aztertuko dugu, eta nola ideia oker horiek eraso-mekanismo honen ospea eta erakundeek jasaten duten arrisku izugarria eragiten duten. Amaitzeko, zerk funtzionatzen duen eta zein den beharrezkoa den ahalegina eta baliabideak aztertuko ditugu.
Ohizko okerrak
Softwarearen segurtasunarekin dugun bidaian zehar, eraso teknikak eboluzionatzen ikusi ditugu eta segurtasunaz arduratzen diren pertsonen ideia ugari. Erakundeek askotan gaizki ulertzen dute zerk funtzionatzen duen mehatxu honen aurka, beraz, lehenik eta behin, zerk ez duen funtzionatzen aztertuko dugu, ondorengo ideia okerren zerrenda ez-osoan laburbilduta.
1. ideia okerra: SCA Tresnek dagoeneko osagai gaiztoak salatzen dituzte
Hain zuzen ere! Baina gertaeraren ondoren… Elementua software eraikuntza batean erabili bada eta gaizkileek dagoeneko oinarri bat hartu badute garatzaile edo CI/CD ostalaria. Sekretuak atera, malware gehigarria deskargatu eta instalatu ahal izan da, eta agian etsaia alboetara mugitu eta beste nonbait sarbidea lortu du.
Softwarearen Konposizioaren Azterketa (SCA) tresnak balizko ahultasun ezagunen identifikazioa egiteko diseinatu ziren. Tresna modernoek lan bikaina egiten dute seinale-zarata erlazioa handituz, ahultasuna benetan eskuragarri edo ustiagarria den zehaztuz. Baina alferrikakoak dira malware berriaren aurka. Pentsa ezazu osagai gaizto bat zero eguneko ahultasun gisa: bere portaera gaiztoa detektatzen denean bakarrik jakinarazten zaio osagaia erregistroari, eta segurtasun-talde batek berrikusi ondoren, gaiztoa dela baieztatzen da eta erregistrotik kentzen da. [1].
Une horretan, mundua (barne) SCAs)-ek badaki osagaia (edo dagoeneko dagoen osagai baten bertsio batzuk) instalatzea edo erabiltzea ez dela gauza ona. Baina hori gertatzen da osagaia erregistroan eskuragarri ez dagoenean.Hirugarrenen osagaietan ahultasunak ditudala jakitea, edo erregistroak gaiztotzat sailkatutako osagaietan ere, ona da, baina zoritxarrez SCA edo ohiko auditoria-tresnek ez dute laguntzen testuinguru honetan. Besterik ezean SCA/audit tresnak aldez aurretik jakin dezake osagai bat gaiztoa dela zure erakundean erabili aurretik.
Gogoratu, kode irekiko osagai gaiztoen aurkako edozein irtenbidek detektatu egin behar dituela. hegaldian, osagaia erregistroan argitaratzen denetik osagaia (bertsioa) zure erakundean lehen aldiz erabiltzen den arte. Eta horrek osagai trantsitiboak barne hartzen ditu.
2. ideia okerra: Instalazio-gidoiak eraikuntza-garaian kontrolatzeak kode irekiko osagaien portaera gaiztoa saihesten du
Pakete kudeatzaile askok script-ak exekutatzeko aukera eskaintzen dute (osagaien tarball-ean sartuta) [2]), arrazoi legitimoengatik, hala nola, beharrezko elementuak plataforma desberdinetan konpilatzea, kodea sortzea edo probak egitea, eta denok jakin beharko genuke gaizkileek gehiegi erabili ditzaketela tarball-ean script gaiztoak sartzen badira, edo erasotzaileak script gaizto bat exekutaraz badezake onaren ordez.
Hau jakinda, pakete kudeatzailea konfigura dezakegu script-ak alde batera uzteko. Adibidez, NPM-rekin –ignore-script-ak bandera (edo konfigurazio-propietate bat .npmrc fitxategia) scriptak saltatzen ditu instalazioan zehar. Honek arazo batzuk sor ditzake, scriptak exekutatzea ohikoa baita ekosistema askotan: Pakete kudeatzaile batzuek ez dute scriptaren exekuzioa desgaitzen uzten ere (aholkua: gonbita "Zein pakete kudeatzailek ez dute instalazio script-en exekuzioa desgaitzen uzten?"zure IA gogokoenean). Baina honek ez du babesten orokorrean (saltatu desgaitzeko konfigurazioa nonahi egotea betearazi behar dugu).
Eta portaera gaiztoa instalazio-skriptetan ez dagoenean, baizik eta exekuzio-garaian exekutatzeko softwarean, aukera honek bakarrik ez gaitu babesten.
3. ideia okerra: Bertsio finkatzeak osagai gaiztoak instalatzea eragozten du
Ordainketa bat dago goiz adabakitzea eta maiz egitearen artean bertsio irekiak (pakete kudeatzaileari segurtasun konponketak eskuragarri daudenean eguneratze berriak automatikoki instalatzeko aukera emanez) eta bertsioa finkatzea (software baten menpekotasun zuzen eta trantsizional guztiak bertsio finko batean edukita). Segurtasun-printzipioak tematiak eta batzuetan kontrajarriak dira, "lehenago adabakitu, maiz adabakitu" eta "Berritzea ez da arin hartu behar"Pakete kudeatzaile batzuek zerbitzari-barrutiekin automatikoki eguneratzen dituzte gomendatutako moduan. Bikaina eguneratze gaiztoak ere jaso nahi badituzu! Bai, osagaiak eguneratu behar dira ahultasunak ahalik eta azkarren ixten dituzten segurtasun-konponketak jasotzeko, baina... ez utzi inoiz pakete kudeatzaileari hau automatikoki egiten.
4. ideia okerra: Osagai fidagarriak erabiltzea segurua da. Edozein bertsio gaizto berehala aurkitu, zabaldu eta kenduko litzateke.
Zergatik da fidagarria osagai bat? Agian oso ezaguna delako, ahultasunak bilatzen dituzten begi asko dituelako, mantentze-lanetarako kolaboratzaile asko dituelako, eta guztiak arduraz berrikusten dituzten hainbat mantentzaile nagusi dituelako. pull requestsErrealitatea oso bestelakoa da. Osagai funtsezko batzuk garatzaile bakar eta ordaindu gabeko batek mantentzen ditu. Oso erabilitako framework-ek... ohiko kolaboratzaile batzuk, kopurua azkar gutxitzen ari den bitartean commits mantentzaile bakoitzeko (proiektu ezagunek laguntzaile isats luzea dute, eta horiek gidari-lan batzuk egiten dituzte) commit eta ez itzultzeko). Eta mantentzaile bakarra duten proiektu ezagunak ugariak dira.
Imajinatu zeure burua esaten «A, Spring Boot / Angular / React / PyTorch / Docker oinarrizko irudi ofizialak erabiltzen ari gara, beraz, aipatzen ari zaren arriskua nahiko txikia da.» Agian hori egia da, gu, segurtasun saltzaileok, etengabe beldurra zabaltzen dugu, eta garapen taldeetan esku hartzea arrisku eztabaidagarri bat arintzeko zentzugabekeria da. Arriskuen onarpenari buruzko paragrafora (hurrengo atalean) salto egiteko tentazioa izan dezakezu eta kitto. Zoritxarrez, osagai ezagunenak gaizkileen jomuga dira, eta adibidez, ezagunak... PyTorch liburutegia erasotua izan da iraganean.
"Berehala aurkitu, agerian utzi eta kendu". Egunak behar dira osagai gaizto berri bat erregistro publikotik kentzeko. Erregistroak kontuz ibiltzen dira osagaien bertsio bat kentzerakoan, betiko. Gure esperientziak dioenez, gure aldetik jakinarazi ondoren, erregistroak kaltetutako bertsioa kentzeko batez besteko denbora 39 ordukoa da, egun eta erdi baino gehiago. Badira erregistroan hasierako txostena egin eta astebetera kendu aurretik dauden osagai gaiztoak. Eta kasu batzuetan, osagaia biktima batek edo intzidenteei erantzuteko enpresa batek osagaiarekin lotutako intzidente baten berri eman ondoren bakarrik kentzen da.
Zerk EZ du funtzionatzen osagai gaiztoen aurka
Edozein ikuspegi zehaztugabe huts egingo du latz. Hau ziurra da, ez dituzu mehatxu honekin lotutako arriskuaren aurkako neurri eraginkorrik ematen.
Ohizko SCA Tresnek malware ezagunen berri ematen dizute, baina esposizio-leiho handia dute. Malwarearen detekzioa proaktiboki egiten ez badute osagai gaiztoen blokeoa behartuta, ez dute mehatxu honen aurka funtzionatzen.
Instalazio-gidoiak desgaitzeak lagun dezake, baina osagai bat instalatu behar den leku guztietan betearazi behar da. Gauza bera gertatzen da bertsioen finkatzearekin, bertsioak ezin baitira hasierako egoera seguru batetik betiko finkatu.
Osagai ezagunek arreta nahikoa jasotzen dutela, eta, ondorioz, hornidura-kateko eraso batean nahi gabeko portaerarik ez dutela injektatu ahal izateko, ia berehalako detekziorik egin gabe, kalteak saihesteko, inozoa eta arriskutsua da. Ez duzu mugan bizi nahi, ezta?
Puntu honetan gelditzen bazara, orduan arriskuen onarpena egin dezakezun gauza bakarra da: Hau de bat dacismehatxu ereduan/arriskuen ebaluazioan dokumentatu behar den ioa, arriskua onartzeko arrazoia eta haren ondorio potentzialak barne. Kontzientziazioa areagotu zuzendaritzari eta beste alderdi garrantzitsuei jakinaraziz. Batzuk kontingentzia Osagai gaizto bat instalatzen edo zure softwarean sartzen denean planifikatu daiteke, baina zaila da erasotzaileek bide asko jarraitu behar dituztelako. Osagai gaizto baten erabileran oinarritutako hornidura-katearen eraso baten xehetasunek izugarri aldatuko dute gertakariaren dibulgazio publikoa, eta hori ziurrenik derrigorrezkoa da zure erakundearen araudi-esparruaren arabera. Baliteke ere jorratzea konpentsazio-kontrolak or transferentzia arriskua adibidez, aseguruarekin.
Hala ere, mehatxuari aurre egiten dioten kontrolak daude eta kontuan hartu beharko zenituzke arriskuen onarpenarekin pozik ez bazaude. Jarraitu irakurtzen.
Zerk funtzionatzen du osagai gaiztoak erabiltzen dituzten erasoen aurka?
Bertsio Solidoen Kudeaketa
Bertsioen finkatzea, bertsio-igoera kontrolatu eta informatuekin, da bidea, malwarea jaso gabe ahultasunak kentzeko beharra orekatzeko. Baina gogoratu 3. ideia okerra: bertsioen finkatzea ez da nahikoa bertsio berrietatik datorren kode gaiztoa blokeatzeko, etorkizunean edozein mendekotasun zuzen edo zeharkako bertsioak eguneratu beharko dituzulako. Une horretan, ebidentzia sendoa behar duzu aldatutako bertsio guztiek malwarerik ez dutela ziurtatzeko.
Abisu goiztiarra
Osagai gaiztoen arazoari aurre egiteko modu bat alerta goiztiarreko sistema bat da (hemen honela izendatua) Malwarearen abisu goiztiarra edo MEW), non argitaratutako bertsio berriak (osagai berri edo lehendik daudenentzat) detekzio-motor batek aztertzen dituen, eta nahikoa froga aurkitzen denean bertsio berria potentzialki gaiztotzat sailka dezake.
Automatizazioa ezinbestekoa da hemen, egungo argitalpen-erritmoan osagai berri guztiak eskuz berrikustea ezinezkoa baita. Beraz, detekzio-motorrak hainbat teknika konbinatu behar ditu, besteak beste, analisi estatikoa, dinamikoa eta gaitasun-analisia, erabiltzaileen ospea eta osagaien metadatuen eta tarball edukien arteko desadostasunetatik eratorritako frogak, edo tarballaren eta osagaia ustez datorren iturburu-biltegiaren artekoak.
Ez dago gune iluna argitalpen-orduaren eta motorrak osagaien edukia aztertzen duen arteko tartea, baina ez luke minutu batzuk baino gehiago izan behar. Eskema alda daiteke, adibidez, osagai berriak aztertu arte itxaronez, instalatu eta softwarearen eraikuntzan erabili aurretik. pipelines, edo eskaeraren arabera azter itzazu behar denean. Bertsio jakin bateko osagai bat aldaezina da [3], beraz, behin bakarrik aztertu behar da.
Automatizazio osoa ezinezkoa da, eta segurtasun-berrikuspena beharrezkoa da osagai gaiztoak izan daitezkeen ikusteko. Kontuz panazea digitalaren aldekoekinAdimen Artifiziala eta Makina Ikaskuntza ez daude nahikoa garatuta osagai susmagarri batek malwarea duen baieztatzeko azken hitza hartzeko. Noski, makina ikaskuntzak funtsezko zeregina du detekzio-motorrean sarrerako osagaia sailkatzeko, jasotako ebidentzia gordinetik abiatuta, baina osagaia "berrogeialdian" jartzen denean, azken hitza osagai gaiztoetan esperientzia duen segurtasun-talde batek eskuz berrikustea da. Horrek malware potentziala baieztatzen du edo seguru gisa berriro sailkatzen du. Eta denbora-tartea ordu gutxitan izaten da.
Erregistroak bertsio/osagai gaiztoaren berri ematen du; ondoren, erregistroak berrikuspena egiten du baieztatzeko eta publikoki ezagutzera eman eta erregistrotik kentzen du. Erregistro batzuek segurtasun-pakete bat mantentzen dute. Hemen denbora-tartea argitalpenaren ondorengo egunak edo asteak dira, hau da, 'egonaldi denbora'edo'esposizio leihoa' osagai gaizto gehienentzat.
Jakin al daiteke osagai baten bertsio gaiztoa den ala ez?
Beraz, alerta goiztiarra izateko, galdera honi erantzun asegarria eman behar diogu: Nola jakin dezaket liburutegi edo pakete bat (ez) dela gaiztoa? Nola bildu portaera gaiztoaren froga nahikoa? Posiblea da, baina zaila, aurkariek asmamen handia erabiltzen baitute detekzioa saihesteko. Hainbat ikuspegi daude, bakoitzak alde onak eta txarrak dituela.
Analisi estatikoa exekuzio-bide guztiak aztertu ditzake, erasotzaileek erabilitako teknikak egiaztatu osagaia exekutatu gabe, eta aurreprozesatzeko zereginak egin ditzake, hala nola des-ofuskatzea edo deszifratzea. Erasotzaileek beren gaiztakeria ezkutatzen saiatzen diren heinean, ofuskazio-saiakerak malwarearen froga dira (baina kontuan izan osagai legitimoek kodea ofuskatzen dutela jabetza intelektuala babesteko, kontraesanean "kode irekiko"). Nahasketa sendoa duten eraso sofistikatu gutxi batzuek baino ez dute behar sandboxing-a, baina nahasketa sendo hori gaiztakeriaren seinale da. Kontuan izan ohikoak direla SAST Tresnak nahi gabeko ahultasunetarako diseinatu ziren, ez atzeko ateak bezalako asmo gaiztoetarako.
Analisi dinamikoa osagaia exekutatzen du eta erantzuna aztertzen du exekuzio-denbora instrumentatuz, normalean sandbox ingurune bat eskainiz. Baldintza jakin batzuetan abiarazten den portaera gaiztoa detektatu gabe pasa daiteke: kontuan izan malwareak saihesteko teknikak erabil ditzakeela, hala nola Birtualizazioa/Sandbox Saihestea azterketapean ez dagoenean bakarrik aktibatzea, eta baita analisi estatikoen motor guztientzat jarduera gaiztoaren seinale ere.
Gaitasunen analisia osagaiak zer egiten duen kontuan hartzen du: non konektatzen den, zein fitxategitara sartzen den, zein komando edo programa exekutatzen diren, zein terminal edo gailuren S/I egiten den edo zein sistema-dei deitzen diren. Portaeraren hatz-marka hau (dagoeneko dauden osagaientzat) bertsioen artean alderatu daiteke, beraz, ustekabeko portaera detektatzen denean, froga horrek bertsio berrian txertatutako jarduera gaizto potentzialaren susmoa sor dezake. Ikuspegi honek segurtasun-analistek malware potentzial baten aurrean jarraitzen dituzten sailkapen-urratsak jarraitzen ditu: ikuskapen bat erabiliz kateak edo antzeko tresnak. Ikuspegi honek portaera gaiztoa detektatzen du, abiarazte-baldintzak edozein direla ere, eta iturburu-koderik eskuragarri ez dagoenean funtzionatzen du.
Testuinguruaren analisia osagaia nola argitaratu den eta nork argitaratu duen informazioa biltzen du. Egile gaiztoen kanpainek askotan erabiltzaile-kontu berri bat erabiltzen dute, inolako egiaztapen-prozesu zorrotzik jasan gabe. Iraganeko jardueraren jarraipenak azpiko erabiltzailearen inguruko informazioa eman dezake, batez ere arrisku potentzial baten zantzuak izan daitezkeen anomaliak ikusteko. Ospea oso zaila da irabazten eta oso erraza galtzen! Iraganeko jarduerarik ez duen erabiltzaile bat neutrala da, baina karmak gaiztoak jarraitzen ditu. Hacktibistak edo argitalpen-kredentzialak lapurtzen dizkieten erabiltzaile normalak arretaz jarraitu behar dira.
Beste testuinguru-informazio bat osagaiaren tarballa sortzeko erabilitako iturburu-biltegiaren eta tarballaren beraren edukiaren arteko edozein desadostasun da. Eta baita jardunbide egokiak jarraitzea ere, hala nola, iturburu-biltegian erregistro publikoan argitaratutako osagaiaren bertsioekin bat datozen etiketak edo bertsioak sortzea. Iturburu-biltegia jakin batean... commit bertsioarekin etiketatuta badago, eta bat-batean bertsio batek ez badu jarraitzen, hori bakarrik froga sendoa da osagaia kutsatuta egon daitekeela: gaizkileak osagaia argitaratzeko erabilitako kontua arriskuan jar dezake, baina ez du idazteko baimenik iturburu-kodearen biltegian). Eraso asko detektatzen dira ohiko arau hauek erabiliz: adibidez, Ledger erasoa erraz detektatu litezke lerro hauetan. Beraz, testuinguruaren analisiak argitalpen prozesuan dauden anomalia horiek identifikatzen ditu.
Mendekotasun Suebakia
Beste ikuspegi bat softwarean erabiltzen diren mendekotasun-grafo guztien osagaien zerrenda zuri osoa izatea da, edozein eraikuntzatan... pipeline zure erakundean exekutatzen diren osagaien bertsio onartuak bakarrik instalatu eta erabil daitezke. "firewall" barne erregistro bat erabiliz betearazten da, non baimendutako osagaien bertsioen tarballak zerbitzatzen diren (cachean edo proxyan). Kontuan izan zerrenda zuri batek ez duela funtzionatuko bertsio berri bat nahiko segurutzat sailkatzeko teknologia ez baduzu, zerrenda zurira gehitu ahal izateko.
Kontuan izan abisu goiztiarra (bertsio berria argitaratu ondoren ahalik eta azkarren detektatzea) informazio hori proaktiboki erabiltzeko moduren batekin konbinatu behar dela, eraikuntzan eragina duen osagaia blokeatzeko. pipelines edo garatzaileen makinak [4]Honi “ deitzen diogumendekotasun suebakia": pakete gaiztoetatik eraikitako sistema eragile automatizatuak babesteko berrogeialdi mekanismo bat. Barne paketeak eta irudi erregistroak onak dira erakundeak kanpoko gaitzetik isolatzeko, baina berrogeialdia eraginkorra izan dadin froga sendoak behar dira."
Exekuzio-denbora sandboxing-a
Argitalpen-garaian detektatzeko beste modu bat exekuzio-garaian portaera aztertzea da. Ideia softwarearen espero den portaera jasotzea eta aurkitzen diren anomaliak detektatzea (edo blokeatzea) da. Ekintza-lerro honek exekuzio-garaia monitorizatzeko edo blokeatzeko tresnak jarri behar izatearen arazoa du, eta ideia itxaropentsua da, osagai gaiztoen izurritearen aurkako babes-mekanismoen arsenalari gehituko zaiona.
Estrategia integral bat ezartzea
Gomendatutako estrategiak teknika desberdinak konbinatu behar ditu softwarearen garapen prozesuan, bertsioen eguneraketak kontrolatuz sarrerako osagai gaiztoak blokeatzeko. Bertsioen finkatzea egokitu behar dugu bertsioak eguneratzean infekzio automatikoa saihesteko, ahultasun garrantzitsuen konponketak lortzeko; bertsioen eguneraketetan zeharreko eta zeharkako mendekotasunen ebaluazio azkar eta eraginkorra, malwarez beteta ez daudela frogatzeko nahikoa froga izateko. Osagai gaizto ezagunen menpe dauden softwarearen bertsioak blokeatu behar dira. Eta guztiak betearazi behar dira.
Erabili bertsioen finkatzea, ahal den guztietan, eraikuntzak erreproduzigarriagoak egiten baititu. Bertsioen finkatzea kontrolatutako eta eskuz onartutako bertsio-igoerekin, eta laguntza-teknologiak lagunduta, ebaluatu beharko luke eguneratzeak malwarea ekartzen duen edo softwarea hondatzen duen, eta ahultasunak konpontzeko eguneratzea malware infekzioa saihestearekin bateragarri egin. Tresnek lagun dezakete hemen, (1) zein ahultasun diren benetan garrantzitsuak lehenetsiz (eskuragarriak eta ustiagarriak, erasotzaileek jomugan izateko arrisku handikoak), (2) egungo osagaien erabilerekin bateragarriak diren eta softwarea hondatzen ez duten helburu-bertsioak hautatuz, (3) portaera gaiztorik ez duten helburu-bertsioak aukeratuz, eta (4) zuzeneko eta zeharkako mendekotasunen bertsio-eguneratzea erraztuz, manifestu-fitxategietan azkar onar daitezkeen aldaketak iradokiz. (3) urratsak osagai gaiztoei buruzko informazio zehatza behar du, ahalik eta argitalpen-denborarik hurbilen.
Mendekotasunak eguneratzeko prozesu hau izan behar da behartuta egiaztatu leku guztietan. Prozesua dokumentatu behar da, eta inplikatutako alderdi guztiak prestatu behar dira, askotan garapena eta softwarearen eraikuntza/hedapena kanpora ateratzen baitira. CI/CD pipelines-ak horren arabera aldatu beharko lirateke, automatizazioak ez dezan menpekotasun zeharkako gaizto bat eraikuntzan sartzen utziko: guardrails Mendekotasun batean malware potentzialaren froga nahikoa badago, eraikuntza blokeatzea da gomendatutako bidea.
Zure erakundeak barne-erregistro bat badu baimendutako osagaien bertsioak gordetzeko segurtasun-proxy gisa jarduten duena, osagai gaiztoei buruzko informazioa lortu behar duzu (beste irizpide batzuez gain) eskatutako osagaia egiaztatzeko, baimen-zerrendan gehitu aurretik.
Kode irekiko softwarea segurtasunez kontsumitzea ez da erraza, eta malware faktorea guztiz kontuan hartu behar da, ahultasunen kudeaketan ahalegin bera eginez.
Azken ohar bat: Jatorrizko jatorria, osagaiaren eraikuntza-garaian sortutako software-ziurtagirien moduan, beste pieza gako bat da artefaktua (osagaiaren tarballa) hura sortu duten iturburuekin eta eraikuntza-prozesuarekin jarraitzeko ahaleginean. Kontuan izan iturburu-argazkiaren + eraikuntza-ingurunearen eta lotutako software-artefaktuaren (eraikuntza-sistema fidagarriak sinatutakoa) arteko lotura honek ez duela berez eragozten osagaiak ez duela portaera gaiztorik, baina zaildu egiten du gaizkileek malwarea txertatzea. Eta jatorriaren balidazioa iturburu irekiko osagaiak kontsumitzeko ohiko baldintza bihurtzeak denbora asko beharko du, eta bakarrik... duela gutxi gehitu da NPMraKonpilazio eta hedapen sistema fidagarri horiek manipulazioetatik babestuta egitea edo eraikuntzan manipulazioren bat detektatzea gaitzea beste kontu bat da, mezu honen helburutik kanpo.
Gehiago irakurketa
Hurrengo atala Kode irekiko pakete gaiztoak: Xygeni ikuspegia Xygenin jarraitzen dugun estrategia aurkeztuko dugu guretzat Malwarearen abisu goiztiarra (MEW) sistema. Pakete publikoen eta irudien erregistroetako pakete bertsio berriak eskaneatzen dira eta frogak lortzen dira analisi estatiko, dinamiko, gaitasun eta testuinguruaren konbinazio bat erabiliz. Frogek, erabiltzaileen ospearekin eta iturburu-kode biltegietako aldaketen historiarekin konbinatuta, osagai bat arrisku handiko eta ziurrenik gaiztoak diren kategorietan sailkatzea ahalbidetzen dute modu guztiz automatizatuan. Sistemak paketeetatik bildutako iraganeko frogetatik ikasten du positibo faltsuak ahalik eta gehien murrizteko.
Harpidetutako erakundeek abisu-jakinarazpen bat jasotzen dute zuzenean edo zeharka erabiltzen ari diren osagaiei buruz, bertsio gaizto bat sailkatzen denean. Ondoren, gure analistek eskuzko analisi bat egiten dute, sailkapena berresten edo baztertzen duena. Baieztatutako malwarearen kasuan, erregistro publikoari jakinarazten zaio, bere analisia egin dezan eta normalean bertsio gaiztoa kendu edo ekintza gehigarriak egin ditzan, hala nola, erabiltzaile-kontua blokeatzea edo kentzea.
Azalduko dugu nola laguntzen ari garen NPM, PyPI, GitHub eta kode irekiko ekosistemako beste azpiegitura gako batzuei argitaratutako osagai gaizto berri bat aktibo mantentzen den denbora murrizten, malwarea dela baieztatu eta erregistrotik kendu arte. Eta nola onura dezaketen erakundeek MEW sistematik, kode irekiko osagaiekin lotutako software hornikuntza-kateko erasoen aurkako babes hobea izateko.
- [1] Nolanahi ere, osagaiaren erabiltzaileek egiaztatu behar dute osagaiaren tarball-a cachean edo nonbait erregistratuta dagoen, adibidez barne-erregistro batean, gaixotasuna desagerrarazteko.
- [2] Osagai paketatuek manifestu bat dute, non bere edukia eta metadatuak, iturburu-kodea edo konpilatutako kodea, instalazio-gidoiak eta proba-multzoen moduko elementu gehigarriak deklaratzen diren, pakete-formatu baten arabera eta normalean formatu konprimituan. Honi "osagaien tarball" deritzo.
- [3] Egile gaiztoak erregistroan bertan izandako haustura baten ondorioz argitaratutako osagai bat alda dezakeen arren, kriptografia-digest arrunt batek tarball-ean edozein aldaketa detektatu dezake analisia egin ondoren.
- [4] Gogoratu osagai gaizto batzuk instalazio garaian exekutatzen direla, beraz, nahi gabe "npm install X" exekutatzen duten garatzaile nodoei eragin diezaieke X osagai gaiztoa izanik.
