Suchen

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

Seite: 2/2

Firmen zum Thema

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.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 45272537)