Architektur

Die CRA-Automatisierung der BAUER GROUP ist auf zwei Repositories aufgeteilt:

• CRA-spezifische Workflows und Actions leben in SEC-CRACompliance (dieses Repo)
• Generische Actions (VEX-Generierung, SBOM-Attestation) leben in automation-templates

Consumer-Repositories (Ihre Produkte) rufen den CRA-Release-Workflow mit einer einzigen uses:-Zeile auf.

┌──────────────────────────────────────────┐
│          Consumer-Repo (Produkt)          │
│                                          │
│  uses: bauer-group/SEC-CRACompliance/    │
│        .github/workflows/cra-release.yml │
└──────────────────┬───────────────────────┘
                   │
    ┌──────────────┼──────────────┐
    ▼              ▼              ▼
┌─────────┐  ┌──────────┐  ┌────────────┐
│ CRA-Repo│  │ CRA-Repo │  │ Automation │
│ Actions │  │ Actions  │  │ Templates  │
├─────────┤  ├──────────┤  ├────────────┤
│ SBOM    │  │Compliance│  │ VEX        │
│ Sign    │  │ Report   │  │ Attestation│
│ Scan    │  │          │  │            │
│ Hub     │  │          │  │            │
└─────────┘  └──────────┘  └────────────┘
CRA-spezifisch CRA-spezifisch  Generisch

Reusable Workflows

cra-release.yml — Release-Artefakte

Der primäre Workflow. Erzeugt, signiert und archiviert alle CRA-Artefakte bei einem Release.

Verwendung (Zero-Config):

jobs:
  cra:
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

Pipeline-Ablauf:

cra-scan.yml — Geplanter Vulnerability Scan

Für kontinuierliches CVE-Monitoring (Art. 10 Abs. 8). Täglich per Cron-Schedule ausführen.

cra-report.yml — Hub-API-Report

Sendet Compliance-Daten an die Software Security Hub API zur zentralen Erfassung.

Vollständiger Consumer-Workflow

Minimal (Zero-Config)

Funktioniert ohne Konfiguration für jedes Repository. Alle Features mit Defaults aktiviert.

# .github/workflows/cra.yml
name: CRA Compliance

on:
  release:
    types: [published]
  schedule:
    - cron: '0 6 * * 1'  # Wöchentlich Montag 06:00 UTC
  workflow_dispatch:

permissions:
  contents: write
  id-token: write
  attestations: write
  security-events: write
  issues: write

jobs:
  # Bei Release: Vollständige CRA-Pipeline
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

  # Wöchentlich: CVE-Scan
  cra-scan:
    if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    permissions:
      contents: read
      security-events: write
      issues: write

Vollständige Konfiguration (alle Parameter)

Für Produkte mit spezifischen Anforderungen — Node.js-Validierung, Class I, Grype-Scanning, etc.

# .github/workflows/cra.yml
name: CRA Compliance

on:
  release:
    types: [published]
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:

permissions:
  contents: write
  id-token: write
  attestations: write
  security-events: write
  issues: write

jobs:
  # ── Release: Vollständige CRA-Pipeline ──
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    with:
      # Validierung
      run-validation: true              # Lint/Build vor CRA-Artefakten
      node-version: '24'                # Node.js-Version
      validation-command: 'npm run ci'  # Validierungsbefehl

      # SBOM & Scanning
      scan-target: '.'                  # Verzeichnis, Image-Ref oder SBOM-Pfad
      scan-type: 'auto'                 # auto | fs | image | sbom
      sign-sbom: true                   # Cosign Keyless Signing
      fail-on-critical: true            # Release bei CRITICAL CVEs blockieren
      enable-grype: true                # Zusätzlicher Grype-Scan
      enable-osv: true                  # Zusätzlicher OSV-Scanner

      # Attestation & VEX
      attest-sbom: true                 # GitHub-native SBOM-Attestation
      generate-vex: true                # OpenVEX-Dokument
      vex-overrides: 'security/vex-overrides.json'

      # Compliance-Report
      generate-compliance-report: true
      support-period-years: 5           # Art. 13(8): mindestens 5 Jahre

      # EU-Konformitätserklärung
      generate-eu-doc: true             # Annex V JSON
      render-pdfs: true                 # JSON → PDF-Rendering
      classification: 'important-class-1'  # standard | important-class-1 | important-class-2 | critical
      conformity-module: 'module-a'     # module-a | module-b-c | module-h | eucc
      manufacturer-name: 'BAUER GROUP GmbH'

      # Release
      upload-to-release: true
      retention-days: 90
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

  # ── Wöchentlich: CVE-Scan ──
  cra-scan:
    if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    with:
      severity-threshold: 'MEDIUM'
      fail-on-critical: false
      create-issue: true
      enable-grype: true
      enable-osv: true
    permissions:
      contents: read
      security-events: write
      issues: write

  # ── Nach Release: An Hub melden ──
  cra-report:
    if: github.event_name == 'release'
    needs: [cra-release]
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-report.yml@main
    with:
      dry-run: true                     # Auf false setzen wenn Hub betriebsbereit
    permissions:
      contents: read
      id-token: write

Docker / Container Image

Für Produkte die Container-Images bauen — scannt das Image statt des Dateisystems.

jobs:
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    with:
      scan-target: 'ghcr.io/bauer-group/my-app:${{ github.ref_name }}'
      scan-type: 'image'
      classification: 'important-class-2'
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

Parameter-Referenz

cra-release.yml

cra-scan.yml

Benötigte Permissions

VEX-Triage

Erstellen Sie security/vex-overrides.json in Ihrem Produkt-Repo für manuelle Triage-Entscheidungen:

Compliance-Scoring

8.1.1 Tool → CRA-Anforderungsmatrix

Diese Zuordnung zeigt, welches Tool welche CRA-Anforderungen abdeckt.

8.1.2 GitHub Ecosystem

Dependabot

GitHub Security Advisories

GitHub Actions (Automation-Templates)

8.1.3 Security Scanning

Trivy (Aqua Security)

Grype (Anchore)

OSV-Scanner (Google)

Snyk

Gitleaks + GitGuardian

8.1.4 SBOM & Compliance

Syft (Anchore)

FOSSA / License Compliance

8.1.5 Signing & Integrity

Cosign (Sigstore)

8.1.6 CRA Compliance Workflows (dieses Repository)

Zusätzlich zu den Automation-Templates stellt dieses Repository dedizierte CRA-Workflows bereit, die in jedem Quellcode-Repository wiederverwendet werden können. Siehe 8.2 Automatisierte Workflows für Details.

Composite Actions (CRA-spezifisch)

Composite Actions (Generisch, in automation-templates)

Reusable Workflows

CLI-Tool

8.1.7 Geplante Erweiterungen

8.1.8 Zusammenfassung: CRA-Abdeckung durch Tooling

                         CRA-Anforderung
                    ┌─────────────────────────┐
                    │  Art. 10 (Hersteller)    │
                    │  ├── Abs. 1 (Security)   │──→ Trivy, Gitleaks, Code Review
                    │  ├── Abs. 2 (Risiko)     │──→ Manuell + Template
                    │  ├── Abs. 4 (3rd Party)  │──→ FOSSA, License Compliance
                    │  ├── Abs. 6 (Schwachst.) │──→ CVE-Monitor, Dependabot
                    │  ├── Abs. 7 (Updates)    │──→ Dependabot, CI/CD
                    │  ├── Abs. 8 (Keine CVEs) │──→ CVE-Monitor, Trivy
                    │  ├── Abs. 9 (CVD)        │──→ GitHub Advisories
                    │  ├── Abs. 12 (Integrität)│──→ Cosign + Attestation
                    │  └── Abs. 16 (Support)   │──→ SECURITY.md
                    ├─────────────────────────┤
                    │  Art. 13 (Information)    │
                    │  ├── Abs. 6 (CVD-Policy)  │──→ SECURITY.md
                    │  └── Abs. 23 (SBOM)      │──→ Trivy/Syft
                    ├─────────────────────────┤
                    │  Art. 14 (Meldepflicht)   │
                    │  ├── 24h Frühwarnung      │──→ ENISA SRP + Teams
                    │  ├── 72h Meldung          │──→ ENISA SRP
                    │  └── Nutzer-Info          │──→ GitHub Advisory
                    └─────────────────────────┘

Übersicht

cra-check ist ein Zero-Dependency Node.js CLI-Tool zur Prüfung der CRA-Compliance eines Produkts. Es prüft Vorhandensein und Qualität von Compliance-Artefakten — SBOM, VEX, Vulnerability Scans, Sicherheitsrichtlinien und Supportzeitraum.

Verwendung

# Aktuelles Verzeichnis prüfen
npx @bauer-group/cra-check

# GitHub-Repository prüfen (neuestes Release)
npx @bauer-group/cra-check bauer-group/mein-produkt

# JSON-Ausgabe für Automatisierung
npx @bauer-group/cra-check --format json

# CI-Modus (Exit-Code 1 bei Unterschreitung)
npx @bauer-group/cra-check --ci --min-score 70

Modi

Lokaler Modus

Durchsucht das Dateisystem nach CRA-Artefakten:

Remote-Modus

Ruft Daten über die GitHub API ab — Release-Assets, Signaturen, SECURITY.md.

Ausgabe

  CRA Compliance: mein-produkt v2.3.1
  ══════════════════════════════════════════

  SBOM                ✅ PASS  CycloneDX, 142 Komponenten
  SBOM Signiert       ✅ PASS  Cosign-Signatur + Zertifikat vorhanden
  VEX-Dokument        ✅ PASS  15 Statements (3 bewertet)
  Schwachstellen      ⚠️ WARN  0 kritisch, 2 hoch, 5 mittel, 3 niedrig
  Sicherheitsrichtl.  ✅ PASS  SECURITY.md mit CVD-Prozess
  Supportzeitraum     ✅ PASS  5 Jahre

  Score: 85/100 ████████████████░░░░ PASS

CI/CD-Integration

- name: 🔍 CRA Compliance Check
  run: npx @bauer-group/cra-check --ci --min-score 70
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Exit-Codes

Optionen

Voraussetzungen

• Node.js >= 20
• Keine npm-Abhängigkeiten

Vollständige Zuordnung: CRA-Artikel → Dokumentation → Tooling

Diese Matrix ordnet jede relevante CRA-Anforderung der entsprechenden Dokumentation und dem implementierten Tooling zu. Sie dient als zentrale Referenz für Audits und Konformitätsprüfungen.

Detaillierte Zuordnung: 8.1 Tooling-Zuordnung (Tool → CRA-Anforderung)

Pflichten nach Wirtschaftsakteur-Rolle

Geschätzter Aufwand nach Produktklasse

* Klasse I: Selbstbewertung bei vollständiger Anwendung harmonisierter Normen; sonst Drittbewertung.

Art. 10 – Pflichten der Hersteller

Art. 13 – Informationspflichten

Art. 14 – Meldepflichten

Art. 16 – Bevollmächtigter (EU Authorized Representative)

Art. 28 – Konformitätserklärung & CE

Annex I, Teil I – Sicherheitsanforderungen

Annex I, Teil II – Schwachstellenbehandlung

Annex II – Nutzerinformation

Annex VII – Technische Dokumentation

Legende

7.1.1 Übersicht

Jedes Produkt mit digitalen Elementen muss gemäß dem Cyber Resilience Act (CRA) in eine Risikokategorie eingestuft werden. Die Einstufung bestimmt das erforderliche Konformitätsbewertungsverfahren. Der CRA unterscheidet vier Kategorien: Standard, Klasse I (Wichtig), Klasse II (Wichtig) und Kritisch.

7.1.2 Entscheidungsbaum zur Klassifizierung

Der folgende Entscheidungsbaum zeigt den systematischen Ablauf der Produktklassifizierung:

Ist das Produkt in Annex IV aufgeführt?
├── Ja → KRITISCH (EUCC erforderlich)
└── Nein
    └── Ist das Produkt in Annex III aufgeführt?
        ├── Ja → Welche Klasse?
        │   ├── Klasse II → KLASSE II (Modul B+C oder H)
        │   └── Klasse I → KLASSE I (Modul A* oder B+C)
        └── Nein → STANDARD (Modul A)

* Modul A nur bei vollständiger Anwendung harmonisierter Normen

7.1.3 Produktkategorien

Kategorie: Standard (Default)

Konformitätsbewertung: Interne Kontrolle (Modul A) – Selbstbewertung

Die Mehrheit der Produkte fällt in diese Kategorie. Der Hersteller führt die Konformitätsbewertung selbst durch.

Typische Produkte:

• Standard-Webanwendungen
• Interne Tools und Utilities
• Nicht-kritische Container-Images
• Einfache IoT-Sensoren

Klasse I (Annex III)

Konformitätsbewertung: Interne Kontrolle (Modul A) mit Anwendung harmonisierter Normen ODER EU-Baumusterprüfung (Modul B+C)

Beispiele aus Annex III:

• Identity Management Systeme und Software für privilegierten Zugang
• Browser (eigenständig)
• Passwort-Manager
• Software zur Suche, Entfernung und Quarantäne von Schadsoftware
• VPN-Produkte
• Netzwerk-Management-Systeme
• SIEM-Systeme
• Boot-Manager
• Firewalls, IDS/IPS (nicht-industriell)
• Router, Modems (für Internetzugang)
• Mikrocontroller mit sicherheitsrelevanten Funktionen
• Betriebssysteme (nicht für Server/Desktop-Klasse II)

Klasse II (Annex III)

Konformitätsbewertung: EU-Baumusterprüfung (Modul B+C) ODER Umfassende Qualitätssicherung (Modul H)

Beispiele aus Annex III:

• Hypervisor und Container-Laufzeitumgebungen
• Firewalls und IDS/IPS für industrielle Nutzung
• Tamper-Resistant Mikrocontroller/-prozessoren
• Betriebssysteme für Server, Desktop, Mobile
• Public-Key-Infrastruktur und Zertifikatsaussteller
• Industrielle Automatisierungs- und Steuerungssysteme (IACS)
• Industrielle IoT-Geräte (nicht unter andere sektorale Regulierung)

Kategorie: Kritisch (Annex IV)

Konformitätsbewertung: Europäisches Cybersicherheitszertifikat (EUCC) auf Vertrauenswürdigkeitsstufe „substanziell" oder höher

Beispiele aus Annex IV:

• Hardware-Sicherheitsmodule (HSM)
• Smartcards und ähnliche Geräte (inkl. Secure Elements)
• Smartcard-Leser
• Sensoren und Aktoren für Roboter und Maschinensteuerungen
• Smart Meter Gateways

7.1.4 Konformitätsbewertung je Kategorie

* Nur bei Anwendung harmonisierter Normen oder bei Konformität mit EU-Cybersicherheitszertifizierung

7.1.5 Relevante Produkttypen für BAUER GROUP

Prüfung gegen Annex III (Wichtige Produkte)

Prüfung gegen Annex IV (Kritische Produkte)

Typische Klassifizierung für BAUER GROUP Produkte

7.1.6 Klassifizierungsprozess

Für jedes Produkt ist folgender Prozess durchzuführen:

1. Funktionsprüfung

Prüfen Sie, ob das Produkt eine der in Annex III oder IV genannten Funktionen erfüllt. Gleichen Sie systematisch alle Kategorien ab.

2. Verwendungszweck

Berücksichtigen Sie den bestimmungsgemäßen Verwendungszweck:

• Wird das Produkt in kritischer Infrastruktur eingesetzt?
• Verarbeitet es sensible/personenbezogene Daten?
• Hat es Netzwerkfunktionalität?
• Kann eine Kompromittierung physische Schäden verursachen?

3. Einstufung dokumentieren

Verwenden Sie das Template Risikobewertung zur Dokumentation der Klassifizierungsentscheidung.

7.1.7 Dokumentation der Klassifizierung

Für jedes Produkt wird die Klassifizierung in der Produktbeschreibung dokumentiert:

1. Prüfung gegen Annex III und IV -- Systematisches Abgleichen aller Kategorien
2. Begründung -- Warum diese Klassifizierung (mit Verweis auf Annex)
3. Konformitätsbewertungsverfahren -- Welches Modul angewendet wird
4. Datum -- Wann die Klassifizierung durchgeführt wurde
5. Verantwortlicher -- Wer die Klassifizierung durchgeführt hat

4.3.1 Rechtsgrundlage

Gemäß Art. 14 CRA sind Hersteller verpflichtet, bestimmte Sicherheitsereignisse an ENISA bzw. die zuständige nationale CSIRT-Behörde zu melden. Die Meldepflicht gilt ab dem 11. September 2026.

4.3.2 Meldepflichtige Ereignisse

Aktiv ausgenutzte Schwachstelle (Art. 14 Abs. 1)

Eine Schwachstelle in einem Produkt der BAUER GROUP wird in freier Wildbahn aktiv ausgenutzt. Gemäß Art. 3 Nr. 42 CRA liegt eine aktive Ausnutzung vor, wenn zuverlässige Belege existieren, dass die Schwachstelle von einem böswilligen Akteur in einem System ohne Erlaubnis des Eigentümers ausgenutzt wurde.

Indikatoren für aktive Ausnutzung:

• Aufnahme in den KEV-Katalog (CISA Known Exploited Vulnerabilities)
• Threat-Intelligence-Feeds berichten über Exploitation-Aktivitäten
• Meldung durch Kunden oder Sicherheitsforscher mit Nachweis der Ausnutzung
• Eigene Erkennung in Logs, Monitoring oder Incident-Response-Prozessen
• Öffentliche Berichte (Vendor Advisories, Blogs, Foren) über Angriffe

Schwerer Sicherheitsvorfall (Art. 14 Abs. 3)

Ein Vorfall, der die Sicherheit des Produkts oder seiner Nutzer erheblich beeinträchtigt (Art. 3 Nr. 43 CRA).

Kriterien für die Einstufung als schwerer Vorfall:

4.3.3 Rollen und Verantwortlichkeiten

4.3.4 Meldeplattform

ENISA Single Reporting Platform (SRP)

Ab dem 11. September 2026 steht die ENISA Single Reporting Platform als zentrale Meldestelle zur Verfügung:

Nationale CSIRTs der EU-Mitgliedstaaten

Falls die ENISA SRP temporär nicht verfügbar ist, erfolgt die Meldung an das zuständige nationale CSIRT. Nachfolgend das vollständige Verzeichnis aller 27 EU-Mitgliedstaaten:

Quelle: ENISA CSIRTs Network / ENISA CSIRT Inventory. Stand: 2026-02. Aktuelle Kontaktdaten vor Erstmeldung verifizieren.

4.3.5 Meldeprozess

Phase 1: Frühwarnung (≤ 24 Stunden)

Verantwortlich: Security Lead

Aktiv ausgenutzte Schwachstelle / schwerer Vorfall erkannt
    │
    ├── 1. Sofortbenachrichtigung
    │   ├── Security Lead alarmieren (sofort, jede Uhrzeit)
    │   └── Incident-Ticket erstellen (GitHub Issue, Label: incident + enisa)
    │
    ├── 2. Erstbewertung (≤ 2 Stunden)
    │   ├── Schwachstelle / Vorfall bestätigen
    │   ├── Betroffene Produkte und Versionen identifizieren
    │   ├── Aktive Ausnutzung verifizieren (KEV, Threat Intel)
    │   ├── Schweregrad bestimmen (CVSS)
    │   └── ENISA-Meldepflicht bestätigen
    │
    ├── 3. ENISA-Frühwarnung absenden (≤ 24h)
    │   ├── Template: /templates/enisa-early-warning
    │   ├── Plattform: ENISA SRP (primär) oder CSIRT (Fallback)
    │   └── Mindestinhalt gemäß Art. 14 Abs. 1:
    │       ├── Hersteller-Identifikation
    │       ├── Betroffenes Produkt / betroffene Versionen
    │       ├── Art der Schwachstelle / des Vorfalls
    │       ├── Schweregrad (CVSS Score + Vector)
    │       ├── Bestätigung der aktiven Ausnutzung
    │       ├── Erste Einschätzung der Auswirkung
    │       └── Geplante Sofortmaßnahmen
    │
    └── 4. Parallele Maßnahmen
        ├── Kommunikationsplan aktivieren (→ 5.4)
        ├── Management informieren (bei SEV-1/SEV-2)
        └── Sofortmaßnahmen einleiten (Workaround, Isolation)

Nachweis: Screenshot der Meldungsbestätigung + Zeitstempel im Incident-Ticket

Phase 2: Schwachstellenmeldung (≤ 72 Stunden)

Verantwortlich: Security Lead + DevOps Lead

Detailbewertung läuft / abgeschlossen
    │
    ├── 1. Technische Analyse vertiefen
    │   ├── Vollständige Versionsliste der betroffenen Produkte
    │   ├── CWE-Klassifikation zuweisen
    │   ├── CVSS v3.1 Vector vollständig berechnen
    │   ├── Angriffsvektor und Voraussetzungen dokumentieren
    │   └── Ausnutzungsszenarien beschreiben
    │
    ├── 2. Maßnahmen dokumentieren
    │   ├── Bereits ergriffene Mitigationsmaßnahmen
    │   ├── Status der Patch-Entwicklung
    │   ├── Verfügbare Workarounds
    │   └── Empfohlene Nutzermaßnahmen
    │
    └── 3. ENISA-Meldung absenden (≤ 72h)
        ├── Template: /templates/enisa-notification
        ├── Plattform: ENISA SRP
        └── Mindestinhalt gemäß Art. 14 Abs. 2:
            ├── Bezug zur Frühwarnung
            ├── Detaillierte Schwachstellenbeschreibung
            ├── CVE-ID (falls bereits zugewiesen)
            ├── Alle betroffenen Produktversionen
            ├── CWE-Klassifikation + CVSS Vector
            ├── Technische Details (Attack Vector, Impact)
            ├── Status ergriffener Mitigationsmaßnahmen
            ├── Verfügbarer Patch / Workaround
            ├── Empfohlene Nutzermaßnahmen
            └── Geschätzte Anzahl betroffener Nutzer / Geräte

Nachweis: Meldungsbestätigung + vollständige Kopie im Incident-Ticket

Phase 3: Abschlussbericht (≤ 14 Tage)

Verantwortlich: Security Lead

Behebung abgeschlossen oder fortgeschritten
    │
    ├── 1. Abschlussdokumentation erstellen
    │   ├── Root-Cause-Analyse abschließen
    │   ├── Vollständige Zeitlinie des Vorfalls erstellen
    │   ├── Alle ergriffenen Maßnahmen auflisten
    │   ├── Bereitgestellte Patches / Updates benennen
    │   ├── Verbleibende Risiken bewerten
    │   └── Lessons Learned formulieren
    │
    └── 2. ENISA-Abschlussbericht absenden (≤ 14 Tage)
        ├── Template: /templates/enisa-final-report
        ├── Plattform: ENISA SRP
        └── Mindestinhalt gemäß Art. 14 Abs. 3:
            ├── Bezug zu Frühwarnung und Meldung
            ├── Detaillierte Schwachstellenbeschreibung
            ├── Root-Cause-Analyse
            ├── Vollständige Ereigniszeitlinie
            ├── Alle ergriffenen Korrekturmaßnahmen
            ├── Bereitgestellte Patches / Updates (mit Versionsnummern)
            ├── Verbleibende Risiken und deren Mitigation
            ├── Kompromittierungsindikatoren (IoC), falls vorhanden
            ├── Lessons Learned
            └── Maßnahmen zur Vermeidung künftiger Vorfälle

Nachweis: Meldungsbestätigung + vollständige Kopie im Incident-Ticket + Archivierung

4.3.6 Nutzerbenachrichtigung (Art. 14 Abs. 8)

Parallel zur ENISA-Meldung müssen betroffene Nutzer unverzüglich über die Schwachstelle und verfügbare Korrekturmaßnahmen informiert werden.

4.3.7 Dokumentation und Nachweisführung

Jede ENISA-Meldung wird vollständig dokumentiert. Diese Dokumentation dient als Nachweis der Pflichterfüllung gegenüber Marktaufsichtsbehörden (Art. 52 CRA).

Pflichtdokumentation je Meldung

Referenzierungsschema

Alle Meldungen verwenden ein einheitliches Referenzierungsschema:

4.3.8 Vorbereitungsmaßnahmen (vor 11.09.2026)

Die folgenden Maßnahmen müssen vor dem Inkrafttreten der Meldepflicht abgeschlossen sein:

4.3.9 Entscheidungsbaum: Meldepflicht

Sicherheitsereignis erkannt
    │
    ├── Ist eine Schwachstelle in unserem Produkt betroffen?
    │   ├── Nein → Keine CRA-Meldepflicht (ggf. NIS2 prüfen)
    │   └── Ja ↓
    │
    ├── Wird die Schwachstelle aktiv ausgenutzt?
    │   ├── Ja → MELDEPFLICHTIG (Art. 14 Abs. 1)
    │   │         → 24h Frühwarnung + 72h Meldung + 14d Abschlussbericht
    │   └── Nein ↓
    │
    ├── Liegt ein schwerer Sicherheitsvorfall vor?
    │   ├── Ja → MELDEPFLICHTIG (Art. 14 Abs. 3)
    │   │         → 24h Frühwarnung + 72h Meldung + 14d Abschlussbericht
    │   └── Nein ↓
    │
    └── Standardmäßige Schwachstellenbehandlung
        → Vulnerability Management (→ Kap. 3)
        → Patch Management gemäß SLA
        → Keine ENISA-Meldepflicht

Dokumentenlenkung

Hinweis: Dies ist die öffentliche Version dieses Dokuments. Personenbezogene Daten (Namen, Kontaktdaten) werden in dieser Fassung nicht aufgeführt und sind ausschließlich in der internen Version enthalten.

Änderungshistorie

Verbindlichkeit

Dieses Handbuch ist verbindlich für alle Mitarbeiter der BAUER GROUP, die an Entwicklung, Betrieb, Vertrieb oder Support von Produkten mit digitalen Elementen beteiligt sind. Abweichungen von den hier beschriebenen Prozessen bedürfen der schriftlichen Genehmigung durch den Security Lead und das Management.

Verordnung (EU) 2024/2847 – Cyber Resilience Act

Der Cyber Resilience Act (CRA) ist die EU-Verordnung über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Er wurde am 20. November 2024 im Amtsblatt der Europäischen Union veröffentlicht (ABl. L, 2024/2847) und trat am 10. Dezember 2024 in Kraft.

Der CRA gilt unmittelbar in allen EU-Mitgliedstaaten und begründet verbindliche Pflichten für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen.

Rechtscharakter

Ziel und Zweck

Der CRA verfolgt zwei Kernziele:

1. Sicherheitsanforderungen an Produkte (Annex I Teil I) – Produkte mit digitalen Elementen dürfen nur auf dem EU-Markt bereitgestellt werden, wenn sie die wesentlichen Cybersicherheitsanforderungen erfüllen. Dies umfasst Security-by-Design, Vertraulichkeit, Integrität, Verfügbarkeit und Minimalität der Angriffsfläche.

2. Schwachstellenbehandlung (Annex I Teil II) – Hersteller müssen während des gesamten Support-Zeitraums (mindestens 5 Jahre, Art. 13 Abs. 8) Schwachstellen systematisch identifizieren, dokumentieren, bewerten, beheben und gegenüber Nutzern und Behörden melden.

Zusammenspiel mit NIS2

Der CRA ergänzt die NIS2-Richtlinie (Richtlinie (EU) 2022/2555). Während NIS2 die Cybersicherheit von Betreibern wesentlicher und wichtiger Einrichtungen regelt, adressiert der CRA die Sicherheit der von diesen Einrichtungen eingesetzten Produkte. Die Meldepflichten des CRA (Art. 14) sind an die NIS2-Meldepflichten (Art. 23 NIS2) angelehnt und laufen über die gleiche ENISA-Meldeplattform.

Geltungsbereich

Gemäß Art. 2 CRA gilt diese Verordnung für Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netzwerk umfasst.

Für die BAUER GROUP betrifft dies:

• Software – Eigenständige Applikationen, Microservices, APIs, Container-Images
• Firmware – Eingebettete Systeme (ESP32, STM32, Zephyr RTOS)
• Bibliotheken – Öffentlich veröffentlichte NPM- und NuGet-Pakete
• Hardware mit Software – IoT-Geräte, industrielle Steuerungen
• Remote-Datenverarbeitung – Cloud-Komponenten, die integraler Bestandteil eines Produkts sind

Detaillierte Produktkategorien und Ausnahmen: siehe 1.1 Geltungsbereich & Produkte.

Unterseiten dieses Kapitels

Struktur dieses Handbuchs

Dieses Handbuch ist nach den Kernprozessen des CRA gegliedert. Jedes Kapitel behandelt einen abgegrenzten Compliance-Bereich mit Rechtsgrundlage, Prozessbeschreibung und operativer Umsetzung:

Toolchain

Die BAUER GROUP setzt auf eine durchgehend automatisierte Toolchain, um CRA-Konformität ohne manuellen Mehraufwand sicherzustellen:

Regulatorische Referenzen

Begriffe und Definitionen

Verwenden Sie diesen Entscheidungsbaum, um festzustellen, ob der Cyber Resilience Act auf Ihr Produkt anwendbar ist und welcher Konformitätsweg einzuschlagen ist.

Entscheidungsbaum

Gate 1: Produkt mit digitalen Elementen?

┌───────────────────────────────────────────────┐
│ Enthält das Produkt digitale Elemente?        │
│ (Software, Firmware oder Hardware mit         │
│ logischer Datenverbindung — Art. 3(1) CRA)    │
│                                               │
│   NEIN → CRA nicht anwendbar → STOP          │
│   JA   ↓                                     │
└───────────────────────────────────────────────┘

„Produkt mit digitalen Elementen" bezeichnet jedes Software- oder Hardwareprodukt und seine Lösungen zur Ferndatenverarbeitung, einschließlich separat in Verkehr gebrachter Software- oder Hardwarekomponenten (Art. 3(1) CRA).

Gate 2: Ausnahmen (Art. 2(2))

┌───────────────────────────────────────────────┐
│ Trifft eine der folgenden Ausnahmen zu?       │
│                                               │
│ ☐ Medizinprodukt (VO 2017/745, 2017/746)     │
│ ☐ Kraftfahrzeug (VO 2019/2144)               │
│ ☐ Luftfahrt (VO 2018/1139)                   │
│ ☐ Schiffsausrüstung (RL 2014/90/EU)          │
│ ☐ Nationale Sicherheit / Militärprodukt      │
│ ☐ Reines SaaS ohne Produktkomponente         │
│                                               │
│   JA   → CRA nicht anwendbar (sektorale      │
│           Regulierung gilt) → STOP            │
│   NEIN ↓                                     │
└───────────────────────────────────────────────┘

Gate 3: Open-Source-Bewertung (Art. 18–19)

┌───────────────────────────────────────────────┐
│ Handelt es sich um Open-Source-Software?      │
│                                               │
│   NEIN → Weiter zu Gate 4 ↓                  │
│   JA   → Liegt eine kommerzielle Aktivität    │
│           vor? (Verkauf, bezahlter Support,    │
│           monetarisierte Integration, SaaS)    │
│                                               │
│     NEIN → CRA nicht anwendbar → STOP         │
│     JA   → Open-Source-Steward-Pflichten      │
│             gelten (Art. 18–19) → Weiter ↓   │
└───────────────────────────────────────────────┘

Gate 4: Produktklassifizierung (Art. 6–7, Annex III & IV)

┌───────────────────────────────────────────────┐
│ Ist das Produkt in Annex IV gelistet?         │
│                                               │
│   JA   → KRITISCH                             │
│          → EUCC-Zertifizierung erforderlich   │
│          → Siehe: Konformität / EUCC           │
│   NEIN ↓                                     │
├───────────────────────────────────────────────┤
│ Ist das Produkt in Annex III gelistet?        │
│                                               │
│   JA   → Welche Klasse?                       │
│     Klasse II → Modul B+C oder Modul H        │
│                 → Siehe: Konformität / Modul B+C│
│     Klasse I  → Modul A (mit hEN) oder B+C    │
│                 → Siehe: Konformität / Modul A  │
│   NEIN ↓                                     │
├───────────────────────────────────────────────┤
│ STANDARD (Standardkategorie)                  │
│ → Modul A (Selbstbewertung)                   │
│ → Siehe: Konformität / Selbstbewertung         │
└───────────────────────────────────────────────┘

Ergebnisübersicht

Geschätzter Compliance-Aufwand

* Klasse I erfordert nur dann eine Drittbewertung, wenn harmonisierte Normen nicht vollständig angewendet werden.

Nächste Schritte

Basierend auf Ihrem Klassifizierungsergebnis:

1. Entscheidung dokumentieren → Produktklassifizierungs-Protokoll
2. Konformitätsverfahren starten → Konformitätsbewertung Übersicht
3. Dokumentation vorbereiten → Technische Dokumentation
4. Meldewesen einrichten → ENISA-Meldeprozess

1. Produktidentifikation

2. Anwendbarkeits-Bewertung

Ergebnis Anwendbarkeit: [ ] CRA anwendbar / [ ] CRA nicht anwendbar

Falls nicht anwendbar, Begründung: ___

3. Produktklassifizierung

3.1 Annex-IV-Prüfung (Kritische Produkte)

Annex-IV-Ergebnis: [ ] Gelistet (→ Kritisch) / [ ] Nicht gelistet (→ weiter)

3.2 Annex-III-Prüfung (Wichtige Produkte)

Annex-III-Ergebnis: [ ] Klasse II / [ ] Klasse I / [ ] Nicht gelistet (→ Standard)

3.3 Klassifizierungsergebnis

4. Konformitätsbewertungsweg

5. Freigabe

Übersicht

Das Incident Response Framework deckt die vollständigen CRA-Meldepflichten ab. Ab dem 11. September 2026 sind Hersteller verpflichtet, aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle an ENISA bzw. die zuständige nationale Behörde zu melden.

Meldepflichten-Übersicht

Kapitelstruktur

1.14.1 Übersicht

Der Cyber Resilience Act (CRA) und die NIS2-Richtlinie (Richtlinie (EU) 2022/2555) sind komplementäre EU-Regulierungen zur Cybersicherheit. Während der CRA Produkte reguliert, betrifft NIS2 Betreiber (wesentliche und wichtige Einrichtungen). Unternehmen wie BAUER GROUP können beiden Regulierungen gleichzeitig unterliegen.

Die vollständige NIS2-Compliance-Dokumentation der BAUER GROUP ist verfügbar unter nis2.docs.bauer-group.com.

1.14.2 Abgrenzung CRA vs. NIS2

1.14.3 Entscheidungsbaum: Welche Regulierung gilt?

Stellt BAUER GROUP Produkte mit digitalen Elementen her?
├── Ja → CRA gilt (als Hersteller)
│   └── Sind die Produkte SaaS (rein cloudbasiert)?
│       ├── Ja → CRA gilt NICHT für SaaS
│       │   └── NIS2 prüfen (als Betreiber)
│       └── Nein → CRA gilt
└── Nein → CRA gilt nicht als Hersteller

Ist BAUER GROUP eine wesentliche oder wichtige Einrichtung?
├── Ja → NIS2 gilt (als Betreiber)
│   └── Branche prüfen (Annex I/II der NIS2)
└── Nein → NIS2 gilt nicht

1.14.4 Überlappende Anforderungen

Schwachstellenmanagement

→ Synergie: CRA-konforme Schwachstellenbehandlung erfüllt weitgehend auch NIS2 Art. 21 Abs. 2 (e).

Meldepflichten

→ CRA-Meldeprozess: ENISA-Meldeprozess

Supply-Chain-Sicherheit

→ Synergie: CRA-konforme Supply-Chain-Prozesse erfüllen auch NIS2 Art. 21 Abs. 2 (d) Lieferkettenanforderungen.

Incident Response

→ Gap: NIS2 fordert explizit Business Continuity und Krisenmanagement, der CRA fokussiert auf Produktsicherheit.

1.14.5 Kombinierte Compliance-Strategie

Schritt 1: Geltungsbereich bestimmen

Schritt 2: Synergien nutzen

Folgende Prozesse decken beide Regulierungen ab:

1. Schwachstellenmanagement → Vulnerability Management
2. Incident Response → Incident Response
3. Supply-Chain-Sicherheit → Supply Chain
4. SBOM-Management → SBOM & Signierung

Schritt 3: NIS2-spezifische Ergänzungen

Über den CRA hinausgehende NIS2-Anforderungen:

Schritt 4: Einheitliche Meldeprozesse

Für Unternehmen, die beiden Regulierungen unterliegen:

1. Gemeinsamer Erstbewertungsprozess für Vorfälle
2. Parallele Meldung an CRA- und NIS2-Stellen (bis einheitliche Plattform verfügbar)
3. Einheitliche Templates (ENISA Frühwarnung)
4. Dokumentierte Entscheidungslogik: Welcher Vorfall löst welche Meldepflicht aus

1.14.6 Zeitstrahl

Übersicht

Die Absicherung der Software-Lieferkette ist eine zentrale CRA-Anforderung. Hersteller müssen Sorgfaltspflichten bei der Integration von Drittkomponenten erfüllen und die Integrität der gesamten Lieferkette gewährleisten.

Sicherheitsmaßnahmen

Implementierte Maßnahmen

Kapitelstruktur

Übersicht

Das Schwachstellenmanagement ist eine der Kernpflichten des CRA. Hersteller müssen während des gesamten Support-Zeitraums Schwachstellen in ihren Produkten identifizieren, bewerten, beheben und melden.

Prozessarchitektur

                         ┌─────────────────────┐
                         │  SBOM (pro Release)  │
                         └──────────┬──────────┘
                                    │
              ┌──────────┬──────────┼──────────┬──────────┐
              ▼          ▼          ▼          ▼          ▼
    ┌──────────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
    │CVE-Monitoring│ │Dependa-│ │ Trivy  │ │  OSV-  │ │ Grype  │
    │(tägl. SBOM)  │ │  bot   │ │ Scan   │ │Scanner │ │(option)│
    │              │ │(PR)    │ │(CI/CD) │ │(CI/CD) │ │        │
    └──────┬───────┘ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘
           │             │          │          │          │
           └─────────────┴──────────┼──────────┴──────────┘
                                    ▼
                         ┌──────────────────────┐
                         │  Triage & Bewertung   │
                         │  (CVSS / Severity)    │
                         └──────────┬───────────┘
                                    │
                   ┌────────────────┼────────────────┐
                   ▼                ▼                 ▼
         ┌─────────────────┐ ┌──────────────┐ ┌──────────────┐
         │  CRITICAL/HIGH   │ │  MEDIUM/LOW  │ │  Keine CVEs  │
         │  → Sofort-Patch  │ │  → Geplant   │ │  → Monitoring│
         │  → ggf. ENISA    │ │  → Nächster   │ │    fortsetzen│
         │    Meldung       │ │    Release    │ │              │
         └─────────────────┘ └──────────────┘ └──────────────┘

Kapitelstruktur

Verantwortlichkeiten

9.1.1 Zweck

Das CRA Compliance Statement ist die öffentliche Zusammenfassung aller CRA-Compliance-Artefakte eines Produkts. Es dient als zentrale Anlaufstelle für Kunden, Marktaufsichtsbehörden und interne Audits.

9.1.2 Generierungsprinzip

                    ┌──────────────────────────┐
                    │  .compliance/             │
                    │  cra-statement.json       │
                    │  (Single Source of Truth)  │
                    └─────────┬────────────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Compliance-Seite│ │ CE-Kennzeichnung│ │ Container-Labels│
│ (HTML/PDF)      │ │ (About-Dialog,  │ │ (OCI-Annotations│
│ auf Portal      │ │  README, Footer)│ │  Dockerfile)    │
└─────────────────┘ └─────────────────┘ └─────────────────┘
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ API-Endpunkt    │ │ Vereinfachte DoC│ │ Release Notes   │
│ für Behörden    │ │ (Annex VI)      │ │ Snippet         │
└─────────────────┘ └─────────────────┘ └─────────────────┘

Generierte Artefakte

CE-Kennzeichnung aus JSON

Die CE-Kennzeichnung wird aus den JSON-Feldern generiert und automatisch an den konfigurierten Stellen platziert (→ 7.7 CE-Kennzeichnung):

Generierte CE-Kennzeichnung:

  CE [1234]                              ← notified_body (falls vorhanden)
  BAUER GROUP                            ← manufacturer.name
  Musterstraße 1, 12345 Musterstadt     ← manufacturer.address
  MinIO Gateway v2.1.0                   ← product.name + product.version

Für Container Images werden zusätzlich OCI-Labels generiert:

LABEL org.opencontainers.image.ce-marking="conformant"
LABEL eu.cra.doc.url="https://go.bauer-group.com/cra-minio-gateway"
LABEL eu.cra.doc.version="1.0"
LABEL eu.cra.support.end="2031-03-01"

9.1.3 Pflichtinhalte

Folgende Informationen müssen gemäß CRA öffentlich zugänglich sein und werden im Statement gebündelt:

9.1.4 Empfohlene Struktur

Ein CRA Compliance Statement sollte folgende Abschnitte enthalten:

1. Produktidentifikation

• Produktname, Version, Typ (Software / Container / Firmware)
• CRA-Produktkategorie (Standard / Klasse I / Klasse II / Kritisch)
• Eindeutige Kennung (z.B. Package-URL, Container-Image-Referenz)

2. Herstellerangaben

• Unternehmen, Anschrift
• Sicherheitskontakt (z.B. disclosure@bauer-group.com)
• Bevollmächtigter (falls zutreffend)

3. Konformitätsstatus

• Angewandtes Konformitätsbewertungsverfahren (→ Kapitel 7)
• Link zur EU-Konformitätserklärung (Annex V)
• CE-Kennzeichnung: Status und Platzierung
• Datum der letzten Bewertung

4. Sicherheitsdokumentation

Links zu:

• SBOM (CycloneDX JSON)
• Vulnerability Disclosure Policy / SECURITY.md
• Nutzerinformation (Annex II)
• Technische Dokumentation (soweit öffentlich)

5. Support-Zeitraum

• Beginn und Ende des Support-Zeitraums
• Aktuelle Phase (Active Support / Security Support)
• Verweis auf Update-Mechanismus (→ 6.3 Update-Mechanismus)

6. Harmonisierte Normen

• Angewandte harmonisierte Normen und technische Spezifikationen
• SBOM-Format-Standard (z.B. CycloneDX v1.5)

7. Schwachstellenmanagement

• Verweis auf Vulnerability Disclosure Policy
• CVE-Monitoring-Status
• Patch-SLAs (→ 3.3 Patch Management)

9.1.5 Beispiel

So könnte ein CRA Compliance Statement für ein fiktives Produkt aussehen:

CRA COMPLIANCE STATEMENT

MinIO Gateway — Version 2.1.0

Datum: 2026-03-01 | Hersteller: BAUER GROUP

---

Feld	Wert
Produkttyp	Container Image
CRA-Kategorie	Standard
Konformitätsmodul	Modul A (Interne Kontrolle)
CE-Kennzeichnung	✅ In About-Dialog und Dokumentation
EU-Konformitätserklärung	[Link zur DoC]
SBOM	[CycloneDX JSON — GitHub Release]
SECURITY.md	[Link]
Nutzerinformation (Annex II)	[Link]
Support-Zeitraum	2026-03-01 bis 2031-03-01
Vulnerability Disclosure	disclosure@bauer-group.com

9.1.6 Platzierung

→ Details zur Publikationsstrategie: 9.2 Publikationsstrategie

9.1.7 Querverweise

9.2.1 Dual-Publication-Konzept

Compliance-Daten werden an genau einer Stelle gepflegt — im Repository des jeweiligen Produkts. Von dort werden sie automatisiert auf eine zentrale Compliance-Website publiziert.

┌────────────────────┐                ┌──────────────────────────┐
│  Produkt-Repo      │     CI/CD      │  Generierte Artefakte    │
│                    │                │                          │
│  .compliance/      │  Validierung   │  ┌── Compliance-Portal   │
│    cra-statement.  │──────────────→│  │   (HTML/PDF)           │
│    json            │  + Generierung │  ├── CE-Kennzeichnung    │
│                    │                │  │   (About, README)      │
│  (einzige Quelle)  │                │  ├── Container-Labels    │
│                    │                │  │   (OCI-Annotations)    │
│                    │                │  ├── Vereinfachte DoC     │
│                    │                │  └── API-Endpunkt         │
└────────────────────┘                └──────────────────────────┘
        ↑                                       ↑
   Entwickler pflegen                  Kunden, Behörden,
   nur das JSON                        Öffentlichkeit

9.2.2 Vorteile

9.2.3 Repository-Struktur

Jedes Produkt-Repository enthält ein .compliance/-Verzeichnis:

produkt-repo/
├── .compliance/
│   ├── cra-statement.json          # Maschinenlesbares CRA Statement
│   └── README.md                   # Kurzhinweis zur Compliance-Struktur
├── SECURITY.md                     # Vulnerability Disclosure Policy
├── docs/
│   └── compliance/
│       ├── eu-declaration.pdf      # EU-Konformitätserklärung (Annex V)
│       └── user-info.md            # Nutzerinformation (Annex II)
└── ...

Dateien im Detail

9.2.4 Website-URL-Schema

Das zentrale Compliance-Portal folgt einer einheitlichen URL-Struktur:

https://cra.app.bauer-group.com/
├── /products/                      # Produktverzeichnis
│   ├── /products/{name}/           # Produkt-Compliance-Seite
│   │   ├── /cra                    # CRA Compliance Statement
│   │   ├── /doc                    # EU-Konformitätserklärung
│   │   └── /sbom                   # SBOM-Download
│   └── ...
└── /api/                           # (Optional) API-Zugang für Behörden
    └── /api/products/{name}.json   # Maschinenlesbarer Zugang

9.2.5 Zugänglichkeit

9.2.6 CI/CD-Integration

Die Publikation wird in die bestehende CI/CD-Pipeline integriert:

Release-Tag erstellt
    │
    ├── 1. JSON-Schema-Validierung (.compliance/cra-statement.json)
    │       → Fehler = Release blockiert
    │
    ├── 2. Vollständigkeitsprüfung
    │       → Sind alle Pflichtfelder ausgefüllt?
    │       → Existieren referenzierte Dokumente (DoC, SBOM)?
    │
    ├── 3. Publikation auf Compliance-Portal
    │       → HTML generieren
    │       → PDF generieren (optional)
    │
    └── 4. Benachrichtigung
            → Slack/Teams: "Compliance Statement für {Produkt} v{Version} publiziert"

9.2.7 Querverweise

Reporting a Vulnerability

BAUER GROUP takes the security of our products seriously. If you believe you have found a security vulnerability, please report it to us as described below.

Preferred Method: GitHub Security Advisory

For each affected repository, use Security → Advisories → New Draft Advisory to report the vulnerability confidentially.

Email

Email: disclosure@bauer-group.com

Please include:

• Description of the vulnerability
• Steps to reproduce
• Affected product(s) and version(s)
• Impact assessment (if possible)
• Your contact information

What to Expect

Our Commitment

• We will not take legal action against researchers acting in good faith
• We will acknowledge your contribution (with your permission)
• We will coordinate the disclosure timeline with you
• We will provide regular status updates

Supported Versions

Please refer to the individual product documentation for supported versions and support periods.

Scope

This policy applies to all BAUER GROUP products with digital elements, including:

• Software products (web applications, APIs, libraries)
• Container images
• Firmware (ESP32, STM32, Zephyr)
• Published packages (NuGet, NPM)

Out of Scope

• Social engineering attacks
• Denial of service attacks
• Physical attacks against infrastructure
• Vulnerabilities in third-party products (report to the respective vendor)

Regulatory Framework

This security policy complies with:

• Cyber Resilience Act (EU) 2024/2847 – Art. 13 Abs. 6 & 8
• ISO/IEC 29147:2018 – Vulnerability Disclosure
• ISO/IEC 30111:2019 – Vulnerability Handling Processes

7.10.1 Übersicht

Annex II des CRA definiert die Pflichtinformationen, die der Hersteller den Nutzern des Produkts bereitstellen muss. Diese Informationen müssen klar, verständlich und in einer für den Nutzer leicht zugänglichen Weise bereitgestellt werden.

7.10.2 Pflichtinhalte

Nr. 1 – Herstellerinformationen

Anforderung: Name, eingetragener Handelsname oder eingetragene Handelsmarke und Anschrift des Herstellers.

Umsetzung:

• In jedem Produkt-Repository: README.md mit Herstellerangaben
• Auf der Produktwebseite: Impressum
• In der Software: About-Dialog oder Footer
• In der Dokumentation: Titelseite

Template-Vorgabe:

Hersteller: BAUER GROUP
Anschrift:  [Firmenadresse]
E-Mail:     [Kontakt-E-Mail]
Web:        [Produkt-URL]

Nr. 2 – Kontaktstelle

Anforderung: Einzelne Kontaktstelle, über die Schwachstellen gemeldet werden können, und die Schwachstellenbehandlungspolitik des Herstellers.

Umsetzung:

• SECURITY.md in jedem Repository (Vorlage)
• Kontakt: disclosure@bauer-group.com
• GitHub Security Advisories aktiviert
• Verweis auf Disclosure Policy

Nr. 3 – Produktidentifikation

Anforderung: Eindeutige Identifikation des Produkts: Name, Typ, Version, Charge/Seriennummer.

Umsetzung:

• Semantische Versionierung (SemVer) für alle Software
• Container-Image-Tags mit SHA-Digest
• Release Notes mit Version, Datum und Changelog
• SBOM enthält eindeutige Produktidentifikation (CPE/PURL)

Nr. 4 – Bestimmungsgemäße Verwendung

Anforderung: Bestimmungsgemäße Verwendung des Produkts, einschließlich der Sicherheitsumgebung.

Umsetzung:

• Produktbeschreibung (Referenz): Zweck, Zielgruppe, Einsatzumgebung
• Einsatzbedingungen: Betriebssystem, Netzwerk, Hardware-Anforderungen
• Sicherheitsumgebung: Voraussetzungen (Firewall, VPN, Netzwerksegmentierung)
• Einschränkungen: Explizit dokumentieren, wofür das Produkt NICHT gedacht ist

Beispiel:

Bestimmungsgemäße Verwendung: Interne Unternehmensanwendung zur
Verwaltung von [Funktion]. Ausgelegt für den Betrieb hinter einer
Unternehmens-Firewall mit authentifiziertem Zugang.

NICHT bestimmungsgemäß: Öffentlich zugänglicher Betrieb ohne
Netzwerkschutz, Einsatz in kritischer Infrastruktur (KRITIS).

Nr. 5 – Vorhersehbarer Fehlgebrauch

Anforderung: Beschreibung vorhersehbarer Fehlgebrauchsszenarien.

Umsetzung:

• Identifikation typischer Fehlgebrauchsszenarien pro Produkttyp
• Warnhinweise in der Dokumentation
• Technische Schutzmaßnahmen gegen Fehlgebrauch

Typische Fehlgebrauchsszenarien:

Nr. 6 – SBOM-Verweis

Anforderung: Hinweis auf die Verfügbarkeit des SBOM (oder URL zum Abruf).

Umsetzung:

• SBOM als Release-Asset veröffentlichen
• URL zum SBOM in der Produktdokumentation
• SBOM in maschinenlesbarem Format (CycloneDX JSON)

Template-Vorgabe:

SBOM: Verfügbar unter [Release-URL]/sbom.cdx.json
Format: CycloneDX JSON v1.6
Signiert: Ja (Cosign)

→ Details: SBOM & Signierung

Nr. 7 – Support-Zeitraum

Anforderung: Zeitraum, in dem Sicherheitsupdates bereitgestellt werden, mindestens 5 Jahre oder die erwartete Produktlebensdauer.

Umsetzung:

• Support-Zeitraum in der Produktdokumentation dokumentiert
• In SECURITY.md pro Repository
• Auf der Produktwebseite
• In den Release Notes

→ Details: Support & Lifecycle

Nr. 8 – Installationsanleitung und sichere Konfiguration

Anforderung: Anweisungen zur sicheren Installation, Konfiguration, Inbetriebnahme und Nutzung des Produkts.

Umsetzung:

• Installationsanleitung: Schritt-für-Schritt mit Sicherheitshinweisen
• Härtungsguide: Empfohlene Sicherheitskonfiguration
• Checkliste: Post-Installation Security Checklist
• Mindestanforderungen: Dokumentierte Systemvoraussetzungen

Inhalte der Installationsanleitung:

1. Systemvoraussetzungen (inkl. Sicherheitsanforderungen)
2. Installationsschritte mit Integritätsprüfung
3. Ersteinrichtung (Passwort, MFA, Netzwerk)
4. Empfohlene Sicherheitskonfiguration (Härtung)
5. Update-Konfiguration (automatisch/manuell)
6. Backup-Einrichtung

Nr. 9 – EU-Konformitätserklärung

Anforderung: Verweis auf die EU-Konformitätserklärung oder vereinfachte Version mit URL.

Umsetzung:

• URL zur EU-Konformitätserklärung in der Produktdokumentation
• Vereinfachte Version gemäß Annex VI (→ Vereinfachte DoC)

Nr. 10 – Update-Informationen

Anforderung: Informationen über Art und Ort der Sicherheitsupdates.

Umsetzung:

• Release-Kanal dokumentiert (GitHub Releases, Container Registry, OTA)
• Benachrichtigungskanal (GitHub Watch, E-Mail, RSS)
• Update-Anleitung in der Dokumentation

7.10.3 Template: Nutzerinformation

→ Ausfüllbares Template: Nutzerinformation / Product Security Info

7.10.4 Checkliste: Annex II

• [ ] Herstellerangaben im Produkt und der Dokumentation
• [ ] SECURITY.md mit Kontaktstelle und CVD-Policy
• [ ] Eindeutige Produktidentifikation (SemVer, Digest)
• [ ] Bestimmungsgemäße Verwendung dokumentiert
• [ ] Vorhersehbare Fehlgebrauchsszenarien identifiziert und adressiert
• [ ] SBOM-Verweis in der Produktdokumentation
• [ ] Support-Zeitraum definiert und kommuniziert
• [ ] Installationsanleitung mit Sicherheitshinweisen
• [ ] Verweis auf EU-Konformitätserklärung
• [ ] Update-Informationen (Kanal, Benachrichtigung, Anleitung)

7.9.1 Übersicht

Neben der vollständigen EU-Konformitätserklärung (Annex V) erlaubt der CRA eine vereinfachte Fassung gemäß Annex VI. Diese darf dem Produkt beigefügt werden, sofern die vollständige Version online abrufbar ist.

7.9.2 Wann die vereinfachte Version nutzen?

7.9.3 Pflichtinhalt (Annex VI)

Die vereinfachte EU-Konformitätserklärung muss mindestens enthalten:

1. Herstellerangaben

[Name des Herstellers]
erklärt, dass das Produkt mit digitalen Elementen

2. Produktidentifikation

[Produktname, Typ, Version]

3. Konformitätsaussage

den Bestimmungen der Verordnung (EU) 2024/2847
(Cyber Resilience Act) entspricht.

4. URL zur vollständigen Erklärung

Die vollständige EU-Konformitätserklärung ist abrufbar unter:
[URL]

7.9.4 Template: Vereinfachte EU-Konformitätserklärung

## EU-Konformitätserklärung (vereinfacht)

Die **BAUER GROUP** erklärt hiermit, dass das Produkt

**[Produktname] v[Version]**

den Bestimmungen der Verordnung (EU) 2024/2847
(Cyber Resilience Act) entspricht.

Die vollständige EU-Konformitätserklärung ist abrufbar unter:
→ [URL zur vollständigen DoC]

Support-Zeitraum: [Datum] bis [Datum]
Kontakt: [E-Mail]

7.9.5 Platzierung

Für Software-Produkte

• README.md im Repository
• About-Dialog oder Footer in der Anwendung
• Release Notes pro Version
• Produktwebseite
• Container-Image Labels (OCI Annotations)

Für Firmware / Hardware

• Verpackung (Aufdruck oder Beilage)
• Quick Start Guide
• Produktetikett (QR-Code mit URL)

7.9.6 Beispiel für Container-Image Label

LABEL eu.cra.doc.url="https://go.bauer-group.com/cra-[produkt]"
LABEL eu.cra.doc.version="1.0"
LABEL eu.cra.support.end="2031-12-31"

7.9.7 Verhältnis zu Annex V

→ Vollständige Version: EU-Konformitätserklärung (Annex V)

→ Ausfüllbares Template: EU-Konformitätserklärung Template

4.4.1 Übersicht

Der Kommunikationsplan definiert die internen und externen Kommunikationswege bei Sicherheitsvorfällen. Ziel ist eine schnelle, konsistente und rechtskonforme Informationsweitergabe.

4.4.2 Kommunikationsmatrix

Interne Kommunikation

Externe Kommunikation

4.4.3 Kommunikationsvorlagen

Interne Erstmeldung (Teams)

🚨 SECURITY INCIDENT – SEV-[1/2/3/4]

Produkt: [Produktname] v[Version]
Schwachstelle: [CVE-ID oder Kurzbeschreibung]
Schweregrad: [CRITICAL/HIGH/MEDIUM/LOW]
Aktiv ausgenutzt: [Ja/Nein/Unbekannt]
ENISA-meldepflichtig: [Ja/Nein]

Status: [Triage/Eindämmung/Behebung/Abgeschlossen]
Nächste Schritte: [Beschreibung]
Verantwortlich: [Name]

Incident-Ticket: [Link zum GitHub Issue]

Externe Nutzerbenachrichtigung

Sicherheitshinweis – [Produktname]

Sehr geehrte Nutzerin, sehr geehrter Nutzer,

wir haben eine Sicherheitslücke in [Produktname] identifiziert
und behoben.

Betroffene Versionen: [Versionen]
Behobene Version: [Version]
Schweregrad: [CRITICAL/HIGH]
CVE: [CVE-ID]

Empfohlene Maßnahme:
Bitte aktualisieren Sie auf Version [X.Y.Z].

Details: [Link zum Security Advisory]

Bei Fragen wenden Sie sich an: disclosure@bauer-group.com

4.4.4 Eskalationspfade

SEV-1 (Kritisch):
Developer → Security Lead → Management → ENISA (24h)
                                       → Nutzer (unverzüglich)

SEV-2 (Hoch):
Developer → Security Lead → Management (Info)
                          → Nutzer (nach Fix)

SEV-3 (Mittel):
Developer → Security Lead → Patch im nächsten Release

SEV-4 (Niedrig):
Developer → Backlog → Regulärer Release

4.4.5 Teams-Integration

Die bestehende Teams-Notification (teams-notifications.yml) wird für Sicherheitsvorfälle erweitert:

• Incident Channel: Dedizierter Teams-Kanal für Security Incidents
• Automatische Alerts: Bei CRITICAL/HIGH CVE-Findings aus dem CVE-Monitor
• Status-Updates: Automatische Updates bei Statusänderung des Incident-Tickets

4.4.6 Dokumentationspflicht

Alle Kommunikation im Rahmen eines Sicherheitsvorfalls wird dokumentiert:

• Zeitstempel jeder Kommunikation
• Empfänger und Kanal
• Inhalt (Zusammenfassung)
• Bestätigung des Empfangs

Diese Dokumentation ist Teil des Incident-Tickets und dient als Nachweis gegenüber Aufsichtsbehörden.

4.2.1 Coordinated Vulnerability Disclosure (CVD)

Diese Policy definiert den Prozess für die koordinierte Offenlegung von Schwachstellen gemäß CRA Art. 13 Abs. 6 und ISO/IEC 29147:2018.

4.2.2 Geltungsbereich

Diese Policy gilt für alle Produkte mit digitalen Elementen der BAUER GROUP, einschließlich:

• Software-Produkte (Web-Anwendungen, APIs, Libraries)
• Container-Images
• Firmware (ESP32, STM32, Zephyr)
• Öffentlich zugängliche Dienste

4.2.3 Meldewege

1. GitHub Security Advisories (bevorzugt)

Für jedes Repository: Security → Advisories → New Draft Advisory

Vorteile:

• Vertrauliche Kommunikation
• Integrierte CVE-Zuweisung
• Patch-Koordination im Private Fork
• Strukturierte Erfassung

2. E-Mail

Adresse: disclosure@bauer-group.com

• Verschlüsselung: PGP-Schlüssel im Repository (SECURITY.md)
• Sprache: Deutsch oder Englisch

3. SECURITY.md

Jedes Repository enthält eine SECURITY.md mit:

• Meldewegen
• PGP-Schlüssel (oder Link)
• Unterstützte Versionen
• Reaktionszeiten

4.2.4 Prozess für externe Melder

Was wir erwarten

Sicherheitsforscher, die Schwachstellen melden, werden gebeten:

• Die Schwachstelle nicht öffentlich zu machen, bevor ein Fix bereitsteht
• Keine Daten zu exfiltrieren oder zu zerstören
• Keine Denial-of-Service-Angriffe durchzuführen
• Einen angemessenen Zeitraum für die Behebung einzuräumen

Was wir zusichern

Offenlegungszeitplan

Tag 0:   Schwachstelle gemeldet
Tag 2:   Empfangsbestätigung
Tag 7:   Erstbewertung und Severity-Einstufung
Tag 14:  Statusupdate an Melder
Tag 28:  Statusupdate an Melder
Tag 60:  Patch sollte entwickelt sein
Tag 90:  Koordinierte Offenlegung (Default-Deadline)
         ├── Security Advisory veröffentlichen
         ├── CVE-ID zuweisen
         ├── Patch-Release veröffentlichen
         └── Melder wird im Advisory genannt (auf Wunsch)

4.2.5 Interner Prozess bei eingehender Meldung

Externe Schwachstellenmeldung
    │
    ├── 1. Empfang bestätigen (≤ 48h)
    │   └── Automatisch oder durch Security Lead
    │
    ├── 2. Triage (≤ 7 Tage)
    │   ├── Schwachstelle reproduzieren
    │   ├── Schweregrad bewerten (CVSS)
    │   ├── Betroffene Produkte identifizieren
    │   └── Prüfe: Aktiv ausgenutzt?
    │       └── Ja → ENISA-Meldepflicht + beschleunigter Fix
    │
    ├── 3. Patch-Entwicklung
    │   ├── Fix entwickeln (ggf. im Private Fork)
    │   ├── Tests durchführen
    │   └── Security Review
    │
    ├── 4. Koordinierte Offenlegung
    │   ├── Zeitpunkt mit Melder abstimmen
    │   ├── Security Advisory vorbereiten
    │   ├── CVE-ID beantragen (via GitHub oder MITRE)
    │   └── Patch-Release vorbereiten
    │
    └── 5. Veröffentlichung
        ├── Security Advisory publizieren
        ├── Patch-Release veröffentlichen
        ├── SBOM aktualisieren
        ├── Nutzer informieren
        └── Melder danken und nennen

4.2.6 Safe Harbor

BAUER GROUP wird keine rechtlichen Schritte gegen Sicherheitsforscher einleiten, die:

• In gutem Glauben handeln
• Diese Disclosure Policy einhalten
• Keine Daten unbefugt zugreifen, kopieren oder vernichten
• Keine Dienste durch Denial-of-Service beeinträchtigen
• Betroffene Dritte nicht gefährden

4.2.7 Compliance-Referenzen

9.3.1 Zweck

Maschinenlesbare Compliance-Daten ermöglichen:

• Automatisierte Publikation auf dem Compliance-Portal (→ 9.2)
• Programmatische Validierung in CI/CD-Pipelines
• Aggregation über alle Produkte in einem zentralen Dashboard
• Behördenzugang via API für Marktaufsichtsbehörden

9.3.2 JSON-Schema

Das CRA Compliance Statement folgt einem definierten JSON-Schema:

{
  "$schema": "https://cra.app.bauer-group.com/schemas/cra-statement/v1.json",
  "schema_version": "1.0.0",

  "manufacturer": {
    "name": "BAUER GROUP",
    "address": "[Vollständige Postanschrift]",
    "contact_email": "disclosure@bauer-group.com",
    "website": "[URL]"
  },

  "product": {
    "name": "[Produktname]",
    "version": "[X.Y.Z]",
    "type": "[software|container|firmware|embedded]",
    "description": "[Kurzbeschreibung]",
    "identifier": "[Package-URL oder Container-Image-Referenz]"
  },

  "cra_classification": {
    "category": "[standard|class_i|class_ii|critical]",
    "conformity_module": "[module_a|module_bc|module_h|eucc]",
    "notified_body": "[Name und Kennnummer oder null]"
  },

  "conformity": {
    "declaration_url": "[URL zur vollständigen DoC (Annex V)]",
    "declaration_date": "[YYYY-MM-DD]",
    "ce_marking": true,
    "ce_marking_placement": "[about_dialog|documentation|website|container_label]",
    "last_assessment_date": "[YYYY-MM-DD]"
  },

  "security_documentation": {
    "sbom_url": "[URL zum SBOM (CycloneDX JSON)]",
    "sbom_format": "CycloneDX",
    "sbom_version": "1.5",
    "security_policy_url": "[URL zur SECURITY.md]",
    "user_info_url": "[URL zur Nutzerinformation (Annex II)]",
    "disclosure_contact": "disclosure@bauer-group.com"
  },

  "support_period": {
    "start_date": "[YYYY-MM-DD]",
    "end_date": "[YYYY-MM-DD]",
    "phase": "[active|security|eol]",
    "update_mechanism": "[auto|manual|notification]"
  },

  "harmonised_standards": [
    {
      "identifier": "[z.B. EN XXXXX:YYYY]",
      "description": "[Beschreibung]"
    }
  ],

  "metadata": {
    "generated_at": "[ISO 8601 Timestamp]",
    "generator": "[Tool oder manuell]",
    "statement_version": "[Version des Statements]"
  }
}

9.3.3 Feldübersicht

Pflichtfelder

Optionale Felder

9.3.4 Validierung

CI/CD-Pipeline

Die Validierung der cra-statement.json sollte in die CI/CD-Pipeline integriert werden:

# Beispiel: GitHub Actions Step
- name: Validate CRA Statement
  run: |
    npx ajv validate \
      -s schemas/cra-statement-v1.schema.json \
      -d .compliance/cra-statement.json

Validierungsregeln

9.3.5 Vollständiges Beispiel

{
  "$schema": "https://cra.app.bauer-group.com/schemas/cra-statement/v1.json",
  "schema_version": "1.0.0",

  "manufacturer": {
    "name": "BAUER GROUP",
    "address": "Musterstraße 1, 12345 Musterstadt, Deutschland",
    "contact_email": "disclosure@bauer-group.com",
    "website": "https://www.bauer-group.com"
  },

  "product": {
    "name": "MinIO Gateway",
    "version": "2.1.0",
    "type": "container",
    "description": "S3-kompatibler Object Storage Gateway",
    "identifier": "ghcr.io/bauer-group/minio-gateway:2.1.0"
  },

  "cra_classification": {
    "category": "standard",
    "conformity_module": "module_a",
    "notified_body": null
  },

  "conformity": {
    "declaration_url": "https://cra.app.bauer-group.com/products/minio-gateway/doc",
    "declaration_date": "2026-03-01",
    "ce_marking": true,
    "ce_marking_placement": "about_dialog",
    "last_assessment_date": "2026-03-01"
  },

  "security_documentation": {
    "sbom_url": "https://github.com/bauer-group/minio-gateway/releases/download/v2.1.0/sbom.cdx.json",
    "sbom_format": "CycloneDX",
    "sbom_version": "1.5",
    "security_policy_url": "https://github.com/bauer-group/minio-gateway/blob/main/SECURITY.md",
    "user_info_url": "https://cra.app.bauer-group.com/products/minio-gateway/user-info",
    "disclosure_contact": "disclosure@bauer-group.com"
  },

  "support_period": {
    "start_date": "2026-03-01",
    "end_date": "2031-03-01",
    "phase": "active",
    "update_mechanism": "auto"
  },

  "harmonised_standards": [
    {
      "identifier": "CycloneDX v1.5",
      "description": "SBOM-Format (OWASP)"
    },
    {
      "identifier": "ISO/IEC 29147:2018",
      "description": "Vulnerability Disclosure"
    }
  ],

  "metadata": {
    "generated_at": "2026-03-01T10:00:00Z",
    "generator": "manual",
    "statement_version": "1.0.0"
  }
}

9.3.6 Schema-Versionierung

9.3.7 Querverweise

6.1.1 Template: Produktbeschreibung gemäß Annex VII CRA

1. Produktidentifikation

2. Bestimmungsgemäße Verwendung

Beschreibung: [Beschreiben Sie den bestimmungsgemäßen Zweck des Produkts, die Zielgruppe und die vorgesehene Betriebsumgebung.]

Nutzungsumgebung:

• [z.B. Cloud-Infrastruktur, On-Premise, Embedded Device, IoT]
• [Betriebssystem / Plattform]
• [Netzwerkverbindung erforderlich: Ja / Nein]

3. CRA-Produktklassifizierung

4. Technische Beschreibung

Architektur-Übersicht: [Beschreiben Sie die Softwarearchitektur auf hoher Ebene]

Technologie-Stack:

Schnittstellen:

5. Sicherheitsfunktionen

6. Abhängigkeiten

SBOM-Referenz: [Link zur aktuellen SBOM]

Kritische Drittkomponenten:

7. Support-Zeitraum

8. Konformität

A.9.1 Vorlage: Öffentliches CRA Compliance Statement

Diese Vorlage dient als Basis für das produktspezifische öffentliche CRA Compliance Statement. Es bündelt alle CRA-relevanten Informationen auf einer Seite und verweist auf die zugehörigen Detaildokumente.

A.9.2 CRA COMPLIANCE STATEMENT

[Produktname] — Version [X.Y.Z]

Datum: [YYYY-MM-DD] | Hersteller: BAUER GROUP

1. Produktidentifikation

2. Hersteller

3. Konformitätsstatus