3.3 Patch Management

Patch Management Policy

This policy defines the binding process for the provision of security updates for products with digital elements in accordance with the CRA.

LEGAL BASIS

Art. 10(7) CRA: "The manufacturer shall ensure that vulnerabilities are remediated through security updates that are made available to users without delay and free of charge."

Annex I, Part II, No. 7: "The manufacturer shall provide security updates to remediate the identified vulnerabilities without delay, as soon as this is practically feasible according to the state of the art."

Patch Classification

Class	Severity	Response Time	Patch Deadline	Release Type
P0 -- Emergency	CRITICAL, actively exploited	Immediate	24 hours	Hotfix
P1 -- Critical	CRITICAL, not exploited	4 hours	48 hours	Hotfix
P2 -- High	HIGH	24 hours	7 days	Patch release
P3 -- Medium	MEDIUM	72 hours	30 days	Minor release
P4 -- Low	LOW	7 days	Next release	Planned

Patch Process

P0/P1: Emergency & Critical Patches

1. CVE alert received
   +-- CVE monitor, Dependabot, external report

2. Triage (Security Lead) -- within 4h
   +-- Confirm severity (CVSS)
   +-- Identify affected products
   +-- Assess exploitability
   +-- If actively exploited -> ENISA early warning (24h)

3. Patch development (Dev Team) -- immediate start
   +-- Dependency update or code fix
   +-- Unit tests + integration tests
   +-- Security review

4. Patch release
   +-- Create hotfix branch
   +-- CI/CD pipeline (accelerated)
   +-- Update SBOM
   +-- Sign release (Cosign)
   +-- Publish release

5. User notification
   +-- GitHub Security Advisory
   +-- Release notes with CVE reference
   +-- Direct notification for critical customers

6. Follow-up
   +-- ENISA final report (if reportable)
   +-- Close CVE issue
   +-- Lessons learned

P2/P3: High & Medium Patches

1. CVE alert received
2. Triage (Security Lead) -- within 24h/72h
3. Add to sprint backlog (prioritised)
4. Patch development within regular development cycle
5. Patch release according to release calendar
6. Update SBOM

P4: Low Patches

1. CVE alert received
2. Triage -- within 7 days
3. Add to backlog
4. Remediation in next regular release

Automation

The majority of patch management is automated:

Step	Automation	Manual
CVE detection	CVE monitor + Dependabot	-
Issue creation	Auto-issue for Critical/High	Manual creation for Medium/Low
PR creation	Dependabot Security PR	Manual PR for code fixes
CI/CD	Automatic pipeline	-
SBOM generation	Automatic on release	-
Signing	Automatic on release	-
User notification	Release notes	Advisory for P0/P1

Security Updates -- Provision Obligation

In accordance with Art. 10(7) CRA, security updates must be:

• Provided free of charge
• Made available without delay
• Delivered through a secure channel (signed, integrity assured)
• Maintained for the entire support period of the product

For container-based products:

• Updated container image on GHCR/Docker Hub
• Signed image (Cosign)
• Updated SBOM as release asset

For firmware-based products:

• Signed firmware binary
• OTA update (where technically feasible)
• Download via GitHub Releases