Risiken bei Open-Source-Software: Warum eine Bill-of-Materials sinnvoll ist

Wenn wir Flugzeuge so bauen wie wir Software entwickeln, würde kaum jemand noch fliegen. Software ist nie zu 100% sicher. Grund dafür ist auch die unkontrollierte und nicht verwaltete Nutzung von Open Source-Software (OSS). Darum ist auch bei Software eine gut geführte Bill of Materials (BOM) essentiell.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Flexera Software GmbH

Softwareentwickler greifen bei Programmierroutinen gerne auf OSS- und kommerzielle Komponenten von Drittanbietern zurück, um sich ganz auf den innovativen, komplexen und spannenden Teil ihrer Arbeit zu konzentrieren. Tatsächlich machen OSS-Komponenten bis zu 50 Prozent des Codes kommerzieller Software aus. Doch wie in jeder anderen Software, finden sich auch dort Fehler.

In einer softwaregesteuerten Welt entwickeln sich diese Fehler, z. B. bekannte, aber nicht gepatchte Vulnerabilities, schnell zu einem Problem – insbesondere wenn es sich um Software handelt, die für die öffentliche Grundversorgung oder sicherheitskritische Anwendungen genutzt wird. Die Menge an Malware, die Schwachstellen in Software von Drittanbietern ausnutzt, steigt kontinuierlich. Eine geeignete Angriffsfläche finden Schadprogramme auch in bereits ausgelieferten Produkten, die nach wie vor Sicherheitslücken aufweisen. So nutzte Bashlite IoT ursprünglich die Shellshock/Bash Schwachstelle, um IoT-Systeme zu infizieren und sich weiter zu verbreiten. Andere Angriffe zielten auf kommerzielle Komponenten in White-Label-Überwachungskameras, deren eingebetteten Benutzernamen und Passwörter bekannt waren.

Bildergalerie

Bill of Materials: Stückliste und Verzeichnis aller Abhängigkeiten zwingend erforderlich

Diese und ähnliche Vorfälle haben das Risikobewusstsein geschärft. Verstärkt sucht die Softwareindustrie nach neuen Lösungsansätzen für die Softwareentwicklung und -wartung und orientiert sich dabei auch an Best Practices anderer Branchen. In der Luftfahrt, in der Elektronik oder auch im Bereich Automotive gehören die Bestandsverfolgung und die Rückverfolgbarkeit der in einer Stückliste aufgeführten Teile zu den zentralen Aufgaben. Hersteller können die Leistungsfähigkeit sowie die Toleranzen der von ihnen gefertigten Produkte besser prüfen und gleichzeitig den Ursachen von Fehlern und Ausfällen auf den Grund gehen. Bricht ein Bolzen, lassen sich über die Überwachungs-/Kontrollkette Herkunft, Bestellvorgang, Lieferant und sogar die Bedingungen am Fertigungsort systematisch ermitteln. Eine ähnlich hohe Transparenz fehlt in der Software Supply Chain.

Vor ein paar Jahren war eine Aufstellung zu den genutzten Softwarekomponenten bis auf wenige Ausnahmen kaum zu finden. Das änderte sich schlagartig mit Heartbleed. Die OpenSSL-Sicherheitslücke gilt nach wie vor als eindrücklicher Beweis dafür, wie wichtig ein aktuelles Verzeichnis aller Abhängigkeiten und eine Software-Stückliste (auch bekannt als Bill-of-Materials) der eingesetzten Komponenten sind. Zwar finden sich heute häufiger Software-Stücklisten, doch der Anteil an bekannten und gelisteten Komponenten ist auf Grund der rasant wachsenden Menge an Komponenten zurückgegangen. Laut Untersuchungen beträgt der Anteil der in Verzeichnissen geführten Komponenten durchschnittlich nur 4 Prozent. Auf jede bekannte Komponente, fallen damit 24 weitere Komponenten, die unerkannt und unverwaltet in der Software verwendet und an Kunden ausgeliefert werden. Zudem werden Komponenten mit längst bekannten Schwachstellen weiter genutzt, so dass die Sicherheitslücken selbst in neuen Produkten weiterhin bestehen.

Die mangelnde Dokumentation und Überprüfung von Open Source hat unterschiedliche Ursachen. Häufig werden dazu nötige komplexe Prozesse aus Effizienz-, Zeit- oder Kostengründen schlichtweg gestrichen. Das erhöht nicht nur das Sicherheitsrisiko bei der Nutzung von Open Source, sondern gefährdet auch die Einhaltung von Open Source-Lizenzvorgaben. Unternehmen liefern nach wie vor Hunderte bis Tausende von Softwarekomponenten von Drittanbietern an ihre Kunden ohne diese genau zu kennen, und ohne Verfahren festzulegen, die eine regelmäßige Überprüfung gewährleisten. Dies gilt insbesondere für das IoT, wo Geräte häufig mit eingebetteten Betriebssystemen und Softwarekomponenten bereitgestellt werden. In vielen Fällen sind diese Betriebssysteme Open Source und unterliegen der General Public License (GPL). Danach sind Entwicklerteams bei der Nutzung verpflichtet, den Quellcode aller Produkte und Komponenten, in denen sie GPL-lizenzierte, unveränderte oder veränderte Komponenten verwenden, ebenfalls offenzulegen. In der Praxis geschieht dies jedoch leider nur selten.

Erste Schritte zur Software-BOM

Soll eine Bill-of-Materials erstellt werden, beginnen viele Entwicklerteams mit einem Verzeichnis von neuen Top-Level-Komponenten, die in der Regel in eindeutig bezeichneten Dateien und Directories zu finden sind. Dies ist ein guter Ausgangspunkt, um neue Komponenten zu erfassen, bildet aber nur die Spitze des Eisbergs, da untergeordnete Abhängigkeiten außer Acht gelassen werden. Eine solche Analyse auf Top-Level deckt in der Regel nur 10 bis 30 Prozent der tatsächlich zu erfassenden Stückliste ab. Letztendlich führt kein Weg an einer kompletten Inventarisierung aller derzeit genutzter Drittsoftware vorbei.

Zu einer vollständigen Bestandsaufnahme zählen deshalb auch Teilkomponenten, die deutlich schwerer zu ermitteln sind und in denen sich selbst bekannte Vulnerabilities wie Heartbleed leicht verstecken können. Versionen dieser Komponenten, die in größeren Paketen kompiliert und gelinkt werden, sind für Entwickler, die ein vollständiges Verzeichnis der Abhängigkeiten erstellen wollen, so gut wie nicht zu erkennen. Darüber hinaus empfiehlt sich die Überprüfung der Codebasis der verbleibenden Quelldateien, um festzustellen, ob Open-Source-Komponenten durch Cut and Paste, Refactoring oder Umstellungen von größeren Paketen in das Produkt gelangt sind. Doch auch hier ist eine Überprüfung der Codebasis ohne die Hilfe einer automatisierte Software Composition Analysis-Lösungen kaum noch möglich.

Aufschlussreich kann zudem die gezielte Suche nach bekannten Schwachstellen wie OpenSSL oder Struts2 sein. Dadurch lassen sich mit hoher Wahrscheinlichkeit zahlreiche Kopien von bislang nicht bekannten Fällen in Open Source und in kommerziellen Komponenten finden.

(ID:45272537)