Kurzfassung

Dieses Glossar behandelt wesentliche Begriffe des EU Cyber Resilience Act (CRA): SBOM (Software-Stückliste), CycloneDX, SPDX, VEX (Vulnerability Exploitability eXchange), CSAF, CVE, EPSS, KEV, TR-03183, ENISA-Meldungen, CE-Kennzeichnung, harmonisierte Normen, Benannte Stellen, Risikobewertung, Anforderungen an technische Unterlagen und Konformitätsbewertung. Verwenden Sie diese Referenz bei der Vorbereitung auf die CRA-Compliance vor der Frist im Dezember 2027.

CRA-Konformitäts-Glossar

Wesentliche Terminologie zum Verständnis des EU Cyber Resilience Act, der Sicherheitsstandards für Software-Lieferketten und der Compliance-Anforderungen.

A

Anhang VII

CRA-Anhang VII legt den Mindestinhalt der EU-Konformitätserklärung fest, die Hersteller für Produkte mit digitalen Elementen ausstellen müssen. Enthält Produktidentifikation, Herstellerangaben, angewendete Normen und die Unterschrift eines bevollmächtigten Vertreters.

CRA-Anhang

Artikel 13 - Pflichten der Hersteller

CRA Artikel 13 legt die grundlegenden Herstellerpflichten fest: Security by Design, SBOM-Pflege, Schwachstellenbehandlung, Bereitstellung von Sicherheitsupdates über den gesamten Produktlebenszyklus und Aufbewahrung der technischen Dokumentation für mindestens 10 Jahre.

CRA-Artikel

Artikel 14 - Meldepflichten

CRA Artikel 14 verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden (Frühwarnung), 72 Stunden (Detailbericht) und 14 Tagen (Abschlussbericht) an ENISA zu melden. Schwerwiegende Vorfälle folgen demselben Schema, jedoch mit einer 30-Tage-Frist für den Abschlussbericht.

CRA-Artikel

C

CE-Kennzeichnung

Europäisches Konformitätszeichen, das die Einhaltung der EU-Gesetzgebung anzeigt. Unter CRA müssen Produkte mit digitalen Elementen die CE-Kennzeichnung tragen, um legal im EU-Markt verkauft zu werden. Erfordert die Durchführung der Konformitätsbewertung und EU-Konformitätserklärung.

CRA-Anforderung

Konformitätsbewertung

Verfahren zur Überprüfung, ob ein Produkt die wesentlichen CRA-Cybersicherheitsanforderungen erfüllt. Standardprodukte können die Selbstbewertung (Modul A) nutzen, während Wichtige Klasse I, Klasse II und Kritische Produkte eine Bewertung durch Dritte bei benannten Stellen erfordern.

CRA-Anforderung

CRA - Cyberresilienzgesetz

EU-Verordnung 2024/2847 zur Festlegung verbindlicher Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (PDEs), die in der Europäischen Union verkauft werden. In Kraft getreten am 10. Dezember 2024. Hauptpflichten gelten ab 11. Dezember 2027. Umfasst Hardware- und Softwareprodukte mit Netzwerkkonnektivität.

EU-Verordnung

CSAF - Gemeinsames Rahmenwerk für Sicherheitshinweise

OASIS-Standard für maschinenlesbare Sicherheitshinweise. Ermöglicht die automatisierte Verarbeitung von Schwachstellenmeldungen. Wird für koordinierte Schwachstellenoffenlegung (CVD) und ENISA-Berichterstattung unter CRA-Anforderungen verwendet.

OASIS-Standard

CVD - Koordinierte Offenlegung von Schwachstellen

Prozess zur verantwortungsvollen Offenlegung von Sicherheitslücken gegenüber Anbietern vor der öffentlichen Bekanntgabe. CRA Artikel 13(8) verlangt von Herstellern, CVD-Richtlinien einzuführen und zu veröffentlichen, einschließlich Sicherheitskontaktinformationen.

CRA-Anforderung

CVE - Häufige Schwachstellen und Gefährdungen

Standardisierter Identifikator für öffentlich bekannte Cybersicherheitslücken (z. B. CVE-2024-12345). Verwaltet von MITRE Corporation. Weltweit verwendet für Schwachstellenverfolgung, Offenlegung und Behebungskoordination.

Industriestandard

CVSS - Gemeinsames Bewertungssystem für Schwachstellen

Industriestandard zur Bewertung der Schwachstellenschwere auf einer Skala von 0-10. CVSS 4.0 ist die neueste Version. Bietet Basis-, zeitliche und Umgebungsmetriken. Kritisch (9.0-10.0), Hoch (7.0-8.9), Mittel (4.0-6.9), Niedrig (0.1-3.9).

FIRST.org-Standard

CycloneDX

OWASP-Standard zur Erstellung von Software-Stücklisten (SBOMs) und verwandten Artefakten. Unterstützt SBOM, VEX, HBOM, SaaSBOM und mehr. Version 1.5+ empfohlen. Von BSI TR-03183 als bevorzugtes Format für CRA-Compliance referenziert.

OWASP-Standard

Kritisches Produkt — CRA Anhang IV

Produkte mit digitalen Elementen, die wesentliche Cybersicherheitsfunktionen für andere Produkte, Netzwerke oder Dienste erfüllen. In CRA Anhang IV aufgeführt, umfassen diese Hardware-Sicherheitsmodule (HSMs), Smartcard-Leser, sichere Elemente und Hardwaregeräte mit Sicherheitsboxen. Kritische Produkte erfordern eine europäische Cybersicherheitszertifizierung gemäß einem anwendbaren Schema oder — falls kein Schema existiert — eine Konformitätsbewertung durch Dritte bei einer benannten Stelle.

CRA-Klassifizierung

D

Standard-Produktkategorie

Produkte mit digitalen Elementen, die nicht unter die in den CRA-Anhängen III und IV definierten Kategorien „Wichtig“ oder „Kritisch“ fallen. Standardprodukte können die Konformitätsbewertung durch interne Kontrolle (Selbstbewertung) des Herstellers gemäß CRA Anhang VIII ohne Beteiligung Dritter durchlaufen. Dies umfasst die überwiegende Mehrheit kommerzieller Software und Hardware.

CRA-Klassifizierung

Vertriebspartner

Jede Einrichtung in der Lieferkette, die nicht Hersteller oder Importeur ist und ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt. Händler müssen vor der Bereitstellung prüfen, ob das Produkt die CE-Kennzeichnung trägt und die EU-Konformitätserklärung beigefügt ist. Wenn ein Händler das Produkt verändert, wird er nach dem CRA zum Hersteller.

CRA-Rolle

E

ENISA - Agentur der Europäischen Union für Cybersicherheit

EU-Agentur verantwortlich für Cybersicherheitspolitik und Incident-Koordination. Unter CRA müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an ENISA melden und schwere Vorfälle innerhalb von 72 Stunden. Meldepflicht beginnt am 11. September 2026.

EU-Agentur

EPSS - System zur Vorhersage von Exploit-Wahrscheinlichkeit

FIRST.org-Modell zur Schätzung der Wahrscheinlichkeit (0-100%), dass eine Schwachstelle in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird. Wird für risikobasierte Schwachstellenpriorisierung zusammen mit CVSS verwendet. Höherer EPSS = höhere Priorität für Behebung.

FIRST.org-Standard

EU-Konformitätserklärung

Formelles Dokument, das erklärt, dass ein Produkt die anwendbare EU-Gesetzgebung einschließlich CRA einhält. Muss vom Hersteller oder bevollmächtigten Vertreter unterzeichnet werden. Erforderlich für CE-Kennzeichnung. Muss auf anwendbare harmonisierte Normen verweisen.

CRA-Anforderung

H

HBOM - Hardware-Stückliste

Maschinenlesbares Inventar von Hardware-Komponenten in einem Produkt, einschließlich Prozessoren, Speicher, integrierte Schaltkreise und Firmware. Ergänzt SBOM für vollständige Produkttransparenz. CycloneDX unterstützt das HBOM-Format.

CycloneDX-Format

Harmonisierte Normen

Europäische Normen, die von anerkannten Normungsorganisationen (CEN, CENELEC, ETSI) verabschiedet und im EU-Amtsblatt referenziert werden. Produkte, die harmonisierten Normen entsprechen, profitieren von einer Konformitätsvermutung mit den entsprechenden wesentlichen CRA-Anforderungen, was die Konformitätsbewertung vereinfacht.

CRA-Konzept

I

Importeur

Eine in der EU ansässige Einrichtung, die ein Produkt mit digitalen Elementen eines Herstellers außerhalb der EU auf dem europäischen Markt in Verkehr bringt. Importeure müssen überprüfen, ob der Hersteller die Konformitätsbewertung durchgeführt hat, die CE-Kennzeichnung angebracht ist und die technische Dokumentation verfügbar ist. Sie haften gemeinsam für nicht konforme Produkte.

CRA-Rolle

Wichtiges Produkt (Klasse I) — CRA Anhang III, Teil I

Produkte mit digitalen Elementen, die eine cybersicherheitsrelevante Funktion erfüllen oder ein erhöhtes Risiko bergen. Klasse I umfasst Identitätsmanagementsysteme, VPNs, Netzwerkmanagement-Tools, SIEM-Systeme, Boot-Manager und andere in CRA Anhang III Teil I aufgeführte Kategorien. Hersteller müssen entweder harmonisierte Normen anwenden, die alle wesentlichen Anforderungen abdecken (was eine Selbstbewertung ermöglicht), oder eine Konformitätsbewertung durch Dritte bei einer benannten Stelle durchlaufen.

CRA-Klassifizierung

Wichtiges Produkt (Klasse II) — CRA Anhang III, Teil II

Produkte mit digitalen Elementen, die kritische Cybersicherheitsfunktionen erfüllen und ein erhebliches Risiko bergen. Klasse II umfasst Betriebssysteme, Hypervisoren, Firewalls, Intrusion-Detection-Systeme, Mikrocontroller, industrielle Automatisierungssysteme und andere in CRA Anhang III Teil II aufgeführte Kategorien. Diese Produkte erfordern stets eine Konformitätsbewertung durch Dritte bei einer benannten Stelle, unabhängig davon, ob harmonisierte Normen existieren.

CRA-Klassifizierung

K

KEV - Bekannte ausgenutzte Schwachstellen

CISAs maßgeblicher Katalog von Schwachstellen, die aktiv in freier Wildbahn ausgenutzt werden. Höchste Priorität für die Behebung, da sie bestätigte reale Bedrohungen darstellen. Bundesbehörden müssen KEV-Schwachstellen innerhalb festgelegter Fristen beheben.

CISA-Katalog

M

Hersteller

Die Einrichtung, die ein Produkt mit digitalen Elementen entwickelt oder herstellt und unter eigenem Namen oder eigener Marke auf dem EU-Markt in Verkehr bringt. Hersteller tragen die Hauptpflichten des CRA: Risikobeurteilungen durchführen, SBOMs pflegen, Schwachstellen behandeln, Sicherheitsupdates für mindestens fünf Jahre bereitstellen und ausgenutzte Schwachstellen an die ENISA melden.

CRA-Rolle

N

NVD - Nationale Schwachstellendatenbank

US-Regierungs-Repository für Schwachstellendaten, gepflegt von NIST. Aufgebaut auf CVE-Identifikatoren. Bietet CVSS-Scores, CPE-Informationen (betroffenes Produkt), CWE-Klassifizierungen und Behebungshinweise.

NIST-Datenbank

Benannte Stelle

Unabhängige Konformitätsbewertungsstelle, die von einem EU-Mitgliedstaat benannt wurde, um zu beurteilen, ob Produkte die regulatorischen Anforderungen erfüllen. Erforderlich für die Konformitätsbewertung durch Dritte von Wichtige Klasse I, Klasse II und Kritische Produkte gemäß CRA Anhang III und IV.

CRA-Anforderung

O

OSV.dev - Open-Source-Schwachstellendatenbank

Open-Source-Schwachstellendatenbank, gepflegt von Google. Aggregiert Sicherheitshinweise von GitHub (GHSA), Go, Rust, PyPI und 15+ Ökosystemen in eine einzige abfragbare API. CRA Evidence nutzt OSV.dev als sekundäre Schwachstellenquelle neben NVD, um Hinweise zu erfassen, die ökosystemspezifische Datenbanken verfolgen, bevor sie CVE-IDs erhalten.

Vulnerability Database

P

PDE - Produkt mit digitalen Elementen

Jedes Software- oder Hardware-Produkt mit einer Verbindung (direkt oder indirekt) zu einem anderen Gerät oder Netzwerk. Der Kernbereich der CRA-Verordnung. Umfasst IoT-Geräte, Industrieausrüstung, Unterhaltungselektronik und eigenständige Software.

CRA-Definition

PURL - Paket-URL

Standardisiertes Format zur Identifizierung von Softwarepaketen über Ökosysteme hinweg (z. B. pkg:npm/lodash@4.17.21). Wird in SBOMs zur eindeutigen Identifizierung von Komponenten verwendet. Ermöglicht automatisiertes Schwachstellenmatching und Lizenzcompliance.

Industriestandard

R

Risikobewertung

Systematischer Prozess zur Identifizierung, Analyse und Bewertung von Cybersicherheitsrisiken im Zusammenhang mit einem Produkt mit digitalen Elementen. Vorgeschrieben durch CRA Artikel 13(2) und muss in der technischen Dokumentation dokumentiert werden. Umfasst Bedrohungen, Schwachstellen, potenzielle Auswirkungen und Risikominderungsmaßnahmen über den gesamten Produktlebenszyklus.

CRA-Anforderung

S

SBOM - Software-Stückliste

Formales, maschinenlesbares Inventar von Softwarekomponenten und Abhängigkeiten, einschließlich Versionen, Lizenzen und Beziehungen. Erforderlich durch CRA Artikel 13(4) für Schwachstellenmanagement und Lieferkettentransparenz. Kann im CycloneDX- oder SPDX-Format sein.

CRA-Anforderung TR-03183

SPDX - Software-Paketdatenaustausch

ISO/IEC 5962:2021 Standard zur Kommunikation von Software-Stücklisteninformationen. Entwickelt von der Linux Foundation. Weit verbreitet für Lizenzcompliance und Schwachstellenverfolgung. Version 2.2.1+ empfohlen für CRA-Compliance.

ISO-Standard

T

Technische Dokumentation

Vollständiges Dokumentationspaket zum Nachweis der CRA-Konformität. Umfasst Risikobewertung, SBOM, Sicherheitsdesign-Dokumentation, Schwachstellenbehandlungsverfahren, Testergebnisse und EU-Konformitätserklärung. Muss 10 Jahre oder die Produktlebensdauer aufbewahrt werden (je nachdem, was länger ist).

CRA-Anforderung

TR-03183

Technische Richtlinie des deutschen BSI (Bundesamt für Sicherheit in der Informationstechnik) mit detaillierten Anforderungen für die SBOM-Erstellung und -Verwaltung. Weithin als Best Practice für die Einhaltung von CRA Artikel 13 referenziert. Spezifiziert minimale SBOM-Felder, Formate und Aktualisierungsanforderungen.

BSI-Richtlinie

V

VEX - Austausch zur Ausnutzbarkeit von Schwachstellen

Dokument, das den Ausnutzbarkeitsstatus von Schwachstellen in einem bestimmten Produkt kommuniziert. Gibt an, ob ein CVE Ihr Produkt betrifft (betroffen, nicht betroffen, behoben, in Untersuchung). Hilft nachgelagerten Benutzern, Alert-Fatigue durch Fehlalarme zu reduzieren.

CycloneDX/CSAF-Format

Bereit für die CRA-Compliance?

CRA Evidence hilft Ihnen bei der Verwaltung von SBOMs, der Nachverfolgung von Schwachstellen und der Erstellung prüfungsfertiger Dokumentation.