Drei Schritte zur Sicherheit von Container-Images

Sicherheit von Container-Images mit Docker

Wenn Sie schon einmal ein Container-Image auf Schwachstellen geprüft haben, sind Ihnen wahrscheinlich mehr als nur ein paar Probleme begegnet – vielleicht Hunderte oder sogar Tausende. Dieser gemeinsam von Snyk und Docker verfasste Leitfaden Container-Sicherheit für Entwicklungsteams konzentriert sich auf das Container-Image und die darin gebündelte Software. Hier können Sie die PDF-Version dieses Leitfadens zur Container-Sicherheit herunterladen.

Zunächst erfahren Sie, warum Container-Sicherheit wichtig ist. Container werden immer beliebter, bergen jedoch Sicherheitsrisiken, die Unternehmen Produktivitätseinbußen, Umsatzrückgänge und sogar Bußgelder in Millionenhöhe bescheren können. Dieser Artikel stellt unseren dreistufigen Prozess zur Erstellung sicherer Container-Images vor. Erstellen Sie ein kostenloses Snyk-Konto, um Schwachstellen in Docker-Images und Open-Source-Bibliotheken ganz einfach zu finden und zu beheben.

Drei Schritte zur Sicherheit von Container-Images

Wie bereits erwähnt, betrifft die Sicherheit von Container-Images nicht nur einen einzelnen Bereich – sie erstreckt sich auf Entwicklungs-, Sicherheits- und Betriebsteams. Bei Containern spielen verschiedene Sicherheitsaspekte eine Rolle:

• Das Container-Image selbst und die darin enthaltene Software

• Das Zusammenspiel zwischen einem Container, dem Host-Betriebssystem und anderen Containern auf demselben Host

• Das Host-Betriebssystem selbst

• Aspekte rund um Container-Netzwerke und -Speicher

• Laufzeitsicherheit, häufig in Kubernetes-Clustern

Jeder dieser Punkte verdient einen eigenen Leitfaden, um ihm gerecht zu werden. Für alle außer dem ersten gibt es bereits mindestens einen Leitfaden. Dieser Leitfaden konzentriert sich auf das Container-Image und die darin gebündelte Software.

Im Wesentlichen umfasst die Erstellung eines sicheren Container-Images drei wichtige Schritte:

1. Sichern Sie Ihren Code und seine Abhängigkeiten

2. Verwenden Sie als Ausgangspunkt ein minimales Basis-Image aus einer vertrauenswürdigen Quelle

3. Verwalten Sie die Tools und Pakete, die Sie während des gesamten Entwicklungslebenszyklus zu Images hinzufügen

Wir betrachten jeden dieser Schritte etwas genauer und zeigen, wie sich mit diesem Ansatz sichere Container-Images erstellen lassen.

1. Sichern Sie Ihren Code und seine Abhängigkeiten

Die schnellere Bereitstellung Cloud-nativer Anwendungen ist wahrscheinlich einer der Hauptgründe, warum Sie überhaupt Container erstellen. Ihre Anwendungen sind das Lebenselixier Ihres Unternehmens. Noch vor gar nicht so langer Zeit begann und endete die Anwendungssicherheit beim Code. Container und andere moderne Entwicklungspraktiken haben zwar die weit gefasste Bedeutung von „Anwendungscode“ erweitert, doch dieser besondere Aspekt bleibt weiterhin relevant.

Glücklicherweise ist dies der Teil von Container-Images, den Entwickler am direktesten kontrollieren können und hoffentlich auch am besten verstehen. Dennoch ist es nicht einfach, sämtliche Code-Abhängigkeiten aufzuspüren und herauszufinden, wie sich Sicherheitsprobleme beheben lassen. Wenn Sie Zugriff auf den Quellcode haben, sollten Sie speziell entwickelte Tools wie Snyk Open Source verwenden, um eine Software Composition Analysis (SCA) und ein Static Application Security Testing (SAST) durchzuführen und Ihren Code sowie seine Abhängigkeiten zu analysieren. Bei modernen Anwendungen machen Abhängigkeiten von Open-Source-Software Dritter oft den Großteil der Codezeilen aus.

Abbildung 2: Die Menge an Open-Source-Code in einer App kann die Menge an proprietärem Code leicht in den Schatten stellen.

Wenn Sie Probleme früh im Entwicklungsprozess erkennen und Sicherheitstools in Ihren Quellcode integrieren, können Sie diesen Prozess unabhängig von der Containerisierung automatisieren. Zwar lassen sich Container scannen und manche Arten von Code analysieren, doch die Erkennung dieser Probleme direkt in Ihren Git-Commits, Pipelines und Repositorys passt wahrscheinlich besser zum Arbeitsablauf von Entwicklern.

2. Verwenden Sie als Ausgangspunkt ein minimales Basis-Image aus einer vertrauenswürdigen Quelle

Warum sind kleine Images so wichtig?

Das Basis-Image – die FROM-Zeile in Ihrer Dockerfile – ist einer der wichtigsten Sicherheitsaspekte. Glücklicherweise bieten viele vertrauenswürdige Anbieter Inhalte, die Sie problemlos verwenden können. Docker Hub ist mit Abstand der beliebteste Ausgangspunkt für die Suche nach Container-Basis-Images.

Docker Hub bietet mehr als 3,8 Millionen verfügbare Images und über 7 Millionen Repositorys. Docker Hub ist sehr aktiv und verzeichnet rund 11 Milliarden Pulls pro Monat. Einige dieser Images sind Official Images, die Docker als kuratierte Sammlung von Docker-Open-Source- und „Drop-in“-Lösungs-Repositorys veröffentlicht.

Docker bietet außerdem Images von Verified Publishers an. Diese hochwertigen Images werden direkt von einem kommerziellen Unternehmen veröffentlicht und gepflegt, das Docker als Verified Publisher bestätigt hat. Die Richtlinien, die Docker diesen verifizierten Herausgebern vorgibt, sind ein guter Ausgangspunkt, um eigene interne Best Practices für Container-Images festzulegen.

Abbildung 3: Offizielle Images auf Docker Hub. Beachten Sie das „Official“-Abzeichen und die aktuellen Aktualisierungen.

Auf Docker Hub finden Sie ganz einfach ein öffentlich verfügbares Image, das zu Ihrem Anwendungsfall passt. Sie sollten jedoch auf die Herkunft der ausgewählten Images achten. So wie Sie Software nicht von einer nicht vertrauenswürdigen Website herunterladen und installieren würden, sollten Sie wahrscheinlich auch keine Images verwenden, die von Ihnen unbekannten und nicht vertrauenswürdigen Nutzern auf Docker Hub bereitgestellt wurden.

Wenn Sie Images aus dem Official-Programm von Docker verwenden oder die Quelle und den Inhalt von Images Dritter kennen und verifizieren können – etwa mit einem Tool wie Notary zur Überprüfung digitaler Signaturen –, haben Sie ein gewisses Maß an Qualitätssicherheit. Um die Zahl der Schwachstellen weiter zu senken und besser zu kontrollieren, was in Ihren Containern enthalten ist, sollten Sie noch einen Schritt weitergehen und minimale, auf Ihre Anforderungen abgestimmte Basis-Images auswählen.

Als Beispiel sehen Sie oben in Abbildung 3 ein Python-Repository. Sie können damit natürlich Ihre Python-Anwendung erstellen, und sie wird mit ziemlicher Sicherheit funktionieren. Das liegt daran, dass das auf Docker Hub gekennzeichnete Image so konzipiert ist, dass es sich für viele Anwendungsfälle eignet und gut gepflegt wird. In diesem Repository gibt es jedoch mehr als 1.000 weitere Python-Images.

Sollten Sie einfach das leicht zu merkende _python verwenden, oder gibt es kleinere Images, die Ihren Anforderungen entsprechen und zugleich Ihre Angriffsfläche verringern_? Wie Sie sich vielleicht denken können, gibt es aus Sicherheitssicht mit ziemlicher Sicherheit bessere Optionen.

Die Größe eines Container-Images ist nicht nur für die Portierbarkeit und schnelle Downloads wichtig. Das Image mit dem Tag python ist einfach zu verwenden, weil es bereits zahlreiche Betriebssystembibliotheken und Entwicklerpakete enthält. Dadurch funktioniert es wahrscheinlich mit vielen Projekten und bietet alles, was Sie zum Kompilieren von Code und Abhängigkeiten benötigen. Schwachstellen-Scanner können jedoch auch eine lange Liste von Problemen melden, denen Sie nachgehen müssen.

Abbildung 4: Ein Vergleich zweier Debian-basierter Images für Python 3.x.

Vielleicht fragen Sie sich, warum beide Images noch immer Schwachstellen aufweisen, insbesondere Schwachstellen mit hohem Schweregrad. Bei näherer Betrachtung dieser konkreten Schwachstellen zeigt sich jedoch, dass sie zu den zugrunde liegenden Betriebssystempaketen gehören. Für keine davon sind Korrekturen verfügbar, und für keine sind bekannte Exploits im Umlauf. Außerdem wurden beide Images im Rahmen des Verifizierungsprozesses von Docker innerhalb der vergangenen Tage mit den neuesten Versionen aller Pakete aktualisiert. Sie werden also tatsächlich gut gepflegt.

Auch der Kontext ist wichtig: Häufig treten Schwachstellen in Entwicklungstools auf, die Sie wahrscheinlich aus der Produktionsversion Ihres Images entfernen möchten – etwa in Tools wie curl, Entwicklungsbibliotheken oder sogar Shells und Paketmanagern. Mit der Zeit ist die Wahrscheinlichkeit, dass neu entdeckte Schwachstellen das größere Python-Image betreffen, jedoch deutlich höher als beim schlankeren Image.

Beispiel zur praktischen Umsetzung der Container-Image-Sicherheit: Auswahl des Basis-Images

Wie bereits erwähnt, ist „Verwenden Sie schlanke Images“ ein Ratschlag, den Sie überall hören können. Einer der Gründe für die Partnerschaft von Docker und Snyk ist jedoch, Ihnen dabei zu helfen, aus Ratschlägen konkrete Maßnahmen zu machen. Die integrierte Funktion zum Scannen auf Schwachstellen in Docker Desktop kann Ihnen die Auswahl eines Basis-Images tatsächlich teilweise abnehmen!

Wir setzen unser Python-Beispiel fort und zeigen, wie Sie vom Python-Image zum Image python:3-slim-buster wechseln können – mithilfe der Funktion zum Scannen auf Schwachstellen von Docker, die von Snyk unterstützt wird. Sie können diese Schritte bei Bedarf selbst nachvollziehen.

Zunächst beginnen wir mit einem einfachen Beispiel und verwenden das Python-Image, um ein sehr einfaches Container-Image zu erstellen. Hier ist die entsprechende Dockerfile:

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

Viel einfacher geht es kaum. Die Datei hello.py besteht aus einer einzelnen print-Anweisung: (“Hello, World!”).

Als Nächstes erstellen wir das Image und führen anschließend einen Scan durch:

$> docker build -t hello-python .

[+] Building 67.4s (5/5) FINISHED
=> [internal] load build definition from Dockerfile 0.4s => => transferring dockerfile: 36B 0.1s => [internal] load .dockerignore 0.4s => => transferring context: 2B 0.1s => [internal] load metadata for docker.io/library/python:latest 1.6s => FROM [1/1] FROM docker.io/library/python 65.1s
...
=> exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:3a92e9... 0.0s => => naming to docker.io/library/hello-python 0.0s

$> docker run hello-python
Hello, World!

$> docker scan hello-python -f Dockerfile
/ Analyzing docker dependencies for hello-python/Dockerfile

Organization: snyk-pmm Package manager: deb
 Target file: Project name: Docker image: Base image:
Dockerfile docker-image|hello-python hello-python
python

Tested 431 dependencies for known issues, found 268 issues. Base Image Vulnerabilities Severity
python:latest 268 6 high, 34 medium, 228 low

Recommendations for base image upgrade:
Alternative image types
Vulnerabilities Severity
75 1 high, 10 medium, 64 low
Base Image
python:3-slim-buster
python:3.9-rc-slim-buster 75 1 high, 10 medium, 64 low

Beachten Sie zunächst, dass im Ergebnis 431 Abhängigkeiten und 268 Probleme im Image gefunden wurden. Der Übersichtlichkeit halber haben wir alle einzelnen Schwachstellen weggelassen – darauf kommen wir gleich noch zurück. Da wir dem Basis-Image python nichts Interessantes hinzugefügt haben, stammen alle 268 Schwachstellen aus dem Basis-Image. Auch das ist in der Ausgabe zu sehen.

Am Ende der Ausgabe erhalten wir jedoch Empfehlungen für Basis-Images, mit denen wir unsere Sicherheitslage verbessern können. Konkret wird das bereits gezeigte Image python:3-slim-buster aufgeführt. Tatsächlich sind wir genau so zu unserem ursprünglichen Vergleich gekommen. Wir sehen bereits, dass dieses neue Image über 70 % der Schwachstellen aus dem Python-Image beseitigt und die Zahl auf eine Schwachstelle mit hohem Schweregrad reduziert. Trotzdem erstellen und scannen wir das Image noch einmal, um es zu bestätigen.

Dazu müssen wir in der Dockerfile lediglich die Zeile FROM ändern. Wir speichern eine separate Kopie unter dem Namen Dockerfile.slim.

FROM python
WORKDIR /app
COPY hello.py /app
CMD [“python3”, “hello.py”]

Anschließend können wir das Image mit einem Slim-Tag erneut erstellen und scannen, damit wir die Images getrennt behalten:

```
$> docker build -t hello-python:slim . -f Dockerfile.slim

[+] Building 21.0s (8/8) FINISHED
=> [internal] load .dockerignore                                        0.1s
=> => transferring context: 2B                                          0.0s
=> [internal] load build definition from Dockerfile.slim                0.1s
=> => transferring dockerfile: 135B                                     0.0s
=> [internal] load metadata for docker.io/library/python:3-slim-buster  11.5s                                                                            
...
=> exporting to image                                                   0.0s                           
=> => exporting layers                                                  0.0s                            
=> => writing image sha256:63768699.                                    0.0s                                          
=> => naming to docker.io/library/hello-python:slim                     0.0s                                                         

$> docker run hello-python:slim
Hello, World!

$> docker scan hello-python:slim -f Dockerfile.slim

Package manager:  deb
Target file:      Dockerfile.slim
Project name:     docker-image hello-python
Docker image:     hello-python:slim
Base image:       python:3-slim-buster
Licenses:         enabled

Tested 94 dependencies for known issues, found 75 issues.

According to our scan, you are currently using the most secure version of the selected base image
```

Diesmal sehen Sie, dass die vollständigen Scan-Ergebnisse nur 94 Abhängigkeiten und eine Schwachstelle mit hohem Schweregrad aufweisen. So helfen Docker und Snyk Ihnen dabei, bessere Basis-Images zu finden. Wie Sie sich vorstellen können, decken wir nicht jedes Image auf Docker Hub ab, aber die meisten beliebten offiziellen Basis-Images.

3. Verwalten Sie alle Ebenen zwischen dem Basis-Image und Ihrem Code

Wir sind ausführlich auf Basis-Images eingegangen, da sie besondere Aufmerksamkeit erfordern. Beim Erstellen eigener Ebenen übernehmen Sie alles, was im Basis-Image enthalten ist. Ein schlankes Image verringert häufig den Sicherheitsaufwand. Doch was ist mit all den Ebenen, die Sie dem Container hinzufügen? Wenn Sie mit einem schlanken Image beginnen, müssen Sie wahrscheinlich Tools und Bibliotheken hinzufügen. Außerdem kommen Ihr Code und verschiedene Komponenten hinzu, die Sie für den Betrieb benötigen. All dies muss auf Schwachstellen überwacht werden.

Die gute Nachricht: Diese mittleren Ebenen können Sie direkt kontrollieren. Dazu zählen alle Ebenen nach der ersten FROM-Zeile bis zu den letzten Zeilen der Dockerfile, in denen Sie die Ausführung Ihres Codes einrichten. Besonders relevant sind die Befehle RUN, COPY und ADD in Dockerfiles, da sie zur Installation von Komponenten dienen. Technisch gesehen kann sich Ihr Code ebenfalls in diesen mittleren Ebenen befinden. Der Einfachheit halber bezeichnen wir Ihren Code jedoch als letzte Ebene – vor allem, weil wir uns in Schritt 1 bereits damit befasst haben.

Abbildung 5: Die mittleren Ebenen eines Container-Images

Eine der größten Herausforderungen beim Umgang mit Schwachstellen in diesen mittleren Ebenen ist es, in den verschiedenen Phasen des Lebenszyklus die richtigen Prioritäten zu setzen.

In jeder Phase benötigen Sie möglicherweise unterschiedliche Tools. Wenn Images jedoch in die Produktion gelangen, sollten Sie alles entfernen, was für den Betrieb Ihrer Anwendung nicht unbedingt erforderlich ist. Passen Sie Ihre Images an, indem Sie mit einem minimalen Basis-Image beginnen und anschließend Ihre Tools hinzufügen. So können Sie diese später ganz einfach entfernen, indem Sie sie aus der Dockerfile löschen und das Image neu erstellen. Noch besser ist es, alle Phasen mit Multi-Stage-Builds in einem einzigen automatisierten Build-Prozess abzubilden.

Sicherheitslücken in Containern priorisieren und beheben

Dennoch werden Sie weiterhin Sicherheitslücken finden und entscheiden müssen, wie Sie damit umgehen. Theoretisch ist es großartig, keine Sicherheitslücken zu haben. In der Praxis ist das jedoch wahrscheinlich nicht machbar oder den erforderlichen Zeitaufwand nicht wert.

Hier finden Sie einen empfohlenen Ausgangspunkt für die traditionellen Entwicklungsphasen: Entwicklung, Test und Produktion. Ihre Software-Produktionsprozesse sind wahrscheinlich komplexer, aber Sie können diese Empfehlungen entsprechend anpassen.

• Beginnen Sie mit Entwicklungs-Images
  Entwicklungs-Images enthalten in den mittleren Schichten wahrscheinlich die meisten Sicherheitslücken, da sie vermutlich die meisten Tools und unterstützenden Pakete benötigen. Die gute Nachricht: WENN Sie Images in mehreren Phasen erstellen und Ihre Produktions-Images all diese Extras nicht enthalten, können Sie viele der Sicherheitslücken in dieser Phase möglicherweise ignorieren. Für diese Entscheidung müssen Sie die im Container installierten Abhängigkeiten nachverfolgen und mit den Anforderungen Ihrer Entwicklungsarbeit im Inner Loop abgleichen können. Es ist völlig normal, dass eine Bibliothek eine Sicherheitslücke aufweist, die als Abhängigkeit einer Abhängigkeit einer Abhängigkeit installiert wird … Sie müssen feststellen können, ob sich die Sicherheitslücke beheben lässt, indem Sie einfach eines Ihrer Entwicklungspakete entfernen.
  
  

  Im folgenden Beispiel haben wir eine Ruby-Anwendung. SQLite wird häufig zusammen mit Ruby verwendet, um die Entwicklung zu vereinfachen. Wahrscheinlich würden Sie jedoch nicht dieselbe SQLite-Datenbank in der Produktion einsetzen. Mit diesem Wissen und den richtigen Details aus dem Container-Sicherheitslücken-Scan können Sie entscheiden, ob Sie Sicherheitslücken in Bibliotheken ignorieren, die bei der Entwicklung mit SQLite installiert werden. Wir sehen uns an, wie der Docker-Scan diese Informationen und weitere Details bereitstellt, die diese Aufgabe erheblich vereinfachen.
  

  

• Test-Images abspecken
  Test-Images: unterscheiden sich in der Praxis kaum von Entwicklungs-Images, zumindest wenn es darum geht, Sicherheitslücken zu bewerten. Wenn Sie wissen, dass eine Sicherheitslücke zu einem Testpaket gehört, das nicht im Produktions-Image enthalten sein wird, können Sie sie ignorieren. Jetzt ist ein guter Zeitpunkt, die Scan-Ergebnisse mit denen aus der Entwicklungsphase zu vergleichen – insbesondere dann, wenn Sie sich entschieden haben, schwerwiegende Sicherheitslücken in der Entwicklungsphase zu ignorieren. Sind die Sicherheitslücken aus den Entwicklungs-Images in den Test-Images tatsächlich verschwunden? Wenn ja, funktioniert Ihr Prozess. Wenn nicht, sollten Sie Ihr Entwicklungs-Image oder Ihre Build-Schritte noch einmal anpassen.

• Produktions-Images gezielt absichern
  Produktions-Images:  sind besonders wichtig, da sie tatsächlich ausgeführt werden und möglicherweise dem Internet ausgesetzt sind. Dennoch kann es schwierig sein, alle Sicherheitslücken zu beseitigen – selbst wenn Sie die Images verkleinern und so viel wie möglich entfernen. In vielen Fällen besteht das Ziel darin, den Release-Prozess zu automatisieren. Sie sollten Sicherheitslücken mit hohem Risiko unbedingt beheben, insbesondere wenn dafür bekannte Exploits existieren. Einer der Gründe, warum Sie auch Images aus der Entwicklungs- und Testphase scannen sollten, ist jedoch, die Zahl der Überraschungen vor dem Release zu verringern. Wenn Sie die Risiken frühzeitig eingedämmt haben, besteht die Hauptaufgabe des Scans in der Produktion darin, neu entdeckte Sicherheitslücken zu finden.

Sehen wir uns ein weiteres Beispiel an, um zu erfahren, wie Sie Docker und Snyk nutzen können, um Ihre mittleren Image-Layer abzusichern.

Praxisbeispiel: Von Benutzer:innen eingeführte Sicherheitslücken bei der Behebung priorisieren

In diesem Beispiel zeigen wir Ihnen einige praktische Techniken für mittlere Schichten, die Sie mit den von Snyk unterstützten Funktionen zum Scannen auf Sicherheitslücken in Docker verwenden können. Diesmal verwenden wir eine etwas interessantere Anwendung. Es handelt sich um eine Ruby-App, was für diese Übungen jedoch nicht besonders wichtig ist.

Hier ist unsere Dockerfile:

```
FROM ruby:2.5.1

RUN apt-get update && \
  apt-get install -y git vim && \
  rm -rf/var/lib/apt/lists/*

RUN gem update --system 3.0.4 && \
  gem install bundler -V '2.0.2'

WORKDIR /usr/src/app/alpha-blog

COPY . .

ENV BUNDLER VERSION 2.0.2

RUN bundle update && \
  bundle install && \
  rails db:setup && \
  rails db:migrate

EXPOSE 3000

CMD ["rails", "server", "-b", "0.0.0.0"]
```

Es handelt sich nach wie vor um eine recht einfache Dockerfile, der wir mehrere Schichten auf unserem Ruby-Basis-Image hinzufügen:

• Die erste RUN-Zeile fügt einige Dienstprogramme hinzu, um lokale Entwicklungsarbeiten im Image zu ermöglichen

• Anschließend aktualisieren wir unsere zentralen Ruby-Komponenten und bereiten sie vor

• Unser Code wird mit dem Befehl COPY . . kopiert

• Unser Rails-Projekt wird mit den Befehlen RUN bundle… eingerichtet

Falls Sie denken: „Git und Vim in einem Image zu installieren, ist eine ungewöhnliche Entscheidung“, liegen Sie richtig. Tun Sie das nicht. Im vollständigen Lab, das in der vorherigen Anmerkung erwähnt wurde, erfahren Sie mehr über die Entstehungsgeschichte dieses Images und warum diese Tools darin enthalten sind.

Es ist zwar nicht besonders schwierig zu erkennen, was hier passiert, aber wie Sie sich vorstellen können, installiert jede dieser Dockerfile-Zeilen einiges und kann dadurch neue Sicherheitslücken in unserem Image verursachen.

Wir können dieses Image erstellen und genauso testen wie zuvor:

```
$> docker build -t blog .

[+] Building 111.5s (11/11) FINISHED
.
.
.
=> [6/6] RUN bundle update && bundle install && 
  rails db:setup && rails db:migrate 108.8s
=> exporting to image                                           1.6s
=> => exporting layers                                          1.6s 
=> => writing image sha256:0b7c017032e301429...433c23a5         0.0s                                  
=> => naming to docker.io/library/blog                          0.0s                 

$> docker scan blog -f Dockerfile

Testing blog...
.
.
.
X High severity vulnerability found in bzip2
  Description: Out-of-bounds Write
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-BZIP2-450801
  Introduced through: bzip2@1.0.6-8.1, bzip2/libbz2-dev@1.0.6-8.l, imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-11+deb9u6,meta-common-packages@meta
  From: bzip2@1.0.6-8.1
  From: bzip2/libbz2-dev@1.0.6-8.1
  From: imagemagick/libmagickcore-dev@8:6.9.7.4+dfsg-ll+deb9u6>imagemagick/libmagickcore-6.q16-dev@8:6.9.7.4+dfsg-1l+deb9u6 › bzip2/libbz2-devel.0.6-8.1
  and 1 more..
  Introduced by your base image (ruby:2.5.1)

X High severity vulnerability found in apt/libapt-pkg5.0
  Description: Arbitrary Code Injection
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-APT-407402
  Introduced through: apt/libapt-pkg5.0@1.4.8, apt@l.4.8
  From: apt/libapt-pkg5.001.4.8
  From: apt@l.4.8 > apt/libapt-pkg5.001.4.8
  From: apt@l.4.8
  Introduced by your base image (ruby:2.5.1)
  Fixed in: 1.4.9

Organization:      snyk-pmm
Package manager:   deb
Target file:       Dockerfile
Project name:      docker-image|blog
Docker image:      blog
Base image:        ruby:2.5.1
Licenses:          enabled

Tested 413 dependencies for known issues, found 871 issues.

Base Image     Vulnerabilities   Severity
ruby:2.5.1     867               48 high, 237 medium, 582 low

Recommendations for base image upgrade:

Minor upgrades
Base Image     Vulnerabilities   Severity
ruby:2.5       257               6 high, 34 medium, 217 low

Alternative image types
Base Image                       Vulnerabilities   Severity
ruby:2.5-slim                    53                0 high, 5 medium, 48 low
ruby:2.7.0-slim-buster           61                1 high, 8 medium, 52 low
ruby:2.7.0-preview3-slim-buster  63                1 high, 9 medium, 53 low
ruby:2.7.0-preview2-slim         63                1 high, 9 medium, 53 low

Offenbar hat die Person, die diese Dockerfile erstellt hat, unseren Rat aus dem vorherigen Abschnitt nicht befolgt: 871 Sicherheitslücken, und bereits unser Basis-Image weist 867 auf! Wir müssen diese Person ausfindig machen und ihr ein Exemplar dieses Leitfadens geben. Zunächst wollen wir jedoch herausfinden, ob einer unserer eigenen Dockerfile-Befehle Sicherheitslücken hinzugefügt hat. Aus der Differenz zwischen der Gesamtzahl der Probleme und den Problemen im Basis-Image geht hervor, dass wir mindestens vier Sicherheitslücken beheben müssen.

Mit dem Befehl docker scan können wir die Suche schnell eingrenzen, indem wir mithilfe der Option –exclude-base alle Sicherheitslücken des Basis-Images ignorieren. Hier sehen Sie einen weiteren Scan und einen Auszug aus der Ausgabe, bei dem die Sicherheitslücken des Basis-Images ausgeschlossen sind:

Für die Option —exclude-base muss die Dockerfile in den Scan einbezogen werden (mit der bisher verwendeten Option -f Dockerfile).

X High severity vulnerability found in curl/libcurl3
  Description: Buffer Overflow
  Info: https://snyk.io/vuln/SNYK-DEBIAN9-CURL-466505
  Introduced through: curl@7.52.1-5+deb9u7, curl/libcurl4-openssl-dev@7.52.1-5+deb9u7, gitel:2.11.0-3+deb9u7
  From: curl@7.52.1-5+deb9u7 > curl/libcurl3@7.52.1-5+deb9u7
  From: curl/libcurl4-openssl-dev@7.52.1-5+deb9u7 › curl/libcurl3@7.52.1-5+deb9u7
  From: curl@7.52.1-5+deb9u7
  and 2 more..
  Introduced in your Dockerfile by `RUN apt-get update && apt-get install -y git vim && rm -rf/var/lib/apt/lists/*`
  Fixed in: 7.52.1-5+deb9u10

Organization:     snyk-pmm
Package manager:  deb
Target file:      Dockerfile
Project name:     docker-image|blog
Docker image:     blog
Base image:       ruby:2.5.1
Licenses:         enabled

Tested 413 dependencies for known issues, found 70 issues.

Das ist schon überschaubarer: 70 statt 871 Probleme. Wenn Sie die Liste der erkannten Sicherheitslücken durchgehen, sehen Sie außerdem eine Zeile, die mit „Introduced in your Dockerfile by“ beginnt. Zusätzlich wird der Abhängigkeitspfad angezeigt, über den sich eine bestimmte Sicherheitslücke bis zu ihrer Quelle zurückverfolgen lässt. Der konkrete Dockerfile-Befehl – statt einer kryptischen Interpretation des Befehls – führt uns jedoch direkt zum Ursprung.

Trotzdem sind 70 Sicherheitslücken auf einmal ziemlich viele.

Sicherheits- und Entwicklungsteams möchten sich häufig zuerst auf alle behebbaren Sicherheitslücken mit hohem Schweregrad konzentrieren.

Auch diese Details lassen sich ganz einfach anzeigen, indem Sie die JSON-Ausgabeoption nutzen und die Ausgabe mit dem JSON-Befehlszeilenprogramm jq filtern (beachten Sie, dass jq Zeilenumbrüche innerhalb des Befehls problemlos verarbeitet):

```
$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

$> docker scan blog -f Dockerfile --exclude-base --json | \
    jq '[.vulnerabilities[] 
      | select(.nearestFixedInVersion) 
      | select(.severity == "high") 
      | { packageName, 
          dockerfileInstruction, 
          title, 
          severity, 
          version, 
          nearestFixedInVersion}]'

[
  {
    "packageName": "curl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "7.52.1-5+deb9u7",
    "nearestFixedInVersion": "7.52.1-5+deb9u13"
  },
...  
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Integer Overflow or Wraparound",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Buffer Overflow",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  },
  {
    "packageName": "perl",
    "dockerfileInstruction": "apt-get install -y git vim",
    "title": "Out-of-bounds Write",
    "severity": "high",
    "version": "5.24.1-3+deb9u4",
    "nearestFixedInVersion": "5.24.1-3+deb9u7"
  }
]
```

Geschafft! In unserer abschließenden Ansicht werden 36 Sicherheitslücken aufgeführt. Alle haben einen hohen Schweregrad, und für alle ist eine Behebung verfügbar. Außerdem werden der Dockerfile-Befehl und die Version mit der Korrektur angezeigt. Damit sollten wir diese Sicherheitslücken beheben können. Wenn Sie den Befehl jq nicht kennen, wirkt das vielleicht kompliziert. Hier finden Sie eine kurze Übersicht über unsere Schritte. jq ist jedoch sehr leistungsstark und es lohnt sich, etwas Zeit in die Einarbeitung zu investieren:

Zunächst haben wir unserem docker-scan-Befehl die Ausgabeoption --json hinzugefügt. Anschließend haben wir mit jq Folgendes gemacht:

• Nur die Sicherheitslücken aus der Ausgabe ausgewählt

• Nur die Sicherheitslücken ausgewählt, für die eine Korrektur verfügbar ist, sowie diejenigen mit dem Schweregrad „high“

• Die Ausgabe übersichtlicher gestaltet, indem wir nur einige wenige Felder zu den Sicherheitslücken angezeigt haben

Fazit

Containersicherheit ist ein weitreichendes Thema. Selbst wenn man sich auf die Sicherheit von Images beschränkt, gibt es zahlreiche Sicherheitsvektoren zu berücksichtigen. Wenn es darum geht, Ihre Images abzusichern, sollten Sie sich jedoch vor allem Folgendes vor Augen halten:

• Beginnen Sie mit Basis-Images eines Anbieters, dem Sie vertrauen. Verifizieren Sie die Authentizität mithilfe digitaler Signaturen.

• Entscheiden Sie sich nach Möglichkeit für minimale Basis-Images, die nur grundlegende Betriebssystempakete und die Framework-Version Ihrer Wahl enthalten, und bauen Sie darauf auf.

• Prüfen Sie Ihre Images frühzeitig und regelmäßig auf Sicherheitslücken. Erstellen Sie eigene, genehmigte Basis-Images, die aktiv gepflegt werden und alle Ihre Sicherheitsprüfungen bestehen. Scannen Sie erneut, sobald neue Images erstellt werden.

• Scannen Sie an mehreren Stellen im Software-Lebenszyklus: auf dem Desktop, in CI, gespeicherte Images in Registries sowie Container und Pods, die in Ihren Clustern ausgeführt werden.

• Wenn Sie Tools für Ihre Scans auswählen, sollten Sie mehr als nur die bereitgestellte Liste mit Sicherheitslücken berücksichtigen:

  • Meldet das Tool nicht nur Sicherheitslücken, sondern weist es Sie auch darauf hin, wenn ein neueres oder besseres Basis-Image verfügbar ist?

  • Wenn ein Build aufgrund erkannter Sicherheitslücken fehlschlägt, erhalten Entwickler:innen und DevOps-Teams vom Tool genügend Informationen, um die Probleme zu beheben?

  • Bietet das Tool die Flexibilität, die Sie benötigen, um Ihre Sicherheits-Gates festzulegen?

  • Eine Lösung passt nicht immer für alle: Ihre Entwickler:innen benötigen in einem Image wahrscheinlich mehr Tools, als Sie in der Produktion zulassen würden. Daher verwenden Sie möglicherweise in jeder Phase des Entwicklungslebenszyklus andere Images. Automatisierung, CI und Dockerfiles, die diese Phasen unterstützen, ermöglichen geeignete Sicherheits-Gates und die richtige Balance zwischen Sicherheit und Produktivität – und bieten so den größten Nutzen.

Um mit Docker und Snyk Ihre Container-Images abzusichern, melden Sie sich jetzt an!