Begriff

Docker Security Scanning

Containerization Security S2

3 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Ein Docker Image ist wie ein Rucksack. Du packst alles rein, was deine App braucht (Ubuntu, Python, Libraries). Aber was, wenn du aus Versehen eine kaputte Bibliothek einpackst, von der jeder Hacker weiß ("Log4j Lücke")? Docker Security Scanning ist wie der Scanner am Flughafen. Er durchleuchtet deinen Rucksack (Image), bevor er ins Flugzeug (Server) darf. Er schaut in jede Datei und jede Bibliothek. Er vergleicht das Gefundene mit einer Polizeidatenbank (CVE-Liste). Wenn er eine Bombe findet, sagt er: "Alarm! CVE-2021-44228 gefunden. Bitte austauschen."

Merksatz: Der automatisierte Prozess des Analysierens von Container-Images auf bekannte Sicherheitslücken (CVEs), Malware und Fehlkonfigurationen, oft integriert in CI/CD-Pipelines.

Kommandozeile (Trivy): trivy image python:3.4-alpine Output:

python:3.4-alpine (alpine 3.9.2)
Total: 34 (UNKNOWN: 0, LOW: 2, MEDIUM: 15, HIGH: 11, CRITICAL: 6)

In Docker Desktop: docker scan my-image (Nutzt Snyk Engine). Der Scanner zeigt dir genau: "In /usr/local/lib/node_modules/... liegt eine alte Version. Upgrade auf v1.2.3 empfohlen."

Praxisroutine

In der Praxis lernst du Docker Security Scanning, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Static vs. Dynamic Analysis

Die meisten Scanner machen SCA (Software Composition Analysis). Sie sehen sich nur die Paket-Listen an (apk info, dpkg -l, package.json). Das ist statisch und extrem schnell. Problem: Wenn du eine Binary (curl) manuell kompilierst (make install), taucht sie in keiner Paketliste auf. Der Scanner ist blind! Lösung: Scanner, die auch Binaries signieren/hashen oder zur Laufzeit scannen (Dynamic Analysis).

2. Distroless Scanning

Distroless Images haben keinen Paketmanager (kein apt, kein apk). Trivy und Co. müssen hier schlauer sein und direkt die installierten Binaries/Libraries auf der Festplatte finden. Das funktioniert oft gut, ist aber schwieriger zu parsen als eine saubere package-lock.json.

3. False Positives & VEX

Scanner sind paranoid. Sie melden oft Lücken in Libraries, die du gar nicht nutzt ("Dead Code"). Oder Lücken im Linux-Kernel des Base-Images, die im Container gar nicht relevant sind (da der Host-Kernel genutzt wird!). Moderne Scanner unterstützen VEX (Vulnerability Exploitability eXchange). Das ist eine "Entschuldigung" vom Hersteller: "Ja, wir haben CVE-X, aber wir sind nicht betroffen, weil wir Funktion Y deaktiviert haben." Scanner lesen das VEX und unterdrücken den Fehlalarm.

False Negatives und Scanner-Evasion

Security-Scanner in Docker verlassen sich primär auf Metadaten (Paketmanager-DBs). Das ist leicht auszutricksen. Wenn ein Hacker ein Image kompromittiert, patcht er oft das System-Tool (/usr/bin/ls), berührt aber die APT-Datenbank (/var/lib/dpkg/status) nicht. Der Scanner liest die Datenbank, sieht "Paket coreutils Version 8.30", und meldet "Grün" – während das Binary bereits bösartig verändert ist. Enterprise-SCA kombiniert daher den Metadaten-Scan mit Hash-Verifizierung. Trivy oder Aqua prüfen den SHA256-Hash des tatsächlichen Executable-Files auf Platte gegen die kryptografische Signatur des Original-Distributoren-Pakets.

Reachability Analysis (EPSS & Call Graphs)

Die neueste Evolutionststufe im Docker Security Scanning ist "Reachability". Ein Scan findet oft 300 CVEs in Java-Bibliotheken (Log4j oder Spring). Admins haben keine Zeit, alles zu fixen. Die Frage ist nicht: "Ist die unsichere Library installiert?", sondern: "Rufen wir in unserem Java-Code tatsächlich die genaue Funktion (die verwundbar ist) auf?" Moderne Scanner analysieren den Call Graph (AST - Abstract Syntax Tree) zur Build-Zeit. Wenn der Scanner merkt, dass die anfällige Funktion parseJndiEndpoint() niemals im Flow der Applikation aufgerufen wird, de-priorisiert er den Fund von "Critical" auf "Info", da kein Angreifer die ungenutzte Schwachstelle (den Dead Code) von außen dynamisch triggern kann.

Host-Kernel Blindspots

Ein massives Versäumnis beim Image-Scan: Scanner prüfen isoliert das Image filesystem (z. B. OpenSSL Lücken in /lib/ssl.so). Sie prüfen nicht den Linux-Kernel. Ein Docker-Daemon mounted den Kernel (/boot/vmlinuz) transparent vom Hostsystem ein (Shared Kernel). Hast du ein perfekt CVE-freies Container-Image (0 Lücken), aber dein EC2-Worker läuft auf einem ungepatchten Ubuntu 18.04-Kernel (z. B. "Dirty Pipe" Vulnerability), liefert dir das CVE-freie Image falsche Sicherheit. Ein Container-Ausbruch ist trivial, doch Trivy/Snyk scannen diese Host-Grenze im Standardbetrieb oft nicht mit (es sei denn als Node-Agent im Kubernetes-DaemonSet modus).

Quick-Check

Wann sollte ich scannen?
Immer in der CI-Pipeline ("Shift Left"). Wenn der Scan rot ist, darf das Image gar nicht erst in die Registry gepusht werden. Spätestens aber in der Registry (täglicher Cronjob), weil heute eine neue Lücke für ein altes Image bekannt werden kann.
Was ist SBOM?
Software Bill of Materials. Eine Zutatenliste für Software. Scanner erzeugen oft eine SBOM ("Das ist alles drin"). Das ist die Basis für Compliance.
Scannt es meinen Code?
Jein. Image Scanner fokussieren sich auf OS-Pakete und Libraries (Dependencies). Für deinen eigenen Code (Logikfehler, SQL Injection) brauchst du SAST (Static Application Security Testing) wie SonarQube, nicht Trivy.