Trivy als vielseitiger Open Source Security Scanner

Im folgenden Artikel beschäftigen wir uns mit dem Open Source Security Scanner Trivy. Ich werde zeigen, welche Artefakte mit ihm gescannt und welche Art von Reports erzeugt werden können. Außerdem werde ich anhand eines exemplarischen DevSecOps Prozesses zeigen, wie Trivy darin eingesetzt werden kann.

Trivy als vielseitiger Open Source Security Scanner

Mit Trivy stellen ich hier einen sehr vielseitigen Open Source Security Scanner vor, welcher nicht nur für Source Code Scans sondern zum Beispiel auch zum Scannen von Images oder Kubernetes Clustern verwendet werden kann. Die Bedienung von Trivy erfolgt - wie bei bei den meisten anderen Scannern auch - über ein Command Line Interface (CLI), was ihn für den Einsatz in DevSecOps-Pipelines in CI/CD-Umgebungen befähigt. Die CLI ist sehr benutzerfreundlich und zudem auf Geschwindigkeit bei den Scan ausgelegt.

Trivy ist eine willkommene Unterstützung bei Aufgaben wie Schwachstellenscans, Lizenzprüfungen oder dem Erkennen von fehlerhaften Konfigurationen.

Was kann Trivy scannen?

Mit Trivy und dessen CLI können vielfältige Artefakte der Softwareentwicklung sowie im Bereich des sicheren Betriebs von Anwendungen gescannt und überprüft werden:

• Container Images: Hierbei werden die Files innerhalb der Container und/oder die Metadaten der Images gescannt. Es wird auf Schwachstellen, Fehlkonfigurationen, Secrets und Lizenzen geprüft.

• Dateisysteme (Filesystem fs oder als Rootfs rootfs): Bei diesen Scans werden Dateien im Dateisystem gescannt. Der Filesystem Scan ist dabei eher für eine lokales Repo und der Rootfs Scan für einen traversierenden Scan des Dateisystems geeignet. Beide Scans prüfen auf Schwachstellen, Fehlkonfigurationen, Secrets und Lizenzen.

• Code Repositories: Dieser Scan ist vor allem für Repos und deren Analyse innerhalb von CI-Pipelines vorgesehen. Er scant auf lock-Files (wie package-lock.json) und nicht auf Artefakte wie JAR-Files oder Binaries. Auch dieser Scan detektiert Probleme mit Schwachstellen, Fehlkonfigurationen, Secrets und Lizenzen.

• SBOM-Dateien (CycloneDX, SPDX): Bei der Ausführung dieses Scans wird ein SBOM auf mögliche Schwachstellen oder Lizenzen untersucht.

• Kubernetes (via Trivy Operator): Trivy kann sogar Kubernetes Cluster scannen. Dabei werden Infrastruktur, Konfigurationen sowie Workloads betrachtet. Ergebnis des Scans sind Schwachstellen, Fehlkonfigurationen und möglicherweise öffentlich zugängliche Secrets.

• Images virtueller Maschinen: Mit diesem neuen Feature können .vmdk Files gescannt werden. Auch hier wird auf Schwachstellen, Fehlkonfigurationen, Secrets und Lizenzen geprüft.

• Infrastructure-as-Code Konfigurationen (AWS, GCP etc.): Als Teil der Scans oben können auch typische Infrastructure-as-Code (IaC)-Files Terraform oder Helm gescannt werden.

1# Container Image Scan des Nginx Images
2trivy image nginx:1.21
3
4# Filesystem Scan im aktuellen Directory
5trivy fs .
6
7# Code Repo Scan
8trivy repo https://github.com/aquasecurity/trivy

Beispiele für Scans mit dem Trivy CLI

Welche Arten von Schwachstellenberichten erzeugt Trivy?

Als Ergebnis seiner Scans kann Trivy eine Reihe unterschiedlicher Berichte erzeugen. Diese Berichte umfassen Informationen die in verschieden Bereichen der DevSecOps-Vorgehensweise benötigt und eingesetzt werden.

• Vulnerabilities (CVEs): Das sind potentielle Schwachstellen, die sich aus den verwendeten und installierten Pakten ergeben.

• Fehlkonfigurationen: Das können unterschiedlichste Dinge wie zum Beispiel die Verwendung des Users root oder ein fehlendes Image-Tag im FROMim Dockerfile sein. Dieser Bericht kann auch mittel eigener Custom Checks erweitert werden.

• Secrets: Warnungen, falls Tokens, Passwörter oder SSH-Keys hardcoded sind.

• Lizenzen: Eine Klassifizierung von verwendeten Open Source Lizenzen und deren Compliance (mit der Google License Classification).

• SBOM: Generierung und Analyse von Software Bill of Materials

Beispiele & Code-Snippets

Die folgenden Snippets zeigen wie die verschiedenen Scanner verwendet werden können, um die unterschiedlichen Schwachstellenberichte zu erzeugen.

1# Container Image Scan mit Generierung von SBOM im CycloneDX-Format
2trivy image --format cyclonedx --output sbom.json nginx:1.21
3
4# Scan auf exposed Secrets im aktuellen Directory
5trivy fs --scanners secret .
6
7# Überprüfung des Kubernetes-Cluster mit der Erstellung eines zusammenfassenden Reports
8trivy k8s --report summary cluster

Trivy Scan Beispiele

Einbettung in DevSecOps-Prozesse innerhalb einer CI-Pipeline

Wie bereits oben erwähnt, eignet sich Trivy sehr gut als ein Tool innerhalb eines DevSecOps-Prozesses. Einen dieser exemplarischen Prozesse stelle ich im folgenden vor. Der Scan mit Trivy ist ein Teil dieses größeren Prozesses.

1. Code & Dependency Stage

• Das Entwicklungsteam macht einen Commit, in dem neue Abhängigkeiten installiert werden. Dabei hat sich zum Beispiel das requirements.txt, das package.json oder das Makefile geändert.

• Trivy scannt das gesamte Repository.

1trivy repo https://github.com/orga/projekt

→ Es werden veraltete Libraries, eingecheckte Secrets sowie problematische Lizenzen erkannt.

2. Build Stage (CI/CD)

• Der Build der Anwendung wird ausgeführt und es wird ein Container Image erstellt.

• Das resultierende Image wird von Trivy auf CVEs und problematische Pakete überprüft.

1trivy image my-app:latest

→ Es werden CVEs in den Systempaketen erkannt.

3. Pre-Deploy Stage

• Nun wird anhand einer Policy der Schwellenwert für die CVEs überprüft: „keine CVEs mit CVSS > 7 erlaubt“

• Sollte dieser Scan des Images fehlschlagen, so wird die komplette Pipeline abgebrochen.

1trivy image --exit-code 1 --severity HIGH,CRITICAL my-app:latest

4. Deployment

• Die Anwendung wird in den Kubernetes-Clustern einer Staging- sowie der Produktions-Umgebung deployed.
• Optional: Trivy kann nun nochmals das Kubernetes-Cluster und die Helm-Charts im Hinblick auf Fehlkonfigurationen überprüfen.

1trivy k8s cluster
2trivy config ./helm/mychart

5. Monitoring & Compliance

• Um die deployte Konfiguration nachträglich überprüfbar zu machen, kann Trivy eine SBOM (CycloneDX/SPDX) erstellen. Diese SBOM sollte archiviert werden.
• Falls vorhanden kann die SBOM in ein Vulnerability-Management-System integriert werden.
• Damit ist die Grundlage für Audits geschaffen (ISO 27001, CRA, Open Chain).

    flowchart TD
	    A["Code Commit"] --> B["Repo Scan mit Trivy"]
	    B --> C["Build / Container Image"]
	    C --> D["Image Scan mit Trivy"]
	    D --> E{"CVE > Schwellenwert?"}
	    E -->|Ja| F["Pipeline bricht ab"]
	    E -->|Nein| G["Deployment nach Staging/Prod"]
	    G --> H["Cluster Scan mit Trivy (optional)"]
	    G --> I["SBOM-Generierung"]
	    I --> J["Archivierung / Compliance"]

Der DevSecOps-Prozess mit Trivy als Schwachstellenscanner

Fazit und Best Practices

Trivy ist ein vielseitiges Tool mit dem eine unterschiedlichste Schwachstellen aufgedeckt und reported werden können. Es kann mit einfachen Mitteln in die CI-Pipeline integriert werden und damit die Automatisierung des DevSecOps-Prozesses unterstützen. Mit der Erzeugung von SBOMs und deren anschließende Archivierung kann man die Grundlagen für erfolgreiche Auditierungen schaffen.