Vandaag de dag is open source software de norm in plaats van de uitzondering. Er worden grote hoeveelheden code ontwikkeld en die code duikt op in kritieke toepassingen. Dat levert grote voordelen op voor gebruikers ervan, maar programmeurs moeten zich er ook bewust van zijn dat ze de binnengehaalde code doorlichten voor ze het implementeren.

Josh Bressers is security-strateeg bij open source-leverancier Red Hat. Hij benadrukte dit punt in gesprek met IDG-journalist Paul Krill. Het interview volgt hieronder.

Paul Krill: Waarom maakt Red Hat zich opeens druk om open source-beveiliging?

Josh Bressers: We benadrukken dit al een hele tijd. We hebben tegenwoordig een keten van toeleveranciers van code in plaats van één persoon of partij die software leverde. We zien het nu meer als een channel: leveranciers bouwen onderdelen die worden verwerkt in het product. Net als met hardware is het zo dat als je onderdelen van lage kwaliteit gebruikt, je per definitie een eindproduct krijgt van een lagere kwaliteit.

Ik denk dat we eindelijk beginnen te beseffen dat als je software gebruikt die een commerciële partij of de open source-community aanlevert en je niet precies weet wat het is of niet weet wat de kwaliteit ervan is, de kwaliteit van jouw eindproduct eronder lijdt. Ontwikkelaars die ideeën vinden op GitHub en via Stack Overflow zijn zich niet noodzakelijkerwijs bewust van wat ze precies downloaden en hoe dat wordt onderhouden.

Open source heeft gewonnen van propriëtair: het is overal. Maar dat betekent dat we te maken hebben met een toeleveranciersketen en we moeten nadenken over wat daar de gevolgen van zijn en hoe we daarmee omgaan, want software veroudert en veroudert slecht. We kunnen niet zomaar software in ons project trekken zonder precies te weten wat de effecten op korte en lange termijn zijn.

Krill: Dus wat nu?

Bressers: Het uitgangspunt is dat we vooral moeten begrijpen waar software vandaan komt. In een open source-context betekent dit dat we ernaar moeten kijken zoals we naar een third-party leverancier kijken, dus vooral naar wie erop let. In een zakelijke omgeving heb je óf een team nodig dat kritisch naar codedelen kijkt, of dat je een leverancier vindt die met je kan samenwerken om de code uit te pluizen om te zien wat werkt, wat slecht is, hoe het wordt bijgewerkt - en dat je zeker weet dat je begrijpt wat dit inhoudt.

Lees ook: Leg de schuld van Heartbleed niet bij open source

Dat stukje missen we vandaag. Er zijn veel organisaties waarbij ontwikkelaars zien wat er is in de open source-wereld, code gebruiken die ze nodig hebben en er vervolgens niet meer naar omkijken. Het is logisch dat als je dit doet en de code nooit herziet, er op een moment een probleem ontstaat in de software dat aandacht verdient. Kijk naar Heartbleed. Dat is een prachtig voorbeeld van wat er mis kan gaan: de meeste mensen die OpenSSL in hun applicatie gebruikten realiseerden zich niet dat er een issue was.

Hierna: Kernelbeveiliging en hoe we moeten omgaan met open source-toeleveranciers.

Krill: Hoe gaan we dit veranderen?

Bressers: Ik kan je vertellen wat Red Hat doet, maar het zal per organisatie verschillend zijn. We hebben een team dat kijkt naar open source-code en zoekt naar beveiligingsissues. Hierom is open source anders dan doorsnee softwareleveranciers. Daarbij heb je een product en met het kopen ervan heb je een verwachting dat het onderhouden wordt en dat je bij ze kunt aankloppen voor ondersteuning. Dat werkt net iets anders met open source, waar je in principe twee opties hebt.

De eerste is dat je naar een leverancier stapt die in feite producten maakt van open source. Dat is de oude relatie tussen klant en leverancier. De tweede optie is dat je open source zelf als leverancier beschouwt, maar dat betekent wel dat je actief met de community moet bezig zijn om zelf te zien wat er gebeurt en wanneer er bijgewerkt moet worden.

Ik zou zeggen dat als je als organisatie bezorgd bent over zulk open source gebruik, je moet zorgen voor IT'ers die begrijpen wat er wordt ingezet en kunnen samenwerken met de community op het niveau dat vereist is voor het product dat je gebruikt. Je moet ervoor zorgen dat je programmeurs niet zomaar code gebruiken, maar dat er een procedure is waarbij grondig naar software wordt gekeken om niet voor nare verrassingen te komen. En dat moet werk van hoge kwaliteit zijn.

Krill: Hoe zit het met de Linux-kernel; hoe lichten jullie die door?

Bressers: We staan hier natuurlijk bekend om Red Hat Enterprise Linux, maar zelfs RHEL bestaat uit letterlijk honderden open source-componenten die bij elkaar zijn gevoegd. Het is niet alleen de kernel. Dat is een groot onderdeel ervan en toegegeven, een heel belangrijk onderdeel. We hebben kernel-expertise, maar nog steeds een team dat specifiek kijkt naar de beveiliging van de Linux-kernel en wat daarin gebeurt: zijn dit logische processen en wat is de impact op security ervan? Wat doen we ermee en hoe lossen we het op?

Lees ook: Hoe Linux zijn kernel nog beter beschermt

Heartbleed ging over een component dat onder meer in RHEL was verwerkt: de OpenSSL-library. Het zat ook in enkele van onze middleware-producten, bijvoorbeeld webservers. En er waren producten die OpenSSL van RHEL als image in hun product hadden verwerkt. We moesten kijken naar al deze delen en we hebben teams die puur en alleen bestaan om naar dit soort dingen te kijken om software goed door te lichten.

Hierna: Als het op security aankomt, hoe verhoudt open source zich dan met propriëtaire software?

Krill: Hoe werken zulke processen bij Red Hat en wat raad je anderen aan?

Bressers: Het hangt af van de grootte van je team, hoe gevorderd die is en deels van hoe goed zijn zijn. Enkele library's en applicaties binnen Red Hat onderwerpen we aan fuzz-tests. We voeren geautomatiseerde codescans uit en scannen delen met de hand.

We hebben een aantal interne tools dat kijkt naar de onderdelen die we samenstellen om te zien of we geen voor de hand liggende fouten maakt: als je een RPM-pakket hebt dat de applicatie of library installeert, worden delen dan op logische plekken weggeschreven? We hebben dedicated build-systemen om te inzicht te hebben in wat we bouwen en hoe het wordt gebouwd.

Krill: Denk je dat open source-software vandaag de dag beter beveiligd is dan vijf jaar geleden? Is het veiliger dan propriëtaire software?

Bressers: Open source is niet beter beveiligd dan propriëtaire software, maar ook niet slechter beveiligd. Propriëtaire software zoals we dat lang hebben gezien is aan het verdwijnen, omdat vrijwel elke organisatie open code heeft in de producten die ze bouwen.

Hoe het is vergeleken met vijf jaar geleden? We hebben hier geen goede gegevens over en ik zou niet durven stellen dat we beter beveiligd zijn. Maar ik denk wel dat we de problemen beter voor ogen hebben. We hebben verschillende partijen, zoals Red Hat, die naar security-issues kijken en er zijn bug bounty-programma's. Je hebt gebruikers als Google waar beveiligers een hoop tests uitvoeren. Allerlei organisaties die open source gebruiken, beginnen nu iets terug te doen voor de community.

Lees ook: Pas op voor de open source lock-in!

Ik verwacht dat als dit zo doorgaat, de toekomst stukken beter wordt. Daar moeten we zelf voor blijven zorgen, want op het moment dat open source-gebruikers niet meer bijdragen, gaat de kracht ervan verloren. Dat is ook de sleutel op beveiligingsgebied: je kunt het niet simpelweg pakken en gebruiken, maar je moet actief meewerken aan de code en community, en er een deel van worden.

Op de laatste pagina: de nabije toekomst om open source te beveiligen. Krill: Wat is de volgende stap voor de beveiliging van open source software?

Bressers: De grote ontwikkeling is het concept dat we open source behandelen als deel van de keten van toeleveranciers. Dat idee begint pas net te leven, maar we zijn nog lang niet waar we moeten zijn. Ik ben bang dat er nog veel organisaties zijn die GitHub of Stack Overflow zien als een plek waar ze gratis code kunnen oppikken zonder dat ze er ooit weer naar kijken.

Maar dat werkt niet. Ik vergelijk het met de auto-industrie. Hoe betrouwbaar zou een auto zijn als een fabrikant onderdelen gebruikte die hij zomaar ergens vond zonder er kritisch naar te kijken. "Hé, dit ziet er prima uit, laten we het maar gebruiken." Dat zou heel verkeerd aflopen, maar met software doen we dat dus wel.

Lees ook: Het verdienmodel van open source zit in innovatie

Ontwikkelaars zijn dus in dat stadium van "hé, dit ziet er prima uit, laten we het maar gebruiken". We komen nu aan op een punt waarbij organisaties die open source implementeren beter leren wat dit betekent voor het eindproduct en hoe open source een rol speelt in hun eigen omgeving.