Schwachstellenmanagement - vom Fund zur Behebung

≈ 2 min
securitymanagement

CVEs finden ist einfach. Der schwierige Teil ist zu entscheiden was davon wirklich kritisch ist, wer es behebt, bis wann, und wie man nachverfolgt ob es erledigt wurde.

Schwachstellen systematisch erfassen

  • Quellen:
  • composer audit / npm audit — Anwendungsabhängigkeiten
  • trivy image — Container-Images
  • lynis — Betriebssystem-Konfiguration
  • CVE-Feeds für verwendete Software (Nginx, PHP, MariaDB)
  • Dependabot-Alerts wenn auf GitHub

All das liefert rohe Ergebnisse. Schwachstellenmanagement bedeutet daraus einen priorisierten Backlog zu machen.

Bewertung mit CVSS

CVSS-Score allein reicht nicht. Zwei weitere Faktoren:

Exploitability: Gibt es schon funktionierenden Exploit-Code? Ein CVE mit Score 9.8 ohne öffentlichen Exploit ist weniger dringend als ein CVE mit Score 7.5 mit aktivem Exploit in the wild.

Exposure: Ist der verwundbare Code überhaupt aus dem Internet erreichbar? Eine Schwachstelle in einer Admin-Library die nur intern genutzt wird hat einen anderen Risikokontext als dieselbe Schwachstelle im öffentlichen Login-Endpunkt.

Priorität = CVSS-Score × Exploitability × Exposure

Nicht als Formel sondern als Denkrahmen.

Behandlungsoptionen

Nicht jede Schwachstelle wird gepatcht.

  • Patchen: ideale Lösung, nicht immer sofort möglich
  • Mitigieren: Workaround der das Risiko reduziert ohne zu patchen (z. B. betroffenes Feature deaktivieren)
  • Akzeptieren: bewusste Entscheidung mit Dokumentation warum das Risiko akzeptabel ist
  • Transferieren: durch eine andere Kontrolle abgedeckt (WAF, Netzwerksegmentierung)

Akzeptieren ist legitim — aber es muss eine explizite Entscheidung sein mit Datum und Begründung, nicht einfach Vergessen.

Tracking

## CVE-2023-44487 (HTTP/2 Rapid Reset) — Nginx
- CVSS: 7.5
- Entdeckt: 2023-10-10
- Betroffene Systeme: web01, web02
- Status: Nginx 1.25.3 deployt am 2023-10-12 ✓
- Verifiziert: nginx -v bestätigt neue Version

## CVE-2023-12345 — PHP 8.2.x
- CVSS: 5.3
- Exposure: nur interne Admin-Requests → niedrig
- Entscheidung: akzeptiert bis PHP 8.3 LTS verfügbar
- Review-Datum: 2024-01-01

Eine einfache Markdown-Datei im Repository reicht für kleine Projekte.

SLA für Schwachstellen

Ein Beispiel-SLA:

| Schwere | Frist |
|---|---|
| Kritisch (9+) | 24 Stunden |
| Hoch (7–8.9) | 7 Tage |
| Mittel (4–6.9) | 30 Tage |
| Niedrig (<4) | nächstes reguläres Update |

Die Fristen sind nicht universell — sie sollten zum eigenen Risikoprofil passen. Kritisch für eine Hobbyseite ist anders als kritisch für einen Zahlungsdienstleister.