Een recent onderzoek uitgevoerd door Snyk naar de staat van open-source beveiliging heeft alarmerende resultaten opgeleverd: voor NPM-pakketten zit 86% van de beveiligingsproblemen in secundaire afhankelijkheden waar je vaak weinig controle over hebt.
Wat zijn secundaire afhankelijkheden?
Als je iets van NPM installeert, installeer je niet slechts één pakket, je installeert ook dat pakket, plus alle vereiste afhankelijkheden. U kunt deze afhankelijkheidsboom voor uw eigen projecten bekijken met
npm ls -- depth=10Zelfs een basisproject met twee geïnstalleerde pakketten bevat in feite vier niveaus van afhankelijkheden, in totaal 10 daadwerkelijke pakketten:
Het probleem is dus duidelijk. Je ha alt code uit veel meer pakketten dan je
package.json zou suggereren. En elk van die pakketten is een potentiële beveiligingsbug.
Volgens het rapport van Snyk is dit precies wat er gebeurt in open source-omgevingen zoals NPM en Ruby Gems. Het probleem is groot en de meeste bugs komen van indirecte pakketten die je niet handmatig hebt geïnstalleerd.
De positieve kant: dit probleem is niet zo erg als het klinkt. NPM heeft een ingebouwde tool voor auditing die de meeste vervelende dingen zal opvangen en je vertellen om te updaten. Vanwege de prevalentie van auditing krijgen deze beveiligingsbugs meer aandacht en worden ze verholpen wanneer ze zich voordoen, waarbij updates snel naar de getroffen gebruikers worden gepusht.
De meeste door Snyk gevonden bugs waren potentiële XSS-aanvallen, en hoewel dat niet geweldig is, is hun impact in de echte wereld vrij laag. De belangrijkste bugs kwamen neer op enkele tientallen prototype-vervuilingsaanvallen - mogelijke uitvoering van willekeurige code - evenals enkele kwaadaardige of gehackte pakketten die speciaal zijn ontworpen om te proberen nietsvermoedende
package.json binnen te sluipen 's.
Het probleem wordt ook beter, of krijgt in ieder geval meer aandacht. Het aantal bugs dat in NPM werd gemeld, was vorig jaar met 20% gedaald en dezelfde trend gold voor andere ecosystemen van pakketbeheerders.
De belangrijkste conclusie van dit alles: je moet nadenken over waar je code vandaan komt. Met de opkomst van FOSS-software is het gemakkelijk om verstrikt te raken in de afhankelijkheidshel met code die je niet van plan was toe te voegen.
De oplossing: controle
Er zitten ongetwijfeld bugs in willekeurige stukjes open-source code, en hoewel je sommige van de kleine niet echt kunt repareren zonder alles in eigen huis te ontwikkelen, kun je enkele van de bijzonder vervelende problemen opsporen met regelmatige audits.
Het probleem is echter niet bijzonder nieuw, en
npm
heeft een ingebouwde tool voor deze-
npm-audit. Je hebt het zeker al eens eerder gezien, want het wordt automatisch uitgevoerd wanneer je het installeert:
NPM's ingebouwde auditing controleert meestal alleen op updates voor pakketten die bepaalde bugs oplossen, dus er is altijd een upgrade die je kunt maken (hoewel deze mogelijk kapot gaat) die het probleem kan oplossen. Er bestaan echter nog andere beveiligingsscanners, zoals Snyk zelf, die een service uitvoeren voor het controleren van GitHub-projecten, en die een openbaar toegankelijke database met bekende bugs onderhouden die u kunt bekijken.
