EU CRA SBOM-Compliance: So erfüllen Sie die Anforderungen bis 2027

Die wichtigsten Punkte

• SBOM erhöht die Transparenz durch ein strukturiertes Inventar von Softwarekomponenten und unterstützt Security by Design
• Der EU Cyber Resilience Act (CRA) schreibt SBOM als Teil der Sicherheits- und Compliance-Verpflichtungen für Produkte mit digitalen Elementen vor.
• TR-03183 verlangt, dass SBOMs maschinenlesbar (JSON/XML) sind und SPDX oder CycloneDX 1.5+ entsprechen, um ein automatisiertes Schwachstellenmanagement zu ermöglichen.
• SBOMs enthalten keine Schwachstelleninformationen, ermöglichen aber externe Schwachstellenbewertungen (z. B. VEX, CSAF) als Teil der Risikobewertung
• Strafen bei Nichteinhaltung können bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes betragen, wobei Marktüberwachungsbehörden befugt sind, Produkte vom Markt zu nehmen.
• CLOUDYRION unterstützt Unternehmen bei der Implementierung von SBOMs, kryptografischer Signierung und Compliance-Maßnahmen zur Erfüllung der EU-CRA-Anforderungen.

---

Die Herausforderung: Mangelnde Transparenz bei Drittanbieter-Abhängigkeiten

Eine der größten Herausforderungen in der Softwaresicherheit ist die mangelnde Transparenz bei Drittanbieter-Abhängigkeiten. Viele Unternehmen setzen auf Softwarekomponenten von Drittanbietern, haben aber keinen vollständigen Einblick in den Inhalt ihrer Anwendungen. Dies erschwert die Erkennung und Behebung von Schwachstellen und erhöht das Risiko von Cyberangriffen.

Der EU CRA adressiert diese Risiken durch die Durchsetzung einer transparenten Dokumentation der Softwaresicherheit, die verpflichtende SBOMs als Eckpfeiler der Lieferkettensicherheit umfasst. Ohne eine strukturierte SBOM haben Unternehmen Schwierigkeiten:

• Schwachstellen effektiv zu erkennen und darauf zu reagieren, einschließlich aktiv ausgenutzter Schwachstellen
• Regulatorische Anforderungen einzuhalten, wie sie beispielsweise in der NIS2-Richtlinie festgelegt sind
• Softwareintegrität und -sicherheit zu gewährleisten, die zentrale Aspekte der Secure-by-Default-Prinzipien sind

Um diese Probleme anzugehen, schreibt die BSI TR-03183 ein maschinenverarbeitbares SBOM-Format vor, das kryptografische Integrität, Metadaten-Tracking und strukturierte Abhängigkeiten umfasst. Dieser Ansatz entspricht dem europäischen Cybersicherheits-Zertifizierungsschema und unterstützt das vom CRA geforderte Konformitätsbewertungsverfahren.

CRA-Compliance-Zeitplan

Das Verständnis der wichtigsten Termine ist entscheidend für die Planung Ihrer Compliance-Reise:

Meilenstein	Datum
CRA in Kraft getreten	10. Dezember 2024
Meldepflichten gelten	11. September 2026
Vollständige Verpflichtungen gelten	11. Dezember 2027

Wichtig: Der delegierte Rechtsakt zur RED (EU 2022/30) wird voraussichtlich mit Wirkung vom 11. Dezember 2027 aufgehoben, wodurch der CRA das einzige horizontale Gesetz zur Produktcybersicherheit bleibt.

Durchsetzung und Strafen

Der CRA führt erhebliche Durchsetzungsbefugnisse ein. Gemäß Artikel 64 können Verstöße zu folgenden Strafen führen:

Art des Verstoßes	Höchststrafe
Schwerwiegende Verstöße	15 Mio. € oder 2,5 % des weltweiten Umsatzes
Weniger schwerwiegende Verstöße	10 Mio. € oder 2 % des weltweiten Umsatzes

Darüber hinaus können Marktüberwachungsbehörden Produkte vom Markt nehmen, deren Bereitstellung untersagen oder Rückrufe anordnen.

Welche Produkte sind betroffen? CRA-Klassifizierung verstehen

Der CRA gilt für praktisch alle Produkte mit digitalen Elementen, die auf dem EU-Markt verkauft werden. Allerdings unterliegen nicht alle Produkte denselben Compliance-Anforderungen. Die Verordnung führt ein risikobasiertes Klassifizierungssystem ein, das den Prüfungsumfang und die Art der erforderlichen Konformitätsbewertung bestimmt.

Standardprodukte (Standardkategorie)

Die Mehrheit der digitalen Produkte fällt in diese Kategorie. Hersteller können eine Selbstbewertung durchführen, um die Compliance nachzuweisen – keine Drittpartei-Beteiligung erforderlich. Dazu gehören Verbraucheranwendungen, einfache IoT-Geräte, Standard-Unternehmenssoftware und die meisten vernetzten Produkte ohne kritische Sicherheitsfunktionen.

Klasse I – Wichtige Produkte

Produkte in dieser Kategorie haben eine erhöhte Sicherheitsrelevanz und erfordern entweder interne Kontrollverfahren auf Basis harmonisierter Standards oder eine Drittpartei-Bewertung, wenn Standards nicht angewendet werden. Klasse-I-Produkte umfassen:

• Passwort-Manager und Authentifizierungssoftware
• VPN-Clients und Remote-Access-Tools
• Netzwerkmanagement- und Konfigurationstools
• Browser und Browser-Erweiterungen
• Boot-Manager und BIOS/UEFI-Software

Klasse II – Kritische Produkte

Diese Produkte sind für die Cybersicherheitsinfrastruktur essenziell und müssen eine verpflichtende Drittpartei-Konformitätsbewertung durch eine benannte Stelle vor dem Inverkehrbringen durchlaufen. Klasse-II-Produkte umfassen:

• Firewalls und Intrusion Detection/Prevention Systeme (IDS/IPS)
• Hardware-Sicherheitsmodule (HSMs) und manipulationssichere Hardware
• Betriebssysteme (Desktop, Mobil, Server)
• Hypervisoren und Container-Runtime-Umgebungen
• Public-Key-Infrastruktur (PKI)-Komponenten
• Smart Meter und kritische Infrastruktur-Controller

Vom CRA ausgenommene Produkte

Bestimmte Produktkategorien sind explizit ausgenommen, da sie bereits durch sektorspezifische Gesetzgebung reguliert werden:

Ausnahme	Anwendbare Regulierung
Software-as-a-Service (SaaS)	NIS2-Richtlinie (EU 2022/2555)
Automotive-Produkte	UN R155/R156
Medizinprodukte	MDR/IVDR
Luftfahrtsysteme	EU-Luftfahrtsicherheitsvorschriften
Verteidigung und nationale Sicherheit	Nationale Vorschriften der Mitgliedstaaten
Open-Source-Software*	Unter bestimmten Bedingungen ausgenommen

*Die Open-Source-Ausnahme gilt nur für nicht-kommerzielle, community-getriebene Entwicklung ohne Supportverpflichtungen oder direkte finanzielle Vergütung von Nutzern. Sobald Open-Source-Komponenten in ein kommerzielles Produkt integriert werden, liegen sie in der Verantwortung des Herstellers.

Warum die Klassifizierung wichtig ist

Die korrekte Klassifizierung Ihrer Produkte ist der entscheidende erste Schritt auf Ihrer Compliance-Reise. Eine Fehlklassifizierung kann zu unzureichender Konformitätsbewertung führen (mit dem Risiko von Strafen bei Nichteinhaltung) oder zu unnötigen Drittpartei-Kosten. Bei Unsicherheit über die Klassifizierung Ihres Produkts sollten Sie frühzeitig Expertenrat einholen.

---

SBOM verstehen und seine Rolle bei der Compliance

Eine Software Bill of Materials ist im Wesentlichen ein detailliertes Inventar von Softwarekomponenten, vergleichbar mit einer Zutatenliste für Software. TR-03183 definiert SBOM als ein maschinenlesbares Dokument, das eine automatisierte Sicherheitsverarbeitung unterstützt – entscheidend für die Verwaltung der Angriffsfläche von Produkten mit digitalen Elementen.

Verpflichtende SBOM-Elemente (TR-03183-2)

Eine konforme SBOM MUSS enthalten:

• Komponentenname und Version – Gewährleistung der Rückverfolgbarkeit von Abhängigkeiten
• Komponentenersteller (Hersteller/Lieferanten-URL oder E-Mail) – Identifizierung der Softwarequellen
• Lizenzinformationen – Sowohl deklarierte als auch abgeleitete Lizenzen
• Kryptografischer Hash (SHA-512) – Sicherstellung der Integrität deployierbarer Komponenten
• Dateieigenschaften – Ob die Komponente ausführbar, ein Archiv oder strukturiert ist
• Zeitstempel – Datum und Uhrzeit der SBOM-Erstellung
• Abhängigkeits-Tracking – Mindestens bis zur ersten externen Komponente

Ohne diese Pflichtfelder erfüllt eine SBOM nicht die Compliance-Anforderungen von TR-03183 und damit auch nicht die CRA-Anforderungen.

Wie sich TR-03183 von US-Standards unterscheidet

Unternehmen, die mit den US-amerikanischen NTIA-Mindestanforderungen (National Telecommunications and Information Administration) für SBOMs vertraut sind, fragen sich möglicherweise, wie die europäischen Anforderungen im Vergleich abschneiden. Während beide Rahmenwerke gemeinsame Grundlagen teilen, stellt TR-03183 zusätzliche Pflichtanforderungen, die über die US-Baseline hinausgehen.

SBOM-Element	NTIA (USA)	TR-03183 (EU)
Lieferanten-/Erstellername	✓	✓
Komponentenname	✓	✓
Komponentenversion	✓	✓
Abhängigkeitsbeziehungen	✓	✓
Zeitstempel	✓	✓
Eindeutiger Identifikator	✓	✓
Kryptografischer Hash (SHA-512)	–	✓ Pflicht
Lizenzinformationen	–	✓ Pflicht
SBOM-URI/Dokument-Namespace	–	✓ Pflicht
Dateieigenschaften (ausführbar/Archiv)	–	✓ Pflicht

Wichtige Unterschiede erklärt

Kryptografischer Hash: TR-03183 schreibt SHA-512-Hashes für alle deployierbaren Komponenten vor. Dies gewährleistet die Integritätsverifizierung – Sie können nachweisen, dass die Komponente in der Produktion exakt dem entspricht, was in der SBOM dokumentiert wurde.

Lizenzinformationen: Die europäischen Anforderungen umfassen explizit sowohl deklarierte als auch abgeleitete Lizenzen. Dies unterstützt die rechtliche Compliance und das Management von geistigem Eigentum entlang der Lieferkette.

SBOM-URI: Jede SBOM muss einen eindeutigen Dokument-Namespace (URI) haben, der eine unmissverständliche Identifizierung und systemübergreifende Referenzierung ermöglicht.

Dateieigenschaften: Komponenten müssen nach Typ klassifiziert werden (ausführbar, Archiv, Quellcode oder strukturierte Daten), was eine granularere Sicherheitsanalyse unterstützt.

Was das für Ihre Compliance-Strategie bedeutet

Wenn Ihr Unternehmen bereits SBOMs nach NTIA-Richtlinien erstellt, haben Sie eine solide Grundlage – aber Sie sind noch nicht CRA-konform. Das Upgrade auf TR-03183 erfordert das Hinzufügen kryptografischer Hashes zu allen Komponenteneinträgen, die Einbeziehung umfassender Lizenzdaten, die Implementierung eindeutiger Dokumentidentifikatoren und die Klassifizierung der Dateieigenschaften für jede Komponente.

Die meisten modernen SBOM-Tools (Syft, Trivy, CycloneDX CLI) können TR-03183-konforme Ausgaben mit der richtigen Konfiguration generieren. Der Schlüssel liegt darin, Ihre Pipeline-Einstellungen und Validierungsprüfungen vor der 2027-Deadline zu aktualisieren.

Gängige SBOM-Formate

Um Kompatibilität zu gewährleisten, MÜSSEN SBOMs in JSON oder XML formatiert sein und einem dieser Standards entsprechen:

1. CycloneDX (Version 1.5 oder höher) – Fokussiert auf Sicherheitsanwendungen (bevorzugt für CRA-Compliance)
2. SPDX (Version 2.2.1 oder höher) – Weit verbreitet für Softwarepaketbeschreibungen und Lizenzierung
3. SWID Tags – Weniger verbreitet, aber in Unternehmensumgebungen genutzt

SBOM und VEX (TR-03183-Compliance)

Ein häufiges Missverständnis ist, dass SBOMs Schwachstellendaten enthalten. Das ist nicht korrekt.

BSI TR-03183 legt ausdrücklich fest, dass SBOMs KEINE Schwachstelleninformationen enthalten DÜRFEN. Diese Trennung unterstützt effektivere Prozesse im Schwachstellenmanagement.

Stattdessen sollten Unternehmen SBOMs mit separaten Schwachstellenberichten kombinieren unter Verwendung von:

• VEX (Vulnerability Exploitability eXchange) – Liefert Kontext darüber, ob eine Schwachstelle ausnutzbar ist
• CSAF (Common Security Advisory Framework) – Ein standardisiertes Format für Sicherheitshinweise

Best Practice: Nutzen Sie SBOM für Komponententransparenz und VEX für die Analyse der Schwachstellenauswirkungen.

---

Entwicklungen 2025: Standardisierung und Infrastruktur

Seit dem Inkrafttreten des CRA im Dezember 2024 wurden erhebliche Fortschritte bei der Implementierungsinfrastruktur erzielt:

Europäische Standardisierung

Am 3. April 2025 wurde der Standardisierungsauftrag für den CRA offiziell von CEN, CENELEC und ETSI angenommen. Diese europäischen Normungsorganisationen entwickeln:

• Typ-A-Standards: Horizontale Standards, die allgemeine Cybersicherheitsanforderungen abdecken
• Typ-B-Standards: Generische Sicherheitsanforderungen, die produktübergreifend anwendbar sind
• Typ-C-Standards: Produktspezifische Anforderungen (Veröffentlichung bis Oktober 2026 geplant)

Im September 2025 veröffentlichte ETSI die ersten Entwürfe Europäischer Normen (EN) zur öffentlichen Konsultation, die technische Standards für Produktkategorien wie Passwort-Manager, Netzwerkschnittstellen und Betriebssysteme abdecken.

ENISA-Infrastruktur

• European Vulnerability Database (EUVD) – Am 13. Mai 2025 gestartet, dient als zentrale Plattform für verwertbare Schwachstelleninformationen in der gesamten EU
• Single Reporting Platform (SRP) – Derzeit in Entwicklung für die Meldung von Schwachstellen und Vorfällen gemäß Artikel 16
• EUCC-CRA-Angleichung – ENISA hat Studien veröffentlicht, die analysieren, wie eine Zertifizierung durch EUCC die CRA-Compliance nachweisen könnte, wobei Pilotprojekte bereits laufen

BSI Technische Richtlinien-Updates

Das BSI entwickelt eine umfassende technische Richtlinie in drei Teilen:

• Teil 1: Allgemeine Anforderungen – Leitlinien für Hersteller und Produkte in Übereinstimmung mit CRA-Artikeln und Anhängen
• Teil 2: Software Bill of Materials (SBOM) – Formale und inhaltliche Anforderungen an SBOMs
• Teil 3: Schwachstellenberichte und Meldungen – Verfahren für den Umgang mit eingehenden Schwachstellenmeldungen

---

Integration von SBOMs in CI/CD-Pipelines

SBOMs sollten in den Softwarelebenszyklus integriert werden, um sicherzustellen, dass sie in jeder Build-Phase automatisch generiert und aktualisiert werden. Durch kontinuierliche Überwachung von Abhängigkeiten und Validierung von SBOMs mit Tools wie Syft und Trivy können Unternehmen Sicherheitsrisiken vor dem Deployment verhindern. Sichere Build-Pipelines spielen eine entscheidende Rolle bei der Minderung von Bedrohungen in der Software-Lieferkette und unterstützen den Produktlebenszyklus.

Die BSI TR-03183-Richtlinie verlangt, dass SBOMs in sichere Softwareentwicklungs-Pipelines integriert werden, um eine durchgängige Rückverfolgbarkeit zu gewährleisten.

Best Practices für die SBOM-Integration

Eine effektive SBOM-Implementierung beginnt mit Automatisierung. Unternehmen sollten SBOMs automatisch in jeder Build-Phase generieren, um sicherzustellen, dass jede Version eine genaue Momentaufnahme aller Komponenten erfasst. Dependency-Tracking-Tools wie Syft, Grype und OWASP Dependency-Check helfen dabei, Schwachstellen zu erkennen, bevor sie in die Produktion gelangen. Um die Integrität Ihrer Software-Lieferkette weiter zu stärken, sollten Sie das SLSA-Framework (Supply Chain Levels for Software Artifacts) für sichere Builds einsetzen und alle SBOMs kryptografisch signieren – beispielsweise mit Tools wie Sigstore’s Cosign.

Vom Commit bis zum Deployment: Ein Beispiel-Workflow

Eine gut konzipierte Pipeline integriert die SBOM-Generierung nahtlos in den Entwicklungslebenszyklus. Wenn Entwickler Code committen, löst die CI/CD-Pipeline automatisch die SBOM-Generierung aus. Während des Build-Prozesses wird diese SBOM integriert und validiert, um vollständige Transparenz über alle Abhängigkeiten zu gewährleisten. Sicherheitstools analysieren anschließend die SBOM, um potenzielle Risiken zu identifizieren, bevor der Build fortgesetzt wird. Nach erfolgreicher Freigabe werden sowohl die finalen Build-Artefakte als auch die zugehörige SBOM kryptografisch signiert. Beim Deployment wird die signierte SBOM gemeinsam mit dem Release ausgeliefert – dies ermöglicht regulatorische Audits und liefert einen verifizierbaren Nachweis darüber, was genau ausgeliefert wurde.

Dieser Ansatz gewährleistet Compliance bei gleichzeitiger Minimierung von Sicherheitsrisiken und unterstützt die langfristige Resilienz der Software.

Kryptografisches Hashing und Signieren für SBOM-Integrität

Die Sicherstellung der Integrität einer SBOM ist ebenso wichtig wie deren Erstellung. Ohne angemessene Schutzmaßnahmen könnte eine SBOM manipuliert werden, was das Vertrauen untergräbt, das sie eigentlich schaffen soll. Code-Signierung ermöglicht es Entwicklern, die Authentizität von Software mithilfe kryptografischer Signaturen zu verifizieren, während die Prüfsummen-Validierung sicherstellt, dass Dateien mithilfe von Hash-Funktionen wie SHA-256 unverändert bleiben. Für die SBOM selbst ermöglichen Tools wie Sigstore’s Cosign das Anwenden digitaler Signaturen, die beweisen, dass das Dokument seit seiner Erstellung nicht verändert wurde. Zusammen entsprechen diese Techniken den Secure-by-Default-Prinzipien, die im CRA verankert sind.

Sichere Software-Build-Pipelines und SBOM-Integration

Damit eine SBOM wirklich effektiv ist, muss sie in sichere Entwicklungspipelines eingebettet werden – anstatt nachträglich hinzugefügt zu werden. Reproduzierbare Builds stellen sicher, dass derselbe Quellcode immer identische Ausgaben erzeugt, wodurch verifiziert werden kann, dass verteilte Binärdateien mit ihren angegebenen Ursprüngen übereinstimmen. Build-Provenance-Tracking, unterstützt durch Frameworks wie SLSA, liefert einen auditierbaren Nachweis darüber, wo und wie Software erstellt wurde. Schließlich verhindern ephemere Build-Umgebungen – temporäre, saubere Umgebungen, die für jeden Build neu erstellt und danach wieder gelöscht werden – dass persistente Bedrohungen die Pipeline über die Zeit hinweg kompromittieren.

---

Warum SBOM für kritische Branchen wichtig ist

Mit dem CRA sind SBOMs nicht mehr optional – Sektoren wie Energie, Gesundheitswesen, Finanzwirtschaft und Transportwesen sind auf digitale Produkte angewiesen, die strenge regulatorische Standards erfüllen müssen. Ohne SBOM-Compliance riskieren Unternehmen Sanktionen wegen Nichteinhaltung. SBOM stärkt die Resilienz durch:

• Transparenz über Drittanbieter-Komponenten zur Reduzierung von Lieferkettenrisiken
• Unterstützung eines proaktiven Schwachstellenmanagements durch automatisierte Sicherheitsscans
• Erleichterung der Incident Response durch schnelle Identifikation betroffener Komponenten
• Sicherstellung der Software-Herkunft und -Authentizität durch kryptografische Signierung

Diese Praktiken sind besonders wichtig für alle Unternehmen, die Produkte mit digitalen Elementen auf dem EU-Markt anbieten – unabhängig von ihrem Standort.

---

Für wen gilt der CRA?

Der CRA hat einen breiten Anwendungsbereich und umfasst nahezu alle Hardware- und Softwareprodukte, die mit einem anderen Gerät oder Netzwerk verbunden werden können:

• Alle Hardware- und Softwareprodukte mit digitalen Elementen, die in der EU verkauft werden
• Einschließlich Remote-Datenverarbeitungslösungen
• Gilt unabhängig davon, wo das Produkt hergestellt wurde
• Umfasst sowohl B2C- als auch B2B-Produkte
• Produkte, die entgeltlich oder kostenlos bereitgestellt werden

Open-Source-Software und der CRA

Die Verwendung von Open-Source-Software befreit ein kommerzielles Produkt nicht von den CRA-Anforderungen. Wenn Sie Open-Source-Komponenten in ein Produkt mit digitalen Elementen integrieren, das Sie auf dem EU-Markt bereitstellen, sind Sie weiterhin für die Einhaltung der Vorschriften verantwortlich – einschließlich Schwachstellenmanagement und SBOM.

Einige rein gemeinschaftsgetriebene Open-Source-Projekte ohne kommerzielle Aktivität fallen nicht unter die direkten CRA-Verpflichtungen. Sobald sie jedoch in ein kommerzielles Produkt mit digitalen Elementen integriert werden, fallen sie in den Verantwortungsbereich des Herstellers.

Bemerkenswerte Ausnahmen

Der CRA sieht einige bemerkenswerte Ausnahmen für stark regulierte Branchen vor, die bereits strenge Cybersicherheitsanforderungen erfüllen müssen – darunter die Automobilindustrie, Medizinprodukte und die Luftfahrt. Darüber hinaus fällt SaaS unter die NIS2-Richtlinie und nicht unter den CRA.

---

Häufig gestellte Fragen

Q1: Muss die SBOM öffentlich zugänglich sein?

Nein. Der CRA verlangt ausdrücklich keine öffentliche Bereitstellung der SBOM. Sie muss jedoch als Teil der technischen Dokumentation geführt und auf Anfrage an Marktüberwachungsbehörden übermittelt werden können. Dies schützt sensible Informationen über die Softwarezusammensetzung vor Wettbewerbern und verhindert, dass Angreifer Schwachstellen leichter identifizieren können.

Q2: Welches SBOM-Format ist für CRA-Compliance erforderlich?

Die TR-03183 fordert ein maschinenlesbares Format – entweder CycloneDX (Version 1.5 oder höher) oder SPDX (Version 2.2.1 oder höher) im JSON- oder XML-Format. CycloneDX wird aufgrund seines Sicherheitsfokus und der nativen VEX-Unterstützung für CRA-Compliance bevorzugt. Beide Formate sind international anerkannt und ermöglichen automatisierte Sicherheitsanalysen.

Q3: Ab wann gilt die SBOM-Pflicht?

Die vollständige Anwendbarkeit des CRA einschließlich der SBOM-Pflicht beginnt am 11. Dezember 2027. Die Meldepflicht für aktiv ausgenutzte Schwachstellen startet bereits am 11. September 2026. Unternehmen sollten jetzt mit der Implementierung beginnen, da die Integration von SBOM-Prozessen in bestehende Entwicklungspipelines erfahrungsgemäß Zeit erfordert.

Q4: Gilt der CRA auch für SaaS-Anwendungen?

Nein. Reine Software-as-a-Service (SaaS) ohne lokale Komponenten fällt unter die NIS2-Richtlinie (EU 2022/2555), nicht unter den CRA. NIS2 enthält keine explizite SBOM-Pflicht, fordert aber Supply-Chain-Sicherheit. Hybride Lösungen mit lokalen Komponenten – etwa Desktop-Apps mit Cloud-Anbindung – können jedoch unter den CRA fallen.

Q5: Müssen Schwachstellen in der SBOM dokumentiert werden?

Nein. Die BSI TR-03183 stellt klar, dass SBOMs keine Schwachstelleninformationen enthalten müssen. Stattdessen sollten separate Formate wie VEX (Vulnerability Exploitability eXchange) oder CSAF (Common Security Advisory Framework) verwendet werden. Diese Trennung ermöglicht eine effizientere Aktualisierung von Schwachstellendaten ohne die gesamte SBOM zu ändern.

Q6: Welche Produkte sind von der SBOM-Pflicht ausgenommen?

Ausgenommen sind SaaS-Anwendungen (fallen unter NIS2), Automotive-Produkte (bereits durch UN R155/R156 reguliert), Medizinprodukte (MDR/IVDR), Luftfahrt- und Verteidigungsprodukte sowie Open-Source-Software unter bestimmten Bedingungen. Die Ausnahme für Open Source gilt nur bei nicht-kommerzieller Entwicklung ohne Support-Verpflichtungen oder finanzielle Vergütung gegenüber den Nutzern.

Q7: Wie tief muss die SBOM-Abhängigkeitsverfolgung sein?

Der CRA fordert mindestens die Top-Level-Abhängigkeiten. Die TR-03183 empfiehlt jedoch eine Verfolgung bis zur ersten externen Komponente. Für effektives Schwachstellenmanagement – wie beim Log4j-Vorfall gezeigt – empfehlen wir die vollständige Erfassung aller transitiven Abhängigkeiten, um versteckte Risiken in der Lieferkette zu identifizieren.

---

Nützliche externe Ressourcen

• EU-Kommission CRA-Implementierungsseite
• BSI Cyber Resilience Act Übersicht
• OpenSSF Kostenloser CRA-Kurs (LFEL1001)
• European Vulnerability Database (EUVD)