A
Abhängigkeit (Dependency)
Eine Abhängigkeit ist eine externe Softwarekomponente, die ein Produkt zur Laufzeit oder beim Build benötigt. Man unterscheidet direkte Abhängigkeiten (vom Entwickler explizit eingebunden) und transitive Abhängigkeiten (indirekt über andere Pakete mitgezogen). Der CRA verlangt in Anhang I Teil 2 Nr. 1 mindestens die Dokumentation der Top-Level-Abhängigkeiten in der SBOM.
Anhang I / Anhang II (CRA Annexes I & II)
Anhang I der Verordnung (EU) 2024/2847 definiert die wesentlichen Cybersicherheitsanforderungen an Produkte mit digitalen Elementen. Teil 1 betrifft Sicherheitseigenschaften (Vertraulichkeit, Integrität, Verfügbarkeit), Teil 2 die Schwachstellenbehandlung — einschließlich der SBOM-Pflicht (Nr. 1). Anhang II listet die Informations- und Dokumentationspflichten des Herstellers gegenüber dem Nutzer auf, darunter Kontaktdaten für Schwachstellenmeldungen und den definierten Unterstützungszeitraum.
B
BOM (Bill of Materials)
Eine Bill of Materials ist eine strukturierte Stückliste aller Bestandteile eines Produkts. Der Begriff stammt aus der Fertigungsindustrie und wurde in den 2010er Jahren auf Software übertragen. Im Softwarebereich spricht man von SBOM (Software BOM), im Hardwarebereich von HBOM (Hardware BOM). Der CRA macht die SBOM zur verpflichtenden Dokumentation für alle Produkte mit digitalen Elementen in der EU.
BSI (Bundesamt für Sicherheit in der Informationstechnik)
Das BSI ist die zentrale Cybersicherheitsbehörde Deutschlands mit Sitz in Bonn. Im CRA-Kontext fungiert es als nationales CSIRT, das Schwachstellenmeldungen von Herstellern entgegennimmt und an die ENISA weiterleitet. Deutsche Hersteller melden aktiv ausgenutzte Schwachstellen primär an das BSI (24-Stunden-Frist für die Frühwarnung).
C
CE-Konformität (CE Conformity)
Die CE-Kennzeichnung bestätigt im CRA-Kontext, dass ein Produkt mit digitalen Elementen alle Anforderungen aus Anhang I erfüllt — einschließlich der SBOM-Erstellung. Ohne vollständige technische Dokumentation (die die SBOM umfasst) darf kein CE-Zeichen angebracht werden. Produkte ohne CE-Kennzeichnung dürfen ab dem 11. Dezember 2027 nicht mehr in der EU in Verkehr gebracht werden.
CPE (Common Platform Enumeration)
CPE ist ein strukturiertes Benennungsschema der NIST zur Identifikation von IT-Produkten, Betriebssystemen und Anwendungen. Das Format lautet cpe:2.3:a:vendor:product:version (z. B. cpe:2.3:a:apache:log4j:2.14.1). In SBOMs dient CPE als Identifikator, um Komponenten gegen die NVD abzugleichen. In modernen SBOMs wird Package-URL (purl) bevorzugt, da es ökosystemspezifischer und granularer ist.
CRA (Cyber Resilience Act)
Die Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 legt horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest. Sie ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab 11. September 2026, die vollständige Anwendung einschließlich SBOM-Pflicht ab 11. Dezember 2027. Bei Verstößen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.
CSIRT (Computer Security Incident Response Team)
Ein CSIRT ist eine spezialisierte Einheit zur Bearbeitung von Cybersicherheitsvorfällen. Unter dem CRA müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an das zuständige nationale CSIRT melden (Art. 14 CRA). In Deutschland ist das BSI zuständig, auf EU-Ebene koordiniert die ENISA.
CVE (Common Vulnerabilities and Exposures)
CVE ist das weltweit genutzte Bezeichnungssystem für Sicherheitslücken, verwaltet von der MITRE Corporation und finanziert durch CISA. Jede Schwachstelle erhält eine eindeutige Kennung im Format CVE-JJJJ-NNNNN (z. B. CVE-2021-44228 für Log4Shell). SBOM-Management-Tools gleichen Komponentenlisten automatisch gegen CVE-Datenbanken ab, um verwundbare Abhängigkeiten zu identifizieren.
CycloneDX
CycloneDX ist ein SBOM-Format der OWASP Foundation, erstmals 2017 veröffentlicht, aktuell in Version 1.6. Es unterstützt Software-, Hardware-, Service- und ML-Modell-Inventare und bietet eine native VEX-Integration (Vulnerability Exploitability eXchange). CycloneDX ist im Cloud-nativen und DevSecOps-Umfeld das verbreitetste SBOM-Format. Der CRA erkennt es als „gängiges und maschinenlesbares Format" an.
D
Dependency-Track
Dependency-Track ist eine Open-Source-Plattform der OWASP Foundation zur zentralen Verwaltung und Analyse von SBOMs. Die Plattform importiert CycloneDX- und SPDX-Dokumente, gleicht Komponenten automatisch gegen die NVD, OSV und weitere Schwachstellendatenbanken ab und bietet Policy-basierte Alerts. Sie ist die am weitesten verbreitete Open-Source-Lösung für organisationsweites SBOM-Management.
E
ENISA (Agentur der Europäischen Union für Cybersicherheit)
Die ENISA mit Sitz in Athen koordiniert die Cybersicherheit auf EU-Ebene. Unter dem CRA betreibt sie die zentrale Meldeplattform für Schwachstellen. Hersteller müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden als Frühwarnung und innerhalb von 72 Stunden als vollständige Meldung an die ENISA übermitteln (Art. 14 CRA). Die ENISA leitet relevante Informationen an die nationalen CSIRTs weiter.
H
Hersteller (Manufacturer)
Im Sinne des CRA (Art. 3 Nr. 13) ist ein Hersteller jede natürliche oder juristische Person, die ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke in Verkehr bringt. Der Hersteller trägt die Hauptverantwortung für SBOM-Erstellung, CE-Konformitätsbewertung, Schwachstellenbehandlung und Bereitstellung von Sicherheitsupdates über den gesamten Unterstützungszeitraum.
I
Importeur (Importer)
Ein Importeur ist eine in der EU ansässige Person, die ein Produkt mit digitalen Elementen eines Drittstaat-Herstellers in der EU in Verkehr bringt (Art. 3 Nr. 15 CRA). Importeure müssen sicherstellen, dass der Hersteller das Konformitätsbewertungsverfahren durchgeführt hat und die technische Dokumentation einschließlich SBOM vorliegt. Bringt ein Importeur ein Produkt unter eigenem Namen in Verkehr, gilt er selbst als Hersteller.
M
Meldepflicht (Reporting Obligation)
Der CRA (Art. 14) schreibt eine zweistufige Meldepflicht für aktiv ausgenutzte Schwachstellen vor: Frühwarnung innerhalb von 24 Stunden und vollständige Meldung mit technischer Analyse innerhalb von 72 Stunden an das zuständige CSIRT und die ENISA. Diese Pflicht gilt bereits ab dem 11. September 2026 — 15 Monate vor der vollen CRA-Anwendung. Eine aktuelle SBOM ist für die schnelle Identifikation betroffener Produkte operativ unverzichtbar.
N
NVD (National Vulnerability Database)
Die NVD ist die vom US-amerikanischen NIST gepflegte Schwachstellendatenbank. Sie reichert CVE-Einträge mit CVSS-Scores (Schweregradbewertung), CPE-Zuordnungen und Referenzen an. SBOM-Management-Tools wie Dependency-Track gleichen Komponentenlisten automatisch gegen die NVD ab. Seit 2024 kämpft die NVD mit einem Analyserückstau, weshalb ergänzende Quellen wie die OSV-Datenbank an Bedeutung gewinnen.
O
Open-Source-Steward
Der Open-Source-Steward ist eine vom CRA (Art. 3 Nr. 14) neu geschaffene Rolle für juristische Personen — typischerweise Stiftungen wie die Apache Software Foundation, die Eclipse Foundation oder die Linux Foundation — die die Entwicklung von Open-Source-Software systematisch fördern. Stewards unterliegen leichteren Pflichten als Hersteller: Sie müssen eine Cybersicherheitspolitik dokumentieren und mit Marktüberwachungsbehörden kooperieren, sind aber von der CE-Konformitätsbewertung befreit.
P
Package-URL (purl)
Package-URL ist ein standardisiertes URI-Schema zur eindeutigen Identifikation von Softwarepaketen über Paketmanager und Ökosysteme hinweg. Das Format lautet pkg:type/namespace/name@version (z. B. pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1). Purl wird von CycloneDX und SPDX gleichermaßen unterstützt und ist in modernen SBOMs der bevorzugte Identifikator gegenüber dem älteren CPE-Schema.
Produkt mit digitalen Elementen (Product with Digital Elements)
Der CRA-Kernbegriff (Art. 3 Nr. 1) bezeichnet jedes Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich separat in Verkehr gebrachter Komponenten. Erfasst sind eigenständige Software, Firmware, Betriebssysteme und Hardware mit eingebetteter Software. Ausgenommen sind rein cloudbasierte SaaS-Dienste ohne lokale Komponente sowie Produkte, die bereits sektorspezifisch reguliert sind (Medizinprodukte, Fahrzeuge, Luftfahrt).
S
SBOM (Software Bill of Materials)
Eine Software Bill of Materials ist eine strukturierte, maschinenlesbare Liste aller Komponenten eines Softwareprodukts — einschließlich Name, Version, Lieferant, Lizenz, kryptographischem Hashwert und Abhängigkeitsbeziehungen. Der CRA (Verordnung (EU) 2024/2847, Anhang I Teil 2 Nr. 1) macht die SBOM ab dem 11. Dezember 2027 zur Pflicht für alle Produkte mit digitalen Elementen in der EU. Die gängigen Formate sind CycloneDX (OWASP) und SPDX (Linux Foundation, ISO/IEC 5962:2021).
SPDX (Software Package Data Exchange)
SPDX ist ein SBOM-Format der Linux Foundation, standardisiert als ISO/IEC 5962:2021. Es bietet die detaillierteste Lizenz- und Urheberrechtsdokumentation aller SBOM-Formate und ist das native Format des Yocto-Embedded-Build-Systems. SPDX 3.0 (veröffentlicht April 2024) hat die Struktur modularisiert und eine eigene Security-Profil-Extension eingeführt, die VEX-Informationen nativ abbilden kann.
T
Top-Level-Abhängigkeit (Top-Level Dependency)
Eine Top-Level-Abhängigkeit ist eine Komponente, die direkt vom Hersteller in das Produkt eingebunden wird — im Gegensatz zu transitiven Abhängigkeiten, die indirekt mitgezogen werden. Der CRA verlangt als Minimum die Dokumentation der Top-Level-Abhängigkeiten in der SBOM (Anhang I Teil 2 Nr. 1). In der Praxis reicht diese Mindestanforderung für effektives Schwachstellenmanagement nicht aus, da kritische CVEs häufig in tieferen Abhängigkeitsebenen liegen.
Transitive Abhängigkeit (Transitive Dependency)
Eine transitive Abhängigkeit ist eine Softwarekomponente, die nicht direkt eingebunden wird, sondern als Abhängigkeit einer direkten Abhängigkeit in das Projekt gelangt. Moderne Projekte haben typischerweise 5- bis 20-mal mehr transitive als direkte Abhängigkeiten. Log4Shell (CVE-2021-44228) demonstrierte eindrücklich, dass kritische Schwachstellen häufig in transitiven Abhängigkeiten stecken, die dem Entwickler nicht unmittelbar bewusst sind.
U
Unterstützungszeitraum (Support Period)
Der CRA (Art. 13 Abs. 8) verpflichtet Hersteller, Sicherheitsupdates für die erwartete Nutzungsdauer des Produkts bereitzustellen, mindestens jedoch für fünf Jahre ab Inverkehrbringen. Der Unterstützungszeitraum muss auf der Verpackung und in der Begleitdokumentation angegeben werden. Während des gesamten Zeitraums muss die SBOM bei jedem Release aktualisiert und bekannte Schwachstellen über VEX-Dokumente kommuniziert werden.
V
VEX (Vulnerability Exploitability eXchange)
Ein VEX-Dokument ergänzt eine SBOM um die herstellerseitige Einschätzung, ob eine bekannte Schwachstelle in einer Komponente im konkreten Produkt tatsächlich ausnutzbar ist. Die vier definierten Status sind: not affected, affected, fixed und under investigation. VEX wurde von der US-amerikanischen NTIA/CISA konzipiert und ist in CycloneDX nativ integriert. Für SPDX existiert ein separater Workflow über das OpenVEX-Format. VEX verhindert, dass Hersteller bei jeder neuen CVE sofort patchen müssen, wenn die betroffene Funktion im Produkt gar nicht genutzt wird.