Snyks Ansatz für Container-Sicherheitsforschung und relative Bedeutung
14. Dezember 2020
0 Min. LesezeitContainer-Schwachstellen sind nicht einfach zu handhaben. Dafür müssen Sie sowohl die Linux-Sicherheit als auch die Architektur von Container-Images verstehen. Abgesehen von Schwachstellen in Ihrem Code betreffen die meisten Schwachstellen in Containern Linux-Betriebssystempakete und deren Abhängigkeiten. Container werden jedoch in der Regel von Entwicklern verwaltet, die meist keine Experten für die Wartung von Betriebssystemen sind. Außerdem werden diese Pakete nicht so gepatcht wie ein vollständiges Betriebssystem auf Servern. Wir freuen uns, ein neues Feature anzukündigen, das mehr Klarheit bei der Priorisierung und Behebung von Container-Schwachstellen schafft: relative Bedeutung.
Relative Bedeutung und Datenvollständigkeit in der Container-Sicherheit
Relative Bedeutung ist eine Methode, mit der unser Sicherheitsteam den Schweregrad von Schwachstellen in Containerpaketen bewertet. Wenn Sie Container-Images auf Debian- oder Ubuntu-Basis mit Snyk Container gescannt haben, können Sie diese Angaben bereits heute sehen. In Kürze ergänzen wir Daten für weitere Distributionen. Kurz gesagt: Bei der relativen Bedeutung berücksichtigen wir die Einschätzungen der Maintainer und Sicherheitsforscher der jeweiligen Distribution und beziehen sie in die Bewertung von Schwachstellen durch Snyk Container ein. Das ist wichtig, denn Linux-Pakete erhalten zwar in der Regel eine Schwachstellenbewertung von NVD, doch da jede Distribution ihre Releases etwas anders erstellt und wartet, können die Maintainer ein Paket anders bewerten. Das nennen wir relative Bedeutung.
Im folgenden Beispiel sehen Sie eine Container-Schwachstelle, die von NVD ursprünglich als SCHWERWIEGEND eingestuft wurde. Der betreffende Container verwendet jedoch Debian-Pakete. Da Debian das Paket _bash_shell in seiner Distribution auf besondere Weise handhabt, stufen die Debian-Maintainer die Schwachstelle als UNWICHTIG ein. In den Snyk-Bewertungen entspricht das einem niedrigen Schweregrad. Dies wird sowohl in unserer Schweregradbewertung (oben links) als auch im rechts angezeigten Prioritätswert (321) berücksichtigt.

Sie müssen nichts tun, um das neue Feature zu aktivieren. Es ist ab sofort sowohl in der Snyk-Benutzeroberfläche als auch in der CLI verfügbar. Snyk Container verwendet automatisch die jeweils passendste Bewertung für die Schwachstelle. Unten sehen Sie eine gekürzte Version der CLI-JSON-Ausgabe mit den Angaben severity, nvdSeverity und relativeImportance.
Wenn Sie wissen möchten, wie diese Felder funktionieren:
relativeImportance– Dies ist die Schweregradbewertung der Maintainer der Distribution, sofern sie die Schwachstelle geprüft und bewertet haben. Snyk hält die Angaben der Distributionen für am genauesten. Daher wird Ihnen dieser Schweregrad angezeigt, wenn er verfügbar ist. Die Distributionen unterscheiden sich jedoch darin, wie viele und welche Arten von Schwachstellen sie prüfen. Sind diese Daten nicht verfügbar, verwenden wir nvdSeverity.nvdSeverity– Dies ist der ursprüngliche, von NVD festgelegte Schweregrad der Schwachstelle. Wenn eine Distribution die Schwachstelle geprüft hat, ist dies das am wenigsten genaue Feld. Es ist im Allgemeinen nur für Unternehmen mit sehr strengen SLAs relevant, die sich ausdrücklich auf NVD stützen, oder für Unternehmen, bei denen CVSS-Score und Schweregrad übereinstimmen müssen. Wir zeigen diese Daten im Schwachstellenbericht an, damit Sie den Kontext unserer angezeigten Schweregradbewertung kennen. Gibt es keine distributionsspezifische Bewertung, wird Ihnen dieser Schweregrad angezeigt.severity– Dies ist der Schweregrad, den Snyk tatsächlich anzeigt. Wurde die Schwachstelle von der Distribution geprüft und liegt eine Bewertung für relativeImportance vor, verwenden wir diese. severity entspricht dann relativeImportance. Hat die Distribution die Schwachstelle nicht geprüft, verwendet Snyk nvdSeverity. So entgehen Ihnen keine schwerwiegenden oder kritischen Probleme, nur weil die Distribution keine eigenen Daten veröffentlicht hat.
Im Allgemeinen empfehlen wir, das Standardfeld severity zu verwenden, wenn Sie unsere APIs oder die JSON-Ausgabe nutzen. Wir leisten die nötige Arbeit, um Ihnen den genauesten Schweregrad für Ihr Container-Image zu liefern. Die zusätzlichen Felder bieten Ihnen mehr Kontext, damit Sie nachvollziehen können, warum sich ein bestimmter Schweregrad und Score unterscheiden. Wir wissen jedoch, dass andere Kunden diese Felder aufgrund ihrer individuellen Anforderungen anders nutzen.
Ein genauerer Blick auf Snyks Rechercheprozess zu Container-Schwachstellen
Die neuen Daten zu relativeImportance sind ein Beispiel für die aufwendige Arbeit des Snyk-Sicherheitsforschungsteams, die Ihnen erspart bleibt. Bei der Schwachstellenforschung und der Bereitstellung nützlicher Sicherheitsinformationen für unsere Kunden messen wir uns an vier Faktoren:
Vollständigkeit: Wir beschränken uns nicht auf eine einzige Quelle für Schwachstellendaten, sondern führen Informationen aus mehreren Quellen zusammen und ergänzen sie durch eigene Primärforschung.
Aktualität: Wir tragen alle relevanten Daten schnell zusammen und stellen sie unseren Endnutzern zur Verfügung.
Genauigkeit: Wenige falsch-positive und falsch-negative Ergebnisse sind entscheidend, damit Sie keine Zeit verschwenden und wichtige Risikofaktoren nicht übersehen.
Umsetzbarkeit: Snyk wird von Sicherheitsteams und Entwicklern eingesetzt. In der Regel sind jedoch letztlich die Entwickler dafür verantwortlich, die von uns gefundenen Probleme zu beheben. Das berücksichtigen wir stets bei der Darstellung unserer Ergebnisse.
Der Umgang mit Container-Schwachstellen erfordert ein umfassendes Verständnis der Linux- und Containerwelt, das Herausfiltern relevanter Informationen für Endnutzer – meist Entwickler – und deren Nutzbarmachung für die Erstellung und Wartung von Containern. Bei Snyk übernimmt unser Sicherheitsforschungsteam diese aufwendige Arbeit für Sie. Registrieren Sie sich kostenlos bei Snyk und schützen Sie Ihre Container!
Container-Sicherheit mit Fokus auf Entwickler
Snyk findet und behebt automatisch Schwachstellen in Container-Images und Kubernetes-Workloads.