3.5 Schwachstellenbehandlung (Annex I Teil II)
3.5.1 Übersicht
Annex I Teil II des CRA definiert 8 Anforderungen an die Schwachstellenbehandlung, die Hersteller während des gesamten Support-Zeitraums eines Produkts mit digitalen Elementen erfüllen müssen. Während Teil I die Sicherheitseigenschaften des Produkts selbst regelt (Wesentliche Sicherheitsanforderungen), adressiert Teil II die organisatorischen und prozessualen Pflichten im Umgang mit Schwachstellen.
RECHTSGRUNDLAGE
Annex I Teil II CRA: Anforderungen an die Behandlung von Schwachstellen. Die Hersteller von Produkten mit digitalen Elementen müssen die folgenden Anforderungen erfüllen, um die Schwachstellen des Produkts während des gesamten Support-Zeitraums wirksam zu behandeln.
3.5.2 Nr. 1 – Schwachstellen und Komponenten identifizieren und dokumentieren
Anforderung: Der Hersteller muss Schwachstellen und Komponenten des Produkts identifizieren und dokumentieren, einschließlich der Erstellung einer Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten des Produkts abdeckt.
Umsetzung bei BAUER GROUP:
- Automatisierte SBOM-Generierung im CycloneDX-Format bei jedem Release
- Vollständige Erfassung aller direkten und transitiven Abhängigkeiten
- Tägliches CVE-Monitoring aller aktiven Produkt-SBOMs gegen NVD, GitHub Advisory Database und OSV
- Multi-Engine Security Scanning (Trivy, Grype, OSV-Scanner) in der CI/CD-Pipeline
- Dependabot für automatische Erkennung veralteter oder verwundbarer Abhängigkeiten
- Zentrale Inventarisierung aller Produkte und ihrer Komponentenstruktur
Nachweis: SBOM pro Release (CycloneDX JSON), CVE-Scan-Berichte, Dependency-Audit-Logs, Komponenteninventar
3.5.3 Nr. 2 – Schwachstellen unverzüglich beheben
Anforderung: Der Hersteller muss Schwachstellen unverzüglich adressieren und beheben, unter anderem durch die Bereitstellung von Sicherheitsupdates. Soweit technisch möglich, müssen Sicherheitsupdates getrennt von funktionalen Updates bereitgestellt werden.
Umsetzung bei BAUER GROUP:
- SLA-basierter Patch-Management-Prozess mit definierten Reaktionszeiten:
- P0 (Critical, aktiv ausgenutzt): Hotfix innerhalb von 24 Stunden
- P1 (Critical): Hotfix innerhalb von 48 Stunden
- P2 (High): Patch-Release innerhalb von 7 Tagen
- P3 (Medium): Minor-Release innerhalb von 30 Tagen
- Trennung von Sicherheitsupdates und Funktionsupdates im Release-Prozess
- Pre-Release Security Gate: Kein Release mit bekannten Critical/High CVEs
- Automatisiertes Dependency-Update über Dependabot mit automatischen Pull Requests
Nachweis: Patch-Protokolle mit Zeitstempeln, Release Notes mit Security-Fix-Kennzeichnung, SLA-Einhaltungsberichte
3.5.4 Nr. 3 – Wirksame und regelmäßige Tests und Überprüfungen
Anforderung: Der Hersteller muss wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts mit digitalen Elementen durchführen.
WAS „REGELMÄSSIG" BEDEUTET
Regelmäßige Tests verlangen keine mechanische Wiederholung einer unveränderten Testkampagne in festen Intervallen. Verlangt ist die regelmäßige Prüfung, ob neue Eingangsgrößen — neu identifizierte Bedrohungen oder neu entdeckte Schwachstellen — eine Aktualisierung der bestehenden Tests erfordern, und die entsprechende Durchführung von Tests.
| Ergebnis der Prüfung | Folge |
|---|---|
| Es werden relevante neue Eingangsgrößen für den Testumfang festgestellt | Neue oder geänderte Tests sind zu entwickeln und am Produkt durchzuführen, damit keine Schwachstellen unbehandelt bleiben. Dazu kann die erneute Ausführung bestehender Tests gehören, wenn eine Produktänderung dies angezeigt erscheinen lässt — etwa Regressionstests. |
| Es werden keine solchen Eingangsgrößen festgestellt | Zusätzliche Tests müssen nicht entwickelt werden. Die übrigen Pflichten zur Schwachstellenbehandlung, einschließlich der Behebung von Schwachstellen im Verhältnis zu den bestehenden Risiken, gelten parallel fort. |
Häufigkeit, Tiefe und Inhalt der Prüfung müssen im Verhältnis zum Cybersicherheits-Risikoprofil des Produkts, seiner Entwicklung im Zeitverlauf und der Bedrohungslage stehen.
DIE PRÜFUNG SELBST IST DER NACHWEIS
Da die Pflicht darin besteht, zu prüfen, ob der Testumfang noch angemessen ist, ist die Aufzeichnung dieser Prüfung — einschließlich solcher mit dem Ergebnis „keine Änderung erforderlich" — der Compliance-Nachweis. Eine Quartalsprüfung ohne neue Tests ist konform; eine ausgebliebene Prüfung nicht.
Umsetzung bei BAUER GROUP:
- Automatisierte Tests: SAST, DAST und SCA in jeder CI/CD-Pipeline
- Container-Scanning: Trivy-Scan aller Container-Images bei Build und als Scheduled Job
- Dependency-Scanning: Täglicher SBOM-basierter CVE-Scan
- Regelmäßige Überprüfungen: Quartalsweise Security Reviews pro Produkt
- Penetration Testing: Jährlich für kritische Produkte, ergänzend bei wesentlichen Änderungen
- Risikobewertung: Kontextbezogene Risikobewertung bei jeder neuen Schwachstelle
Nachweis: CI/CD-Scan-Ergebnisse, Security-Review-Protokolle, Penetration-Test-Berichte, Risikobewertungsberichte
3.5.5 Nr. 4 – Öffentliche Offenlegung behobener Schwachstellen
Anforderung: Sobald ein Sicherheitsupdate verfügbar ist, muss der Hersteller Informationen über behobene Schwachstellen öffentlich zugänglich machen, einschließlich einer Beschreibung der Schwachstelle, Informationen zur Identifizierung der betroffenen Produkte, der Auswirkungen, des Schweregrads und Maßnahmen zur Behebung. Soweit verfügbar, ist eine CVE-ID zu vergeben.
Umsetzung bei BAUER GROUP:
- Veröffentlichung von Security Advisories über GitHub Security Advisories
- Jede behobene Schwachstelle erhält:
- CVE-ID: Vergabe über GitHub CNA oder MITRE
- Beschreibung: Klare Erläuterung der Schwachstelle und betroffener Versionen
- Schweregrad: CVSS v3.1/v4.0 Score und Einstufung
- Betroffene Produkte: Exakte Versionsangaben
- Behebung: Verweis auf das Sicherheitsupdate und Handlungsempfehlungen
- Release Notes enthalten dedizierte Security-Sektion
- Koordinierte Offenlegung gemäß Disclosure Policy
Nachweis: GitHub Security Advisories, Release Notes, CVE-Einträge in NVD/OSV
3.5.6 Nr. 5 – Richtlinie zur koordinierten Schwachstellenoffenlegung
Anforderung: Der Hersteller muss eine Richtlinie zur koordinierten Schwachstellenoffenlegung (Coordinated Vulnerability Disclosure) einführen und durchsetzen.
Umsetzung bei BAUER GROUP:
- Umfassende Disclosure Policy gemäß ISO/IEC 29147:2018
- Definierte Meldewege:
- GitHub Security Advisories (bevorzugt)
- Dedizierte E-Mail-Adresse (security@bauer-group.com)
- SECURITY.md in jedem Repository
- Verbindliche Reaktionszeiten für eingegangene Meldungen (Erstreaktion innerhalb von 48 Stunden)
- Koordinierter Offenlegungszeitraum (standardmäßig 90 Tage)
- Safe-Harbor-Klausel für gutgläubige Sicherheitsforscher
- Anerkennungsprogramm (Security Hall of Fame)
Nachweis: Disclosure Policy (veröffentlicht), SECURITY.md in Repositories, Meldungs-Tracking-Log
3.5.7 Nr. 6 – Austausch von Informationen über potenzielle Schwachstellen
Anforderung: Der Hersteller muss Maßnahmen ergreifen, um den Austausch von Informationen über potenzielle Schwachstellen in seinem Produkt und in Drittkomponenten zu erleichtern, einschließlich einer Kontaktstelle für die Meldung von Schwachstellen.
Umsetzung bei BAUER GROUP:
- Kontaktstelle: Dedizierte Security-Kontaktadresse in jedem Produkt und Repository
- Upstream-Kommunikation: Aktive Meldung von Schwachstellen in genutzten Open-Source-Komponenten an Upstream-Maintainer
- ENISA-Meldeprozess: Strukturierte Meldung aktiv ausgenutzter Schwachstellen an ENISA gemäß Meldeprozess
- Interne Kommunikation: Sicherheitsrelevante Informationen werden über definierte Kanäle (Kommunikationsplan) geteilt
- Branchenkooperation: Teilnahme an relevanten Informationsaustausch-Initiativen (ISACs, Sicherheitsgemeinschaften)
Nachweis: Kontaktstellen-Dokumentation, Upstream-Meldungsprotokolle, ENISA-Meldungen, Kommunikationsprotokoll
Umfang und Grenzen der Upstream-Meldepflicht nach Art. 13 Abs. 6 sind in 3.5.11 dargestellt.
3.5.8 Nr. 7 – Mechanismen zur sicheren Verteilung von Updates
Anforderung: Der Hersteller muss Mechanismen bereitstellen, um Updates sicher zu verteilen und eine rechtzeitige Bereitstellung sicherzustellen. Sicherheitspatches und -updates werden über vertrauenswürdige Kanäle verteilt.
Umsetzung bei BAUER GROUP:
- Signierte Artefakte: Alle Release-Artefakte werden mit Cosign signiert (Signierung)
- Vertrauenswürdige Kanäle:
- Container-Images über signierte Registry (GHCR)
- Binaries über signierte GitHub Releases
- Firmware-Updates über gesicherte OTA-Kanäle
- Integritätsverifikation: Verifikationsprozess mit Cosign verify
- Update-Mechanismus: Automatische und manuelle Update-Pfade dokumentiert (Update-Mechanismus)
- Verfügbarkeit: Updates über redundante Infrastruktur bereitgestellt
- Rollback: Möglichkeit zur Rückkehr auf vorherige Version bei fehlgeschlagenen Updates
Nachweis: Signaturprotokolle, Update-Architektur-Dokumentation, Verifikationsanleitung, Rollback-Testprotokolle
3.5.9 Nr. 8 – Sicherheitspatches unverzüglich und kostenlos bereitstellen
Anforderung: Der Hersteller muss sicherstellen, dass Sicherheitspatches unverzüglich und kostenlos verbreitet werden, begleitet von Empfehlungsmeldungen mit relevanten Informationen, einschließlich möglicher Maßnahmen der Nutzer.
Umsetzung bei BAUER GROUP:
- Kostenlose Bereitstellung: Alle Sicherheitspatches sind während des gesamten Support-Zeitraums kostenlos verfügbar
- Unverzügliche Verteilung: Gemäß SLA-Vorgaben des Patch-Managements
- Advisory Messages: Jedes Sicherheitsupdate wird begleitet von:
- Beschreibung der behobenen Schwachstellen
- Schweregrad (CVSS Score)
- Betroffene Versionen und Upgrade-Pfad
- Empfohlene Nutzermaßnahmen (Workarounds, Konfigurationsänderungen)
- Zeitplan für die Behebung (sofern verzögert)
- Benachrichtigung: Proaktive Benachrichtigung der Nutzer über verfügbare Sicherheitsupdates
- Keine Kopplung: Sicherheitsupdates enthalten keine zwingenden Funktionsänderungen
WICHTIG
Gemäß Art. 13 Abs. 8 CRA müssen Sicherheitspatches für den gesamten Support-Zeitraum kostenlos bereitgestellt werden. Eine Kopplung an kostenpflichtige Wartungsverträge ist nicht zulässig.
Nachweis: Release Notes mit Security-Sektion, Advisory-Meldungen, Download-Statistiken, Nutzer-Benachrichtigungsprotokolle
3.5.10 Bekannte ausnutzbare Schwachstellen (Anhang I Teil I)
Anhang I Teil I verlangt, dass Produkte mit digitalen Elementen auf Grundlage der Risikobewertung nach Art. 13 Abs. 2 und gegebenenfalls ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden. Obwohl es sich um eine Anforderung des Teils I handelt, ist sie von der Schwachstellenbehandlung nicht zu trennen und wird daher hier dokumentiert.
RECHTSGRUNDLAGE
Art. 3 Nr. 41 CRA: „‚ausnutzbare Schwachstelle' bezeichnet eine Schwachstelle, die das Potenzial hat, von einem Angreifer unter praktischen Betriebsbedingungen wirksam genutzt zu werden."
„Ausnutzbar" — der Filter der praktischen Bedingungen
Nicht jede Schwachstelle ist ausnutzbar. Manche lassen sich nur unter theoretischen Bedingungen ausnutzen — im Labor oder in der Simulation — oder unter Bedingungen, die in der Betriebsumgebung des Produkts nicht auftreten würden. Diese lösen die Anforderung nicht aus.
Wann ist eine Schwachstelle „bekannt"?
Der CRA definiert den Zeitpunkt nicht. Die Leitlinien nennen drei Wege:
| Weg | Detail |
|---|---|
| Öffentliche Datenbanken | Die Schwachstelle ist in einer einschlägigen, öffentlich zugänglichen Schwachstellendatenbank gelistet — etwa der europäischen Schwachstellendatenbank nach Art. 12 Abs. 2 der Richtlinie (EU) 2022/2555 oder anderen prominenten Datenbanken |
| Nicht-öffentliche Informationen | Koordinierte Offenlegung durch Sicherheitsforschende oder eigene interne Tests und Analysen des Herstellers — ausdrücklich einschließlich des Einsatzes KI-gestützter Dienste |
| Prominente Medienberichte | Öffentlich und prominent in verlässlichen Medien berichtet, einschließlich Fachpublikationen zur Cybersicherheit oder allgemeiner Massenmedien |
EINE MELDUNG IST KEINE BESTÄTIGUNG
Dass eine Schwachstelle gemeldet oder gefunden wurde, bedeutet nicht ohne Weiteres, dass sie praktisch ausnutzbar oder auf das konkrete Produkt anwendbar ist. Der Hersteller muss den Wahrheitsgehalt der Information und ihre Anwendbarkeit auf sein eigenes Produkt untersuchen und bestätigen. Zwischen Erstmeldung und Bestätigung kann daher eine begrenzte Zeit vergehen — mit der Betonung, wie bei der Meldung, auf zügigem Handeln.
Die Release-Entscheidung
Die Pflicht gilt zum Zeitpunkt des Inverkehrbringens (Art. 13 Abs. 1). In der Praxis werden potenziell ausnutzbare Schwachstellen mitunter in den letzten Phasen des Entwicklungszyklus entdeckt, kurz bevor das Produkt in die Vertriebskette gelangt.
Da es sich um eine risikobasierte Pflicht handelt, obliegt es dem Hersteller zu bestimmen, ob das Produkt sicher in Verkehr gebracht werden kann oder ob die Schwachstelle zuvor behoben werden muss.
| Faktoren für eine Behebung vor dem Release | Faktoren, die ein Release rechtfertigen können |
|---|---|
| Schweregrad der Schwachstelle | Das Release behebt weitere ausnutzbare Schwachstellen |
| Ausnutzbarkeit unter praktischen Betriebsbedingungen | Das Release ist für den Weiterbetrieb kritischer Systeme erforderlich |
| Potenzielle Auswirkungen | |
| Risiken für das Produkt im Einsatz |
DIE ENTSCHEIDUNG IST ZU DOKUMENTIEREN
Ein Release mit einer bekannten Schwachstelle ist eine dokumentierte Risikoentscheidung, kein Versäumnis. Festzuhalten sind die abgewogenen Faktoren, das Ergebnis der Risikobewertung und die geplante Behebung. Nach dem Inverkehrbringen bleibt der Hersteller unabhängig davon vollumfänglich an die Pflichten des Anhangs I Teil II gebunden.
3.5.11 Upstream-Meldung und Weitergabe von Sicherheitsfixes (Art. 13 Abs. 6)
Art. 13 Abs. 6 CRA verpflichtet Hersteller, (i) Schwachstellen in integrierten Komponenten an die Person oder Einrichtung zu melden, die die Komponente herstellt oder pflegt, und (ii) eine von ihnen entwickelte Softwareänderung zur Behebung einer solchen Schwachstelle zu teilen.
Umfang der Meldepflicht
| Regel | Detail |
|---|---|
| Versionsbezug | Nur in Bezug auf die integrierte Version der Komponente melden |
| Kanal des Maintainers nutzen | Bestehen beim Maintainer Sicherheitsrichtlinien, Prozesse zur koordinierten Offenlegung oder benannte Meldekanäle, ist entsprechend zu melden — insbesondere dort, wo eine vorzeitige Offenlegung ungepatchter Schwachstellen Cybersicherheitsrisiken erhöhen könnte |
| Keine Doppelmeldungen | Hersteller müssen nicht nach oben melden, wenn sie bestätigen können, dass dem Maintainer die Schwachstelle bereits bekannt ist. Ihnen wird empfohlen, zuvor öffentlich zugängliche Schwachstellendatenbanken, projektspezifische Sicherheitshinweise und etablierte Issue-Tracker zu prüfen — dies dient ausdrücklich der Entlastung der Upstream-Maintainer, besonders in Open-Source-Projekten |
| Nur Komponentenschwachstellen | Nur Schwachstellen melden, die in der integrierten Komponente selbst bestehen — nicht solche, die aus der Integration zwischen der Komponente und eigenem Code oder aus der Integration anderer Komponenten entstehen |
| Nicht gepflegte Komponenten | Nicht erforderlich, wenn die Komponente keinen Maintainer mehr hat oder wenn der Hersteller für neue Versionen oder Sicherheitsfixes nicht mehr auf den ursprünglichen Maintainer angewiesen ist |
ZWEI DINGE, DIE EMPFOHLEN — NICHT VERLANGT — SIND
- Offenbart die Integration einer Komponente Verhaltensweisen, Wechselwirkungen oder sicherheitsrelevante Merkmale, die isoliert nicht erkennbar waren, sollte dies dem Maintainer mitgeteilt werden. Es ist keine Komponentenschwachstelle, verbessert aber die Sicherheit des Komponenten-Ökosystems.
- Ist eine Komponente nicht mehr gepflegt, sollten ihre Nutzer über angemessene alternative Wege informiert werden — bestehende Community-Mechanismen wie Mailinglisten oder Issue-Tickets oder öffentliche Schwachstellenverzeichnisse.
Weitergabe des Sicherheitsfixes
| Regel | Detail |
|---|---|
| Format | Den Fix soweit angemessen in einem maschinenlesbaren Format bereitstellen, so dass er leicht überprüft und gegebenenfalls vom Maintainer integriert werden kann |
| Lizenzierung (FOSS-Komponenten) | Den Fix lizenzkompatibel zur Komponente teilen — etwa unter derselben Lizenz oder unter einer Lizenz, die dem Maintainer die Weitergabe unter seiner eigenen Lizenz erlaubt |
| Vorgaben des Maintainers | Bestehen beim Maintainer Vorgaben zur Weitergabe von Sicherheitsfixes, sind diese einzuhalten |
Was nicht verlangt wird
DIE PFLICHT IST DAS ANGEBOT, NICHT DAS DURCHSETZEN
- Hersteller müssen nicht sicherstellen, dass ihre Fixes vom Maintainer akzeptiert werden.
- Sie müssen nicht sicherstellen, dass Fixes in das Repository der Komponente übernommen werden — der Maintainer kann eine andere Lösung bevorzugen.
- Umgekehrt müssen Hersteller einen vom Maintainer vorgeschlagenen Fix nicht übernehmen und dürfen das Problem auf andere geeignete Weise mindern.
- Hat der Maintainer bereits einen Fix bereitgestellt, der Hersteller setzt aber eine andere Minderungsstrategie um — etwa eine Konfigurationsänderung an anderer Stelle —, verlangt der CRA nicht, diese Änderung nach oben zu teilen. Es wird empfohlen, wo es dem Maintainer hilft.
3.5.12 Compliance-Matrix
| Nr. | Anforderung | Umsetzungsstatus | Nachweis-Ort | Verweis |
|---|---|---|---|---|
| 1 | Schwachstellen und Komponenten identifizieren (SBOM) | ✅ | SBOM-Archiv, CVE-Berichte | SBOM, CVE-Monitoring |
| 2 | Schwachstellen unverzüglich beheben | ✅ | Patch-Protokolle, Release Notes | Patch Management |
| 3 | Wirksame und regelmäßige Tests | ✅ | CI/CD-Berichte, Pen-Test-Ergebnisse | CVE-Monitoring |
| 4 | Öffentliche Offenlegung (CVE-ID, Schweregrad) | ✅ | GitHub Advisories, NVD | Disclosure Policy |
| 5 | Richtlinie zur koordinierten Offenlegung | ✅ | Disclosure Policy, SECURITY.md | Disclosure Policy |
| 6 | Austausch über potenzielle Schwachstellen | ✅ | Kontaktstellen, ENISA-Meldungen | ENISA-Meldeprozess |
| 7 | Sichere Verteilung von Updates | ✅ | Signaturprotokolle, Update-Architektur | Update-Mechanismus, Signierung |
| 8 | Patches unverzüglich und kostenlos | ✅ | Release Notes, Advisories | Patch Management |
Quelle und Rechtsstatus der Auslegungen in den Abschnitten 3.5.4, 3.5.10 und 3.5.11: Leitlinien der EU-Kommission zum CRA.