Kubernetes-Sicherheit 2026: Warum die Supply Chain zur Hauptangriffsfläche wird

Die Zahl klingt alarmierend, ist aber offiziell: 97 Prozent der Organisationen meldeten im vergangenen Jahr mindestens einen cloud-nativen Sicherheitsvorfall. Das ist ein zentrales Ergebnis des „State of Cloud-Native Security 2026"-Reports von Red Hat. Gleichzeitig zeigt eine Serie von Supply-Chain-Angriffen im Jahr 2026, dass die Angriffsfläche längst nicht mehr nur der Kubernetes-Cluster selbst ist: Die Build-Pipeline, CI/CD-Systeme und Paket-Repositories sind zur neuen Frontlinie geworden. Für Teams, die Kubernetes produktiv betreiben, heißt das: Sicherheit beginnt heute weit vor dem ersten kubectl apply.

Die Lage: Sicherheitsvorfälle sind der Normalfall

Der Red-Hat-Report zeichnet ein nüchternes Bild: Sicherheitsvorfälle sind in cloud-nativen Umgebungen „nahezu universell" geworden — und meist sind es keine hochkomplexen Angriffe, sondern Alltagsfehler. Die Folgen sind messbar: 74 Prozent der Organisationen haben in den letzten zwölf Monaten Anwendungs-Deployments wegen Sicherheitsbedenken verzögert oder verlangsamt, 52 Prozent meldeten erhöhten Aufwand für Remediation, 43 Prozent eine geringere Entwicklerproduktivität.

Besonders auffällig ist das „Maturity-Paradoxon": 56 Prozent der Befragten beschreiben ihre tägliche Sicherheitslage als „hochproaktiv", aber nur 39 Prozent haben tatsächlich eine ausgereifte, klar definierte Sicherheitsstrategie. Rund 22 Prozent arbeiten komplett ohne definierte Strategie. Dieser Widerspruch macht Teams anfällig — insbesondere, weil 64 Prozent der Organisationen den EU Cyber Resilience Act (CRA) als wichtigsten Treiber ihrer Investitionsentscheidungen für 2026 sehen. Compliance-Anforderungen wachsen also, während die strategische Basis oft fehlt.

Die Build-Pipeline als Angriffsziel: Die TanStack-Attacke

Dass die Supply Chain kein theoretisches Risiko ist, zeigte der TanStack-Vorfall vom Mai 2026. Angreifer kompromittierten 42 npm-Pakete und publizierten innerhalb von sechs Minuten 84 bösartige Paketversionen. Bemerkenswert war die Angriffskette: ein getarnter Fork des TanStack-Routers mit schädlichem Pull Request, Cache-Poisoning der GitHub-Actions-Workflows und die Ausnutzung unsicherer pull_request_target-Workflows. So konnten OIDC-Tokens erzeugt werden, die direkt auf npm publizieren durften — ohne dass npm-Zugangsdaten gestohlen wurden.

Die injizierte Malware griff gezielt Entwickler- und CI-Umgebungen an und sammelte Credentials aus AWS, GCP, Kubernetes, Vault, GitHub, SSH-Keys und npm-Konfigurationen. Für Kubernetes-Betreiber ist das ein Warnsignal: Kompromittierte Build-Pipelines sind ein direkter Weg zu Cluster-Credentials. OpenAI bestätigte kurz darauf, dass zwei Mitarbeiter-Geräte betroffen waren und Code-Signing-Zertifikate rotiert werden mussten. Die Angreifergruppe TeamPCP weitete die Kampagne auf weitere Ökosysteme aus; betroffen waren unter anderem Pakete rund um Mistral AI und UiPath.

Auch die Plattform selbst bleibt ein Ziel

Parallel zu Supply-Chain-Angriffen zeigen neue Schwachstellen, dass auch Kubernetes-Erweiterungen selbst kritische Lücken aufweisen. Dell veröffentlichte im Oktober 2026 Sicherheitsupdates für ihre Container Storage Modules (CSM): Mehrere Schwachstellen (u. a. CVE-2026-63688, CVE-2026-67269, CVE-2026-67273) ermöglichen unauthentifizierten administrativen Zugriff, die Kompromittierung aller Nodes eines Clusters über eine einzelne Custom Resource und clusterweiten Lesezugriff auf Kubernetes Secrets inklusive Erstellung clusterweiter RBAC-Ressourcen. Betroffen waren alle CSM-Versionen vor 1.17.0 — ein Beleg dafür, wie schnell ein einzelnes, wenig beachtetes Add-on die gesamte Cluster-Sicherheit aushebeln kann.

Was Teams jetzt tun sollten

Aus den Vorfällen lassen sich konkrete Maßnahmen ableiten:

• Supply-Chain-Absicherung standardisieren: SLSA-Provenance-Verifikation, Sigstore-Signing und konsequentes Dependency-Auditing sind keine Optionalfeatures mehr. Organisationen mit klar definierter Strategie berichten deutlich höheres Vertrauen in die Sicherheit ihrer Software-Supply-Chain (61 Prozent im Red-Hat-Report).
• CI/CD härten: Unsichere Workflow-Muster wie pull_request_target vermeiden, Cache-Isolation sicherstellen, GitHub-Actions auf feste SHAs pinnen. TanStack selbst hat genau diese Maßnahmen nach dem Vorfall umgesetzt.
• Kubernetes-Erweiterungen ernst nehmen: Add-ons wie Storage- oder Security-Controller sind Teil der Angriffsfläche. Regelmäßige Updates, CVE-Monitoring und ein Inventar aller Custom Resource Definitions gehören zur Grundhygiene.
• Least Privilege konsequent durchsetzen: Kurzlebige, OIDC-basierte Credentials statt langlebiger Tokens, Secrets nicht in Umgebungsvariablen, sondern in einem Secret-Manager.
• Strategie statt Feuerwehr: Der Red-Hat-Report empfiehlt, über Ad-hoc-Reaktionen hinaus zu einer plattformzentrierten Security-Architektur zu kommen — Security Guardrails direkt in die Entwicklungs- und Deployment-Pipelines integriert.

Fazit

Kubernetes-Sicherheit 2026 ist mehrdimensional: Während der Cluster selbst durch Schwachstellen in Erweiterungen bedroht bleibt, verschiebt sich der Fokus der Angreifer zunehmend auf die Lieferkette und die Automatisierung davor. Die gute Nachricht: Die Werkzeuge zur Absicherung sind bekannt und ausgereift — SLSA, Sigstore, Policy-Engines und harte CI/CD-Konfiguration. Was vielen fehlt, ist die strategische Verankerung. Genau dort liegt der Hebel für 2026: Sicherheit muss von einem Bremsklotz zu einem Basissystem werden, das in den Cloud-Native-Stack eingebaut ist — nicht aufgesetzt, sondern integriert.

Quellen

• Red Hat: The state of cloud-native security 2026: Maturity gaps and the automation mandate — Berichtsdaten zu Vorfällen, Reifegrad und CRA
• InfoQ: TanStack Details Sophisticated npm Supply Chain Attack That Compromised 42 Packages — Angriffskette & Gegenmaßnahmen
• The Hacker News: TanStack Supply Chain Attack Hits Two OpenAI Employee Devices, Forces macOS Updates — Auswirkungen, TeamPCP, betroffene Ökosysteme
• The Hacker News: Dell CSM Flaws Enable Unauthenticated Admin Access and Root on Kubernetes Nodes — aktuelle Kubernetes-Schwachstellen in Dell CSM