3.3 Patch Management

Patch-Management-Policy

Diese Policy definiert den verbindlichen Prozess für die Bereitstellung von Sicherheitsupdates für Produkte mit digitalen Elementen gemäß CRA.

RECHTSGRUNDLAGE

Art. 10 Abs. 7 CRA: „Der Hersteller stellt sicher, dass Schwachstellen durch Sicherheitsupdates behoben werden, die den Nutzern unverzüglich und kostenlos zur Verfügung gestellt werden."

Annex I, Teil II, Nr. 7: „Der Hersteller stellt Sicherheitsupdates bereit, um die ermittelten Schwachstellen unverzüglich zu beheben, sobald dies nach dem Stand der Technik praktisch möglich ist."

Patch-Klassifizierung

Klasse	Schwere	Reaktionszeit	Patch-Deadline	Release-Typ
P0 – Emergency	CRITICAL, aktiv ausgenutzt	Sofort	24 Stunden	Hotfix
P1 – Critical	CRITICAL, nicht ausgenutzt	4 Stunden	48 Stunden	Hotfix
P2 – High	HIGH	24 Stunden	7 Tage	Patch-Release
P3 – Medium	MEDIUM	72 Stunden	30 Tage	Minor-Release
P4 – Low	LOW	7 Tage	Nächster Release	Geplant

Patch-Prozess

P0/P1: Emergency & Critical Patches

1. CVE-Alert eingeht
   └── CVE-Monitor, Dependabot, externe Meldung

2. Triage (Security Lead) – innerhalb 4h
   ├── Schwere bestätigen (CVSS)
   ├── Betroffene Produkte identifizieren
   ├── Ausnutzbarkeit bewerten
   └── Bei aktiver Ausnutzung → ENISA-Frühwarnung (24h)

3. Patch-Entwicklung (Dev Team) – Sofortstart
   ├── Dependency-Update oder Code-Fix
   ├── Unit Tests + Integration Tests
   └── Security Review

4. Patch-Release
   ├── Hotfix-Branch erstellen
   ├── CI/CD Pipeline (beschleunigt)
   ├── SBOM aktualisieren
   ├── Release signieren (Cosign)
   └── Release veröffentlichen

5. Nutzer-Benachrichtigung
   ├── GitHub Security Advisory
   ├── Release Notes mit CVE-Referenz
   └── Direkte Benachrichtigung bei kritischen Kunden

6. Nachbereitung
   ├── ENISA-Abschlussbericht (wenn meldepflichtig)
   ├── CVE-Issue schließen
   └── Lessons Learned

P2/P3: High & Medium Patches

1. CVE-Alert eingeht
2. Triage (Security Lead) – innerhalb 24h/72h
3. In Sprint-Backlog aufnehmen (priorisiert)
4. Patch-Entwicklung im normalen Entwicklungszyklus
5. Patch-Release gemäß Release-Kalender
6. SBOM aktualisieren

P4: Low Patches

1. CVE-Alert eingeht
2. Triage – innerhalb 7 Tagen
3. In Backlog aufnehmen
4. Behebung im nächsten regulären Release

Automatisierung

Der Großteil des Patch-Managements ist automatisiert:

Schritt	Automatisierung	Manuell
CVE-Erkennung	CVE-Monitor + Dependabot	-
Issue-Erstellung	Auto-Issue bei Critical/High	Manuelle Erstellung bei Medium/Low
PR-Erstellung	Dependabot Security PR	Manueller PR bei Code-Fixes
CI/CD	Automatische Pipeline	-
SBOM-Generierung	Automatisch bei Release	-
Signing	Automatisch bei Release	-
Nutzer-Info	Release Notes	Advisory bei P0/P1

Sicherheitsupdates – Bereitstellungspflicht

Gemäß Art. 10 Abs. 7 CRA müssen Sicherheitsupdates:

• Kostenlos bereitgestellt werden
• Unverzüglich nach Verfügbarkeit
• In einem sicheren Kanal (signiert, Integrität gewährleistet)
• Für den gesamten Support-Zeitraum des Produkts

Für Container-basierte Produkte:

• Aktualisiertes Container-Image auf GHCR/Docker Hub
• Signiertes Image (Cosign)
• Aktualisierte SBOM als Release-Asset

Für Firmware-basierte Produkte:

• Signiertes Firmware-Binary
• OTA-Update (wo technisch möglich)
• Download über GitHub Releases