Open Source wird dank steigender Code-Qualität immer sicherer.
Open Source Initiative (OSI)
Die kürzlich bekannt gewordene Sicherheitslücke in der Verschlüsselungstechnik OpenSSL wirft in den IT-Abteilungen Fragen nach der Sicherheit von Open Source auf. Trotzdem: Die Code-Qualität von Open Source wird immer besser.
Open Source ist von PCs und Servern im Unternehmen nicht mehr wegzudenken. In den Rechenzentren und Entwicklungsabteilungen arbeiten heute allerorts Linux, Apache-Server, PostgreSQL-Datenbanken, Eclipse oder Hadoop. Dass die Heartbleed-Sicherheitslücke in der freien Verschlüsselungs-Bibliothek OpenSSL gefunden wurde, die als Quasi-Standard in vielen Open-Source-Programmen und auch in kommerzieller Software verwendet wird, schürt Sicherheitsbedenken in Unternehmen.
Die gute Nachricht ist, dass Open Source in den letzten Jahren deutlich an Qualität zugelegt hat und damit auch immer sicherer geworden ist. Das liegt zum einen daran, dass die Open-Source-Gemeinde besser organisiert sind. Die Projekte agieren schnell, wenn sicherheitsrelevante Probleme gemeldet werden. Die Linux-Entwickler haben zum Beispiel ihre Bemühungen verstärkt, neu gemeldete Fehler deutlich schneller zu fixen, solange der geschriebene Code noch frisch im Gedächtnis der Programmierer ist. Im Schnitt werden Lücken in dem Open-Source-Betriebssystem nun innerhalb von sechs Tagen mit einem Patch geschlossen, statt erst nach über 120 Tagen, wie es noch Anfang 2013 üblich war.
C/C++-Programme: Weniger Fehler in Open Source
In seiner aktuellen Untersuchung hat Sicherheitsspezialist Coverity nicht nur 740 quelloffene C/C++-Projekte mit insgesamt 250 Millionen Zeilen Code untersucht, sondern zieht auch 500 Millionen Codezeilen aus proprietärer Software zum Vergleich heran. Dabei schneidet Open Source auf C/C++-Basis mit einer geringeren Fehlerdichte sogar besser ab als die proprietären Lösungen in diesem Bereich. Die proprietären Programme, die in den Vergleich einfließen, bleiben dabei anonym.
Bei den ebenfalls untersuchten Java-Projekten, über Hundert an der Zahl, wurden mehr Fehler als bei den C/C++-Projekten gefunden. Dennoch fällt die Rate der Fehlerkorrekturen niedriger aus. Ein Grund dürfte laut dem Coverity Scan Report sein, dass sich Java-Entwickler häufig auf eingebaute Funktionen wie die Garbage Collection verlassen, die Memory Leaks durch das Aufräumen des Speichers verhindern soll. Luft nach oben gibt es also noch.