Šī ir trešā epizode sērijā rakstu sērija par visizplatītākajiem programmatūras piegādes ķēdes uzbrukumu veidiem: tiem, kas ļaunprātīgi izmanto publisku reģistru atvērtais avots programmatūras komponenti. Pēc iepriekšējā epizodē veiktās analīzes “Ļaunprātīgu pakotņu anatomija: Kādas ir tendences?"Tā kā ļaundari ievaino ļaunprātīgu uzvedību jaunos vai esošos publicētos komponentos, mēs esam gatavi uzvilkt ugunsdzēsības vestes un izpētīt, kā mēs varam veiksmīgi bloķēt šādā veidā piegādātu ļaunprātīgu programmatūru vai arī tikt galā ar potenciāli nopietnu kiberincidentu, ko izraisījis mūsu nepareizā pieeja."
Lielākajai daļai drošību apzinošu profesionāļu ir idejas par to, kā rīkoties ar šo apdraudējumu. Esam dzirdējuši drošības vadītājus bez vilcināšanās sakām, ka SCA rīki jau norāda, kad pakotnes versija ir ļaunprogrammatūra. Vai arī to, ka tie ir atkarīgi no labi zināmiem, augsti novērtētiem programmatūras komponentiem, kur jebkura ļaunprogrammatūra tiktu nekavējoties atklāta un noņemta. Tie izmanto atvērtas nelielas/ielāpu versijas, lai automātiski iegūtu ievainojamību labojumus, un tas ir pareizs, ieteicamais veids, kā samazināt atvērtā pirmkoda atkarību risku, ievērojot “ielāps agri, ielāps bieži”Princips.
Šajā epizodē mēs apskatīsim, kāpēc šīs idejas ir nepareizas un kā šādi maldīgi priekšstati veicina šī uzbrukuma mehānisma popularitāti un milzīgo risku, ar ko saskaras organizācijas. Noslēgumā aplūkosim, kas darbojas, un kādas pūles un resursi ir nepieciešami.
Bieži sastopami nepareizi uzskati
Mūsu ceļojumā ar programmatūras drošību mēs redzējām, kā attīstās uzbrukumu metodes un plašu ideju klāstu no cilvēkiem, kas apzinās drošību. Organizācijas bieži vien pārprot, kas darbojas pret šo apdraudējumu, tāpēc vispirms mēs aplūkosim, kas nedarbojas, apkopots šajā, nepilnīgajā, nepareizo priekšstatu sarakstā.
Nepareizs priekšstats Nr. 1: SCA rīki jau ziņo par ļaunprātīgām komponentēm
Patiešām! Bet pēc fakta... Kad, iespējams, ir par vēlu, ja elements tika izmantots programmatūras izveidē, un ļaundari jau ir ieguvuši pamatu izstrādātāja vai uzņēmuma ietvaros. CI/CD saimniekdators. Iespējams, ka noslēpumi ir tikuši nopludināti, lejupielādēta un instalēta papildu ļaunprogrammatūra, un, iespējams, pretinieks ir pārvietojies uz sāniem un jau ir ieguvis piekļuvi citur.
Programmatūras kompozīcijas analīze (SCA) rīki tika izstrādāti, lai identificētu potenciāli zināmas ievainojamības. Mūsdienu rīki lieliski veic darbu, palielinot signāla un trokšņa attiecību, nosakot, vai ievainojamība patiešām ir sasniedzama vai izmantojama. Taču tie ir bezjēdzīgi pret jaunu ļaunprogrammatūru. Iedomājieties ļaunprātīgu komponentu kā nulles dienas ievainojamību: tikai tad, kad tiek atklāta tā ļaunprātīgā darbība, komponents tiek ziņots glabāšanas reģistram, kas pēc drošības komandas pārskatīšanas tiek apstiprināts kā ļaunprātīgs un noņemts no reģistra. [1].
Tajā brīdī pasaule (ieskaitot SCAs) zina, ka komponenta (vai kādas(-u) esoša komponenta versijas(-u)) instalēšana vai lietošana nav ieteicama. Taču tas notiek tad, kad komponents nav pieejams reģistrā.Ir labi zināt, ka man ir trešo pušu komponentu ievainojamības vai pat komponenti, kurus reģistrs ir klasificējis kā ļaunprātīgus, bet diemžēl... SCA vai arī šajā kontekstā nepalīdz parastie audita rīki. Ja vien SCA/audit rīks patiešām var iepriekš zināt, ka komponents ir ļaunprātīgs, pirms tas tiek izmantots jūsu organizācijā..
Atcerieties, ka jebkuram risinājumam pret ļaunprātīgiem atvērtā pirmkoda komponentiem tie ir jāatklāj. lidojumāstarp brīdi, kad komponents tiek publicēts reģistrā, un brīdi, kad komponents (versija) tiek pirmo reizi izmantots jūsu organizācijā. Tas ietver arī tranzitīvos komponentus.
2. nepareizs priekšstats: instalācijas skriptu kontrole izveides laikā novērš ļaunprātīgu darbību no atvērtā pirmkoda komponentiem
Dažādi pakotņu pārvaldnieki piedāvā iespēju palaist skriptus (iekļauti komponentu tarball failā [2]), likumīgu iemeslu dēļ, piemēram, nepieciešamo vienumu kompilēšanai dažādās platformās, koda ģenerēšanai vai testu veikšanai, un mums visiem jāzina, ka ļaunprātīgi lietotāji tos var izmantot, ja tarball failā ir iekļauti ļaunprātīgi skripti vai ja uzbrucējs var likt palaist ļaunprātīgu skriptu labā skripta vietā.
Zinot to, mēs varam konfigurēt pakotņu pārvaldnieku tā, lai tas ignorētu skriptus. Piemēram, ar NPM – Ignorēt-skriptus karodziņš (vai konfigurācijas īpašība .npmrc fails) izlaiž skriptus instalēšanas laikā. Tas var radīt dažas problēmas, jo skriptu palaišana ir izplatīta daudzās ekosistēmās: daži pakotņu pārvaldnieki pat neļauj atspējot skriptu izpildi (padoms: uzvedne “Kuri pakotņu pārvaldnieki neļauj atspējot instalēšanas skriptu izpildi?"jūsu iecienītākajā mākslīgajā intelektā). Taču tas neaizsargā kopumā (mums jānodrošina, lai izlaišanas atspējošanas konfigurācija būtu visur).
Un, ja ļaunprātīgā rīcība neatrodas instalēšanas skriptos, bet gan programmatūrā, kas jāizpilda izpildlaikā, šī opcija vien mūs nepasargā.
3. nepareizais priekšstats: versiju piespraušana neļauj instalēt ļaunprātīgas komponentes
Pastāv kompromiss starp ielāpu agrīnu uzlikšanu un biežu ar atvērtās versijas (ļaujot pakotņu pārvaldniekam automātiski instalēt jaunus atjauninājumus, kad tie ir pieejami drošības labojumiem) un versijas piespraušana (kam ir visas tiešās un pārejošās atkarības programmatūrai fiksētā versijā). Drošības principi ir spītīgi un dažreiz pretrunīgi, kā tas notiek ar principu "ielāpojiet agri, ielāpojiet bieži" un “Uzlabošanu nevajadzētu uztvert vieglprātīgi”Daži pakotņu pārvaldnieki veic automātiskus atjauninājumus ar serveru diapazoniem, kā ieteikts. Lieliski, ja vēlaties saņemt arī ļaunprātīgos atjauninājumus! Jā, komponenti ir jāatjaunina, lai saņemtu drošības labojumus, kas pēc iespējas ātrāk novērš ievainojamības, taču… nekad neļaujiet pakotņu pārvaldniekam to darīt automātiski.
4. nepareizs priekšstats: uzticamu komponentu izmantošana ir droša. Jebkura ļaunprātīga versija tiktu nekavējoties atrasta, atklāta un noņemta.
Kāpēc komponents ir uzticams? Iespējams, tāpēc, ka tas ir ļoti populārs, daudzi meklē tā ievainojamības, tam ir liels skaits uzturēšanas dalībnieku un vairāki galvenie uzturētāji, kas rūpīgi pārskata visu. pull requestsRealitāte ir pavisam citāda. Dažas būtiskas komponentes uztur viens neapmaksāts izstrādātājs. Plaši izmantotiem ietvariem ir daži regulāri līdzstrādnieki, ar strauji sarūkošu skaitu commits uz vienu uzturētāju (populāriem projektiem ir gara līdzstrādnieku grupa, kas veic zināmu automātisku darbību) commit un nekad neatgriezīsies). Un ir daudz populāru projektu ar vienu uzturētāju.
Iedomājieties sevi sakām "Ak, mēs izmantojam Spring Boot / Angular / React / PyTorch / oficiālos Docker bāzes attēlus, tāpēc risks, par kuru jūs runājat, ir diezgan zems." Varbūt tā ir taisnība, mēs, drošības pakalpojumu sniedzēji, visu laiku biedējoši rīkojamies un iejaucamies izstrādes komandu darbā, lai mazinātu diskutablu risku, ir absurds. Jums varētu rasties kārdinājums pāriet uz riska pieņemšanas rindkopu (nākamajā sadaļā), un viss. Diemžēl populārākās sastāvdaļas ir ļaundaru mērķi, un, piemēram, populārais PyTorch bibliotēka tika uzbrukta pagātnē.
"Nekavējoties atrasts, atklāts un noņemts". Jauna ļaunprātīga komponenta noņemšana no publiskā reģistra aizņem vairākas dienas. Reģistri ir piesardzīgi attiecībā uz komponenta versijas noņemšanu, lai gan tas ir svarīgi. Mūsu pieredze rāda, ka pēc mūsu ziņojuma saņemšanas vidējais laiks, kas nepieciešams, lai reģistrs noņemtu skarto versiju, ir 39 stundas, kas ir vairāk nekā pusotra diena. Ir ļaunprātīgi komponenti, kas tiek noņemti reģistrā pat nedēļu pēc mūsu sākotnējā ziņojuma iesniegšanas. Dažos gadījumos komponents tiek noņemts tikai pēc tam, kad cietušais vai incidentu reaģēšanas uzņēmums ziņo par incidentu, kurā iesaistīts komponents.
Kas NEDROŠINA aizsardzību pret ļaunprātīgām komponentēm
Jebkura nespecifiska pieeja cietīs neveiksmi. Tas ir skaidrs — jūs nenodrošināt efektīvus pretpasākumus ar šo apdraudējumu saistītajam riskam.
Tradicionāls SCA Šie rīki informē par zināmu ļaunprogrammatūru, taču tiem ir ilgs iedarbības logs. Ja vien tie neveic proaktīvu ļaunprogrammatūras noteikšanu ar ļaunprātīgu komponentu piespiedu bloķēšanu, tie nedarbojas pret šo apdraudējumu.
Instalēšanas skriptu atspējošana varētu palīdzēt, taču tā ir jāievieš visur, kur ir jāinstalē komponents. Tas pats attiecas uz versiju piespraušanu, jo versijas nevar piespraust no droša sākotnējā stāvokļa uz visiem laikiem.
Pieņemt, ka populāriem komponentiem tiek pievērsta pietiekama uzmanība, lai tiem nevarētu tikt ievadīta neparedzēta uzvedība piegādes ķēdes uzbrukumā bez gandrīz tūlītējas atklāšanas, lai novērstu jebkādus bojājumus, ir naivi un riskanti. Jūs taču nevēlaties dzīvot uz robežas, vai ne?
Ja apstāsieties šajā brīdī, tad riska pieņemšana ir vienīgais, ko jūs varat darīt: Šī ir deciskas jādokumentē jūsu apdraudējuma modelī/riska novērtējumā, tostarp riska pieņemšanas pamatojums un tā iespējamās sekas. Veiciniet informētību, paziņojot par to vadībai un citām attiecīgajām pusēm. Dažas neparedzētiem gadījumiem varētu tikt plānots, ja jūsu programmatūrā ir instalēts vai iekļauts ļaunprātīgs komponents, taču tas ir sarežģīti, jo uzbrucējiem ir daudz ceļu, pa kuriem sekot. Piegādes ķēdes uzbrukuma detaļas, kuru pamatā ir ļaunprātīga komponenta izmantošana, krasi mainīs incidenta publiskošanu, kas, iespējams, ir obligāta saskaņā ar jūsu organizācijas normatīvo regulējumu. Jūs varat arī pievērsties kompensējošās kontroles or pārskaitījuma risks piemēram, ar apdrošināšanu.
Tomēr pastāv kontroles mehānismi, kas novērš apdraudējumu, un tie būtu jāapsver, ja neesat apmierināts ar riska pieņemšanu. Lūdzu, lasiet tālāk.
Kas darbojas pret uzbrukumiem, izmantojot ļaunprātīgas komponentes
Cieto versiju apstrāde
Versiju piespraušana ar kontrolētiem un informētiem versiju labojumiem ir risinājums, lai līdzsvarotu nepieciešamību novērst ievainojamības, nesaņemot ļaunprogrammatūru. Taču atcerieties 3. nepareizo priekšstatu: versiju piespraušana vien nepietiek, lai bloķētu ļaunprātīgu kodu no jaunām versijām, jo nākotnē jums būs jāatjaunina versijas jebkādā tiešā vai netiešā atkarībā. Šajā brīdī jums ir nepieciešami pietiekami spēcīgi pierādījumi, ka visās modificētajās versijās nav ļaunprogrammatūras.
Agrīna brīdināšana
Viena no pieejām ļaunprātīgo komponentu problēmai ir agrīnās brīdināšanas sistēma (šeit nosaukta par Agrīnā brīdināšana pret ļaunprogrammatūru jeb MEW), kur noteikšanas programma analizē jaunās publicētās versijas (jaunām vai esošām komponentēm), kas, atrodot pietiekami daudz pierādījumu, var klasificēt jauno versiju kā potenciāli ļaunprātīgu.
Šeit būtiska ir automatizācija, jo nav iespējams manuāli pārskatīt visus jaunos komponentus ar pašreizējo publicēšanas ātrumu. Tāpēc noteikšanas programmai ir jāapvieno dažādas metodes, iespējams, tostarp statiskā, dinamiskā un spēju analīze, lietotāja reputācija un pierādījumi, kas iegūti no neatbilstībām starp komponentu metadatiem un tarball saturu vai starp tarball un avota krātuvi, no kuras komponents it kā nāk.
Ir tumšā zona starp publicēšanas laiku un brīdi, kad programma analizē komponentu saturu, taču tam nevajadzētu pārsniegt dažas minūtes. Shēmu var mainīt, piemēram, gaidot, kamēr jauni komponenti tiek analizēti, pirms tos var instalēt un izmantot programmatūras būvējumā. pipelinevai analizēt tos pēc pieprasījuma, kad tas nepieciešams. Komponents noteiktā versijā ir nemainīgs. [3], tāpēc tas ir jāanalizē tikai vienu reizi.
Pilnīga automatizācija nav iespējama, un ir nepieciešama drošības pārbaude, lai noteiktu potenciāli ļaunprātīgas komponentes. Uzmanieties no digitālo panacejas atbalstītājiemMākslīgais intelekts un mašīnmācīšanās nav pietiekami attīstītas, lai pieņemtu pēdējo lēmumu par aizdomīga komponenta ļaunprogrammatūras esamību. Protams, mašīnmācīšanās spēlē galveno lomu noteikšanas programmā, klasificējot ievades komponentu no iegūtajiem neapstrādātajiem pierādījumiem, taču, kad komponents ir “iekļauts karantīnā”, pēdējais vārds ir manuāli jāpārskata, ko veic drošības komanda ar pieredzi ļaunprātīgu komponentu jomā. Tas apstiprina jebkādu potenciālu ļaunprogrammatūru vai pārklasificē to kā drošu. Un laika periods ir aptuveni stundas.
Reģistrs ziņo par ļaunprātīgo versiju/komponentu; pēc tam reģistrs veic pārbaudi, lai apstiprinātu, un turpina publisku izpaušanu un noņemšanu no reģistra. Daži reģistri glabā drošības glabāšanas paketi. Šeit norādītais laika diapazons ir dienas vai nedēļas kopš publicēšanas, kas ir "aiztures laiks"vai"ekspozīcijas logs'vairumam ļaunprātīgo komponentu.
Vai ir iespējams zināt, vai komponenta versija ir ļaunprātīga?
Tātad, lai nodrošinātu agrīnu brīdināšanu, mums ir jāsniedz apmierinoša atbilde uz šo jautājumu: Kā es varu zināt, ka bibliotēka vai pakotne ir (nav) ļaunprātīga? Kā savākt pietiekami daudz pierādījumu par ļaunprātīgu rīcību? Iespējams, bet sarežģīti, jo pretinieki izmanto lielu atjautību, lai izvairītos no atklāšanas. Pastāv dažādas pieejas, katrai no tām ir plusi un mīnusi.
Statiskā analīze var pārbaudīt visus izpildes ceļus, pārbaudīt uzbrucēju izmantotās metodes, nepalaižot komponentu, un veikt priekšapstrādes uzdevumus, piemēram, atšifrēšanu vai slēpšanu. Tā kā uzbrucēji cenšas slēpt savus ļaunprātības, slēpšanas mēģinājumi patiešām liecina par ļaunprogrammatūru (taču ņemiet vērā, ka likumīgi komponenti slēpj kodu, lai saglabātu intelektuālo īpašumu, kas ir pretrunā ar "atvērtā koda"). Tikai nelielai daļai ļoti sarežģītu uzbrukumu ar spēcīgu slēpšanu ir nepieciešama "smilškastes" metode, taču šāda spēcīga slēpšana ir ļaunprātīgas rīcības pazīme. Lūdzu, ņemiet vērā, ka parastās SAST rīki tika izstrādāti netīšām ievainojamībām, nevis ļaunprātīgiem nolūkiem, piemēram, aizmugurējām durvīm.
Dinamiskā analīze palaiž komponentu un pārbauda atbildi, instrumentējot izpildlaiku, parasti nodrošinot smilškastes vidi. Ļaunprātīga rīcība, kas tiek aktivizēta noteiktos apstākļos, var palikt nepamanīta: lūdzu, ņemiet vērā, ka ļaunprogrammatūra var izmantot izvairīšanās metodes, piemēram, Virtualizācijas/smilškastes apiešana aktivizēties tikai tad, ja tas netiek rūpīgi pārbaudīts, un tā ir arī ļaunprātīgas darbības pazīme jebkurai statiskās analīzes programmai.
Spēju analīze ņem vērā komponenta darbības: kur tas izveido savienojumu, kuriem failiem tas piekļūst, kuras komandas vai programmas tiek palaistas, terminālis vai ierīces I/O tiek veikta vai kuri sistēmas izsaukumi tiek izsaukti. Šo uzvedības pirkstu nospiedumu noteikšanu (esošajam komponentam) varētu salīdzināt dažādās versijās, tāpēc, konstatējot negaidītu uzvedību, šie pierādījumi varētu radīt aizdomas par potenciālu ļaunprātīgu darbību, kas ievadīta jaunajā versijā. Šī pieeja seko triāžas soļiem, ko drošības analītiķi veic, saskaroties ar potenciālu ļaunprogrammatūru: pārbaude, izmantojot virknes vai līdzīgi rīki. Šī pieeja atklāj ļaunprātīgu rīcību neatkarīgi no aktivizēšanas nosacījumiem un darbojas, ja nav pieejams pirmkods.
Konteksta analīze apkopo informāciju par to, kā un kas publicēja komponentu. Ļaunprātīgas darbības veicēju kampaņas bieži izmanto jaunu(-us) lietotāja kontu(-us), kas netiek pakļauts nekādam stingram pārbaudes procesam. Iepriekšējās darbības izsekošana var sniegt ieskatu par attiecīgo lietotāju, galvenokārt attiecībā uz anomālijām, kas var liecināt par iespējamu apdraudējumu. Reputāciju ir tik grūti iegūt un tik viegli zaudēt! Lietotājs bez iepriekšējas aktivitātes ir neitrāls, bet karma vajā ļaunprātīgos. Haktīvisti jeb parastie lietotāji, kuriem ir nozagti publicēšanas dati, ir rūpīgi jāseko līdzi.
Cita kontekstuālā informācija ir jebkāda neatbilstība starp avota repozitoriju, kas it kā izmantots komponentu tarball izveidei, un paša tarball saturu. Kā arī labas prakses ievērošana, piemēram, tagu vai laidienu izveide avota repozitorijā, kas atbilst komponentu versijām, kas publicētas publiskajā reģistrā. Kad avota repozitorijs konkrētā vietā commit ir atzīmēts ar tagu “release” (izlaidums), un tad pēkšņi viena versija tam neseko, tas vien jau ir spēcīgs pierādījums tam, ka komponents varētu būt inficēts: ļaunprātīgais dalībnieks, iespējams, ir apdraudējis kontu, kas izmantots komponenta publicēšanai, taču viņam nav rakstīšanas atļauju pirmkoda krātuvē). Izmantojot šos noteikumus, tiek regulāri atklāti daudzi uzbrukumi: piemēram, Ledger uzbrukums varētu viegli atklāt šādā veidā. Tāpēc konteksta analīze identificē šādas anomālijas publicēšanas procesā.
Atkarību ugunsmūris
Cita pieeja ir izveidot visaptverošu komponentu balto sarakstu visām atkarību diagrammām, kas tiek izmantotas jūsu programmatūrā, tāpēc jebkurā versijā pipeline Jūsu organizācijā var instalēt un izmantot tikai apstiprinātas komponentu versijas.ugunsmūris"tiek ieviests, izmantojot iekšējo reģistru, kurā tiek nodrošināti atļauto komponentu versiju tarball faili (kešatmiņā vai starpniekservera režīmā). Lūdzu, ņemiet vērā, ka neviens baltais saraksts nedarbosies, ja vien jums nav tehnoloģijas, lai klasificētu jebkuru jaunu versiju kā pietiekami drošu, lai to varētu pievienot baltajam sarakstam.
Lūdzu, ņemiet vērā, ka agrīnā brīdināšana (ātra noteikšana pēc iespējas ātrāk pēc jaunās versijas publicēšanas) ir jāapvieno ar veidu, kā proaktīvi izmantot šo informāciju, lai bloķētu komponentu, kas ietekmē būvējumu. pipelinevai izstrādātāju mašīnas [4]Mēs to saucam par “atkarības ugunsmūris”: karantīnas mehānisms automatizētu versiju aizsardzībai pret ļaunprātīgām pakotnēm. Iekšējās pakotnes un attēlu reģistri ir labi, lai organizācijas būtu pasargātas no ārēja ļaunuma, taču ir nepieciešami pietiekami spēcīgi pierādījumi, lai karantīna būtu efektīva.
Izpildes laika smilškaste
Alternatīva pieeja noteikšanai publicēšanas laikā ir analizēt uzvedību izpildes laikā. Ideja ir uztvert paredzamo programmatūras uzvedību un atklāt (vai bloķēt) visas atrastās anomālijas. Šīs rīcības problēma ir tā, ka izpildes laiks ir jāinstrumentē uzraudzībai vai bloķēšanai, un tā ir daudzsološa ideja, kas tiks pievienota aizsardzības mehānismu arsenālam pret ļaunprātīgo komponentu kaitēkļiem.
Visaptverošas stratēģijas izstrāde
Ieteicamajā stratēģijā ir jāapvieno dažādas metodes programmatūras izstrādes procesā, pārņemot kontroli pār versiju atjauninājumiem, lai bloķētu ienākošos ļaunprātīgos komponentus. Mums ir jānodrošina versiju piespraušana, lai izvairītos no automātiskas inficēšanās, atjauninot versijas, lai iegūtu labojumus nozīmīgām ievainojamībām; ātra un efektīva tiešo un netiešo atkarību novērtēšana versiju atjauninājumu laikā, lai iegūtu pietiekamus pierādījumus, ka tās nav inficētas ar ļaunprogrammatūru. Ir jābloķē programmatūras versijas, kas ir atkarīgas no zināmiem ļaunprātīgiem komponentiem. Un tas viss ir jāievieš.
Ja iespējams, izmantojiet versiju piespraušanu, jo tā atvieglo būvējumu atkārtojamību. Versiju piespraušana ar kontrolētiem, manuāli apstiprinātiem versiju uzlabojumiem, un ar palīgtehnoloģiju palīdzību, jānovērtē, vai atjauninājums rada ļaunprogrammatūru vai sabojā programmatūru, un jāsaskaņo atjaunināšana ievainojamību novēršanai ar ļaunprogrammatūras infekcijas novēršanu. Šeit var palīdzēt rīki, (1) prioritāri nosakot, kuras ievainojamības patiešām ir svarīgas (sasniedzamas un izmantojamas, ar augstu uzbrucēju mērķauditorijas risku), (2) izvēloties mērķa versijas, kas ir saderīgas ar pašreizējo komponentu lietojumu un nesabojā programmatūru, (3) izvēloties mērķa versijas, kas nesatur ļaunprātīgu darbību, un (4) padarot versiju atjaunināšanu tiešām un netiešām atkarībām vienkāršu, iesakot izmaiņas manifesta failos, kuras varētu ātri apstiprināt. (3) solī ir nepieciešama konkrēta informācija par ļaunprātīgajiem komponentiem pēc iespējas tuvāk to publicēšanas laikam.
Šim atkarību atjaunināšanas procesam ir jābūt piespiedu kārtā un pārbaudīts visās vietās. Process ir jādokumentē, un visas iesaistītās puses ir jāapmāca, jo programmatūras izstrāde un izveide/ieviešana bieži tiek ārpakalpojumā. CI/CD pipelines ir attiecīgi jāmaina, lai automatizācija neļautu ļaunprātīgai netiešai atkarībai iekļūt būvējumā: guardrails Ieteicamais rīcības veids ir būvējuma bloķēšana, ja atkarībā ir pietiekami daudz pierādījumu par iespējamu ļaunprogrammatūru.
Ja jūsu organizācijai ir iekšējs reģistrs, kas darbojas kā drošības starpniekserveris atļauto komponentu versiju glabāšanai, pirms pievienot pieprasīto komponentu atļauju sarakstam, jums ir jāiegūst informācija par ļaunprātīgajiem komponentiem (papildus citiem kritērijiem), lai pārbaudītu to.
Droši lietot atvērtā pirmkoda programmatūru nav viegli, un ir pilnībā jāņem vērā ļaunprogrammatūras faktors, pieliekot līdzīgas pūles ievainojamību novēršanai.
Viena pēdējā piezīme: Avota izcelsme, programmatūras apliecinājumu veidā, kas ģenerēti komponentes būvēšanas laikā, ir vēl viens svarīgs elements centienos izsekot artefaktu (komponentes tarball) ar avotiem un būvēšanas procesu, kas to radīja. Ņemiet vērā, ka šī saikne starp avota momentuzņēmumu + būvēšanas vidi un saistīto programmatūras artefaktu (ko parakstījusi uzticama būvēšanas sistēma) pati par sevi neliedz komponentam nesaturēt ļaunprātīgu darbību, bet gan apgrūtina ļaundariem ļaunprogrammatūras injicēšanu. Izcelsmes validācijas ieviešana par vispārēju prasību atvērtā pirmkoda komponentu patērēšanai prasīs ilgu laiku, un tikai nesen pievienots NPMPadarīt šīs uzticamās izveides un izvietošanas sistēmas drošas pret viltojumiem vai nodrošināt jebkādas izveides laikā veiktās manipulācijas atklāšanu ir cits stāsts, kas neietilpst šī ieraksta tvērumā.
Papildu informācija
Nākamā epizode Atvērtā pirmkoda ļaunprātīgās pakotnes: Xygeni pieeja iepazīstinās ar stratēģiju, ko mēs ievērojam Xygeni mūsu Agrīnā brīdināšana pret ļaunprogrammatūru (MEW) sistēma. Jaunas pakotņu versijas publiskajos pakotņu un attēlu reģistros tiek skenētas, un pierādījumi tiek iegūti, izmantojot statiskās, dinamiskās, iespēju un kontekstuālās analīzes kombināciju. Pierādījumi apvienojumā ar lietotāja reputāciju un izmaiņu vēsturi pirmkoda krātuvēs ļauj pilnībā automatizēti klasificēt komponentu augsta riska un, iespējams, ļaunprātīgās kategorijās. Sistēma mācās no iepriekšējiem pierādījumiem, kas apkopoti no pakotnēm, lai līdz minimumam samazinātu kļūdaini pozitīvu rezultātu skaitu.
Abonētās organizācijas saņem brīdinājuma paziņojumu par komponentiem, ko tās izmanto tieši vai netieši, kad tiek kategorizēta ļaunprātīga versija. Pēc tam mūsu analītiķi veic manuālu analīzi, kas apstiprina vai noraida klasifikāciju. Apstiprinātas ļaunprogrammatūras gadījumā tiek informēts publiskais reģistrs, lai tas varētu veikt savu analīzi un parasti noņemt ļaunprātīgo versiju vai veikt papildu darbības, piemēram, bloķēt vai noņemt attiecīgo lietotāja kontu.
Mēs paskaidrosim, kā mēs palīdzam NPM, PyPI, GitHub un citām galvenajām atvērtā pirmkoda ekosistēmas infrastruktūrām samazināt laiku, kurā publicēts jauns ļaunprātīgs komponents paliek aktīvs, līdz tas tiek apstiprināts kā ļaunprogrammatūra un noņemts no reģistra. Un kā organizācijas var gūt labumu no MEW sistēmas, lai iegūtu daudz labāku aizsardzību pret programmatūras piegādes ķēdes uzbrukumiem, kuros iesaistīti atvērtā pirmkoda komponenti.
- [1] Jebkurā gadījumā komponentes lietotājiem ir jāpārbauda, vai komponentes tarball ir kešatmiņā vai kaut kur reģistrēts, piemēram, iekšējā reģistrā, lai problēma tiktu izskausta.
- [2] Iepakotajā komponentā ir iekļauts manifests, kas deklarē tā saturu un metadatus, pirmkodu vai kompilēto kodu, instalēšanas skriptus un papildu vienumus, piemēram, testu komplektus, saskaņā ar iepakošanas formātu un parasti saspiestā veidā. To sauc par “komponentu tarball”.
- [3] Pat ja ļaunprātīgais dalībnieks var modificēt publicētu komponentu reģistra pārkāpuma dēļ, vienkāršs kriptogrāfisks apkopojums var atklāt jebkādas izmaiņas tarball failā pēc analīzes veikšanas.
- [4] Atcerieties, ka daži ļaunprātīgi komponenti darbojas instalēšanas laikā, tāpēc tas var ietekmēt izstrādātāju mezglus, kas netīšām palaiž “npm install X” ar X kā ļaunprātīgu komponentu.
