Open Source im Unternehmen: Lizenz- und Sicherheitsrisiken mit SBOMs im Griff behalten

Open Source ist heute allgegenwärtig. 98 % aller Software-Codebasen enthalten Open-Source-Komponenten. Unternehmen setzen auf freie Bausteine, um schneller zu entwickeln und Kosten zu sparen.

Frei heißt aber nicht bedingungslos. Jede Komponente bringt eine Lizenz mit – und manche davon haben Folgen für dein eigenes Produkt.

Schon eine einzige falsche Lizenzentscheidung kann teuer werden. Im Extremfall drohen Unterlassungsverfügungen, die den Vertrieb oder Betrieb eines Produkts stoppen.

Wie verbreitet das Problem ist, zeigt derselbe Report: Zwei Drittel (68 %) der untersuchten Codebasen enthalten Lizenzkonflikte. Im Vorjahr waren es noch 56 %.

Vielleicht denkst du jetzt: Noch ein Compliance-Thema neben allem anderen? Verständlich. Wenn dein Team ohnehin am Limit liefert, klingt Lizenzmanagement nach Bremse. Die gute Nachricht: Richtig aufgesetzt, läuft das meiste automatisch mit – und erspart dir später deutlich mehr Aufwand.

Wir haben dazu mit unserem Entwickler Niko Ebener gesprochen. Er erklärt, worauf es bei Open Source im Unternehmen ankommt und wie eine SBOM dabei hilft.

In diesem Beitrag schauen wir uns an:

1. Open-Source-Lizenzen: Welche Pflichten auf dich zukommen
2. SBOM: die Zutatenliste deiner Software
3. So gehen wir bei der lise mit SBOM-Tools vor
4. Aus der Praxis: Eine SBOM für einen Maschinenbauer
5. Was du konkret tun kannst
6. Fazit: Transparenz macht Open Source sicher

Open-Source-Lizenz ist nicht gleich Open-Source-Lizenz. Grundsätzlich unterscheidet man zwei Kategorien:

• Permissive Lizenzen (= sehr freizügige Lizenzen) erlauben, den Code nahezu ohne Einschränkungen zu nutzen, zu verändern und weiterzugeben. Meist musst du nur Urheberrechts- und Lizenzhinweise beibehalten.
• Copyleft-Lizenzen (auch „virale“ Lizenzen genannt) erlauben ebenfalls Nutzung und Anpassung. Gibst du die Software weiter, musst du aber auch deinen abgeleiteten Code unter derselben Lizenz an die Empfänger*innen weitergeben. Je nach Lizenz kann das Teile oder sogar den gesamten Quellcode deines Produkts betreffen. Wer das ignoriert, riskiert Unterlassungsansprüche und Schadensersatz.

Permissive Lizenzen bieten maximale Freiheit. Copyleft-Lizenzen sorgen dafür, dass Verbesserungen wieder der Community zugutekommen. Beides ist legitim. Entscheidend ist, dass du weißt, welche Lizenz wo in deinem Produkt steckt.

Ein Snickers listet auf seiner Packung 14 Zutaten auf. So sehen Konsument*innen direkt, was in dem Riegel steckt.

Eine Software Bill of Materials (SBOM) macht dasselbe für Software. Sie ist eine strukturierte Liste aller Komponenten wie Bibliotheken und Module, inklusive Versionsnummern und Lizenzinformationen.

Eine regelmäßig aktualisierte SBOM verschafft dir einen möglichst vollständigen Überblick. Das ist gleich doppelt wichtig: für die Sicherheit und für die Lizenz-Compliance.
 

Ende 2021 wurde eine kritische Sicherheitslücke in Log4j bekannt. Die Java-Bibliothek ist seit rund 20 Jahren der De-facto-Standard, um Ereignisse, Statusmeldungen und Fehler in Log-Dateien zu protokollieren.

Das Problem: Viele Unternehmen wussten zunächst gar nicht, ob sie betroffen waren. Log4j steckte oft als indirekte Abhängigkeit in ihrer Software – unsichtbar für alle, die nur auf die direkt eingebundenen Pakete schauten.

Eine SBOM hätte Gewissheit verschafft. Mit ihr weißt du jederzeit, welche Pakete in welchen Versionen in deiner Software stecken. Im Ernstfall findest du die betroffene Komponente sofort und kannst schnell reagieren.

Auch der Gesetzgeber hat das erkannt. Der Cyber Resilience Act (CRA) der EU verlangt von Herstellern, die Software-Komponenten ihrer Produkte zu dokumentieren – unter anderem als SBOM in einem gängigen, maschinenlesbaren Format.

• Seit dem 11.09.2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen.
• Ab dem 11.12.2027 gelten die übrigen Anforderungen.

Wenn du Hardware samt Software in der EU verkaufst, wie viele Maschinen- und Anlagenbauer, betrifft dich das direkt.

Gut zu wissen: Laut CRA muss die SBOM mindestens die Top-Level-Abhängigkeiten abdecken. Veröffentlichen musst du sie nicht, nur der Marktüberwachung auf Anfrage vorlegen.

Unsere Einordnung: Beim Fall Log4j hätte das nicht gereicht, denn die Bibliothek steckte meist tief in indirekten Abhängigkeiten. Es lohnt sich also, die SBOM gründlicher aufzusetzen, als das Gesetz verlangt.
 

Auch für das Lizenzmanagement ist eine SBOM eine echte Erleichterung. Sie ist das Inventar aller Open-Source-Komponenten und ihrer Lizenzen.

So können Entwickler*innen und Compliance-Verantwortliche jederzeit prüfen, welche Lizenzauflagen gelten. Du siehst zum Beispiel auf einen Blick alle GPL-Komponenten in deinem Produkt. Dann kannst du rechtzeitig planen: den Quellcode zur Weitergabe vorbereiten oder die Komponente ersetzen.

SBOM-Tools erzeugen diese Listen in Standardformaten wie SPDX oder CycloneDX. Dadurch lassen sie sich auch mit Partnerunternehmen und Kund*innen austauschen.

Kurz: Eine SBOM schafft Transparenz. Und Transparenz schafft Sicherheit.
 

Eine Enterprise-Anwendung kann leicht Tausende direkte und transitive Dependencies (= indirekte Abhängigkeiten) haben. Manuell behält da niemand den Überblick.

Wir setzen deshalb auf tool-gestützte, strukturierte Prozesse:

1. Regeln festlegen: Welche Komponenten und Lizenzen dürfen verwendet werden? Wie wird dokumentiert? Wer gibt neue Bibliotheken frei?
2. Regeln in Tools abbilden: Software Composition Analysis (SCA), automatisierte Lizenz-Scans und SBOM-Generierung laufen direkt in der Build-Pipeline (= dem automatisierten Prozess, der aus Quellcode fertige Software erstellt).
3. Früh prüfen: Schon vor der Entwicklung klären wir, welche Komponenten technisch und lizenzrechtlich passen. So schleicht sich keine ungewollte Lizenzpflicht tief ins Produkt.
4. Automatisch abgleichen: Die Compliance-Toolchain erfasst alle Komponenten und gleicht sie mit einer Liste erlaubter und kritischer Lizenzen ab. Auffälligkeiten, etwa eine Copyleft-Lizenz im ungünstigen Kontext, zeigt sie sofort an.
5. Konkret handeln: Wir geben dazu klare Empfehlungen, zum Beispiel eine Ersatzbibliothek wählen oder die Weitergabe des Quellcodes vorbereiten.

Ist das einmal eingerichtet, läuft es im Alltag weitgehend automatisch mit. Dein Team kann sich auf die Produktentwicklung konzentrieren, statt kurz vor dem Release von Lizenzfragen ausgebremst zu werden.

Ein Beispiel aus unserem Team: Ein Unternehmen aus dem Maschinenbau verkauft seine Maschinen inklusive Software, die wir mitentwickelt haben. Die Software verlässt also das Haus und landet bei den Endkund*innen. Genau dadurch können zusätzliche Pflichten aus Open-Source-Lizenzen entstehen.

Unser Kunde wollte deshalb wissen: Haben die eingesetzten Komponenten, etwa eine Zeitreihendatenbank, Lizenzbedingungen mit Folgen für seinen bestehenden Stack?

Dabei zeigten sich zwei typische Stolpersteine:

• Abhängigkeiten haben Abhängigkeiten: Nennt die oberste Komponente eine Lizenz, eine tief verschachtelte Abhängigkeit aber eine andere, reicht der Blick auf die oberste Ebene nicht. Es gelten beide Lizenzbedingungen. Eine SBOM macht diese Verschachtelung sichtbar.
• Lizenzangaben widersprechen sich: Bei mehreren Komponenten stand auf GitHub etwas anderes als im Code selbst.

Wir haben eine SBOM erstellt und mit dem Open-Source-Tool Dependency-Track auf kritische Komponenten geprüft. Intern nutzen wir Dependency-Track vor allem, um Sicherheitslücken und Abhängigkeiten in Kundenprojekten laufend im Blick zu behalten. Das Ergebnis: eine verlässliche Dokumentation der tatsächlich verwendeten Komponenten.

Die SBOM ging anschließend an die Rechtsabteilung unseres Kunden, die die rechtliche Bewertung übernommen hat. Diese Arbeitsteilung hat sich bewährt: Entwickler*innen liefern die technische Transparenz, Jurist*innen bewerten.

Ob CTO, Produktmanager*in oder Entwickler*in: Diese acht Schritte haben sich in unseren Projekten bewährt.
 

1. Open-Source-Richtlinie definieren: Lege fest, welche Lizenztypen unbedenklich, welche genehmigungspflichtig und welche tabu sind. Eine schriftliche Policy mit Allowlist und Denylist schafft Verbindlichkeit.
2. Alle Komponenten erfassen: Führe für jede Software eine SBOM, inklusive indirekter Abhängigkeiten. Am einfachsten mit Tools, die bei jedem Build automatisch eine aktuelle SBOM erzeugen.
3. Lizenz- und Security-Scans automatisieren: Integriere SCA-Tools in deine CI/CD-Pipeline und hinterlege dort deine Lizenz-Policy. Verstöße stoppen dann den Build oder lösen zumindest eine Warnung aus. So fallen Probleme früh auf, nicht erst kurz vor dem Release.
4. SBOMs von Lieferanten einfordern: Auch zugekaufte Software kann Lizenzverstöße enthalten, die zum rechtlichen Risiko für dein Unternehmen werden. Verlange SBOMs und Lizenzangaben.
5. Technik und Recht klar trennen: SBOM und Scans liefern die Fakten. Die verbindliche rechtliche Bewertung gehört in die Rechtsabteilung oder zu spezialisierten Anwält*innen.
6. Team sensibilisieren: Dein Entwicklungsteam sollte wissen, dass etwa ein npm-Paket unter GPL oder AGPL nicht „einfach so“ eingebunden werden kann. Regelmäßige Schulungen oder kurze Guidelines im Repository helfen, Wissenslücken zu schließen.
7. Freigaben und Reviews etablieren: Neue Komponenten werden vor dem Einsatz geprüft, idealerweise von einem kleinen Gremium wie dem Architekturboard. Das Vier-Augen-Prinzip senkt das Risiko, etwas zu übersehen.
8. Regelmäßig aktualisieren, aber nicht blind: Open Source ist kein „Fire-and-Forget“. Halte Komponenten aktuell und entferne ungepflegte Bibliotheken. Aber Achtung: Supply-Chain-Angriffe über manipulierte Paket-Updates haben zuletzt deutlich zugenommen. 

Prüfe neue Versionen vor dem Einspielen, pinne Versionsstände und erzeuge bei jedem Update eine neue SBOM.
 

Open Source ist aus der Softwareentwicklung nicht wegzudenken. Die Vorteile für Geschwindigkeit, Innovation und Kosten sind zu groß.

Genauso real sind aber die Risiken, wenn Lizenzauflagen übersehen werden oder Abhängigkeiten im Dunkeln bleiben. Im schlimmsten Fall drohen teure Rechtsstreitigkeiten.

Die Lösung ist kein Verzicht, sondern Überblick: klare Lizenzregeln, eine vollständige SBOM und automatisierte Prüfungen in der Pipeline.

Mit dem Cyber Resilience Act wird die SBOM für viele Hersteller ohnehin Pflicht. Wenn du jetzt einsteigst, bist du vorbereitet, bevor Kund*innen oder Behörden danach fragen.

Am Ende gilt: Nicht Open Source ist das Risiko, sondern Open Source, von dem du nichts weißt.

Wir entwickeln digitale Produkte, die zu dir passen. Von der ersten Idee über die Umsetzung bis zum Betrieb. Sicherheit und Transparenz denken wir dabei von Anfang an mit.

Mit über 27 Jahren Erfahrung und mehr als 700 Projekten begleiten wir dich:

• Individuelle Softwareentwicklung und KI-Lösungen, vom Prototyp nach wenigen Stunden bis zum laufenden System
• Modernisierung bestehender Anwendungen, inklusive Software Audit und SBOM
• DevOps und Betrieb mit Security-by-Design
• Zertifiziert nach ISO 27001, entwickelt von festen Teams in Deutschland
• Feste Ansprechpartner*innen, transparente Kommunikation und volle Kontrolle über dein Budget

Beratungsgespräch vereinbaren!