Skip to content
Declarable

Für Hersteller vernetzter Geräte, die in die EU verkaufen

Von der SBOM, die Ihr Build ohnehin schreibt, zu einer Cyber-Resilience-Act-Akte, die Sie unterschreiben können.

Meldepflicht gilt jetzt, seit dem 11. September 2026. Alles andere gilt ab dem 11. Dezember 2027.

Read in English

Beginnen Sie mit der (die Liste der Software in Ihrer Firmware), jede SPDX- oder CycloneDX-Datei, die Ihr Build ohnehin schreibt. Declarable bereinigt, was Schwachstellendatenbanken nicht zuordnen können, zeigt, was dazu bekannt ist, und behält die Komponenten zwischen den Releases im Blick.

SBOM prüfen, kostenlos (auf Englisch)Ihre Fristen nach Artikel 14 berechnen, kostenlos (auf Englisch)

Sie prüfen und unterschreiben. Es wird nichts für Sie eingereicht. Kein Konto nötig. Ihre Dateien werden in Ihrem Browser gelesen. Nur Komponentenkennungen verlassen ihn, und nur wenn Sie eine Schwachstellenprüfung anfordern.

Die acht Pflichten, die der CRA einem Gerätehersteller auferlegt

Der verlangt von einem Hersteller mehr als das hier (zum Beispiel die CE-Kennzeichnung). Diese acht sind die Unterlagen, um die Declarable gebaut ist.

Die acht Pflichten, woher jede in der Verordnung stammt und was Declarable dazu tut
PflichtWoher sie kommtWas Declarable tut
Komponentenliste (SBOM) — jede Software in Ihrem Produkt, in einem maschinenlesbaren Format aufgelistetLiest die SBOM, die Ihr Build schreibt, ergänzt die Kennungen, die Schwachstellendatenbanken brauchen, markiert Binärblobs (Binärdateien ohne Quelltext) und die Subsysteme, die sie auslässt, und schreibt eine CycloneDX-1.6-Datei.
Behandlung von Schwachstellen — Sicherheitslücken finden, beheben und darüber informieren, solange Sie das Produkt unterstützenGleicht Ihre Komponenten mit öffentlichen Schwachstellendatenbanken ab, prüft das aktuelle Release jedes Produkts und ältere Releases, die noch im Supportzeitraum liegen, täglich erneut, schickt Ihnen per E-Mail, was neu ist, und hält für jeden Fund fest, ob er Ihr Produkt betrifft. Ein Generator für Richtlinie zur Offenlegung und security.txt ist kostenlos.
Meldung an die ENISA — der ENISA, der EU-Agentur für Cybersicherheit, in drei Schritten eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall meldenBerechnet die Fristen von 24 Stunden, 72 Stunden und für den Abschlussbericht ab dem Moment, in dem Sie Kenntnis erlangt haben, entwirft den Text für jede Stufe und erinnert Sie vor jeder Frist. Declarable meldet nicht für Sie: Sie reichen die Meldung selbst auf der ENISA-Plattform ein.
Risikobewertung — herausfinden, welchen Cybersicherheitsrisiken Ihr Produkt ausgesetzt ist, und das in die Entwicklung einfließen lassenEntwirft eine geführte Risikobewertung anhand einer Bedrohungsbibliothek für vernetzte Geräte, zur Prüfung durch Sie.
Technische Dokumentation — die Akte, die Ihr Produkt beschreibt und zeigt, wie es die wesentlichen Anforderungen erfülltEntwirft die technische Akte aus Ihrem Produktdatensatz und Ihrer SBOM und fragt Sie nach dem Rest, zur Prüfung durch Sie.
Nutzerinformationen — was Sie Ihren Kunden mitteilen: an wen sie sich bei Schwachstellen wenden, wie lange Updates kommen, wie das Produkt sicher zu benutzen istEntwirft ein Informationsblatt für Ihr Handbuch oder Ihre Website, zur Prüfung durch Sie.
Konformitätserklärung — eine Erklärung, die Sie unterschreiben und in der Sie festhalten, dass Ihr Produkt die Anforderungen erfülltEntwirft den CRA-Teil der Erklärung, die Sie ohnehin unterschreiben. Die Prüfung des Anwendungsbereichs sagt, welcher Bewertungsweg für Ihr Produkt voraussichtlich in Frage kommt. Unterschreiben müssen Sie selbst.
Unterstützungszeitraum — wie lange Sie zusagen, Sicherheitsupdates zu liefernHält das Enddatum Ihres Unterstützungszeitraums beim Produkt fest.

So funktioniert es

  1. Schritt 1: SBOM des Builds hochladen

    Ziehen Sie die SPDX- oder CycloneDX-Dateien hinein, die Ihr Build ohnehin schreibt: west spdx für Zephyr, die Klasse create-spdx für Yocto, esp-idf-sbom für ESP-IDF.

  2. Schritt 2: Declarable bereinigt sie und behält sie im Blick

    Es ergänzt die Kennungen, nach denen Schwachstellendatenbanken zuordnen, markiert, was es nicht identifizieren konnte, und zeigt, was zu jeder Komponente bekannt ist. Speichern Sie das Produkt, prüft es Ihr aktuelles Release jeden Tag erneut.

  3. Schritt 3: Die Unterlagen beginnen damit

    GeplantAbschnitte der technischen Akte, die Risikobewertung und die Erklärung beginnen mit dem, was Declarable schon über Ihr Produkt weiß, und fragen Sie nach dem Rest. Sie prüfen, ändern und unterschreiben.

Kostenlose Werkzeuge

Jedes funktioniert ohne Konto. Die SBOM-Prüfung ist der beste Einstieg.

Gebaut für die Firmware, die Sie ohnehin bauen

Kleine Teams, die vernetzte Geräte auf Zephyr, Yocto oder ESP-IDF in der EU oder für die EU bauen.

  • Zephyr

    west spdx schreibt vier SPDX-Dokumente ohne die Kennungen (CPE oder PURL), nach denen Schwachstellendatenbanken zuordnen, und lässt Subsysteme aus, die Ihre Konfiguration einschaltet.

    Declarable führt sie zu einer SBOM zusammen, ergänzt Kennungen, findet die fehlenden Subsysteme in Ihrer .config und markiert Binärblobs von Herstellern ohne Quelltext.

    CRA für Zephyr-Hersteller (auf Englisch) →

  • Yocto

    Die Klasse create-spdx schreibt ein SPDX-Dokument je Rezept, Paket und Image, und Rezeptnamen weichen oft von den Produktnamen ab, die Schwachstellendatenbanken verwenden.

    Declarable liest das Archiv .spdx.tar.zst des Images, baut eine SBOM für das Image und ordnet Rezepte den Namen zu, die Datenbanken verwenden.

    CRA für Yocto-Hersteller (auf Englisch) →

  • ESP-IDF

    esp-idf-sbom schreibt bereits Kennungen in seine Ausgabe, sodass weniger zu bereinigen ist.

    Declarable importiert sie, behält diese Kennungen, markiert die Wi-Fi- und Bluetooth-Bibliotheken ohne Quelltext als Binärblobs und fügt einen Lückenbericht hinzu, der auflistet, was Ihrer SBOM fehlt.

    CRA für ESP-IDF-Hersteller (auf Englisch) →

Was Declarable ist und was nicht

  • Eine Dokumentationshilfe. Declarable bereitet Entwürfe und Checklisten vor, die Sie prüfen und ändern.
  • Keine Rechtsberatung. Bei einer Rechtsfrage zu Ihrem Produkt fragen Sie eine Rechtsanwältin oder einen Rechtsanwalt.
  • Keine Zertifizierung. Niemand bei Declarable bewertet Ihr Produkt oder gibt es frei. Ihre Konformitätserklärung unterschreiben Sie selbst.
  • Keine Konformitätsbewertungsstelle. Manche Produkte brauchen eine externe Stelle: die auf den Listen in Anhang III und Anhang IV — die Produktkategorien mit höherem Risiko: Anhang III Klasse II und Anhang IV stets, Anhang III Klasse I, solange keine harmonisierte Norm, gemeinsame Spezifikation oder kein Zertifizierungsschema im Amtsblatt veröffentlicht und vollständig angewendet ist (Art. 32) des CRA. Declarable ist keine solche Stelle. Die Prüfung des Anwendungsbereichs (auf Englisch) stellt die Fragen, die auf Ihre Kategorie hinweisen.
  • Kein Meldedienst. Declarable reicht keine Meldungen für Sie ein. Sie reichen sie selbst auf der ENISA-Plattform ein.

Declarable bereitet Unterlagen vor, die Sie prüfen sollen. Das ist keine Rechtsberatung und keine Zertifizierung. Ihre Konformitätserklärung unterschreiben Sie selbst.