Tai jau trečias epizodas iš straipsnių serija apie labiausiai paplitusias programinės įrangos tiekimo grandinės atakas: tas, kurios piktnaudžiauja viešuoju registru atviro kodo programinės įrangos komponentai. Atlikus ankstesniame epizode atliktą analizę „Kenkėjiškų paketų anatomija: kokios yra tendencijos?„Kaip blogi veikėjai įterpia kenkėjišką elgseną į naujus ar esamus publikuotus komponentus, esame pasirengę apsivilkti gaisrines liemenes ir išnagrinėti, kaip galime sėkmingai blokuoti tokiu būdu pateiktą kenkėjišką programinę įrangą arba, kita vertus, susidoroti su potencialiai rimtu kibernetiniu incidentu, kilusiu dėl to, kad pasirinkome netinkamą požiūrį.“
Dauguma saugumą išmanančių specialistų turi idėjų, kaip elgtis su šia grėsme. Esame girdėję saugumo vadovus nedvejojant sakant, kad SCA įrankiai jau nurodo, kada paketo versija yra kenkėjiška. Arba kad jie priklauso nuo gerai žinomų, kruopščiai patikrintų programinės įrangos komponentų, kuriuose bet kokia kenkėjiška programa būtų greitai aptikta ir pašalinta. Jie naudoja atviras nepilnamečių / pataisų versijas, kad automatiškai gautų pažeidžiamumų pataisymus, ir tai yra tinkamas, rekomenduojamas būdas sumažinti atvirojo kodo priklausomybių riziką, vadovaujantis „lopinėti anksti, lopinėti dažnai”Principas.
Šioje laidoje apžvelgsime, kodėl šios idėjos yra klaidingos ir kaip tokios klaidingos nuomonės prisideda prie šio atakų mechanizmo populiarumo ir didžiulės rizikos, su kuria susiduria organizacijos. Pabaigoje aptarsime, kas veikia ir kokios pastangos bei ištekliai yra reikalingi.
Dažni klaidingi supratimai
Mūsų kelionės su programinės įrangos saugumu metu matėme besivystančius atakų metodus ir daugybę idėjų iš saugumu besirūpinančių žmonių. Organizacijos dažnai neteisingai supranta, kas veikia prieš šią grėsmę, todėl pirmiausia išnagrinėsime, kas neveikia, glaustai pateiktame, neišsamiame, klaidingų nuomonių sąraše.
1 klaidinga nuomonė: SCA įrankiai jau praneša apie kenkėjiškus komponentus
Iš tikrųjų! Bet po fakto... Kai tikriausiai jau per vėlu, jei elementas buvo panaudotas programinės įrangos kūrime, o piktavaliai jau įsitvirtino kūrėjo įmonėje ar... CI/CD šeimininkas. Galbūt buvo išgauti paslaptys, atsisiųsta ir įdiegta papildoma kenkėjiška programa, o galbūt priešininkas pasitraukė į kitą vietą ir jau gavo prieigą kitur.
Programinės įrangos sudėties analizė (SCA) įrankiai buvo sukurti siekiant nustatyti galimus žinomus pažeidžiamumus. Šiuolaikiniai įrankiai puikiai atlieka savo darbą, padidindami signalo ir triukšmo santykį, nustatydami, ar pažeidžiamumas iš tikrųjų pasiekiamas arba išnaudojamas. Tačiau jie nenaudingi prieš naujas kenkėjiškas programas. Įsivaizduokite kenkėjišką komponentą kaip nulinės dienos pažeidžiamumą: tik aptikus kenkėjišką elgesį, komponentas pranešamas saugomajam registrui, kuris, atlikus saugos komandos peržiūrą, patvirtinamas kaip kenkėjiškas ir pašalinamas iš registro. [1].
Tuo metu pasaulyje (įskaitant SCAs) žino, kad komponento (arba kai kurių esamo komponento versijų) diegimas ar naudojimas nėra geras dalykas. Tačiau tai yra tada, kai komponentas nėra pasiekiamas registre.Žinoti, kad turiu pažeidžiamumų trečiųjų šalių komponentuose arba net komponentuose, kuriuos registras priskyrė kenkėjiškiems, yra gerai, bet, deja, SCA arba įprastos audito priemonės šiame kontekste nepadeda. Nebent SCA/audit įrankis gali iš anksto žinoti, kad komponentas yra kenkėjiškas, dar prieš jį panaudojant jūsų organizacijoje..
Atminkite, kad bet koks sprendimas prieš kenkėjiškus atvirojo kodo komponentus turi juos aptikti skrydžio metu, nuo komponento paskelbimo registre iki komponento (versijos) pirmojo panaudojimo jūsų organizacijoje. Tai apima ir tranzityvius komponentus.
2 klaidinga nuomonė: diegimo scenarijų valdymas kūrimo metu apsaugo nuo kenkėjiško atvirojo kodo komponentų elgesio
Įvairūs paketų tvarkytuvai siūlo galimybę paleisti scenarijus (įtrauktus į komponentų tarball). [2]), dėl teisėtų priežasčių, pavyzdžiui, reikalingų elementų kompiliavimui skirtingose platformose, kodo generavimui ar testų vykdymui, ir mes visi turėtume žinoti, kad jais gali piktnaudžiauti blogi veikėjai, jei į tarball įtraukiami kenkėjiški scenarijai arba jei užpuolikas gali priversti paleisti kenkėjišką scenarijų, o ne gerą.
Žinodami tai, galime sukonfigūruoti paketų tvarkyklę taip, kad ji ignoruotų scenarijus. Pavyzdžiui, naudodami NPM –Ignoruoti scenarijus vėliava (arba konfigūracijos ypatybė .npmrc failas) praleidžia scenarijus diegimo metu. Tai gali sukelti tam tikrų problemų, nes scenarijų vykdymas yra įprastas daugelyje ekosistemų: kai kurie paketų tvarkyklės net neleidžia išjungti scenarijų vykdymo (užuomina: raginimas „Kurie paketų tvarkytuvai neleidžia išjungti diegimo scenarijų vykdymo?„jūsų mėgstamiausiame DI). Tačiau tai neapsaugo apskritai (turime užtikrinti, kad praleidimo išjungimo konfigūracija būtų visur).
O kai kenkėjiškas elgesys slypi ne diegimo scenarijuose, o programinėje įrangoje, kuri turi būti vykdoma vykdymo metu, vien ši parinktis mūsų neapsaugo.
3 klaidinga nuomonė: versijos prisegimas neleidžia įdiegti kenkėjiškų komponentų
Yra kompromisas tarp ankstyvo pataisymo ir dažno su atviros versijos (leidžiant paketų tvarkyklei automatiškai įdiegti naujus atnaujinimus, kai tik jie yra prieinami, kad būtų galima pataisyti saugos problemas) ir versijos prisegimas (turintis visas tiesiogines ir pereinamąsias programinės įrangos priklausomybes fiksuotoje versijoje). Saugumo principai yra užsispyrę ir kartais prieštaringi, kaip nutinka su „pataisyti anksti, pataisyti dažnai“ ir „Atnaujinimo nereikėtų vertinti lengvabūdiškai“Kai kurie paketų tvarkytuvai atlieka automatinius atnaujinimus su serverių diapazonais rekomenduojamu būdu. Puiku, jei norite gauti ir kenkėjiškus atnaujinimus! Taip, komponentai turi būti atnaujinti, kad būtų gauti saugos pataisymai, kurie kuo greičiau pašalina pažeidžiamumus, bet... niekada neleiskite paketų tvarkytuvei to daryti automatiškai.
4-oji klaidinga nuomonė: Naudoti patikimus komponentus yra saugu. Bet kokia kenkėjiška versija būtų greitai surasta, atskleista ir pašalinta.
Kodėl komponentu pasitikima? Galbūt todėl, kad jis labai populiarus, daugelis ieško pažeidžiamumų, daug prisideda prie jo priežiūros ir keli pagrindiniai prižiūrėtojai kruopščiai peržiūri visus komponentus. pull requestsRealybė yra visai kitokia. Kai kuriuos esminius komponentus prižiūri vienas nemokamas kūrėjas. Plačiai naudojami karkasai... keli nuolatiniai bendradarbiai, sparčiai mažėjant skaičiui commits vienam prižiūrėtojui (populiarūs projektai turi ilgą bendraautorių grupę, kuri atlieka tam tikrus papildomus veiksmus) commit ir niekada negrįš). Ir gausu populiarių projektų, kuriuos prižiūri vienas kūrėjas.
Įsivaizduokite save sakant „O, mes naudojame „Spring Boot“ / „Angular“ / „React“ / „PyTorch“ / oficialius bazinius „Docker“ atvaizdus, todėl rizika, apie kurią kalbate, yra gana maža.“ Galbūt tai tiesa, mes, saugumo tiekėjai, nuolat gąsdiname ir kišimės į kūrimo komandas, kad sušvelnintume ginčytiną riziką, yra nesąmonė. Galbūt susigundysite pereiti prie rizikos priėmimo pastraipos (kitame skyriuje) ir viskas. Deja, populiariausi komponentai yra blogiukų taikiniai, pavyzdžiui, populiarusis PyTorch biblioteka buvo užpulta praeityje.
„Nedelsiant surasta, atskleista ir pašalinta“. Naujo kenkėjiško komponento pašalinimas iš viešojo registro užtrunka kelias dienas. Registrai atsargiai žiūri į komponento versijos šalinimą, nors ir tik į naudą. Mūsų patirtis rodo, kad gavus pranešimą iš mūsų pusės, registras pašalina paveiktą versiją vidutiniškai per 39 valandas – daugiau nei pusantros dienos. Yra kenkėjiškų komponentų, kurie pašalinami registre praėjus savaitei po mūsų pirmojo pranešimo. Kai kuriais atvejais komponentas pašalinamas tik po to, kai auka arba incidentų valdymo įmonė praneša apie incidentą, susijusį su komponentu.
Kas NEVEIKIA prieš kenkėjiškus komponentus
Bet koks nekonkretus metodas bus apgailėtinai nesėkmingas. Tai neabejotina, kad jūs nesiūlote veiksmingų atsakomųjų priemonių nuo su šia grėsme susijusios rizikos.
Tradicinis SCA Įrankiai praneša apie žinomas kenkėjiškas programas, tačiau turi ilgą veikimo langą. Jei jie neatlieka aktyvios kenkėjiškų programų aptikimo su priverstiniu kenkėjiškų komponentų blokavimu, jie neveikia prieš šią grėsmę.
Diegimo scenarijų išjungimas galėtų padėti, tačiau tai reikia daryti visur, kur reikia įdiegti komponentą. Tas pats pasakytina ir apie versijų prisegimą, nes versijų negalima prisegti iš saugios pradinės būsenos visam laikui.
Manyti, kad populiarūs komponentai sulaukia pakankamai dėmesio, jog jiems nebūtų galima atlikti netyčinio elgesio tiekimo grandinės atakos metu be beveik akimirksniu atliekamo aptikimo, kuris padėtų išvengti bet kokios žalos, yra naivu ir rizikinga. Juk nenorite gyventi ant ribos, ar ne?
Jei sustosite šioje vietoje, tai rizikos priėmimas yra vienintelis dalykas, kurį galite padaryti: Tai yra decision, kurią reikia dokumentuoti jūsų grėsmės modelyje / rizikos vertinime, įskaitant rizikos priėmimo pagrindimą ir galimas jos pasekmes. Didinkite informuotumą, pranešdami apie tai vadovybei ir kitoms susijusioms šalims. Kai kurie nenumatytas atvejis galima būtų suplanuoti, kai jūsų programinėje įrangoje įdiegiama arba įtraukiama kenkėjiška komponentė, tačiau tai sunku, nes užpuolikai turi daug kelių. Tiekimo grandinės atakos, pagrįstos kenkėjiško komponento naudojimu, detalės drastiškai pakeis incidento viešinimą, kuris tikriausiai yra privalomas pagal jūsų organizacijos reguliavimo sistemą. Taip pat galite spręsti kompensacinės kontrolės priemonės or perdavimo rizika pvz., su draudimu.
Tačiau yra kontrolės priemonių, kurios pašalina grėsmę ir į kurias reikėtų atsižvelgti, jei nesate patenkinti rizikos priimtinumu. Prašome skaitykite toliau.
Kas veikia prieš atakas, naudojant kenkėjiškus komponentus
Kietosios versijos tvarkymas
Versijų prisegimas su kontroliuojamais ir pagrįstais versijų atnaujinimais yra tinkamas būdas subalansuoti pažeidžiamumų šalinimo poreikį be kenkėjiškų programų gavimo. Tačiau nepamirškite 3 klaidingos nuomonės: vien versijų prisegimo nepakanka, kad būtų užblokuotas kenkėjiškas kodas iš naujų versijų, nes ateityje reikės atnaujinti versijas, tiesiogiai ar netiesiogiai priklausančias. Tuo metu jums reikia pakankamai tvirtų įrodymų, kad visose modifikuotose versijose nėra kenkėjiškų programų.
Išankstinis perspėjimas
Vienas iš būdų spręsti kenkėjiškų komponentų problemą yra ankstyvojo perspėjimo sistema (čia vadinama Kenkėjiškų programų ankstyvas įspėjimas arba MEW), kur naujai paskelbtos versijos (naujų arba esamų komponentų) yra analizuojamos aptikimo modulio, kuris, radęs pakankamai įrodymų, gali klasifikuoti naują versiją kaip potencialiai kenkėjišką.
Automatizavimas čia yra būtinas, nes neįmanoma rankiniu būdu peržiūrėti visų naujų komponentų dabartiniu publikavimo tempu. Todėl aptikimo modulis turi derinti įvairius metodus, įskaitant statinę, dinaminę ir galimybių analizę, naudotojų reputaciją ir įrodymus, gautus iš neatitikimų tarp komponentų metaduomenų ir tarball turinio arba tarp tarball ir šaltinio saugyklos, iš kurios tariamai yra komponentas.
Čia yra tamsi zona tarp publikavimo laiko ir tada, kai variklis analizuoja komponentų turinį, tačiau šis laikas neturėtų viršyti kelių minučių. Schemą galima modifikuoti, pavyzdžiui, palaukant, kol bus išanalizuoti nauji komponentai, prieš leidžiant juos įdiegti ir naudoti programinės įrangos kūrime. pipelinearba analizuoti juos pagal poreikį. Tam tikros versijos komponentas yra nekeičiamas. [3], todėl analizuoti reikia tik vieną kartą.
Visiškas automatizavimas neįmanomas, todėl reikalinga potencialiai kenkėjiškų komponentų saugumo peržiūra. Saugokitės skaitmeninių panacėjos šalininkųDirbtinis intelektas ir mašininis mokymasis nėra pakankamai išvystyti, kad galėtų tarti paskutinį žodį, kai reikia patvirtinti, ar įtariamas komponentas turi kenkėjiškų programų. Žinoma, mašininis mokymasis atlieka pagrindinį vaidmenį aptikimo modulyje klasifikuojant įvesties komponentą pagal užfiksuotus neapdorotus įrodymus, tačiau kai komponentas „karantine“ laikomas, galutinį žodį taria saugos komanda, turinti patirties su kenkėjiškais komponentais. Tai patvirtina bet kokią galimą kenkėjišką programinę įrangą arba perkvalifikuoja ją kaip saugią. Laikotarpis yra maždaug valandų diapazone.
Registras praneša apie kenkėjišką versiją / komponentą; tada registras atlieka peržiūrą, kad patvirtintų, ir pradeda viešą atskleidimą bei pašalinimą iš registro. Kai kurie registrai saugo saugumo paketą. Laikotarpis čia yra dienos arba savaitės nuo paskelbimo, t. y. „gyvenimo laikas"arba"ekspozicijos langas„daugumai kenkėjiškų komponentų“.
Ar įmanoma sužinoti, ar komponento versija yra kenkėjiška?
Taigi, norėdami anksti įspėti, turime pateikti patenkinamą atsakymą į šį klausimą: kaip žinoti, kad biblioteka ar paketas yra (ne) kenkėjiškas? Kaip surinkti pakankamai kenkėjiško elgesio įrodymų? Įmanoma, bet sunku, nes priešininkai naudoja daug išradingumo, kad išvengtų aptikimo. Yra įvairių metodų, kiekvienas iš jų turi privalumų ir trūkumų.
Statinė analizė gali patikrinti visus vykdymo kelius, patikrinti užpuolikų naudojamus metodus nepaleidžiant komponento, ir atlikti išankstinio apdorojimo užduotis, pvz., deobfuskaciją ar iššifravimą. Užpuolikams bandant nuslėpti savo piktadarystes, bandymai užmaskuoti kodą iš tiesų yra kenkėjiškos programos įrodymas (tačiau atkreipkite dėmesį, kad teisėti komponentai užmaskuoja kodą, siekdami išsaugoti intelektinę nuosavybę, o tai prieštarauja „atviro kodo„). Tik nedaugeliui itin sudėtingų atakų, kurioms taikomas stiprus maskavimas, reikia „smėlio dėžės“ tipo atakų, tačiau toks stiprus maskavimas yra iškalbingas piktavališkumo požymis. Atkreipkite dėmesį, kad įprasti SAST Įrankiai buvo sukurti netyčiniams pažeidžiamumams, o ne kenkėjiškiems ketinimams, pavyzdžiui, užpakalinėms durims.
Dinaminė analizė paleidžia komponentą ir išnagrinėja atsaką, pritaikydamas vykdymo aplinką, paprastai pateikdamas smėlio dėžės tipo aplinką. Kenkėjiškas elgesys, sukeltas tam tikromis sąlygomis, gali likti nepastebėtas: atkreipkite dėmesį, kad kenkėjiška programa gali naudoti tokius apėjimo metodus kaip Virtualizacijos / smėlio dėžės apėjimas aktyvuoti tik tada, kai nėra atidžiai tikrinamas, ir tai taip pat yra kenkėjiškos veiklos požymis bet kuriame statinės analizės variklyje.
Pajėgumų analizė atsižvelgiama į komponento atliekamą veiklą: prie kur jis jungiasi, kokius failus pasiekia, kurios komandos ar programos paleidžiamos, atliekamas terminalo ar įrenginio įvesties / išvesties veiksmas arba iškviečiami sistemos skambučiai. Šis elgesio pirštų atspaudų nustatymas (esamo komponento atveju) galėtų būti palyginamas skirtingose versijose, todėl aptikus netikėtą elgesį, šie įrodymai galėtų sukelti įtarimą dėl potencialios kenkėjiškos veiklos, įterptos į naują versiją. Šis metodas atitinka triažo veiksmus, kuriuos saugumo analitikai taiko susidūrę su potencialia kenkėjiška programine įranga: patikrinimas naudojant stygos arba panašius įrankius. Šis metodas aptinka kenkėjišką elgesį, neatsižvelgiant į suaktyvinimo sąlygas, ir veikia, kai nėra šaltinio kodo.
Konteksto analizė renka informaciją apie tai, kaip ir kas paskelbė komponentą. Piktavališkų veikėjų kampanijos dažnai naudoja naują(-as) vartotojo paskyrą(-as), kuriai(-ioms) netaikomas joks griežtas tikrinimo procesas. Ankstesnės veiklos stebėjimas gali suteikti įžvalgų apie pagrindinį vartotoją, dažniausiai dėl anomalijų, kurios gali rodyti galimą pažeidimą. Reputaciją taip sunku užsitarnauti ir taip lengva prarasti! Vartotojas, kuris anksčiau nebuvo aktyvus, yra neutralus, tačiau karma persekioja piktavališkus. Hakeriai arba įprasti vartotojai, kurių publikavimo duomenys pavogti, turėtų būti atidžiai stebimi.
Kita kontekstinė informacija yra bet koks neatitikimas tarp šaltinio saugyklos, tariamai naudotos komponentų rinkiniui sukurti, ir paties rinkinio turinio. Taip pat gerosios praktikos laikymasis, pvz., žymų ar leidimų kūrimas šaltinio saugykloje, atitinkantis viešajame registre paskelbtas komponento versijas. Kai šaltinio saugykla tam tikroje... commit yra pažymėtas išleidimo žyma, o tada staiga viena versija po jos nebepasirodo, tai jau yra rimtas įrodymas, kad komponentas gali būti užkrėstas: piktavalis veikėjas galėjo pažeisti paskyrą, naudojamą komponentui publikuoti, bet neturi rašymo teisių šaltinio kodo saugykloje). Daugelis atakų įprastai aptinkamos naudojant šias taisykles: pavyzdžiui, Ledgerio ataka būtų galima lengvai aptikti pagal šią schemą. Todėl konteksto analizė nustato tokias leidybos proceso anomalijas.
Priklausomybių užkarda
Kitas būdas – turėti išsamų komponentų baltąjį sąrašą visoms jūsų programinėje įrangoje naudojamoms priklausomybių diagramoms, kad bet kurioje versijoje pipeline Jūsų organizacijoje gali būti diegiamos ir naudojamos tik patvirtintos komponentų versijos.užkarda„yra vykdomas naudojant vidinį registrą, kuriame pateikiami leidžiamų komponentų versijų tarball failai (talpykloje arba per tarpinį serverį). Atminkite, kad joks baltasis sąrašas neveiks, nebent turėsite technologiją, leidžiančią bet kurią naują versiją klasifikuoti kaip pakankamai saugią, kad ją būtų galima įtraukti į baltąjį sąrašą.
Atkreipkite dėmesį, kad ankstyvas įspėjimas (greitas aptikimas kuo greičiau po naujos versijos paskelbimo) turi būti derinamas su tam tikru būdu, kaip aktyviai panaudoti šią informaciją, kad būtų užblokuotas komponentas, turintis įtakos kompiliavimui. pipelinearba kūrėjų mašinos [4]Mes tai vadiname „priklausomybės užkarda„: karantino mechanizmas, skirtas apsaugoti automatizuotas versijas nuo kenkėjiškų paketų. Vidiniai paketai ir atvaizdų registrai yra tinkami organizacijų apsaugai nuo išorinio blogio, tačiau norint, kad karantinas būtų veiksmingas, reikia pakankamai tvirtų įrodymų.“
Veikimo laiko smėlio dėžė
Alternatyvus aptikimo publikavimo metu metodas yra analizuoti elgseną vykdymo metu. Idėja yra užfiksuoti numatomą programinės įrangos elgseną ir aptikti (arba blokuoti) visas rastas anomalijas. Šis veiksmų planas turi problemą, susijusią su tuo, kad reikia pritaikyti vykdymo aplinką stebėjimui arba blokavimui, ir tai perspektyvi idėja, kuri bus įtraukta į apsaugos mechanizmų, skirtų kenkėjiškiems komponentams, arsenalą.
Visapusiškos strategijos nustatymas
Rekomenduojama strategija turi derinti skirtingus programinės įrangos kūrimo proceso metodus, kontroliuojant versijų atnaujinimus, kad būtų blokuojami gaunami kenkėjiški komponentai. Turime atsižvelgti į versijų prisegimą, kad būtų išvengta automatinio užkrėtimo atnaujinant versijas, siekiant ištaisyti svarbius pažeidžiamumus; greitas ir efektyvus tiesioginių ir netiesioginių priklausomybių įvertinimas versijų atnaujinimų metu, kad būtų pakankamai įrodymų, jog jos nėra užkrėstos kenkėjiška programa. Programinės įrangos versijos, kurios priklauso nuo žinomų kenkėjiškų komponentų, turi būti blokuojamos. Ir visa tai turi būti vykdoma.
Kai įmanoma, naudokite versijų prisegimą, nes tai palengvina kompiliacijų atkartojimą. Versijų prisegimas su kontroliuojamais, rankiniu būdu patvirtintais versijų sutrumpinimaisir padeda pagalbinė technologija, turėtų įvertinti, ar atnaujinimas atneša kenkėjiškų programų, ar sugadina programinę įrangą, ir suderinti atnaujinimus, skirtus pažeidžiamumų taisymui, su kenkėjiškų programų užkrėtimo vengimu. Čia gali padėti įrankiai, (1) nustatant prioritetus, kurie pažeidžiamumai iš tiesų yra svarbūs (pasiekiami ir išnaudojami, turintys didelę riziką tapti užpuolikų taikiniais), (2) pasirenkant tikslines versijas, kurios suderinamos su dabartiniu komponentų naudojimu ir nesugadina programinės įrangos, (3) pasirenkant tikslines versijas, kuriose nėra kenkėjiško elgesio, ir (4) supaprastinant tiesioginių ir netiesioginių priklausomybių versijų atnaujinimą, siūlant manifesto failų pakeitimus, kuriuos būtų galima greitai patvirtinti. (3) žingsnyje reikia konkrečios informacijos apie kenkėjiškus komponentus kuo arčiau jų paskelbimo laiko.
Šis priklausomybių atnaujinimo procesas turi būti priverstas bei patikrinta visose vietose. Procesas turi būti dokumentuotas, o visos dalyvaujančios šalys turėtų būti apmokytos, nes programinės įrangos kūrimas ir diegimas dažnai yra perduodami išorės tiekėjams. CI/CD pipelinereikėtų atitinkamai modifikuoti, kad automatizavimas neleistų kenkėjiškai netiesioginei priklausomybei patekti į kūrimą: guardrails Rekomenduojama blokuoti kompiliavimą, jei yra pakankamai įrodymų apie galimą kenkėjišką programinę įrangą priklausomybėje.
Jei jūsų organizacija turi vidinį registrą, veikiantį kaip saugos tarpinis serveris, skirtas leistinoms komponentų versijoms saugoti, prieš įtraukdami prašomą komponentą į leidžiamų versijų sąrašą, turite gauti informacijos apie kenkėjiškus komponentus (be kitų kriterijų), kad galėtumėte jį patikrinti.
Saugiai naudoti atvirojo kodo programinę įrangą nėra lengva, todėl reikia visapusiškai atsižvelgti į kenkėjiškų programų veiksnį, panašiai stengiantis tvarkyti pažeidžiamumus.
Viena paskutinė pastaba: Šaltinio kilmė, programinės įrangos atestatų pavidalu, sugeneruotų komponento kūrimo metu, yra dar vienas svarbus elementas, siekiant atsekti artefaktą (komponento tarball) su jį sukūrusiais šaltiniais ir kūrimo procesu. Atkreipkite dėmesį, kad šis ryšys tarp šaltinio momentinės kopijos + kūrimo aplinkos ir susijusio programinės įrangos artefakto (pasirašyto patikimos kūrimo sistemos) savaime neužkerta kelio tam, kad komponentas neturėtų kenkėjiškos veiklos, bet apsunkina kenkėjiškų programų įterpimą. Kilmės patvirtinimo įdiegimas kaip bendras reikalavimas naudojant atvirojo kodo komponentus užtruks ilgai ir tik... neseniai pridėta prie NPMKaip užtikrinti, kad šios patikimos kūrimo ir diegimo sistemos būtų apsaugotos nuo klastojimo arba kad būtų galima aptikti bet kokį kūrimo metu atliktą klastojimą, yra kita istorija, neįeinanti į šio įrašo taikymo sritį.
Toliau skaitykite
Kitas epizodas Atvirojo kodo kenkėjiški paketai: „Xygeni“ metodas pristatys mūsų „Xygeni“ taikomą strategiją. Kenkėjiškų programų ankstyvas įspėjimas (MEW) sistema. Nuskaitomos naujos paketų versijos viešuosiuose paketų ir vaizdų registruose, o įrodymai gaunami naudojant statinės, dinaminės, galimybių ir kontekstinės analizės derinį. Įrodymai kartu su naudotojų reputacija ir šaltinio kodo saugyklų pakeitimų istorija leidžia visiškai automatiškai klasifikuoti komponentą į didelės rizikos ir tikriausiai kenkėjiškas kategorijas. Sistema mokosi iš ankstesnių įrodymų, surinktų iš paketų, kad sumažintų klaidingai teigiamų rezultatų skaičių iki minimumo.
Prenumeruotos organizacijos gauna įspėjamąjį pranešimą apie komponentus, kuriuos jos naudoja tiesiogiai ar netiesiogiai, kai kenkėjiška versija yra priskiriama kategorijai. Tada mūsų analitikai atlieka rankinę analizę, kuri patvirtina arba atmeta klasifikaciją. Patvirtinus kenkėjišką programinę įrangą, pranešama viešajam registrui, kad jis galėtų atlikti savo analizę ir paprastai pašalinti kenkėjišką versiją arba imtis papildomų veiksmų, pvz., užblokuoti arba pašalinti atitinkamą vartotojo paskyrą.
Paaiškinsime, kaip padedame NPM, PyPI, GitHub ir kitoms svarbioms atvirojo kodo ekosistemos infrastruktūroms sutrumpinti naujai paskelbto kenkėjiško komponento aktyvumo laiką, kol patvirtinama, kad jis yra kenkėjiškas, ir jis pašalinamas iš registro. Ir kaip organizacijos gali pasinaudoti MEW sistemos teikiama nauda, kad geriau apsisaugotų nuo programinės įrangos tiekimo grandinės atakų, susijusių su atvirojo kodo komponentais.
- [1] Bet kokiu atveju, komponento naudotojai turi patikrinti, ar komponento tarball yra talpykloje arba kažkur registruotas, pavyzdžiui, vidiniame registre, kad problema būtų išnaikinta.
- [2] Supakuotą komponentą sudaro manifestas, kuriame pagal pakavimo formatą ir paprastai suspausta forma deklaruojamas jo turinys ir metaduomenys, šaltinio arba kompiliuotas kodas, diegimo scenarijai ir papildomi elementai, pvz., testų rinkiniai. Tai vadinama „komponentų tarball“.
- [3] Net jei kenkėjiškas veikėjas gali modifikuoti paskelbtą komponentą dėl paties registro pažeidimo, paprasta kriptografinė santrauka gali aptikti bet kokius pakeitimus tarball faile atlikus analizę.
- [4] Atminkite, kad kai kurie kenkėjiški komponentai paleidžiami diegimo metu, todėl tai gali paveikti kūrėjo mazgus, kurie netyčia paleidžia „npm install X“ su kenkėjišku komponentu X.
