Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Container Image Scanning & Vulnerability Management mit Trivy

In diesem 130-Minuten-Modul baut ihr euch ein eigenes Trainings-Image mit einer bekannten, dokumentierten CVE und scannt es mit trivy image: Severity-Stufen lesen, zwischen einem Fund mit und ohne verfügbaren Fix unterscheiden, und den Fund durch eine Base-Image-Anhebung tatsächlich auflösen, mit einem zweiten Scan als Beleg. Danach baut ihr denselben Scan als CI-Gate in eine Pipeline ein, das den Build bei HIGH/CRITICAL-Funden abbricht, und lernt am selben Fund, wie eine .trivyignore-Ausnahme mit Ablaufdatum aussieht: befristet, begründet, und nach Ablauf schlägt das Gate wieder fehl, nicht stillschweigend weiter grün. Zum Abschluss ordnet ihr Image Scanning gegenüber SBOM-Erzeugung ein, ohne die SBOM-Vertiefung vorwegzunehmen. Die komplette Session läuft lokal mit Docker und Trivy: kein Cloud-Account, keine Kostenwirkung.

Teil der Cybersecurity-Weiterbildung: Querschnitt aus DevSecOps, Docker, Kubernetes und Secrets-Management.

Format

130 Minuten, live (remote oder vor Ort), Input & zwei vollständige Hands-on-Blöcke auf einem selbst gebauten Trainings-Image

Teilnehmende

DevOps-/Platform-Engineers und Security-Verantwortliche nach “Docker Grundlagen”, die Image Scanning hands-on statt nur begrifflich einführen wollen

Voraussetzungen

Kein eigener Cloud-Account nötig: alles läuft lokal. Docker und die Trivy-CLI lokal installiert, Grundkenntnisse Dockerfile/Image aus “Docker Grundlagen” vorausgesetzt.

Warum dieses Training für deine Organisation wirkt

Scanner-Setup statt Taxonomie-Folie

Wo Nachbarmodule Container Image Scanning bewusst nur einordnen, installiert und bedient ihr hier die Trivy-CLI selbst: ein echter Scan-Lauf gegen ein echtes Image, kein Begriffsabriss.

Fund mit Fix gegen Fund ohne Fix

Ihr löst einen Fund durch eine Base-Image-Anhebung tatsächlich auf und lernt am selben Fund, wie eine befristete .trivyignore-Ausnahme aussieht, wenn ein sofortiger Fix (noch) nicht möglich ist: zwei unterschiedliche, beide begründete Reaktionen, keine davon ein Freifahrtschein.

Gate, das wieder zuschlägt

Die .trivyignore-Ausnahme trägt ein Ablaufdatum: Lauft ihr das CI-Gate nach Ablauf erneut, schlägt der Build wieder fehl, live demonstriert, nicht nur behauptet.

Was Teilnehmende mitnehmen

  • Container Image Scanning als eigenständige Pipeline-Phase einordnen (Binary/Artifact-Ebene), abgegrenzt von Dependency Scanning, SAST und Container Runtime Security (Rückverweis auf die Tool-Taxonomie aus DevSecOps Werkzeuge & Compliance, keine Doppelerklärung).
  • Ein eigenes Trainings-Image mit einer bekannten, dokumentierten CVE bauen und mit trivy image scannen, die Ausgabetabelle (Severity, Installed/Fixed Version, Status) lesen und einordnen.
  • Severity-Schwellenwerte (–severity HIGH,CRITICAL) und den Unterschied zwischen einem Fund mit und ohne verfügbaren Fix (–ignore-unfixed) praktisch anwenden.
  • Einen Fund durch eine Base-Image-Anhebung tatsächlich auflösen und den Erfolg mit einem zweiten Scan belegen, statt dem ersten Befund nur zu vertrauen.
  • Denselben Scan als CI-Gate einbauen, das den Build bei einem HIGH/CRITICAL-Fund abbricht (–exit-code 1), und eine befristete, begründete .trivyignore-Ausnahme mit Ablaufdatum setzen und nach Ablauf live scheitern sehen.
  • Image Scanning gegenüber SBOM-Erzeugung (trivy image –format cyclonedx) einordnen, ohne die SBOM-Vertiefung aus DevSecOps Artefakte vorwegzunehmen.

Für wen dieses Modul ideal ist

  • • DevOps-/Platform-Engineers, die nach “Docker Grundlagen” jetzt Image Scanning hands-on statt nur begrifflich einführen wollen
  • • Security-/Compliance-Verantwortliche, die ein CI-Gate mit dokumentierter Ausnahme-Regelung aufbauen wollen
  • • Teams, die aus der Tool-Taxonomie von “DevSecOps Werkzeuge & Compliance” jetzt den konkreten Scanner-Betrieb ableiten wollen

Rahmendaten

  • • Dauer: 130 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei vollständige Hands-on-Blöcke auf einem selbst gebauten Trainings-Image
  • • Voraussetzungen: Kein eigener Cloud-Account nötig, Docker und Trivy-CLI lokal installiert, Dockerfile-/Image-Grundkenntnisse vorausgesetzt

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu DevSecOps Werkzeuge & Compliance (dort Tool-Taxonomie rein begrifflich, ausdrücklich “kein Scanner-Setup, keine Tool-Installation”), zu Docker Sicherheit & Orchestrierung (Container-Härtung und Rechte-Eskalation dort, kein Scanning-Hands-on) und zu Helm: Paketmanagement für Kubernetes (Chart-Security-Scanning dort nur konzeptionell erwähnt). Hier stattdessen echtes Scanner-Hands-on.

  2. Warum Image Scanning & Trivy im Überblick (25 min): Supply-Chain-Risiko durch Base-Image- und OS-Paket-Schwachstellen, Trivy-Scan-Typen (image, fs, config, repo) und ihre jeweilige Pipeline-Phase, Severity-Stufen (UNKNOWN/LOW/MEDIUM/HIGH/CRITICAL), Status “fixed” vs. “unfixed”, Einordnung gegenüber Config Scanning (Dockerfile-Best-Practices) und Dependency Scanning.

  3. Hands-on 1: Trivy-Scan lokal (35 min): ein eigenes Trainings-Image mit docker build bauen, mit trivy image scannen, die Fundtabelle lesen, nach Severity filtern, danach das Base-Image anheben und mit einem zweiten Scan belegen, dass der Fund aufgelöst ist.

  4. Hands-on 2: CI-Gate & .trivyignore (35 min): denselben Scan als Pipeline-Stage einbauen, die bei HIGH/CRITICAL mit –exit-code 1 abbricht, am selben Fund eine befristete .trivyignore-Ausnahme mit Ablaufdatum setzen, Gate einmal grün und nach Ablauf des Datums einmal wieder rot sehen.

  5. SBOM-Ausblick & Abgrenzung (15 min): Trivy kann aus demselben Image auch eine SBOM erzeugen (trivy image –format cyclonedx). Kurzer Ausblick, keine Vertiefung, dafür das eigenständige Modul DevSecOps Artefakte, dazu ein Verweis auf registry-seitiges Scanning aus GitLab & Container-Registry selbst hosten mit Docker.

  6. Fazit & Ausblick (10 min): Zusammenfassung der beiden Hands-on-Blöcke, offene Fragen, Kontaktmöglichkeit.

Abgrenzung: Dieses Modul behandelt bewusst keine erneute Tool-Taxonomie oder Compliance-Governance (dafür DevSecOps Werkzeuge & Compliance), keine Container-Härtung oder Rechte-Eskalation (dafür Docker Sicherheit & Orchestrierung), keine SBOM-Vertiefung inkl. Signaturen und Audit-Trail (dafür DevSecOps Artefakte) und keine Kubernetes-Admission-Durchsetzung von Scan-Ergebnissen (eigenständiges Thema, hier nicht Teil der Agenda).

Hands-on Inhalte (Auszug)

Konzept & Trivy-Überblick

  • Scan-Typen image/fs/config/repo und ihre Pipeline-Phase
  • Severity-Stufen und Status “fixed” vs. “unfixed”
  • Kein Cloud-Account, keine Kostenwirkung

Trivy-Scan lokal

  • Eigenes Trainings-Image mit docker build bauen
  • trivy image gegen das eigene Image laufen lassen
  • Base-Image anheben, zweiter Scan als Fix-Beleg

CI-Gate & .trivyignore

  • Pipeline-Stage mit trivy image –exit-code 1 –severity HIGH,CRITICAL
  • Befristete .trivyignore-Ausnahme mit exp:-Ablaufdatum
  • Gate nach Ablauf erneut laufen lassen: wieder rot

Ausblick

  • SBOM-Erzeugung aus demselben Image (–format cyclonedx)
  • Registry-seitiges Scanning als Anschlussthema
  • Kein eigenes Hands-on zu beiden Punkten in diesem Modul

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum ersten erfolgreichen Fix-Nachweis, Ergebnis des CI-Gate-Laufs nach Ablauf der Ausnahme) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen das Trainings-Image und die CI-Umgebung auf eure tatsächliche Toolchain an.

Academy Briefing anfragen