# Vulnerability Scanning: Schwachstellen finden, bevor es andere tun

TL;DR / Management Summary Jeden Monat werden tausende neue Sicherheitslücken (CVEs) entdeckt. Ein Senior Admin verlässt sich nicht auf das wöchentliche dnf upgrade, sondern scannt seine Infrastruktur aktiv. Werkzeuge wie Trivy und Grype gleichen den installierten Software-Stand mit globalen Schwachstellen-Datenbanken ab. Das Ziel: Eine priorisierte Liste von Sicherheitsrisiken, die sofortiges Handeln oder gezieltes Patching erfordern – sowohl für das Betriebssystem als auch für Container-Images.

# 1. Einführung & Architektur

Die CVE-Lieferkette.

Ein Vulnerability Scanner funktioniert in drei Schritten:

1. Inventory: Erfassen aller installierten Pakete und deren Versionen.
2. Lookup: Abgleich mit CVE-Datenbanken (NVD, GitHub Advisories, Red Hat Security Data).
3. Priorisierung: Bewertung nach Schweregrad (Critical, High, Medium, Low).

# Der Scanning-Workflow (Mermaid)

graph LR
    A[SLES / Arch Host] --> B[Scanner: Trivy / Grype]
    C[CVE Databases] -->|Sync| B
    B --> D{Analysis Result}
    D -->|Critical| E[Alert & Instant Patch]
    D -->|Medium| F[Scheduled Maintenance]
    G[Container Registry] --> B

# 2. Praxis: Scanning mit Trivy

Der Allrounder.

Trivy ist extrem schnell und unterstützt sowohl OS-Pakete als auch Libraries (Python, JS, Go).

# Den Host scannen

# Installiert Trivy und scannt das lokale System
trivy fs /

# Ein Container-Image scannen

trivy image nginx:latest

# 3. Grype: Der Spezialist für SBOMs

Tiefer in die Abhängigkeiten.

Grype arbeitet hervorragend mit Syft zusammen, um eine Software Bill of Materials (SBOM) zu analysieren.

# SBOM erstellen und scannen

syft / -o json > system_sbom.json
grype system_sbom.json

# 4. Day-2 Operations: Native OS-Tools

Distributions-eigene Checks.

Viele Distributionen haben eigene Werkzeuge, die spezifisch auf deren Security-Advisories zugreifen.

# Unter Debian (debsecan)

sudo apt install debsecan
debsecan --suite $(lsb_release -c -s) --only-fixed

# Unter RHEL (dnf-plugin-security)

sudo dnf updateinfo list security all

# 5. Troubleshooting & “War Stories”

Wenn der Scan Panik auslöst.

# Story 1: “Die False-Positive Flut”

Symptom: Ein Scan meldet 500 “Critical” Schwachstellen auf einem frisch installierten System. Das Team ist in Panik. Ursache: Der Scanner erkennt installierte Libraries, berücksichtigt aber nicht, ob diese im OS bereits durch Backporting (Artikel 001) geflickt wurden. Lösung: Nutzen Sie Scanner, die distributionsspezifische OVAL-Feeds unterstützen. Verlassen Sie sich bei RHEL/SLES primär auf die herstellereigenen Reports.

# Story 2: “Das versteckte Binary”

Symptom: Alle Scans sind “Clean”, aber der Server wird gehackt. Ursache: Der Admin hat Software manuell aus dem Quellcode kompiliert und unter /opt/myapp installiert. Da dieses Binary nicht in der Paket-Datenbank (dpkg/rpm) registriert ist, wird es von vielen Scannern ignoriert. Lösung: Nutzen Sie Scans auf File-Ebene (trivy fs) oder scannen Sie den gesamten Verzeichnisbaum, nicht nur die installierten Pakete.

# 6. Fazit & Empfehlung

• Automation: Integrieren Sie Vulnerability-Scans in Ihre CI/CD-Pipeline (Artikel 209).
• Frequenz: Scannen Sie kritische Systeme täglich. Schwachstellen warten nicht auf Ihr Wartungsfenster.
• Wahl: Trivy ist aktuell die beste All-in-One Lösung für moderne DevOps-Umgebungen.

# Anhang: Cheatsheet