Thomas.will am 11. August 2026 um 11:26 Uhr

2026-08-11T11:26:56Z

Thomas.will: Die Seite wurde neu angelegt: „== CVE-Scanner: Container, Dependencies und Compliance == Diese Seite vergleicht die gängigen Open-Source- und kommerziellen Scanner für Container-Images, S…“

2026-08-11T11:22:22Z

Die Seite wurde neu angelegt: „== CVE-Scanner: Container, Dependencies und Compliance == Diese Seite vergleicht die gängigen Open-Source- und kommerziellen Scanner für Container-Images, S…“

Neue Seite

== CVE-Scanner: Container, Dependencies und Compliance ==

Diese Seite vergleicht die gängigen Open-Source- und kommerziellen Scanner für Container-Images, Software-Abhängigkeiten und System-Compliance. Für jedes Tool: Funktionsweise, Installation, Nutzung und Best Practices aus der Kurspraxis.

=== Trivy ===

;Was es macht
Trivy (Aqua Security) scannt Container-Images, Dateisysteme, Git-Repositories und IaC-Definitionen (Terraform, Kubernetes-Manifeste, Dockerfiles) auf bekannte CVEs, hartcodierte Secrets und Fehlkonfigurationen. Die Vulnerability-Daten stammen aus mehreren Quellen (NVD, GitHub Security Advisories, distributionsspezifische Feeds wie Debian/RHEL Security Tracker) und werden in einer lokalen SQLite-DB gecacht.

;Installation (Debian/Ubuntu)
* sudo apt-get install wget apt-transport-https gnupg lsb-release
* wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg
* echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
* sudo apt-get update
* sudo apt-get install trivy

;Installation (Rocky Linux/RHEL)
* sudo tee /etc/yum.repos.d/trivy.repo <<EOF
* [trivy]
* name=Trivy repository
* baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/$releasever/$basearch/
* gpgcheck=1
* enabled=1
* gpgkey=https://aquasecurity.github.io/trivy-repo/rpm/public.key
* EOF
* sudo dnf install trivy

;Grundlegende Nutzung
* trivy image nginx:latest
* trivy image --severity CRITICAL,HIGH nginx:latest
* trivy fs /pfad/zum/repo
* trivy config /pfad/zu/terraform
* trivy repo https://github.com/beispiel/projekt

;Best Practice
* In CI/CD als Quality Gate einbauen, damit Builds mit kritischen Findings fehlschlagen:
<syntaxhighlight lang="bash">
trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest
</syntaxhighlight>
* Akzeptierte Risiken über <code>.trivyignore</code> dokumentieren statt Severity-Filter pauschal herunterzudrehen – so bleibt nachvollziehbar, warum ein Finding ignoriert wird
* DB regelmäßig separat aktualisieren, besonders wenn viele Scans hintereinander laufen:
* trivy image --download-db-only
* Für Kursumgebungen ideal als Einstiegstool, da Ergebnis innerhalb von 1–2 Minuten ohne Account oder Cloud-Anbindung sichtbar ist
* SARIF- oder JSON-Ausgabe (<code>--format json</code>) eignet sich gut, um Ergebnisse später mit <code>jq</code> auszuwerten oder in ein SIEM (z.B. Wazuh) einzuspeisen

=== Grype ===

;Was es macht
Grype (Anchore) verfolgt einen ähnlichen Ansatz wie Trivy, ist aber konzeptionell auf Zusammenspiel mit Syft ausgelegt: Syft erzeugt eine Software Bill of Materials (SBOM), Grype scannt anschließend gegen diese SBOM statt direkt gegen das Image. Das entkoppelt Inventarisierung (was ist überhaupt installiert) von Bewertung (welche CVEs betreffen das).

;Installation
* curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sudo sh -s -- -b /usr/local/bin
* curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sudo sh -s -- -b /usr/local/bin

;Grundlegende Nutzung
* syft nginx:latest -o json > sbom.json
* grype sbom:sbom.json
* grype nginx:latest (direkter Scan ohne separate SBOM, für schnelle Checks)

;Best Practice
* SBOM einmal erzeugen und archivieren, dann wiederholt gegen aktualisierte Vulnerability-DB scannen – spart Zeit und liefert einen Audit-Trail, wann welche Komponenten im Image steckten
* SBOM-Datei als Artefakt in der CI/CD-Pipeline ablegen, nicht nur den Scan-Report – für Lieferketten-Nachweise (Supply Chain Security) zunehmend relevant
* Gut geeignet, um im Kurs den Unterschied zwischen "Inventar erstellen" (Syft) und "Inventar bewerten" (Grype) als zwei getrennte Schritte zu demonstrieren

=== Docker Scout ===

;Was es macht
Docker Scout ist direkt in Docker Desktop und die Docker CLI integriert und braucht daher kein separates Tool, wenn Docker ohnehin im Einsatz ist. Es zeigt CVEs an, vergleicht Image-Versionen gegeneinander und gibt Empfehlungen (z.B. "neueres Base-Image verwenden").

;Installation
* Ab Docker CLI 24 ist das Plugin standardmäßig vorhanden
* Falls nicht vorhanden: sudo apt-get install docker-scout-plugin

;Grundlegende Nutzung
* docker scout cves nginx:latest
* docker scout compare nginx:latest --to nginx:1.25
* docker scout recommendations nginx:latest

;Best Practice
* <code>docker scout compare</code> eignet sich besonders gut für Kursvorführungen zum Thema Patch-Management: "ist mein neues Image besser oder schlechter als das alte"
* Kostenlose Nutzung ist pro Nutzer/Organisation limitiert – vor dem Kurs prüfen, ob die Free-Tier-Grenzen für die Teilnehmerzahl reichen
* Da es in der Docker-Toolchain "mitläuft", eignet es sich gut, um zu zeigen, dass Security-Scanning kein Extra-Tool sein muss, sondern in bestehende Workflows integriert werden kann

=== Clair ===

;Was es macht
Clair läuft als Backend-Service (eigener API-Server plus PostgreSQL-Datenbank) und wird meist hinter einer Registry wie Harbor oder Quay betrieben statt als CLI-Tool für Ad-hoc-Scans genutzt. Images werden automatisch beim Push in die Registry gescannt.

;Best Practice
* Nicht für schnelle Kurs-Demos geeignet – der Setup-Aufwand (DB, API-Server, Registry-Anbindung) steht in keinem guten Verhältnis zum Lerneffekt gegenüber Trivy/Grype
* Sinnvoll als Beispiel für "Enterprise-Registry-Scanning", falls Harbor oder Quay bereits Teil der Kursumgebung ist
* Bei Zeitdruck im Kurs zugunsten von Trivy/Grype überspringen

=== OWASP Dependency-Check ===

;Was es macht
Prüft Software-Abhängigkeiten (Schwerpunkt Java/.NET, aber auch Node.js, Python, Ruby, PHP) gegen die NVD und identifiziert Bibliotheken mit bekannten CVEs. Läuft als eigenständige CLI, als Maven-/Gradle-Plugin oder als Jenkins-Plugin.

;Installation
* wget https://github.com/jeremylong/DependencyCheck/releases/download/v10.0.0/dependency-check-10.0.0-release.zip
* unzip dependency-check-10.0.0-release.zip -d /opt/
* ln -s /opt/dependency-check/bin/dependency-check.sh /usr/local/bin/dependency-check

;Grundlegende Nutzung
* dependency-check --project MeinProjekt --scan /pfad/zum/projekt --format HTML --out ./report

;Best Practice
* NVD-API-Key kostenlos beantragen (https://nvd.nist.gov/developers/request-an-api-key) und über <code>--nvdApiKey</code> übergeben – ohne Key ist das Rate-Limiting beim ersten DB-Update sehr streng und der Download kann eine Stunde oder länger dauern
* Ersten DB-Download vor Kursbeginn anstoßen und den Cache-Ordner (<code>~/.m2/repository/org/owasp</code> bzw. <code>data</code>-Verzeichnis) für alle Teilnehmer-VMs vorbereiten, statt live im Kurs zu warten
* HTML-Report eignet sich gut zum gemeinsamen Durchgehen, da er CVSS-Score, betroffene Datei und Beschreibung übersichtlich verknüpft
* Bei False Positives <code>suppression.xml</code> nutzen statt Findings zu ignorieren – macht Ausnahmen dokumentiert und nachvollziehbar

=== Snyk ===

;Was es macht
Snyk deckt Dependencies, Container-Images, Infrastructure-as-Code und eigenen Anwendungscode (SAST) ab und bietet sehr gute Entwicklerintegration (VS Code, GitHub, GitLab, Jenkins). Betrieben als Freemium-SaaS mit monatlichem Test-Limit in der kostenlosen Stufe.

;Installation
* sudo npm install -g snyk
* snyk auth

;Grundlegende Nutzung
* snyk test
* snyk container test nginx:latest
* snyk iac test
* snyk monitor (kontinuierliches Monitoring, meldet neue CVEs auch nach dem initialen Scan)

;Best Practice
* Account-Erstellung und Auth-Flow vor Kursbeginn klären – im Gegensatz zu Trivy ist Snyk nicht ohne Login sofort nutzbar, das kostet sonst Unterrichtszeit
* <code>snyk monitor</code> eignet sich gut als Kontrastpunkt zu einmaligen CLI-Scans: zeigt, wie kontinuierliches Vulnerability-Monitoring in echten Teams aussieht (Snyk meldet auch neu bekanntgewordene CVEs für bereits gescannte, unveränderte Projekte)
* Free-Tier-Limits vorher prüfen, wenn mehrere Teilnehmer parallel mit eigenen Accounts arbeiten

=== OpenSCAP ===

;Was es macht
OpenSCAP ist kein reiner CVE-Scanner im engeren Sinn, sondern ein Compliance- und Configuration-Scanner nach dem SCAP-Standard (Security Content Automation Protocol). Es prüft Systeme gegen Policies wie CIS Benchmarks, DISA STIG oder PCI-DSS. Zusätzlich kann es über OVAL-Definitionen (Open Vulnerability and Assessment Language) auch klassisches CVE-Scanning durchführen, sofern die jeweilige Distribution offizielle OVAL-Feeds bereitstellt – bei RHEL-basierten Systemen (RHEL, Rocky, CentOS) ist das der Fall.

;Zwei Anwendungsfälle
* '''Configuration Compliance''': prüft z.B. ob SSH-Root-Login deaktiviert ist oder Passwort-Policies den Vorgaben entsprechen
* '''Vulnerability Scanning via OVAL''': nutzt distributionsspezifische OVAL-Feeds, um installierte Pakete gegen bekannte CVEs zu prüfen

;Installation (Rocky Linux/RHEL)
* sudo dnf install openscap-scanner scap-security-guide

;CVE-Scan gegen offiziellen Red-Hat-OVAL-Feed
* wget https://www.redhat.com/security/data/oval/v2/RHEL9/rhel-9.oval.xml.bz2
* bzip2 -d rhel-9.oval.xml.bz2
* oscap oval eval --results scan-results.xml rhel-9.oval.xml

;Compliance-Scan gegen CIS-Benchmark
<syntaxhighlight lang="bash">
oscap xccdf eval \
--profile cis \
--results results.xml \
--report report.html \
/usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml
</syntaxhighlight>

;Verfügbare Profile anzeigen
* oscap info /usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml

;Best Practice
* Thematisch sehr passend für den Rocky-Linux-Kurs, da <code>scap-security-guide</code> fertige Profile für Rocky/RHEL mitbringt und keine Zusatzkonfiguration braucht
* Im Kurs gut geeignet, um den Unterschied zwischen Vulnerability Scanning (Trivy, Grype, Snyk – "welche bekannte Schwachstelle steckt in dieser Software") und Compliance/Baseline Scanning (OpenSCAP – "entspricht dieses System einer Sicherheitsrichtlinie") klarzumachen; die beiden werden von Teilnehmern häufig verwechselt
* HTML-Report (<code>report.html</code>) ist sehr anschaulich für die Vorführung, zeigt Pass/Fail pro Regel inklusive Begründung und Referenz auf den Benchmark-Punkt
* Remediation-Skripte lassen sich direkt aus dem Profil generieren:
* oscap xccdf generate fix --profile cis --output remediate.sh /usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml
* Remediation-Skripte im Kurs ausschließlich auf einer Wegwerf-VM testen, nie auf einer produktiv genutzten Maschine, da Änderungen (z.B. an SSH- oder PAM-Konfiguration) Systeme aussperren können

=== Übersicht ===

{| class="wikitable"
! Tool !! Scope !! Setup-Aufwand !! Kosten
|-
| Trivy || Images, Filesystem, IaC || sehr gering || kostenlos
|-
| Grype || Images (via SBOM) || gering || kostenlos
|-
| Docker Scout || Images (Docker-integriert) || sehr gering || Freemium
|-
| Clair || Images (Registry-Backend) || hoch || kostenlos
|-
| OWASP Dependency-Check || Code-Dependencies || mittel (erster DB-Download) || kostenlos
|-
| Snyk || Dependencies, Images, IaC, Code || mittel (Account nötig) || Freemium
|-
| OpenSCAP || System-Compliance + OVAL-CVEs || gering (RHEL-Familie) || kostenlos
|}

[[Kategorie:Sicherheit]]
[[Kategorie:CVE-Scanner]]

@@ Zeile 27: / Zeile 27: @@
 ;Grundlegende Nutzung
 * trivy image nginx:latest
 * trivy image --severity CRITICAL,HIGH nginx:latest
 * trivy fs /pfad/zum/repo
 * trivy config /pfad/zu/terraform
 * trivy repo https://github.com/beispiel/projekt
@@ Zeile 54: / Zeile 64: @@
 ;Grundlegende Nutzung
 * syft nginx:latest -o json > sbom.json
 * grype sbom:sbom.json
-* grype nginx:latest (direkter Scan ohne separate SBOM, für schnelle Checks)
 ;Best Practice
@@ Zeile 73: / Zeile 89: @@
 ;Grundlegende Nutzung
 * docker scout cves nginx:latest
 * docker scout compare nginx:latest --to nginx:1.25
 * docker scout recommendations nginx:latest
@@ Zeile 103: / Zeile 125: @@
 ;Grundlegende Nutzung
 * dependency-check --project MeinProjekt --scan /pfad/zum/projekt --format HTML --out ./report
@@ Zeile 121: / Zeile 145: @@
 ;Grundlegende Nutzung
 * snyk test
 * snyk container test nginx:latest
 * snyk iac test
-* snyk monitor (kontinuierliches Monitoring, meldet neue CVEs auch nach dem initialen Scan)
 ;Best Practice

Cve scanner - Versionsgeschichte

Thomas.will am 11. August 2026 um 11:26 Uhr

Thomas.will: Die Seite wurde neu angelegt: „== CVE-Scanner: Container, Dependencies und Compliance == Diese Seite vergleicht die gängigen Open-Source- und kommerziellen Scanner für Container-Images, S…“