CRA-Komponenten-Cockpit — Tech-Stack-Inventur für den Cyber Resilience Act
Leitet aus dem beim Scan erkannten Tech-Stack eine SBOM-artige Komponentenliste ab, markiert potenziell veraltete Komponenten mit CVE-Hinweisen (Heuristik), exportiert CycloneDX und führt die CRA-Fristen mit. Eine Vorbereitungshilfe — keine Konformitätszusicherung.
Der Cyber Resilience Act (CRA) verlangt von Herstellern von Produkten mit digitalen Elementen unter anderem eine nachvollziehbare Übersicht ihrer Komponenten und einen Umgang mit Schwachstellen. Das CRA-Komponenten-Cockpit gibt Ihnen einen praktischen Einstieg: Es leitet aus dem beim Website-Scan erkannten Tech-Stack — Server, CMS, Plugins, Bibliotheken, Frameworks, CDN, WAF, Zahlungs- und Consent-Dienste — eine SBOM-artige Komponentenliste ab und weist potenziell veraltete oder am Ende ihres Lebenszyklus stehende Komponenten mit CVE-Hinweisen aus. Wichtig: Diese Einschätzung beruht auf einer Offline-Heuristik aus erkannten Versionen, nicht auf einem echten Abhängigkeits-Scan Ihres Quellcodes — Distributions-Backports und individuelle Patches kann sie nicht erkennen.
Funktionen von CRA-Komponenten-Cockpit — Tech-Stack-Inventur für den Cyber Resilience Act
Komponenten-Inventur aus dem Scan
Aus dem beim Website-Scan erkannten Tech-Stack entsteht automatisch eine Komponentenliste — gegliedert nach Server, CMS, Plugin, Bibliothek, Framework, CDN, WAF, Zahlung, Consent und Schrift, jeweils mit erkannter Version, soweit sichtbar.
Veraltungs-, EoL- und CVE-Hinweise (Heuristik)
Komponenten, deren erkannte Version als potenziell veraltet oder am Ende ihres Lebenszyklus (EoL) gilt, werden hervorgehoben — mit Schweregrad, möglichen CVE-Hinweisen und einem etwaigen “fixed in”-Vermerk. Eine Heuristik, kein verbindliches Schwachstellen-Gutachten.
CycloneDX-Export (SBOM-artige Liste)
Exportieren Sie die Komponentenliste als CycloneDX-1.5-JSON (.cdx.json) — ein offenes, weit genutztes SBOM-Format. So haben Sie eine maschinenlesbare, SBOM-artige Komponentenliste als Arbeitsgrundlage und Diskussionsbasis.
Anwendungsbereich: gilt der CRA für Sie?
Eine Frage zu Beginn klärt, ob Sie ein Produkt mit digitalen Elementen in Verkehr bringen — Desktop-Programm, mobile App, Browser-Erweiterung, Gerät mit eigener Software, On-Premise-Variante oder Datenfernverarbeitung als Produktbestandteil. Wer ausschließlich eine Website oder reines Software as a Service betreibt, antwortet mit Nein: dann blendet das Cockpit die Fristen aus und verschickt keine Frist-Erinnerungen mehr. Die Komponentenliste bleibt in jedem Fall nutzbar.
CRA-Fristen mit Eskalations-Banner
Das Cockpit führt die beiden zentralen CRA-Stichtage mit: die Meldepflichten ab dem 11.09.2026 und die volle Anwendung ab dem 11.12.2027. Ein Banner eskaliert von Hinweis über Warnung bis kritisch, je näher eine Frist rückt; ein bereits verstrichener Termin wird als in Kraft ausgewiesen statt dauerhaft rot zu leuchten.
Bestätigen & Notizen je Komponente
Sie können einen Hinweis je Komponente bestätigen (etwa nach geprüftem Distributions-Backport) und eine Notiz hinterlegen — bestätigte Einträge bleiben sichtbar, lassen sich aber rückgängig machen. So dokumentieren Sie Ihren Prüfstand nachvollziehbar.
Überblick über alle Websites
Eine Übersicht fasst Komponentenzahl, Anzahl potenziell veralteter Komponenten und den höchsten Schweregrad je Website zusammen — damit Sie sehen, wo der Vorbereitungsbedarf am größten ist.
So funktioniert es
Website scannen lassen
XICTRAQ erkennt beim regulären Scan den Tech-Stack Ihrer Website. Daraus leitet das Cockpit eine SBOM-artige Komponentenliste ab — ohne Zugriff auf Ihren Quellcode oder Ihre Abhängigkeitsdateien.
Hinweise prüfen und einordnen
Sehen Sie pro Komponente die erkannte Version, Veraltungs- und EoL-Hinweise sowie mögliche CVE-Verweise. Wo ein Distributions-Backport oder ein individueller Patch vorliegt, bestätigen Sie den Hinweis mit Notiz.
Exportieren und Fristen wahren
Exportieren Sie die Komponentenliste als CycloneDX-JSON für Ihre Unterlagen und behalten Sie über das Fristen-Banner die CRA-Stichtage 11.09.2026 und 11.12.2027 im Blick.
Die beiden Stichtage im Blick
Ein Fristen-Banner im Cockpit eskaliert von Hinweis über Warnung bis kritisch, je näher der jeweilige Stichtag rückt.
Ab diesem Stichtag gelten die Melde- und Benachrichtigungspflichten des Cyber Resilience Act für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle.
Ab diesem Stichtag gelten die Anforderungen des Cyber Resilience Act in vollem Umfang für betroffene Produkte mit digitalen Elementen.
Komponenten-Kategorien aus dem Tech-Stack
Das CRA-Komponenten-Cockpit leitet die Komponentenliste aus dem von außen erkannten Tech-Stack ab und beurteilt Versionen mit einer Offline-Heuristik. Es führt keinen echten Abhängigkeits-Scan durch (etwa über eine composer.lock) und fragt keine Schwachstellen-Datenbank live ab. Markierungen sind „potenziell betroffen“, können durch Distributions-Backports oder individuelle Patches unzutreffend sein und sind als Prüfhinweis zu verstehen. Der Export ist eine SBOM-artige Komponentenliste, keine vollständige Software-Stückliste. Eine Konformität mit dem Cyber Resilience Act wird nicht zugesichert; maßgeblich sind die geltenden Vorgaben und eine Prüfung durch Fachkundige.
Häufige Fragen
Macht mich das CRA-Komponenten-Cockpit CRA-konform?
Was ist der Cyber Resilience Act (CRA)?
Wie zuverlässig sind die CVE- und Veraltungs-Hinweise?
Ist der CycloneDX-Export eine echte SBOM?
Welche Komponenten erkennt das Cockpit?
In welchem Plan ist das CRA-Komponenten-Cockpit enthalten?
Der Security-Scan erkennt den Tech-Stack, aus dem das Cockpit die Komponentenliste ableitet — plus SSL, Security-Header und Third-Party-Skripte als laufende Belege.
Datenschutz und CRA greifen ineinander: Der DSGVO-Check prüft Tracker, Cookie-Consent und Pflichtseiten — eine sinnvolle Ergänzung zu Ihrer CRA-Vorbereitung.
CRA und NIS2 verfolgen verwandte Ziele bei Cybersicherheit und Lieferkette. Das NIS2-Readiness-Modul strukturiert Ihren Vorbereitungsstand über zehn Maßnahmenbereiche.