Open source software (OSS) speelt in vrijwel ieder belangrijk technologisch product of service een onmisbare rol. Het kan overal vandaan komen. Zo ontstond Linux bijvoorbeeld op een studentenkamer in Finland. Het mooie aan open source is dat iedereen toegang heeft tot open source projecten. Iedereen kan bijdragen, de vruchten plukken en informatie met elkaar delen.
Nu we ons in een wereld bevinden waar digitalisering een steeds grotere rol speelt, zien we dat OSS ook steeds belangrijker wordt en razendsnel groeit. Uit onderzoek van Gartner blijkt zelfs dat meer dan 70% van de ondernemingen tot 2025 hun IT-uitgaven in OSS gaan verhogen. Voor mij komt dit niet als een verrassing omdat in de digitale wereld applicatieontwikkeling het belangrijkste instrument is voor groei, en open source software en tools veel worden ingezet voor software development en -delivery. Hoe efficiënter en productiever de supply chain van je software is, hoe beter de ervaringen van je klant en dus de prestaties van je bedrijf. Om nog maar over de lagere kosten, meer flexibiliteit en productiviteit te zwijgen.
Desondanks maken veel organisaties zich nog zorgen over OSS. Uit onderzoek van VMware Tanzu blijkt dat gebruikers deze risico’s ook zien.Hoewel de meeste IT-professionals de voordelen ondervinden van OSS, is een groot deel van de gebruikers bezorgd over de cyberveiligheid. Ongeveer de helft (56%) van alle respondenten maakt zich zorgen over de afhankelijkheid van de OSS-community als het gaat om patches en bugfixes. Bovendien gelooft een groot deel (47%) van de deelnemers dat het gebruik van OSS de nodige veiligheidsrisico’s met zich meebrengt. Afgelopen december, tijdens de ontdekkking van de Apache Log4J kwetsbaarheid, zagen we ook veel kritische opmerkingen over OSS. Later in dit artikel zullen we hierover terugkomen. Bij het gebruik van OSS is het patchen gedurende de life cycle van applicaties en open source tools extreem belangrijk, omdat de diversiteit van OSS tools vaak groter is. Het integreren en onderhouden van de software is daarom erg belangrijk. Veel respondenten denken dan ook dat OSS zich met name kan verbeteren op het gebied van patching (66%), scanresultaten (60%) en het inzicht in testen (58%).
Maak van security een teamsport
Toch zijn deze security uitdagingen te verbeteren door enkele maatregelen door te voeren. Zo zien we nog te vaak dat security teams beter zouden kunnen samenwerken met developers. Vaak worden developers buiten de security planning gehouden, maar wel belast met de uitvoering van de procedures. Hierdoor ontstaat er een verstoorde relatie tussen development- en security teams. Een goede relatie tussen deze twee teams kan voor veel voordelen zorgen. Denk hierbij aan veiligere applicaties, meer agility en ongoing compliance. Het is daarom raadzaam dat security teams hun processen herbekijken samen met de verschillende teams die de processen moeten omarmen.
Wat wij ook zien is dat security teams vaak een andere taal spreken dan de rest van de organisatie. Hierdoor is het lastig voor de rest van de organisatie om het security beleid- en procedures te begrijpen. Security teams zullen daarom de taal van het development team moeten spreken in plaats van andersom. Een overheidsorganisatie waarvoor wij werken heeft dit sterk verbeterd door iemand aan te stellen binnen het security team die de taal van development teams spreekt. Op deze manier werden de security processen beter geïntegreerd en ontwikkelde deze developers per definitie veiligere applicaties.
Bovendien zien we dat bedrijven succesvoller zijn op het gebied van security als ze gedeelde KPI’s of OKR’s (Objectives & Key Results) doorvoeren. Denk hierbij aan het versnellen van de productiviteit, patch frequentie en minder beveiligingsincidenten. Op deze manier leren beiden teams elkaar beter begrijpen, waardoor ze elkaars prioriteiten serieuzer nemen. Bovendien kan dit zorgen voor minder beveiligingsproblemen.
Om te voorkomen dat development teams worden belemmerd door allerlei security procedures, doen security teams er goed aan om uit de software delivery lifecycle zoveel mogelijk (security) processen te automatiseren. Door automatisering toe te passen, verdwijnt het handmatige samenstelwerk. Bij Cloud applicaties kun je denken aan een automatische manier van creatie en updaten van containers. Bovendien worden kwetsbaarheden, die vaak onbedoeld over het hoofd worden gezien, aanzienlijk verminderd.
Onzekerheden over security niet altijd terecht
Hoewel deze activiteiten de security van OSS kunnen verbeteren, zijn de onzekerheden bij organisaties niet altijd even terecht. OSS is namelijk even veilig/onveilig als closed software, omdat niemand kan beweren dat zijn software 100% veilig is. Zowel OSS alsclosed source software kunnen worden getroffen door een cyberaanval. Ook op het gebied van bugs doet open source niet onder voor closed source. Fouten in de broncode komen namelijk in iedere software voor. Dit kan de software kwetsbaarder maken, omdat ook kwaadwillenden op de hoogte zijn van eventuele zwaktes in de software. Daar tegenover staat dat bugs door de grote open source community vaak sneller opgemerkt en opgelost worden. Iedere ontwikkelaar kan namelijk patches voor bugs uitbrengen. Open source is immers een samenwerking. Er zijn letterlijk duizenden mensen die hun vrije tijd opofferen om samen te werken aan nieuwe softwareproducten. De meeste software ter wereld draait nu op de twee grootste open source-projecten, namelijk Linux en/of Kubernetes. Organisaties kunnen dit ondervangen door de belangrijkste OSS uit te breiden met officiële support.
Sommige organisaties zijn bang dat OSS communities verlaten worden, waardoor de OSS geen updates meer krijgt en kwetsbaarheden niet meer door de community worden gepatcht. Het is daarom belangrijk dat organisaties een cultuur creëren waarbij security een teamsport is. Op deze manier houdt iedereen rekening met beveiliging en worden alle onderdelen in de software supply chain in de gaten gehouden. Dit zagen we onlangs ook met de Apache Log4J kwetsbaarheid. Zodra de kwetsbaarheid was ontdekt werd versie 2.16 snel vrijgegeven. Bij de Tanzu oplossingen hebben we deze patches razendsnel kunnen uitbrengen omdat de technologie voor automatisering van het patch proces zorgt. Zo waren onze klanten, die vele duizenden applicaties hebben, razendsnel gepatcht door één persoon via onze platform automatisering.
We kunnen dus concluderen dat de veiligheid van OSS net zo veilig is als bij closed source software. Echter moeten er wel een cultuur worden gecreëerd waarin alle teams onderdeel zijn van het maken, ontwikkelen en uitvoeren van het security beleid. Maak daarom van security een teamsport, dit creëert veiligere OSS, meer vertrouwen en meer creativiteit. Daartegenover staat dat open source geen doel op zich moet zijn, maar een doel naar ‘business outcomes’. Op deze manier kan er een omgeving worden gecreëerd waar development teams creatief kunnen zijn en meer waarde kunnen toevoegen.
Dit is een ingezonden bijdrage van Rouven Besters, Director Benelux & Nordics bij VMware Tanzu. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.
8 uur geleden
