3.1 CVE-Monitoring

Prozess

Das CVE-Monitoring scannt täglich alle aktiven Produkt-SBOMs gegen aktuelle CVE-Datenbanken. Ziel ist die frühzeitige Erkennung neu veröffentlichter Schwachstellen in Abhängigkeiten bereits ausgelieferter Produkte.

RECHTSGRUNDLAGE

Art. 10 Abs. 6 CRA: „Der Hersteller verfügt über wirksame und regelmäßige Verfahren und Mechanismen, um Schwachstellen in dem Produkt mit digitalen Elementen zu ermitteln."

Annex I, Teil II, Nr. 5: „Der Hersteller überwacht aktiv Schwachstellen Dritter, die in dem Produkt enthalten sind."

Workflow-Design

Trigger

on:
  schedule:
    - cron: '0 6 * * *'    # Täglich um 06:00 UTC
  workflow_dispatch:         # Manueller Trigger

Ablauf

1. Lade SBOMs der aktiven Produktversionen
   └── Quelle: Compliance-Repo (sbom/) oder GitHub Release-Assets

2. Scanne jede SBOM gegen aktuelle CVE-Datenbanken
   ├── trivy sbom sbom.cdx.json --severity CRITICAL,HIGH
   └── grype sbom:sbom.cdx.json --only-fixed --fail-on high

3. Parse Ergebnisse
   ├── Filtere nach Severity (CRITICAL, HIGH)
   ├── Extrahiere: CVE-ID, Package, Version, Fixed-Version
   └── Prüfe auf Duplikate (bereits gemeldete CVEs)

4. Bei neuen Findings:
   ├── GitHub Issue erstellen
   │   ├── Title: "[CVE-YYYY-XXXXX] <Package> – <Severity>"
   │   ├── Labels: security, cve, <severity>
   │   ├── Body: CVE-Details, betroffene Produkte, Fix-Version
   │   └── Assignee: Security Lead
   ├── Teams-Notification (bei CRITICAL)
   └── Bei aktiv ausgenutzt → ENISA-Meldeprozess triggern

5. Scan-Report archivieren
   └── Als GitHub Actions Artifact (90 Tage)

Workflow-Spezifikation

name: CVE Monitor

on:
  schedule:
    - cron: '0 6 * * *'
  workflow_dispatch:
    inputs:
      severity:
        description: 'Minimum severity to report'
        default: 'HIGH'
        type: choice
        options: ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW']

jobs:
  scan-sboms:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        product: [product-a, product-b, firmware-esp32]
    steps:
      - name: Checkout Compliance Repo
        uses: actions/checkout@v4

      - name: Get Latest SBOM
        run: |
          SBOM=$(ls -t sbom/${{ matrix.product }}/sbom-*.cdx.json | head -1)
          echo "SBOM_PATH=$SBOM" >> $GITHUB_ENV

      - name: Trivy SBOM Scan
        uses: aquasecurity/trivy-action@master
        with:
          input: ${{ env.SBOM_PATH }}
          scan-type: sbom
          severity: CRITICAL,HIGH
          format: json
          output: trivy-results.json

      - name: Create Issues for New CVEs
        uses: actions/github-script@v7
        with:
          script: |
            const results = require('./trivy-results.json');
            // Erstelle Issue für jede neue CVE
            // Prüfe Duplikate über bestehende Issues

CVE-Datenbanken

Datenbank	Tool	Abdeckung
NVD (NIST)	Trivy, Grype	Umfassend – alle CVEs
GitHub Advisory DB	Dependabot	Sprachspezifisch
OSV (Open Source Vulnerability)	Trivy	Open-Source-fokussiert
Red Hat Security Data	Trivy	Linux-Pakete
Alpine SecDB	Trivy	Alpine-Pakete

Issue-Template

## CVE-[YYYY-XXXXX]: [Package Name] – [Severity]

**Schweregrad:** CRITICAL / HIGH
**CVSS Score:** X.X
**Betroffen:** [Produktname] v[Version]

### Details
- **Package:** [name]@[version]
- **Fixed in:** [fixed-version]
- **CVE:** https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXXX
- **Beschreibung:** [CVE-Beschreibung]

### Betroffene Produkte
| Produkt | Version | SBOM |
|---------|---------|------|
| [Name]  | [Ver]   | [Link] |

### Empfohlene Maßnahme
- [ ] Package auf Version [fixed-version] aktualisieren
- [ ] Patch testen
- [ ] Release erstellen
- [ ] SBOM aktualisieren
- [ ] Prüfe: Wird CVE aktiv ausgenutzt? → [ENISA-Meldeprozess](/de/incident-response/enisa-reporting)

### Klassifizierung
- **Aktiv ausgenutzt:** Ja / Nein / Unbekannt
- **ENISA-Meldepflichtig:** Ja / Nein

SLA für CVE-Behandlung

Severity	Reaktionszeit	Patch-Deadline	Referenz
CRITICAL	4 Stunden	48 Stunden	Annex I, Teil II, Nr. 7
HIGH	24 Stunden	7 Tage	Annex I, Teil II, Nr. 7
MEDIUM	72 Stunden	30 Tage	Best Practice
LOW	7 Tage	Nächster Release	Best Practice