Wie ISO 27001 und Open Source Standards gemeinsam Sicherheit und Compliance stärken
- Sarah Berger
- ISO 27001
- 8. Mai 2025
Inhaltsverzeichnis
Open Source Software ist längst kein Nischenthema mehr, sondern fundamentaler Bestandteil moderner IT-Architekturen. Kaum ein Softwareprojekt wird heute ohne den Einsatz von Open Source Software durchgeführt. Gleichzeitig steigt der regulatorische Druck auf Unternehmen, ihre Informationssicherheit systematisch und nachvollziehbar zu managen. Wie beispielsweise durch ein zertifiziertes Informationssicherheits-Managementsystem (ISMS) nach der ISO/IEC 27001.
Bisher wurden die Themenbereiche Informationssicherheit und Open Source Compliance getrennt betrachtet. Während das Thema Informationssicherheit oft in den entsprechenden IT-Teams verankert war, war Open Source Compliance eher ein Thema für die Legal-Teams. Diese beiden Themenbereiche wachsen jedoch zunehmend zusammen.
Mit der ISO/IEC 5230 und der neueren ISO/IEC 18974, die speziell auf Sicherheitsaspekte im Umgang mit Open Source eingeht, existieren international anerkannte Standards, die strukturierte Prozesse für den sicheren Einsatz von Open Source Software fordern und entsprechende Anforderungen sowie Checklisten an die Hand geben. Doch wie lassen sich diese Anforderungen mit einem ISMS nach ISO 27001 verbinden? Welche Kontrollziele aus dem Anhang A der ISO 27001 werden durch Open Source Compliance und Security direkt oder indirekt adressiert?
Dieser Artikel beleuchtet die Schnittmengen zwischen diesen Normen und zeigt auf, wie Unternehmen Synergien nutzen können, um sowohl ihre Sicherheits- als auch ihre Compliance-Ziele effizienter zu erreichen und damit auch konform zu sein gegenüber den entsprechenden Normen. Gleichzeitig gilt dies als Vorbereitung und auch besser auf neue gesetzliche Anforderungen wie den Cyber Resilience Act (CRA) gewappnet zu sein.
Überblick über die Normen
ISO/IEC 27001 – Informationssicherheitsmanagement
Die ISO/IEC 27001 definiert Anforderungen an die Einführung, den Betrieb und die kontinuierliche Verbesserung eines ISMS. Ihr Ziel ist es, Risiken für Vertraulichkeit, Integrität und Verfügbarkeit von Informationen systematisch zu identifizieren und zu behandeln. Ein zentraler Bestandteil ist der Anhang A, der 93 Sicherheitsmaßnahmen (Controls) enthält, die im Rahmen einer Risikoanalyse berücksichtigt werden sollten. Der Maßnahmenkatalog deckt ein sehr breites Feld ab, von Zugriffskontrollen über Lieferantenmanagement bis zu Schwachstellenmanagement. In der ISO/IEC 27002 werden diese Maßnahmen weiter detailliert, diese Norm (ISO 27002) ist jedoch hinweisend.
ISO/IEC 5230 – OpenChain Specification
Die ISO/IEC 5230 ist der erste internationale Standard für Open Source Compliance Management. Sie zielt darauf ab, sicherzustellen, dass Organisationen OSS-Komponenten rechtssicher nutzen können. Im Fokus stehen dokumentierte Prozesse zur Lizenzkonformität, zum Umgang mit Open Source Policies, zur Schulung relevanter Stakeholder sowie zur Nachvollziehbarkeit eingesetzter Software.
ISO/IEC 18974 – Open Source Security Assurance
Ergänzend zur ISO 5230 legt ISO/IEC 18974 Sicherheitsanforderungen für den Umgang mit Open Source fest. Im Mittelpunkt stehen Prozesse zur Verwaltung von Schwachstellen, die Erstellung und Pflege von Software Bill of Materials (SBOMs) sowie Maßnahmen zur Sicherheitsüberprüfung von Drittanbieter-Komponenten. Die Norm ist insbesondere relevant, wenn Open Source Bestandteil von Produkten oder Plattformen ist, die Sicherheitszertifizierungen erfordern.
Gemeinsame Anforderungen und Überschneidungen
In der folgenden Tabelle sind typische Überschneidungen zwischen den drei Normen dargestellt:
| Thema | ISO 27001 (Anhang A) | ISO 5230 | ISO 18974 | |
|---|---|---|---|---|
| Rollen & Verantwortlichkeiten | A.5.2 - Informationssicherheitsrollen und Verantwortlichkeiten | Rollen und deren entsprechende Pflichten müssen identifiziert, dokumentiert und mit Leben gefüllt werden | Rollen und deren entsprechende Pflichten müssen identifiziert, dokumentiert und mit Leben gefüllt werden | |
| Leitlinie und Unterstützung von der Führungsebene | A.5.4 – Verantwortlichkeit der Leitung | Die Open Source Policy muss zwar nicht von der Führungsebene unterzeichnet werden, jedoch braucht es ein starkes Signal, dass Open Source Policy Chefsache ist | ||
| Lieferkettensicherheit | A.5.20 – Behandlung von Informationssicherheit in Lieferentenvereinbarungen A.8.30 - Ausgegliederte Entwicklung | In den Lieferentenvereinbarungen muss Open Source Compliance sichergestellt werden. Der Lieferant muss die Prüfungen übernehmen und die Lizenzvereinbarungen sicherstellen. | In den Lieferentenvereinbarungen muss Open Source Sicherheit sichergestellt werden. Der Lieferant muss die Software scannen und etwaige Schwachstellen beseitigen. | |
| Sicherheitsvorfälle | A.5.24 - Planung und Vorbereitung der Handhabung von Informationssicherheitsvorfällen | Sollte es zu neuen Schwachstellen in verbauten Open Source Komponenten kommen, muss es einen Prozess geben, wie diese behandelt werden. | ||
| Eigentumsrechte und vertragliche Anforderungen | A.5.31 Juristische, gesetzliche, regulatorische und vertragliche Anforderungen A.5.32 Geistige Eigentumsrechte | Jede Open Source Komponente hat eine entsprechende Lizenz, was einem Vertrag gleicht. Gleichzeitig muss das entsprechende Copyright der Komponente beachtet werden. | ||
| Schwachstellenmanagement und Softwareentwicklungsprozesse | A.8.8 – Handhabung von technischen Schwachstellen A.8.25 – Lebenszyklus einer sicheren Entwicklung A.8.27 - Sichere Systemarchitektur und Entwicklungsgrundsätze A.8.28 - Sichere Codierung A.8.29 Sicherheitsüberprüfungen bei Entwicklung und Abnahme | Das Herzstück der ISO 18974. Es müssen Prozesse in der Softwareentwicklung existieren, um Schwachstellen zu erkennen und SBOMs zu erstellen. Jedoch müssen diese Komponenten auch nach Release beobachtet werden. | ||
| Software Asset Management | A.5.9 – Inventar der Informationen und anderer damit verbundener Werte | SBOM | SBOM | |
| Awareness & Training | A.6.3 – Informationssicherheitsbewusstsein sowie Ausbildung und Schulung | OSS Compliance Awareness | Security Awareness zu OSS |
Diese Überschneidungen zeigen, dass viele der in ISO 5230 und 18974 geforderten Aktivitäten gleichzeitig auch Anforderungen oder Maßnahmen nach ISO 27001 adressieren. Insbesondere im Kontext von Lieferkettensicherheit, Schwachstellenmanagement und Softwareentwicklungsprozesse.
Integration in bestehende Managementsysteme
Ein großer Vorteil für Unternehmen mit einem bestehenden ISMS nach ISO 27001 ist, dass viele Prozesse und Rollen bereits etabliert sind wie beispielsweise im Bereich Risikoanalyse, Schulung oder Lieferentenmanagement. Weiterhin legt die ISO 27001 bereits großen Wert auf die notwendigen Prozesse innerhalb der Softwareentwicklung. Diese können mit wenig zusätzlichem Aufwand um Aspekte der Open Source Compliance und Security erweitert werden:
- Eine SCA (Software Composition Analysis) Lösung kann in bestehende Softwareentwicklungsprozesse und Freigaben etabliert werden
- Das Awarenessprogramm kann um die Aspekte der Open Source Compliance und Sicherheit erweitert werden
- Die Lieferentenvereinbarungen können und müssen um die Aspekte von Open Source ergänzt werden
Für Unternehmen, die ISO 27001 zertifiziert sind oder dies anstreben, bietet die Integration von ISO 5230 und 18974 eine Möglichkeit, ihre Sicherheitsprozesse zukunftssicher aufzustellen und diese noch weiter zu verbessern. Insbesondere im Hinblick auf gesetzliche Anforderungen wie den Cyber Resilience Act, der SBOMs und Schwachstellenmanagement in der Software-Lieferkette fordert.
Fazit und Ausblick
Die Einführung von ISO/IEC 5230 und ISO/IEC 18974 bietet nicht nur rechtliche Absicherung im Umgang mit Open Source, sondern stärkt auch die Resilienz gegenüber Software-Sicherheitsrisiken. Im Zusammenspiel mit ISO/IEC 27001 entsteht ein ganzheitlicher Ansatz für die sichere und konforme Nutzung von Open Source Software. Und das ganzheitlich vom Lizenzmanagement über das Schwachstellenmonitoring bis hin zur Lieferantensicherheit.
Angesichts wachsender regulatorischer Anforderungen wie dem Cyber Resilience Act sollten Unternehmen frühzeitig beginnen, ihre Prozesse in diesem Bereich zu harmonisieren. Wer bereits ein ISMS etabliert hat, kann hier auf bestehenden Strukturen aufbauen und mit geringem Zusatzaufwand bereits große Erfolge feiern.
Glossar
ISO/IEC 27001 Internationale Norm für Informationssicherheits-Managementsysteme (ISMS), mit dem Ziel, Risiken für Vertraulichkeit, Integrität und Verfügbarkeit von Informationen systematisch zu steuern.
ISO/IEC 5230 Internationaler Standard zur Sicherstellung von Open Source Compliance in Unternehmen, insbesondere im Hinblick auf Lizenzanforderungen und Prozesssicherheit.
ISO/IEC 18974 Norm zur Open Source Security. Sie beschreibt Anforderungen für den sicheren Umgang mit Open Source Komponenten, insbesondere zur Schwachstellenbewertung und -behandlung.
ISMS (Information Security Management System) Ein Rahmenwerk aus Richtlinien, Prozessen und Maßnahmen zur systematischen Verwaltung von Informationssicherheit in einer Organisation.
SBOM (Software Bill of Materials) Eine strukturierte Liste aller Komponenten (einschließlich Open Source), aus denen eine Software besteht. Eine SBOM ist vergleichbar mit einer Stückliste in der Fertigung.
VEX (Vulnerability Exploitability eXchange) Ein maschinenlesbares Format zur Beschreibung, ob eine bekannte Schwachstelle (CVE) für ein konkretes Produkt tatsächlich ausnutzbar ist.
OSS (Open Source Software) Software, deren Quellcode öffentlich zugänglich ist und unter einer Open-Source-Lizenz steht, die Nutzung, Änderung und Weiterverbreitung erlaubt.
Compliance Einhaltung von gesetzlichen, regulatorischen oder vertraglichen Vorgaben – im Kontext von OSS insbesondere die Einhaltung von Lizenzbedingungen.
Cyber Resilience Act (CRA) Geplante EU-Verordnung zur Verbesserung der Cybersicherheit von Produkten mit digitalen Elementen – fordert u. a. SBOMs und Schwachstellenmanagement über den gesamten Produktlebenszyklus.
Asset Management Verfahren zur Identifikation und Verwaltung von IT-Assets, einschließlich Software-Komponenten – eine Grundvoraussetzung für Sicherheits- und Lizenzmanagement.
Du möchtest mehr zum Thema erfahren?
Vereinbare einen kostenlosen Gesprächstermin mit uns oder sende uns deine Anfrage über unser Kontaktformular.
