Gebruik van open source software niet altijd even veilig

Open source software

Het gebruik van third-party open source componenten is een deel van het dagelijkse leven van een developer. Als bepaalde code online verkrijgbaar is, is het niet nodig om deze opnieuw te gaan uitvinden. Het gebruik van bestaande code is ook populair omwille van de tijdsefficiëntie.  Er is echter ook een keerzijde aan de medaille. Bij het gebruik van third-party code geven we een bepaald niveau van vertrouwen aan die ontwikkelaars. Nochtans is het meestal niet geweten wie de code juist onderhoudt. Hierdoor is er geen garantie dat de software nog steeds op dezelfde manier werkt zoals de versies ervoor.

Supply chain attacks

Bij een supply chain attack wordt er malicious code toegevoegd aan de bestaande code, of worden libraries gekopieerd. Deze geüpdatete versie van de library wordt vervolgens door ontwikkelaars gebruikt in hun nieuwe projecten, waardoor de malware wordt verspreid. Developers willen vaak niet te veel tijd besteden aan het onderzoeken van de changes in de libraries die ze gebruiken. Er wordt op gerekend dat de ontwikkelaars van de vorige code betrouwbaar zijn.

Zelfs al zouden de ontwikkelaars de tijd nemen om de veranderingen te evalueren, dan nog is het niet evident om de malicious code te vinden. Libraries binnen een project kunnen afhankelijk zijn van andere libraries, of er wordt gebruik gemaakt van modules die geëncapsuleerd zijn waardoor het langer duurt. Op deze manier is het moeilijk om als gebruiker van de software na te gaan of de libaries malicious zijn geworden sinds de laatste update. Wel kan er bij zulke situaties gebruik gemaakt worden van dependency checkers of gekozen worden voor commerciële oplossingen.

Hoe kunnen we ons dan wel beveiligen?

Er zijn verschillende vormen van beveiliging : zoals het verschillende keren nakijken van de code en dit tijdens het volledige ontwikkelingsproces; approval/ validation van third party code; code sandboxing… Het is ook altijd een goed idee om de hash values van software te vergelijken via threat intelligence en indicators of compromise (IOC). Ook een sandbox kan de gevaren van een software blootleggen. Hierbij wordt er gekeken naar het gedrag van de libraries. Gezien het gevaar en de opkomst van software supply chain attacks, is het belangrijker dan ooit om beveiligingsmaatregelen te treffen tegen het releasen van software met een malware payload. Als software bouwers niet testen tegen malware bij elke build, lopen ze het gevaar om ongewild de reputatie van hun bedrijf (mogelijks permantent) te beschadigen. Natuurlijk willen we het gebruik van third-party producten niet ontmoedigen, maar we adviseren wel om de veiligheid en de authenticiteit grondig te testen alvorens deze code als basis te gebruiken voor jouw project.

Bronnen:

https://gblogs.cisco.com/uki/protecting-against-supply-chain-attacks/ https://www.opswat.com/blog/how-to-protect-against-software-supply-chain-attacks https://www.crowdstrike.com/blog/should-you-worry-about-software-supply-chain-attacks/ https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/supply-chain-malware

Tijd voor een gesprek?

ICONS

Contacteer ons

Wil u weten hoe uw security en netwerk ervoor staan? Met een diepgaande audit brengen we uw security uitdagingen en volledige netwerk in kaart.