Zum Hauptinhalt springen

​
Übersicht

  • Funktion: Container-Image-Scanning erkennt bekannte Schwachstellen in den von Ihrem Projekt verwendeten Container-Images. Dazu gehören Schwachstellen in Paketen des Basisbetriebssystems, Systembibliotheken und Anwendungspaketen in den Image-Layern. Wenn Sie Images vor dem Deployment scannen, erkennen Sie Sicherheitsrisiken in containerisierten Anwendungen frühzeitig.
  • Zielgruppe: Security-Teams, Entwickler und DevOps Engineers, die containerisierte Anwendungen bereitstellen und die aus Basis-Images übernommenen Schwachstellen nachvollziehen möchten.

​
So funktioniert es

Corgea erkennt automatisch die in Ihrem Projekt referenzierten Container-Images und gleicht jedes Image mit bekannten Schwachstellendatenbanken ab.
1

Erkennung von Images

Corgea durchsucht Ihr Projekt nach Dockerfile- und Docker-Compose-Dateien und extrahiert die darin enthaltenen Image-Referenzen:
  • Dockerfiles: Basis-Images, die mit FROM deklariert sind (zum Beispiel FROM python:3.11-slim)
  • Docker Compose: Images, die für jeden Service unter image: deklariert sind (zum Beispiel image: postgres:15)
Doppelte Images werden zusammengeführt und der jeweils referenzierenden Datei zugeordnet.
2

Image-Analyse

Jedes Image wird abgerufen und seine Layer werden analysiert, um ein Inventar der installierten Software zu erstellen. Dazu gehören Betriebssystem- und Distributionspakete (Debian, Ubuntu, Alpine und weitere) sowie im Image installierte Anwendungspakete.
3

Abgleich von Schwachstellen

Die entdeckten Pakete werden gegen bekannte Schwachstellendatenbanken abgeglichen, und alle Übereinstimmungen werden zusammen mit Ihren anderen Scan-Ergebnissen gemeldet.

​
Ein vollständig gebautes Image scannen

Der oben beschriebene Erkennungsablauf scannt die Basis-Images, die Ihr Projekt referenziert. Um stattdessen ein vollständig gebautes Image zu scannen – etwa eines, das Sie gerade in der CI gebaut haben und das nie in eine Registry gepusht wurde –, übergeben Sie es der CLI mit --include-image:
Ihre lokale Container-Engine (docker oder podman) exportiert das Image, und die CLI lädt es mit Ihrem Projekt hoch. Das Image wird damit genau so gescannt, wie es ausgeliefert wird. Wenn Sie --include-image verwenden, scannt Corgea die übergebenen Images, anstatt Basis-Images aus Ihrem Quellcode zu ermitteln. --include-image wird nur vom BLAST-Scanner unterstützt. Container-Scanning muss für Ihr Konto aktiviert sein. Das vollständige Verhalten der Option beschreibt Container-Images scannen in der CLI-Referenz.

​
Befunde über Scans hinweg verfolgen

Corgea verfolgt einen Container-Befund anhand von Image, Paket und Schwachstellenhinweis. Triage-Entscheidungen bleiben bei Änderungen der Paketversion erhalten, während unterschiedliche Pakete, die vom selben Hinweis betroffen sind, getrennte Befunde bleiben.

​
Unterstützte Registries

Corgea scannt Images aus öffentlichen Registries ohne Einrichtung:
  • Docker Hub
  • GitHub Container Registry (GHCR)
  • Google Container Registry (GCR)
  • Quay.io
  • Microsoft Container Registry (MCR)
  • Amazon ECR Public
  • GitLab Container Registry
Images aus privaten Registries werden gescannt, wenn Sie die Registry als Docker-Registry unter Private Package Registries verbinden. Das umfasst private Images auf Docker Hub, GitHub, GitLab, Azure und Google Artifact Registry sowie selbst gehostete Registries wie JFrog Artifactory, Sonatype Nexus und Harbor.
Die automatische Image-Erkennung wird aktiviert, sobald Corgea Docker-Dateien in Ihrem Projekt erkennt, und benötigt keine Konfiguration. Für das Scannen eines vollständig gebauten Images mit --include-image muss Container-Scanning für Ihr Konto aktiviert sein.

​
Einschränkungen

Diese Grenzen gelten für Images, die Corgea selbst erkennt und pullt:
  • Private Registries benötigen Zugangsdaten: Ein Image aus einer privaten Registry wird übersprungen, sofern keine Docker-Registry für seinen Host auf das Projekt angewendet wird. Private Amazon-ECR-Registries werden nicht unterstützt. Um ein Image zu scannen, das Corgea nicht pullen kann, pullen oder bauen Sie es auf Ihrem eigenen Runner und übergeben es mit --include-image. Das Image wird dann aus Ihrer Container-Engine hochgeladen, anstatt dass Corgea es abruft.
  • Maximale Image-Größe: Images über 1000 MB (1 GB) werden übersprungen.
  • Es werden nur Images erkannt, die in Dockerfile- oder Docker-Compose-Dateien referenziert sind. Mit --include-image scannen Sie ein Image, das in keiner der beiden Dateien vorkommt.

​
Best Practices

Verwenden Sie spezifische Image-Tags (zum Beispiel python:3.11.5-slim) anstelle von latest für konsistente, reproduzierbare Scannergebnisse.
  • Spezifische Tags verwenden: Vermeiden Sie latest-Tags; fixieren Sie genaue Versionen, damit Scans reproduzierbar sind.
  • Minimale Basis-Images bevorzugen: Verwenden Sie Slim-, Alpine- oder Distroless-Varianten, um die Angriffsfläche zu reduzieren.
  • Regelmäßige Updates: Halten Sie Basis-Images auf dem neuesten Stand, um Sicherheitsupdates zu übernehmen.
  • Multi-Stage-Builds: Minimieren Sie die Größe des finalen Images und die Anzahl der enthaltenen Pakete.

​
Verwandt