CRA Schwachstellen-Advisory: Kostenlose Vorlage (DOCX & PDF)

CRA Schwachstellen-Advisory: Vorlage

Eine CRA-Schwachstellen-Advisory-Vorlage gibt Ihrem Sicherheitsteam eine wiederholbare Struktur für die öffentlichen Offenlegungen, die der Cyber Resilience Act verlangt, sobald Sie eine Schwachstelle beheben. Ab dem 11. September 2026 treffen Hersteller von Produkten mit digitalen Elementen verbindliche Meldepflichten nach der Verordnung (EU) 2024/2847 — und ab der vollständigen Anwendung im Dezember 2027 ist die Veröffentlichung von Informationen über behobene Schwachstellen keine gute Praxis mehr, sondern eine Marktzugangsvoraussetzung. Diese kostenlose Security-Advisory-Vorlage wird als DOCX, PDF und agentenlesbare Markdown-Datei ausgeliefert (die herunterladbaren Dateien sind auf Englisch), mit jedem Feld, das ein konformes Advisory braucht, plus einem vollständig ausgefüllten Beispiel.

Ein CRA-konformes Schwachstellen-Advisory muss die behobene Schwachstelle beschreiben, das betroffene Produkt und die Versionen identifizieren und Nutzern sagen, welche Maßnahmen zu ergreifen sind (Anhang I Teil II, Nummern 4 und 8 der Verordnung (EU) 2024/2847). Ein vollständiges Advisory ergänzt eine CVE- oder EUVD-Kennung, einen CVSS-v4.0-Score samt Vektor, behobene Versionen, Abhilfemaßnahmen oder Workarounds, den Ausnutzungsstatus, eine Offenlegungs-Zeitleiste, ein Update-Log und einen Sicherheitskontakt. Wird die Schwachstelle aktiv ausgenutzt, läuft parallel eine eigene regulatorische Uhr: Frühwarnung an die ENISA und Ihr koordinierendes CSIRT innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme (Artikel 14).

Die wichtigsten Erkenntnisse

• Die Anforderungen des CRA an die Schwachstellenbehandlung stehen in Anhang I Teil II; Artikel 13 macht ihre Einhaltung zu einer Kernpflicht des Herstellers, und Artikel 14 ergänzt die regulatorische Meldung aktiv ausgenutzter Schwachstellen.
• Zwei verschiedene Uhren: Das öffentliche Advisory ist fällig, sobald ein Sicherheitsupdate verfügbar ist; die Meldung nach Artikel 14 (24 h / 72 h / 14 Tage über die zentrale Meldeplattform der ENISA) greift nur bei aktiv ausgenutzten Schwachstellen.
• Advisories sollten sowohl eine CVE-ID als auch eine EUVD-ID tragen — die European Union Vulnerability Database der ENISA ist inzwischen die EU-eigene Referenz für Kunden wie CSIRTs.
• Artikel 14 Abs. 8 verlangt, betroffene Nutzer zu informieren, gegebenenfalls in einem strukturierten, maschinenlesbaren Format — die Felder dieser Vorlage lassen sich auf CSAF 2.0 abbilden, den maschinenlesbaren Advisory-Standard von OASIS.
• Bußgelder für Verstöße gegen die Artikel 13/14 oder Anhang I erreichen 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Was in der Vorlage steckt

Die Vorlage spiegelt den Feldsatz reifer Produktsicherheitsteams und deckt alles ab, was Anhang I Teil II erwartet — in der Reihenfolge, in der Ihre Leser es brauchen:

Feld	Was es erfasst	Warum es wichtig ist
Advisory-ID	Ihre interne Kennung (z. B. ACME-SA-2026-001)	Stabile Referenz über Updates, E-Mails und CSAF-Dokumente hinweg
Titel	Einzeilige Zusammenfassung mit Produkt und Fehlerklasse	Das Erste, was Kunden und Aggregatoren indexieren
CVE- / EUVD-ID	CVE-YYYY-NNNNN und EUVD-YYYY-NNNNN	Querverweis auf NVD und die EUVD der ENISA
CVSS-v4.0-Score + Vektor	Numerischer Score, Schweregrad-Band, vollständiger Vektor-String	Objektiver Schweregrad; steuert die Patch-SLAs der Kunden
Betroffene Produkte & Versionen	Produktnamen, Versionsbereiche, Deployment-Modelle	Anhang I Teil II verlangt, dass Nutzer betroffene Produkte identifizieren können
Behobene Versionen	Erstes gepatchtes Release je betroffener Linie	Das Handlungsziel des gesamten Advisories
Abhilfemaßnahmen & Workarounds	Übergangsmaßnahmen, wo sich das Patchen verzögert	Geforderte „mögliche zu ergreifende Maßnahmen" (Anhang I Teil II, Nummer 8)
Auswirkungen	Was ein Angreifer erreichen kann, Voraussetzungen	Erlaubt Kunden ihre eigene Risikobewertung
Ausnutzungsstatus	Keine bekannt / PoC veröffentlicht / aktiv ausgenutzt	Entscheidet, ob die Meldung nach Artikel 14 ausgelöst wurde
Zeitleiste	Meldung eingegangen → Triage → Fix → Offenlegungsdaten	Nachweis einer Behandlung „ohne Verzögerung"; schafft Vertrauen bei Forschern
Update-Log	Datierte Revisionshistorie des Advisories	Zeigt, dass das Advisory gepflegt wird und kein Fire-and-forget ist
Kontakt & PGP-Schlüssel	Sicherheitskontaktadresse und Verschlüsselungsschlüssel	Anhang I Teil II verlangt eine Kontaktadresse für Schwachstellenmeldungen

Die Markdown-Variante enthält zusätzlich Felddefinitionen, eine Schweregrad-Skala, ein Enum für den Ausnutzungsstatus, Advisory-Lebenszyklus-Zustände, eine E-Mail-Variante zur Abonnenten-Benachrichtigung und ein vollständig ausgefülltes fiktives Beispiel — damit sowohl Ihr Team als auch Ihr KI-Tooling aus einer Datei ein vollständiges Advisory entwerfen kann.

So nutzen Sie die Vorlage

1. Triagieren Sie die Meldung. Protokollieren Sie das Eingangsdatum, bestätigen Sie die Schwachstelle und vergeben Sie Ihre interne Advisory-ID. Beantragen Sie eine CVE-ID (über Ihre CNA oder MITRE) und notieren Sie die EUVD-ID, sobald sie vergeben ist.
2. Bewerten Sie sie. Berechnen Sie den CVSS-v4.0-Basisscore und erfassen Sie den vollständigen Vektor-String; setzen Sie dann das Feld Ausnutzungsstatus ehrlich — es steuert alles Weitere.
3. Prüfen Sie den regulatorischen Auslöser. Wird die Schwachstelle aktiv ausgenutzt, beginnen die Pflichten nach Artikel 14 jetzt: Frühwarnung innerhalb von 24 Stunden über die zentrale Meldeplattform, Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme. Das öffentliche Advisory ist ein separates Deliverable auf einer separaten Uhr.
4. Erst beheben, dann entwerfen. Bereiten Sie das Advisory vor, während der Fix in Arbeit ist, veröffentlichen Sie es aber erst, wenn das Sicherheitsupdate verfügbar ist — das ist der Offenlegungszeitpunkt, an dem Anhang I Teil II ansetzt. Koordinieren Sie das Embargo mit dem Melder im Rahmen Ihrer Coordinated-Vulnerability-Disclosure-Richtlinie (CVD).
5. Erst Abonnenten benachrichtigen, dann veröffentlichen. Senden Sie die Abonnenten-Benachrichtigungs-E-Mail (in der Vorlage enthalten) an Sicherheitskontakte und Trust-Center-Abonnenten zeitgleich mit oder kurz vor der Veröffentlichung, dann stellen Sie das Advisory öffentlich. Artikel 14 Abs. 8 verlangt gesondert, betroffene Nutzer über aktiv ausgenutzte Schwachstellen und Abhilfemaßnahmen zu informieren — versäumen Sie es, kann das CSIRT dies öffentlich für Sie tun.
6. Pflegen Sie das Update-Log. Jede wesentliche Änderung — neue betroffene Versionen, beobachtete Ausnutzung, überarbeitete Abhilfemaßnahmen — erhält einen datierten Eintrag. Schließen Sie das Advisory erst, wenn alle unterstützten Linien behoben sind.

Meldepflicht vs. öffentliches Advisory — die Unterscheidung, an der Teams stolpern

Die meisten Schwachstellen, die Sie beheben, erreichen die Plattform der ENISA nie. Artikel 14 erfasst aktiv ausgenutzte Schwachstellen (und schwerwiegende Vorfälle); Anhang I Teil II erfasst jede behobene Schwachstelle. Bauen Sie Ihren Workflow so, dass die Advisory-Vorlage der Standardpfad ist und die Artikel-14-Eskalation angedockt wird, sobald Ausnutzungsnachweise auftauchen — nicht umgekehrt.

Rechtsgrundlage

• Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 13 — Hersteller müssen Schwachstellen während des gesamten Unterstützungszeitraums gemäß den in Anhang I Teil II festgelegten Anforderungen an die Schwachstellenbehandlung handhaben und eine Richtlinie zur koordinierten Offenlegung von Schwachstellen betreiben.
• Anhang I Teil II — die Anforderungen an die Schwachstellenbehandlung: Schwachstellen identifizieren und dokumentieren (einschließlich einer SBOM, die mindestens die Top-Level-Abhängigkeiten abdeckt, Nummer 1); sobald ein Sicherheitsupdate verfügbar ist, Informationen über behobene Schwachstellen teilen und öffentlich offenlegen, einschließlich einer Beschreibung und Informationen zur Identifizierung des betroffenen Produkts (Nummer 4); eine CVD-Richtlinie durchsetzen (Nummer 5); eine Kontaktadresse für Schwachstellenmeldungen bereitstellen; und kostenlose Sicherheitsupdates ohne Verzögerung verbreiten, begleitet von Advisory-Meldungen mit relevanten Informationen und möglichen zu ergreifenden Maßnahmen (Nummer 8).
• Artikel 14 — Meldung aktiv ausgenutzter Schwachstellen an das als Koordinator benannte CSIRT und die ENISA über die nach Artikel 16 eingerichtete zentrale Meldeplattform: Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme. Artikel 14 Abs. 8 verlangt, betroffene Nutzer zu informieren, gegebenenfalls in einem strukturierten, maschinenlesbaren Format. Diese Pflichten gelten ab dem 11. September 2026; die Hauptpflichten des CRA gelten ab dem 11. Dezember 2027.
• Maschinenlesbare Advisories — der CRA nennt kein Format, aber CSAF 2.0 (Common Security Advisory Framework, ein OASIS-Standard) ist der etablierte Standard für strukturierte Advisories, genutzt von der CISA und großen Anbietern. Die Felder dieser Vorlage entsprechen CSAF-Dokumenteigenschaften, sodass eine spätere CSAF-Migration mechanisch bleibt.
• Sanktionen — Verstöße gegen die grundlegenden Anforderungen des Anhangs I oder die Artikel 13/14 sind mit Geldbußen bis zu 15 Mio. EUR oder 2,5 % des gesamten weltweiten Jahresumsatzes bedroht (Artikel 64).

Das vollständige Bild der Herstellerpflichten zeichnen unsere Leitfäden zum Cyber Resilience Act und zu den CRA-Artikeln 13 und 14.

Vereinigtes Königreich und Norwegen/EWR

UK: Das Regime des Product Security and Telecommunications Infrastructure (PSTI) Act 2022, in Kraft seit dem 29. April 2024, verpflichtet Hersteller vernetzter Verbraucherprodukte, die in UK verkauft werden, zur Veröffentlichung einer Vulnerability-Disclosure-Richtlinie mit Meldekontakt — die Felder Kontakt, Zeitleiste und Update-Log dieser Vorlage leisten dort Doppeldienst, wobei PSTI zusätzlich das Richtliniendokument und einen erklärten Sicherheitsupdate-Zeitraum verlangt. Norwegen/EWR: Der CRA ist als EWR-relevant gekennzeichnet und dürfte in das EWR-Abkommen übernommen werden; Hersteller aus Norwegen, Island und Liechtenstein, die in den EU-Binnenmarkt verkaufen, sind praktisch ohnehin im Anwendungsbereich, da der CRA an Produkte anknüpft, die auf dem EU-Markt bereitgestellt werden.

Veröffentlichen Sie Advisories dort, wo Ihre Kunden ohnehin nachsehen

Ein Advisory, das niemand sieht, verfehlt seinen Zweck. Orbiq Trust Updates veröffentlicht Ihre Security Advisories und Vorfallsmeldungen direkt in Ihrem Trust Center, benachrichtigt abonnierte Kunden automatisch und führt das datierte Update-Log, das der CRA erwartet — und macht so aus einer Compliance-Pflicht ein sichtbares Vertrauenssignal. Verwandt: was ein Trust Center ist und wie die NIS2-Meldepflichten bei Vorfällen mit der Kundenbenachrichtigung zusammenspielen.

---

Quellen & Referenzen

1. Verordnung (EU) 2024/2847 (Cyber Resilience Act) — Volltext — Amtsblatt der Europäischen Union.
2. Europäische Kommission — CRA-Meldepflichten — die zentrale Meldeplattform und die Fristen des Artikels 14.
3. Europäische Kommission — Cyber Resilience Act (Policy-Seite) — Inkrafttreten und Anwendungsdaten.
4. ENISA — European Union Vulnerability Database (EUVD) — EU-Schwachstellendatensätze und EUVD-Kennungen.
5. Richtlinie (EU) 2022/2555 (NIS2), Artikel 12 — Rechtsgrundlage der europäischen Schwachstellendatenbank.
6. OASIS — Common Security Advisory Framework (CSAF) v2.0 — Standard für maschinenlesbare Security Advisories.
7. FIRST — CVSS-v4.0-Spezifikation — Scoring und Schweregrad-Bänder.
8. UK Product Security and Telecommunications Infrastructure Act 2022 — britisches Produktsicherheitsregime.
9. ENISA — Cyber Resilience Act Requirements Standards Mapping — Zuordnung der CRA-Anforderungen zu bestehenden Standards.