Ovo je treća epizoda u serija članaka o najraširenijoj vrsti napada na lanac snabdijevanja softverom: onima koji zloupotrebljavaju javni registar Open-source softverske komponente. Nakon analize u prethodnoj epizodi "Anatomija zlonamjernih paketa: Koji su trendovi?„Kako zlonamjerni akteri ubrizgavaju zlonamjerno ponašanje u nove ili postojeće objavljene komponente, spremni smo obući vatrogasne prsluke i ispitati kako možemo uspješno blokirati zlonamjerni softver koji se isporučuje na ovaj način ili, alternativno, suočiti se s potencijalno ozbiljnim cyber incidentom jer smo zauzeli pogrešan pristup.“
Većina stručnjaka koji su svjesni sigurnosti imaju ideje o tome kako se nositi s ovom prijetnjom. Čuli smo menadžere sigurnosti kako bez oklijevanja govore da SCA Alati vam već govore kada je verzija paketa zlonamjerni softver. Ili da zavise od dobro poznatih, visoko ocijenjenih softverskih komponenti, gdje bi svaki zlonamjerni softver bio odmah otkriven i uklonjen. Koriste otvorene manje verzije/zakrpe za automatsko dobijanje ispravki ranjivosti, a to je ispravan, preporučen način za smanjenje rizika od zavisnosti otvorenog koda, slijedeći „krpi rano, krpi često”Princip.
U ovoj epizodi ćemo razmotriti zašto su ove ideje pogrešne i kako takve zablude doprinose popularnosti ovog mehanizma napada i ogromnom riziku s kojim se organizacije suočavaju. Završit ćemo s onim što funkcionira i koji su napori i resursi potrebni.
Uobičajene zablude
Tokom našeg putovanja kroz svijet sigurnosti softvera, vidjeli smo kako se tehnike napada razvijaju i širok spektar ideja ljudi koji su svjesni sigurnosti. Organizacije često pogrešno shvataju šta funkcioniše protiv ove prijetnje, pa ćemo prvo ispitati šta ne funkcioniše, sažeto u sljedećoj, ne iscrpnoj, listi zabluda.
Zabluda br. 1: SCA alati već prijavljuju zlonamjerne komponente
Zaista! Ali nakon što se to dogodilo... Kada je vjerovatno prekasno ako je element korišten u izradi softvera, a zlonamjerni akteri su već stekli uporište u programeru ili CI/CD host. Tajne su možda ukradene, dodatni zlonamjerni softver preuzet i instaliran, a možda se protivnik pomaknuo bočno i već dobio pristup negdje drugdje.
Analiza sastava softvera (SCA) alati su dizajnirani da identifikuju potencijalne poznate ranjivosti. Moderni alati odlično rade svoj posao povećavajući odnos signal-šum, određujući da li je ranjivost zaista dostupna ili se može iskoristiti. Ali su beskorisni protiv novog zlonamjernog softvera. Zamislite zlonamjernu komponentu kao zero-day ranjivost: Tek kada se otkrije njeno zlonamjerno ponašanje, komponenta se prijavljuje registru koji je, nakon pregleda od strane sigurnosnog tima, potvrđuje kao zlonamjerna i uklanja iz registra. [1].
U tom trenutku, svijet (uključujući SCAs) zna da instaliranje ili korištenje komponente (ili neke verzije postojeće komponente) nije dobra stvar. Ali to je kada komponenta nije dostupna iz registraSaznanje da imam ranjivosti u komponentama trećih strana, ili čak komponentama koje je registar kategorizirao kao zlonamjerne, je dobro, ali nažalost SCA ili uobičajeni alati za reviziju ne pomažu u ovom kontekstu. Osim ako SCA/audit alat zaista može unaprijed znati da je komponenta zlonamjerna prije nego što se koristi u vašoj organizaciji.
Zapamtite, svako rješenje protiv zlonamjernih komponenti otvorenog koda mora ih detektovati u letu, između trenutka kada je komponenta objavljena u registru i trenutka kada se komponenta (verzija) prvi put koristi u vašoj organizaciji. To uključuje i tranzitivne komponente.
Zabluda br. 2: Kontroliranje instalacijskih skripti u vrijeme izgradnje sprječava zlonamjerno ponašanje komponenti otvorenog koda
Razni upravitelji paketa nude mogućnost pokretanja skripti (uključenih u tarball komponenti) [2]), iz legitimnih razloga, kao što je kompajliranje potrebnih stavki na različitim platformama, generiranje koda ili pokretanje testova, i svi bismo trebali znati da ih mogu zloupotrijebiti loši akteri ako su zlonamjerni skripti uključeni u tarball ili ako napadač može pokrenuti zlonamjerni skript umjesto dobrog.
Znajući ovo, možemo konfigurirati upravitelj paketa da ignorira skripte. Na primjer, s NPM-om –ignor-skripte zastavica (ili svojstvo konfiguracije u .npmrc datoteka) preskače skripte tokom instalacije. Ovo može uzrokovati neke probleme jer je pokretanje skripti uobičajeno u mnogim ekosistemima: Neki upravitelji paketa čak ne dozvoljavaju ni onemogućavanje izvršavanja skripti (nagovještaj: prompt “Koji upravitelji paketa ne dozvoljavaju onemogućavanje izvršavanja instalacijskih skripti?"u vašoj omiljenoj umjetnoj inteligenciji). Ali ovo ne štiti općenito (moramo osigurati da konfiguracija onemogućavanja preskakanja bude svugdje).
A kada se zlonamjerno ponašanje ne nalazi u instalacijskim skriptama, već u softveru koji se izvršava za vrijeme izvođenja programa, ova opcija nas sama po sebi ne štiti.
Zabluda br. 3: Zakačivanje verzija sprečava instaliranje zlonamjernih komponenti
Postoji kompromis između ranog krpljenja i čestog otvorene verzije (omogućavanje upravitelju paketa da automatski instalira nova ažuriranja kada su dostupna za sigurnosne ispravke) i piniranje verzije (posjedovanje svih direktnih i tranzitivnih zavisnosti za softver u fiksnoj verziji). Sigurnosni principi su tvrdoglavi i ponekad kontradiktorni, kao što se dešava sa principom "zakrpi rano, zakrpi često" i "Nadogradnju ne treba shvatati olako"Neki upravitelji paketa vrše automatska ažuriranja sa rasponima servera na preporučeni način. Odlično ako želite primati i zlonamjerna ažuriranja! Da, komponente moraju biti ažurirane kako bi se što prije primile sigurnosne ispravke koje zatvaraju ranjivosti, ali... nikada ne dozvolite upravitelju paketa da to radi automatski.
Zabluda br. 4: Korištenje pouzdanih komponenti je sigurno. Svaka zlonamjerna verzija bit će odmah pronađena, otkrivena i uklonjena.
Zašto se komponenti vjeruje? Moguće zato što je veoma popularna, s mnogima koji traže ranjivosti, velikim brojem saradnika za održavanje, s više glavnih održavatelja koji marljivo pregledavaju sve pull requestsStvarnost je sasvim drugačija. Neke bitne komponente održava jedan, neplaćeni programer. Široko korišteni frameworkovi imaju nekoliko redovnih saradnika, sa brzo opadajućim brojem commits po održavatelju (popularni projekti imaju dugi niz saradnika koji obavljaju neke drive-by aktivnosti) commit i nikad se ne vratiti). I popularnih projekata s jednim održavateljem ima u izobilju.
Zamislite da kažete „Oh, koristimo Spring Boot / Angular / React / PyTorch / službene osnovne Docker slike, tako da je rizik o kojem govorite prilično nizak.“ Možda je to istina, mi, dobavljači sigurnosnih rješenja, stalno širimo zastrašivanje i miješamo se u razvojne timove kako bismo ublažili diskutabilni rizik, što je besmisleno. Možda ćete biti u iskušenju da pređete na paragraf o prihvatanju rizika (u sljedećem odjeljku) i to je to. Nažalost, najpopularnije komponente su mete za zlonamjerne aktere, a na primjer, popularne PyTorch biblioteka je napadnuta u prošlosti.
"Odmah pronađeno, otkriveno i uklonjeno". Potrebni su dani da se nova zlonamjerna komponenta ukloni iz javnog registra. Registri su oprezni u pogledu uklanjanja verzije komponente, što je i dobro. Naše iskustvo je da je, nakon što se s naše strane prijavi, srednje vrijeme potrebno za uklanjanje pogođene verzije od strane registra 39 sati, što je više od dan i po. Postoje zlonamjerne komponente koje se nalaze u registru sedmicu dana nakon našeg početnog prijavljivanja prije uklanjanja. A u nekim slučajevima, komponenta se uklanja tek nakon što žrtva ili kompanija za odgovor na incident prijavi incident koji uključuje komponentu.
Šta NE djeluje protiv zlonamjernih komponenti
Svaki nespecifičan pristup će neslavno propasti. To je sigurno, ne pružate efikasne protumjere za rizik povezan s ovom prijetnjom.
Tradicionalan SCA Alati vas obavještavaju o poznatom zlonamjernom softveru, ali imaju širok raspon izloženosti. Osim ako proaktivno ne vrše detekciju zlonamjernog softvera s prisilnim blokiranjem zlonamjernih komponenti, ne djeluju protiv ove prijetnje.
Onemogućavanje instalacijskih skripti bi moglo pomoći, ali se mora primijeniti svugdje gdje je potrebno instalirati komponentu. Isto važi i za fiksiranje verzija, jer se verzije ne mogu zauvijek fiksirati iz sigurnog početnog stanja.
Pretpostavka da popularne komponente dobijaju dovoljno pažnje da im se ne može ubrizgati neželjeno ponašanje u napadu na lanac snabdijevanja bez gotovo trenutnog otkrivanja kako bi se spriječila bilo kakva šteta je naivna i rizična. Ne želite živjeti na ivici, zar ne?
Ako se zaustavite na ovoj tački, onda prihvatanje rizika je jedino što možeš učiniti: Ovo je decision koji treba dokumentirati u vašem modelu prijetnje/procjeni rizika, uključujući obrazloženje za prihvatanje rizika i njegove potencijalne implikacije. Podignite svijest komunicirajući to s menadžmentom i drugim relevantnim stranama. Neki slučajnost moglo bi se planirati kada se zlonamjerna komponenta instalira ili uključi u vaš softver, ali to je teško jer napadači imaju mnogo puteva kojima mogu slijediti. Detalji napada na lanac snabdijevanja zasnovanog na korištenju zlonamjerne komponente drastično će promijeniti javno objavljivanje incidenta, što je vjerovatno obavezno prema regulatornom okviru vaše organizacije. Također se možete obratiti kompenzacijske kontrole or rizik transfera npr. sa osiguranjem.
Međutim, postoje kontrole koje se bave prijetnjom i treba ih uzeti u obzir ako niste zadovoljni prihvatanjem rizika. Molimo vas da nastavite čitati.
Šta djeluje protiv napada koji koriste zlonamjerne komponente
Rukovanje solidnom verzijom
Pinovanje verzija sa kontrolisanim i informisanim ažuriranjima verzija je pravi put, kako bi se uravnotežila potreba za uklanjanjem ranjivosti bez primanja zlonamjernog softvera. Ali zapamtite zabludu broj 3: Samo pinovanje verzija nije dovoljno da blokira zlonamjerni kod koji dolazi iz novih verzija, jer ćete u budućnosti morati ažurirati verzije u bilo kojoj direktnoj ili indirektnoj zavisnosti. U tom trenutku vam je potreban dovoljno jak dokaz da sve modificirane verzije ne sadrže zlonamjerni softver.
Rano upozorenje
Jedan od pristupa problemu zlonamjernih komponenti je sistem ranog upozorenja (ovdje nazvan Rano upozorenje o zlonamjernom softveru ili MEW), gdje se nove objavljene verzije (za nove ili postojeće komponente) analiziraju pomoću detekcijskog mehanizma, koji, kada se pronađe dovoljno dokaza, može klasificirati novu verziju kao potencijalno zlonamjernu.
Automatizacija je ovdje ključna, jer je nemoguće ručno pregledati sve nove komponente trenutnom brzinom objavljivanja. Stoga, mehanizam za detekciju mora kombinovati različite tehnike, možda uključujući statičku, dinamičku i analizu mogućnosti, reputaciju korisnika i dokaze koji proizlaze iz neslaganja između metapodataka komponente i sadržaja tarballa, ili između tarballa i izvornog repozitorija odakle komponenta navodno dolazi.
Postoji tamna zona između vremena objavljivanja i kada mehanizam analizira sadržaj komponenti, ali ne bi trebalo biti duže od nekoliko minuta. Shema se može modificirati, na primjer čekanjem da se nove komponente analiziraju prije nego što se dozvoli njihova instalacija i korištenje u izgradnji softvera. pipelineili ih analizirati na zahtjev kada je to potrebno. Komponenta u datoj verziji je nepromjenjiva [3], tako da ga je potrebno analizirati samo jednom.
Potpuna automatizacija nije moguća i potreban je sigurnosni pregled potencijalno zlonamjernih komponenti. Čuvajte se zagovornika digitalne panacejeVještačka inteligencija i mašinsko učenje nisu dovoljno razvijeni da bi preuzeli posljednju riječ kada je u pitanju potvrđivanje da li sumnjiva komponenta sadrži zlonamjerni softver. Naravno, mašinsko učenje igra ključnu ulogu u mehanizmu za detekciju u klasifikaciji ulazne komponente iz prikupljenih sirovih dokaza, ali kada se komponenta "stavi u karantin", posljednja riječ je na ručnom pregledu od strane sigurnosnog tima sa iskustvom u radu sa zlonamjernim komponentama. Ovo potvrđuje svaki potencijalni zlonamjerni softver ili ga reklasificira kao siguran. A vremenski period je u rasponu od nekoliko sati.
Registar izvještava o zlonamjernoj verziji/komponenti; registar zatim vrši pregled radi potvrde i nastavlja s javnim objavljivanjem i uklanjanjem iz registra. Neki registri čuvaju sigurnosni paket. Vremenski raspon ovdje je dani ili sedmice od objavljivanja, što je 'vremena zadržavanja'ili'prozor ekspozicije' za većinu zlonamjernih komponenti.
Da li je moguće znati da li je neka verzija komponente zlonamjerna?
Dakle, za rano upozorenje, moramo dati zadovoljavajući odgovor na ovo pitanje: Kako mogu znati da biblioteka ili paket (nije) zlonamjeran? Kako prikupiti dovoljno dokaza o zlonamjernom ponašanju? Moguće, ali teško, jer protivnici koriste mnogo domišljatosti kako bi izbjegli otkrivanje. Postoje različiti pristupi, svaki sa svojim prednostima i nedostacima.
Statička analiza Može ispitati sve putanje izvršenja, provjeriti tehnike koje koriste napadači bez pokretanja komponente i izvršiti zadatke prethodne obrade poput de-obfuskacije ili dešifriranja. Dok napadači pokušavaju sakriti svoju štetu, pokušaji obfuskacije su zaista dokaz zlonamjernog softvera (ali imajte na umu da legitimne komponente obfusciraju kod radi očuvanja intelektualnog vlasništva, što je u suprotnosti s "open source„). Samo manjina visoko sofisticiranih napada sa jakim zamagljivanjem zahtijeva sandbox, ali takvo jako zamagljivanje je znak zlonamjernosti. Imajte na umu da konvencionalni SAST Alati su dizajnirani za nenamjerne ranjivosti, a ne za zlonamjerne namjere poput stražnjih vrata.
Dinamička analiza pokreće komponentu i ispituje odgovor instrumentiranjem okruženja za izvršavanje, obično pružanjem sandbox okruženja. Zlonamjerno ponašanje pokrenuto pod određenim uvjetima može proći neotkriveno: imajte na umu da zlonamjerni softver može koristiti tehnike izbjegavanja poput Virtuelizacija/Sandbox Evasion da se aktivira samo kada nije pod nadzorom, a ujedno je i znak zlonamjerne aktivnosti za bilo koji mehanizam za statičku analizu.
Analiza sposobnosti uzima u obzir šta komponenta radi: gdje se povezuje, kojim datotekama pristupa, koje naredbe ili programi se izvršavaju, koji se I/O terminal ili uređaj izvršavaju ili koji se sistemski pozivi pozivaju. Ovo otiskivanje ponašanja moglo bi se uporediti (za postojeću komponentu) u različitim verzijama, tako da kada se otkrije neočekivano ponašanje, taj dokaz može izazvati sumnju na potencijalnu zlonamjernu aktivnost ubrizganu u novu verziju. Ovaj pristup slijedi korake trijaže koje sigurnosni analitičari slijede kada se suoče s potencijalnim zlonamjernim softverom: inspekcija korištenjem strings ili slične alate. Ovaj pristup detektuje zlonamjerno ponašanje bez obzira na uslove koji ga pokreću i funkcioniše kada izvorni kod nije dostupan.
Analiza konteksta prikuplja informacije o tome kako je komponenta objavljena i od strane koga. Kampanje zlonamjernih aktera često koriste novi korisnički račun (račune) koji nisu podložni strogom procesu provjere. Praćenje prošlih aktivnosti može dati uvid u osnovnog korisnika, uglavnom zbog anomalija koje mogu ukazivati na potencijalno kompromitovanje. Reputaciju je tako teško steći, a tako lako izgubiti! Korisnik bez prošlih aktivnosti je neutralan, ali karma progoni zlonamjernike. Haktiviste ili obične korisnike kojima su ukradeni akreditivi za objavljivanje treba pažljivo pratiti.
Druga kontekstualna informacija je bilo kakva neskladnost između izvornog repozitorija koji se navodno koristi za kreiranje tarballa komponente i samog sadržaja tarballa. Također, slijedeći dobre prakse, poput kreiranja oznaka ili izdanja u izvornom repozitoriju koje odgovaraju verzijama komponente objavljenim u javnom registru. Kada se izvorni repozitorij na određenom commit označena je sa "release", a onda odjednom jedna verzija ne uspije da ga prati, to samo po sebi predstavlja jak dokaz da komponenta može biti kontaminirana: zlonamjerni akter je možda kompromitovao račun koji se koristi za objavljivanje komponente, ali nema dozvole za pisanje u repozitoriju izvornog koda). Mnogi napadi se rutinski otkrivaju korištenjem ovih pravila: na primjer, Napad na Ledger moglo bi se lako otkriti na ovaj način. Analiza konteksta, stoga, identificira takve anomalije u procesu objavljivanja.
Zaštitni zid ovisnosti
Drugačiji pristup je imati sveobuhvatnu bijelu listu komponenti za sve grafove zavisnosti koji se koriste u vašem softveru, tako da u bilo kojoj izgradnji pipeline U vašoj organizaciji mogu se instalirati i koristiti samo odobrene verzije komponenti.firewall" se provodi korištenjem internog registra gdje se poslužuju tarball datoteke za dozvoljene verzije komponenti (keširane ili proxyirane). Imajte na umu da bilo koja bijela lista neće raditi osim ako nemate tehnologiju za klasifikaciju bilo koje nove verzije kao razumno sigurne kako bi se mogla dodati na bijelu listu.
Imajte na umu da rano upozorenje (brzo otkrivanje što je prije moguće nakon objavljivanja nove verzije) treba biti kombinirano s nekim načinom proaktivnog korištenja tih informacija za blokiranje komponente koja utječe na izgradnju. pipelineili mašine programera [4]Mi ovo zovemo "zaštitni zid ovisnosti„: mehanizam karantina za zaštitu automatiziranih verzija od zlonamjernih paketa. Interni paketi i registri slika su dobri za izolaciju organizacija od vanjskog zla, ali su potrebni dovoljno jaki dokazi da bi karantin bio efikasan.“
Sandboxing za vrijeme izvođenja
Alternativni pristup za detekciju u vrijeme objavljivanja je analiza ponašanja u vrijeme izvođenja. Ideja je uhvatiti očekivano ponašanje softvera i otkriti (ili blokirati) sve pronađene anomalije. Ovaj način djelovanja ima problem potrebe za instrumentacijom vremena izvođenja za praćenje ili blokiranje, i to je obećavajuća ideja koja će biti dodana arsenalu mehanizama zaštite od zlonamjernih komponenti.
Postavljanje sveobuhvatne strategije
Preporučena strategija treba da kombinuje različite tehnike u procesu razvoja softvera, preuzimajući kontrolu nad ažuriranjima verzija kako bi se blokirale dolazne zlonamjerne komponente. Moramo omogućiti blokiranje verzija kako bismo izbjegli automatsku infekciju ažuriranjem verzija kako bismo dobili ispravke za važne ranjivosti; brzu i efikasnu procjenu direktnih i indirektnih zavisnosti tokom ažuriranja verzija kako bismo imali dovoljno dokaza da nisu zaražene zlonamjernim softverom. Verzije softvera koje zavise od poznatih zlonamjernih komponenti moraju biti blokirane. I sve se moraju provoditi.
Koristite fiksiranje verzija, kada je to moguće, jer to čini izgradnje reproducibilnijim. Piniranje verzija s kontroliranim, ručno odobrenim izbočinama verzija, I uz pomoć pomoćne tehnologije, treba procijeniti da li ažuriranje donosi zlonamjerni softver ili kvari softver, te uskladiti ažuriranje radi ispravljanja ranjivosti sa izbjegavanjem infekcije zlonamjernim softverom. Alati mogu pomoći ovdje, (1) davanjem prioriteta ranjivostima koje su zaista važne (dostupne i iskoristive, s visokim rizikom da budu meta napadača), (2) odabirom ciljnih verzija koje su kompatibilne s trenutnom upotrebom komponenti i ne kvare softver, (3) odabirom ciljnih verzija koje ne sadrže zlonamjerno ponašanje i (4) čineći ažuriranje verzije za direktne i indirektne zavisnosti brzim, predlaganjem promjena u datotekama manifesta koje bi se mogle brzo odobriti. Korak (3) zahtijeva specifične informacije o zlonamjernim komponentama što je moguće bliže vremenu njihovog objavljivanja.
Ovaj proces ažuriranja zavisnosti mora biti prisilno i verifikovan na svim mjestima. Proces mora biti dokumentiran, a sve uključene strane trebaju biti obučene, jer se razvoj i izgradnja/implementacija softvera često eksternaliziraju. CI/CD pipelines treba shodno tome izmijeniti, kako automatizacija ne bi dozvolila da se zlonamjerna indirektna zavisnost uvuče u izgradnju: guardrails Preporučeni način je blokiranje izgradnje ako postoji dovoljno dokaza o potencijalnom zlonamjernom softveru u zavisnosti.
Ako vaša organizacija ima interni registar koji djeluje kao sigurnosni posrednik za čuvanje dozvoljenih verzija komponenti, morate prikupiti obavještajne podatke o zlonamjernim komponentama (pored ostalih kriterija) za provjeru tražene komponente prije nego što je dodate na listu dozvoljenih verzija.
Nije lako koristiti softver otvorenog koda uz siguran pristup, a faktor zlonamjernog softvera mora se u potpunosti uzeti u obzir, uz sličan napor koji se ulaže u rješavanje problema s ranjivostima.
Posljednja napomena: Porijeklo izvora, u obliku softverskih atesta, generiranih u vrijeme izgradnje komponente, još je jedan ključni dio u nastojanju da se prati artefakt (tarball komponente) s izvorima i procesom izgradnje koji ga je proizveo. Imajte na umu da ova veza između snimka izvora + okruženja za izgradnju i pridruženog softverskog artefakta (potpisanog od strane pouzdanog sistema za izgradnju) ne sprječava per-se da komponenta ne sadrži zlonamjerno ponašanje, ali otežava zlonamjernim igračima ubrizgavanje zlonamjernog softvera. A uvođenje validacije porijekla kao uobičajenog zahtjeva za korištenje komponenti otvorenog koda trajat će dugo, i samo nedavno dodano u NPMOmogućavanje otkrivanja bilo kakvog neovlaštenog mijenjanja u izgradnji tih pouzdanih sistema za izgradnju i implementaciju je druga priča i izlazi iz okvira ovog posta.
dalje čitanje
Sljedeća epizoda Zlonamjerni paketi otvorenog koda: Xygeni pristup predstavit ćemo strategiju koju slijedimo u Xygeniju za naše Rano upozorenje o zlonamjernom softveru (MEW) sistem. Nove verzije paketa u javnim registrima paketa i slika se skeniraju, a dokazi se dobijaju kombinacijom statičke, dinamičke, analize mogućnosti i kontekstualne analize. Dokazi, u kombinaciji s reputacijom korisnika i historijom promjena u repozitorijima izvornog koda, omogućavaju potpuno automatiziranu klasifikaciju komponente u kategorije visokog rizika i vjerovatno zlonamjerne. Sistem uči iz prošlih dokaza prikupljenih iz paketa kako bi se lažno pozitivni rezultati sveli na minimum.
Pretplaćene organizacije primaju upozorenje za komponente koje koriste, direktno ili indirektno, kada se kategorizira zlonamjerna verzija. Zatim naši analitičari vrše ručnu analizu, koja potvrđuje ili odbacuje klasifikaciju. Za potvrđeni zlonamjerni softver, javni registar se obavještava kako bi mogao izvršiti vlastitu analizu i obično ukloniti zlonamjernu verziju ili poduzeti dodatne radnje, kao što je blokiranje ili uklanjanje dotičnog korisničkog računa.
Objasnit ćemo kako pomažemo NPM-u, PyPI-ju, GitHubu i drugim ključnim infrastrukturama u ekosistemu otvorenog koda da smanje vrijeme zadržavanja aktivne nove zlonamjerne komponente dok se ne potvrdi da je zlonamjerni softver i ukloni iz registra. I kako organizacije mogu imati koristi od MEW sistema kako bi imale mnogo bolju zaštitu od napada na lanac snabdijevanja softverom koji uključuju komponente otvorenog koda.
- [1] U svakom slučaju, korisnici komponente trebaju provjeriti je li tarball komponente keširan ili negdje registriran, na primjer u internom registru, kako bi se problem iskorijenio.
- [2] Pakirana komponenta uključuje manifest koji deklarira njen sadržaj i metapodatke, izvorni ili kompajlirani kod, instalacijske skripte i dodatne stavke kao što su testni paketi, prema formatu pakiranja i obično u komprimiranom obliku. Ovo se naziva "tarball komponente".
- [3] Čak i ako zlonamjerni akter može izmijeniti objavljenu komponentu zbog propusta u samom registru, običan kriptografski sažetak može otkriti bilo kakvu promjenu u tarballu nakon što je analiza završena.
- [4] Imajte na umu da se neke zlonamjerne komponente pokreću tokom instalacije, tako da to može uticati na razvojne čvorove koji nenamjerno pokreću "npm install X" sa X kao zlonamjernom komponentom.
