Schwachstellenbehandlung (Annex I Teil II)
Ü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.
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, Snyk) 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
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
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.
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
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
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@bauergroup.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
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
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
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. 10 Abs. 16 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
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 |