Neuigkeiten der Plattform
Funktionen, die in der Plattform in Betrieb gegangen sind, nach Datum. Die Liste stammt aus dem Funktionsregister der Plattform und wird jede Woche aktualisiert. Die Beschreibungen kommen von dort und liegen auf Englisch und Türkisch auch in der Plattform vor.
SBOM-Export (CycloneDX 1.6, SPDX 2.3, SPDX 3.0.1)
Lädt die SBOM in Standardformaten herunter; jeder SPDX-3.0.1-Export wird gegen das offizielle Schema geprüft.
Schwachstellenerkennung aus mehreren Quellen
Gleicht Komponenten mit NVD, OSV, CVE-Program-Einträgen und Herstellermeldungen (Espressif, Mbed TLS) ab; jeder Befund verlinkt auf seine Quellen. Warnt im Panel und in der technischen Dokumentation vor Einträgen, die NVD ohne CPE-Daten lässt (Deferred).
Nachweis aktiver Ausnutzung (CISA KEV, ENISA EUVD)
Eine gefundene Schwachstelle auf der Ausnutzungsliste von CISA KEV oder ENISA EUVD wird vorgezogen und als Kandidat nach Artikel 14 markiert; ihre EUVD-Kennung wird als Quellenlink ergänzt. Die Entscheidung bleibt beim Hersteller.
Interne Schwachstelleneinträge (ohne CVE)
Erfasst Schwachstellen Ihrer eigenen Software ohne CVE unter einer internen Kennung; sie funktionieren in VEX, Sicherheitshinweisen und Artikel 14 wie CVEs.
SBOM-Qualitätsbericht (BSI TR-03183-2)
Zeigt, wie vollständig die SBOM-Felder gemäß BSI TR-03183-2 ausgefüllt sind; keine Konformitätsaussage.
Binär-Härtung und Krypto-Inventar
Zeigt NX, PIE, RELRO und Stack-Schutz sowie Typ und Schwächen der Schlüssel und Zertifikate im Image.
Angewandte Normen und EN 18031
Erfasst die angewandten Normen und die Bewertung der EN-18031-Klauseln und nimmt sie in die technische Dokumentation auf.
Lizenzbeschränkte Komponenten
Dateien von Komponenten, deren Lizenz Reverse Engineering verbietet, werden nicht binär analysiert; nur Paketmetadaten, der Schwachstellenabgleich läuft weiter und die Dokumente nennen den Grund.
Aktualität der Quellen und Ausweichwege
Schwachstellenquellen werden täglich aktualisiert; eine nicht aktualisierbare Quelle wird in der Analyse mit Datum benannt, ein Alarm ausgelöst und bei Nichterreichbarkeit von GitHub die eigene Veröffentlichung der Quelle genutzt.
Konfigurationsabhängiger Schwachstellenfilter (ESP-IDF)
Ergänzt im VEX-Entwurf den Vorschlag 'nicht betroffen' für Schwachstellen in ESP-IDF-Teilen, die laut vollständiger sdkconfig nicht gebaut werden; nur wo eine Option den Code sicher entfernt, die Entscheidung bleibt beim Analysten.
Anhang-I-Anforderungskarten und Analystenentscheidungen
Zeigt den Stand jeder grundlegenden Anforderung (erfüllt, fehlt, manuell, nicht anwendbar) mit Nachweisquelle; der Analyst entscheidet.
Veröffentlichung der Nutzerinformationen (Anhang II)
Zeigt die Nutzerinformationen nach Anhang II in der Vorschau und veröffentlicht sie nach ausdrücklicher Bestätigung auf einer öffentlichen Seite; jede Veröffentlichung ist eine neue Version, frühere Versionen bleiben erhalten.
Nachweisdateien nach Anhang VII
Speichert Nachweise wie Prüfberichte und Designunterlagen unveränderlich im Tresor und verknüpft sie mit der technischen Dokumentation.
SBOM-Anfragen an Zulieferer
Fordert SBOMs bei Zulieferern an, vergleicht die erhaltene SBOM mit dem Image und dokumentiert die Sorgfaltspflicht.
Produktseite und Bereitschaftspfad
Zeigt für jedes Produkt den CRA-Bereitschaftsgrad und den nächsten Schritt; Aufgaben sind auf der Produktseite in Reitern gruppiert.
Dokumente aus einer Komponentenliste (ohne Firmware)
Erstellt SBOM und produktbezogene CRA-Dokumente aus einer CSV/XLSX-Komponentenliste, ohne Firmware-Upload.
Hersteller außerhalb der EU und Wirtschaftsakteure
Erfasst Bevollmächtigten, Einführer und Händler und trägt sie an der richtigen Stelle der Dokumente ein.
Hardware-Sicherheit als Nachweis nach Anhang I
Erfasst Secure Boot, Flash-Verschlüsselung und den Zustand des JTAG-/Debug-Ports als Nachweis nach Anhang I: aus den Meldungen verbundener Geräte oder, ohne Geräte, aus der Herstellererklärung mit Nachweisdatei.
Cybersicherheits-Risikobewertung
Führt durch die Risikobewertung nach Artikel 13(2)-(3) mit Bedrohungsprofil und Restrisiken und dokumentiert ihre Freigabe.
Produktklassen-Test
Bestimmt über einen kurzen Fragebogen die CRA-Klasse des Produkts (Standard, wichtig I/II, kritisch) und den Konformitätsbewertungsweg.
EU-Konformitätserklärung und vereinfachte Erklärung
Erstellt die Konformitätserklärung nach Anhang V und die vereinfachte Konformitätserklärung nach Anhang VI als PDF- und Word-Entwurf aus den hinterlegten Herstellerdaten.
Meldeformular und Posteingang für Schwachstellen
Bietet Forschenden ein öffentliches Meldeformular, security.txt und einen Posteingang, der jeden Bearbeitungsschritt festhält.
Sicherheitshinweise (CSAF)
Veröffentlicht CSAF-Sicherheitshinweise für behobene Schwachstellen; die korrigierte Version muss ein veröffentlichtes Update sein.
Benachrichtigungen an Maintainer
Dokumentiert, dass eine Schwachstelle in einer integrierten Komponente an deren Maintainer gemeldet wurde.
Lizenzübersicht
Fasst die Komponentenlizenzen je Version zusammen und listet unbekannte gesondert auf.
Supportzeitraum und Warnungen zum Supportende
Erfasst den Supportzeitraum des Produkts, zeigt ihn in den Dokumenten und warnt vor dem Ende.
CLI und GitHub Action
Führt Analyse-Upload, Ergebnis-Gate und SBOM/VEX-Downloads aus Ihrer Build-Pipeline aus.
Vorfall- und Meldeablauf nach Artikel 14
Überwacht die Fristen für 24 Stunden, 72 Stunden und Abschlussbericht, bereitet das Formular der einheitlichen Meldeplattform vor und schlägt das koordinierende CSIRT nach Artikel 14 Absatz 7 vor. Jede Übermittlung wird signiert und mit RFC-3161-Zeitstempel archiviert.
Geräte-SDK (ESP32)
C-SDK für Registrierung, Telemetrie, sichere Updates und Anomaliemeldung; auf einem ESP32-Board durchgängig geprüft.
Import der Hersteller-SBOM
Übernimmt die SBOM Ihres Build-Systems (CycloneDX 1.4-1.7, SPDX 2.2/2.3/3.0), gleicht sie mit der Analyse ab und überwacht ihre Komponenten auf Schwachstellen.
Gruppierung von Linux-Kernel-Befunden
Gruppiert tausende Kernel-Befunde nach Subsystem und schlägt anhand der Kernel-Konfiguration 'Code nicht in diesem Image' vor.
Signierte technische Dokumentation
Erstellt die technische Dokumentation nach Anhang VII als PDF und JSON, signiert sie und friert sie mit einem RFC-3161-Zeitstempel ein.
Geräteregistrierung und Flottenüberwachung
Registriert Geräte mit befristeten Registrierungscodes, überwacht Telemetrie und Offline-Status und warnt bei Anomalien.
Signierte OTA-Updates
Liefert Updates mit einem per ECDSA P-256 signierten Manifest, verhindert Downgrades und kann eine zweite Freigabe verlangen. Im ESP32-SDK prüft das Gerät die Signatur, schreibt in seine A/B-Partition und kehrt zur vorherigen Version zurück, wenn das neue Image seinen Start-Selbsttest nicht besteht.
Firmware-Analyse und SBOM
Entpackt ein Firmware-Image (Binärdatei, Dateisystem, Intel HEX, S-Record und ELF, einschließlich Linux-ELFs sowie ESP32- und Arm-Cortex-M-MCU-ELF/AXF-Dateien), erkennt seine Komponenten und erstellt eine Software-Stückliste, die ihre Lücken offen benennt.
Priorisierung mit EPSS
Ordnet Befunde nach CVSS, der FIRST-EPSS-Ausnutzungswahrscheinlichkeit und Nachweisen aktiver Ausnutzung; jeder Befund zeigt seinen EPSS-Wert. Die Markierung nach Artikel 14 entsteht nur aus bestätigter Ausnutzung, nie aus EPSS.
VEX-Entscheidungen und CSAF VEX / OpenVEX
Erfasst die Entscheidung des Analysten zu jedem Befund mit Begründung und erzeugt CSAF-VEX- und OpenVEX-Dokumente, die den offiziellen Validator bestehen.
Sicherheitsereignisse von Geräten
Kritische Geräteereignisse (Manipulation bei falscher OTA-Signatur oder -Prüfsumme, Stack-Beschädigung, Speicherzugriffsverletzung) und ein zu niedriger Sicherheitszähler legen automatisch einen Vorfall zur Bewertung an und lösen eine Warnung aus; die Entscheidung trifft der Analyst.
Suche nach eingebetteten Geheimnissen
Findet private Schlüssel und Zugangsdaten im Image; der Analyst markiert jeden Befund als bestätigt oder Fehlalarm.
Oberfläche und Dokumente auf Türkisch und Englisch
Portal und alle Dokumente sind auf Türkisch und Englisch verfügbar; die Dokumentsprache wird je Produkt gewählt.
Geplantes, das es in der Plattform noch nicht gibt, steht in der Roadmap auf der Plattformseite.