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

Autor / Redakteur: Jeff Luszcz * / Sebastian Gerstl

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.

Firmen zum Thema

Flexera Report “Open Source Risk – Fact or Fiction?” (Oktober 2017).
Flexera Report “Open Source Risk – Fact or Fiction?” (Oktober 2017).
(Bild: Flexera)

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.

So gelangen Open-Source-Komponenten in die Software

Die von Jahr zu Jahr wachsende Zahl der Komponenten, die in einem typischen Softwareprodukt verwendet werden, macht das Erstellen einer solchen Stückliste nicht gerade leichter. Effizienter ist es daher, Prozesse zu implementieren, die automatisch alle Dateien und Ressourcen überprüfen, die in allen Produkten verwendet werden – egal ob diese in der Entwicklung stecken oder bereits beim Kunden zum Einsatz kommen.

Durchschnittlich enthält eine Unternehmensanwendung oder ein IoT-Gerät mehr als 500 Komponenten. Komponenten von Drittanbietern können dabei auf unterschiedliche Weise in Anwendungen gelangen. Viele werden von den Entwicklern gezielt ausgewählt. Andere wiederum werden über einen Repositorymanager wie z. B. Maven, Yacto oder NuGet eingebunden. Diese Top-Level-Komponenten sowie ihre Abhängigkeiten werden am häufigsten von Teams überwacht und gemanagt.

Bildergalerie

Zu den zweithäufigsten Komponenten zählen monolithische Verzeichnisbäume, die von den Entwicklerteams oft manuell angelegt werden. Auf diese Weise werden typischerweise Libraries wie OpenSSL oder zlib zunächst heruntergeladen und in die Codebasis kopiert. Entsprechende Komponenten lassen sich entweder durch visuelle Überprüfung, per „grep“-Kommando oder über die Suche nach Lizenzdateien, Readme-Dateien, bekannten Dateinamen oder eingebettete Zeichenfolgen finden. Darüber hinaus gelangen Komponenten auch in Form von Quellcode aus Foren und Tutorials in die Software.

Alle diese Komponenten müssen identifiziert, dokumentiert, überwacht und auf Schwachstellen sowie Compliance-Verstöße untersucht werden. Bei Komponenten in Binärformat gilt es zudem zu überprüfen, ob der verwendete Quellcode verfügbar ist.

Lücken in der Software Supply Chain schließen

Grundsätzlich gilt es, bei der Nutzung von OSS-Komponenten sowie von Komponenten der Drittanbieter kritischer zu sein. Zeitcodes (TC) werden oft ohne viele Fragen von externen Quellen übernommen und in die Codebasis kopiert. Hier sollten Entwickler ähnlich hohe Erwartungen an die Qualität stellen, wie bei ihrem selbst geschriebenen Code. Eine einfache Grundregel könnte lauten: Fehlt eine Stückliste, wird dies wie ein Software-Fehler gehandhabt.

Es gibt eine Reihe von Möglichkeiten, um einen verantwortungsvollen Umgang mit OSS innerhalb des IT-Procurement im Unternehmen sicherzustellen. Dazu gehört eine einheitliche Vertragssprache, die die Offenlegung von Komponenten von Drittanbietern sowie den Prozess der Benachrichtigung über Patches oder Upgrades im Zusammenhang mit Schwachstellen von Drittanbietern bis ins Detail regelt und klar formuliert. Hilfreich ist zudem ein offener und konstruktiver Dialog mit externen Softwareanbietern, um Fragen zu in der Analyse identifizierten Komponenten, Schwachstellen oder Lizenzen zu klären und auf die Bedeutung von Software-Stücklisten hinzuweisen. Dabei gilt es abzuwägen, ob eine Zusammenarbeit mit Lieferanten, die nicht die Erwartungen an eine transparenten Software Supply Chain erfüllen, noch tragbar ist. „Es war sicher, als wir es ausgeliefert haben“ hat als goldene Regel ausgedient – ganz besonders für Code in IoT-Geräte, die dauerhaft mit dem Netzwerk verbunden sind.

Softwareentwickler können nur dann die Sicherheit ihres Codes garantieren, wenn die Nutzung von Open Source Komponenten und Komponenten von Drittanbietern klar geregelt ist. Dabei sollten die entsprechenden Richtlinien und Prozesse jedoch immer auch auf die Entscheidungen und Bedürfnisse der Entwickler sowie auf die zu entwickelnden Produkte abgestimmt sein. Hier liegt es auch an der Unternehmensführung, die grundsätzlichen Bestimmungen auf sämtlichen Unternehmensebenen zu kommunizieren und durchzusetzen. Nur so lassen sich Sicherheits- und Compliance-Lücken in der Software Supply Chain langfristig schließen.

Der Autor

Jeff Luszcz, Vice President of Product Management bei Flexera
Jeff Luszcz, Vice President of Product Management bei Flexera
(Bild: Flexera)

*Jeff Luszcz ist Vice President of Product Management bei Flexera und leitet das Professional Services Team, das für Open Source Compliance und Security Audits verantwortlich ist. Zuvor war er Gründer und CTO von Palamida, einem führenden Anbieter von Open Source Discovery und Vulnerability Management Tools. Er unterstützt seit über zehn Jahren Softwarefirmen, Open Source optimal zu nutzen und gleichzeitig ihre Lizenzverpflichtungen zu erfüllen und Sicherheitsfragen im Auge zu behalten.

(ID:45272537)