Blog

Schwachstellenscanner Trivy: Sicherheitsprüfung für Docker-Container in CI/CD-Pipelines

Trivy scannt in CI/CD-Pipelines Docker-Container auf Schwachstellen.
2. August 2024
Picture of Skaylink
Skaylink

In der Software-Entwicklung hat Sicherheit heute höchste Priorität. Da inzwischen immer mehr containerisiert wird, muss auch auf die Sicherheit der Docker-Images geachtet werden – sonst holt man sich Schwachstellen ins Haus. CI/CD-Pipelines sind eine robuste Plattform für die automatische Software-Bereitstellung, und genau dort sollten beim Erstellen der Container spezielle Scanning-Tools zum Einsatz kommen. In diesem Blogartikel sehen wir uns an, wie sich mit Trivy die Sicherheit von Docker-Containern in CI/CD-Pipelines optimieren lässt.

Warum Docker-Container abgesichert werden müssen

Docker-Container haben zahlreiche Vorteile. Sie sind portabel, skalierbar und funktionieren zuverlässig in jeder Umgebung. Doch sie bringen auch Sicherheitsprobleme mit sich: Enthalten Container-Images bereits Schwachstellen, kann es später zu Datenlecks, Systemkompromittierung oder Dienstausfällen kommen. Deshalb ist es so wichtig, Sicherheitsaspekte während des gesamten Container-Lebenszyklus zu beachten, von der Entwicklung bis zur Bereitstellung.

Die Lösung: Trivy

Trivy ist ein Open-Source-Schwachstellenscanner für Container und andere Artefakte, der sehr schnell Sicherheitsprobleme in Images erkennt. Damit können Sie in Ihren CI/CD-Pipelines die Schwachstellenprüfung automatisieren und dafür sorgen, dass nur sichere Container-Images in der Produktionsumgebung bereitgestellt werden.

Trivy in CI/CD-Pipelines integrieren

CI/CD-Pipelines sind eine flexible, individuell anpassbare Methode für die Software-Bereitstellung. Mit Trivy integrieren Sie den Schwachstellenscan dort direkt in den Prozess der Container-Erstellung. Das funktioniert im Wesentlichen wie folgt:

  1. Trivy installieren: Zuerst installieren Sie Trivy in Ihrer CI/CD-Umgebung. Sie können es entweder als Standalone-Tool verwenden oder zur einfacheren Integration in einen Docker-Container einbauen.
  2. Pipeline konfigurieren: Anschließend richten Sie eine CI/CD-Pipeline für die Erstellung von Docker-Images ein – mit Phasen für die Image-Erstellung, den Trivy-Scan und das Deployment.
  3. Trivy-Scan integrieren: Sie fügen in Ihre Pipeline einen Schritt ein, in dem Trivy ausgeführt wird und das Docker-Image auf Schwachstellen prüft. Trivy wird über die Kommandozeile aufgerufen, wodurch es sich ganz einfach in Pipeline-Skripte integrieren lässt.
  4. Ergebnisse analysieren: Nach dem Trivy-Scan sehen Sie sich die Ergebnisse mit den gefundenen Schwachstellen an. Trivy liefert einen detaillierten Bericht mit Informationen über den Schweregrad der Sicherheitslücken und Empfehlungen zur Behebung.
  5. Build-Fail bei Schwachstellen: Damit Sicherheitsstandards nicht umgangen werden können, sollten Sie Ihre Pipeline so konfigurieren, dass der Build fehlschlägt, wenn der Trivy-Scan schwerwiegende Schwachstellen findet. So gelangen nur die Images in die Produktion, die den Trivy-Scan bestanden haben.

Azure DevOps-Pipeline einrichten

Legen Sie in Azure DevOps eine YAML-Pipeline an, die ein Docker-Image erstellt, mit Trivy scannt und in einer Container-Registry veröffentlicht, sofern keine Schwachstellen erkannt wurden.

Schritt 1: Neue Pipeline anlegen

  1. Loggen Sie sich in Ihr Azure DevOps-Konto ein, und navigieren Sie zu Ihrem Projekt.
  2. Wählen Sie „Pipelines“ > „New Pipeline“ und dann „Azure Repos Git“ als Quelle.

Schritt 2: YAML-Pipeline definieren

Ersetzen Sie <YourContainerRegistry> und <YourDockerfile> durch Ihre Container-Registry bzw. den Namen Ihres Dockerfiles.

((Codeblock begin))

trigger:
– main

pool: 

  vmImage: ‚ubuntu-latest‘ 

 

steps: 

  – task: Docker@2 

    displayName: ‚Build Docker image‘ 

    inputs: 

      command: ‚build‘ 

      dockerfile: ‚<YourDockerfile>‘ 

      tags: ‚latest‘ 

      repository: ‚<YourContainerRegistry>/<YourImageName>‘

((Codeblock end))

Schritt 3: Trivy-Scan hinzufügen

Fügen Sie in die Pipeline einen Schritt ein, in dem Trivy ausgeführt wird und das Docker-Image auf Schwachstellen prüft.

  • Trivy-Scan nach Erstellen des Docker-Image einfügen:

((Codeblock begin))

– task: Bash@3 

    displayName: ‚Run Trivy vulnerability scan‘ 

    inputs: 

      targetType: ‚inline‘ 

      script: | 

        # Install Trivy 

        Wget https://github.com/aquasecurity/trivy/releases/download/v0.49.1/trivy_0.49.1_Linux-64bit.tar.gz 

        tar zxvf trivy_0.49.1_Linux-64bit.tar.gz 

        sudo mv trivy /usr/local/bin/trivy 

        rm trivy_0.49.1_Linux-64bit.tar.gz 

 

        # Run Trivy scan 

        trivy image –severity HIGH,CRITICAL –exit-code 1 <YourContainerRegistry>/<YourImageName>:latest 

((Codeblock end))

Im Scanning-Schritt konfigurieren Sie Trivy so, dass der Scan mit Exit-Code 1 endet, wenn im Container eine HIGH- oder CRITICAL-Schwachstelle gefunden wird. Dadurch schlägt der Schritt in der Azure-Pipeline fehl, und die Pipeline-Ausführung stoppt. Trivy zeigt ein Protokoll der Ergebnisse an und empfiehlt jeweils eine Version, bei der die Schwachstelle behoben ist.

Schritt 4: Docker-Push hinzufügen

Fügen Sie in die Pipeline einen Schritt ein, in dem das Docker-Image in die Container-Registry gepusht wird. Dieser Schritt wird nur ausgeführt, wenn Trivy keine Schwachstellen gefunden hat.

  • Docker-Push nach Trivy-Scan einfügen:

((Codeblock begin))

– task: Docker@2 

    displayName: ‚Push Docker image to Container Registry‘ 

    inputs: 

      command: ‚push‘ 

      tags: ‚latest‘ 

      repository: ‚<YourContainerRegistry>/<YourImageName>‘ 

((Codeblock end))

Vollständige YAML-Pipeline

So sieht die komplette YAML-Pipeline mit Trivy-Scan aus:

((Codeblock begin))

trigger: 

  – main 

 

pool: 

  vmImage: ‚ubuntu-latest‘ 

 

steps: 

  – task: Docker@2 

    displayName: ‚Build Docker image‘ 

    inputs: 

      command: ‚build‘ 

      dockerfile: ‚<YourDockerfile>‘ 

      tags: ‚latest‘ 

      repository: ‚<YourContainerRegistry>/<YourImageName>‘ 

             

  – task: Bash@3 

    displayName: ‚Run Trivy vulnerability scan‘ 

    inputs: 

      targetType: ‚inline‘ 

      script: | 

        # Install Trivy 

        wget https://github.com/aquasecurity/trivy/releases/download/v0.49.1/trivy_0.49.1_Linux-64bit.tar.gz 

        tar zxvf trivy_0.49.1_Linux-64bit.tar.gz 

        sudo mv trivy /usr/local/bin/trivy 

        rm trivy_0.49.1_Linux-64bit.tar.gz 

 

        # Run Trivy scan 

        trivy image –severity HIGH,CRITICAL –exit-code 1 <YourContainerRegistry>/<YourImageName>:latest 

 

   – task: Docker@2 

     displayName: ‚Push Docker image to Container Registry‘ 

     inputs: 

 command: ‚push‘ 

 tags: ‚latest‘ 

 repository: ‚<YourContainerRegistry>/<YourImageName>‘ 

((Codeblock end))

Vorteile der sicheren Container-Erstellung

Trivy in Ihre CI/CD-Pipelines zu integrieren, hat mehrere Vorteile:

  • Frühzeitige Erkennung: Schwachstellen in Docker-Images werden im Entwicklungsprozess bereits früh erkannt. Das Risiko von Sicherheitslücken im Code sinkt damit erheblich.
  • Automatische Sicherheitsprüfung: In Ihrer CI/CD-Pipeline werden automatisch Sicherheitsscans durchgeführt. Das senkt den manuellen Aufwand und sorgt für konsistente Sicherheitsverfahren.
  • Umfassendes Reporting: Trivy stellt detaillierte Berichte über die gefundenen Schwachstellen bereit. Sie liefern Ihren Teams die Informationsgrundlage für fundierte Entscheidungen zur Risikoeindämmung.
  • Bessere Compliance: Sicherheitsmaßnahmen während des gesamten Container-Lebenszyklus von der Entwicklung bis zur Bereitstellung umzusetzen, leistet einen wichtigen Beitrag zur Compliance.

Fazit

Docker-Container müssen abgesichert werden, um Anwendungen und Infrastruktur vor potenziellen Bedrohungen zu schützen. Mit Trivy in Ihrer CI/CD-Pipeline können Sie Schwachstellenscans automatisieren und dafür sorgen, dass nur sichere Container-Images in der Produktion bereitgestellt werden. Diese proaktiven Sicherheitsmaßnahmen stärken die Resilienz Ihrer Software-Systeme und sichern Ihnen das Vertrauen Ihrer Kunden und Stakeholder.