Dieser Leitfaden zeigt die Anforderungen, den Ablauf und die Rolle von CSAF. Die Meldepflicht nach Art. 14 CRA erklärt unser eigener Leitfaden dazu.
Die acht Anforderungen auf einen Blick
| Nr. | Was Anhang I Teil II verlangt | So sieht das in der Praxis aus |
|---|---|---|
| 1 | Schwachstellen und Komponenten ermitteln und dokumentieren, mit Software-Stückliste | SBOM je Version in einem gängigen maschinenlesbaren Format |
| 2 | Schwachstellen unverzüglich behandeln und beheben, Sicherheitsupdates, soweit technisch machbar, getrennt von Funktionsupdates | Priorisierung und eigener Update-Pfad |
| 3 | Sicherheit regelmäßig und wirksam testen | Geplante Tests, Ergebnisse gesichert |
| 4 | Nach dem Update Informationen zu behobenen Schwachstellen veröffentlichen | Sicherheitshinweis mit Produkt, Auswirkung, Schwere und Abhilfe |
| 5 | Strategie für die koordinierte Offenlegung aufstellen und umsetzen | Veröffentlichte Richtlinie |
| 6 | Austausch über Schwachstellen erleichtern, mit Kontaktadresse | Sicherheitskontakt, zum Beispiel über security.txt |
| 7 | Mechanismen für die sichere Verbreitung von Updates bereitstellen | Signierte Updates, wo passend automatisch |
| 8 | Sicherheitsupdates unverzüglich und kostenlos verbreiten, mit Hinweisen für die Nutzer | Update und Hinweis gehen zusammen hinaus |
Bei Nr. 8 können Hersteller und gewerbliche Nutzer für ein maßgeschneidertes Produkt etwas anderes vereinbaren. Bei Nr. 4 darf die Veröffentlichung in begründeten Fällen warten, bis die Nutzer den Patch einspielen konnten.
Was außerdem dazugehört
- Unterstützungszeitraum: Er spiegelt die voraussichtliche Nutzung und beträgt mindestens fünf Jahre, bei kürzerer erwarteter Betriebsdauer entsprechend weniger (Art. 13 Abs. 8 CRA).
- Verfügbarkeit von Updates: Bereitgestellte Sicherheitsupdates bleiben mindestens zehn Jahre verfügbar oder für den restlichen Unterstützungszeitraum, je nachdem, was länger ist (Art. 13 Abs. 9 CRA).
- Fremde Komponenten: Finden Sie eine Schwachstelle in einer integrierten Komponente, melden Sie sie deren Hersteller oder Betreuer. Das gilt auch für Open Source (Art. 13 Abs. 6 CRA).
- Zentrale Anlaufstelle: Nutzer müssen Sie leicht finden und ihr Kommunikationsmittel wählen können (Art. 13 Abs. 17 CRA).
Art. 13 und Anhang I gelten ab dem 11. Dezember 2027, die Meldepflichten nach Art. 14 seit dem 11. September 2026 (Art. 71 Abs. 2 CRA). Der Prozess hilft schon vorher, denn die Meldepflicht setzt voraus, dass Sie Schwachstellen erkennen und einordnen.
Der Prozess in sieben Schritten
- Eingang öffnen. Richten Sie einen Sicherheitskontakt ein und veröffentlichen Sie Ihre Richtlinie zur koordinierten Offenlegung.
- Eingang bestätigen. Antworten Sie der meldenden Person und halten Sie den Zeitpunkt fest.
- Prüfen. Klären Sie, welche Produkte und Versionen betroffen sind. Die SBOM zeigt, wo eine Komponente steckt.
- Bewerten. Ordnen Sie die Schwere ein und prüfen Sie, ob die Schwachstelle aktiv ausgenutzt wird. Dann greift Art. 14 CRA.
- Beheben. Entwickeln und testen Sie die Korrektur. Halten Sie Sicherheits- und Funktionsupdates möglichst getrennt.
- Verteilen und informieren. Stellen Sie das Update sicher und kostenlos bereit und veröffentlichen Sie den Sicherheitshinweis.
- Lernen. Halten Sie die Ursache fest, aktualisieren Sie die Risikobewertung und die Dokumentation (Art. 13 Abs. 7 CRA).
Der Verlauf belegt später, dass der Prozess läuft. Die Verfahren gehören in die technische Dokumentation (Anhang VII Nr. 2 Buchst. b CRA).
Was die Richtlinie zur Offenlegung enthält
Der CRA verlangt eine Strategie, schreibt aber keinen Aufbau vor. Bewährt haben sich fünf Angaben:
- Kontakt: Wohin gehen Meldungen, und wie lässt sich vertraulich schreiben?
- Umfang: Welche Produkte und Versionen sind erfasst?
- Ablauf: Was passiert nach dem Eingang?
- Zeitrahmen: Welche Zeiten streben Sie für Bestätigung, Einschätzung und Veröffentlichung an?
- Anerkennung: Nennen Sie meldende Personen, wenn sie es möchten?
Das Gesetz nennt für diese Schritte keine festen Tage. Die Zeiten sind Ihre eigene Zusage. Halten Sie nur zu, was Sie schaffen.
CSAF: was es ist und was es nicht ist
CSAF steht für Common Security Advisory Framework. Das OASIS-Format beschreibt Sicherheitshinweise maschinenlesbar, verbreitet ist die Fassung CSAF 2.0. Das BSI hat dazu die Technische Richtlinie TR-03191 veröffentlicht.
- Was der CRA sagt: Er nennt CSAF nicht. Art. 14 Abs. 8 verlangt die Information der Nutzer gegebenenfalls in einem strukturierten, maschinenlesbaren Format, das leicht automatisch zu verarbeiten ist.
- Was CSAF dafür leistet: Es passt zu dieser Beschreibung, ist aber nicht die einzige denkbare Lösung.
- Was Ihre Kunden davon haben: Betreiber gleichen Hinweise automatisch mit ihrem Inventar ab, statt PDF-Dateien zu lesen.
- VEX: Ein CSAF-Profil sagt, ob ein Produkt von einer Schwachstelle betroffen ist oder nicht. Das erspart Rückfragen.
Beispiel aus dem Maschinenbau
Das Beispiel ist erfunden. Ein Hersteller von Steuerungen erhält eine Meldung zu einem Fehler im Webserver der Firmware.
- Tag 1: Der Eingang wird bestätigt, die Prüfung beginnt.
- Tag 3: Die SBOM zeigt: Zwei von fünf Versionen enthalten die Komponente. Eine Ausnutzung ist nicht bekannt.
- Tag 20: Firmware 2.4.1 ist getestet und freigegeben.
- Tag 21: Update und Sicherheitshinweis gehen hinaus, als Webseite und als CSAF-Dokument.
Die Zeiten sind Beispielwerte und keine Vorgabe.
Checkliste
- Sicherheitskontakt ist veröffentlicht und wird gelesen.
- Richtlinie zur koordinierten Offenlegung ist veröffentlicht.
- Je Produktversion gibt es eine aktuelle SBOM.
- Unterstützungszeitraum ist festgelegt und begründet.
- Bewertung und Zuständigkeit sind geregelt, auch für die Meldepflicht.
- Sicherheitsupdates lassen sich getrennt und kostenlos verteilen.
- Sicherheitshinweise haben eine feste Struktur, möglichst maschinenlesbar.
- Schwachstellen in Fremdkomponenten gehen an deren Hersteller oder Betreuer.
- Der Verlauf jeder Meldung ist dokumentiert.
Der Prozess in Complass
Schluss mit dem Rätseln, wo eine Meldung gerade steht. In Complass laufen Meldung, Produkt und Hinweis zusammen:
- Schwachstellenmeldungen: Jede Meldung läuft vom Eingang über die Prüfung bis zur Veröffentlichung, mit Verlauf.
- security.txt und Richtlinie: Complass erzeugt beides. Die Werte prüfen und veröffentlichen Sie auf Ihrer Website.
- Öffentliches Meldeformular: Auf Wunsch nehmen Sie Meldungen über ein Formular an.
- Produktversion: Meldungen, Funde und Hinweise erscheinen an der Version, mit SBOM und Support-Ende.
- Sicherheitshinweise: Sie schreiben einen Hinweis, geben ihn als CSAF 2.0 frei und veröffentlichen ihn mit Feed.
- Versand: Hinweise gehen an Empfängerlisten je Produkt, mit Versandnachweis.
- CRA-Meldung: Bei aktiver Ausnutzung legen Sie aus der Meldung den Vorfall an. Die Fristen laufen ab Ihrer Kenntniserlangung.
Häufige Fragen
Müssen wir CSAF einsetzen?
Der CRA schreibt CSAF nicht vor. Für Hinweise an Nutzer verlangt Art. 14 Abs. 8 gegebenenfalls ein strukturiertes, maschinenlesbares Format. Mehrere große Hersteller der Industrieautomation veröffentlichen ihre Hinweise bereits als CSAF.
Wie schnell müssen wir eine Schwachstelle beheben?
Anhang I Teil II sagt „unverzüglich“ im Hinblick auf die Risiken und nennt keine Zahl von Tagen. Halten Sie fest, wie Sie priorisieren und warum.
Gilt das auch für ältere Produkte?
Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen nur bei einer wesentlichen Änderung nach diesem Datum unter die Anforderungen. Art. 14 gilt jedoch für alle Produkte im Anwendungsbereich (Art. 69 Abs. 2 und 3 CRA).
Was ist der Unterschied zur Meldepflicht?
Der Prozess nach Anhang I Teil II gilt für alle Schwachstellen. Die Meldung nach Art. 14 betrifft aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.
Wer sollte den Prozess führen?
Der CRA nennt keine bestimmte Rolle. Viele Hersteller bündeln die Aufgabe in einem kleinen Team aus Entwicklung, Produktmanagement und Support. Wichtig sind eine feste Zuständigkeit und eine Vertretung.
In einer Demo zeigen wir Ihnen an einem Beispiel, wie aus einer Meldung ein freigegebener Sicherheitshinweis wird.
Demo anfragen CRA-Meldefristen berechnen
Weiterlesen
- Leitfaden „CRA-Meldepflicht für Hersteller nach Art. 14“
- Leitfaden „SBOM nach CRA“
- Whitepaper zum CRA für Hersteller
- Vulnerability-Management: Schwachstellen, Herstellerhinweise und Prioritäten
- CRA in Complass
Keine Rechtsberatung. Dieser Leitfaden gibt einen allgemeinen Überblick und ersetzt nicht die Prüfung im Einzelfall. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847 im Amtsblatt. Stand: November 2026.