Dit is de tredde ôflevering yn in rige artikels oer de meast foarkommende soarte oanfallen yn 'e software-oanfierketen: dyjingen dy't misbrûk meitsje fan in iepenbier register fan iepen-boarne softwarekomponinten. Nei it analysearjen yn 'e foarige ôflevering "Anatomy fan kweade pakketten: Wat binne de trends?"hoe't de minne akteurs kwea-aardich gedrach yn nije of besteande publisearre komponinten ynjeksjearje, binne wy ree om ús blusjassen oan te dwaan en te ûndersykjen hoe't wy mei súkses kwea-aardige software dy't op dizze manier levere wurdt, kinne blokkearje, of alternatyf, in potinsjeel serieus cyberynsidint oanpakke, om't wy de ferkearde oanpak keazen hawwe."
De measte feiligensbewuste professionals hawwe ideeën oer hoe't se mei dizze bedriging omgean kinne. Wy hawwe feiligensmanagers sûnder wifkjen heard sizzen dat SCA ark fertelle jo al wannear't in pakketferzje malware is. Of dat se ôfhinklik binne fan bekende, heech beoardiele softwarekomponinten, wêrby't alle malware direkt ûntdutsen en fuorthelle wurde soe. Se brûke iepen lytse/patchferzjes foar it automatysk krijen fan kwetsberensreparaasjes, en dat is de juste, oanrikkemandearre manier om it risiko op iepen boarne-ôfhinklikheden te ferminderjen, neffens de "betiid patchje, faak patchje”Prinsipe.
Yn dizze ôflevering sille wy besjen wêrom't dizze ideeën ferkeard binne, en hoe't sokke misfettingen bydrage oan 'e populariteit fan dit oanfalsmeganisme, en oan in oerweldigjend risiko dat organisaasjes ûnderfine. Wy sille einigje mei wat wurket, en wat de ynspanning en middels binne dy't nedich binne.
Algemiene misferstannen
Tidens ús reis mei softwarefeiligens seagen wy de oanfalstechniken evoluearje en in breed skala oan ideeën fan feiligensbewuste minsken. Organisaasjes begripe faak ferkeard wat wurket tsjin dizze bedriging, dus earst sille wy ûndersykje wat net wurket, gearfette yn 'e folgjende, net útputtende, list mei misfettingen.
Misferstân # 1: SCA ark melde al kweade komponinten
Yndied! Mar nei it feit... As it wierskynlik te let is as it elemint brûkt waard yn in softwarebou, en de minne akteurs al in foet oan 'e grûn krigen hawwe by in ûntwikkelder of CI/CD host. Geheimen kinne ûntmaskere wêze, ekstra malware downloade en ynstalleare, en miskien is de tsjinstanner letterlik ferhuze en hat al tagong krigen earne oars.
Analyse fan softwarekomposysje (SCA) ark waarden ûntworpen om potinsjele bekende kwetsberheden te identifisearjen. Moderne ark dogge in geweldich wurk troch de sinjaal-rûsferhâlding te fergrutsjen, en te bepalen oft de kwetsberens eins berikber of eksploitabel is. Mar se binne nutteloos tsjin nije malware. Tink oan in kweade komponint as in nul-dei kwetsberens: Allinnich as it kweade gedrach wurdt ûntdutsen, wurdt de komponint rapportearre oan it register, dat nei in resinsje troch in befeiligingsteam as kwea-aardich wurdt befêstige en út it register wurdt fuorthelle. [1].
Op dat stuit, de wrâld (ynklusyf SCAs) wit dat it ynstallearjen of brûken fan 'e komponint (of in ferzje(s) fan in besteande komponint) gjin goede saak is. Mar dit is as de komponint net beskikber is út it registerWitte dat ik kwetsberheden haw yn komponinten fan tredden, of sels komponinten dy't troch it register as kwea-aardich kategorisearre binne, is goed, mar spitigernôch SCA of gewoane kontrôle-ark helpe yn dizze kontekst net. Behalven as de SCA/audit-ark kin echt fan tefoaren witte dat in komponint kwea-aardich is foardat it yn jo organisaasje brûkt wurdt.
Tink derom, elke oplossing tsjin kweade iepen boarne-komponinten moat se detektearje Yn it foarbygean, tusken wannear't de komponint yn it register publisearre wurdt en wannear't de komponint (ferzje) foar it earst brûkt wurdt by jo organisaasje. En dat omfettet transitive komponinten.
Misfetting #2: It kontrolearjen fan ynstallaasjeskripts by it bouwen foarkomt kwea-aardich gedrach fan iepen boarnekomponinten
Ferskate pakketbehearders biede de mooglikheid om skripts út te fieren (ynbegrepen yn 'e komponint tarball [2]), om legitime redenen, lykas it gearstallen fan fereaske items op ferskate platfoarms, it generearjen fan koade, of it útfieren fan tests, en wy moatte allegear witte dat se misbrûkt wurde kinne troch minne akteurs as kweade skripts opnommen binne yn 'e tarball, of as de oanfaller in kwea-aardich skript útfiere kin ynstee fan it goede skript.
Wittende dit, kinne wy de pakketbehearder ynstelle om skripts te negearjen. Bygelyks, mei NPM de –Ignorearje-skripts flagge (of in konfiguraasje-eigenskip yn 'e .npmrc triem) slaat de skripts oer tidens de ynstallaasje. Dit kin problemen feroarsaakje, om't it útfieren fan skripts gewoan is yn in protte ekosystemen: Guon pakketbehearders tastean it útskeakeljen fan skriptútfiering net iens ta (hint: prompt "Hokker pakketbehearders tastean it útskeakeljen fan it útfieren fan ynstallaasjeskripts net ta?" yn jo favorite AI). Mar dit beskermet yn 't algemien net (wy moatte ôftwinge dat de konfiguraasje foar it útskeakeljen fan oerslaan oeral is).
En as it kwea-aardige gedrach net yn ynstallaasjeskripts sit, mar yn 'e software om tidens runtime út te fieren, beskermet dizze opsje allinich ús net.
Misferstân #3: Ferzje-pinning foarkomt dat kweade komponinten ynstalleare wurde
Der is in ôfwaging tusken it betiid patchen en faak mei iepen ferzjes (de pakketbehearder automatysk nije updates ynstallearje litte as se beskikber binne foar feiligensreparaasjes) en ferzje fêstmeitsje (mei alle direkte en transitive ôfhinklikheden foar software op in fêste ferzje). De feiligensprinsipes binne koppich en soms tsjinstridich, lykas bart mei "patch betiid, patch faak" en "Upgrade moat net licht opnommen wurde"Guon pakketbehearders meitsje automatyske updates mei serverberik op 'e oanrikkemandearre manier. Geweldich as jo ek de kweade updates ûntfange wolle! Ja, komponinten moatte bywurke wurde om feiligensreparaasjes te ûntfangen dy't kwetsberheden sa gau mooglik slute, mar ... lit de pakketbehearder dit noait automatysk dwaan.
Misfetting #4: It brûken fan fertroude komponinten is feilich. Elke kweade ferzje soe direkt fûn, iepenbiere en fuorthelle wurde.
Wêrom wurdt in komponint fertroud? Mooglik om't it tige populêr is, mei in protte eachballen dy't sykje nei kwetsberheden, in grut oantal bydragers foar ûnderhâld, mei meardere kearnûnderhâlders dy't alles sekuer kontrolearje pull requestsDe realiteit is hiel oars. Guon essensjele komponinten wurde ûnderhâlden troch ien, ûnbetelle ûntwikkelder. Breed brûkte frameworks hawwe in pear reguliere bydragejouwers, mei in rap ôfnimmend oantal fan commits per ûnderhâlder (populêre projekten hawwe in lange sturt fan bydragejouwers dy't wat drive-by útfiere commit en nea weromkomme). En populêre projekten mei ien ûnderhâlder binne der yn oerfloed.
Stel dy foar datst sizze "Och, wy brûke Spring Boot / Angular / React / PyTorch / offisjele basis Docker-ôfbyldings, dus it risiko dêr't jo it oer hawwe is frij leech." Miskien is dat wier, wy befeiligingsleveransiers dy't de hiele tiid bangmeitsje en ús bemuoie mei ûntwikkelingsteams om in debatabel risiko te ferminderjen is ûnsin. Jo kinne yn 'e ferlieding komme om nei de paragraaf oer risiko-akseptaasje te springen (yn 'e folgjende seksje) en klear. Spitigernôch binne de populêrste komponinten doelen foar minne akteurs, en bygelyks de populêre PyTorch-bibleteek waard oanfallen yn it ferline.
"Fluch fûn, iepenbier makke en fuorthelle". It duorret dagen foar in nije kweade komponint út it iepenbiere register fuorthelle wurdt. Registers binne foarsichtich mei it fuortheljen fan in komponintferzje, foar it goede. Us ûnderfining is dat as ienris fan ús kant rapportearre is, de mediane tiid foar it register om de troffen ferzje te ferwiderjen 39 oeren is, mear as oardel dei. Der binne kweade komponinten dy't in wike nei ús earste rapportaazje yn it register fuorthelle wurde. En yn guon gefallen wurdt de komponint allinich fuorthelle neidat in slachtoffer of in ynsidintresponsbedriuw in ynsidint mei de komponint rapportearret.
Wat wurket NET tsjin kweade komponinten
Elke net-spesifike oanpak sil jammerdearlik mislearje. Dit is in wissichheid, jo leverje gjin effektive tsjinmaatregels foar it risiko dat ferbûn is mei dizze bedriging.
Tradisjoneel SCA ark fertelle jo oer bekende malware, mar hawwe in grut bleatstellingsfinster. Behalven as se proaktyf malwaredeteksje útfiere mei twongen blokkearring fan kweade komponinten, wurkje se net tsjin dizze bedriging.
It útskeakeljen fan ynstallaasjeskripts kin helpe, mar moat oeral ôftwongen wurde wêr't in komponint ynstalleare wurde moat. Itselde jildt foar ferzje-pinnen, om't ferzjes net foar altyd fan in feilige begjinsteat pinne kinne wurde.
It is naïf en riskant om oan te nimmen dat populêre komponinten genôch oandacht krije dat se net ynjektearre wurde kinne mei ûnbedoeld gedrach yn in oanfal op 'e supply chain sûnder in hast direkte deteksje om skea te foarkommen. Jo wolle dochs net op 'e râne libje?
As jo op dit punt stopje, dan risiko-akseptaasje is it iennige dat jo dwaan kinne: Dit is in decision dy't dokumintearre wurde moat yn jo bedrigingsmodel/risikobeoardieling, ynklusyf de redenearring foar it akseptearjen fan it risiko en de potinsjele gefolgen dêrfan. Fergrutsje bewustwêzen troch it te kommunisearjen oan it management en oare relevante partijen. Guon kontinginsje koe pland wurde as in kwea-aardige komponint ynstalleare of opnommen is yn jo software, mar dit is lestich, om't oanfallers in protte paden hawwe om te folgjen. De details fan in oanfal op 'e supply chain basearre op it gebrûk fan in kwea-aardige komponint sille de iepenbiere iepenbiering fan it ynsidint drastysk feroarje, wat wierskynlik ferplicht is ûnder it regeljouwingskader fan jo organisaasje. Jo kinne ek oanpakke kompensearjende kontrôles or oerdrachtrisiko bygelyks mei fersekering.
Der binne lykwols kontrôles dy't de bedriging oanpakke en moatte wurde beskôge as jo net tefreden binne mei risiko-akseptaasje. Lês asjebleaft fierder.
Wat wurket tsjin oanfallen mei kweade komponinten
Solid ferzjebehanneling
Ferzje-pinning mei kontroleare en ynformearre ferzje-bumps is de manier om te gean, om de needsaak foar it fuortheljen fan kwetsberheden te balansearjen sûnder malware te ûntfangen. Mar tink oan misfetting #3: Ferzje-pinning allinich is net genôch om kweade koade te blokkearjen dy't út nije ferzjes komt, om't jo yn 'e takomst ferzjes moatte bywurkje yn elke direkte of yndirekte ôfhinklikens. Op dat stuit hawwe jo bewiis nedich dat alle oanpaste ferzjes gjin malware befetsje.
Iere warskôging
Ien oanpak foar it probleem fan kweade komponinten is in systeem foar iere warskôging (hjir neamd as Malware Betiid warskôging of MEW), dêr't nije ferzjes publisearre (foar nije of besteande komponinten) analysearre wurde troch in deteksjemotor, dy't, as genôch bewiis fûn wurdt, de nije ferzje as potinsjeel kwea-aardich klassifisearje kin.
Automatisearring is hjir essensjeel, om't it ûnmooglik is om alle nije komponinten manuell te besjen mei de hjoeddeiske publikaasjesnelheid. Dat de deteksjemotor moat in ferskaat oan techniken kombinearje, miskien ynklusyf statyske, dynamyske en kapasiteitsanalyse, brûkersreputaasje, en bewiis dat komt fan ferskillen tusken de komponintmetadata en de tarball-ynhâld, of tusken tarball en de boarne-repository wêr't de komponint nei alle gedachten weikomt.
Dêr is in tsjustere sône tusken de publikaasjetiid en wannear't de motor de ynhâld fan 'e komponint analysearret, mar it moat net mear as in pear minuten duorje. It skema kin oanpast wurde, bygelyks troch te wachtsjen oant nije komponinten analysearre binne foardat se ynstalleare en brûkt wurde meie yn 'e softwarebou. pipelines, of analysearje se op oanfraach as it nedich is. In komponint by in bepaalde ferzje is ûnferoarlik [3], dus it hoecht mar ien kear analysearre te wurden.
Folsleine automatisearring is net mooglik, en in feiligenskontrôle foar potinsjeel kwea-aardige komponinten is nedich. Pas op foar foarstanners fan digitale panaceaAI en Masinelearen binne net ûntwikkele genôch om it lêste wurd te nimmen as it giet om te befêstigjen oft in fertochte komponint malware befettet. Wis, masinelearen spilet in wichtige rol yn 'e deteksjemotor by it klassifisearjen fan' e ynfierkomponint út it rûge bewiis dat is fongen, mar as de komponint ienris "yn karantêne" is, is it lêste wurd oer de hânmjittige resinsje troch in befeiligingsteam mei ûnderfining mei kweade komponinten. Dit befêstiget alle potinsjele malware of klassifisearret it opnij as feilich. En de tiidsperioade is yn it berik fan oeren.
It register rapportearret oer de kwea-aardige ferzje/komponint; it register docht dan syn resinsje om te befêstigjen en giet troch nei iepenbiere iepenbiering en ferwidering út it register. Guon registers hâlde in befeiligingspakket by. It tiidsberik hjir is de dagen of wiken sûnt de publikaasje, dat is de 'ferbliuwstiid'of'bleatstellingsfinster' foar de measte kweade komponinten.
Is it mooglik om te witten oft in komponintferzje skealik is?
Dus foar iere warskôging moatte wy in befredigjend antwurd jaan op dizze fraach: Hoe kin ik witte dat in bibleteek of pakket (net) kwea-aardich is? Hoe kin ik genôch bewiis sammelje fan kwea-aardich gedrach? Mooglik, mar lestich, om't de tsjinstanners in soad ynventiviteit brûke om deteksje te foarkommen. D'r binne ferskate oanpakken, elk mei foar- en neidielen.
Statyske analyze kinne alle útfieringspaden ûndersykje, kontrolearje op techniken dy't brûkt wurde troch oanfallers sûnder de komponint út te fieren, en foarferwurkingstaken útfiere lykas de-obfuskaasje of ûntsiferjen. As oanfallers besykje har kwea-aardichheid te ferbergjen, binne obfuskaasjepogingen yndie bewiis fan malware (mar tink derom dat legitime komponinten koade ferbergje foar it behâld fan yntellektueel eigendom, yn tsjinspraak mei "iepen Boarne”). Mar in minderheid fan tige ferfine oanfallen mei sterke obfuskaasje hawwe sandboxing nedich, mar sokke sterke obfuskaasje is in ferriedlik teken fan kwea-aardichheid. Tink derom dat konvinsjonele SAST ark waarden ûntworpen foar ûnbedoelde kwetsberheden, net foar kweade bedoelingen lykas efterdoarren.
Dynamyske analyze fiert de komponint út en ûndersiket de reaksje troch de runtime te ynstrumintearjen, typysk troch in sandbox-omjouwing te leverjen. Kwea-aardich gedrach dat ûnder bepaalde omstannichheden aktivearre wurdt, kin ûnopmurken bliuwe: tink derom dat malware ûntwykingstechniken kin brûke lykas Virtualisaasje/Sandbox-ûntwyking allinich te aktivearjen as it net ûnder kontrôle is, en ek in ferriedlik teken fan kweade aktiviteit foar elke statyske analysemotor.
Kapasiteitsanalyse beskôget wat de komponint docht: wêr't it mei ferbynt, hokker bestannen it tagong krijt, hokker kommando's of programma's wurde útfierd, de terminal- of apparaat-I/O dy't wurdt útfierd, of hokker systeemopropen wurde oanroppen. Dizze fingerprinting fan gedrach koe (foar in besteande komponint) fergelike wurde oer ferskate ferzjes, sadat as ûnferwachts gedrach wurdt ûntdutsen, dat bewiis fermoedens kin wekke fan potinsjele kweade aktiviteit dy't yn 'e nije ferzje ynjektearre is. Dizze oanpak folget de triage-stappen dy't feiligensanalysten folgje as se te krijen hawwe mei potinsjele malware: in ynspeksje mei help fan strings of ferlykbere ark. Dizze oanpak detektearret kwea-aardich gedrach, ûnôfhinklik fan triggerbetingsten, en wurket as der gjin boarnekoade beskikber is.
Kontekstanalyse sammelet ynformaasje oer hoe't de komponint publisearre is en troch wa. Kampanjes fan minne akteurs brûke faak in nij brûkersakkount(s) dat net ûnderwurpen is oan in strang kontrôleproses. It folgjen fan eardere aktiviteit kin ynsjoch jaan yn 'e ûnderlizzende brûker, meast foar anomalieën dy't kinne wize op in mooglike kompromis. Reputaasje is sa dreech te fertsjinjen en sa maklik te ferliezen! In brûker sûnder eardere aktiviteit is neutraal, mar karma efterfolget de kweade. Hacktivisten, of normale brûkers waans publisearringsgegevens stellen binne, moatte soarchfâldich folge wurde.
In oare kontekstuele ynformaasje is elke diskrepânsje tusken de boarne-repository dy't nei alle gedachten brûkt wurdt om de komponint-tarball te meitsjen en de ynhâld fan 'e tarball sels. En ek it folgjen fan goede praktiken, lykas it meitsjen fan tags of releases yn 'e boarne-repository dy't oerienkomme mei de ferzjes fan 'e komponint dy't publisearre binne yn it iepenbiere register. As de boarne-repository op in bepaald commit is markearre mei release, en dan ynienen folget ien ferzje it net, dat allinich is sterk bewiis dat de komponint besmet wêze kin: de minne akteur kin it akkount dat brûkt wurdt foar it publisearjen fan 'e komponint kompromittearre hawwe, mar hat gjin skriuwrjochten yn 'e boarnekoade-repository). In protte oanfallen wurde routinematich ûntdutsen mei dizze regels: bygelyks de Ledger-oanfal koe maklik op dizze manier ûntdutsen wurde. Kontekstanalyse identifisearret dêrom sokke anomalieën yn it publisearringsproses.
Ofhinklikens Firewalling
In oare oanpak is om in wiidweidige wite list mei komponinten te hawwen foar alle ôfhinklikheidsgrafiken dy't yn jo software brûkt wurde, dus yn elke build pipeline yn jo organisaasje kinne allinich goedkarde komponintferzjes ynstalleare en brûkt wurde. De "brânmuorre" wurdt ôftwongen mei in yntern register dêr't de tarballs foar de tastiene komponintferzjes wurde tsjinne (cache of proxy). Tink derom dat elke wite list net sil wurkje, útsein as jo de technology hawwe om elke nije ferzje as ridlik feilich te klassifisearjen, sadat it tafoege wurde kin oan 'e wite list.
Tink derom dat iere warskôging (fluch deteksje sa gau mooglik nei de publikaasje fan 'e nije ferzje) kombinearre wurde moat mei in manier om dy ynformaasje proaktyf te brûken om de komponint dy't ynfloed hat op 'e build te blokkearjen. pipelines of de masines fan 'e ûntwikkelders [4]Wy neame dit “ôfhinklikens firewalling”: in karantênemeganisme foar it beskermjen fan automatisearre builds tsjin kweade pakketten. Ynterne pakketten en ôfbyldingsregisters binne goed om organisaasjes te isolearjen fan kwea fan bûten, mar bewiis dat sterk genôch is, is nedich om karantêne effektyf te meitsjen.
Runtime Sandboxing
In alternative oanpak foar deteksje by publikaasje is it analysearjen fan gedrach by runtime. It idee is om it ferwachte gedrach fan 'e software te fangen en alle fûne anomalieën te detektearjen (of te blokkearjen). Dizze aksjeline hat it probleem dat de runtime ynstrumintearre wurde moat foar monitoring of blokkearjen, en it is in beloftefol idee dat tafoege wurde sil oan it arsenaal fan beskermingsmeganismen tsjin de kweade komponintpest.
In wiidweidige strategy ynstelle
De oanrikkemandearre strategy moat ferskate techniken kombinearje yn it softwareûntwikkelingsproses, wêrby't de kontrôle oer de ferzje-updates nommen wurdt om ynkommende kwea-aardige komponinten te blokkearjen. Wy moatte ferzje-pinning mooglik meitsje om automatyske ynfeksje te foarkommen mei it bywurkjen fan ferzjes om reparaasjes te krijen foar de kwetsberheden dy't wichtich binne; in rappe en effisjinte beoardieling fan direkte en yndirekte ôfhinklikheden tidens ferzje-updates om genôch bewiis te hawwen dat se net fol binne mei malware. Builds fan software dy't ôfhinklik binne fan bekende kwea-aardige komponinten moatte blokkearre wurde. En alles moat hanthavene wurde.
Brûk ferzjepinnen, as it mooglik is, om't it builds better reprodusearber makket. Ferzje-pinnen mei kontroleare, mei de hân goedkarde ferzje-bumps, en bystien troch helptechnology, moat beoardielje oft de update malware bringt of de software kapot makket, en it bywurkjen foar it oplossen fan kwetsberheden ferienigje mei it foarkommen fan malware-ynfeksje. Tooling kin hjir helpe, troch (1) prioriteit te jaan oan hokker kwetsberheden echt wichtich binne (berikber en eksploitearber, mei in heech risiko om it doelwyt te wurden fan oanfallers), (2) de doelferzjes te selektearjen dy't kompatibel binne mei it hjoeddeistige gebrûk fan komponinten en de software net kapot meitsje, (3) doelferzjes te kiezen dy't gjin kwea-aardich gedrach befetsje, en (4) de ferzje-update foar direkte en yndirekte ôfhinklikheden in fluitsje fan in sjabloan te meitsjen, troch feroarings yn 'e manifestbestannen foar te stellen dy't fluch goedkard wurde kinne. De stap (3) hat spesifike ynformaasje nedich oer kwea-aardich komponinten sa ticht mooglik by har publikaasjetiid.
Dit proses fan it bywurkjen fan ôfhinklikheden moat wêze ferfolge en ferifiearje op alle plakken. It proses moat dokumintearre wurde, en alle belutsen partijen moatte oplaat wurde, om't de ûntwikkeling en softwarebou/ynset faak eksternalisearre wurdt. De CI/CD pipelines moat dêrop oanpast wurde, sadat automatisearring net tastean dat in kweade yndirekte ôfhinklikens yn 'e build glide kin: guardrails It blokkearjen fan 'e bou as der genôch bewiis is fan potinsjele malware yn in ôfhinklikens is de oanrikkemandearre manier om te gean.
As jo organisaasje in yntern register hat dat fungearret as in befeiligingsproxy foar it bewarjen fan de tastiene komponintferzjes, moatte jo yntelliginsje krije oer kweade komponinten (neist oare kritearia) foar it kontrolearjen fan in oanfrege komponint foardat jo it tafoegje oan de tastiene list.
It feilich brûken fan iepen boarne software is net maklik, en de malwarefaktor moat folslein yn rekken brocht wurde, mei ferlykbere ynspanning yn it omgean mei kwetsberens.
Ien lêste opmerking: Boarneherkomst, yn 'e foarm fan software-attestaasjes, generearre by de boutiid fan 'e komponint, is in oar wichtich ûnderdiel yn 'e ynspanning om it artefakt (komponint-tarball) te tracearjen mei de boarnen en it bouproses dat it produsearre hat. Tink derom dat dizze keppeling tusken de boarne-snapshot + bou-omjouwing en it assosjearre software-artefakt (ûndertekene troch it fertroude bousysteem) net per se foarkomt dat de komponint gjin kwea-aardich gedrach befettet, mar it dreger makket foar de minne jonges om malware te ynjeksjearjen. En it meitsjen fan herkomstfalidaasje in mienskiplike eask foar it konsumearjen fan iepen boarne-komponinten sil lang duorje, en allinich koartlyn tafoege oan NPMIt meitsjen fan dy fertroude build- en ynsetsystemen tamperbestindich, of it mooglik meitsjen fan deteksje fan manipulaasje yn 'e build is in oar ferhaal, bûten it berik fan dizze post.
fierder lêze
De folgjende ôflevering Iepen boarne kweade pakketten: De Xygeni-oanpak sil de strategy presintearje dy't wy by Xygeni folgje foar ús Malware Betiid warskôging (MEW) systeem. Nije pakketferzjes yn 'e iepenbiere pakket- en ôfbyldingsregisters wurde scanne en bewiis wurdt krigen mei in kombinaasje fan statyske, dynamyske, mooglikheden en kontekstuele analyze. It bewiis, kombinearre mei brûkersreputaasje en de skiednis fan feroarings yn boarnekoade-repositories, makket in folslein automatisearre klassifikaasje fan in komponint mooglik yn kategoryen mei hege risiko's en wierskynlik kwea-aardige problemen. It systeem leart fan earder bewiis dat sammele is fan pakketten om de falske positiven ta in minimum te ferminderjen.
Abonnearre organisaasjes krije in warskôgingsnotifikaasje foar komponinten dy't se brûke, direkt of yndirekt, as in kwea-aardige ferzje kategorisearre wurdt. Dan wurdt in hânmjittige analyze dien troch ús analysten, dy't de klassifikaasje befêstiget of ôfwiist. Foar befêstige malware wurdt it iepenbiere register ynformearre, sadat it syn eigen analyze útfiere kin en typysk de kwea-aardige ferzje fuortsmite kin of ekstra aksje kin nimme, lykas it blokkearjen of ferwiderjen fan it brûkersaccount yn kwestje.
Wy sille útlizze hoe't wy NPM, PyPI, GitHub, en oare wichtige ynfrastruktueren yn it iepen boarne-ekosysteem helpe om de ferbliuwstiid te ferminderjen dy't in nije kwea-aardige komponint dy't publisearre wurdt aktyf bliuwt oant it befêstige malware is en út it register fuorthelle wurdt. En hoe't organisaasjes profitearje kinne fan it MEW-systeem om in folle bettere beskerming te hawwen tsjin oanfallen fan software-supply chain mei iepen boarne-komponinten.
- [1] Hoe dan ek, brûkers fan 'e komponint moatte kontrolearje oft de komponint-tarball earne yn 'e cache opslein of registrearre is, bygelyks yn in yntern register, sadat de sykte útrûge wurdt.
- [2] De ynpakte komponint befettet in manifest dat de ynhâld en metadata, boarne- of kompilearre koade, ynstallaasjeskripts en ekstra items lykas testsuites ferklearret, neffens in ynpaktformaat en typysk yn komprimearre foarm. Dit wurdt de "komponint-tarball" neamd.
- [3] Sels as de kweade akteur in publisearre komponint kin oanpasse fanwegen in ynbreuk yn it register sels, kin in gewoane kryptografyske digest elke feroaring yn 'e tarball detektearje nei't de analyze dien is.
- [4] Tink derom dat guon kwea-aardige komponinten by ynstallaasje rinne, dus it kin ynfloed hawwe op ûntwikkeldersknooppunten dy't sûnder it te witten "npm install X" útfiere mei X in kwea-aardige komponint.
