Dit is de derde aflevering in een reeks artikelen over de meest voorkomende vorm van software supply chain-aanvallen: aanvallen waarbij misbruik wordt gemaakt van een openbaar register open source softwarecomponenten. Na analyse in de vorige aflevering “Anatomie van kwaadaardige pakketten: wat zijn de trends?“hoe de slechte actoren kwaadaardig gedrag in nieuwe of bestaande gepubliceerde componenten injecteren, zijn we bereid om onze brandweerjassen aan te trekken en te onderzoeken hoe we op deze manier geleverde kwaadaardige software met succes kunnen blokkeren, of als alternatief een mogelijk ernstig cyberincident kunnen aanpakken omdat we de verkeerde aanpak.
De meeste beveiligingsbewuste professionals hebben ideeën over hoe ze met deze dreiging om moeten gaan. We hebben beveiligingsmanagers zonder aarzeling horen zeggen dat SCA tools vertellen je al wanneer een pakketversie malware is. Of dat ze afhankelijk zijn van bekende, goed beoordeelde softwarecomponenten, waarbij malware snel wordt gedetecteerd en verwijderd. Ze gebruiken open minor/patch-versies om automatisch kwetsbaarheidsoplossingen te krijgen, en dat is de juiste, aanbevolen manier om het risico op open source-afhankelijkheden te verlagen, volgens de "vroeg patchen, vaak patchen”Principe.
In deze aflevering zullen we bekijken waarom deze ideeën verkeerd zijn, en hoe dergelijke misvattingen bijdragen aan de populariteit van dit aanvalsmechanisme en aan het overweldigende risico dat organisaties lopen. We eindigen met wat wel werkt, en welke inspanning en middelen daarvoor nodig zijn.
Veelvoorkomende misvattingen
Tijdens onze reis met softwarebeveiliging zagen we de aanvalstechnieken evolueren en een breed scala aan ideeën van beveiligingsbewuste mensen. Organisaties begrijpen vaak niet wat werkt tegen deze dreiging, dus eerst zullen we onderzoeken wat niet werkt, samengevat in de volgende, niet-uitputtende, lijst met misvattingen.
Misvatting #1: SCA Hulpmiddelen melden al schadelijke componenten
Inderdaad! Maar achteraf… Als het waarschijnlijk te laat is, als het element is gebruikt in een software-build, en de kwaadwillenden al voet aan de grond hebben gekregen in een ontwikkelaars- of CI/CD host. Geheimen kunnen zijn geëxfiltreerd, extra malware gedownload en geïnstalleerd, en misschien is de tegenstander lateraal bewogen en heeft hij elders al toegang gekregen.
Analyse van softwaresamenstelling (SCA) tools zijn ontworpen om potentiële bekende kwetsbaarheden te identificeren. Moderne tools doen geweldig werk door de signaal-ruisverhouding te vergroten en te bepalen of de kwetsbaarheid daadwerkelijk bereikbaar of exploiteerbaar is. Maar ze zijn nutteloos tegen nieuwe malware. Beschouw een kwaadaardige component als een zero-day-kwetsbaarheid: alleen wanneer het kwaadaardige gedrag ervan wordt gedetecteerd, wordt de component gerapporteerd aan het holdingregister, dat na een beoordeling door een beveiligingsteam wordt bevestigd als kwaadaardig en uit het register wordt verwijderd [1].
Op dat moment is de wereld (inclusief SCAs) weet dat het installeren of gebruiken van het component (of een versie(s) van een bestaand component) geen goed idee is. Maar dit is wanneer het component niet beschikbaar is in het register. Weten dat ik kwetsbaarheden heb in componenten van derden, of zelfs componenten die door het register als kwaadaardig zijn gecategoriseerd, is goed, maar helaas SCA of algemene audittools bieden in deze context geen uitkomst. Tenzij de SCAMet de /audit-tool kunt u van tevoren vaststellen of een component schadelijk is, voordat deze in uw organisatie wordt gebruikt.
Houd er rekening mee dat elke oplossing tegen kwaadaardige open-sourcecomponenten deze moet detecteren tijdens de vlucht, tussen het moment waarop het onderdeel in het register wordt gepubliceerd en het moment waarop het onderdeel (de versie) voor het eerst wordt gebruikt binnen uw organisatie. En dat omvat transitieve componenten.
Misvatting #2: Het controleren van installatiescripts tijdens het bouwen voorkomt kwaadaardig gedrag van open-sourcecomponenten
Verschillende pakketbeheerders bieden de mogelijkheid om scripts uit te voeren (opgenomen in de component tarball [2]), om legitieme redenen, zoals het compileren van vereiste items op verschillende platforms, het genereren van code of het uitvoeren van tests, en we moeten allemaal weten dat ze kunnen worden misbruikt door slechte actoren als kwaadaardige scripts in de tarball zijn opgenomen, of als de aanvaller een kwaadwillige aanval kan maken script uitgevoerd in plaats van het goede.
Als we dit weten, kunnen we de pakketbeheerder configureren om scripts te negeren. Bij NPM bijvoorbeeld - Negeer-scripts flag (of een configuratie-eigenschap in de .npmrc file) slaat de scripts over tijdens de installatie. Dit kan enkele problemen opleveren omdat het uitvoeren van scripts gebruikelijk is in veel ecosystemen: sommige pakketbeheerders staan niet eens toe dat de uitvoering van scripts wordt uitgeschakeld (hint: prompt “Welke pakketbeheerders staan het uitschakelen van de uitvoering van installatiescripts niet toe?” in je favoriete AI). Maar dit biedt in het algemeen geen bescherming (we moeten afdwingen dat de configuratie voor het uitschakelen van overslaan overal aanwezig is).
En als het kwaadaardige gedrag zich niet in de installatiescripts bevindt, maar in de software die tijdens runtime moet worden uitgevoerd, beschermt deze optie alleen ons niet.
Misvatting #3: Versie vastzetten voorkomt dat kwaadaardige componenten worden geïnstalleerd
Er is een afweging tussen vroeg en vaak patchen open versies (waardoor de pakketbeheerder automatisch nieuwe updates kan installeren wanneer deze beschikbaar zijn voor beveiligingsoplossingen) en versie vastzetten (met alle directe en transitieve afhankelijkheden voor software in een vaste versie). De beveiligingsprincipes zijn koppig en soms tegenstrijdig, zoals gebeurt met ‘patch vroeg, patch vaak’ en “Upgraden moet niet lichtvaardig worden opgevat”. Sommige pakketbeheerders maken op de aanbevolen manier automatische updates met serverbereiken. Handig als je ook de kwaadaardige updates wilt ontvangen! Ja, componenten moeten worden bijgewerkt om beveiligingsoplossingen te ontvangen die kwetsbaarheden zo snel mogelijk dichten, maar ... laat de pakketbeheerder dit nooit automatisch doen.
Misvatting #4: Het gebruik van vertrouwde componenten is veilig. Elke kwaadaardige versie zou onmiddellijk worden gevonden, openbaar gemaakt en verwijderd.
Waarom wordt een component vertrouwd? Mogelijk omdat het erg populair is, met veel ogen die op zoek zijn naar kwetsbaarheden, een groot aantal bijdragers voor onderhoud, met meerdere kernbeheerders die alles zorgvuldig beoordelen pull requests. De realiteit is heel anders. Sommige essentiële componenten worden onderhouden door een enkele, onbetaalde ontwikkelaar. Veelgebruikte frameworks hebben enkele vaste bijdragers, met een snel afnemend aantal commits per onderhouder (populaire projecten hebben een lange reeks bijdragers die een aantal drive-by-acties uitvoeren commit en kom nooit meer terug). En populaire projecten met één enkele onderhouder zijn er in overvloed.
Stel je voor dat je het zegt "Oh, we gebruiken Spring Boot / Angular / React / PyTorch / officiële Docker-basisafbeeldingen, dus het risico waar je het over hebt is vrij laag." Misschien is dat waar: wij beveiligingsleveranciers zijn voortdurend bezig met angstzaaierij, en het is onzin om ontwikkelingsteams te bemoeien met het beperken van een betwistbaar risico. U zou in de verleiding kunnen komen om naar de paragraaf over risicoacceptatie te gaan (in het volgende gedeelte) en klaar is Kees. Helaas zijn de populairste componenten het doelwit van slechte acteurs, en bijvoorbeeld de populaire De PyTorch-bibliotheek werd aangevallen in het verleden.
“Onmiddellijk gevonden, bekendgemaakt en verwijderd”. Het duurt dagen voordat een nieuw kwaadaardig onderdeel uit het openbare register wordt verwijderd. Registers zijn voorzichtig met het ten goede verwijderen van een componentversie. Onze ervaring is dat, eenmaal gerapporteerd van onze kant, de gemiddelde tijd die het register nodig heeft om de getroffen versie te verwijderen 39 uur bedraagt, meer dan anderhalve dag. Er zijn kwaadaardige componenten die een week na onze eerste rapportage in het register vóór verwijdering worden verwijderd. En in sommige gevallen wordt het onderdeel pas verwijderd nadat een slachtoffer of een incidentresponsbedrijf een incident met het onderdeel heeft gemeld.
Wat werkt NIET tegen schadelijke componenten
Elke niet-specifieke aanpak zal jammerlijk mislukken. Dit is een zekerheid: u biedt geen effectieve tegenmaatregelen voor het risico dat aan deze dreiging is verbonden.
Traditioneel SCA tools vertellen u over bekende malware, maar hebben een groot blootstellingsvenster. Tenzij ze proactief malwaredetectie uitvoeren met gedwongen blokkering van kwaadaardige componenten, werken ze niet tegen deze bedreiging.
Het uitschakelen van installatiescripts kan helpen, maar moet overal worden afgedwongen waar een component moet worden geïnstalleerd. Hetzelfde geldt voor het vastzetten van versies, omdat versies niet voor altijd vanuit een veilige beginstatus kunnen worden vastgezet.
Ervan uitgaande dat populaire componenten voldoende aandacht krijgen zodat ze niet kunnen worden geïnjecteerd met onbedoeld gedrag in een supply chain-aanval zonder een vrijwel onmiddellijke detectie om schade te voorkomen, is naïef en riskant. Je wilt toch niet op de rand wonen?
Als je op dit punt stopt, dan risicoacceptatie is het enige wat je kunt doen: Dit is een decision die gedocumenteerd moet worden in uw dreigingsmodel/risicobeoordeling, inclusief de redenatie voor het accepteren van het risico en de mogelijke implicaties ervan. Vergroot het bewustzijn door het te communiceren aan het management en andere relevante partijen. Sommige onvoorziene Dit kan worden gepland wanneer een kwaadaardig onderdeel wordt geïnstalleerd of in uw software wordt opgenomen, maar dit is moeilijk omdat aanvallers vele paden moeten volgen. De details van een supply chain-aanval op basis van het gebruik van een kwaadaardige component zullen de publieke openbaarmaking van het incident drastisch veranderen, wat waarschijnlijk verplicht is volgens het regelgevingskader van uw organisatie. Je mag ook adresseren compenserende controles or overdrachtsrisico bijvoorbeeld met een verzekering.
Er zijn echter controles die de dreiging aanpakken en die moeten worden overwogen als u niet tevreden bent met de aanvaarding van risico's. Lees verder.
Wat werkt tegen aanvallen waarbij kwaadaardige componenten worden gebruikt
Solide versiebehandeling
Versie vastzetten met gecontroleerde en geïnformeerde versie-hobbels is de juiste keuze om de noodzaak van het verwijderen van kwetsbaarheden zonder het ontvangen van malware in evenwicht te brengen. Maar vergeet misvatting #3 niet: het vastzetten van versies alleen is niet voldoende om kwaadaardige code uit nieuwe versies te blokkeren, omdat u in de toekomst versies in elke directe of indirecte afhankelijkheid zult moeten bijwerken. Op dat moment heb je bewijs nodig dat sterk genoeg is dat alle aangepaste versies geen malware bevatten.
Vroege waarschuwing
Eén benadering van het probleem van kwaadaardige componenten is een systeem voor vroegtijdige waarschuwing (hier genoemd als Vroegtijdige waarschuwing voor malware of MEW), waarbij nieuwe gepubliceerde versies (voor nieuwe of bestaande componenten) worden geanalyseerd door een detectie-engine, die, wanneer er voldoende bewijs wordt gevonden, de nieuwe versie als potentieel schadelijk kan classificeren.
Automatisering is hierbij essentieel, omdat het onmogelijk is om alle nieuwe componenten handmatig te beoordelen tegen het huidige publicatietempo. De detectie-engine moet dus een verscheidenheid aan technieken combineren, misschien inclusief statische, dynamische en capaciteitsanalyse, gebruikersreputatie en bewijsmateriaal dat voortkomt uit discrepanties tussen de metagegevens van de componenten en de tarball-inhoud, of tussen tarball en de bronrepository waar de component zogenaamd aanwezig zou zijn. komt van.
Er is een donkere zone tussen het publicatietijdstip en het moment waarop de engine de inhoud van de componenten analyseert, maar dit mag niet langer duren dan een paar minuten. Het schema kan worden gewijzigd, bijvoorbeeld door te wachten tot nieuwe componenten zijn geanalyseerd voordat ze kunnen worden geïnstalleerd en gebruikt in de softwareontwikkeling pipelines, of analyseer ze indien nodig op aanvraag. Een component in een bepaalde versie is onveranderlijk [3], dus het hoeft slechts één keer te worden geanalyseerd.
Volledige automatisering is niet mogelijk en er is een beveiligingsonderzoek naar potentieel schadelijke componenten nodig. Pas op voor voorstanders van digitale wondermiddelen: AI en Machine Learning zijn niet voldoende ontwikkeld om het laatste woord te nemen als het gaat om het bevestigen of een verdacht onderdeel malware bevat. Zeker, machinaal leren speelt een sleutelrol in de detectie-engine bij het classificeren van de invoercomponent op basis van het vastgelegde ruwe bewijsmateriaal, maar zodra de component in quarantaine is geplaatst, is het laatste woord aan de handmatige beoordeling door een beveiligingsteam met ervaring in kwaadaardige componenten. Dit bevestigt eventuele malware of classificeert deze opnieuw als veilig. En de tijdsperiode ligt in het urenbereik.
Het register rapporteert over de kwaadaardige versie/component; het register voert vervolgens een beoordeling uit om dit te bevestigen en gaat over tot openbaarmaking en verwijdering uit het register. Sommige registers houden een beveiligingspakket bij. Het tijdsbereik hier is de dagen of weken sinds de publicatie, wat de 'verblijfstijd'of'belichtingsvenster' voor de meeste kwaadaardige componenten.
Is het mogelijk om te weten of een componentversie schadelijk is?
Voor vroegtijdige waarschuwing moeten we dus een bevredigend antwoord geven op deze vraag: hoe kan ik weten dat een bibliotheek of pakket (niet) kwaadaardig is? Hoe verzamel je voldoende bewijs van kwaadwillig gedrag? Mogelijk, maar moeilijk, omdat de tegenstanders veel vindingrijkheid gebruiken om detectie te voorkomen. Er zijn verschillende benaderingen, elk met voor- en nadelen.
Statische analyse kan alle uitvoeringspaden onderzoeken, controleren op technieken die door aanvallers worden gebruikt zonder de component uit te voeren, en voorverwerkingstaken uitvoeren, zoals de-verduistering of ontcijfering. Terwijl aanvallers hun kwaad proberen te verbergen, zijn verduisteringspogingen inderdaad een bewijs van malware (maar houd er rekening mee dat legitieme componenten code voor het behoud van intellectueel eigendom verdoezelen, wat in tegenspraak is met “open source”). Slechts een minderheid van de zeer geavanceerde aanvallen met sterke verduistering heeft sandboxing nodig, maar zo'n sterke verduistering is een duidelijk teken van kwaadaardigheid. Houd er rekening mee dat conventionele SAST Hulpmiddelen zijn ontworpen voor onbedoelde kwetsbaarheden, niet voor kwaadaardige bedoelingen zoals achterdeurtjes.
Dynamische analyse voert de component uit en onderzoekt de respons door de runtime te instrumenteren, meestal door een sandbox-omgeving te bieden. Schadelijk gedrag dat onder bepaalde omstandigheden wordt geactiveerd, kan onopgemerkt blijven: houd er rekening mee dat malware gebruik kan maken van ontwijkingstechnieken zoals Virtualisatie/Sandbox-ontduiking wordt alleen geactiveerd als er geen toezicht op is, en is ook een teken van kwaadwillige activiteit voor elke statische analyse-engine.
Capaciteitenanalyse houdt rekening met wat de component doet: waar hij verbinding mee maakt, tot welke bestanden hij toegang heeft, welke opdrachten of programma's worden uitgevoerd, welke terminal of apparaat-I/O wordt uitgevoerd, of welke systeemaanroepen worden aangeroepen. Deze vingerafdrukken van gedrag kunnen (voor een bestaande component) tussen versies worden vergeleken, dus wanneer onverwacht gedrag wordt gedetecteerd, kan dat bewijs het vermoeden wekken van mogelijke kwaadaardige activiteit die in de nieuwe versie is geïnjecteerd. Deze aanpak volgt de triagestappen die beveiligingsanalisten volgen wanneer ze worden geconfronteerd met potentiële malware: een inspectie met behulp van strings of soortgelijke hulpmiddelen. Deze aanpak detecteert kwaadaardig gedrag, ongeacht de triggeromstandigheden, en werkt als er geen broncode beschikbaar is.
Contextanalyse verzamelt informatie over hoe het onderdeel is gepubliceerd en door wie. Bij campagnes van slechte actoren wordt vaak gebruik gemaakt van nieuwe gebruikersaccount(s) die niet aan een strikt controleproces zijn onderworpen. Het volgen van activiteiten uit het verleden kan inzicht geven in de onderliggende gebruiker, vooral voor afwijkingen die kunnen wijzen op een mogelijk compromis. Een reputatie is zo moeilijk te verdienen en zo gemakkelijk te verliezen! Een gebruiker zonder activiteiten in het verleden is neutraal, maar karma achtervolgt de kwaadwilligen. Hacktivisten of normale gebruikers waarvan de publicatiegegevens zijn gestolen, moeten zorgvuldig worden gevolgd.
Een andere contextuele informatie is elke discrepantie tussen de bronrepository die zogenaamd wordt gebruikt om de component-tarball te maken en de inhoud van de tarball zelf. En ook het volgen van goede praktijken, zoals het maken van tags of releases in de bronrepository die overeenkomen met de versies van de component die in het openbare register zijn gepubliceerd. Wanneer de bronrepository op een bepaald commit wordt getagd met release, en dan plotseling één versie er niet in slaagt deze te volgen, dat alleen al is een sterk bewijs dat de component besmet zou kunnen zijn: de slechte acteur heeft mogelijk het account gecompromitteerd dat wordt gebruikt voor het publiceren van de component, maar heeft geen schrijfrechten in de broncode opslagplaats). Veel aanvallen worden routinematig gedetecteerd met behulp van deze regels: bijvoorbeeld de Grootboek aanval langs deze lijnen gemakkelijk kunnen worden gedetecteerd. Contextanalyse identificeert daarom dergelijke afwijkingen in het publicatieproces.
Afhankelijkheidsfirewall
Een andere aanpak is om een uitgebreide witte lijst met componenten te hebben voor alle afhankelijkheidsgrafieken die in uw software worden gebruikt, dus in elke build pipeline die in uw organisatie worden uitgevoerd, kunnen alleen goedgekeurde componentversies worden geïnstalleerd en gebruikt. De "firewall' wordt afgedwongen met behulp van een intern register waar de tarballs voor de toegestane componentversies worden aangeboden (in cache of proxy). Houd er rekening mee dat een witte lijst niet zal werken tenzij u over de technologie beschikt om een nieuwe versie als redelijk veilig te classificeren, zodat deze aan de witte lijst kan worden toegevoegd.
Houd er rekening mee dat vroege waarschuwing (snelle detectie zo snel mogelijk na publicatie van de nieuwe versie) moet worden gecombineerd met een manier om die informatie proactief te gebruiken om de component die de build beïnvloedt te blokkeren pipelines of de machines van de ontwikkelaars [4]. Wij noemen dit “afhankelijkheidsfirewall”: een quarantainemechanisme om geautomatiseerde builds te beschermen tegen kwaadaardige pakketten. Interne pakketten en beeldregistraties zijn goed om organisaties te beschermen tegen kwaad van buitenaf, maar bewijsmateriaal dat sterk genoeg is, is noodzakelijk om quarantaine effectief te maken.
Runtime-sandboxen
Een alternatieve benadering voor detectie tijdens publicatie is het analyseren van gedrag tijdens runtime. Het idee is om het verwachte gedrag van de software vast te leggen en eventuele gevonden afwijkingen te detecteren (of te blokkeren). Deze actielijn heeft het probleem dat de looptijd moet worden geïnstrumenteerd voor monitoring of blokkering, en het is een veelbelovend idee dat zal worden toegevoegd aan het arsenaal aan beschermingsmechanismen tegen de kwaadaardige componentplaag.
Een alomvattende strategie opstellen
De aanbevolen strategie moet verschillende technieken in het softwareontwikkelingsproces combineren, waarbij de controle over de versie-updates wordt overgenomen om binnenkomende kwaadaardige componenten te blokkeren. We moeten het vastzetten van versies mogelijk maken om automatische infectie te voorkomen door versies bij te werken om oplossingen te krijgen voor de kwetsbaarheden die er toe doen; een snelle en efficiënte beoordeling van directe en indirecte afhankelijkheden tijdens versie-updates om voldoende bewijs te hebben dat ze niet door malware worden geteisterd. Softwarebuilds die afhankelijk zijn van bekende kwaadaardige componenten moeten worden geblokkeerd. En alles moet worden afgedwongen.
Gebruik indien mogelijk versie vastzetten, omdat dit builds reproduceerbaarder maakt. Versievastzetten met gecontroleerde, handmatig goedgekeurde versiehobbelsen bijgestaan door helpertechnologie, moet beoordelen of de update malware met zich meebrengt of de software verbreekt, en updates voor het verhelpen van kwetsbaarheden verzoenen met het voorkomen van malware-infectie. Tooling kan hierbij helpen, door (1) prioriteit te geven aan welke kwetsbaarheden er echt toe doen (bereikbaar en exploiteerbaar, met een hoog risico om het doelwit te worden van aanvallers), (2) de doelversies te selecteren die compatibel zijn met het huidige componentgebruik en de software, (3) het kiezen van doelversies die geen kwaadaardig gedrag bevatten, en (4) het updaten van de versie voor directe en indirecte afhankelijkheden in een handomdraai, door wijzigingen in de manifestbestanden voor te stellen die snel kunnen worden goedgekeurd. Voor stap (3) is specifieke informatie nodig over kwaadaardige componenten, zo dicht mogelijk bij hun publicatietijd.
Dit proces van het bijwerken van afhankelijkheden moet zo zijn afgedwongen en geverifieerd op alle plaatsen. Het proces moet worden gedocumenteerd en alle betrokken partijen moeten worden getraind, aangezien de ontwikkeling en softwarebouw/-implementatie vaak wordt geëxternaliseerd. De CI/CD pipelines moeten dienovereenkomstig worden aangepast, zodat automatisering niet toestaat dat er een kwaadaardige indirecte afhankelijkheid in de build terechtkomt: guardrails de aanbevolen manier om de build te blokkeren als er voldoende bewijs is van potentiële malware in een afhankelijkheid.
Als uw organisatie een intern register heeft dat fungeert als beveiligingsproxy voor het bewaren van de toegestane componentversies, moet u informatie verkrijgen over kwaadaardige componenten (naast andere criteria) om een aangevraagd onderdeel te controleren voordat u het aan de toegestane lijst toevoegt.
Het veilig consumeren van open source-software is niet eenvoudig en er moet volledig rekening worden gehouden met de factor malware, terwijl vergelijkbare inspanningen moeten worden geleverd bij het omgaan met kwetsbaarheden.
Nog een laatste opmerking: Bron herkomst, in de vorm van softwareattesten, gegenereerd tijdens de bouwtijd van de component, is een ander belangrijk onderdeel in de poging om het artefact (component-tarball) te traceren met de bronnen en het bouwproces dat het heeft geproduceerd. Houd er rekening mee dat deze koppeling tussen de bronsnapshot + bouwomgeving en het bijbehorende softwareartefact (ondertekend door het vertrouwde bouwsysteem) niet per se verhindert dat de component geen kwaadaardig gedrag bevat, maar het voor de slechteriken moeilijker maakt om malware te injecteren . En het zal lang duren om herkomstvalidatie tot een algemene vereiste te maken voor het consumeren van open source-componenten onlangs toegevoegd aan NPM. Het fraudebestendig maken van deze vertrouwde bouw- en implementatiesystemen, of het mogelijk maken van detectie van manipulatie in de build, is een ander verhaal en valt buiten het bestek van dit bericht.
Verdere lezing
De volgende aflevering Open source kwaadaardige pakketten: de Xygeni-aanpak zal voor ons de strategie presenteren die we bij Xygeni volgen Vroegtijdige waarschuwing voor malware (MEW)-systeem. Nieuwe pakketversies in de openbare pakket- en beeldregisters worden gescand en bewijsmateriaal wordt verkregen met behulp van een combinatie van statische, dynamische, mogelijkheden en contextuele analyse. Het bewijsmateriaal, gecombineerd met de reputatie van de gebruiker en de geschiedenis van veranderingen in broncodeopslagplaatsen, maakt een volledig geautomatiseerde classificatie van een component in risicovolle en waarschijnlijk kwaadaardige categorieën mogelijk. Het systeem leert van bewijs uit het verleden dat uit pakketten is verzameld, om het aantal valse positieven tot een minimum te beperken.
Geabonneerde organisaties ontvangen een waarschuwing voor componenten die zij direct of indirect gebruiken wanneer een kwaadaardige versie wordt gecategoriseerd. Vervolgens wordt er door onze analisten een handmatige analyse uitgevoerd, die de classificatie bevestigt of verwerpt. Bij bevestigde malware wordt het openbare register op de hoogte gesteld, zodat het zijn eigen analyse kan uitvoeren en doorgaans de kwaadaardige versie kan verwijderen of aanvullende actie kan ondernemen, zoals het blokkeren of verwijderen van het betreffende gebruikersaccount.
We zullen uitleggen hoe we NPM, PyPI, GitHub en andere belangrijke infrastructuren in het open source-ecosysteem helpen om de verblijftijd te verkorten waarin een nieuw gepubliceerd kwaadaardig onderdeel actief blijft totdat wordt bevestigd dat het malware is en uit het register wordt verwijderd. En hoe organisaties kunnen profiteren van het MEW-systeem om een veel betere bescherming te krijgen tegen aanvallen op de softwaretoevoerketen waarbij open source-componenten betrokken zijn.
- [1] Hoe dan ook, gebruikers van de component moeten controleren of de tarball van de component ergens in de cache is opgeslagen of ergens is geregistreerd, bijvoorbeeld in een intern register, zodat de ziekte wordt uitgeroeid.
- [2] De verpakte component bevat een manifest waarin de inhoud en metagegevens, de bron- of gecompileerde code, installatiescripts en aanvullende items zoals testsuites worden gedeclareerd, volgens een verpakkingsformaat en doorgaans in gecomprimeerde vorm. Dit wordt de “component-tarball” genoemd.
- [3] Zelfs als de kwaadwillende een gepubliceerd onderdeel kan wijzigen vanwege een inbreuk op het register zelf, kan een eenvoudige cryptografische samenvatting elke verandering in de tarball detecteren nadat de analyse is uitgevoerd.
- [4] Houd er rekening mee dat sommige kwaadaardige componenten tijdens de installatie worden uitgevoerd, dus dit kan invloed hebben op ontwikkelaarsknooppunten die onbewust “npm install X” uitvoeren terwijl X een kwaadaardig onderdeel is.
