Vulnerability Scanning

Tools: Trivy, Grype, Snyk, Clair. Befehl: trivy image my-app:latest Output:

Total: 1 (HIGH: 1, CRITICAL: 0)
CVE-2023-44487 | libnghttp2 | High | DoS via Rapid Reset

Lösung: apt-get update im Dockerfile und Image neu bauen.

1. Distroless Scanning

Scanner schauen oft nur in die Paket-Datenbank (/var/lib/dpkg/status oder apk test). Distroless Images (von Google) haben keinen Package Manager und keine Shell. Einfache Scanner finden dort nichts, obwohl Lücken da sind! Gute Scanner (Trivy) scannen Binaries direkt oder nutzen SBOMs (Software Bill of Materials), um auch in minimalen Images fündig zu werden.

2. False Positives & VEX

Scanner sind dumm. Sie schreien: "Curl hat eine Lücke!" Aber deine App nutzt Curl gar nicht. Oder die Lücke betrifft nur Windows, du bist auf Linux. Resultat: Dein Build schlägt fehl ("Compliance Failure"), Entwickler sind genervt. Lösung: VEX (Vulnerability Exploitability eXchange). Ein Standard, um Scanner-Alarme zu unterdrücken: "Ja, die Lücke ist da, aber status=not_affected, weil wir die Funktion nicht nutzen."

3. Runtime Scanning

Image Scanning in der Pipeline (Build Time) reicht nicht. Ein Container läuft seit 3 Monaten. Gestern kam ein neuer CVE raus. Die Pipeline läuft nicht mehr (kein neuer Commit). Du bist unsicher. Lösung: Runtime Scanning (z. B. Starboard / Trivy Operator in K8s). Scannt alle laufenden Pods täglich neu und alarmiert im Dashboard.

1. DAST vs. SAST vs. SCA

Sicherheitsscanning findet auf drei Ebenen statt:

• SAST (Static Application Security Testing): Scannt deinen eigenen Code (z. B. Static Analysis (SAST)). Findet logische Fehler wie "Passwort hart im Code".
• SCA (Software Composition Analysis): Das ist das klassische Vulnerability Scanning. Es scannt deine Abhängigkeiten (npm packages, Go modules), ob diese bekanntlich unsicher sind.
• DAST (Dynamic Application Security Testing): Scannt die laufende App von außen. Es verhält sich wie ein Hacker und schickt "böse" Requests, um zu sehen, ob die App mit Fehlern reagiert. Ein professioneller DevSecOps-Workflow nutzt alle drei, da ein SCA-Scanner niemals eine SQL-Injection in deinem selbstgeschriebenen Code finden würde.

2. Binary Lattice & Reachability Analysis

Moderne Scanner werden "intelligenter". Ein Problem klassischer Scanner: Sie finden 500 Lücken, aber 490 sind egal, weil der betroffene Code-Teil in der Bibliothek niemals aufgerufen wird. Reachability Analysis geht einen Schritt weiter: Der Scanner analysiert den Aufrufbaum (Call Graph) deiner App. Er sagt: "Ja, in libxml2 ist eine Lücke. Aber deine App nutzt nur die print-Funktion dieser Library, nicht den verwundbaren parse-Teil. Du kannst dieses Ticket ignorieren." Das spart Entwicklern unzählige Stunden "Alibi-Updates".

3. VEX und die "Vulnerability Fatigue"

Wenn ein Projekt tausende Microservices hat, ersticken Security-Teams an Alarmen (Vulnerability Fatigue). Der VEX (Vulnerability Exploitability eXchange) Standard erlaubt es Firmen, maschinenlesbare Erklärungen zu veröffentlichen: "Wir wissen von CVE-2023-XYZ, aber unsere Konfiguration verhindert den Exploit." Moderne Scanner lesen diese VEX-Dateien automatisch ein und blenden den Alarm aus. Ziel ist eine "Clean Pipeline", in der nur noch echte, behebbar Fehler auftauchen.