Open-Source-/SBOM-Check

Open-Source-Komponenten, Lizenzen und SBOM rechtlich einordnen

Q: Wann wird Open-Source-/SBOM-Compliance besonders relevant?

Besonders relevant wird Open-Source-/SBOM-Compliance bei Software-Releases, App- oder Container-Auslieferung, Firmware und IoT-Produkten, SDKs, Kundenprojekten, M&A-Prüfungen, Sicherheitsvorfällen, Lieferantenwechseln und wenn Kunden eine SBOM, OSS-Disclosure oder Security-Nachweise verlangen.

Dieser interaktive Check hilft Unternehmen, Softwareanbieter, SaaS-/Cloud-Dienste, Agenturen, Integratoren, IoT-Hersteller und Einkaufs- oder Security-Teams dabei, typische Risiken aus Open-Source-Nutzung, Copyleft, fehlenden Notices, SBOM-Lücken, Vulnerabilities, Kundenanforderungen und CRA-Readiness vorläufig zu strukturieren.

OSS-Lizenzen SBOM & Inventar Copyleft & Notices CRA & Security

Wofür der Check gedacht ist

Der Check liefert eine erste Orientierung, ob eine vertiefte Lizenz-, IP-, Security- oder Produkt-Compliance-Prüfung sinnvoll ist. Besonders relevant ist er vor Releases, Kundenaudits, M&A-Prüfungen, Lieferantenwechseln, kritischen Schwachstellen, OSS-Claims oder dem Aufbau einer CRA-konformen Software-Lieferkette.

Erfasst typische Risikosignale aus Distribution, SaaS, Embedded, SDKs und Kundenprojekten.
Verknüpft Lizenzrisiken mit SBOM, Vulnerability-Handling, Secure SDLC und Release-Gates.
Gibt konkrete nächste Prüfpunkte und Unterlagen für eine Anfrage bei ITMR aus.

Visualisierung

Komponenten- und Lizenzgraph einer Software-Lieferkette

Open-Source-Risiken entstehen selten an nur einer Stelle. Entscheidend ist das Zusammenspiel aus direkter Dependency, transitiver Dependency, Lizenztyp, Notice-Pflichten, Schwachstellen, Source-Angeboten und Kunden- oder CRA-Nachweisen.

Inventar zuerst: Ohne vollständige direkte und transitive Komponentenliste lassen sich Lizenzpflichten, Schwachstellen, Notices und CRA-Nachweise kaum belastbar prüfen.

Prüflogik

So strukturiert der Check die Erstbewertung

Rolle und Produktform klären

Softwareanbieter, SaaS, Embedded, Agentur, Einkauf oder internes Entwicklerteam haben unterschiedliche OSS-, Vertrags- und Nachweispflichten.

Komponenten sichtbar machen

Direkte und transitive Dependencies, Container, SDKs, Firmwarebestandteile, Forks und Build-Artefakte müssen releasebezogen erfassbar sein.

Lizenzpflichten bewerten

Permissive Lizenzen, weak copyleft, strong copyleft, AGPL, Dual Licensing, Notices und Source-Angebote werden kontextabhängig relevant.

Security und CRA einordnen

Für Produkte mit digitalen Elementen sind SBOM, Vulnerability Disclosure, Patch-Prozesse und Secure SDLC zunehmend Teil der Produkt-Compliance.

Nachweise und nächste Schritte ableiten

Der Check erzeugt eine Anfragezusammenfassung mit Risikogründen, Prüfpunkten und vorzubereitenden Unterlagen.

Einordnung

Was dieser Check leistet

Der Open-Source-/SBOM-Check ersetzt keine rechtliche oder technische Einzelfallprüfung. Er hilft aber, typische Risikotreiber früh zu erkennen: unklare Lizenzlage, fehlende Komponentenübersicht, Copyleft bei Verteilung, AGPL bei SaaS, fehlende Notices, ungepatchte Dependencies, Kundenaudits, M&A-Due-Diligence, CRA-Roadmap oder regulatorischer Nachweisbedarf.

Wann wird Open-Source-/SBOM-Compliance besonders relevant?

Besonders relevant wird sie bei Software-Releases, App- oder Container-Auslieferung, Firmware und IoT-Produkten, SDKs, Kundenprojekten, M&A-Prüfungen, Sicherheitsvorfällen, Lieferantenwechseln und wenn Kunden eine SBOM, OSS-Disclosure oder Security-Nachweise verlangen.

Warum ist der CRA für OSS und SBOM wichtig?

Der Cyber Resilience Act ist seit 10.12.2024 in Kraft. Für Produkte mit digitalen Elementen werden Security-by-design, Vulnerability-Handling, technische Dokumentation und Konformitätsprozesse zentral. Meldepflichten sind ab 11.09.2026 vorzubereiten; die Hauptpflichten gelten ab 11.12.2027. OSS-Komponenten und SBOM sind dafür wichtige Nachweisbausteine.

Was kann der Check nicht abschließend entscheiden?

Der Check kann nicht verbindlich beurteilen, ob eine konkrete Lizenz verletzt ist, ob ein bestimmtes Linking ein Derivat bildet, ob ein Source-Angebot ausreicht oder ob eine konkrete Komponente CRA-relevant ist. Dafür sind Code-, Architektur-, Vertrags- und Release-Unterlagen zu prüfen.

Interaktiver Check

Open-Source-/SBOM-Risiko vorläufig einordnen

Beantworten Sie die folgenden Fragen. Das Ergebnis zeigt typische Risikosignale, Prioritäten, Prüfpunkte und Unterlagen für eine strukturierte Anfrage.

Schritt 1 von 5

1. Welche Rolle beschreibt Ihr Unternehmen am besten? Software-, App- oder SaaS-AnbieterSie entwickeln oder vertreiben eigene Software, Apps, Plattformen, APIs oder digitale Produkte. SaaS-/Cloud-AnbieterSie stellen Software als Online-Service bereit; Kunden erhalten keinen klassischen Quellcode oder Installer. IoT-, Embedded-, Hardware- oder Firmware-AnbieterOpen Source steckt in Geräten, Firmware, Edge-Systemen, Maschinen, Routern, Sensoren oder Apps. Agentur, Integrator oder EntwicklungsdienstleisterSie entwickeln oder integrieren Software für Kunden und verwenden dabei Drittkomponenten. Kunde, Einkauf oder Vendor-ManagementSie prüfen Software, SaaS, Komponenten oder Lieferanten auf OSS-/SBOM-Risiken. Open-Source-Projekt, Maintainer oder StewardSie betreuen, veröffentlichen oder kommerziell unterstützen Open-Source-Software. Interne EntwicklungSoftware wird vor allem intern genutzt, kann aber später produktisiert, geprüft oder ausgeliefert werden.

2. Wie wird die Software bereitgestellt oder genutzt? Download, App, Installer oder Binary wird verteiltKunden oder Nutzer erhalten ausführbare Software, App, Container, Plugin oder Paket. Software/Firmware ist in Produkt oder Gerät eingebettetOSS läuft in Hardware, Firmware, Embedded System, IoT-Gerät, Appliance oder Maschinenkomponente. Nur SaaS oder serverseitiger BetriebKunden nutzen den Dienst über Browser, App oder API; Software wird nicht klassisch ausgeliefert. Kundenprojekt oder IndividualentwicklungSoftware wird für einen bestimmten Kunden erstellt, angepasst, übergeben oder betrieben. Open Source wurde verändert oder geforktBibliotheken, Frameworks, Kernel, Firmware, Module oder Tools wurden angepasst. Container, API, SDK, CLI oder EntwicklerkomponenteSie liefern Images, SDKs, Libraries, Plug-ins, Build-Tools oder Entwicklerpakete. Nur interne NutzungKeine Weitergabe an Kunden, keine externe Bereitstellung, kein Produktvertrieb. Unklar oder mehrere BereitstellungsformenVerteilung, SaaS, Embedded, Kundenübergabe oder interne Nutzung sind noch nicht sauber abgegrenzt.

3. Welche Lizenz- oder Komponentenrisiken gibt es?

Bitte markieren Sie alles, was zutrifft.

Vor allem permissive LizenzenMIT, BSD, Apache-2.0 oder ähnliche Lizenzen mit Attribution-/Notice-Pflichten. Schwaches Copyleft möglichLGPL, MPL, EPL oder ähnliche Lizenzen können Austauschbarkeit, Modifikationen oder Datei-/Library-Grenzen relevant machen. Starkes Copyleft möglichGPL oder vergleichbare Lizenzen, insbesondere bei Verteilung, Linking, Derivaten oder Embedded-Produkten. AGPL oder Netzwerk-Copyleft möglichSaaS-, API- oder Netzwerkbetrieb kann besondere Quellcode- oder Zugänglichmachungsfragen auslösen. Unbekannte oder uneinheitliche LizenzlageDependencies, transitive Dependencies, Snippets, Forks, GitHub-Code oder KI-generierter Code wurden nicht zuverlässig geprüft. Kommerzielle Drittkomponenten oder Dual LicensingSDKs, Datenbanken, Fonts, UI-Kits, Icons, AI-Modelle, Plugins oder Libraries mit Lizenzmetriken. Attribution, Copyright Notices oder Lizenztexte fehlenNotice File, About-Box, OSS-Report, Lizenzanhang oder Source-Angebot ist nicht vollständig. Kein vollständiges Komponenten- oder LizenzinventarEs gibt keine belastbare Übersicht über direkte und transitive Dependencies, Versionen und Lizenzen. Keine bekannten Lizenzrisiken oder noch unklarEs gibt bereits eine grobe Prüfung oder noch keine belastbaren Hinweise auf konkrete Lizenzrisiken.

5. Gibt es konkreten Handlungsdruck?

Bitte markieren Sie alles, was zutrifft.

Launch, Release oder Kundenauslieferung steht bevorProdukt, App, Firmware, Container, SDK oder SaaS-Funktion soll kurzfristig veröffentlicht werden. Kunde, Einkauf oder Security-Team verlangt SBOM/OSS-NachweiseVendor Assessment, Security Questionnaire, OSS Disclosure, SBOM, Audit oder Procurement-Freigabe. M&A, Investment, Due Diligence oder ExitInvestor, Käufer, Konzern, Versicherung oder Auditor prüft IP, OSS, Security und Lieferkette. CRA, NIS-2 oder regulierte LieferketteProdukt mit digitalen Elementen, kritischer Kunde, IT-Security-Anforderungen oder regulatorische Roadmap. Kritische Schwachstelle oder Security AdvisoryLog4Shell-ähnliches Thema, CVE, Exploit, unsichere Dependency, kompromittiertes Paket oder Kundenwarnung. Lizenzhinweis, Abmahnung oder OSS-ClaimRechteinhaber, OSS-Projekt, Kunde oder Wettbewerber behauptet Lizenzverstoß, fehlenden Quellcode oder fehlende Notices. Neue Komponente, Toolwechsel oder LieferantenproblemNeue Library, SDK, AI-Modell, Paketquelle, Cloud-Komponente, Entwicklerteam oder Lieferant. Präventive PrüfungKeine akute Frist, aber OSS-Compliance, SBOM und Security Supply Chain sollen sauber aufgebaut werden.

Fristen & Maßnahmen

Typische Risiken, Fristen und Nachweise

Thema	Typisches Risiko	Zeitliche Einordnung	Praktische Maßnahme
OSS-Inventar und SBOM	Direkte und transitive Dependencies, Versionen, Lizenzen, CVEs oder Herkunft sind nicht belastbar dokumentiert.	Releasebezogen und bei Kunden-/Audit-Anforderungen sofort relevant.	SBOM pro Produktversion, Dependency-Inventar, Lizenz- und CVE-Scan sowie Freigabe-Gate etablieren.
Copyleft und Notices	GPL, LGPL, MPL, AGPL oder fehlende Lizenztexte können Quellcode-, Austauschbarkeits- oder Notice-Pflichten auslösen.	Vor Verteilung, Kundenübergabe, Firmware-Auslieferung oder SaaS-Architekturänderung prüfen.	Lizenzreview, Architekturprüfung, Notice File, Lizenzanhang und Source-Code-Angebot vorbereiten.
Cyber Resilience Act	Produkte mit digitalen Elementen benötigen Security-by-design, Vulnerability-Handling und technische Dokumentation.	Meldepflichten ab 11.09.2026; Hauptpflichten ab 11.12.2027.	Secure SDLC, VDP/PSIRT, SBOM, Patch-Prozess, Release-Dokumentation und CRA-Produktakte aufbauen.
Kunden, Einkauf und Due Diligence	Fehlende SBOM, OSS-Disclosure oder Security-Nachweise blockieren Procurement, M&A oder Vertragsabschluss.	Regelmäßig kurzfristig, sobald Audit, Ausschreibung, Investor oder Kunde Nachweise verlangt.	OSS-Report, Lieferanten-SBOMs, Security-Fragebogen, Vertragsgarantien und Risikoausnahmen vorbereiten.
Kritische Schwachstelle	CVE, Exploit, kompromittiertes Paket oder unsichere Dependency kann Kundenkommunikation und Patchpflichten auslösen.	Ereignisabhängig sofort; Meldepflichten können je nach Rechtsregime zusätzlich greifen.	Betroffenheit feststellen, Patchstrategie, Advisory, Kundeninformation, Logs und Entscheidungsdokumentation sichern.

Nächste sinnvolle Schritte

Open-Source-/SBOM-Prüfung strukturiert vorbereiten

Wenn Releases, Kundenanforderungen, Copyleft, kritische Schwachstellen oder CRA-Readiness im Raum stehen, sollte die Prüfung nicht nur technisch, sondern auch lizenz-, vertrags- und produktrechtlich erfolgen.

Anfrage mit Kurzüberblick senden

Hinweis: Dieser Check bietet eine unverbindliche Erstorientierung. Er ersetzt keine Prüfung konkreter Software, Verträge, Lizenztexte, Architektur, Build-Prozesse, Kundenzusagen, Security-Vorfälle oder regulatorischer Pflichten im Einzelfall.