To je tretja epizoda v serija člankov o najpogostejši vrsti napadov na dobavno verigo programske opreme: tistih, ki zlorabljajo javni register open-source programske komponente. Po analizi v prejšnji epizodi “Anatomija zlonamernih paketov: Kakšni so trendi?»Glede na to, kako zlonamerni akterji vbrizgavajo zlonamerno vedenje v nove ali obstoječe objavljene komponente, smo pripravljeni obleči gasilske jopiče in preučiti, kako lahko uspešno blokiramo zlonamerno programsko opremo, ki se dostavlja na ta način, ali pa se spopademo s potencialno resnim kibernetskim incidentom, ker smo uporabili napačen pristop.«
Večina strokovnjakov, ki se zavedajo varnosti, ima ideje o tem, kako se spopasti s to grožnjo. Slišali smo varnostne vodje, ki so brez oklevanja rekli, da SCA Orodja vam že povedo, kdaj je različica paketa zlonamerna programska oprema. Ali pa da so odvisna od znanih, visoko ocenjenih programskih komponent, kjer bi bila vsaka zlonamerna programska oprema takoj zaznana in odstranjena. Uporabljajo odprte manjše različice/popravke za samodejno pridobivanje popravkov ranljivosti, kar je pravilen in priporočen način za zmanjšanje tveganja za odvisnosti od odprte kode, v skladu z "obliž zgodaj, obliž pogosto”Načelo.
V tej epizodi bomo pregledali, zakaj so te ideje napačne in kako takšne zmotne predstave prispevajo k priljubljenosti tega napadalnega mehanizma in k ogromnemu tveganju, s katerim se soočajo organizacije. Zaključili bomo s tem, kaj deluje in kaj sta potrebna trud in viri.
Pogoste napačne predstave
Med našim potovanjem z varnostjo programske opreme smo bili priča razvoju tehnik napadov in širokemu naboru idej ljudi, ki se zavedajo varnosti. Organizacije pogosto napačno razumejo, kaj deluje proti tej grožnji, zato bomo najprej preučili, kaj ne deluje, kar je strnjeno v naslednjem, neizčrpnem seznamu zmotnih predstav.
Zmota št. 1: SCA orodja že poročajo o zlonamernih komponentah
Prav zares! Ampak po dejstvu... Ko je verjetno že prepozno, če je bil element uporabljen pri gradnji programske opreme in so se zlonamerni akterji že uveljavili pri razvijalcu ali CI/CD gostitelj. Skrivnosti so bile morda ukradene, prenesena in nameščena dodatna zlonamerna programska oprema, morda pa se je nasprotnik premaknil stransko in že pridobil dostop drugje.
Analiza sestave programske opreme (SCA) orodja so bila zasnovana za prepoznavanje potencialnih znanih ranljivosti. Sodobna orodja odlično opravljajo svoje delo, saj izboljšujejo razmerje signal-šum in ugotavljajo, ali je ranljivost dejansko dosegljiva ali izkoriščena. Vendar so neuporabna proti novi zlonamerni programski opremi. Zlonamerno komponento si predstavljajte kot ranljivost ničelnega dne: šele ko je zaznano njeno zlonamerno vedenje, se komponenta prijavi v register, ki ga varnostna ekipa po pregledu potrdi kot zlonamerno in odstrani iz registra. [1].
Na tej točki je svet (vključno z SCAs) ve, da namestitev ali uporaba komponente (ali neke različice(-ic) obstoječe komponente) ni dobra stvar. Vendar to velja, kadar komponenta ni na voljo v registruZavedanje, da imam ranljivosti v komponentah tretjih oseb ali celo v komponentah, ki jih je register označil kot zlonamerne, je dobro, a žal SCA ali običajna revizijska orodja v tem kontekstu ne pomagajo. Razen če SCAOrodje /audit lahko resnično vnaprej ve, da je komponenta zlonamerna, še preden se jo uporabi v vaši organizaciji..
Ne pozabite, da mora vsaka rešitev proti zlonamernim odprtokodnim komponentam te zaznati. spotoma, med objavo komponente v registru in prvo uporabo komponente (različice) v vaši organizaciji. To vključuje tudi tranzitivne komponente.
Zmota št. 2: Nadzorovanje namestitvenih skriptov med gradnjo preprečuje zlonamerno vedenje odprtokodnih komponent
Različni upravitelji paketov ponujajo možnost izvajanja skriptov (vključenih v tarball komponent [2]), iz legitimnih razlogov, kot so prevajanje zahtevanih elementov na različnih platformah, ustvarjanje kode ali izvajanje testov, in vsi bi morali vedeti, da jih lahko zlonamerni akterji zlorabijo, če so v tarball vključeni zlonamerni skripti ali če lahko napadalec namesto dobrega skripta zažene zlonamerni.
Če to vemo, lahko upravljalnik paketov konfiguriramo tako, da ignorira skripte. Na primer, z NPM –Ignoriraj skripte zastavica (ali lastnost konfiguracije v .npmrc datoteka) med namestitvijo preskoči skripte. To lahko povzroči nekaj težav, ker je izvajanje skriptov pogosto v mnogih ekosistemih: Nekateri upravitelji paketov sploh ne dovoljujejo onemogočanja izvajanja skriptov (namig: poziv »Kateri upravitelji paketov ne dovoljujejo onemogočanja izvajanja namestitvenih skriptov?"v vaši najljubši umetni inteligenci). Vendar to na splošno ne ščiti (moramo zagotoviti, da je konfiguracija onemogočanja preskakovanja povsod).
In ko zlonamerno vedenje ni v namestitvenih skriptih, temveč v programski opremi, ki se izvaja med izvajanjem, nas ta možnost sama po sebi ne zaščiti.
Zmota št. 3: Pripenjanje različic preprečuje namestitev zlonamernih komponent
Obstaja kompromis med zgodnjim krpanjem in pogostim odprte različice (omogočanje upravljalniku paketov, da samodejno namesti nove posodobitve, ko so na voljo za varnostne popravke) in pripenjanje različic (ki ima vse neposredne in tranzitivne odvisnosti za programsko opremo v fiksni različici). Varnostna načela so trmasta in včasih protislovna, kot se dogaja pri načelu »popravki zgodaj, popravki pogosto« in "Nadgradnje ne smemo jemati zlahka"Nekateri upravitelji paketov izvajajo samodejne posodobitve z obsegi strežnikov na priporočen način. Odlično, če želite prejemati tudi zlonamerne posodobitve! Da, komponente je treba posodobiti, da čim prej prejmejo varnostne popravke, ki odpravijo ranljivosti, vendar ... nikoli ne dovolite, da upravitelj paketov to stori samodejno.
Zmota št. 4: Uporaba zaupanja vrednih komponent je varna. Vsaka zlonamerna različica bi bila takoj najdena, razkrita in odstranjena.
Zakaj je komponenta zaupanja vredna? Morda zato, ker je zelo priljubljena, saj veliko ljudi išče ranljivosti, veliko število sodelavcev pri vzdrževanju in več vzdrževalcev jedra, ki skrbno pregledujejo vse pull requestsResničnost je precej drugačna. Nekatere bistvene komponente vzdržuje en sam, neplačan razvijalec. Široko uporabljeni ogrodji so nekaj rednih sodelavcev, s hitro padajočim številom commitna vzdrževalca (priljubljeni projekti imajo dolg rep sodelavcev, ki izvajajo nekaj mimohodnih commit in se nikoli več ne vrnejo). In priljubljenih projektov z enim samim vzdrževalcem je veliko.
Predstavljajte si, da pravite »Oh, uporabljamo slike Spring Boot / Angular / React / PyTorch / uradne osnovne Dockerjeve datoteke, zato je tveganje, o katerem govorite, precej nizko.« Morda je to res, saj mi, ponudniki varnostnih rešitev, ves čas širimo strašenje in se vmešavamo v razvojne ekipe, da bi ublažili vprašljivo tveganje, kar je nesmisel. Morda vas bo zamikalo, da bi skočili na odstavek o sprejemanju tveganja (v naslednjem razdelku) in končali. Žal so najbolj priljubljene komponente tarče zlonamernih akterjev, na primer priljubljene Knjižnica PyTorch je bila napadena v preteklosti.
"Takoj najdeno, razkrito in odstranjeno". Odstranitev nove zlonamerne komponente iz javnega registra traja več dni. Registri so previdni pri odstranjevanju različice komponente, kar je dobro. Naše izkušnje kažejo, da je po prijavi z naše strani povprečni čas, ki ga register potrebuje za odstranitev prizadete različice, 39 ur, kar je več kot dan in pol. Obstajajo zlonamerne komponente, ki so v registru pred odstranitvijo šele teden dni po naši začetni prijavi. V nekaterih primerih pa je komponenta odstranjena šele potem, ko žrtev ali podjetje za odzivanje na incidente prijavi incident, v katerega je bila vpletena komponenta.
Kaj NE deluje proti zlonamernim komponentam
Vsak nespecifičen pristop bo klavrno propadel. To je gotovo, ne zagotavljate učinkovitih protiukrepov za tveganje, povezano s to grožnjo.
Tradicionalna SCA Orodja vas obvestijo o znani zlonamerni programski opremi, vendar imajo veliko obdobje izpostavljenosti. Razen če proaktivno ne izvajajo zaznavanja zlonamerne programske opreme z vsiljenim blokiranjem zlonamernih komponent, ne delujejo proti tej grožnji.
Onemogočanje namestitvenih skriptov bi lahko pomagalo, vendar je treba to uveljaviti povsod, kjer je treba namestiti komponento. Enako velja za pripenjanje različic, saj različic ni mogoče za vedno pripeti iz varnega začetnega stanja.
Predvidevanje, da priljubljene komponente dobijo dovolj pozornosti, da jim v napadu na dobavno verigo ni mogoče povzročiti nenamernega vedenja brez skoraj takojšnjega zaznavanja, ki bi preprečilo kakršno koli škodo, je naivno in tvegano. Saj ne želite živeti na robu, kajne?
Če se na tej točki ustavite, potem sprejemanje tveganja je edino, kar lahko storiš: To je decision, ki ga je treba dokumentirati v vašem modelu groženj/oceni tveganja, vključno z utemeljitvijo za sprejetje tveganja in njegovimi morebitnimi posledicami. Ozaveščajte tako, da o tem obvestite vodstvo in druge ustrezne strani. Nekateri nepredvidljivih dogodkov bi se lahko načrtovalo, ko je zlonamerna komponenta nameščena ali vključena v vašo programsko opremo, vendar je to težko, ker imajo napadalci veliko poti, ki jim lahko sledijo. Podrobnosti napada v dobavni verigi, ki temelji na uporabi zlonamerne komponente, bodo drastično spremenile javno razkritje incidenta, kar je verjetno obvezno v skladu z regulativnim okvirom vaše organizacije. Lahko se obrnete tudi na kompenzacijske kontrole or tveganje prenosa npr. z zavarovanjem.
Vendar pa obstajajo mehanizmi, ki obravnavajo grožnjo in jih je treba upoštevati, če niste zadovoljni s sprejemanjem tveganja. Prosimo, berite dalje.
Kaj deluje proti napadom z zlonamernimi komponentami
Ravnanje s trdno različico
Pripenjanje različic z nadzorovanimi in informiranimi nadgradnjami različic je prava pot, s katero uravnotežimo potrebo po odstranjevanju ranljivosti brez prejemanja zlonamerne programske opreme. Vendar ne pozabite na zmotno prepričanje št. 3: samo pripenjanje različic ne zadostuje za blokiranje zlonamerne kode, ki prihaja iz novih različic, saj boste v prihodnje morali posodabljati različice, ki so neposredno ali posredno odvisne. V tem trenutku potrebujete dovolj močan dokaz, da vse spremenjene različice ne vsebujejo zlonamerne programske opreme.
Zgodnje opozorilo
En pristop k problemu zlonamernih komponent je sistem zgodnjega opozarjanja (tukaj imenovan Zgodnje opozorilo o zlonamerni programski opremi ali MEW), kjer nove objavljene različice (za nove ali obstoječe komponente) analizira zaznavalni mehanizem, ki lahko, ko najde dovolj dokazov, novo različico razvrsti kot potencialno zlonamerno.
Avtomatizacija je tukaj bistvenega pomena, saj je pri trenutni stopnji objavljanja nemogoče ročno pregledati vse nove komponente. Zato mora mehanizem za zaznavanje kombinirati različne tehnike, morda vključno s statično, dinamično in analizo zmogljivosti, ugledom uporabnikov in dokazi, ki izhajajo iz neskladij med metapodatki komponente in vsebino tarballa ali med tarballom in izvornim repozitorijem, od koder komponenta domnevno prihaja.
Obstaja temna cona med časom objave in časom, ko iskalnik analizira vsebino komponent, vendar ne sme presegati nekaj minut. Shemo je mogoče spremeniti, na primer tako, da počakate na analizo novih komponent, preden jih namestite in uporabite pri gradnji programske opreme. pipelineali pa jih analizirati na zahtevo, ko je to potrebno. Komponenta v dani različici je nespremenljiva [3], zato ga je treba analizirati samo enkrat.
Popolna avtomatizacija ni mogoča in potreben je varnostni pregled morebitnih zlonamernih komponent. Pazite se zagovornikov digitalne panacejeUmetna inteligenca in strojno učenje nista dovolj razvita, da bi imela zadnjo besedo pri potrditvi, ali ima sumljiva komponenta zlonamerno programsko opremo. Seveda ima strojno učenje ključno vlogo v mehanizmu za zaznavanje pri razvrščanju vhodne komponente iz zajetih surovih dokazov, toda ko je komponenta »v karanteni«, je zadnja beseda na ročnem pregledu varnostne ekipe z izkušnjami z zlonamernimi komponentami. To potrdi morebitno zlonamerno programsko opremo ali jo prerazvrsti kot varno. Časovno obdobje pa je v razponu ur.
Register poroča o zlonamerni različici/komponenti; register nato izvede pregled za potrditev in nadaljuje z javnim razkritjem ter odstranitvijo iz registra. Nekateri registri hranijo varnostni paket. Časovno obdobje tukaj je dnevi ali tedni od objave, kar je 'čas bivanja"ali"okno osvetlitve' za večino zlonamernih komponent.
Ali je mogoče vedeti, ali je različica komponente zlonamerna?
Za zgodnje opozarjanje moramo torej zadovoljivo odgovoriti na to vprašanje: Kako lahko vem, da knjižnica ali paket (ni) zlonameren? Kako zbrati dovolj dokazov o zlonamernem vedenju? Možno, vendar težko, saj nasprotniki uporabljajo veliko iznajdljivosti, da se izognejo odkritju. Obstajajo različni pristopi, vsak s prednostmi in slabostmi.
Statična analiza lahko pregleda vse poti izvajanja, preveri tehnike, ki jih uporabljajo napadalci, ne da bi zagnal komponento, in izvede naloge predobdelave, kot sta odkrivanje ali dešifriranje. Ko napadalci poskušajo skriti svojo zlonamernost, so poskusi zakrivanja dejansko dokaz zlonamerne programske opreme (vendar upoštevajte, da legitimne komponente zakrivajo kodo za ohranitev intelektualne lastnine, kar je v nasprotju z "open source"). Le manjšina zelo sofisticiranih napadov z močnim zakrivanjem potrebuje peskovnik, vendar je takšno močno zakrivanje značilen znak zlonamernosti. Upoštevajte, da običajni SAST Orodja so bila zasnovana za nenamerne ranljivosti, ne za zlonamerne namene, kot so zadnja vrata.
Dinamična analiza zažene komponento in pregleda odziv z instrumentalizacijo izvajalnega okolja, običajno z zagotavljanjem peskovnika. Zlonamerno vedenje, ki se sproži pod določenimi pogoji, lahko ostane neopaženo: upoštevajte, da lahko zlonamerna programska oprema uporablja tehnike izogibanja, kot so Izmikanje virtualizaciji/peskovniku aktivirati le, če ni pod drobnogledom, in je tudi znak zlonamerne dejavnosti za kateri koli mehanizem za statično analizo.
Analiza zmogljivosti upošteva, kaj komponenta počne: kam se povezuje, do katerih datotek dostopa, kateri ukazi ali programi se izvajajo, kateri V/I terminal ali naprava izvajajo ali kateri sistemski klici se sprožajo. To prstno odtisnjeno vedenje bi lahko primerjali (za obstoječo komponento) med različicami, tako da bi lahko ob zaznavi nepričakovanega vedenja ti dokazi vzbudili sum na morebitno zlonamerno dejavnost, vbrizgano v novo različico. Ta pristop sledi korakom triaže, ki jih varnostni analitiki upoštevajo, ko se soočijo s potencialno zlonamerno programsko opremo: pregled z uporabo strune ali podobna orodja. Ta pristop zazna zlonamerno vedenje ne glede na sprožilne pogoje in deluje, kadar izvorna koda ni na voljo.
Analiza konteksta zbira informacije o tem, kako je bila komponenta objavljena in kdo jo je objavil. Kampanje zlonamernih akterjev pogosto uporabljajo nov uporabniški račun (račune), ki ni podvržen strogemu postopku preverjanja. Sledenje preteklim dejavnostim lahko da vpogled v osnovnega uporabnika, večinoma za anomalije, ki lahko namigujejo na morebitno ogrožanje. Ugled si je tako težko prislužiti in tako enostavno izgubiti! Uporabnik brez preteklih dejavnosti je nevtralen, karma pa preganja zlonamerne. Hektiviste ali navadne uporabnike, ki jim ukradejo poverilnice za objavljanje, je treba skrbno spremljati.
Druga kontekstualna informacija je morebitno neskladje med izvornim repozitorijem, ki naj bi bil uporabljen za ustvarjanje tarballa komponente, in vsebino samega tarballa. Prav tako pa upoštevanje dobrih praks, kot je ustvarjanje oznak ali izdaj v izvornem repozitoriju, ki se ujemajo z različicami komponente, objavljenimi v javnem registru. Ko izvorni repozitorij na določenem commit označena z oznako »release« in nato nenadoma ena različica ne sledi tej omejitvi, je to že samo po sebi močan dokaz, da je komponenta lahko okužena: zlonamerni akter je morda ogrozil račun, uporabljen za objavo komponente, vendar nima dovoljenj za pisanje v repozitoriju izvorne kode). Številni napadi se rutinsko zaznajo z uporabo teh pravil: na primer Napad na knjigo računov bi jih bilo mogoče zlahka zaznati na podlagi teh značilnosti. Analiza konteksta torej prepozna takšne anomalije v procesu objavljanja.
Požarni zid odvisnosti
Drugačen pristop je, da imate obsežen seznam dovoljenih komponent za vse grafe odvisnosti, ki se uporabljajo v vaši programski opremi, torej v kateri koli gradnji pipeline V vaši organizaciji je mogoče namestiti in uporabljati samo odobrene različice komponent.požarni zid»se uveljavlja z uporabo notranjega registra, kjer se strežejo datoteke tarball za dovoljene različice komponent (shranjene v predpomnilniku ali posredovane prek posrednika). Upoštevajte, da noben seznam dovoljenih komponent ne bo deloval, razen če imate tehnologijo za razvrščanje katere koli nove različice kot razumno varne, da jo je mogoče dodati na seznam dovoljenih komponent.«
Upoštevajte, da je treba zgodnje opozarjanje (hitro zaznavanje čim prej po objavi nove različice) združiti z načinom proaktivne uporabe teh informacij za blokiranje komponente, ki vpliva na gradnjo. pipelineali stroji razvijalcev [4]Temu pravimo "požarni zid odvisnosti»: karantenski mehanizem za zaščito avtomatiziranih gradenj pred zlonamernimi paketi. Notranji paketi in registri slik so dobri za izolacijo organizacij pred zunanjim zlom, vendar so za učinkovitost karantene potrebni dovolj močni dokazi.«
Izvajalno peskovno okolje
Alternativni pristop k zaznavanju v času objavljanja je analiza vedenja med izvajanjem. Ideja je zajeti pričakovano vedenje programske opreme in zaznati (ali blokirati) vse najdene anomalije. Ta način delovanja ima težavo, da je treba izvajalno okolje opremiti za spremljanje ali blokiranje, in je obetavna ideja, ki bo dodana arzenalu zaščitnih mehanizmov pred zlonamernimi komponentami.
Določitev celovite strategije
Priporočena strategija mora združevati različne tehnike v procesu razvoja programske opreme in prevzeti nadzor nad posodobitvami različic za blokiranje dohodnih zlonamernih komponent. Omogočiti moramo pripenjanje različic, da se izognemo samodejni okužbi s posodabljanjem različic, da dobimo popravke za pomembne ranljivosti; hitro in učinkovito oceno neposrednih in posrednih odvisnosti med posodobitvami različic, da imamo dovolj dokazov, da niso okužene z zlonamerno programsko opremo. Gradnje programske opreme, ki so odvisne od znanih zlonamernih komponent, je treba blokirati. In vse je treba uveljaviti.
Kadar koli je mogoče, uporabite pripenjanje različic, saj to omogoča večjo ponovljivost gradenj. Pripenjanje različic z nadzorovanimi, ročno odobrenimi izboklinami različicin s pomočjo pomožne tehnologije, bi moral oceniti, ali posodobitev prinaša zlonamerno programsko opremo ali pokvari programsko opremo, in uskladiti posodabljanje za odpravljanje ranljivosti s preprečevanjem okužbe z zlonamerno programsko opremo. Orodja lahko pri tem pomagajo z (1) določanjem prioritet, ki ranljivosti so resnično pomembne (dosegljive in izkoriščene, z visokim tveganjem, da bi jih napadli napadalci), (2) izbiro ciljnih različic, ki so združljive s trenutno uporabo komponent in ne pokvarijo programske opreme, (3) izbiro ciljnih različic, ki ne vsebujejo zlonamernega vedenja, in (4) pospešitvijo posodobitve različice za neposredne in posredne odvisnosti s predlaganjem sprememb v datotekah manifesta, ki bi jih bilo mogoče hitro odobriti. Korak (3) zahteva specifične informacije o zlonamernih komponentah čim bližje času njihove objave.
Ta postopek posodabljanja odvisnosti mora biti prisiljeni in preverjeno na vseh mestih. Postopek mora biti dokumentiran in vse vpletene strani morajo biti usposobljene, saj se razvoj in izdelava/uvajanje programske opreme pogosto izvaja eksternalizirano. CI/CD pipelines je treba ustrezno spremeniti, da avtomatizacija ne dovoli, da bi se zlonamerna posredna odvisnost vpletla v gradnjo: guardrails Priporočljiva je blokada gradnje, če je v odvisnosti dovolj dokazov o morebitni zlonamerni programski opremi.
Če ima vaša organizacija notranji register, ki deluje kot varnostni posrednik za shranjevanje dovoljenih različic komponent, morate pred dodajanjem na seznam dovoljenih komponent pridobiti obveščevalne podatke o zlonamernih komponentah (poleg drugih meril) za preverjanje zahtevane komponente.
Varna uporaba odprtokodne programske opreme ni enostavna, pri čemer je treba v celoti upoštevati dejavnik zlonamerne programske opreme, pri čemer je treba vložiti podoben trud v obvladovanje ranljivosti.
Še zadnja opomba: Izvor, v obliki potrdil programske opreme, ustvarjenih v času gradnje komponente, je še en ključni del pri prizadevanju za sledenje artefaktu (komponentni tarball) z izvornimi kodami in procesom gradnje, ki ga je ustvaril. Upoštevajte, da ta povezava med posnetkom izvorne kode + okoljem gradnje in povezanim artefaktom programske opreme (ki ga je podpisal zaupanja vreden sistem gradnje) sama po sebi ne preprečuje, da komponenta ne vsebuje zlonamernega vedenja, vendar zlonamernim fantom otežuje vbrizgavanje zlonamerne programske opreme. In uvedba preverjanja izvora kot običajne zahteve za uporabo odprtokodnih komponent bo trajala dolgo in le nedavno dodano v NPMZagotavljanje zaščite teh zaupanja vrednih sistemov za gradnjo in uvajanje pred nedovoljenimi posegi ali omogočanje zaznavanja kakršnih koli nedovoljenih posegov v gradnjo je druga zgodba, ki ni del te objave.
Nadaljnje branje
Naslednja epizoda Zlonamerni paketi odprte kode: pristop Xygeni bo predstavil strategijo, ki ji sledimo pri Xygeniju za našo Zgodnje opozorilo o zlonamerni programski opremi (MEW) sistem. Nove različice paketov v javnih registrih paketov in slik se skenirajo, dokazi pa se pridobijo s kombinacijo statične, dinamične analize zmogljivosti in kontekstualne analize. Dokazi v kombinaciji z ugledom uporabnika in zgodovino sprememb v repozitorijih izvorne kode omogočajo popolnoma avtomatizirano razvrščanje komponente v kategorije z visokim tveganjem in verjetno zlonamernimi komponentami. Sistem se uči iz preteklih dokazov, zbranih iz paketov, da zmanjša število lažno pozitivnih rezultatov na minimum.
Naročene organizacije prejmejo opozorilo za komponente, ki jih uporabljajo, neposredno ali posredno, ko je zlonamerna različica kategorizirana. Nato naši analitiki opravijo ročno analizo, ki potrdi ali zavrne klasifikacijo. V primeru potrjene zlonamerne programske opreme je obveščen javni register, da lahko izvede lastno analizo in običajno odstrani zlonamerno različico ali sprejme dodatne ukrepe, kot je blokiranje ali odstranitev zadevnega uporabniškega računa.
Pojasnili bomo, kako pomagamo NPM, PyPI, GitHub in drugim ključnim infrastrukturam v ekosistemu odprte kode, da skrajšajo čas, ko novo objavljena zlonamerna komponenta ostane aktivna, dokler ni potrjena kot zlonamerna programska oprema in odstranjena iz registra. In kako lahko organizacije izkoristijo sistem MEW za veliko boljšo zaščito pred napadi v dobavni verigi programske opreme, ki vključujejo komponente odprte kode.
- [1] Kakorkoli že, uporabniki komponente morajo preveriti, ali je datoteka tarball komponente shranjena v predpomnilniku ali registrirana nekje, na primer v notranjem registru, da se težava odpravi.
- [2] Pakirana komponenta vključuje manifest, ki v skladu z obliko pakiranja in običajno v stisnjeni obliki deklarira njeno vsebino in metapodatke, izvorno ali prevedeno kodo, namestitvene skripte in dodatne elemente, kot so testni paketi. To se imenuje »tarball komponente«.
- [3] Tudi če lahko zlonamerni akter spremeni objavljeno komponento zaradi kršitve v samem registru, lahko navaden kriptografski pregled zazna vsako spremembo v tarballu po opravljeni analizi.
- [4] Ne pozabite, da se nekatere zlonamerne komponente zaženejo med namestitvijo, zato lahko vplivajo na vozlišča razvijalcev, ki nevede zaženejo »npm install X« z zlonamerno komponento X.
