Tämä on kolmas jakso sarjassa artikkeleita yleisimmistä ohjelmistojen toimitusketjuhyökkäysten tyypeistä: hyökkäyksistä, jotka väärinkäyttävät julkista rekisteriä avoimen lähdekoodin ohjelmistokomponentteja. Edellisessä jaksossa analysoituamme…Haittaohjelmien anatomia: Mitkä ovat trendit?”Kun otetaan huomioon, miten pahantahtoiset toimijat lisäävät haitallista toimintaa uusiin tai olemassa oleviin julkaistuihin komponentteihin, olemme valmiita pukemaan sammutusliivejämme ja tutkimaan, kuinka voimme onnistuneesti estää tällä tavoin toimitetut haittaohjelmat tai vaihtoehtoisesti käsitellä mahdollisesti vakavaa kyberongelmaa, joka johtuu väärästä lähestymistavasta.”
Useimmilla turvallisuustietoisilla ammattilaisilla on ideoita siitä, miten käsitellä tätä uhkaa. Olemme kuulleet turvallisuuspäälliköiden sanovan epäröimättä, että SCA työkalut kertovat jo, milloin pakettiversio on haittaohjelma. Tai että ne ovat riippuvaisia tunnetuista ja paljon arvostetuista ohjelmistokomponenteista, joissa kaikki haittaohjelmat havaitaan ja poistetaan nopeasti. Ne käyttävät avoimia pienimpiä/korjausversioita haavoittuvuuksien automaattiseen korjaamiseen, ja se on oikea ja suositeltu tapa pienentää avoimen lähdekoodin riippuvuuksien riskiä noudattaen "paikka aikaisin, paikka usein”-Periaate.
Tässä jaksossa tarkastelemme, miksi nämä ajatukset ovat virheellisiä ja miten tällaiset väärinkäsitykset lisäävät tämän hyökkäysmekanismin suosiota ja aiheuttavat organisaatioille valtavan riskin. Lopuksi käsittelemme sitä, mikä toimii, ja mitä vaivaa ja resursseja siihen liittyy.
Yleisiä väärinkäsityksiä
Ohjelmistoturvallisuuden parissa tekemämme matkan aikana näimme hyökkäystekniikoiden kehittyvän ja turvallisuustietoisilta ihmisiltä esitettiin monenlaisia ideoita. Organisaatiot ymmärtävät usein väärin, mikä toimii tätä uhkaa vastaan, joten ensin tarkastelemme, mikä ei toimi, tiivistettynä seuraavaan, ei tyhjentävään, väärinkäsitysten luetteloon.
Väärinkäsitys # 1: SCA työkalut raportoivat jo haitallisista komponenteista
Todellakin! Mutta jälkikäteen... Kun on luultavasti liian myöhäistä, jos elementtiä on käytetty ohjelmistokehityksessä ja pahat toimijat ovat jo saaneet jalansijaa kehittäjässä tai CI/CD isäntä. Salaisuuksia on saatettu vuotaa, lisää haittaohjelmia on ladattu ja asennettu, ja ehkä vastustaja on liikkunut sivusuunnassa ja jo saanut pääsyn muualle.
Ohjelmiston koostumusanalyysi (SCA) työkalut on suunniteltu tunnistamaan mahdollisia tunnettuja haavoittuvuuksia. Nykyaikaiset työkalut tekevät erinomaista työtä parantamalla signaali-kohinasuhdetta ja määrittämällä, onko haavoittuvuus todella saavutettavissa tai hyödynnettävissä. Mutta ne ovat hyödyttömiä uusia haittaohjelmia vastaan. Ajattele haitallista komponenttia nollapäivähaavoittuvuutena: Vasta kun sen haitallinen toiminta havaitaan, komponentista ilmoitetaan rekisteriin, joka tietoturvatiimin tarkistuksen jälkeen vahvistetaan haitalliseksi ja poistetaan rekisteristä. [1].
Tuolloin maailma (mukaan lukien SCAs) tietää, että komponentin (tai jonkin olemassa olevan komponentin version/versioiden) asentaminen tai käyttäminen ei ole hyvä asia. Mutta tämä on silloin, kun komponentti ei ole saatavilla rekisteristäOn hyvä tietää, että minulla on haavoittuvuuksia kolmannen osapuolen komponenteissa tai jopa komponenteissa, jotka rekisteri on luokitellut haitallisiksi, mutta valitettavasti SCA tai yleiset tarkastustyökalut eivät auta tässä yhteydessä. Ellei SCA/audit-työkalu voi todella tietää etukäteen, onko komponentti haitallinen, ennen kuin sitä käytetään organisaatiossasi.
Muista, että kaikkien haitallisia avoimen lähdekoodin komponentteja vastaan suunniteltujen ratkaisujen on havaittava ne. lennossa, komponentin rekisterissä julkaisemisen ja komponentin (version) ensimmäisen organisaatiossasi käyttöönoton välillä. Tämä sisältää transitiiviset komponentit.
Väärinkäsitys nro 2: Asennusskriptien hallinta koontivaiheessa estää avoimen lähdekoodin komponenttien haitallisen toiminnan
Useat pakettienhallinnan ohjelmat tarjoavat mahdollisuuden suorittaa komentosarjoja (jotka sisältyvät komponenttien tarball-tiedostoon) [2]), oikeutetuista syistä, kuten pakollisten kohteiden kääntäminen eri alustoille, koodin luominen tai testien suorittaminen, ja meidän kaikkien tulisi tietää, että pahantahtoiset toimijat voivat väärinkäyttää niitä, jos tarballiin sisältyy haitallisia skriptejä tai jos hyökkääjä saa aikaan haitallisen skriptin suorittamisen oikean skriptin sijaan.
Tämän tietäen voimme määrittää paketinhallinnan jättämään skriptit huomiotta. Esimerkiksi NPM:n avulla –Ignore-komentosarjat lippu (tai määritysominaisuus kohdassa .npmrc-tiedosto tiedosto) ohittaa skriptit asennuksen aikana. Tämä voi aiheuttaa ongelmia, koska skriptien suorittaminen on yleistä monissa ekosysteemeissä: Jotkut pakettienhallinnan paketinhallintaohjelmat eivät edes salli skriptien suorittamisen poistamista käytöstä (vihje: kehote “Mitkä pakettienhallinnan ohjelmat eivät salli asennusskriptien suorittamisen poistamista käytöstä?”suosikki tekoälyssäsi). Mutta tämä ei suojaa yleisesti (meidän on varmistettava, että ohituksen estoasetus on kaikkialla).
Ja kun haitallinen toiminta ei sijaitse asennusskripteissä, vaan ajonaikana suoritettavassa ohjelmistossa, tämä vaihtoehto yksinään ei suojaa meitä.
Väärinkäsitys nro 3: Versioiden kiinnittäminen estää haitallisten komponenttien asentamisen
Aikaisen paikantamisen ja usein tapahtuvan paikantamisen välillä on kompromissi avoimet versiot (antaa paketinhallintaohjelman asentaa automaattisesti uudet päivitykset, kun niitä on saatavilla tietoturvakorjauksille) ja version kiinnittäminen (jolla on kaikki suorat ja transitiiviset riippuvuudet ohjelmistolle kiinteässä versiossa). Tietoturvaperiaatteet ovat itsepäisiä ja joskus ristiriitaisia, kuten käy "korjaa aikaisin, korjaa usein" -periaatteelle ja "Päivitystä ei pidä ottaa kevyesti"Jotkin pakettienhallinnan ohjelmat tekevät automaattisia päivityksiä palvelinalueilla suositellulla tavalla. Loistava vaihtoehto, jos haluat vastaanottaa myös haitallisia päivityksiä! Kyllä, komponentit on päivitettävä, jotta ne saavat haavoittuvuuksia korjaavia tietoturvakorjauksia mahdollisimman pian, mutta… älä koskaan anna pakettienhallinnan tehdä tätä automaattisesti.
Väärinkäsitys nro 4: Luotettavien komponenttien käyttö on turvallista. Kaikki haitalliset versiot löydettäisiin, paljastettaisiin ja poistettaisiin nopeasti.
Miksi komponenttiin luotetaan? Mahdollisesti siksi, että se on erittäin suosittu, monet silmäparit etsivät sen haavoittuvuuksia, suuri määrä ylläpitäjiä ja useita ydinylläpitäjiä, jotka tarkistavat kaikki tiedot huolellisesti. pull requestsTodellisuus on aivan toinen. Joitakin olennaisia komponentteja ylläpitää yksi ainoa, palkaton kehittäjä. Laajalti käytetyillä kehyksillä on muutama vakituinen avustaja, ja niiden määrä vähenee nopeasti commitylläpitäjää kohden (suosituilla projekteilla on pitkä joukko avustajia, jotka suorittavat jonkinlaisia ohitustoimintoja) commit ja eivät koskaan palaa). Ja suosittuja projekteja, joilla on vain yksi ylläpitäjä, on runsaasti.
Kuvittele itsesi sanovan "Käytämme Spring Bootin / Angularin / Reactin / PyTorchin / virallisia Dockerin peruskuvia, joten mainitsemasi riski on melko pieni." Ehkä se on totta, me tietoturvatoimittajat lietsomme pelottelua koko ajan ja sekaannumme kehitystiimien toimintaan kyseenalaisen riskin lieventämiseksi, mikä on hölynpölyä. Saatat tuntea kiusausta siirtyä riskin hyväksymistä käsittelevään kappaleeseen (seuraavassa osiossa) ja siinä kaikki. Valitettavasti suosituimmat komponentit ovat pahojen toimijoiden kohteita, ja esimerkiksi suosittu PyTorch-kirjastoon hyökättiin aikaisemmin.
"Löydetty, julkistettu ja poistettu viipymättä". Uuden haitallisen komponentin poistaminen julkisesta rekisteristä kestää päiviä. Rekisterit ovat varovaisia komponenttiversion poistamisessa, jos se on mahdollista. Kokemuksemme mukaan rekisteri poistaa kyseisen version mediaaniaika on 39 tuntia, yli puolitoista päivää, kun olemme tehneet ilmoituksen. Rekistereissä on haitallisia komponentteja, jotka poistetaan vasta viikon kuluttua alkuperäisestä ilmoituksestamme. Joissakin tapauksissa komponentti poistetaan vasta sen jälkeen, kun uhri tai tapaukseen reagoiva yritys on ilmoittanut komponenttiin liittyvästä tapauksesta.
Mikä EI toimi haitallisia komponentteja vastaan
Mikä tahansa epämääräinen lähestymistapa epäonnistuu surkeasti. Tämä on varmaa, ettet tarjoa tehokkaita vastatoimia tähän uhkaan liittyvälle riskille.
Perinteinen SCA Työkalut kertovat tunnetuista haittaohjelmista, mutta niillä on pitkä altistumisikkuna. Ellei ne suorita ennakoivaa haittaohjelmien tunnistusta ja pakotettua haitallisten komponenttien estämistä, ne eivät toimi tätä uhkaa vastaan.
Asennusskriptien poistaminen käytöstä voi auttaa, mutta sitä on noudatettava kaikkialla, mihin komponentti on asennettava. Sama pätee versioiden kiinnittämiseen, koska versioita ei voida kiinnittää turvallisesta alkutilasta ikuisesti.
On naiivia ja riskialtista olettaa, että suositut komponentit saavat riittävästi huomiota, jotta niihin ei voida syöttää tahatonta toimintaa toimitusketjuhyökkäyksessä ilman lähes välitöntä havaitsemista vahinkojen estämiseksi. Et kai halua elää reunalla?
Jos pysähdyt tähän kohtaan, niin riskin hyväksyminen on ainoa mitä voit tehdä: Tämä on decisjoka on dokumentoitava uhkamallissasi/riskinarvioinnissasi, mukaan lukien riskin hyväksymisen perustelut ja sen mahdolliset seuraukset. Lisää tietoisuutta siitä viestimällä johdolle ja muille asiaankuuluville tahoille. Jotkut ennakoimattomia voitaisiin suunnitella, kun haitallinen komponentti asennetaan tai sisällytetään ohjelmistoosi, mutta tämä on vaikeaa, koska hyökkääjillä on monia polkuja seurattavanaan. Haitallisen komponentin käyttöön perustuvan toimitusketjuhyökkäyksen yksityiskohdat muuttavat dramaattisesti tapahtuman julkistamista, mikä on todennäköisesti pakollista organisaatiosi sääntelykehyksen nojalla. Voit myös käsitellä kompensoivat kontrollit or siirtoriski esim vakuutuksen kanssa.
On kuitenkin olemassa toimenpiteitä, jotka puuttuvat uhkaan, ja niitä kannattaa harkita, jos et ole tyytyväinen riskin hyväksymiseen. Lue lisää.
Mikä toimii haitallisia komponentteja käyttäviä hyökkäyksiä vastaan
Solid-versioiden käsittely
Versioiden kiinnittäminen hallituilla ja tietoon perustuvilla versioiden muutostöillä on oikea tapa tasapainottaa haavoittuvuuksien poistamisen tarvetta ilman haittaohjelmien vastaanottamista. Muista kuitenkin väärinkäsitys nro 3: Pelkkä versioiden kiinnittäminen ei riitä estämään haitallisen koodin tulevan uusista versioista, koska sinun on tulevaisuudessa päivitettävä versioita kaikissa suorissa tai epäsuorissa riippuvuuksissa. Tuolloin tarvitset riittävän vahvat todisteet siitä, että kaikki muokatut versiot eivät sisällä haittaohjelmia.
Aikainen varoitus
Yksi lähestymistapa haitallisten komponenttien ongelmaan on varhaisvaroitusjärjestelmä (tässä nimeltään Haittaohjelmien varhainen varoitus tai MEW), jossa tunnistusmoottori analysoi julkaistut uudet versiot (uusista tai olemassa olevista komponenteista) ja voi luokitella uuden version mahdollisesti haitalliseksi, jos todisteita löytyy riittävästi.
Automaatio on tässä olennaista, koska kaikkien uusien komponenttien manuaalinen tarkistaminen nykyisellä julkaisuvauhdilla on mahdotonta. Siksi tunnistusmoottorin on yhdistettävä useita tekniikoita, mukaan lukien ehkä staattinen, dynaaminen ja ominaisuusanalyysi, käyttäjän maine sekä todisteet komponenttien metatietojen ja tarball-sisällön välisistä eroista tai tarball-sisällön ja lähdetietovaraston välisistä eroista, josta komponentin oletetaan olevan peräisin.
Tuolla on pimeä alue julkaisuajan ja moottorin komponenttien sisällön analysoinnin välillä, mutta sen ei tulisi ylittää muutamaa minuuttia. Järjestelmää voidaan muokata esimerkiksi odottamalla uusien komponenttien analysointia ennen niiden asentamista ja käyttöä ohjelmiston koonnissa. pipelinetai analysoida niitä tarvittaessa. Tietyn version komponentti on muuttumaton [3], joten se tarvitsee analysoida vain kerran.
Täysi automatisointi ei ole mahdollista, ja mahdollisesti haitallisten komponenttien varalta tarvitaan tietoturvatarkastus. Varo digitaalisten ihmelääkkeiden kannattajiaTekoäly ja koneoppiminen eivät ole vielä tarpeeksi kehittyneitä ottamaan viimeistä sanaa, kun on kyse epäilyttävän komponentin haittaohjelmien varmentamisesta. Koneoppimisella on toki keskeinen rooli tunnistusmoottorissa syöttökomponentin luokittelussa tallennetun raakatiedon perusteella, mutta kun komponentti on "karanteenissa", lopullinen sana kuuluu manuaaliselle tarkistukselle, jonka tekee tietoturvatiimi, jolla on kokemusta haitallisten komponenttien kanssa. Tämä vahvistaa mahdolliset haittaohjelmat tai luokittelee ne uudelleen turvalliseksi. Ja ajanjakso on tuntien luokkaa.
Rekisteri raportoi haitallisesta versiosta/komponentista; rekisteri suorittaa sitten tarkistuksen vahvistaakseen sen ja jatkaa julkista paljastamista ja poistamista rekisteristä. Jotkut rekisterit säilyttävät suojauspakettia. Aikaväli tässä on päiviä tai viikkoja julkaisusta, joka on 'viipymisaika"Tai"valotusikkuna'useimmille haitallisille komponenteille.
Onko mahdollista tietää, onko komponenttiversio haitallinen?
Jotta voimme saada varhaisen varoituksen, meidän on annettava tyydyttävä vastaus tähän kysymykseen: Mistä voin tietää, että kirjasto tai paketti on (ei ole) haitallinen? Miten kerätä tarpeeksi todisteita haitallisesta toiminnasta? Mahdollista, mutta vaikeaa, koska vastustajat käyttävät paljon kekseliäisyyttä välttääkseen havaitsemisen. On olemassa erilaisia lähestymistapoja, joilla jokaisella on hyvät ja huonot puolensa.
Staattinen analyysi voi tutkia kaikki suorituspolut, tarkistaa hyökkääjien käyttämiä tekniikoita suorittamatta komponenttia ja suorittaa esikäsittelytehtäviä, kuten hämärryksen poistamisen tai salauksen purkamisen. Kun hyökkääjät yrittävät peittää ilkivaltansa, hämärrysyritykset ovat todellakin todiste haittaohjelmasta (mutta on huomattava, että lailliset komponentit hämärtävät koodia immateriaalioikeuksien suojaamiseksi, mikä on ristiriidassa "avoimen lähdekoodin"). Vain vähemmistö erittäin kehittyneistä hyökkäyksistä, joissa käytetään vahvaa hämärtämistä, tarvitsee hiekkalaatikkosuojausta, mutta tällainen vahva hämärtäminen on paljastava merkki pahantahtoisuudesta. Huomaa, että perinteiset SAST Työkalut suunniteltiin tahattomia haavoittuvuuksia varten, eivätkä takaporttien kaltaisia haitallisia tarkoituksia varten.
Dynaaminen analyysi suorittaa komponentin ja tutkii vasteen instrumentoimalla suoritusympäristöä, tyypillisesti tarjoamalla hiekkalaatikkoympäristön. Tietyissä olosuhteissa laukaistu haitallinen toiminta voi jäädä huomaamatta: huomaa, että haittaohjelmat voivat käyttää väistötekniikoita, kuten Virtualisointi/hiekkalaatikon kiertäminen aktivoitua vain silloin, kun sitä ei tarkastella tarkasti, ja se on myös merkki haitallisesta toiminnasta mille tahansa staattiselle analyysimoottorille.
Kyvykkyysanalyysi ottaa huomioon, mitä komponentti tekee: mihin se muodostaa yhteyden, mitä tiedostoja se käyttää, mitä komentoja tai ohjelmia suoritetaan, pääte- tai laite-I/O suoritetaan tai mitä järjestelmäkutsuja kutsutaan. Tätä käyttäytymisen sormenjälkien luokittelua voitaisiin verrata (olemassa olevan komponentin osalta) eri versioiden välillä, joten kun havaitaan odottamatonta toimintaa, tämä näyttö voisi herättää epäilyksiä uuteen versioon mahdollisesti lisätystä haitallisesta toiminnasta. Tämä lähestymistapa noudattaa turvallisuusanalyytikoiden noudattamia triage-vaiheita kohdatessaan potentiaalisia haittaohjelmia: tarkastus, jossa käytetään jouset tai vastaavia työkaluja. Tämä lähestymistapa havaitsee haitallisen toiminnan riippumatta laukaisuehdoista ja toimii, kun lähdekoodia ei ole saatavilla.
Kontekstianalyysi kerää tietoa siitä, miten komponentti julkaistiin ja kuka sen julkaisi. Pahoinpitelijöiden kampanjat käyttävät usein uutta käyttäjätiliä/-tilejä, joita ei ole tarkastettu millään tiukalla tarkastusprosessilla. Aiemman toiminnan seuraaminen voi antaa tietoa taustalla olevasta käyttäjästä, enimmäkseen poikkeavuuksista, jotka voivat viitata mahdolliseen tietomurtoon. Maine on niin vaikea ansaita ja niin helppo menettää! Käyttäjä, jolla ei ole aiempaa toimintaa, on neutraali, mutta karma jahtaa pahansuopia. Haktivisteja eli tavallisia käyttäjiä, joilta on varastettu julkaisutiedot, tulisi seurata tarkasti.
Toinen kontekstuaalinen tieto on mahdollinen ristiriita komponenttipaketin luomiseen käytetyn lähdekoodivaraston ja itse tarballin sisällön välillä. Myös hyvien käytäntöjen noudattaminen, kuten lähdekoodivaraston tunnisteiden tai julkaisujen luominen siten, että ne vastaavat julkisessa rekisterissä julkaistuja komponentin versioita. Kun tietyn lähdekoodivarasto commit on merkitty julkaisu-tunnisteella, ja sitten yhtäkkiä yksi versio ei seuraa sitä, se yksinään on vahva todiste siitä, että komponentti voi olla saastunut: pahantahtoinen toimija on saattanut vaarantaa komponentin julkaisemiseen käytetyn tilin, mutta hänellä ei ole kirjoitusoikeuksia lähdekoodivarastoon). Monet hyökkäykset havaitaan rutiininomaisesti näiden sääntöjen avulla: esimerkiksi Ledger-hyökkäys voitaisiin helposti havaita tällä tavoin. Kontekstianalyysi siis tunnistaa tällaiset poikkeamat julkaisuprosessissa.
Riippuvuuspalomuuri
Erilainen lähestymistapa on käyttää kattavaa sallittujen komponenttien luetteloa kaikille ohjelmistossasi käytetyille riippuvuusgraafeille, joten missä tahansa kokoonpanossa pipeline organisaatiossasi voidaan asentaa ja käyttää vain hyväksyttyjä komponenttiversioita.palomuuri” valvotaan sisäisen rekisterin avulla, johon sallittujen komponenttiversioiden tar-tiedostot tarjoillaan (välimuistissa tai välityspalvelimen kautta). Huomaa, että mikään sallittujen lista ei toimi, ellet käytä tekniikkaa uusien versioiden luokittelemiseen kohtuullisen turvalliseksi, jotta ne voidaan lisätä sallittujen listaan.
Huomaa, että varhaisvaroitus (nopea havaitseminen mahdollisimman pian uuden version julkaisun jälkeen) on yhdistettävä johonkin tapaan käyttää tätä tietoa ennakoivasti estääkseen kokoonpanoon vaikuttavan komponentin toiminnan. pipelinetai kehittäjien koneille [4]Me kutsumme tätä ”riippuvuuspalomuuri”: karanteenimekanismi automatisoitujen koontien suojaamiseksi haitallisilta paketeilta. Sisäiset paketit ja levykuvarekisterit ovat hyviä eristämään organisaatioita ulkoiselta pahalta, mutta karanteenin tehokkuuden varmistamiseksi tarvitaan riittävän vahvaa näyttöä.
Suorituksenaikainen hiekkalaatikko
Vaihtoehtoinen lähestymistapa havaitsemiseen julkaisun aikana on analysoida käyttäytymistä suorituksen aikana. Ajatuksena on tallentaa ohjelmiston odotettu käyttäytyminen ja havaita (tai estää) kaikki löydetyt poikkeamat. Tämän toimintatavan ongelmana on, että suorituksenaikainen ympäristö on instrumentoitava valvontaa tai estämistä varten, ja se on lupaava idea, joka lisätään suojausmekanismien arsenaaliin haitallisia komponenttituholaisia vastaan.
Kokonaisvaltaisen strategian laatiminen
Suositellun strategian on yhdistettävä erilaisia tekniikoita ohjelmistokehitysprosessissa ja otettava hallintaan versiopäivitykset estääksemme saapuvat haitalliset komponentit. Meidän on otettava huomioon versioiden kiinnittäminen automaattisen tartunnan välttämiseksi päivitettäessä versioita, jotta saadaan korjauksia tärkeisiin haavoittuvuuksiin. Versiopäivitysten aikana on arvioitava nopeasti ja tehokkaasti suoria ja epäsuoria riippuvuuksia, jotta saadaan riittävästi näyttöä siitä, etteivät ne ole haittaohjelmien saastuttamia. Tunnetuista haitallisista komponenteista riippuvaisten ohjelmistojen koontiversiot on estettävä. Ja kaikkia näitä käytäntöjä on valvottava.
Käytä versioiden kiinnittämistä mahdollisuuksien mukaan, sillä se tekee koontiversioista toistettavampia. Versioiden kiinnittäminen hallituilla, manuaalisesti hyväksytyillä versioiden lisäyksilläja avustavan teknologian avustamana, tulisi arvioida, tuoko päivitys haittaohjelmia tai rikkooko se ohjelmiston, ja sovittaa yhteen haavoittuvuuksien korjaamiseen tähtäävä päivittäminen haittaohjelmatartuntojen välttämisen kanssa. Työkalut voivat auttaa tässä (1) priorisoimalla, mitkä haavoittuvuudet ovat todella tärkeitä (saavutettavissa ja hyödynnettävissä, ja joilla on suuri riski joutua hyökkääjien kohteeksi), (2) valitsemalla kohdeversiot, jotka ovat yhteensopivia komponenttien nykyisen käytön kanssa eivätkä rikko ohjelmistoa, (3) valitsemalla kohdeversiot, jotka eivät sisällä haitallista toimintaa, ja (4) tekemällä suorien ja epäsuorien riippuvuuksien versiopäivityksestä helppoa ehdottamalla manifest-tiedostoihin muutoksia, jotka voidaan hyväksyä nopeasti. Vaiheessa (3) tarvitaan tarkkoja tietoja haitallisista komponenteista mahdollisimman lähellä niiden julkaisuajankohtaa.
Tämän riippuvuuksien päivitysprosessin on oltava tahdonvastaiselta ja todennettu kaikissa paikoissa. Prosessi on dokumentoitava ja kaikki osapuolet on koulutettava, koska usein kehitys ja ohjelmiston kokoaminen/käyttöönotto ulkoistetaan. CI/CD pipelines tulisi muokata vastaavasti, jotta automaatio ei salli haitallisen epäsuoran riippuvuuden pääsyä rakennukseen: guardrails Suositeltu tapa on estää koonti, jos riippuvuudessa on riittävästi todisteita mahdollisesta haittaohjelmasta.
Jos organisaatiollasi on sisäinen rekisteri, joka toimii sallittujen komponenttiversioiden suojausvälityspalvelimena, sinun on hankittava tietoja haitallisista komponenteista (muiden kriteerien lisäksi) pyydetyn komponentin tarkistamiseksi ennen sen lisäämistä sallittujen luetteloon.
Avoimen lähdekoodin ohjelmistojen turvallinen käyttö ei ole helppoa, ja haittaohjelmatekijä on otettava täysin huomioon ja haavoittuvuuksien hallintaan on panostettava samalla tavalla.
Viimeinen huomautus: Lähteen alkuperä, komponentin koontihetkellä luotujen ohjelmistotodisteiden muodossa, on toinen keskeinen osa pyrkimyksessä jäljittää artefakti (komponenttipaketti) lähteisiin ja sen tuottaneeseen käännösprosessiin. Huomaa, että tämä linkki lähdekoodin tilannevedoksen ja käännösympäristön sekä siihen liittyvän ohjelmistoartefaktin (jonka luotettu käännösjärjestelmä on allekirjoittanut) välillä ei sinänsä estä sitä, etteikö komponentti sisältäisi haitallista toimintaa, mutta vaikeuttaa haitallisten tekijöiden mahdollisuuksia lisätä haittaohjelmia. Ja alkuperän validoinnin tekeminen yleiseksi vaatimukseksi avoimen lähdekoodin komponenttien käyttämiselle vie kauan, ja vain lisätty äskettäin NPM:äänNäiden luotettavien koonti- ja käyttöönottojärjestelmien tekeminen luvattomiksi tai koontiversion manipuloinnin havaitsemisen mahdollistaminen on eri asia, eikä se kuulu tämän viestin piiriin.
Kirjallisuutta
Seuraava jakso Avoimen lähdekoodin haittaohjelmapaketit: Xygeni-lähestymistapa esittelee Xygenillä noudattamamme strategian Haittaohjelmien varhainen varoitus (MEW) -järjestelmä. Julkisten paketti- ja levykuvarekisterien uudet pakettiversiot skannataan ja todisteita hankitaan käyttämällä staattisen, dynaamisen, ominaisuus- ja kontekstuaalisen analyysin yhdistelmää. Todisteet yhdistettynä käyttäjän maineeseen ja lähdekoodivarastojen muutoshistoriaan mahdollistavat komponentin täysin automatisoidun luokittelun korkean riskin ja todennäköisesti haitallisten luokkien mukaan. Järjestelmä oppii paketeista aiemmin kerätyistä todisteista vähentääkseen väärien positiivisten tulosten määrän minimiin.
Tilautuneet organisaatiot saavat varoitusilmoituksen komponenteista, joita ne käyttävät, suoraan tai epäsuorasti, kun haitallinen versio luokitellaan. Tämän jälkeen analyytikkomme tekevät manuaalisen analyysin, joka vahvistaa tai hylkää luokittelun. Vahvistettujen haittaohjelmien osalta ilmoitetaan julkiselle rekisterille, jotta se voi suorittaa oman analyysinsä ja yleensä poistaa haitallisen version tai ryhtyä lisätoimenpiteisiin, kuten estää tai poistaa kyseisen käyttäjätilin.
Selitämme, kuinka autamme NPM:ää, PyPI:tä, GitHubia ja muita avoimen lähdekoodin ekosysteemin keskeisiä infrastruktuureja lyhentämään uuden julkaistun haitallisen komponentin aktiivisuusaikaa, kunnes se vahvistetaan haittaohjelmaksi ja poistetaan rekisteristä. Ja kuinka organisaatiot voivat hyötyä MEW-järjestelmästä saadakseen paljon paremman suojan avoimen lähdekoodin komponentteihin liittyviä ohjelmistojen toimitusketjuhyökkäyksiä vastaan.
- [1] Joka tapauksessa komponentin käyttäjien on tarkistettava, onko komponentin tarball välimuistissa tai rekisteröity jonnekin, esimerkiksi sisäiseen rekisteriin, jotta ongelma poistuu.
- [2] Pakattu komponentti sisältää manifestin, joka ilmoittaa sen sisällön ja metatiedot, lähdekoodin tai käännetyn koodin, asennusskriptit ja lisäelementit, kuten testipaketit, pakkausmuodon mukaisesti ja tyypillisesti pakatussa muodossa. Tätä kutsutaan "komponenttipaketiksi".
- [3] Vaikka pahantahtoinen toimija voisi muokata julkaistua komponenttia itse rekisterin murron vuoksi, tavallinen kryptografinen tiiviste voi havaita kaikki muutokset tarballissa analyysin jälkeen.
- [4] Muista, että jotkin haitalliset komponentit suoritetaan asennuksen aikana, joten se voi vaikuttaa kehittäjäsolmuihin, jotka tietämättään suorittavat "npm install X" -komennon, jossa X on haitallinen komponentti.
