CRA-Komponenten-Cockpit

Beim Scan erkennt XICTRAQ Server-Software, CMS, Frameworks, Bibliotheken, CDN, WAF, Zahlungs- und Consent-Komponenten anhand von Server-Headern, Generator-Meta-Tags und eingebundenen Skripten. Genau dieser Tech-Stack ist die einzige Datenquelle des Cockpits. Es liest keine internen Abhängigkeitsdateien aus — es kennt also nur, was eine Website von außen sichtbar macht, und kann tieferliegende Abhängigkeiten nicht sehen.

Die Liste trägt den Zeitpunkt der letzten Tech-Stack-Prüfung (last_tech_check_at). So ist erkennbar, wie aktuell die abgeleiteten Komponenten sind. Ein neuer Scan aktualisiert die Liste; bestehende Bestätigungen bleiben erhalten, solange sich der Schlüssel einer Komponente nicht ändert.

Das Cockpit kennt zehn Kategorien: Server, CMS, Plugin, Framework, Bibliothek, CDN, WAF, Zahlung, Consent und Schrift. Nicht jede Kategorie lässt sich bei jeder Website von außen erkennen — das Cockpit zeigt nur, was der Scan tatsächlich ermittelt hat. Komponenten ohne erkennbare Version (etwa ein CDN) erscheinen ohne Versionsnummer und ohne Versions-Hinweis.

Ein Hinweis (finding) trägt einen Schweregrad von „low“ bis „critical“ und eine eol-Markierung, wenn die Versionsreihe nicht mehr gepflegt wird. Das Cockpit zählt die potenziell veralteten Komponenten und nennt den höchsten vorkommenden Schweregrad (worst_severity) in der Übersicht. Die Begriffe orientieren sich an gängiger Praxis, sind aber keine behördliche oder zertifizierte Einstufung.

Wo die Heuristik einer Versionsreihe bekannte Schwachstellen zuordnet, nennt der Hinweis die CVE-Kennungen mit Link zur öffentlichen Detailseite, eine empfohlene Zielversion (fixed_in) und gegebenenfalls einen Advisory-Link des Herstellers. Pro Software wird nur das schwerste passende Finding angezeigt. Die zugeordneten CVEs beziehen sich auf die Versionsreihe als Ganzes und müssen nicht zwingend Ihre konkrete Installation betreffen.

Versions- und CVE-Hinweise erzeugt die Heuristik nur für eine kuratierte Liste von acht weit verbreiteten Software-Familien, deren Version eine Website typischerweise nach außen preisgibt: PHP, nginx, Apache httpd und OpenSSL auf der Serverseite, die Website- und Shop-Systeme WordPress und Shopware sowie jQuery und Bootstrap im Frontend. Jede Familie hat eigene Schwellen, unterhalb derer ein Finding mit Schweregrad ausgelöst wird. Alle übrigen erkannten Komponenten erscheinen weiterhin in der Inventur und im Export, erhalten aber keinen Versions- oder CVE-Hinweis. Die Liste ist redaktionell gepflegt und kein vollständiger Schwachstellen-Katalog.

Für Software, die typischerweise aus einer Linux-Distribution stammt — PHP, nginx, Apache httpd und OpenSSL — kennzeichnet das Cockpit den Hinweis zusätzlich mit „Backport möglich“ (distro_backport). Das erinnert daran, dass Distributionen Sicherheitsfixes häufig ohne Versionssprung einspielen und die nach außen sichtbare Version daher kein verlässlicher Patch-Indikator ist. Bei WordPress, jQuery und Bootstrap wird diese Markierung nicht gesetzt, weil dort die Versionsnummer dem Patch-Stand in der Regel direkt folgt.

Über den Export-Endpunkt erhalten Sie eine CycloneDX-1.5-Datei im JSON-Format als Download (Dateiname sbom-<host>.cdx.json). Sie enthält die erkannten Komponenten mit Name und — sofern bekannt — Version und Package-URL (purl im Schema pkg:generic/<name>@<version>). Die Kategorie selbst steht nicht als eigenes Feld in der Datei, sondern bestimmt den CycloneDX-Typ der Komponente: Server, Framework, Bibliothek und CMS werden als „library“ ausgegeben, alle übrigen Kategorien als „application“. Ist einer Komponente ein CVE-Hinweis zugeordnet, hängt der Export ihn als Property „xictraq:cve_hint“ an. Da die Liste aus dem von außen sichtbaren Tech-Stack abgeleitet ist, kann sie tieferliegende Abhängigkeiten nicht abbilden — ergänzen Sie sie bei Bedarf mit Ihren internen Stückdaten.

Sie beantworten „Bringen Sie ein Produkt mit digitalen Elementen in Verkehr?“ mit ja, nein oder noch offen. Bei „ja“ wählen Sie zusätzlich die zutreffenden Produktarten aus sechs Möglichkeiten: Desktop-Programm zum Herunterladen, mobile App, Browser-Erweiterung, Gerät mit eigener Software oder Firmware, Datenfernverarbeitung als fester Bestandteil eines Produkts, oder Software, die Kunden selbst betreiben (On-Premise). Die Angabe gilt für Ihr Konto, nicht je Website, und ist jederzeit änderbar. Solange die Frage offen ist, zeigt das Cockpit die Fristen weiter an und weist ausdrücklich darauf hin, dass der Anwendungsbereich noch nicht geklärt ist.

Antworten Sie mit „nein“, verschwinden die Fristen-Kacheln aus dem Cockpit, und der tägliche Erinnerungs-Cron überspringt Ihr Konto vollständig — wer keine Produkte mit digitalen Elementen in Verkehr bringt, hat die CRA-Pflichten nicht, und für den ist eine CRA-Frist keine Nachricht wert. Die Komponenten-Inventur, die Veraltungs-Hinweise und der CycloneDX-Export bleiben davon unberührt: sie sind auch ohne CRA-Pflicht nützlich, um zu wissen, was auf Ihrer Website läuft.

Das Cockpit führt zwei Termine: den Beginn der Melde- und Berichtspflichten (11.09.2026) und die volle Anwendung der Verordnung (11.12.2027). Zu jedem Termin zeigt das Cockpit die verbleibenden Tage (days_until).

Ein Erinnerungs-Cron läuft einmal täglich (06:30 Uhr Serverzeit). Ausgelöst wird ein Alert vom Typ „cra_deadline“ ausschließlich vom Befund: die Website muss mindestens eine Komponente mit dem Schweregrad „high“ oder „critical“ tragen. Eine näher rückende Frist allein meldet nichts — sie gilt für alle Konten gleichzeitig und rückt täglich um genau einen Tag, das ergäbe eine Alarmwelle ohne Handlungsbezug. Fällt die nächste noch ausstehende Frist — seit dem 11.09.2026 die volle Anwendung am 11.12.2027 — zusätzlich in eine Stufe von 90, 30 oder 7 Tagen, ergänzt der Cron den verbleibenden Vorlauf im Alert-Text; die Stufe formuliert den Alarm also aus, statt ihn auszulösen. Der Alert geht über die regulären Benachrichtigungs-Kanäle (E-Mail, Slack, Teams und weitere) und wird über einen Alert-Schlüssel dedupiert (Website plus schwerster Schweregrad plus Frist-Stufe), sodass dieselbe Lage nur einmal meldet. Ändert sich die Lage — ein anderer schwerster Schweregrad oder die nächste Stufe —, meldet ein neuer Alert und schließt den vorigen ohne Entwarnung; je Website ist höchstens ein „cra_deadline“-Alert offen. Komponenten mit „medium“- oder „low“-Hinweis lösen keinen Alert aus.

Fällt der Grund weg, löst der Cron den offenen „cra_deadline“-Alert im nächsten Lauf selbst auf — etwa wenn Sie die betroffene Komponente aktualisiert haben, wenn der Schweregrad unter „high“ sinkt oder wenn Sie den Anwendungsbereich mit „nein“ beantworten. Das ist kein Detail: die Alarm-Liste filtert auf offen, nicht auf bestätigt, und ein Alarm, der sich nie schließt, bliebe dort dauerhaft stehen und ließe eine erledigte Lage wie eine laufende aussehen. Gibt die Website nach Ihrer Änderung gar keine Versionsnummer mehr preis, schließt der Cron den Alert nicht: das wäre eine Entwarnung für etwas, das niemand prüfen konnte. Einen solchen Alert schließen Sie von Hand.

Je näher ein Stichtag rückt, desto deutlicher wird der Hinweis. Die Schwelle ist fest hinterlegt: bei mehr als 90 Tagen Vorlauf „info“, ab 90 Tagen oder weniger „warning“, ab 30 Tagen oder weniger „critical“. Ein bereits verstrichener Termin fällt bewusst auf „info“ zurück und wird als „seit N Tagen in Kraft“ ausgewiesen: eine verstrichene Frist ist eine Tatsache, kein Zwischenfall — bliebe sie dauerhaft rot, stumpfte die Anzeige ab und verdeckte echte Befunde. Der Banner ist eine Erinnerung, keine Aussage darüber, ob und welche Pflichten in Ihrem konkreten Fall gelten. Welche CRA-Pflichten Sie betreffen, klären Sie mit fachkundiger Beratung.

Über die Bestätigungs-Funktion markieren Sie eine Komponente per Schlüssel (component_key) als bestätigt und können eine Freitext-Notiz hinterlegen — etwa den Hinweis, dass ein Distro-Backport die Lücke bereits schließt. Das Cockpit speichert den Zeitpunkt (acknowledged_at). Mit dem Undo-Flag heben Sie eine Bestätigung wieder auf. So dokumentieren Sie nachvollziehbar, welche Hinweise Sie bewertet haben.

Die Checkliste fragt sechs Punkte ab: ob Software-Komponenten und Versionen dokumentiert sind (SBOM-artige Liste), ob ein Prozess für Sicherheitsupdates und EoL-Ablösung etabliert ist, ob bekannte Schwachstellen regelmäßig beobachtet und bewertet werden, ob ein Kanal zur Aufnahme von Schwachstellen-Meldungen besteht, ob ein Plan zur Reaktion auf Sicherheitsvorfälle vorhanden ist und ob Drittanbieter-Komponenten vertraglich und technisch geprüft werden. Der Zähler zeigt die bestätigten Punkte (etwa „3/6“). Die Antworten bleiben nur im Browser und werden nicht an den Server übertragen.

Drei Kacheln zeigen die Gesamtzahl der erkannten Komponenten (components_total), die Zahl der Komponenten mit einem Hinweis (outdated_count, beschriftet „Potenziell betroffen“) und den höchsten vorkommenden Schweregrad (worst_severity). Unter der Zahl steht, wie viele der erkannten Komponenten überhaupt eine Versionsnummer preisgeben — nur diese kann die Heuristik prüfen. Gibt es keinen einzigen Hinweis, steht statt eines Schweregrads „keine Hinweise“; nennt keine einzige Komponente eine Version, steht dort „nicht bewertbar“. Denn viele Server verbergen ihre Version bewusst, und dann sagt eine Null nichts über den Patch-Stand aus.

Die Übersicht zeigt je Website die Gesamtzahl der Komponenten (components_total), die Zahl der potenziell veralteten Komponenten (outdated_count), die Zahl der Komponenten mit auslesbarer Version (assessable_count) und den höchsten Schweregrad (worst_severity) sowie den Zeitpunkt der letzten Tech-Stack-Prüfung. Darunter steht die Summe der potenziell veralteten Komponenten über alle Websites — als Priorisierungshilfe für Ihre CRA-Vorbereitung.