Bedrijven omarmen open source veel vaker en gemakkelijker dan jaren geleden. Ruim driekwart van de bedrijven heeft tenminste een deel van zijn processen draaien op open source-software. Inzicht in waar en hoeveel open source de bedrijfssoftware precies bevat, ontbreekt vaak volledig.

67 Procent van de bedrijven verzuimt broncode goed te controleren op kwetsbaarheden en loopt daardoor onnodig risico’s (bron: Future of Open Source Software 2015). Dat open source-code vaak niet wordt gecontroleerd op de beveiliging, verbaast Kevin Bland niet. Bland is Director Channel and Alliance EMEA bij Black Duck Software, een Amerikaans bedrijf dat zich heeft gespecialiseerd in de beveiliging van open source-code. “Applicaties worden of in gesloten (proprietary) code of open source-code gemaakt. Ontwikkelaars gebruiken liever al bestaande code dan dat ze zelf alles gaan schrijven.”

Veel CIO’s en IT’ers weten niet goed waar ze binnen de organisatie open source-code gebruiken en waarvoor het wordt gebruikt. Daar ontbreekt vaak beleid om dat goed te registreren, zegt Bland. Ontwikkelaars weten soms nog wel welke delen broncode ze gebruiken, maar een duidelijk overzicht daarvan ontbreekt. “Als je een bepaald stuk open source-code wilt gebruiken, moet je er wel eerst zeker van zijn dat het veilig is. Door het ontbreken van een helder overzicht of proces om open source-code te gebruiken, worden componenten en software zomaar geïntroduceerd zonder dat er vooraf is gecheckt of alles veilig is.”

Ter illustratie vergelijkt Bland broncode met het chassis van een auto. “Je kunt er een auto omheen bouwen. Maar als de auto klaar is, weet je eigenlijk niet zeker of het chassis wel goed was. Tenzij je een manier hebt om dat te meten of na te gaan.”

Als een organisatie niet op de hoogte is van een bestaande kwetsbaarheid in de code en ze verkopen de applicatie aan duizenden klanten of er zijn miljoenen internetters die het gebruiken, weten ze ook niet dat ze risico lopen om geïnfecteerd te raken dankzij dat specifieke lek.

Uiteraard kan je als bedrijf je applicatie laten onderwerpen aan een penetratietest, maar volgens Bland bestaan er wel zo’n 100.000 kwetsbaarheden, en kennen die ‘pentesters’ zelf daar maar 10 procent van. Een groot deel van de beveiligingslekken wordt dus wel publiekelijk gemeld maar door het grote aantal gaan veel meldingen aan de aandacht voorbij. Of zoals Bland het verwoordt: “Niet elk lek krijgt de media-aandacht zoals Heartbleed.”

Kwetsbaarheden

Open source is volgens Bland niet veiliger of onveiliger dan andere software. Maar er zijn bij beide soorten software risico’s. De kwetsbaarheden in open source en gesloten code zijn even ernstig. “Het probleem met gesloten code is alleen dat je geen controle hebt op hoe en wanneer het verholpen wordt. Je bent afhankelijk van de makers/ontwikkelaars. Met open source heb je een hele community.”

Black Duck kan voor klanten opzoeken welke open source-code er wordt gebruikt en binnen welke applicatie of bedrijfsproces deze wordt gebruikt. Vervolgens wordt de code gescand op zoek naar kwetsbaarheden. “We monitoren broncode op zoek naar bekende lekken die gemeld zijn en putten daarbij uit onze unieke database, de Black Duck Knowledge Base. We ontdekken geen nieuwe lekken. We hebben toegang tot een database met kwetsbaarheden, die elke dag wordt bijgewerkt. Daarin zijn 7500 openbare community’s en fora op internet opgenomen, waar kwetsbaarheden worden gemeld.”

Kwetsbaarheden zitten niet alleen in complete programma’s zoals Firefox of een Linux-distributie, maar vaker juist in een component dat door ontwikkelaars in software is verwerkt. Zeker in een tijd dat van ontwikkelaars hoge doorloopsnelheden en grote flexibiliteit worden verwacht, ligt het voor de hand gebruik te maken van componenten die in de open source-community beschikbaar worden gesteld, in plaats van zelf het wiel opnieuw uit te vinden. Een duidelijk voorbeeld hiervan is OpenSSL. Een ander voordeel hiervan is dat de meeste open source-componenten door de community getest en gecontroleerd worden, zodat eventuele kwetsbaarheden snel ontdekt en gedicht worden. Belangrijk is wel dat de in bedrijfssoftware verwerkte componenten naar die inzichten worden bijgewerkt – en daarvoor ontbreken gewoonlijk de inzichten en procedures.

Licenties

Aan het gebruik van open source-broncode, kleven ook commerciële risico’s. Dat hangt vooral samen met de softwarelicenties die gebruikt worden. Veel gebruikt in de open source-wereld is GNU General Public License (GPL). “Dit betekent dat als je een stukje GPL-code in je product opneemt, jouw product automatisch ook open source wordt en dus voor iedereen inzichtelijk.”

Ontwikkelaars kijken niet zo nauwkeurig naar de licenties, maar plakken de code gewoon in hun product, zegt Bland. Als dat een stuk GPL-code is, wordt je product open source, en als je je software commercieel verkoopt, is dat het laatste wat je wilt. Daarnaast is de aGPL-licentie in opkomst, vooral bij clouddiensten. “Als je GPL in een cloudomgeving gebruikt, maak je het niet openbaar, maar stel je het beschikbaar. De aGPL-licentie wordt steeds meer gebruikt door de opkomst van cloudomgevingen. De aGPL-licentie zegt eigenlijk dat als een open source-component gebruikt wordt in software die gedistribueerd is of op afstand te gebruiken is in een cloudomgeving, dat product of die webapplicatie ook open source wordt.” Veel organisaties zijn zich daar volgens Bland nog niet bewust van.

Weet wat je niet weet

Er kleven meer risico’s aan open source-licenties. “Er zijn honderden verschillende soorten open source-licenties”, vertelt Bland. Voldoe je niet aan de licentievoorwaarden, dan kan dat serieuze juridische consequenties en forse claims tot gevolg hebben. “Mijn favoriete voorbeeld is een licentie waarin de auteur eiste dat commerciële gebruikers van de code een filmpje van zichzelf op YouTube zouden plaatsen waarin ze een raar dansje deden. Uiteindelijk heeft de directie van het bedrijf dat daarmee te maken kreeg dat ook werkelijk gedaan, simpelweg omdat hun juridische afdeling duidelijk maakte dat het alternatief veel minder aantrekkelijk was.”

Black Duck brengt, behalve bekende kwetsbaarheden, ook de licenties in kaart waarmee bedrijven te maken krijgen als ze open source-broncode in hun software verwerken. Hoewel het bedrijf nog niet zo lang in Europa actief is, werkt het wereldwijd al jaren samen met grote namen als ADP, Airbus, Dell, Intel, LG Electronics, Samsung, SAP, Siemens en Yahoo!. “We helpen ze de broncode te scannen en de open source-componenten te identificeren, maar we helpen ze niet om eventuele kwetsbaarheden in code op te lossen,” zegt Bland. Voor dat laatste zoekt Black Duck samenwerking met geschikte partners. “Als er binnen een component van jouw product een kwetsbaarheid wordt gevonden, kun je dat meestal niet zomaar even vervangen. Vaak moet de software dan opnieuw gebouwd of herschreven worden.”

De uitdaging waar de meeste bedrijven voor staan, is ontdekken of ze een probleem hebben. “Het ergste probleem is dat je niet weet dat je een probleem hebt.” Bland maakt weer een vergelijking met autorijden. “Als je tijdens het autorijden merkt dat je remmen niet werken, heb je een probleem. Het is beter om erachter te komen dat de remmen niet werken, voordat je in de auto stapt. Zo is het met software ook.”