Container-Sicherheit mit der Sicherheitsexpertise von Snyk vereinfachen

Das Schönste und Inspirierendste an Open-Source-Code ist – nun ja –, dass er Open Source ist. Open-Source-Pakete lassen sich als Geschenke betrachten, die Entwicklerinnen und Entwickler in der gesamten Engineering-Welt austauschen. So können sie von der Arbeit anderer lernen, ihr eigenes Fachwissen einbringen und ihre beruflichen Fähigkeiten ausbauen. Beiträge zu Open Source sind sehr willkommen. Dabei sollten wir nicht nur von diesen Projekten profitieren, sondern auch etwas zurückgeben. Durch diese Zusammenarbeit entwickelt sich Open Source ständig weiter: Gemeinsames Wissen und Pakete bilden das Fundament für neue, spannende Technologien.

Doch diese frei nutzbaren Bibliotheken und Projekte bergen auch Risiken – ob unbeabsichtigt oder durch böswillige Akteure. Genau hier kommt Snyk ins Spiel.

Mit der stetigen Weiterentwicklung von Open-Source-Technologien, etwa neuen und weiterentwickelten Linux-Distributionen und Container-Tools wie Docker, werden immer mehr gebündelte Images dieser Open-Source-Pakete erstellt und verwendet. Ein Container-Image ist im Grunde eine Datei mit dem Code, den Bibliotheken, Abhängigkeiten und weiteren Tools und Dateien, die Anwendungen zum Ausführen benötigen. Ein Container, ist die laufende Instanz dieses Images. Er legt den „Raum“ fest, in dem die Anwendung ausgeführt und entwickelt wird. Ein Container ermöglicht es Ihnen, eine Umgebung zu erstellen, in der Ihr Code funktioniert. Er basiert auf dem Image und wird tatsächlich aus diesem gestartet. Besonders leistungsstark ist, dass Container-Images aufeinander aufbauen können. Sie können mit einem Image beginnen, das nur die grundlegenden Linux-Elemente enthält – zum Beispiel alpine von Docker. Darauf schichten Sie sprachspezifische Tools und Frameworks, um ein entsprechendes Image zu erstellen, anschließend Entwicklungs-Tools für diese Sprache und schließlich die spezifischen Bestandteile Ihres eigenen Codes.

Wenn ein Image also lediglich eine Datei mit einer Reihe von Paketen ist, fragen Sie sich vermutlich schon, welche Herausforderung es dabei gibt, die Sicherheitslücken darin zu ermitteln. Können wir nicht einfach davon ausgehen, dass ein Image anfällig ist, wenn ein Open-Source-Paket eine Sicherheitslücke enthält und in diesem Image verwendet wird? Eine hervorragende Frage – danke, dass Sie sie stellen! So wie ein Basis-Image wie alpine in unserem obigen Beispiel zahlreiche Tools und Möglichkeiten mit sich bringt, kann auch jedes Paket unbemerkt Sicherheitslücken hinzufügen. Plötzlich reicht es nicht mehr aus, Sicherheitslücken in Ihrem eigenen Code aufzudecken: Sie müssen auch sicherstellen, dass Ihr Basis-Image und alle Images, die Sie beim Hinzufügen Ihrer Tools erstellen, sicher sind.

In diesem Blog konzentrieren wir uns auf den allerersten Teil des Images – das übergeordnete Image, auf dem Sie aufbauen (alpine in unserem Beispiel). In dieser Ebene werden in der Regel die meisten grundlegenden Linux-Pakete eingeführt und der Linux-Paketmanager hinzugefügt. Sie sorgt auch oft für Verwirrung, denn anders als bei allem, was Sie möglicherweise noch hinzufügen, haben Sie bei diesem Basis-Image die geringste Kontrolle darüber, was Sie erhalten. Sehen wir uns also die Herausforderungen rund um Sicherheitslücken in Containern genauer an und erfahren wir anschließend, wie Snyk bei ihrer Lösung helfen kann.

Linux-Sicherheitslücken in der Containerwelt verstehen

Paketverwaltungssystem

Jede Linux-Distribution (Alpine, Debian, Ubuntu usw.) hat ihre eigenen Maintainer. Sie alle stellen zwar eine Linux-Version bereit, was eine gewisse Gemeinsamkeit voraussetzt, können jedoch eigene Benennungs- und Versionsschemata für Updates festlegen. Das bedeutet, dass Namen und Versionsnummern nicht immer mit denen des entsprechenden Upstream-Pakets übereinstimmen. Wenn Sie sich also mit den Details der Behebungen eines bestimmten Problems oder allgemeinen System-Patches befassen, können die Empfehlungen der Distributionen für ihre Nutzerinnen und Nutzer unterschiedlich ausfallen.

Betrachten wir als Beispiel die Behebung von CVE-2021-44228, auch bekannt als Log4Shell, im bekannten log4j-Paket. Das vom Apache-Team in Maven gepflegte Upstream-Paket heißt logging-log4j2. Die Behebung dieser kritischen Sicherheitslücke wurde in Version 2.15.0 veröffentlicht. Wenn Sie Debian verwenden, heißt das von Debian bereitgestellte Paket jedoch apache-log4j2 und die Behebung wurde im aktuellen stabilen Zweig Debian 11 („bullseye“) in Version 2.15.0-1~deb11u1 veröffentlicht. In Ubuntu lautet der Name wie bei Debian apache-log4j2, die behobene Version in der neuesten Ubuntu-Version (21.10) ist jedoch 2.15.0-0.21.10.1.

Hier eine Übersicht der behobenen Pakete für CVE-2021-44228:

Dieses relativ einfache Beispiel zeigt: Selbst wenn unsere engagierten Security-Analysten eine Sicherheitslücke in einem Upstream-Open-Source-Paket gefunden oder bewertet haben, können wir nicht ohne Weiteres davon ausgehen, welches Paket in den verschiedenen Linux-Distributionen darauf basiert, welche Versionsnummern betroffen sind oder ob eine bestimmte Distribution überhaupt betroffen ist. Für die Pakete, die in die verschiedenen Images übernommen werden, ist ein eigener Bewertungsprozess erforderlich.

Die unterschiedlichen Namens- und Versionsschemata erleichtern den Linux-Distributionsteams die Verwaltung ihrer eigenen Versionen und helfen ihnen, anhand ihres jeweiligen Formats zu erkennen, welche Upstream-Version sie verwenden. Außerdem können sie so ihre eigenen Pakete kontrollieren. Jede Distribution verwaltet und verantwortet sämtliche Aspekte des Builds und der Kompilierung eines Pakets, das in ihrem Ökosystem verwendet wird. Eigene Paketnamen und Versionen ermöglichen es ihr, Patch-Releases und Backports im System korrekt zu verwalten.

Am zutreffendsten ist es, jedes Paket als eigene Entität zu betrachten – je nachdem, von welcher Quelle es heruntergeladen werden kann. Wenn ein Paket im Paketmanager einer bestimmten Linux-Distribution bereitgestellt wird, müssen wir es als anderes Paket behandeln, selbst wenn es denselben Namen trägt wie ein Paket auf PyPI, Maven oder einer anderen Plattform. Es wird von einem anderen Team gepflegt und speziell auf dessen Umgebung und Anforderungen zugeschnitten kompiliert.

Terminologie und Struktur der Daten

Neben den unterschiedlichen Paketnamen und Versionen der einzelnen Linux-Distributionen unterscheiden sich auch die Begriffe, mit denen verschiedene Aspekte der von den jeweiligen Quellen bereitgestellten Sicherheitsdaten beschrieben werden.

So kann beispielsweise die Definition des Schweregrads „kritisch“ variieren. Ein Team verwendet „kritisch“ möglicherweise häufiger und großzügiger als ein anderes, das in der Regel den Schweregrad „hoch“ angibt und eine Sicherheitslücke nur in ganz bestimmten Fällen als „kritisch“ einstuft.

Andererseits können verschiedene Begriffe tatsächlich dasselbe bedeuten und gleich verwendet werden – etwa „moderat“ und „mittel“, die von verschiedenen Teams verwendet werden können, um denselben Schweregrad auszudrücken.

Wenn ein Team außerdem beispielsweise den Begriff „wichtig“ verwendet, muss geklärt werden, ob sich dies auf die Priorität der Behebung des Problems oder auf die Bedeutung der Sicherheitslücke selbst bezieht (d. h. auf ihren relativ hohen Schweregrad).

Um diese Komplexität zu verdeutlichen, betrachten wir CVE-2021-3507, die Debian betrifft:

Wie in der genannten Empfehlung zu sehen ist, wird diese CVE für Stretch (Debian 9), Buster (10) und Bullseye (11) als <no-dsa> (Minor issue) eingestuft. Diese Angaben spiegeln die Einschätzung der Debian-Maintainer zum Schweregrad des Problems in den jeweiligen Debian-Versionen wider.

NVD hingegen bewertete diese CVE mit einem CVSS-Score von „mittel“. Dieser gibt eine umfassendere Analyse der Sicherheitslücke wieder, die besonders für das Upstream-Paket qemu relevant ist.

Eine Vielzahl von Daten

Jede Linux-Distribution und jede ihrer Versionen enthält standardmäßig zahlreiche Pakete. Viele, viele weitere lassen sich aus dem Repository der jeweiligen Distribution herunterladen. Das bedeutet, dass unser Container Hunderte von Sicherheitslücken enthalten kann, die Pakete in verschiedenen Programmiersprachen betreffen. Die Vielzahl der Sicherheitslückendaten in der Containerumgebung macht es für Snyk, Security-Teams und Entwicklerinnen und Entwickler, die Container nutzen, schwieriger, die einzelnen Sicherheitslücken zu bewerten, zu verstehen und die passenden Maßnahmen zu bestimmen. Jede einzelne Sicherheitslücke eingehend zu untersuchen, ist daher eine große Herausforderung.

Diese besonderen Herausforderungen bei Sicherheitslücken in Containern erschweren es, die genauesten Daten innerhalb eines Containers zu ermitteln. Welche Sicherheitslücken betreffen einen bestimmten Container tatsächlich? Wie groß ist das tatsächliche Risiko im Zusammenhang damit, wie der Container mit dem Linux-Kernel und der darin ausgeführten Anwendung interagiert? Unser Container-Sicherheitslückenteam bei Snyk arbeitet kontinuierlich daran, diese Fragen möglichst präzise zu beantworten. Dafür haben wir ein komplexes Modell entwickelt, das zahlreiche Faktoren berücksichtigt, um Sicherheitslücken genau zu erkennen und zu priorisieren.

Wie lassen sich diese Herausforderungen bewältigen?

Nachdem wir die Komplexität beschrieben haben, können wir uns der Lösung zuwenden, mit der sich die genauesten Daten ermitteln lassen. Der Prozess zur Erfassung, Analyse und Meldung relevanter Sicherheitslücken in Containern beginnt mit einer skalierbaren Pipeline. Sie kann große Datenmengen aus zahlreichen Quellen intelligent automatisiert verarbeiten und bei Bedarf auch menschliches Eingreifen auslösen. Dafür sind fundierte Kenntnisse erforderlich, die auf Sicherheitsexpertise und der Zusammenarbeit mit den Security-Teams der verschiedenen Linux-Distributionen beruhen. Diese liefern den zusätzlichen Kontext, der uns fehlt. Aus dem so gewonnenen Wissen aus zahlreichen Quellen können wir die relevantesten und nützlichsten Informationen zusammenführen und auswählen. Schließlich priorisieren wir Sicherheitslücken in ihrem jeweiligen Kontext anhand all dieser Faktoren und weiterer verfügbarer externer Datenpunkte, um irrelevantes Rauschen zu reduzieren. Das bedeutet es für uns bei Snyk:

Wie analysiert Snyk Sicherheitslücken in Containern und Linux?

Das Hauptziel unseres Container-Security-Teams ist es, folgende Fragen zu beantworten: Welche Sicherheitslücken betreffen einen Container, mit welcher Priorität sollten sie behoben werden und was kann ich dagegen tun?

Hier erhalten Sie einen Einblick, wie wir diese Frage möglichst präzise, umfassend und zeitnah beantworten:

Zeitnahe Datenerfassung

Wir erfassen Sicherheitsdaten unabhängig aus den Quellen der verschiedenen Linux-Distributionen. Dazu verfolgen wir neue Releases und Sicherheitshinweise, sowohl für einzelne Pakete als auch für vollständig neue Distributionsversionen, sobald sie aktualisiert werden. So können wir unsere Sicherheitslückendaten unmittelbar um neue Informationen aus den Quellen der Linux-Distributionen ergänzen. Ein Beispiel für solche Aktualisierungen finden Sie direkt in den Ergebnissen von Snyk Container: die relative Bedeutung der Sicherheitslücke. Sie gibt ihren Schweregrad im Kontext des jeweiligen Images an. Im Beispiel unten beträgt der ursprüngliche CVSS-Score 8,8, was als hoher Schweregrad gilt. Die Debian-Maintainer haben die Sicherheitslücke jedoch in Debian 10 (der in diesem Container verwendeten Version) analysiert und als „geringfügiges Problem“ eingestuft. Daher bewertet Snyk den Gesamtschweregrad als „niedrig“. Diese Information ist für die korrekte Priorisierung und Bewertung der Sicherheitslücke sehr wichtig, denn sie hilft dabei, festzulegen, welche der zahlreichen Probleme zuerst behoben werden sollten.

Zusammenarbeit und fundiertes Verständnis der Ökosysteme von Linux-Distributionen

Um die Sicherheitsdaten der einzelnen Linux-Distributionen zu verstehen, untersuchen wir sie, analysieren ihre Komponenten und überprüfen ihre Vollständigkeit. Außerdem identifizieren wir Sonderfälle und zusätzliche Daten, die die jeweilige Distribution bereitstellt und die wir möglicherweise für die Triage nutzen können. Als wir beispielsweise daran arbeiteten, unsere Sicherheitsinformationen zu Red Hat zu verbessern, stellten wir fest, dass die öffentlichen Seiten zu Sicherheitslücken mehr Informationen zu Schwachstellen enthielten als die OVAL-Datenströme. Dort war etwa angegeben, ob eine Schwachstelle under investigation oder not affecting auf ein bestimmtes Red-Hat-Produkt. Wir machten das Sicherheitsteam von Red Hat darauf aufmerksam. Seitdem sind diese wichtigen Informationen in den OVAL-Datenströmen enthalten, der offiziellen Quelle für Sicherheitsdaten, die wir verwenden.

Sicherheitsexpertise von Menschen

In unserem weitgehend automatisierten Prozess, der auf den oben beschriebenen Untersuchungen basiert, holen wir in bestimmten Situationen eine Entscheidung von Sicherheitsexpertinnen und -experten ein. Zum Beispiel, wenn eine Empfehlung von der Distribution zurückgezogen wird und wir sie vor dem Widerruf überprüfen möchten. Unser ausgefeilter Widerrufsprozess ist äußerst wichtig, damit unsere automatisierten Systeme keine relevanten Schwachstellen entfernen. Gleichzeitig vermeiden wir so False Positives und erleichtern Entwicklerinnen und Entwicklern die Arbeit.

Zusätzliche Anreicherungen und Quellen

Wir reichern unsere Schwachstellendaten mit Informationen aus externen Quellen an, die wir kontinuierlich ergänzen. Dazu gehören Daten aus der NVD, Informationen zu Exploits, Twitter-Trends und – wie kürzlich angekündigt – Runtime-Signale von Sysdig.

Kontextbezogene Priorisierung

Auf Grundlage all dieser Informationen priorisieren wir Schwachstellen mithilfe unseres einzigartigen Prioritätswerts, kennzeichnen ihren Schweregrad, ergänzen sie um weitere Daten für mehr Kontext und stellen sie so dar, dass sie sich möglichst einfach triagieren und verstehen lassen.

Ein Blick in die Zukunft der Schwachstellenforschung für Snyk Container

Für den künftigen Umgang mit Container-Schwachstellen haben wir einiges vor.

Ein Beispiel dafür sind die Snyk Security Insights. Damit möchten wir unnötiges Rauschen in einer ohnehin schon unübersichtlichen Umgebung so weit wie möglich reduzieren. Sicherheitsinformationen zu bestimmten Situationen und Bedingungen helfen dabei, besser zu erkennen, ob eine Schwachstelle in einer bestimmten Konfiguration, Umgebung oder Anwendung relevant ist. Außerdem unterstützen sie uns dabei, gemeinsam mit Entwicklerinnen und Entwicklern Schwachstellen zu triagieren.

Ein Beispiel für eine Snyk Container Vulnerability Insight, an der wir arbeiten, ist der Vorschlag, eine Schwachstelle zu ignorieren, wenn sie in einem Build-Time-Paket auftritt. Oder noch besser: das betroffene Build-Time-Paket vollständig zu löschen – dadurch werden automatisch auch die übrigen Schwachstellen in diesem Paket beseitigt. Grundlage dafür sind erste Untersuchungen, die darauf hindeuten, dass eine Schwachstelle während der Build-Zeit nur schwer ausgenutzt werden kann und Schwachstellen in Runtime-Anwendungen deutlich stärker priorisiert werden sollten. Das Gegenteil der Sysdig-Integration: Sysdig zeigt Ihnen, was in der Produktion ausgeführt wird, und erhöht damit die Priorität, eine Schwachstelle zu beheben. Die Build-Time-Insights von Snyk könnten dagegen die Priorität einer Behebung herabsetzen oder das automatische Ignorieren erleichtern, wenn eine Schwachstelle Build-Tools betrifft, die nicht in der Produktion ausgeführt werden.

Außerdem arbeiten wir daran, Container-Schwachstellen um zusätzliche Metadaten zu ergänzen, die relevantere Informationen für eine effizientere Priorisierung und Analyse liefern. Dazu gehören beispielsweise Angaben zum fix state der Schwachstelle (Wird sie überhaupt jemals behoben? Ist ein Fix bereits zusammengeführt und wartet auf die Veröffentlichung?) sowie Sicherheitshinweise, die mehr Kontext zum Schweregrad oder anderen Status der Schwachstelle liefern. Natürlich prüfen wir auch laufend, wie wir die Unterstützung für weitere Distributionen ausbauen können, die wir bislang noch nicht unterstützen.

Schwachstellen in Ihren Containern zu verwalten, ist kompliziert – aber Sie müssen das nicht allein tun. Die branchenführende Expertise von Snyk wird kontinuierlich verbessert und weiterentwickelt. Sie müssen also kein Experte sein, um Ihre Anwendungen zu schützen – Sie brauchen lediglich ein kostenloses Snyk-Konto.