Executives Guide: Dependency Scanning

Als ik met mijn techneutenbril naar een onderwerp als Dependency Scanning kijk, dan zie ik honderden npm packages voor me. Hiervan worden sommigen goed onderhouden en kennen miljoenen gebruikers, terwijl andere packages een keer worden uitgeprobeerd, maar nooit meer verwijderd. Als directielid of ander niet-technisch persoon, lees je waarschijnlijk deze eerste twee zinnen en worden er al minimaal drie termen genoemd die je helemaal niets zeggen. Wat zijn Dependency Scanning, npm en packages en wat moet je met deze informatie?!

Waarom Dependency Scanning interessant is

Ik zal maar beginnen met de reden dat ik deze tekst überhaupt schrijf. Als functioneel persoon werk je misschien samen met softwareontwikkelaars, of misschien dien je als opdrachtgever. Je vertelt ze: “Ik heb probleem x en dat wil ik opgelost hebben voor bedrag y.” Deze ontwikkelaars doen vervolgens hun magie en je krijgt een applicatie terug die je probleem heeft opgelost! Fantastisch natuurlijk, maar hoe zit het eigenlijk met het onderhoud van de applicatie? Misschien heb je afgesproken dat je altijd bij ze terug mag komen als je nieuwe functionaliteit nodig hebt, of dat het bedrijf waar je mee samenwerkt ervoor zorgt dat de applicatie beschikbaar wordt gemaakt en ook blijft.

We gaan er natuurlijk vanuit dat het bedrijf weet waar het mee bezig is, de applicatie netjes heeft beveiligd en er daarmee voor zorgt dat er geen grote beveiligingsrisico’s bestaan. Het kan alleen nooit kwaad om eens te vragen hoe dit is ingeregeld. Informatiebeveiliging is echter een complex onderwerp, wat de kans groot maakt dat je een van de volgende twee antwoorden zult krijgen:

 

  1. Een veel te uitgebreid en complex antwoord waarvan je 75 procent van de termen niet begrijpt.
    ~ óf ~
  2. Een veel te simpel antwoord waar je eigenlijk niet veel kennis rijker van bent geworden.

 

Met dit artikel ga ik je helpen om het eerste gesprek over het onderwerp Dependency Scanning te voeren.

 

Npm, packages en andere terminologie

 

Packages

Laten we beginnen bij de basis. De tijd van een softwareontwikkelaar is schaars en duur. Daarnaast hergebruiken ontwikkelaars graag code, omdat het vervelend is om steeds hetzelfde te bouwen of ze beschikken zelf niet over de nodige kennis om een bepaalde oplossing te programmeren. Hoe handig zou het zijn als je stukjes software als een pakketje zou kunnen uploaden naar het internet, zodat deze vervolgens door andere ontwikkelaars gebruikt kunnen worden? Dit is precies wat packages zijn; stukjes software die in je in je eigen applicatie kan gebruiken. Een goed voorbeeld is misschien een package waarmee je bestanden op een computer op kan slaan. Als ontwikkelaar heb je waarschijnlijk geen zin om voor elke applicatie die een bestand op moet slaan, weer opnieuw uit te vinden hoe je het besturingssysteem (bijvoorbeeld Windows) moet vertellen dit te doen. Hiervoor kun je dan een package downloaden, waar andere mensen moeite in hebben gestoken om dit gebruiksvriendelijk te maken en bovendien werkend te krijgen op verschillende systemen en verschillende softwareversies.

 

Je bespaart als ontwikkelaar met een softwarepackage dus veel tijd en moeite om soms simpele, maar ook juist uitgebreide functionaliteit in je applicatie te bouwen.

 

Npm en andere package managers

Het zal je misschien niet verbazen dat er een applicatie nodig is om verschillende packages te installeren, verwijderen en updaten. Een voorbeeld van zo’n beheerder van packages is de Node Package Manager (npm). Npm is geschikt voor een specifieke programmeertaal, in dit geval JavaScript. Er bestaan veel verschillende packages managers die soms generiek zijn, maar vaak bestemd voor een specifieke taal. Een aantal voorbeelden van deze package managers voor het ontwikkelen van software zijn: pip (Python), Maven (Java) en Composer (PHP).

 

Npm is dus een voorbeeld van een package manager, welke gebruikt wordt om andermans code in jouw applicatie te gebruiken.

 

Dependency Scanning

Wanneer je packages gebruikt in je applicatie, worden dit ook wel dependencies genoemd, omdat je ervan afhankelijk bent voor een goede werking van de applicatie. Als je dependencies scant, controleer je of er bekende beveiligingslekken (vulnerabilities) aanwezig zijn in de packages die je gebruikt. Dit gebeurt meestal automatisch door een Dependency Scanner te gebruiken; een applicatie die inventariseert welke packages en versies je gebruikt, en vervolgens op het internet opzoek gaat naar meldingen van beveiligingslekken voor die specifieke versies.

 

Wanneer je slechts een tiental packages gebruikt zou je denken dat dit ook best handmatig te doen is. Nu wil het zo zijn dat dependencies zelf ook dependencies kunnen helpen. Ofwel: de ontwikkelaars van de stukjes software die je gebruikt, hebben zelf ook weer stukjes code van anderen gebruikt om hún leven makkelijker te maken. Je begint nu waarschijnlijk te begrijpen waarom het beheren van deze dependencies zo’n uitdaging is en al helemaal in de ogen van een securityspecialist. Daarom is het belangrijk om goede tools in te zetten die je volledig automatisch op de hoogte stellen van de laatste beveiligingsrisico’s, zodat de ontwikkelaars dit op kunnen lossen. Niemand wil het slachtoffer zijn van een cyberaanval, terwijl je het had kunnen voorkomen door een simpel pakketje te updaten.

 

Hoe gebruik ik deze informatie in mijn voordeel?

Nu je weet wat een aantal belangrijke termen rondom Dependency Scanning zijn, kun je het gesprek aangaan met ontwikkelaars over het veilig houden van de dependencies van een applicatie. Het kost weinig moeite om te implementeren, maar je kunt er gigantische beveiligingslekken mee voorkomen. Dit zijn de stappen die je zou kunnen zetten:

  1. Inventariseer welke applicaties jouw organisatie zelf ontwikkeld of laat ontwikkelen door een derde.
  2. Zoek uit wie er verantwoordelijk is voor het veilig programmeren van deze applicaties.
  3. Ga met deze persoon in gesprek om uit te vinden hoe de applicatiebeveiliging is geregeld. Ga specifiek in op het scannen van dependencies op bekende vulnerabilities.
  4. Als het antwoord ongeveer neerkomt op: “We gebruiken een Dependency Scanner om uit te vinden of er bekende vulnerabilities aanwezig zijn in de versies van packages die we gebruiken.”, zit je goed.
  5. Als het antwoord ongeveer neerkomt op: “We gebruiken geen Dependency Scanner.”, kun je gelukkig nog veel doen om deze situatie te verbeteren.
  6. Hoe je het beste een Dependency Scanner implementeert, hangt sterk af van de situatie, dus neem vooral contact met ons op om je op weg te helpen. Mocht je GitHub of GitLab gebruiken om code in op te slaan, zijn er binnen die platformen goede mogelijkheden om Dependency Scanning op te zetten. Kijk voor meer informatie op GitHub Docs of GitLab Docs. Een goede externe tool die op meerdere platformen werkt is SonarCloud.

 

 

Ik hoop dat ik het onderwerp Dependency Scanning zo goed op een rijtje voor je heb kunnen zetten. Mocht ik daar niet in geslaagd zijn, neem dan vooral contact met ons op via info@salt-security.com of een ander kanaal waarop we te vinden zijn.

 

Be safe,

 

De cybersecurityspecialisten van SALT

Package afhankelijkheden: de verborgen killer

Het gebruiken van externe packages in je applicaties om het leven makkelijker te maken is iets wat we allemaal doen, maar waar we vaak de gevaren niet goed van voor ogen hebben. Het grote voordeel van open source code uit de community zou moeten zijn dat we op het werk van anderen kunnen leunen én erop kunnen vertrouwen dat andere mensen de code op veiligheid controleren.

Package afhankelijkheden: de verborgen killer

Het gebruiken van externe packages in je applicaties om het leven makkelijker te maken is iets wat we allemaal doen, maar waar we vaak de gevaren niet goed van voor ogen hebben. Het grote voordeel van open source code uit de community zou moeten zijn dat we op het werk van anderen kunnen leunen én erop kunnen vertrouwen dat andere mensen de code op veiligheid controleren.

De gevaren van het blind vertrouwen van ontwikkelaars

Vorige week kwam naar buiten dat er weer eens een WordPress plug-in gigantische gaten in websites veroorzaakt. John Leyden (journalist voor The Daily Swig) schrijft hier het volgende over: “Kwetsbaarheden in OptinMonster, een plug-in voor e-mailmarketing voor WordPress, lieten meer dan een miljoen websites open voor misbruik, waarschuwen beveiligingsonderzoekers van Wordfence.” De plug-in laat aanvallers gevoelige informatie exporteren en kwaadaardige JavaScript toevoegen aan kwetsbare sites, naast andere exploits.

De gevaren van het blind vertrouwen van ontwikkelaars

Vorige week kwam naar buiten dat er weer eens een WordPress plug-in gigantische gaten in websites veroorzaakt. John Leyden (journalist voor The Daily Swig) schrijft hier het volgende over: “Kwetsbaarheden in OptinMonster, een plug-in voor e-mailmarketing voor WordPress, lieten meer dan een miljoen websites open voor misbruik, waarschuwen beveiligingsonderzoekers van Wordfence.” De plug-in laat aanvallers gevoelige informatie exporteren en kwaadaardige JavaScript toevoegen aan kwetsbare sites, naast andere exploits.

Andere artikelen in de Executives Guide serie:

Thomas van den Nieuwenhoff

Thomas van den Nieuwenhoff

Security Blogger voor SALT Cyber Security en student HBO-ICT Infrastructure Design & Security op Windesheim.