ISO/IEC 5230 als Grundlage für sicheres Open Source Management

Jeden Tag werden mehr als 20 000 neue Open-Source-Software Komponenten released. Ein Softwareprojekt ohne den Einsatz von Open-Source-Software Komponenten ist in der Realität nicht mehr vorstellbar. Doch mit den vielen Vorteilen kommen natürlich auch Pflichten. Welche Lizenz gilt für welchen Code? Was muss ich mitliefern? Welche Risiken gehe ich ein? Wenn Unternehmen Open Source professionell einsetzen, brauchen sie klare, wiederholbare Prozesse. Genau hier setzt die ISO/IEC 5230 an.

Es ist der weltweit erste offizielle Standard für Open-Source-Compliance-Programme. Dieser Blogartikel gibt einen Überblick über die ISO/IEC 5230 und zeigt, welche Bestandteile gewährleistet sein müssen.

Was ist ISO/IEC 5230?

Die Norm ISO/IEC 5230:2020 basiert auf dem Open Chain Standard. Open Chain ist ein Projekt der Linux Foundation, die es sich zum Ziel gesetzt hat, Vertrauen in Softwarelieferketten durch standardisierte Open-Source-Compliance-Prozesse zu ermöglichen. Das Ziel ist es, den Unternehmen ein Framework an die Hand zu geben, um wiederholbare und überprüfbare Prozesse für Open-Source-Compliance zu schaffen. Die ISO 5230 stellt dafür Anforderungen an Rollen, Schulungen, Policies, Dokumentation, Prozesse und externe Kommunikation. Wie auch andere ISO Normen beschreibt die ISO 5230 nicht, welche Tools verwendet werden müssen, sondern zeigt das “Was” und “Warum”. Das bietet den Unternehmen die Flexibilität, eine passende Methode zu wählen, solange die Anforderungen erfüllt werden.

Welche Vorteile bietet ISO/IEC 5230 für ein Unternehmen

Rechtssicherheit

Eingesetzte Open-Source-Software Komponenten unterliegen unterschiedlichen Lizenzmodellen. Das können sehr unkomplizierte Lizenzen sein wie z. B. eine MIT oder eine Apache 2.0. Es gibt jedoch auch problematischere Lizenzen wie die bekannten copyleft-Lizenzen wie z. B. eine GPL3.0. Die ISO/IEC 5230 verlangt, dass es einen wiederholbaren Prozess zur Identifikation, Prüfung und Dokumentation der Lizenzen und den damit einhergehenden Lizenzverpflichtungen gibt. Mit der Erfüllung dieser Anforderungen schaffen Unternehmen die Grundlage, um Open-Source-Software Komponenten rechtssicher verwenden zu können.

Vertrauen in die Software Lieferkette

Das Thema Software Supply Chain Security hat in den letzten Jahren deutlich an Fahrt gewonnen. Software Supply Chain Security befasst sich mit dem Schutz aller Komponenten und Prozesse, die an der Entwicklung, dem Build und der Auslieferung von Software beteiligt sind. Ziel ist es, Manipulationen, Schwachstellen oder Lizenzverstöße in Abhängigkeiten frühzeitig zu erkennen und zu verhindern. Immer mehr Kunden und Partner fordern auch vertraglich, dass eingesetzt Software sicher und compliant ist. Die ISO/IEC 5230 schafft Vertrauen zwischen Kunden und Lieferanten und dient als Aushängeschild.

Standardisierte Prozesse

Mit der Implementierung der Anforderungen, die in der ISO/IEC 5230 gefordert sind, ist es möglich, durch Rollen, Schulungen, Dokumente und Zuständigkeiten die Open-Source-Software Compliance deutlich zu verbessern. Das Lizenzmanagement wird keine Ad-hoc-Aufgabe mehr, welche nur von wenigen beherrscht werden kann. Das Ziel ist es, Prozesse zu etablieren, welche wiederholbar und skalierbar sind.

Geringe Einstiegshürden

Die ISO/IEC 5230 kann kostenfrei von der offiziellen OpenChain Website bezogen werden. Der Standard ist sehr klar strukturiert und gibt Mindestanforderungen bewährte Vorgehensweisen vor. Unternehmen können Schritt für Schritt ein Open-Source-Compliance Programm etablieren, ohne sofort massive Ressourcen einzuplanen. Es ist ebenfalls möglich eine Selbstzertifizierung durchzuführen. Wer jedoch einen externen Blick haben möchte, kann die ISO/IEC 5230 sich durch einen externen Auditor bestätigen lassen. Das hat vor allem den Vorteil, dass die Anforderungen unabhängig geprüft worden sind.

Wettbewerbsvorteil

Die Einhaltung der ISO/IEC stärkt die Wettbewerbsfähigkeit des jeweiligen Unternehmens in vieler Hinsicht. Zum Einen kann bei Ausschreibungen oder bei Kundenprojekten im Allgemeinen eine Zertifizierung einen entschiedenen Vorteil haben. Es bescheinigt einen strukturierten Umgang mit Open-Source-Software Komponenten. Zum anderen reduziert ein standardisierter Umgang mit Lizenzen rechtliche Risiken und beschleunigt Entwicklungs- und Freigabeprozesse. Das ermöglicht eine schnellere Time-To-Market und geringere Kosten.

Wer nutzt ISO/IEC 5230 bereits?

Die ISO/IEC 5230 ist zwar deutlich spezieller als andere bekannte ISO Normen wie z. B. die ISO/IEC 27001. Allerdings entwickelt so gut wie jedes Unternehmen eigene Software oder lässt diese im Auftrag entwickeln. Daher verwundert es nicht, dass der Standard bereits von großen Unternehmen angewandt wurde. Anbei ein Auszug der aktuellen Liste:

• Bosch, Siemens, Volkswagen, Toyota
• Google, Microsoft, Meta (Facebook)
• Sony, Adobe, SAP, Alibaba
• Zahlreiche mittelständische Hidden Champions im Maschinen- und Gerätebau

Die wichtigsten Anforderungen im Überblick

Wie bereits erwähnt bietet die ISO/IEC 5230 eine komplette Anforderungsliste, mit der ein Open-Source-Compliance Programm intensiv umgesetzt werden kann. Es ist jedoch auch möglich, erstmal mit einigen Anforderungen zu beginnen und diese sukzessive weiter auszubauen. Die Norm gibt es ebenfalls vor, bestimmte Anforderungen nicht umzusetzen, sollte dies nicht im Unternehmen relevant sein. Anbei eine Liste der wichtigsten Anforderungen aus der ISO/IEC 5230. SecuraPoint hilft bei der Umsetzung aller dieser Anforderungen in deinem Unternehmen.

Open-Source-Policy

Die Grundlage eines erfolgreichen Open-Source-Compliance Programms ist eine schriftliche Open-Source-Policy. Diese Policy sollte die folgenden Inhalte abdecken:

• Nutzung, Bewertung, Freigabe, Veröffentlichung von Open Source
• Ziele und Einklang mit den Unternehmenszielen
• Eskalation und rechtliche Bewertung

Wie bei anderen Richtlinien auch muss diese Policy intern zugänglich und bekannt sein. Außerdem sollte sie regelmäßig aktualisiert werden und im Rahmen der kontinuierlichen Verbesserung angepasst werden. Im Rahmen der Entwicklung der Open-Source-Policy sollte auch der Scope geklärt werden. Es ist unwahrscheinlich, dass ein Open-Source-Compliance Programm von Anfang an im gesamten Unternehmen ausgerollt wird. In der Praxis beginnt man mit einem Team, Abteilung oder Produkt und vergrößert den Scope dann Schritt für Schritt.

Kompetenz und Awareness

Um die Ziele zu erreichen und die Open-Source-Policy mit Leben zu füllen, braucht man vor allem Menschen und deren notwendige Kompetenz. Daher ist es wichtig, zunächst die notwendigen Rollen (z. B. Legal, Softwareengineering, Product Owner, Projektmanagement) und deren Anforderungsprofil zu kennen und zu dokumentieren. Basierend auf dem Anforderungsprofil ist ein Schulungskonzept zu definieren, also konkret welches Wissen brauchen die einzelnen Rollen und wie kann das Wissen erlangt werden. Hier sind interne Schulungen sowie externe Schulungen möglich. Wichtig dabei ist, dass nicht nur das Legalteam und die Softwareentwickler eine Schulung erhalten. Alle Beteiligten sollten für das Thema sensibilisiert werden.

Lizenzprüfung und -dokumentation

Das Herzstück eines Open-Source-Compliance Programs ist die Lizenzüberprüfung. Damit ist vor allem gemeint, dass ein Prozess definiert und gelebt werden muss, wie die entsprechenden Lizenzen identifiziert und bewertet werden. Das inkludiert auch eine Risikobewertung, sollten Lizenzen gefunden werden, welche gegen die Unternehmensvorgaben stoßen. Es sollte vorab definiert sein, welche Lizenzen für das Unternehmen akzeptabel sind und welche nicht. Weiterhin müssen die entsprechenden Rechte und Pflichten mit diesen Lizenzen ersichtlich sein und allen Beteiligten auch bewusst sein. Der Standard gibt ebenfalls an sich Use Cases zu überlegen, in welchen Situationen Open-Source Software eingesetzt wird und was hierbei mit den entsprechenden Lizenzen bedacht werden muss. Beispielsweise wenn Open-Source-Software Komponenten mit Eigenentwicklungen verlinkt sind.

Erstellung einer Stückliste (SBOM) inklusive Lizenzen

Die ISO/IEC 5230 gibt vor, dass sowohl ein Prozess existieren muss, wie die SBOM erstellt, überprüft, freigegeben und archiviert wird. Die SBOM muss alle eingesetzten open-source Komponenten mit ihren entsprechenden Lizenzen beinhalten. Wichtig hierbei ist es, dass es einen dokumentierten Prozess gibt, welcher wiederholbar und nachvollziehbar ist. Solch ein Prozess ist am besten Tool-unterstützend zu etablieren. Der Standard gibt zudem vor das SPDX Format für die SBOM zu verwenden. Genaue Inhalte werden vom Standard nicht beschrieben, es kann jedoch davon ausgegangen werden, dass die eindeutige Auflistung der Komponenten als auch die Zuordnung der Lizenzen mit SPDX-Identifiziert verlangt wird. Es ist weiterhin sinnvoll die Abhängigkeiten und ggf. die Verlinkung (dynamisch oder statisch) mit anzugeben.

Compliance-Artefakte erstellen und archivieren

Je nach Open-Source-Software Komponente und entsprechender Lizenz müssen Artefakte wie der Softwarecode bereitgestellt werden. Weiterhin müssen häufig Lizenztexte, Acknowledgements, Copyright-Hinweise mit der Software ausgeliefert werden. Daher muss ein Prozess existieren, wie die Artefakte erstellt und mit der Software ausgeliefert werden. Diese Artefakte müssen entsprechend archiviert werden.

Öffentliche Anfragen und Kommunikation

Der Standard besagt, dass eine öffentliche E-Mail-Adresse oder Kontaktformular für OSS-Compliance-Anfragen existieren muss. Weiterhin muss ein Prozess existieren, wie mit den Anfragen umgegangen wird, damit diese nicht in Nirwana versanden.

Beiträge an Open-Source-Projekte

Sollten Mitarbeiter selbst an Open-Source Projekten teilhaben und einen Beitrag während ihrer Arbeitszeit leisten, muss es dafür ebenfalls eine Contribution Policy inklusive Genehmigungsprozesse geben.

Wie funktioniert die Zertifizierung?

Aktuell gibt es zwei Möglichkeiten, sich basierend auf der ISO/IEC 5230 zertifizieren zu lassen. Es gibt die Selbstzertifizierung, welche kostenfrei auf der Open Chain Website angeboten wird. Zudem bieten auch Partner wie z. B. der TÜV Süd oder PWC externe Prüfungen an. Diese sind kostenpflichtig und werden durch einen externen Auditor durchgeführt. Das hat den Vorteil von einer höheren Glaubwürdigkeit und bietet die Option einen externen Blick von Außen zu bekommen.

Fazit

Der Einsatz von Open-Source-Software Komponenten bietet sehr viele Vorteile, ist allerdings nicht kostenlos. Es verlangt Verantwortung und die Einhaltung von Rechten und Pflichten. Die ISO/IEC 5230 hilft dabei, diese Verantwortung strukturiert zu übernehmen. Sie ist der Standard für Unternehmen, die Open Source strukturiert und rechtssicher nutzen wollen. Sie ist flexibel und lässt sich für jedes Unternehmen entsprechend anpassen.