Software Fünf Trends der Open Source Software-Governance

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

RTI Real-Time Innovations

Sicherheitsbedenken, Compliance-Risiken und eine lange, weit verzweigte Software-Supply Chain – Open-Source-Software ist längst den Kinderschuhen entwachsen und muss zentrale Anforderungen bei der Nutzung und Verwaltung erfüllen. Das setzt vor allem DevSecOp-Teams unter Druck, verlangt aber auch nach einem ganzheitlichen Ansatz für die OS-Governance.

Geht es um die Open Source-Governance (OS-Governance) stehen Entwicklerteams häufig an vorderster Front. Sie sollen nicht nur Innovationen schnellstmöglich auf den Weg bringen, sondern auch Sicherheits- und Compliance-Probleme frühzeitig erkennen (Shift-left) und lizenzkonformen und sicheren Code schreiben. Doch diese Aufgabenverteilung ist bei der Arbeitslast auf Entwicklerseite nicht nur utopisch. Sie greift auch zu kurz.

Open Source geht alle an

Entwickler sind keine einsamen Kämpfer, die die Sicherheit und Compliance von OSS-Code verteidigen – egal wie weit sie im Entwicklungszyklus ihrer Software nach links rücken und wie früh sie mit dem Testen beginnen. DevSecOp hat viel zu diesem Mythos beigetragen. Nach diesem Ansatz übernehmen Entwicklerteams die volle Verantwortung für den Code, den sie erstellen – einschließlich Funktionalität und Tests als auch die Sicherheit, Bereitstellung und Betrieb. In der Praxis heißt das, sichere Softwareentwicklungszyklen (SDLC) gewährleisten, Bedrohungsmodelle aufstellen, Best Practices für das Codieren festlegen und Mitarbeiter entsprechend schulen.

Bildergalerie

Die Verantwortung für die OS-Governance obliegt jedoch nicht allein der Entwicklung, sondern setzt die Mitarbeit von Rechtsexperten, Produktmanagern und Sicherheitsteams voraus. Während für verantwortliche Softwareengineers die Frage nach Sicherheitslücken und dem damit verbundenen Risiko im Vordergrund steht, zerbricht sich die Rechtsabteilung den Kopf um IP-Schutz und einschneidende Änderungen in der Lizenzierung bestimmter Komponenten. Produktmanager spüren den Innovationsdruck und wollen Produkte schnellstmöglich auf den Markt bringen. In der Exportkontrolle wiederum gilt es, im Rahmen des Zertifizierungsprozess und der Verschlüsselung zwischen Open Source- und proprietären Komponenten zu unterscheiden. Und schließlich ist da noch der Kunde, der mehr und mehr Auskunft über die Zusammensetzung der gekauften Softwareprodukte verlangt.

Industriestandards legen vor

Der Wunsch nach mehr Transparenz zeigt sich auch deutlich in der Zahl an Industrieverbänden, die verpflichtende Standards im Umgang mit OS-Softwarekomponenten einführen. 2019 legte das PCI Security Standards Council eine neue Norm fest, um den elektronischen Zahlungsverkehr sicherer zu machen. Damit werden Softwareunternehmen verpflichtet, Schwachstellen in Softwareanwendungen über die gesamten Software-Lieferkette hinweg kontinuierlich zu identifizieren und zu bewerten. Die U. S. Lebensmittel- und Arzneimittelbehörde FDA legte im gleichen Jahr neue Bestimmungen vor, nach denen Hersteller als Teil des Zulassungsverfahren eine detaillierte Software-Stückliste (Cybersecurity Bill of Materials, CBOM) ihrer Medizinprodukte einreichen müssen.

Parallel dazu wächst das Angebot an Initiativen, die Unternehmen helfen sollen, die gestiegenen Anforderungen der Open Source-Compliance zu erfüllen. Das OpenChain-Projekt ist seit Dezember 2020 ISO-zertifiziert (ISO/IEC 5230:2020). In Verbindung mit ISO/IEC 27001 – dem De-facto-Standard für das Management von Sicherheit in Informationssicherheits-Managementsystemen (ISMS) – erlaubt es einen ganzheitlichen Blick auf Software-Assets. Das Standardformat SPDX (Software Package Data Exchange) der Linux Foundation steht kurz vor einer Zertifizierung.

Rückenwind gibt es auch von politischer Seite. So verabschiedete die EU-Kommission im Oktober 2020 eine neue Open-Source-Software-Strategie 2020-2023 , mit der sie ihre eigene digitale Transformation weiter in Richtung freier und offener Software ausrichten will. Die Strategie ist die dritte seit dem Jahr 2000 und soll die Kommission zu einer aktiven Teilnehmerin der Open-Source-Community machen.

Software-BOM als Business Intelligence-Tool

Inmitten dieser Initiativen etabliert sich die Software-BOM immer mehr zum Dreh- und Angelpunkt der Open Source-Compliance. Die Bereitstellung eines aktuellen Verzeichnis aller eingesetzten Komponenten sowie ihrer Abhängigkeiten wird von vielen großen Unternehmen mittlerweile beim Kauf von Softwareprodukten sogar vertraglich vorausgesetzt. Keine Software-BOM, kein Geschäft.

Dieses Vorgehen macht Schule. Im Mai 2021 erließ US-Präsident Biden eine Executive Order, mit der die Cybersicherheit von Behörden, öffentlichen Einrichtungen sowie kritischen Infrastrukturen erhöht werden soll. Das Dekret fordert ausdrücklich eine engere Zusammenarbeit mit dem privaten Sektor, um die Software Supply Chain sicherer zu machen und vor Cyberangriffen zu schützen. Softwareanbieter, die mit der US-Regierung zukünftig Geschäfte machen wollen, müssen unter anderem eine Software-BOM für jedes Produkt vorlegen – entweder direkt an den Käufer oder über eine Plattform oder Website.

Das Erstellen der Software-BOM wird noch immer als alleinige Aufgabe der Entwicklerteams angesehen. Das ändert sich jedoch in dem Maße, in dem die Stückliste auch abteilungsübergreifend genutzt wird. Statt wie früher Komponenten wie am Fließband zu erfassen, weiterzugeben und isoliert zu betrachten, setzt sich heute vermehrt ein kollaborativer Ansatz bei der Zusammenstellung durch. Damit legt die Software-BOM nicht nur an Umfang zu, sondern gewinnt auch an Detailtiefe. Die Stückliste kommt fast einem Business Intelligence-Tool gleich, das verschiedenen Stakeholdern die Möglichkeit bietet, relevante Informationen nachzuschlagen.

Zentralisierte Teams: OSPO und OSRB

Um sicherzustellen, dass Entwickler bei der OS-Governance nicht allein gelassen werden, sollten Unternehmen dezidierte Teams ernennen, sogenannte Open Source Program Office (OSPO). Vertreter aus den Bereichen Recht, Technik, Produkt und Sicherheit kommen darin zusammen, um eine ganzheitliche Open Source-Strategie zu entwickeln und zu implementieren. OSPOs arbeiten sowohl an der Definition eines Frameworks als auch an den Prozessen, um die Nutzung von OSS zu einem festen Bestandteil der Entwicklungsarbeit (Inbound-Use-Case) zu machen. Darüber hinaus stellen sie die Rahmenbedingungen, um Code innerhalb von Open-Source-Projekte in die Community einzubringen (Outbound-Use-Case). In den letzten Jahren haben sich viele OSPO-Mitglieder darüber hinaus zu wichtigen Experten für Open Source entwickelt, die über die Unternehmensgrenzen hinaus tätig sind.

Open Source Review Boards (OSRBs) sind ein weiterer guter Ansatz, um Rechts-, Entwicklungs-, Sicherheits-, IT- und Führungsteams an einen Tisch zu bringen, Richtlinien festzulegen und Leitfäden zu erstellen. Ihre Aufgabe besteht darin, die Prozesse kontinuierlich zu verfeinern, mit dem die Entwicklungsteams Open-Source-Code und anderen Code von Drittanbietern in Produkte und Projekte einbinden. Beide Instrumente verdeutlichen eine klare Abwendungen zu früheren Ad-Hoc-Prozessen und stellen klare Regeln im Umgang mit OSS auf.

(Wissens)Basis für Open Source-Governance

Definierte Prozesse für die OS-Governance sind das eine. Etwas anderes ist es, die Richtlinien und Best Practices auch in der Praxis umzusetzen. Dazu brauchen die Teams ausreichend Ressourcen, die richtigen Tools und den Zugang zu Fachwissen. Egal ob Rechtsabteilung, IT-Sicherheit, Produktmanagement oder Compliance – Mitarbeiter müssen über das Know-how verfügen, um in Sachen Compliance den Durchblick zu bewahren und schnell und effektiv handeln zu können. In vielen Unternehmen fehlt es an diesem spezifischem Open Source-Wissen, was unter anderem dem mangelhaften Angebot an höheren Bildungseinrichtungen geschuldet ist. Nach einem Bericht von Forrester Research finden sich in den 40 für ihren Informatikstudiengang bekannten US-Universitäten keine eigenständigen Kurse für OSS-Lizenzierung oder sicheres Codieren. In den Top 5 der internationalen Universitäten fehlen die Themen ebenfalls im Lehrprogramm.

Die Open Source-Wissenslücke zu schließen, bleibt Aufgabe der Unternehmen. Große Softwarenanbieter und Hersteller verpacken das Open-Source-Training oft in Standardkurse, die Basiswissen in Form von kurzen Einheiten und Tests vermitteln. Dabei werden die Kurse im Idealfall regelmäßig wiederholt, um Teams auf den neuesten Stand zu halten. Ganz im Sinne des Open Source-Gedankens arbeiten auch viele Unternehmen branchenweit zusammen, um Best Practices rund um die OS-Governance zu etablieren. Open-Source-Management-Schulungen, wie sie beispielsweise von der Linux Foundation angeboten werden, übernehmen eine wichtige Rolle.

Vereinfacht gesagt ist und bleibt es die Aufgabe von Entwickler, Software zu entwickeln. OS-Governance hilft ihnen, dieser Aufgabe ihre volle Konzentration zu schenken – ohne dabei in Sachen Sicherheit, Innovationskraft, Produktqualität oder Compliance Abstriche machen zu müssen.

* Nicole Segerer ... ist Vice President of Product Management & Marketing bei Revenera

(ID:47598112)