Het nieuwe Trojaanse paard zit in je dependencies

Wanneer je als ontwikkelaar code, configuratie of tooling uit een externe bron haalt, dan vertrouw je die bron. Doe je dat zonder te verifiëren wie erachter zit en wat je binnenhaalt, dan zet je onbedoeld de deur open voor een aanvaller. Aanvallen via pakketregisters als npm en PyPI nemen snel toe en verspreiden zich steeds vaker automatisch.

De vraag is niet óf een van jouw dependencies (afhankelijkheden) ooit gecompromitteerd raakt, maar wanneer. In deze blog lees je hoe deze aanvallen werken, wat recente incidenten ons leren en welke maatregelen je vandaag nog kunt nemen.

Een routine-update met een addertje onder het gras 

Stel je voor: als ontwikkelaar voer je op een doordeweekse ochtend een routine-update uit. Je bent security-bewust, dus je rolt updates zo snel mogelijk uit. De build slaagt, de tests staan op groen. Je neemt een slok koffie en geniet even van een goed begin van de dag.
Wat je niet ziet, is dat de installatie zelf een script uitvoerde. Nog voordat de build begon, verzamelde dat script inloggegevens, cloud-tokens en sleutels uit je omgeving en stuurde het die naar een server van kwaadwillenden. Je tests draaiden pas daarna, en die controleren dit soort gedrag niet.
Dit is geen hypothetisch scenario. Het is precies wat de afgelopen maanden steeds vaker gebeurt.

Bij een supplychainaanval compromitteert een aanvaller niet jouw organisatie, maar iets wat jij binnenhaalt en uitvoert: een software library, een build-script, een container-image, een pipeline-actie of een editor-extensie. Jij haalt die afhankelijkheid nietsvermoedend binnen en zet daarmee zelf de deur open. De aanvaller hoeft dus niet door jouw beveiliging heen te breken.[1]

Softwareontwikkeling berust op vertrouwen