23 juli 2008

Bedrijven dienen er goed over na te denken voordat ze open source oplossingen adopteren vanwege de voortdurende beveiloigingsproblemen, zo stelt een rapport van de beveiligingsfirma Fortify. Hoewel er op het zeer negatieve taalgebruik in het rapport en de ongeveinsde reclame voor de eigen producten nogal wat af te dingen is, is de kern van de boodschap wel de moeite van het vermelden waard. Het rapport wijst namelijk op een al langer bestaand probleem, dat voor bedrijven risico's in kan houden. Het rapport kwam voort uit het werk dat Fortify verrichte in het Java Open Review Project, waarin het de open source Java projecten aan een volledige beveiligingsaudit onderwierp. Fortify's zorgen komen niet zo zeer voort uit de bugs die het in kaart bracht als wel van het feit dat het 'was difficult to identify anyone responsible for fixing them; many persisted for several iterations of the software', zo stelt een woordvoerder van het bedrijf. De aanvankelijke analyse van Fortify van de broncode werd uitgevoerd met behulp van eigen commerciele tools. 11 open source projecten werden geaudit, waaronder de Derby database en de JBoss en Tomcat applicatieservers. Broncode die kwetsbaar is voor beveiligingsproblemen, zoals databasequeries en de code voor de dynamische user interface, werden handmatig geanalyseerd. Alle kwetsbaarheden werden bevestigd door een handmatig onderzoek van de code.

Het aantal problemen was nogal verschillend. Hibernate had slechts 23 problemen in totaal, minder dan eenderde per 1000 regels code. Tomcat daarentegen had meerdere honderden problemen, bijna zes voor idere 1000 regels code. De Hipergate webservice had zoveel problemen dat het niet in dezelfde grafiek als de andere applicaties kon worden geplaatst. Het echte probleem kwam toen Fortify probeerde de resultaten van de audits door te geven aan de ontwikkelaars. Alleen Tomcat had een specifiek e-mailadres voor beveiligingsproblemen; de meeste projecten gaven geen indicatie dat beveiliging een onderdeel is van de doelen van het project en slechts enkele projecten hadden toegang tot beveiligingsspecialisten. De zaken werden zo goed als mogelijk was gerapporteerd, maar de meeste van deze meldingen zijn (nog) niet behandeld. Van de zes projecten die een of meerdere updates of upgrades kenden gedurende de onderzoeksperiode, hadden er vijf meer kwetsbaarheden aan het eind van die periode dan aan het begin. Het is wel nodig op te merken dat deze mate van kwetsbaarheden specifiek kan zijn voor Java-programmatuur, want Coverity's analyse van een breder scala aan open source producten liet bij de meeste van die producten vooruitgang zien. Op zich zijn de resultaten niet verrassend. Slechts weinig projecten hebben de mogelijkheden om een beveiligingsspecialist in te huren, zoals Mozilla. Ze moeten vertrouwen op vrijwilligers om de kwetsbaarheden in de code te vervangen door betrouwbare code. De beschikbaarheid van de code heeft echter een groot voordeel: bedrijven kunnen de problemen identificeren, zelf oplossen of de gevolgen van het probleem verminderen. Proprietary software heeft dit voordeel niet. De boodschap van het rapport is dat bedrijven open source software niet moeten toepassen met het idee dat aangezien de code beschikbaar is en door vele individuen is samengesteld die inherent veilig is. De software moet met voorzichtigheid wordne benaderd en er dienen software-audits te worden uitgevoerd vooraleer de implementatie uit te voeren. Een advies waar niets op af te dingen valt. Aan de open source producten wordt geadviseerd om de verantwoordelijkheid neer te leggen bij iemand met relevante expertise en er voor te zorgen dat beveiliging onderdeel wordt van het standaard ontwikkelproces. Een nuttig rapport, met een aantal zinvolle tips.