DevOps-beveiligingsbedrijf JFrog heeft drie open source-beveiligingstools uitgebracht als reactie op recente problemen met npm om JavaScript-ontwikkelaars te helpen bij het detecteren en voorkomen van de installatie van problematische pakketten.
Aanvallen op de toeleveringsketen van software worden een groot probleem in het open source software-ecosysteem, waarbij aanvallers informatie-stealers, keyloggers en andere soorten malware in pakketbeheerders en opslagplaatsen zoals npm, RubyGems en PyPi smokkelen. In veel gevallen hebben de pakketten die de kwaadaardige code bevatten namen die lijken op bekende, legitieme pakketten. In andere gevallen is er met de pakketten zelf geknoeid. Vorige week is de beheerder achter twee veelgebruikte JavaScript-bibliotheken opzettelijk beschadigd kleuren.js en faker.js, wat problemen veroorzaakt met tienduizenden JavaScript-toepassingen die op die pakketten vertrouwen.
"Het laatste npm-incident is slechts een ander voorbeeld in een reeks recente open-source softwarekwetsbaarheden die zijn ontdekt en die mogelijk grote schade aanrichten aan bedrijfssystemen over de hele wereld", zegt Ilya Khivrich, senior directeur geavanceerde technologieën en beveiligingsonderzoek bij JFrog. "Het is een goede herinnering dat zelfs de softwarebronnen waarvan we denken dat ze te vertrouwen zijn, gemakkelijk in één dag kunnen worden verbroken - en daarom moeten we altijd goede cyberhygiëne toepassen."
De nieuwe instrumenten — pakket_checker om te controleren of een specifieke versie van een pakket kan worden vertrouwd, npm-secure-installatieprogramma om pakketten te blokkeren die de . missen npm-shrinkwrap-lock.json bestand en pakket_problemen_geschiedenis om pakketten te controleren op problematische updates — zijn beschikbaar op GitHub.
pakket_checker kan worden gebruikt "om actief nieuwe versies van gebruikte pakketten te testen voordat ze besluiten de afhankelijkheid bij te werken, of door organisaties om alle nieuwe versies van intern gebruikte pakketten te controleren", zegt het bedrijf. De tool zoekt naar hints dat het pakket is gebruikt bij supply chain-aanvallen en identificeert potentiële risico's met nieuwe versies. Tekenen dat de versie van het pakket niet te vertrouwen is, zijn onder meer een "aanzienlijk gat" in versienummers, een update voor een pakket dat lange tijd niet is onderhouden, verschillen tussen de versie in npm en in de GitHub-repository, en hoe onlangs is de versie geplaatst.
In plaats van gebruiken npm installeren (officieel installatieprogramma) om pakketten wereldwijd te installeren, kunnen ontwikkelaars de wrapper gebruiken npm-secure-installatieprogramma om beveiliging toe te voegen aan het installatieproces. npm krimpfolie is een ingebouwd mechanisme vergelijkbaar met: pakketten-lock.json, die de versies van vereiste pakketten en hun nakomelingen vergrendelt voor een gepubliceerd pakket. Dit betekent dat de exacte versies van alle afhankelijkheden worden bevroren, waardoor het risico van het gebruik van een recent bijgewerkt defect softwareonderdeel wordt verkleind. De wrapper-tool zoekt naar het vergrendelingsbestand voor het pakket en weigert het pakket te installeren als het ontbreekt.
Een opmerking over het gebruik van npm-secure-installatieprogramma: het gaat voorzichtig te werk door een vereiste op te leggen (met het bestand met krimpfolie) waaraan zelfs sommige legitieme pakketten niet voldoen, zegt Khivrich.
pakket_problemen_geschiedenis is een "experimentele tool" die probeert te bepalen of een nieuwe pakketversie problematische code bevat. De tool houdt de GitHub-problemen van het pakket in de dagen na een versie-release bij om te zien of er problemen zijn gemeld. De ontwikkelaar bepaalt of de problemen problematisch zijn of niet. "Voor een bibliotheek die populair genoeg is, kan het aantal afhankelijke projecten groot genoeg zijn, zodat de overtollige problemen die het gevolg zijn van een ingrijpende wijziging aanzienlijk zullen zijn met betrekking tot de 'achtergrond'-problemen die geen verband houden met de wijziging", zegt het bedrijf.
De tool is meer bedoeld voor onderzoekers die vroege tekenen van problemen proberen op te vangen in plaats van een concrete stap in de workflow van ontwikkelaars, zegt Khivrich.
Terwijl pakket_checker en pakket_problemen_geschiedenis vlaggen zullen verhogen boven verdacht uitziende pakketversies, kunnen ze andere indicatoren missen die niet werden overwogen of per ongeluk goedaardige versies markeren, zegt Khivrich. Er is geen perfecte methode om kwaadaardige of beschadigde pakketten te onderscheiden van legitieme, dus bescherming tegen problemen met de toeleveringsketen is een "voortdurende industriebrede uitdaging die verschillende beschermingslagen vereist", zegt hij.
