Gaining Speed Yet Losing Altitude - S1:A4

S1:A4 - Vind het wiel niet opnieuw uit

Voor veel bedrijven is het cruciaal om continu nieuwe releases live te zetten. Dat vraagt om supersnel software ontwikkelen, die per direct de klantvraag adresseert. Low-code platformen maken dit voor steeds meer organisaties en toepassingen werkelijkheid. Maar, de snelheid van low-code ontwikkeling vraagt, nóg meer dan ‘vroeger’, wel om adequate QA- en testoplossingen. Hoe sneller je figuurlijke low-code vliegtuig vliegt, hoe belangrijker het is de juiste maatregelen te nemen om geen hoogte te verliezen.

In de serie Gaining Speed Yet Losing Altitude bespreken we steeds een low-code kwaliteitsuitdaging en de maatregelen die je kunt nemen.

Maar pas op voor de risico's bij het gebruik van Open Source

In mijn vorige blog ('Low-code' staat niet gelijk aan 'no-code') vertelde ik hoe low-code ontwikkelaars soms stukjes 'regular-code' in hun apps gebruiken. Hiermee kunnen ze functionaliteit toevoegen die anders niet beschikbaar zou zijn in low-code-apps. Dit kan prima, zolang je ook de kwaliteit van deze reguliere code maar in de gaten houdt.

In sommige gevallen kan het zelfs zinvol zijn om een bestaande Open Source component te gebruiken in plaats van zelf iets opnieuw uit te vinden, ongeacht of je low-code of regular-code gebruikt. Het gebruik van Open Source componenten kan veel tijd en moeite besparen. Maar … als je mijn vorige blogs hebt gelezen weet je al wat er gaat komen: wees je bewust van de risico's!

Wat is Open Source?

Open Source componenten zijn softwarecomponenten waarvan de code openbaar beschikbaar is. Bijna iedereen mag deze code inspecteren, wijzigen of verbeteren. Bovendien kunnen deze componenten vrij door iedereen worden gebruikt. Dat heeft uiteraard heel veel voordelen.

Dit is de reden dat Open Source componenten vaak worden gebruikt, ook in low-code omgevingen. Sommige onderzoeken zeggen dat ongeveer 90% van alle softwareproducten ten minste één Open Source component bevat. Zelfs als de eigenaren zich hier niet van bewust zijn. Op zichzelf is dat laatste al risico nummer 1. Open Source componenten kun je zonder risico gebruiken, maar de eerste stap is om daadwerkelijk te weten wát je in jouw eigen softwareproducten gebruikt.

Het gebruik van Open Source componenten kan dus voordelen hebben. Maar ze kunnen ook ernstige risico's opleveren voor iedereen die ze gebruikt.

Wat zijn de risico's?

Allereerst zijn eventuele beveiligingsproblemen algemeen bekend. Met andere woorden, als een Open Source component beveiligingsproblemen bevat, is het slechts een kwestie van tijd voordat deze bekend zijn in de hele softwareontwikkelgemeenschap. Dit vormt een reële dreiging omdat cybercriminelen deze kwetsbaarheden relatief gemakkelijk kunnen misbruiken.

Ten tweede kan het gebruik van Open Source componenten een bedreiging vormen voor jouw intellectuele eigendom. Open Source componenten kun je gebruiken volgens verschillende licenties. Er zijn meer dan 2.000 verschillende soorten Open Source licenties. Voorbeelden zijn Apache, GPL en MIT. Sommige van deze licenties bevatten zogenaamde 'copy left' clausules. Als je een Open Source component met dit type licentie gebruikt ben je vrijwel verplicht om al je software die met de Open Source component is gemaakt, volledig vrij te geven. Met andere woorden, al je intellectueel eigendom wordt ineens ook Open Source. Niet heel fijn als je heel veel tijd en geld hebt besteed aan het ontwikkelen van een commercieel product.

Wat is de uitdaging?

Het gaat niet zozeer om hoe je Open Source componenten gebruikt, maar hoe je ze op de juiste manier gebruikt. Ervoor zorgen dat de componenten up-to-date zijn (omdat dit de dreiging van beveiligingskwetsbaarheden beperkt) en ervoor zorgen dat je alleen componenten gebruikt met 'niet-risicovolle' licenties klinkt vrij eenvoudig, toch?

Nou, eerlijk gezegd... nee. Het is eenvoudig zolang je precies weet welke Open Source componenten, versies en licenties je gebruikt! En dát is de echte uitdaging. Hoe houd je bij wat jouw developers gebruiken in een organisatie die tientallen applicaties ontwikkelt en onderhoudt? En om het nog moeilijker te maken: wat als deze applicaties worden gebouwd met low-code platforms zoals Mendix en OutSystems? Met deze platforms kun je JAVA (Maven) en C# (Nuget) Open Source componenten gebruiken. Maar in de praktijk blijkt het bijhouden ervan vaak veel lastiger dan het lijkt. Vooral omdat het analyseren van het gebruik van Open Source componenten in de meeste gevallen géén standaard code-review functionaliteit is.

De oplossing

De oplossing voor de uitdaging is simpelweg een manier vinden om bij te houden welke Open Source componenten, versies en licenties in jouw organisatie worden gebruikt. Sommige organisaties vragen hun ontwikkelteams om dit in Excel-lijstjes bij te houden. Dat kan, maar we weten allemaal dat dat in de praktijk makkelijker gezegd is dan gedaan.

Code-review (door Omnext) is de oplossing!

Zo zorgt Omnext voor jouw veiligheid

Ik heb net gezegd dat het analyseren van het gebruik van Open Source componenten geen standaard code-review functionaliteit is. Hoe helpt het jou dan? Omnext biedt deze functionaliteit wél in combinatie met je ‘gewone low-code quality monitoring’. Het Omnext Fit Test platform analyseert automatisch welke Open Source componenten in bijvoorbeeld jouw Mendix project worden gebruikt. Het vertelt je bovendien welke Open Source componenten verouderd zijn of risicovolle licenties bevatten. En, last but not least, het vertelt je welke Open Source componenten bekende beveiligingsproblemen bevatten.

En dan moet het mooiste nog komen: je hoeft helemaal geen handmatige lijstjes meer bij te houden. Steeds als er een nieuwe Open Source component aan je applicatie wordt toegevoegd, identificeert de Fit Test analyse dit en controleert of er geen ’best practice overtredingen’ zijn. Overzichtelijk in een online portal.

Wil je meer weten? Neem contact op met Omnext via contact@omnext.com

Bezoek www.omnext.com voor meer informatie

Omnext is een Valori solution

Over de auteur

Bryan de Vries is Chief Commercial Officer bij Omnext. Hij is verantwoordelijk voor business en product development en partnerships. Bryan heeft een sterke focus op de low-code oplossingen van Omnext en adviseert organisaties over software kwaliteitsvraagstukken.