Die Lücken im Blick: Risiken durch Abhängigkeiten in cloud-nativen Clustern

Originalartikel von Magno Logan, Information Security Specialist

Was bedeutet es, auf Cloud Native zu setzen? Unternehmen und Anwender von cloud-nativen Applikationen müssen sich darüber im Klaren sein, dass eine Schwachstelle in einer der dabei vorhandenen Abhängigkeiten und Bibliotheken das gesamte System beeinträchtigen und in einigen Fällen zu einer vollständigen Kompromittierung des Clusters führen kann. Nachdem wir die Schwachstellen in den cloud-nativen Applikationen aufgezeigt haben, geht es nun um die Abhängigkeiten von quelloffener Software und entsprechende Empfehlungen für einen besseren Schutz.

Die meisten cloud-nativen Projekte greifen auf Bibliotheken und Abhängigkeiten zurück, die wiederum Open-Source sind. Diese Bibliotheken werden in der Regel während des Entwicklungszyklus eingebunden und nur selten aktualisiert oder auf bekannte Schwachstellen überprüft — ein weiterer Weg zu kompromittierten Cloud-Ressourcen.

Open-Source-Sicherheit und die steigende Zahl von Sicherheitslücken

Wir haben die Abhängigkeiten in diesen Projekten analysiert und die veralteten oder anfälligen Bibliotheken, die möglicherweise im Code verwendet werden, gesucht, aber auch die Risiken durch Lizenzen analysiert. Trend Micro Cloud One – Open Source Security war für die Ergebnisse der Analyse der Softwarezusammensetzung beim Scannen im Einsatz:

Bild 1. Die Zahl der Schwachstellen in Drittanbieter-Abhängigkeiten bei Cloud Native-Projekten, nach Schweregrad (Quelle: Cloud One Open Source Security powered by Snyk).

Als umfangreichstes Projekt mit derzeit über 4,6 Millionen Codezeilen ist Kubernetes dasjenige mit den meisten Drittanbieter-Sicherheitslücken: über 500 mittlere und hochriskante Sicherheitslücken und Lizenzierungsprobleme in den Abhängigkeiten. Harbor, an zweiter Stelle, hat nur 157 Schwachstellen, und Vitess, das an dritter Stelle steht, hat 144. Das Notary-Projekt ist das einzige Projekt mit einer kritischen Sicherheitslücke in seinen Abhängigkeiten, gehört jedoch zu den Projekten mit der geringsten Anzahl von Sicherheitslücken insgesamt. Weitere Einzelheiten dazu beinhaltet der Originalbeitrag.

Die Anzahl der Probleme nimmt immer weiter zu (siehe Bild 2). Während sich ein Projekt weiterentwickelt, werden mit jedem Commit neue Schwachstellen in den Code eingefügt. Im Branchendurchschnitt gibt es pro 1000 Zeilen Code zwischen fünf und 50 potenzielle Probleme. Das ist ein weiterer Grund, warum wir diese Risiken durch Drittanbieter priorisieren sollten.

Bild 2. Die Anzahl der im Laufe der Zeit entdeckten Probleme in den CNCF-Projekten.

Sicherheitsempfehlungen und Prozessverbesserungen

Es mag ein klischeehafter Ratschlag sein, aber die Nutzung der neuesten Version dieser Projekte ist eine der besten Möglichkeiten, um sicher zu bleiben. Darin wurden die meisten der gemeldeten Probleme behoben, da die Projekte dies tun müssen, um den graduierten Status bei der CNCF zu erreichen. Um sicherzugehen, können Sie die offenen Probleme im Zusammenhang mit der Sicherheit für jedes dieser Projekte überprüfen.

Sie können auch einen Blick auf die Sicherheitsprüfungen werfen. Dazu gibt es zwei Möglichkeiten: Erstens können Sie ein bestimmtes CNCF-Projekt beobachten, ob in dessen Repository ein RFP oder der Bericht zum Sicherheits-Audit veröffentlicht wird. Oder sie können das Repository des TOC (Technical Oversight Committee) auf GitHub auf ein Update überprüfen, wenn ein neuer Audit veröffentlicht wird:

Zudem dienen Lösungen wie die Trend Micro Cloud One™-Plattform, die auf Cloud-native Systeme zugeschnitten ist, mit Continuous-Integration- und Continuous-Delivery (CI/CD)-Pipelines und -Anwendungen der Sicherheit der Systme. Die Plattform umfasst:

Empfehlungen für die Cloud Native Computing Foundation (CNCF)

Das Sicherheits-TAG-Team hat sich bemüht, die Häufigkeit der Sicherheitsbewertungen von CNCF-Projekten zu verbessern. Solche Initiativen sollten jedoch priorisiert werden und die CNCF regelmäßigere Bewertungen einführen und durchsetzen. Die Stiftung sollte den häufigsten Projekten wie Kubernetes, etcd, Helm und anderen Priorität einräumen. Darüber hinaus wäre es von Vorteil, die Ausschreibungen für Sicherheit-Audits noch stärker zu fördern und einen vielfältigeren Pool von Beratungsunternehmen zu haben.

Eine weitere Empfehlung wäre, ein einzigartiges Programm zur Offenlegung von Schwachstellen einzurichten, das alle von der CNCF graduierten Projekte abdeckt, und, wenn möglich, als nächsten Schritt eine Bug Bounty-Initiative zu etablieren. Einige dieser CNCF-Projekte, wie z. B. Kubernetes, haben Bug-Bounty-Programme, die je nach Schweregrad der gefundenen Schwachstellen zwischen 100 und 10.000 US-Dollar zahlen.

Die meisten Projekte haben bereits eine SECURITY.md oder eine andere Möglichkeit, um Schwachstellen zu melden. Leider scheint dies nicht bei allen Projekten standardisiert zu sein. Es gibt auch wenig Transparenz darüber, was gemeldet wird und was behoben wird. Sicherheitslücken, die bestätigt werden, sollten verfolgt und behoben werden, und vorzugsweise eine CVE zugewiesen bekommen, wenn das Problem bestätigt ist.

Nicht zuletzt sollten wir Probleme im Zusammenhang mit Komponenten von Drittanbietern untersuchen und priorisieren und sie gegen Angriffe auf die Supply Chain absichern. Um den Wandel voranzutreiben, sollten wir als Gemeinschaft jedoch das tun, was wir predigen, und mit gutem Beispiel vorangehen, indem wir die Empfehlungen und Best Practices aus dem Whitepaper in allen CNCF-Projekten anwenden.

Weitere Informationen über CNCF-Sicherheitsaudits finden Sie im Anhang.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.