KW 12/2026: Supply-Chain-Angriffe erreichen Docker

Wenn ich diese Woche die Security-News durchgehe, fällt mir eines sofort auf: Die Angreifer haben verstanden, dass man Unternehmen heute nicht mehr frontal angreifen muss – es reicht, den Lieferwagen mit der Softwarelieferung zu kapern. Die aktuelle Attacke auf Trivy, kombiniert mit gezielten Angriffen auf Kubernetes-Cluster und den zeitweisen Ausfällen bei Microsoft Exchange Online, zeigt genau das. Infrastruktur, auf die wir uns verlassen, wird zum Risiko.

Trivy-Supply-Chain-Angriff: Wenn die Lieferkette selbst zum Feind wird

Laut BleepingComputer haben Angreifer, die unter dem Namen TeamPCP auftreten, die Sicherheits-Scanner-Software Trivy ins Visier genommen – genauer gesagt deren Distributionswege. Manipulierte Docker-Images und GitHub-Repositories dienten als Einfallstor in Entwicklungsumgebungen. Das perfide daran: Betroffene DevOps-Pipelines konnten bösartigen Code direkt in Produktionssysteme einfließen lassen. Es war also nicht nötig, ein Unternehmen direkt zu kompromittieren – man musste nur die Bausteine an der Quelle manipulieren.

Aus meiner Sicht ist das ein Paradebeispiel dafür, warum Supply-Chain-Security längst kein “Add-on” mehr sein darf, sondern Kern der Sicherheitsstrategie sein muss. Wer Docker-Images blind aus öffentlichen Quellen zieht oder Tools aus GitHub installiert, öffnet der Manipulation Tür und Tor. Gerade CI/CD-Systeme sind kritisch, weil jede Änderung dort sich automatisch in die Produktionsumgebung fortpflanzt. Ehrlich gesagt, wer an dieser Stelle keine Kontrolle implementiert, handelt fahrlässig.

Die Ironie: Trivy selbst ist ein Tool, das Schwachstellen erkennen soll. Ausgerechnet ein Sicherheitsscanner wird also über die Lieferkette zur Schwachstelle. Aqua Security hat bereits Warnungen veröffentlicht und die kompromittierten Pakete entfernt – aber der Schaden ist, wie so oft, weniger technisch als vertrauensbezogen. Wenn selbst Security-Tools kompromittiert werden, wie soll dann ein regulärer Entwickler noch sicher entscheiden, welchem Paket er trauen kann?

Für Unternehmen in Aachen oder NRW mit eigenen Entwicklungsumgebungen – gerade in der Automatisierung oder Medizintechnik – bedeutet das: Nur geprüfte Images und Tools einsetzen. Signaturen, Hash-Prüfungen, und wo möglich eigene Repositories verwenden. Vertrauen ist gut, Supply-Chain-Validierung ist besser.

Kubernetes unter Beschuss: Wiper-Malware im Cluster

Als wäre die Trivy-Geschichte nicht genug, setzt dieselbe Gruppe TeamPCP noch eins drauf: Sie greift Kubernetes-Cluster an und nutzt Skripte, die gezielt Daten löschen, wenn bestimmte Systeme erkannt werden. Laut Bericht von BleepingComputer wurden diese Wiper-Skripte ursprünglich gegen iranische Zielumgebungen eingesetzt. Technisch funktioniert das so: Wenn ein Cluster schlecht abgesichert ist – etwa weil eine Container Registry offen im Netz erreichbar ist oder Pod-Sicherheitsrichtlinien fehlen – schleusen die Angreifer ihre Schadsoftware ein. Die Malware überprüft, ob bestimmte Zielkonfigurationen erfüllt sind, und zerstört im Anschluss Daten im Cluster.

Diese Angriffsart zeigt erneut die Achillesferse moderner IT: Automatisierung ohne ausreichende Absicherung. Kubernetes ist ein fantastisches Werkzeug für Skalierung und Deployment, aber in der Praxis sehe ich regelmäßig, dass Default-Konfigurationen übernommen werden – oft ohne Zugriffskontrolle oder Monitoring. Genau das nutzen Gruppen wie TeamPCP aus.

Was mir dabei Sorgen macht: Es geht hier nicht „nur“ um Datendiebstahl, sondern um aktive Zerstörung. Ein Wiper ist kein Ransomware-Vorfall, den man durch Zahlung wieder lösen könnte – hier ist das Ziel kompletter Datenverlust. Das mag gezielt gegen bestimmte Staaten gerichtet sein, aber wer garantiert, dass dieselben Wiper nicht morgen zufällig ganze Unternehmensinfrastrukturen in Europa treffen? Denn schlechte Konfiguration unterscheidet kein Land.

Für Betriebe in der Städteregion Aachen, gerade in der Produktion oder IT-Dienstleister, gilt daher: Schützen Sie Ihre Cluster konsequent. Ein einfaches Role-Based-Access-Control, Netzwerksegmentierung und das Deaktivieren öffentlicher Registries verhindern solche Angriffe in den meisten Fällen. Kubernetes ist mächtig, aber nur so sicher wie seine Konfiguration.

Microsoft Exchange Online: Ausfall durch Service-Änderung

Das dritte Thema dieser Woche zeigt wieder die Abhängigkeit von Cloud-Diensten. Microsoft hat eine Service-Änderung in Exchange Online vorgenommen, durch die bestimmte Virtual-Account-Einstellungen geändert wurden. Die Folge: Nutzer von Outlook Mobile und Outlook für Mac konnten zeitweise nicht mehr auf ihre Postfächer zugreifen. Für viele Unternehmen bedeutete das schlicht Ausfall der E-Mail-Kommunikation – und das mitten im Arbeitstag.

Klar, kein Angriff diesmal – aber die Wirkung ist ähnlich. Teams waren von außen nicht erreichbar, Tickets blieben liegen, Kommunikation stand still. Und das nur, weil Microsoft in seiner Cloud-Umgebung Änderungen durchführte, die offenbar nicht ausreichend getestet oder kommuniziert worden waren.

Aus meiner Sicht unterstreicht das ein Grundproblem der Cloud-Abhängigkeit: Kontrolle und Transparenz bleiben beim Anbieter. Sie können reagieren, aber selten präventiv etwas tun. Wer also vollständig auf Exchange Online setzt, sollte für Ausfälle vorbereitet sein – etwa mit Offline-Zugängen, redundanten Kommunikationswegen oder hybriden Setups. Cloud bedeutet nicht automatisch Hochverfügbarkeit.

Gerade kleinere Unternehmen in NRW, die sich auf Microsoft 365 verlassen, sollten sich bewusst machen, dass Cloud-Dienste ebenfalls Redundanzkonzepte brauchen. Ein Ausfall muss kein Sicherheitsvorfall sein, kann aber denselben Schaden verursachen.

Was jetzt zu tun ist

Diese drei Themen führen uns alle zum gleichen Punkt: Es sind nicht immer spektakuläre Exploits, die Systeme gefährden, sondern die Kombination aus Vertrauen, Bequemlichkeit und Automatisierung. Wer ein Docker-Image einbindet, ohne es zu prüfen, öffnet dieselbe Tür wie jemand, der Kubernetes ohne Zugriffsbeschränkung betreibt. Und wer auf Cloud-Dienste setzt, ohne Alternativen vorzuhalten, gibt Verantwortung ab, ohne vollständige Absicherung.

Konkret sollten Unternehmen ihre Softwarelieferkette analysieren. Welche Dependencies werden genutzt, woher kommen sie und wie werden sie validiert? Wenn die Antwort darauf ‚aus Docker Hub‘ lautet, ohne eigene Prüfung, ist das Risiko hoch.

Zweitens sollten DevOps-Teams Monitoring in ihren Pipelines implementieren. Es gibt mittlerweile Tools, die automatisch prüfen, ob bekannte Libraries manipuliert wurden oder Commits aus verdächtigen Quellen stammen. Und natürlich: MFA, MFA, MFA – aber auch Conditional Access, um automatisierte Zugriffe abzusichern.

Drittens sollten Betreiber von Kubernetes-Umgebungen – auch Testumgebungen – endlich Policies konsequent umsetzen. PodSecurityPolicies, Namespaces und Logging sind keine Kür, sondern Pflicht. Und wenn Sie Exchange Online nutzen, überlegen Sie sich, wie Sie im Störfall kommunizieren können. Alte Tugenden wie E-Mail-Fallbacks oder lokale Kopien haben noch immer ihren Wert.

Für viele Unternehmen in Aachen und Umgebung mag das übertrieben klingen, aber gerade hier mit vielen High-Tech-Zulieferern und Forschungsinstituten sind Entwicklungsumgebungen extrem attraktiv für Angreifer. Supply-Chain-Angriffe sind kein exotisches Phänomen mehr – sie sind der Standard. Nur wer sie ernst nimmt, bleibt handlungsfähig.

Mein Fazit

Diese Security-Woche war ein Lehrstück in Sachen Vertrauen. Der Supply-Chain-Angriff auf Trivy zeigt, dass selbst gute Absichten ausgenutzt werden können. Die Kubernetes-Wiper machen klar, dass Konfiguration und Überwachung überlebenswichtig sind. Und der Exchange-Ausfall erinnert uns daran, dass Cloud nicht gleichbedeutend mit Sicherheit und Stabilität ist.

Ehrlich gesagt, es gibt keine magische Lösung. Security ist Arbeit und Verantwortung – kontinuierlich, nicht einmalig. Wer denkt, automatisierte Tools würden einem alles abnehmen, hat nicht verstanden, dass Angreifer dieselben Automatisierungsmöglichkeiten nutzen.

Wenn Sie unsicher sind, ob Ihr Team oder Ihre Infrastruktur ausreichend abgesichert ist – insbesondere Ihre CI/CD-Pipelines oder Cluster – sprechen Sie mich an. Ein gezielter Security-Check und ein Härtungskonzept für Ihre Entwicklerumgebung kosten weniger, als wenn manipulierte Images einmal in Produktion gelangen. Theoretisch weiß das jeder – praktisch passiert es leider viel zu oft.