Tipps für eine robustere Container-Image-Sicherheitsstrategie

Im ersten Teil dieser Blogserie haben wir uns Best Practices für die Sicherheit der Basis-Images angesehen, die Sie möglicherweise verwenden. Doch was passiert mit der Sicherheit von Container-Images, wenn weitere Komponenten hinzukommen? Vielleicht installieren wir zusätzliche Software aus vorgelagerten Quellen und haben eigene Anwendungen mit Abhängigkeiten, die ebenfalls installiert werden. Diese Komponenten haben wir hinzugefügt und können sie kontrollieren. Deshalb müssen wir auch die Verantwortung dafür übernehmen, die von uns eingeführten Sicherheitslücken zu beheben.

Eine Baseline erstellen

Beim Erstellen Ihrer Container-Images empfiehlt es sich, zunächst nur das Basis-Image zu scannen, bevor Sie Änderungen daran vornehmen. So legen Sie eine Baseline für die Sicherheit Ihrer Container-Images fest und sehen leicht, welche Sicherheitslücken bereits im Basis-Image vorhanden waren und welche Sie in späteren Layern hinzugefügt haben. Wenn Sie Images mit mehreren zusätzlichen Layern erstellen – etwa einem benutzerdefinierten Middleware-Layer und Ihrer Anwendung –, ist es außerdem sinnvoll, an jedem dieser Punkte eine Baseline zu erstellen und die Images getrennt aufzubewahren. So erkennen Sie klar, woher die Sicherheitslücken stammen.

Prioritäten setzen

Es ist wahrscheinlich unrealistisch, vollständige Sicherheit bei Container-Images zu erwarten – also gar keine Sicherheitslücken –, außer bei sehr einfachen Anwendungen. Da uns keine unbegrenzten Ressourcen zur Verfügung stehen, um alles zu beheben, müssen wir Prioritäten setzen und entscheiden, welche Sicherheitslücken wir beheben und welche wir möglicherweise in Kauf nehmen.

Diese Entscheidungen können jedoch sehr schwierig sein, wenn Sie es mit Images zu tun haben, für die Ihr Scanner eine große Zahl von Sicherheitslücken meldet. Bei Sicherheitsscans besteht die Gefahr, dass die Menge der bereitgestellten Informationen die Nutzerinnen und Nutzer überfordert. Das kann dazu führen, dass Scans ignoriert oder ganz deaktiviert werden.

Sicherheitslücken sind zudem keine Alles-oder-nichts-Angelegenheit. Eine bestimmte Sicherheitslücke kann nur unter sehr speziellen Umständen oder auf einer bestimmten Architektur oder Plattform relevant sein. Wie können wir entscheiden, ob eine Sicherheitslücke in unserer Umgebung tatsächlich ein Problem darstellt, ohne uns die Details jeder einzelnen anzusehen?

Die Priorisierung ist keine exakte Wissenschaft und kann auf verschiedenen Faktoren beruhen. Der Schweregrad allein sagt uns abgesehen von den möglichen Auswirkungen nicht viel. Der CVSS-Score berücksichtigt Faktoren wie Ausnutzbarkeit und Auswirkungen und liefert mehr Kontext. Wir können außerdem Informationen zum Reifegrad verfügbarer Exploit-Codes heranziehen und vor allem dazu, ob eine Korrektur verfügbar ist. Sicherheitslücken mit hohem Schweregrad, für die ein Exploit und eine Korrektur verfügbar sind, sollten vermutlich zuerst behoben werden. Die Priorisierungsbewertungen von Snyk berücksichtigen all diese Faktoren bei der Darstellung von Sicherheitslücken, damit Entwicklerinnen und Entwickler eine klare Informationsgrundlage für ihre Entscheidungen haben.

Eine Strategie für die Sicherheit von Container-Images festlegen

Bei Sicherheit geht es fast immer um Abwägungen, insbesondere zwischen Aufwand und Risiko. Wie viel Aufwand ist nötig, um etwas zu beheben, und wie hoch ist das Risiko, dass es in meiner konkreten Umgebung zum Problem wird? Wenn Sie überlegen, wie Sie Sicherheitslücken priorisiert beheben, sollten Sie zunächst eine Strategie festlegen. Ein sehr einfaches Beispiel könnte so aussehen:

• Keine CVEs mit hohem Schweregrad in der Produktion

• Nichts mit einem ausgereiften Exploit

• Patches anwenden, sofern verfügbar

Wenn Sie sich daran halten, dürfte sich die Gesamtzahl der Sicherheitslücken in den meisten Fällen deutlich verringern.

Risikominderung: Jede Umgebung ist anders

Bewertungen geben zwar Aufschluss über den Schweregrad, doch einige Aspekte sind naturgemäß subjektiv. Sie könnten beispielsweise entscheiden, dass eine Sicherheitslücke mit hohem Schweregrad, für deren Ausnutzung lokaler Shell-Zugriff erforderlich ist, in Ihrer Umgebung ein geringeres Risiko darstellt, weil Sie über andere Kontrollen verfügen, die diesen Zugriff verhindern. Vielleicht verwenden Sie Distroless-Container, die keine Shell enthalten. Diese Kontrollen würden das Risiko mindern.

Ihre Sicherheitsgrenzen kennen

In manchen Umgebungen könnten Sie davon ausgehen, dass das Netzwerk vertrauenswürdig ist und Sicherheitslücken, die innerhalb dieses Netzwerks erreichbar sind, daher weniger problematisch sind. In den meisten modernen Computing-Umgebungen ist das jedoch problematisch, denn die Vernetzung ist so komplex, dass sich Grenzen nur schwer ziehen lassen – außer in vollständig isolierten Umgebungen. In Cloud-Umgebungen ist das besonders problematisch. Außerdem schützt Sie dieser Ansatz nicht vor internen Angreifern, die insbesondere in größeren Unternehmen ein erhebliches Risiko darstellen können. Sicherer ist es in der Regel, alle Ihre Netzwerke als nicht vertrauenswürdig einzustufen.

Ihre Tools kennen

Hier kommt es darauf an, die Tools zu verstehen, mit denen wir solche Probleme erkennen. Bei den meisten Image-Scanning-Tools lässt sich die Ausgabe filtern, sodass Sie festlegen können, welche Informationen für Sie besonders relevant sind. Das ist besonders wichtig, wenn Sie Sicherheitsscans in Ihre Software-Delivery-Pipelines integrieren. Sie möchten sicher nicht, dass Builds oder Deployments wiederholt fehlschlagen, weil Informationen nicht relevant sind oder Sie das Risiko auf andere Weise mindern. Snyk stellt das Flag --fail-on flag bereit, mit dem sich der Status der CLI-Scan-Ausgabe steuern lässt. So meldet die CLI nur unter bestimmten Bedingungen einen Fehler. Zum Beispiel:

1snyk container test purpledobie/mattj-goof --fail-on upgradable

Der Prozess wird nur dann mit einem Fehler beendet, wenn mindestens eine aktualisierbare Sicherheitslücke im Image gefunden wird – nicht jedoch, wenn Sicherheitslücken entdeckt werden, die nicht behoben oder gepatcht werden können.

Die Snyk CLI kann Ergebnisse außerdem im JSON-Format ausgeben, um sie nachträglich zu filtern. Auf Basis der JSON-Ausgabe lassen sich mit Tools wie jq komplexe Filter erstellen:

1snyk container test purpledobie/mattj-goof --json | jq '.vulnerabilities[] | select(.CVSSv3 | test("AV:N"))'

Dieses sehr einfache Beispiel gibt nur Sicherheitslücken zurück, die über das Netzwerk ausnutzbar sind. Dazu wird die Liste der Sicherheitslücken gefiltert, sodass nur Einträge berücksichtigt werden, deren Angriffsvektor im CVSS-Score auf „Network“ gesetzt ist. Mit solchen Filtern können Sie komplexe, richtlinienbasierte Entscheidungsprozesse in Ihre Scans integrieren.

Behebung automatisieren

Wenn Sie Ihre Strategie festgelegt und Ihre Tools konfiguriert haben, können Sie die Behebung automatisieren. Das verringert die kognitive Belastung für Entwicklerinnen und Entwickler, da sie weniger Entscheidungen treffen müssen, und reduziert zugleich den erforderlichen Aufwand. Automatische Pull Requests für Probleme, die klar unter die Gesamtstrategie fallen und für die Korrekturen verfügbar sind, erleichtern Entwicklungsteams die kontinuierliche Behebung. So können manuelle Ressourcen für komplexere Sonderfälle eingesetzt werden.

Sicherheit von Container-Images umfassend gewährleisten

Beim Container-Scanning werden möglicherweise keine Binärdateien erfasst, die nicht zu den während des Build-Prozesses hinzugefügten Paketen gehören. Deshalb sollte das Scannen von Container-Images nicht Ihre einzige Schutzmaßnahme sein. Darum ist es wichtig, auch Ihre Codebasis und Dockerfiles zu scannen. Für Workloads in der Produktion sollten Sie mit hoher Wahrscheinlichkeit auf das Prinzip der mehrschichtigen Sicherheit setzen und weitere Sicherheitsprüfungen einbeziehen, etwa die Erkennung von Anomalien zur Laufzeit und Endpoint-Scans.

Halten Sie Ihre Container sicher

Bei der Sicherheit von Container-Images gibt es einiges zu beachten. Wir hoffen jedoch, dass dieser Beitrag Ihnen einige Ansatzpunkte aufgezeigt hat. Richten Sie ein kostenloses Snyk-Konto ein und führen Sie einen Scan durch, um zu sehen, wie sicher Ihre aktuellen Container-Images sind.