Wer erinnert sich noch an Heartbleed aus 2014? Ein hochkritischer Fehler in der OpenSSL-Implementation zeigte damals die Grenzen der quelloffenen Softwareentwicklung auf. OpenSSL ist der Standard für die Verschlüsselung des Web-Verkehrs im gesamten Internet. Wegen unzureichender Mittel für die EntwicklerInnen wurde ein höchstkritischer Sicherheitsfehler übersehen: Es war theoretisch für längere Zeit möglich, „sichere“ Verbindungen aufzubrechen und abzuhören.

Obwohl die offene Verfügbarkeit von Open Source-Entwicklungen ein wesentlicher Vorteil gegenüber proprietärer Software ist, sorgt diese nicht automatisch für sicheren und fehlerfreien Code. Nach Heartbleed gründeten führende Technologieunternehmen die Core Infrastructure Initiative (CII), um besonders wichtige, weltweit genutzte Standard-Bibliotheken und Anwendungen besser zu unterstützen sowie deren Sicherheit und Qualität dauerhaft zu verbessern. [1]

Vertrauen ist gut, dauernde Kontrolle besser

Damit Applikationen und Routinen sicher entwickelt werden können, muss der Programmcode regelmäßig getestet und wiederholt überprüft werden. Einfach zugängliche Tests verbessern mit automatisierten Kontrollen die Qualität und Sicherheit der Software.

Einen besonderen Aspekt stellen die Abhängigkeiten zu externen Bibliotheken und Routinen dar: Offene Datenbanken wie CVE (Common Vulnerabilities and Exposures) dokumentieren zwar bekannte Sicherheitsprobleme, jedoch sind die Schwachstellen nicht immer klar zuordenbar, wenn z.B.  Versionsbezeichnungen nicht eindeutig sind oder zwischen Versionen, Tags- und regelmäßigen Überarbeitungen, den commits, unterschieden wird.

Google Open Source Vulnerabilities Database

Googles Anfang Februar 2021 angekündigte offene Datenbank Open Source Vulnerabilities (OSV) soll Abhilfe schaffen. Über eine API (Application Programming Interface) kann automatisiert abgefragt werden, ob für spezifische Versionen von Applikationen und Bibliotheken relevante Fehler vorhanden sind. Mit Projektstart enthält die Datenbank Ergebnisse des Google Testing-Werkzeugs OSS-Fuzz, das Open-Source Software automatisiert auf Schwachstellen überprüft. Später sollen Testergebnisse anderer Quellen hinzukommen. Die Datenbank erleichtert es Entwicklern und Software-Testern sicherzugehen, dass externe Abhängigkeiten keine Fehler einbringen, die bisher leicht übersehen wurden. [2]

Bessere Speicher-Sicherheit durch Neuimplementation wichtiger Routinen

Google widmet sich ab Mitte Februar 2021 zudem Schwachstellen, die durch Fehler im Speichermanagement wichtiger Open-Source Projekten ausgelöst werden. Laut einer Studie von Microsoft sollen über zwei Drittel der sicherheitsrelevanten Probleme ihren Ursprung in diesem Bereich haben. [3]

In Zusammenarbeit mit der Internet Security Research Group (ISRG) sollen besonders relevante Programme und Bibliotheken in robusteren Sprachen neu implementiert werden, um Schwachstellen durch unsichere Programmiersprachen auszumerzen. Als Beispiel wird eine Verschlüsselungsroutine im verbreiteten Apache-Webserver angeführt, die nun neu in der optimierten Programmiersprache „RUST“ umgesetzt wurde. [4]

Alle diese Bemühungen zeigen: Open-Source Software ist nicht automatisch sicherer als geschlossene Software. Richtig angewendet und genutzt, ermöglichen zusätzliche Maßnahmen, kritische Fehler oder Design-Schwächen zu minimieren. Google und die Open Source Security Foundation (OpenSSF) weisen darauf hin, dass die Erreichung und Verbesserung von IT-Sicherheit ein gemeinsames Ziel und Unterfangen ist und nur in Zusammenarbeit der vielen Mitwirkenden und unter Anwendung einer koordinierten Strategie umsetzbar ist.

[1] https://www.zdnet.com/article/cisco-microsoft-vmware-and-other-tech-giants-unite-behind-critical-open-source-projects/

[2] https://security.googleblog.com/2021/02/launching-osv-better-vulnerability.html/

[3] https://github.com/Microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf/

[4] https://security.googleblog.com/2021/02/mitigating-memory-safety-issues-in-open.html/