80 % der Entwickler kümmern sich nicht um Docker-Sicherheit

Artikel von

William Henry

17. April 2019

0 Min. Lesezeit

Willkommen zum Docker-Sicherheitsbericht: Docker-Sicherheit nach links verlagern. Dieser Bericht ist in mehrere Beiträge unterteilt:

Docker-Sicherheit nach links verlagern
Die beiden beliebtesten Docker-Basis-Images weisen jeweils über 500 Sicherheitslücken auf
80 % der Entwickler kümmern sich nicht um Docker-Sicherheit
Ergreifen Sie Maßnahmen, um die Sicherheit Ihrer Docker-Images zu verbessern

Oder laden Sie unseren liebevoll gestalteten PDF-Bericht herunter, der all diese Informationen und noch mehr an einem Ort enthält.

Verantwortung für Container-Sicherheit

Wenn Docker ein integraler Bestandteil Ihres Ökosystems ist, muss jemand dafür Verantwortung übernehmen. Die meisten sind sich einig, dass diese Verantwortung gemeinsam getragen wird. Auf die Frage, wer für die Container-Sicherheit verantwortlich ist (Mehrfachantworten waren möglich), waren die meisten Befragten der Meinung, dass Entwickler für die Container-Sicherheit verantwortlich sein sollten (68 %), gefolgt von Operations (39 %).

Balkendiagramm zur Frage, wer für die Sicherheit von Container-Images verantwortlich ist: Entwickler 68 %, Betrieb 39 %, Sicherheitsteam 27 %, Sonstige 3 %, niemand 12 %.

Auch wenn Sicherheit in DevOps – oder besser gesagt in DevSecOps – eine gemeinsame Aufgabe ist, sehen wir, dass die Mehrheit Entwicklern eine Schlüsselrolle zuschreibt. Das entspricht unseren Beobachtungen zur Verantwortung für die Sicherheit von Anwendungscode. Laut dem Bericht The State of Open Source Security sind 81 % der Befragten der Meinung, dass Entwickler für die Sicherheit ihrer Anwendungen verantwortlich sein sollten.

Unternehmen sollten außerdem in Erwägung ziehen, mit dem vertrauenswürdigen Anbieter der Basis-Images zusammenzuarbeiten, um einige der Sicherheitsrisiken beim Einsatz von CI/CD-Pipelines zu bewältigen. Anbieter wie Red Hat stellen geprüfte und signierte Images bereit. Außerdem reagieren sie schnell auf CVEs in Basis-Images, wodurch in CI/CD-Pipelines der Neubau von Anwendungs-Images ausgelöst werden kann. Das macht Scans während des DevOps-Lebenszyklus nicht überflüssig, verkürzt aber die Zeitspanne zwischen anfälligen und sicheren Images in der Produktionsumgebung. Die gemeinsame Übernahme des Risikos mit einem Drittanbieter kann dazu beitragen, das Gesamtrisiko zu senken.

Sicherheitstests auf Betriebssystemebene

Leider geben nur 19 % der Entwickler an, ihre Docker-Images während der Entwicklung auf Sicherheitslücken in der Betriebssystemebene zu testen. Das bedeutet, dass über 80 % der Entwickler die Sicherheit nicht nach links verlagern, um ihre Images während der Entwicklung zu testen. Sicherheitslücken erst später zu entdecken, ist leider kostspieliger.

Darüber hinaus führen die Hälfte (50 %) der Nutzer keinerlei Scan der Betriebssystemebene ihres Docker-Images durch. Es ist wichtig zu wissen, was sich in der Betriebssystemebene Ihrer Images befindet. Docker-Images blindlings zu verwenden, ist sehr gefährlich, da Sie mit Sicherheit zahlreiche Sicherheitslücken einschleppen. Sie können das Risiko leicht verringern, indem Sie die Images scannen und sich zunächst mit den bekannten Sicherheitslücken in jedem Image vertraut machen, das Sie in Betracht ziehen.

Horizontales Balkendiagramm zur Frage, wann Docker-Images auf Betriebssystem-Schwachstellen geprüft werden: 50 % prüfen sie gar nicht, 31 % während des Builds und 19 % während der Entwicklung.

Mit einem Scan-Tool für Docker-Images, wie dem von Snyk, lassen sich anfällige Images während des gesamten Entwicklungszyklus erkennen. Bereits lokal, wenn ein Entwickler ein bestimmtes Docker-Image auswählt, verhindert der Scan, dass anfällige Docker-Images in Ihre Umgebung gelangen. Wiederholen Sie die Scans in allen Phasen bis zum Ende der CI/CD-Pipeline, um zu verhindern, dass ein Image mit bekannten Sicherheitslücken in die Produktion gelangt.

Mit der Zeit werden Sicherheitslücken in Images entdeckt. Daher ist es wichtig, Ihre Produktions-Images im Blick zu behalten. Die mittlere Zeit bis zur Entdeckung und Meldung einer Sicherheitslücke beträgt 2,5 Jahre. Derzeit geben 9 % der Nutzer an, ihre Images in der Produktionsumgebung zu scannen. Ein Image kann zum Zeitpunkt seiner Bereitstellung in der Produktion sicher gewesen sein. Danach wissen jedoch über 90 % der Entwickler nicht mehr, wie es aktuell um die Sicherheit ihrer Images bestellt ist.

Informationen zu Sicherheitslücken erhalten

Wir haben auch gefragt, wie Nutzer erfahren, dass ein von ihnen verwendeter Container offengelegte Sicherheitslücken enthält. 45 % prüfen dies wahrscheinlich nie. Ein gewisser Anteil (15 %) der Befragten prüft öffentliche Datenbanken wie die CVE-Datenbank. Bedenken Sie jedoch, dass die CVE-Datenbank nur die Spitze des Eisbergs ist. Die Registrierung einer CVE kann mehrere Wochen dauern, und viele Sicherheitslücken werden möglicherweise überhaupt nicht als CVE-Eintrag erfasst, können aber dennoch ein erhebliches Risiko für Ihr System darstellen.