84 Security-Scanning

Security-Scanning ist ein unverzichtbarer Bestandteil moderner Container-Lieferketten. Während Signaturen sicherstellen, von wem ein Image stammt und dass es unverändert ist, beantwortet Security-Scanning die Frage, ob das Image vertrauenswürdig ist. Das Scanning deckt Schwachstellen auf, bewertet Risiken und stellt sicher, dass Images konform zu Unternehmensrichtlinien sind. Anders als klassische Paketmanager-Scans untersucht Container-Scanning komplette OCI-Images: alle Layer, alle Binaries, alle Konfigurationsartefakte. Podman und sein Ökosystem setzen dabei auf Werkzeuge wie podman scan, Trivy, Clair, Grype oder OpenSCAP.

84.1 Zweck: Fehler aufdecken, bevor sie produktionswirksam werden

Ein Container-Image enthält in der Regel:

• eine Linux-Basisdistribution (Alpine, Debian, UBI, etc.)
• Bibliotheken und Shared Objects
• Laufzeitumgebungen (JRE, Node.js, Python)
• konfigurierte Services
• eigene Applikationsartefakte

Jedes dieser Elemente kann Schwachstellen enthalten – teils in systemnahen Bereichen wie glibc, teils in Applikationsbibliotheken.

Security-Scanning erkennt unter anderem:

• CVEs in Systembibliotheken
• anfällige Interpreter-Versionen (Python, Node.js)
• unsichere Konfigurationen
• veraltete Basisschichten
• potenzielle Malware oder verdächtige Binaries
• Shells, Daemons oder Tools, die nicht ins Image gehören

Der Zugriff auf CVE-Datenbanken (NVD, Red Hat OVAL, Debian Security Advisories) ist dabei zentral.

84.2 Beziehung zwischen Scanning und Signierung

Signaturen beweisen Herkunft. Scanning beweist Sicherheit.

Beide Mechanismen ergänzen sich, überschneiden sich jedoch nicht.

Ein signiertes Image kann unsicher sein. Ein gescanntes Image kann man-in-the-middle kompromittiert sein.

Ideal ist die Pipeline:

Ein Bild, das nicht besteht → wird nicht signiert → wird nicht acceptiert.

84.3 Scanning-Werkzeuge in Podman-Workflows

Podman integriert Security-Scanning über die containers/image-Bibliothek:

podman scan <image>

Standardmäßig nutzt Podman den Scanner „Trivy“, sofern installiert. Andere Scanner können integriert werden.

84.3.1 Trivy

Einer der populärsten Scanner:

• geringes Setup
• umfassende CVE-Abdeckung
• erkennt OS-Pakete, Programmbibliotheken, IaC-Dateien
• unterstützt Container, Filesysteme, Git-Repositories

Beispiel:

podman scan myapp:1.0

Typische Ausgabe:

CVE-2023-0466 (OpenSSL) HIGH
CVE-2022-37434 (zlib) MEDIUM
...

84.3.2 Grype

Ein weiterer Lightweight-Scanner, häufig in CI/CD eingesetzt:

grype registry.local/myapp:latest

Vorzüge:

• deterministische Ergebnisse
• einfache Integration in Pipelines
• granular konfigurierbare Severity-Stufen

84.3.3 Clair / Claircore

Enterprise-fokussiert, serverseitiger Scanner. Ideal für Multi-Image-Scanning in großen Registries.

84.3.4 OpenSCAP

Für regulierte Umgebungen, z. B. Behörden oder ISO-zertifizierte Unternehmen.

• SCAP Profile
• Compliance Checks
• Konfigurationsvalidierung

Stärker, aber komplexer.

84.4 Wie Scanner Images analysieren

Container-Scanner extrahieren und prüfen jedes Layer und jedes Paket:

Zu den analysierten Quellen gehören:

• dpkg -l oder rpm -q für OS-Pakete
• package-lock.json, go.mod, requirements.txt
• ELF-Binary-Inspection
• Hash-Vergleiche für bekannte Malware-Signaturen

84.5 Unterschied zwischen Build-Time und Registry-Scanning

84.5.1 Build-Time Scanning

Erkennt Fehler früh, verhindert unsichere Artefakte. Beispiel in GitLab oder GitHub Actions.

84.5.2 Registry-Scanning

Scans laufen serverseitig bei jeder Image-Änderung. Clair, Harbor oder GitLab Container Registry integrieren das.

Vorteil: kontinuierliche Prüfung auf neue CVEs – ohne Neu-Build.

84.6 Policy Enforcement: Nur sichere Images zulassen

Scanner sind nur nützlich, wenn ihre Ergebnisse zu Entscheidungen führen. Policies definieren:

• maximal erlaubte Severity (z. B. nur LOW und MEDIUM)
• Blockieren bestimmter CVE-Kategorien
• Pflicht zum regelmäßigen Re-Scan
• Pflicht zum Neu-Build nach kritischen Findings
• automatisierte JIRA-/Ticket-Erzeugung bei Findings

Podman selbst kann Entscheidungen über Trust-Policies treffen, aber Scanning-Policies müssen extern definiert werden, typischerweise:

• in CI/CD
• im Admission Controller
• in der Registry

Beispiel (Cosign + Policy Controller):

• signierte, gescannte Images werden akzeptiert
• unsignierte oder ungeprüfte Images werden verworfen

84.7 Praktische Herausforderungen

84.7.1 1. False Positives

Scanner erkennen manchmal Bibliotheken, die nicht aktiv genutzt werden. Workaround: Layer-Slimming, Multi-Stage Builds.

84.7.2 2. False Negatives

Nicht alle CVEs sind sofort in Datenbanken verfügbar.

84.7.3 3. Private Paketquellen

Scanner müssen Zugriff auf private Repos haben oder alternative Match-Daten verwenden.

84.7.4 4. Language-Package-Scanning ist komplex

JS, Python und Go bringen eigene Paketmanager, eigene CVE-Datenbanken und eigene Semantik.

84.7.5 5. Scanning kostet Zeit

Oft mehrere Sekunden bis Minuten – in CI-Pipelines relevant.

84.8 Best Practices für Architekten

• Always scan – niemals Images ungeprüft akzeptieren
• Reduziere Imagegröße → weniger Angriffsfläche
• Nutze Multi-Stage Builds
• Aktualisiere Baselines regelmäßig
• Verwende dedizierte Security Stages in CI
• Automatisiere CVE-Remediation (z. B. Renovate, Dependabot)
• Erzwinge Sicherheits-Gates in Build-Pipelines

Security-Scanning ist ein struktureller Bestandteil der Containersicherheit. Es ergänzt Signaturen und Trust-Policies, indem es proaktiv Sicherheitsmängel identifiziert, bewertet und in den Entscheidungspfad von Build- und Deployment-Prozessen überführt. Ohne kontinuierliches Scanning bleibt jede Lieferkette blind für bekannte Schwachstellen – und damit unberechenbar.