Container Scanning in GitLab: der vollständige Leitfaden

Schwachstellen in Containern warten nicht auf das nächste Deployment. Sie können jederzeit auftreten – beim Erstellen eines Images ebenso wie während des Betriebs in der Produktion. GitLab begegnet dieser Realität mit mehreren Ansätzen zum Container Scanning, die jeweils auf eine bestimmte Phase im Lebenszyklus eines Containers zugeschnitten sind.

Dieser Leitfaden stellt die verschiedenen Arten des Container Scannings in GitLab vor, zeigt, wie sich jede aktivieren lässt, und erläutert die wichtigsten Konfigurationsmöglichkeiten für den Einstieg.

Warum Container Scanning zählt

Sicherheitslücken in Container-Images bergen Risiken über den gesamten Anwendungslebenszyklus hinweg. Basis-Images, Betriebssystempakete und Anwendungsabhängigkeiten können allesamt Schwachstellen enthalten, die aktiv ausgenutzt werden. Container Scanning erkennt diese Risiken frühzeitig – bevor sie die Produktion erreichen – und zeigt, sofern verfügbar, Wege zur Behebung auf.

Container Scanning ist ein zentraler Bestandteil der Software Composition Analysis (SCA) und hilft dabei, die externen Abhängigkeiten containerisierter Anwendungen zu verstehen und abzusichern.

Die fünf Arten des Container Scannings in GitLab

GitLab bietet fünf unterschiedliche Ansätze für das Container Scanning, die jeweils einem bestimmten Zweck innerhalb einer Sicherheitsstrategie dienen.

1. Pipeline-basiertes Container Scanning

• Funktion: Scannt Container-Images während der Ausführung der CI/CD-Pipeline und erkennt Schwachstellen vor dem Deployment
• Geeignet für: Shift-Left-Sicherheit; verhindert, dass anfällige Images die Produktion erreichen
• Verfügbarkeit: Free, Premium und Ultimate (mit erweitertem Funktionsumfang in Ultimate)
• Dokumentation

GitLab nutzt den Sicherheitsscanner Trivy, um Container-Images auf bekannte Schwachstellen zu untersuchen. Beim Durchlauf der Pipeline analysiert der Scanner die Images und erstellt einen detaillierten Bericht.

Pipeline-basiertes Container Scanning aktivieren

Für die Aktivierung gibt es zwei Wege. Über Secure > Security configuration im Projekt lässt sich in der Zeile „Container Scanning“ per Configure with a merge request automatisch ein Merge Request mit der nötigen Konfiguration erzeugen. Alternativ kann das Template Jobs/Container-Scanning.gitlab-ci.yml direkt in die .gitlab-ci.yml eingebunden werden. Die vollständige Syntax und alle Variablen finden sich in der Dokumentation.

Für gängige Anpassungen stehen CI/CD-Variablen bereit: Über CS_IMAGE lässt sich ein bestimmtes zu scannendes Image festlegen, über CS_SEVERITY_THRESHOLD ein Schwellenwert für den Schweregrad – wird dieser etwa auf „HIGH“ gesetzt, erscheinen nur Schwachstellen ab dem Schweregrad „High“.

Schwachstellen im Merge Request anzeigen

Werden gefundene Schwachstellen direkt im Merge Request angezeigt, wird die Sicherheitsprüfung Teil des Reviews. Sobald Container Scanning in der Pipeline konfiguriert ist, zeigt GitLab erkannte Schwachstellen automatisch im Security-Widget des Merge Requests an.

Im Merge Request angezeigte Container-Scanning-Schwachstellen

Im Abschnitt „Security Scanning“ eines Merge Requests erscheint eine Übersicht neu eingeführter und bereits bestehender Schwachstellen in den Container-Images. Ein Klick auf eine einzelne Schwachstelle öffnet die Detailansicht mit Schweregrad, betroffenen Paketen und – sofern vorhanden – Hinweisen zur Behebung.

Detailansicht einer Schwachstelle im Merge Request

Detailansicht einer Container-Scanning-Schwachstelle im Merge Request

So lassen sich Schwachstellen in Containern erkennen und beheben, bevor sie die Produktion erreichen – als integraler Teil des Code-Reviews statt als vorgelagerte, separate Prüfung.

Schwachstellen im Vulnerability Report einsehen

Über den Merge Request hinaus bietet GitLab einen zentralen Vulnerability Report, der Sicherheitsteams einen projektweiten Überblick über alle Container-Scanning-Ergebnisse gibt.

Nach Container Scanning gefilterter Vulnerability Report

Erreichbar ist der Bericht über Security & Compliance > Vulnerability Report in der Projekt-Seitenleiste. Er bündelt alle in den Branches erkannten Container-Schwachstellen und lässt sich nach Schweregrad, Status, Scanner-Typ oder einzelnen Container-Images filtern. Ein Klick auf eine Schwachstelle führt zur zugehörigen Detailseite.

Vulnerability-Detailseite, erste Ansicht

Vulnerability-Detailseite, zweite Ansicht

Detailansicht einer Container-Scanning-Schwachstelle

Die Vulnerability Details zeigen genau, welche Container-Images und Layer betroffen sind, und erleichtern so das Zurückverfolgen zur Ursache. Schwachstellen lassen sich Teammitgliedern zuweisen, im Status ändern (erkannt, bestätigt, behoben, verworfen), mit Kommentaren zur Zusammenarbeit versehen und mit zugehörigen Issues zur Nachverfolgung der Behebung verknüpfen.

Auf diese Weise wird das Schwachstellenmanagement zum festen Bestandteil des Entwicklungsprozesses: Container-Sicherheitsbefunde werden nachvollziehbar erfasst, priorisiert und systematisch behoben.

Die Dependency List öffnen

Die Dependency List von GitLab liefert eine umfassende Software Bill of Materials (SBOM), die jede Komponente in den Container-Images erfasst und damit vollständige Transparenz über die Software-Lieferkette schafft.

GitLab Dependency List (SBOM)

Über Security & Compliance > Dependency List öffnet sich ein Inventar aller Pakete, Bibliotheken und Abhängigkeiten, die das Container Scanning im Projekt erkannt hat. Diese Ansicht macht sichtbar, was in den Containern tatsächlich läuft – von Betriebssystempaketen bis hin zu Abhängigkeiten auf Anwendungsebene. Filtern lässt sich nach Paketmanager, Lizenztyp oder Schwachstellenstatus, sodass sich sicherheits- oder compliancerelevante Komponenten schnell eingrenzen lassen. Jeder Eintrag zeigt die zugehörigen Schwachstellen im Kontext der realen Software-Komponenten statt als isolierten Befund.

2. Container Scanning for Registry

• Funktion: Scannt automatisch Images, die mit dem Tag latest in die GitLab Container Registry gepusht werden
• Geeignet für: Kontinuierliche Überwachung von Registry-Images ohne manuelles Auslösen einer Pipeline
• Verfügbarkeit: nur Ultimate
• Dokumentation

Wird ein Container-Image mit dem Tag latest gepusht, löst der Security-Policy-Bot von GitLab automatisch einen Scan gegen den Default-Branch aus. Anders als das pipeline-basierte Scanning arbeitet dieser Ansatz mit dem Continuous Vulnerability Scanning zusammen, um auf neu veröffentlichte Sicherheitshinweise zu reagieren.

Container Scanning for Registry aktivieren

Die Aktivierung erfolgt über Secure > Security configuration: Dort im Abschnitt Container Scanning For Registry die Funktion einschalten.

Schalter für Container Scanning for Registry

Vorausgesetzt werden dabei die Maintainer-Rolle oder höher, ein nicht leeres Projekt (mindestens ein Commit im Default-Branch), konfigurierte Benachrichtigungen der Container Registry sowie eine eingerichtete Package Metadata Database (auf GitLab.com standardmäßig aktiv). Gefundene Schwachstellen erscheinen im Tab Container Registry vulnerabilities des Vulnerability Reports.

3. Multi-Container Scanning

• Funktion: Scannt mehrere Container-Images parallel innerhalb einer einzigen Pipeline
• Geeignet für: Microservices-Architekturen und Projekte mit mehreren Container-Images
• Verfügbarkeit: Free, Premium und Ultimate (aktuell als Beta)
• Dokumentation

Das Multi-Container Scanning führt Scans über dynamische Child-Pipelines nebenläufig aus, wenn mehrere Images zu prüfen sind.

Multi-Container Scanning aktivieren

Grundlage ist eine Datei .gitlab-multi-image.yml im Wurzelverzeichnis des Repositorys, in der die zu scannenden Images als Ziele definiert werden; anschließend wird das Template Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml in die .gitlab-ci.yml eingebunden. Auch das Scannen von Images aus privaten Registries sowie das Einbeziehen von Lizenzinformationen lässt sich dort konfigurieren. Die vollständige Konfiguration beschreibt die Dokumentation.

4. Continuous Vulnerability Scanning

• Funktion: Erzeugt automatisch Schwachstelleneinträge, sobald neue Sicherheitshinweise veröffentlicht werden – ohne dass eine Pipeline nötig ist
• Geeignet für: Proaktive Überwachung zwischen Deployments
• Verfügbarkeit: nur Ultimate
• Dokumentation

Herkömmliches Scanning erfasst Schwachstellen nur zum Zeitpunkt des Scans. Doch was geschieht, wenn morgen ein neuer CVE für ein Paket veröffentlicht wird, das gestern gescannt wurde? Genau hier setzt das Continuous Vulnerability Scanning an: Es überwacht die GitLab Advisory Database und legt automatisch Schwachstelleneinträge an, sobald neue Hinweise die eingesetzten Komponenten betreffen.

Funktionsweise

Der Ablauf besteht aus vier Schritten: Ein Container- oder Dependency-Scanning-Job erzeugt eine CycloneDX-SBOM. GitLab registriert daraus die Komponenten des Projekts. Werden neue Sicherheitshinweise veröffentlicht, prüft GitLab, ob die eigenen Komponenten betroffen sind. Zutreffende Schwachstellen erscheinen anschließend automatisch im Vulnerability Report.

Einige Punkte sind dabei zu beachten: Die Scans laufen über Hintergrundjobs (Sidekiq), nicht über CI-Pipelines. Für die Erkennung neuer Komponenten werden nur Hinweise aus den letzten 14 Tagen berücksichtigt. Als Scanner-Name erscheint „GitLab SBoM Vulnerability Scanner“. Um Schwachstellen als behoben zu markieren, ist weiterhin ein pipeline-basierter Scan nötig.

5. Operational Container Scanning

• Funktion: Scannt laufende Container im Kubernetes-Cluster in einem festgelegten Zeitintervall
• Geeignet für: Sicherheitsüberwachung nach dem Deployment und Erkennung von Laufzeit-Schwachstellen
• Verfügbarkeit: nur Ultimate
• Dokumentation

Das Operational Container Scanning schlägt die Brücke zwischen Sicherheit zur Build-Zeit und Sicherheit zur Laufzeit. Über den GitLab-Agent für Kubernetes scannt es Container, die tatsächlich in den Clustern laufen, und erkennt so Schwachstellen, die erst nach dem Deployment auftreten.

Operational Container Scanning aktivieren

Beim Einsatz des GitLab-Agents für Kubernetes wird das Scanning über die Konfigurationsdatei des Agents eingerichtet, wobei sich ein Intervall (etwa täglich) sowie die einzubeziehenden Namespaces festlegen lassen. Ebenso lässt sich über eine Scan Execution Policy ein durch den GitLab-Agent erzwungener, terminierter Scan definieren.

Bedingungen einer Scan Execution Policy für Operational Container Scanning

Die Ergebnisse finden sich über Operate > Kubernetes clusters: im Tab Agent den Agent auswählen und anschließend im Tab Security die Cluster-Schwachstellen einsehen. Zusätzlich erscheinen sie im Tab Operational Vulnerabilities des Vulnerability Reports.

Sicherheitsniveau mit GitLab Security Policies erhöhen

Mit GitLab Security Policies lassen sich einheitliche Sicherheitsstandards über automatisierte, richtliniengesteuerte Kontrollen durchsetzen. Solche Richtlinien verankern Anforderungen direkt in der Entwicklungs-Pipeline und stellen sicher, dass Schwachstellen erkannt und behoben werden, bevor Code die Produktion erreicht.

Scan Execution Policies und Pipeline Execution Policies

Scan Execution Policies steuern, wann und wie Container Scanning projektübergreifend läuft. So lassen sich etwa Scans bei jedem Merge Request auslösen oder wiederkehrende Scans des Haupt-Branches ansetzen – ohne dass Entwicklungsteams das Scanning in jeder einzelnen Pipeline manuell einrichten müssen. Auch die zu verwendende Scanner-Version und die Scan-Parameter lassen sich zentral festlegen.

Konfiguration einer Scan Execution Policy

Pipeline Execution Policies bieten flexible Kontrolle, um eigene Jobs in eine Pipeline einzufügen oder bestehende zu überschreiben – je nach Compliance-Anforderung. Damit lassen sich Container-Scanning-Jobs automatisch einfügen, Builds bei Überschreiten der Risikotoleranz abbrechen, zusätzliche Prüfungen für bestimmte Branches oder Tags anstoßen oder Compliance-Vorgaben für Images durchsetzen, die für die Produktion bestimmt sind.

Aktionen einer Pipeline Execution Policy

Merge Request Approval Policies

Merge Request Approval Policies setzen Sicherheits-Gates durch, indem sie festgelegte Prüfer(innen) verlangen, die Merge Requests mit Container-Schwachstellen freigeben. So lassen sich Richtlinien definieren, die einen Merge bei kritischen oder schwerwiegenden Schwachstellen blockieren oder die Freigabe durch das Sicherheitsteam verlangen, sobald ein Merge Request neue Container-Befunde einführt.

Merge Request Approval Policy blockiert einen Merge Request

Den passenden Ansatz wählen

Für eine umfassende Absicherung bietet es sich an, mehrere Ansätze zu kombinieren: pipeline-basiertes Scanning, um Probleme während der Entwicklung zu erkennen, Registry-Scanning zur kontinuierlichen Überwachung und Operational Scanning für den Einblick in die Produktion.

Der Einstieg

Der direkteste Einstieg in die Container-Sicherheit ist das pipeline-basierte Scanning: im Projekt unter Secure > Security configuration für Container Scanning Configure with a merge request auswählen und den erzeugten Merge Request mergen. Der nächste Pipeline-Durchlauf enthält dann bereits das Schwachstellen-Scanning.

Darauf aufbauend lassen sich je nach Sicherheitsanforderung und GitLab-Tarif weitere Scanning-Arten ergänzen. Container-Sicherheit ist keine einmalige Aufgabe, sondern ein fortlaufender Prozess. Mit den Container-Scanning-Funktionen von GitLab lassen sich Schwachstellen in jeder Phase des Container-Lebenszyklus erkennen – vom Build bis zur Laufzeit.

Weitere Informationen dazu, wie GitLab das Sicherheitsniveau stärkt, bietet die Seite zu GitLab Security- und Governance-Lösungen.