Skip to main content

Developer-first-Container-Sicherheit definieren

Artikel von
Container security

16. März 2021

0 Min. Lesezeit

Haben Sie bereits „nach links verschoben“? Das ist der große Trend, oder? Damit soll eine Verlagerung der Sicherheitsverantwortung von zentralen IT-Teams hin zu Entwicklern signalisiert werden. Doch das ist schwieriger, als es klingt. Tools, die für Sicherheitsexperten gedacht sind, einfach früher in der Supply Chain einzusetzen, liefert Entwicklern noch keine aussagekräftigen Informationen. Genau darum geht es: Organisationen dabei zu unterstützen, die Verantwortung zu verlagern. Dafür setzen wir uns bei Snyk ein. Und deshalb freuen wir uns über die heutige Ankündigung, dass wir Fix-PRs für Container automatisieren können – im Anschluss an unsere jüngste Ankündigung, Dockerfiles zum First-Class-Bestandteil Ihrer Git-Repositories zu machen.

Dashboard zum Vergleich aktueller und alternativer Basis-Images nach Anzahl und Schweregrad der Schwachstellen, mit Schaltflächen zum Erstellen eines Fix-Pull-Requests.

Entwicklern dabei zu helfen, bessere und sicherere Container zu erstellen, ist seit der Veröffentlichung von Snyk Container im Jahr 2019 unser Leitmotiv. Wir sind stolz darauf, dass Snyk-Kunden und -Nutzer bislang 5,8 Millionen Sicherheitslücken in ihren Containern beseitigt haben. Seit wir die neuen Funktionen für Dockerfiles und Fix-Pull-Requests eingeführt haben, nimmt das Tempo weiter zu.

Warum Runtime-Container-Sicherheit von Entwicklern nicht genutzt wird

In Gesprächen mit Kunden und Snyk-Container-Nutzern zu diesem Thema haben wir festgestellt, dass die meisten gute Vorstellungen davon haben, was sie beim Erstellen sicherer Container „tun sollten“: Sicherheitsteams verfügen über entsprechende Richtlinien, und im Internet finden Entwickler zahlreiche Listen mit den „10 wichtigsten Best Practices für Container“, die äußerst beliebt sind. (Unsere eigene Liste der 10 wichtigsten Container-Best-Practices zählt zu unseren beliebtesten Blogbeiträgen aller Zeiten!) Doch wenn es darum geht, diese Richtlinien umzusetzen, geben laut dem Bericht „Best Practices for Container Security“ von Forrester nur 45 % der weltweiten Sicherheitsverantwortlichen an, über genügend Tools zur Unterstützung dieser Richtlinien zu verfügen. Es überrascht also vielleicht nicht, dass Unternehmen Best Practices wie die Verwendung schlanker Images nicht durchsetzen.

Ringdiagramm mit 45 %: ein rot-violetter Abschnitt und der Rest in Weiß

Das zeigt ein Problem mit der Idee, bestehende Tools einfach „nach links zu verschieben“. Docker steht kurz vor dem 8. Geburtstag, und Tools für die Container-Runtime-Sicherheit gibt es seit etwa fünf dieser Jahre. Dennoch sind die vier häufigsten Gründe für die mangelnde Durchsetzung mit vorhandenen Sicherheitstools laut einer ESG-Studie:

  • Entwickler nutzen die Tools, in die wir investiert haben, nicht effektiv

  • Entwicklern fehlt das Wissen, um erkannte Probleme zu beheben

  • Erzeugt Reibungsverluste und verlangsamt unsere Entwicklungszyklen

  • Schwierige oder fehlende Integration zwischen den Tools verschiedener Anbieter für Anwendungssicherheit

Das ist keine Kritik an Runtime-Sicherheit – sie ist absolut notwendig. Für die Sicherheit fast aller Anwendungen haben die meisten Unternehmen sowohl in Code-Sicherheitstools als auch in Tools für die Betriebssicherheit investiert, die jeweils auf unterschiedliche Nutzer ausgerichtet sind. Container sind interessant, weil sie Aspekte beider Bereiche in einem praktischen Paket vereinen. Dennoch gibt es weiterhin beide Nutzergruppen.

Snyk Container ist die einzige Lösung, die von Grund auf dafür entwickelt wurde, Sicherheit in das tägliche Denken und die Build-Prozesse von Entwicklern einzubinden. Wir erkannten ein Problem darin, lediglich lange Listen mit Sicherheitslücken anzuzeigen, wie es bei sicherheitsorientierten Tools üblich war. Stattdessen gibt Snyk Container Entwicklern direkte Anleitungen zur Behebung von Containerproblemen – angefangen mit unseren Empfehlungen für Basis-Images:

Stilisierte Terminalfenster mit einer Snyk-CLI-Ausgabe, die Container-Schwachstellen erkennt und ein Upgrade des Basis-Images empfiehlt.

Die Empfehlungen führen Entwickler zu aktuellen und schlankeren Basis-Images und verringern so die „Angriffsfläche“ für Sicherheitslücken. Mit dem Scannen von Dockerfiles und Fix-PRs gehen wir jetzt noch einen Schritt weiter und automatisieren diese Empfehlungen. Und das Beste: Snyk Container ist unabhängig davon, wie Sie Ihre Container ausführen. Für den Einsatz von Snyk Container sind weder Sidecars noch Agents oder spezielle privilegierte Pods in Kubernetes erforderlich.

Sicherheit mit der zunehmenden Nutzung von Containern skalieren

Natürlich funktioniert Snyk Container dort, wo Entwickler arbeiten. Entwickler können Snyk Container direkt auf ihrem Desktop über unsere CLI nutzen. Außerdem ist die Lösung über Integrationen mit den Quellcodeverwaltungen Ihrer Wahl (einschließlich GitHub-Code-Scanning), jedem CI/CD-Tool und Container-Registries verfügbar. Sie lässt sich auch in Kubernetes integrieren, um Workloads beim Bereitstellen oder Aktualisieren in Ihren Clustern zu scannen.

Mit der wachsenden Zahl containerisierter Workloads wird es noch wichtiger, Entwicklern dabei zu helfen, über das Basis-Image hinaus zu priorisieren, welche Probleme behoben werden sollen. Container werden erstellt, sobald Code committet wird, und lassen sich ebenso schnell bereitstellen. Unser Ziel ist es, von Anfang an für sichere Container zu sorgen. Die Priorisierungsfunktionen von Snyk lenken die Aufmerksamkeit der Entwickler auf die wichtigsten Probleme. Dabei berücksichtigen sie Details zu Sicherheitslücken wie Schweregrad und Reife des Exploits sowie die Frage, ob der Container gerade aktiv ausgeführt wird. Filter helfen Entwicklern außerdem, einfach zu entscheiden, welche Probleme sie beheben und wie sie dabei vorgehen.

Dashboard zur Priorisierung von Sicherheitslücken mit schwerwiegenden Problemen und einer Erklärung der Bewertung, die Exploit- und Container-Risikofaktoren auflistet

Erfahren Sie, wie Kunden von Snyk Container die Sicherheit cloudnativer Anwendungen gewährleisten

Red Ventures wusste, dass ein reibungsloses Entwicklererlebnis entscheidend für eine bessere Containersicherheit ist. Deshalb integrierte das Unternehmen Snyk in seine Tools, um umsetzbare Sicherheitsprobleme sichtbar zu machen und deren effizientere Behebung zu ermöglichen. Als entwicklerorientiertes Sicherheitstool fügt sich Snyk nahtlos in die Engineering-Workflows ein.

Lunar benötigte eine Lösung, die sofort einsatzbereit ist und keine spezielle Schulung oder separate Webanwendung erfordert, um die Akzeptanz bei Entwicklern zu fördern. Durch die Integration von Snyk in die Pipeline erhält das Team einen besseren Überblick über Sicherheitslücken. So kann ein viel beschäftigtes Team übergeordnete Risiken erkennen und die gerade dringendsten Probleme beheben.

Container-Sicherheit mit Fokus auf Entwickler

Snyk findet und behebt automatisch Schwachstellen in Container-Images und Kubernetes-Workloads.

Weiterlesen

feature customer snowflake
Article

Sicherheit von Anfang an: Die Snyk Studio-Integration für Snowflake Cortex Code

Snyk Studio ist in Snowflake Cortex Code integriert und scannt KI-generierten Code, Abhängigkeiten und Container während der Entwicklung auf Schwachstellen.

blog feature pypi spoof
Article

Die gesamte Snyk AI Security Platform – kostenlos für Open-Source-Maintainer

Open-Source-Maintainer werden von echten Schwachstellenmeldungen überflutet und brauchen Unterstützung dabei, diese zu priorisieren, zu beheben und schneller Korrekturen bereitzustellen. Das Secure Developer Program von Snyk bietet qualifizierten Projekten kostenlosen Zugang zur Snyk AI Security Platform.

feature insights announcement
Blog

Node-gyp-Supply-Chain-Kompromittierung: Ein sich selbst verbreitender npm-Wurm, der sich in binding.gyp versteckt

Ein neuer npm-Wurm missbraucht binding.gyp, um node-gyp während der Installation auszuführen. So können schädliche Pakete Code ohne Lifecycle-Skripte ausführen. Der Wurm stiehlt Zugangsdaten, setzt sich in GitHub fest und verbreitet sich selbstständig über Maintainer.