Stückliste für Open Source Software

Open-Source ist mehr als nur Linux oder Unternehmensanwendungen wie SugarCRM, Pentaho oder Open Office. Tatsächlich machen OSS-Komponenten bis zu 50 Prozent des Codes kommerzieller Software aus. Der Grund dafür ist einfach: Um das Rad nicht zweimal erfinden zu müssen, greifen Softwareentwickler gerne auf OSS- und kommerzielle Komponenten von Drittanbietern zurück. Statt also beispielsweise objekt-relationales Mapping aufwändig neu zu entwickeln, nutzt man Hibernate.

Selten unterstützt und oft unverwaltet

Neben diesen Vorteilen birgt die Nutzung von Open Source Software jedoch auch Sicherheitsrisiken. Denn im Gegensatz zu kommerziell unterstützten OSS-Betriebssystemen und Anwendungspaketen steht nur hinter jedem zehnten Open-Source-Projekt eine Community, die ähnlich umfangreichen Support leistet. Setzen Entwicklungsabteilungen also OSS-Komponenten, sind sie in Sachen Patches, Upgrades und Schwachstellenbehebung oft auf sich allein gestellt.

Hinzu kommt: In vielen Fällen werden OSS-Komponenten ohne Prüfung der Quellen und ohne ausreichende Dokumentation übernommen. In Verzeichnissen werden durchschnittlich nur 4% der Komponenten aufgeführt. Auf jede bekannte Komponente, fallen damit 24 weitere, die unerkannt und unverwaltet in der Software genutzt werden. Selbst längst bekannte Schwachstellen, für die Patches bereits zur Verfügung stehen, können so nicht behoben werden.

Rückverfolgbarkeit von Softwarecode

Spätestens seit der OpenSSL-Sicherheitslücke Heartbleed rückt das Thema Rückverfolgbarkeit von Softwareprodukten in den Fokus. Für Hersteller in der Luftfahrt, Elektronik und im Automotive-Bereich ist die genaue Dokumentation jedes einzelnen Teils schon längst mehr Pflicht als Kür. In der Softwareindustrie setzt sich eine ähnliche Transparenz über die Supply Chain hinweg nur langsam durch. Was steht in meinem Code? Wo befindet sich die Open-Source-Software? Und gibt es Schwachstellen in Verbindung mit der verwendeten Open-Source-Software? Diese Fragen schnell und zuverlässig beantworten zu können, ist für die Sicherheit von Softwareanwendungen unverzichtbar sind – zum Beispiel dann, wenn überprüft werden muss, ob eine kürzlich veröffentlichte Vulnerability ein bereits ausgeliefertes Softwareprodukt betrifft.

Ein aktuelles Verzeichnis aller Abhängigkeiten und Komponenten einer Software ist für Unternehmen eine echte Herausforderung. Ob eine Stückliste (Bill-of-Materials) erstellt werden kann, verrät eine Stichprobe des Quellcodes, wobei die angegebenen Versionsnummern auf ihre Aktualität hin überprüft werden. Die Suche nach Copyright-Informationen, Lizenzen und kopierten Dateien, die Durchsicht der Bibliotheksnamen sowie die Überprüfung auf Dateiendungen vermeintlicher Drittanbieter (z. B. .JAR, .DLL) schafft darüber hinaus einen ersten Überblick. Schnell stoßen Unternehmen auf diese Weise auf eine große Menge bisher unbekannter Drittsoftware.

Die Software-Stückliste

Soll eine Bill-of-Materials erstellt werden, führt letztendlich kein Weg an einer kompletten Inventarisierung aller derzeit genutzter Drittsoftware vorbei. Ein Verzeichnis von neuen Top-Level-Komponenten anzulegen, die in der Regel in eindeutig bezeichneten Dateien und Directories zu finden sind, ist zwar ein guter Ausgangspunkt, lässt jedoch untergeordnete Abhängigkeiten außer Acht. Tatsächlich deckt eine solche Analyse auf Top-Level in der Regel nur 10 bis 30 Prozent der zu erfassenden Stückliste ab. Teilkomponenten beispielsweise, in denen sich selbst bekannte Vulnerabilities wie Heartbleed leicht verstecken können und die als Versionen in größeren Paketen kompiliert und gelinkt werden, sind für Entwickler so gut wie nicht zu erkennen.

Aufschlussreicher ist hier eine gezielte Suche nach bekannten Schwachstellen wie OpenSSL oder Struts2. Dadurch lassen sich mit hoher Wahrscheinlichkeit zahlreiche Kopien von bislang nicht bekannten Fällen in Open Source und in kommerziellen Komponenten finden – sowohl in Binärprogrammen als auch in Quelldateien. Schließlich sollten Eigentümer der Codebasis die verbleibenden Quelldateien daraufhin überprüfen, ob es sich um „Cut and Pastes”, Refactoring oder Umstellungen von größeren Open Source Paketen handelt.

Automatisierte Software Composition Analysis

Ohne die Hilfe einer automatisierten Software Composition Analysis(SCA)-Lösung ist eine solche Überprüfung der Codebasis jedoch kaum noch möglich. Entsprechende Tools unterstützen Entwickler darüber hinaus beim Abgleich der gefundenen Komponenten mit bekannten Vulnerabilities und ordnen Prioritäten zu, um im Ernstfall auf eine Handlungsreihenfolge von Maßnahmen zurückgreifen zu können. Dazu zählen Upgrades auf die nächste Version, Patch-Prozesse, Blockieren des Zugriffs und in manchen Fällen auch das vollständige Entfernen der Komponente und aller betroffener Produktfeatures. Zudem lassen sich über solche SCA-Lösungen automatisierte Benachrichtigungssysteme einrichten, die in Echtzeit neue bekannt gewordene Schwachstellen melden.

Das Erstellen einer Stückliste und die Dokumentation aller in Software verwendeter OSS- und Drittkomponenten ist kein einmaliger Vorgang. Open-Source-Management muss vielmehr als fortlaufender Prozess verstanden werden – nicht nur im Umfeld der Softwareentwickler, sondern auch auf Seiten der Unternehmensführung. Wer im Rahmen seiner OSS-Strategie sichere Anwendungen gewährleisten will, muss unternehmensweit über entsprechende Prozesse, Schulungen und Werkzeuge verfügen und klare Vorgaben bei der Nutzung von OSS durchsetzen.

OSS-Sicherheit ist Pflichtfach

Die gute Zusammenarbeit der Teams für Sicherheit, Entwicklung und IT ist ein weiterer wichtiger Baustein. Gemeinsam können diese drei Bereiche dafür sorgen, dass die Regeln für Anwendungssicherheit auch auf Open-Source-Komponenten angewandt werden und in die Sicherheitsstrategie einfließen. Dazu gehören u.a.:

• Durchführen von Prüfungen auf Codeebene und von Penetrationstests für intern entwickelten Code vor der Bereitstellung
• Durchsetzen von Audits auf Codeebene auf Seiten externer Entwicklungs- und Geschäftspartner
• Sicherstellen, dass sämtlicher Code von Dritten, der in den eigenen Softwareanwendungen zum Einsatz kommt, auf Sicherheitsschwachstellen und Updates geprüft und nachverfolgt wird
• Sicherstellen, dass intern entwickelte Anwendungen über angemessene Prüfpunkte verfügen, die gründliche Audit-Trails ermöglichen

Unternehmen etablieren darüber hinaus vermehrt Expertenteams, die sich aus verschiedenen Abteilungen wie Technik, Recht, IT und Management zusammensetzen. Ein solches Open Source Review Board (OSRB) legt Richtlinien fest, ist für konkrete Verstöße gegen Compliance und Sicherheitsbestimmungen zuständig und trägt Sorge für die Schulung der Belegschaft zum Thema Open Source.

Mit Hilfe solcher internen Prozesse und Best Practices in Kombination mit smarten SCA-Lösungen können Unternehmen automatisiert eine formelle OSS-Strategie entwickeln, mit denen sie die Vorteil von OSS im vollem Umfang nutzen können ohne ihre Anwender den Sicherheitsrisiken auszusetzen.

• Passende Whitepaper zum Thema