Wenn vertrauenswürdige Software zum Angriffsvektor wird – Lehren aus der TeamPCP-Supply-Chain-Kampagne 2026

Geschätzte Lesezeit: 12 Minuten

Software-Supply-Chain-Angriffe greifen nicht zwingend ein Unternehmen direkt an. Stattdessen kompromittieren Angreifer Komponenten, denen Entwickler, CI/CD-Systeme und Cloud-Umgebungen bereits vertrauen. Die TeamPCP-Kampagne aus dem Jahr 2026 zeigt, wie aus einer manipulierten Softwarekomponente innerhalb kurzer Zeit ein Risiko für Zugangsdaten, Cloud-Infrastrukturen, Software-Repositories und KI-Systeme entstehen kann.

  • Das FBI bestätigt eine TeamPCP-Kampagne gegen vertrauenswürdige Software-Vertriebskanäle und nennt unter anderem Trivy, KICS, LiteLLM und das Telnyx Python SDK als betroffene Komponenten. [1]
  • Eine Untersuchung von CloudSEK bringt den LiteLLM-Teil der Kampagne mit mehr als 2.500 potenziell exponierten Organisationen und rund 434.000 CI/CD-Pipelines in Verbindung. Diese Zahlen stehen für potenzielle Exposition und nicht für 2.500 bestätigte Sicherheitsverletzungen. [2]
  • Die zentrale Lehre: Wird eine vertrauenswürdige Komponente kompromittiert, entscheidet der Zugriff ihrer Ausführungsumgebung darüber, wie groß der tatsächliche Schadensradius werden kann.

Inhaltsverzeichnis

Angriffe auf die Software-Lieferkette sind besonders gefährlich, weil sie eine der grundlegenden Annahmen moderner IT-Umgebungen untergraben: dass Software, die aus einer vertrauenswürdigen Quelle stammt, selbst vertrauenswürdig ist. Die Kampagne des Jahres 2026, die mit der Cybercrime-Gruppe TeamPCP in Verbindung gebracht wird, zeigt, wie schnell diese Annahme scheitern kann. Anstatt Organisationen einzeln anzugreifen, zielten die Angreifer auf Komponenten, die bereits fest in Entwicklungs-, Sicherheits- und Cloud-Workflows integriert waren. Das FBI hat bestätigt, dass TeamPCP vertrauenswürdige Software-Vertriebskanäle kompromittierte und weit verbreitete Tools wie Trivy, KICS, LiteLLM und das Telnyx Python SDK manipulierte. Dadurch konnte Schadcode in großem Umfang in nachgelagerte Umgebungen gelangen. [1]

Eine von CloudSEK am 11. August 2026 veröffentlichte Untersuchung analysierte die potenzielle nachgelagerte Exposition im Zusammenhang mit dem LiteLLM-Teil dieser Kampagne. Der von CloudSEK rekonstruierte Datensatz brachte den Vorfall mit mehr als 2.500 Organisationen und etwa 434.000 CI/CD-Pipelines in Verbindung. Entscheidend ist jedoch: Diese Zahlen stehen für eine potenzielle Exposition und sind kein Beleg dafür, dass jede dieser Organisationen tatsächlich kompromittiert oder jedes Credential gestohlen wurde. [2] Dieser Artikel betrachtet den Vorfall daher aus einer unabhängigen Perspektive: Was ist passiert? Wann ist es passiert? Wie funktionierte die Angriffskette? Warum ist das relevant? Und was sollten Unternehmen jetzt tun?

Was ist passiert?

TeamPCP führte eine Reihe von Angriffen auf Software-Lieferketten durch, bei denen legitime Entwicklungs- und Sicherheitstools manipuliert und anschließend zur Verbreitung von Schadcode verwendet wurden. Das FBI beschreibt eine Kampagne, bei der Angreifer vertrauenswürdige Mechanismen zur Software-Verteilung kompromittierten und trojanisierte Updates einschleusten, die legitim erschienen. Sobald diese manipulierten Komponenten in Entwickler- oder CI/CD-Umgebungen ausgeführt wurden, konnten sie Zugangsdaten stehlen und Zugriff auf nachgelagerte Systeme ermöglichen. [1]

Das ist deshalb besonders relevant, weil die betroffenen Tools in modernen Softwareumgebungen häufig privilegierte Positionen einnehmen. Trivy ist beispielsweise ein Sicherheitsscanner, der häufig in Entwicklungs- und CI/CD-Workflows eingesetzt wird. KICS dient dazu, Sicherheitsprobleme in Infrastructure-as-Code zu erkennen. LiteLLM stellt eine einheitliche Schnittstellen- und Gateway-Schicht zur Kommunikation mit verschiedenen Large-Language-Model-Anbietern bereit. Diese Anwendungen arbeiten nicht isoliert: Sie können innerhalb von Umgebungen ausgeführt werden, die Zugriff auf Quellcode-Repositories, Cloud-Plattformen, Kubernetes-Cluster, Paket-Registries, Deployment-Infrastrukturen und produktive Zugangsdaten besitzen. Genau das macht dieses Angriffsmodell so wirkungsvoll.

Statt zu fragen: „Auf welche Ressourcen hat dieses kompromittierte Paket Zugriff?“ lautet die wichtigere Frage: „Auf welche Ressourcen kann die Umgebung zugreifen, in der dieses Paket ausgeführt wird?“

Die Antwort kann weit über die ursprünglich kompromittierte Softwarekomponente hinausgehen.

Wann ist es passiert?

Der LiteLLM-Vorfall wurde am 24. März 2026 öffentlich bekannt. LiteLLM bestätigte, dass die beiden PyPI-Releases LiteLLM 1.82.7 und LiteLLM 1.82.8 kompromittiert worden waren. [3] Laut dem eigenen Incident Report von LiteLLM wurden die schädlichen Releases am 24. März gegen 10:39 Uhr UTC auf PyPI verfügbar und waren dort etwa 40 Minuten lang verfügbar, bevor PyPI sie unter Quarantäne stellte. Version 1.82.7 enthielt Schadcode in proxy_server.py des AI Gateways, während Version 1.82.8 zusätzlich eine Datei namens litellm_init.pth enthielt. LiteLLM veröffentlichte anschließend mit Version 1.83.0 eine bereinigte Version über eine neu gestaltete CI/CD-Pipeline und stellte Hashwerte für überprüfte, sichere Releases zur Verfügung. [3]

Mit der Entfernung der Pakete war die weitergehende Bedrohung jedoch nicht beendet. Am 2. Juli 2026 veröffentlichte das FBI den Hinweis FLASH-20260702-01, in dem Organisationen vor den Taktiken von TeamPCP sowie den zugehörigen Indicators of Compromise gewarnt wurden. Das FBI betonte, dass während dieser Vorfälle entwendete Zugangsdaten und Informationen als anhaltendes Risiko betrachtet werden sollten, da sie noch lange nach dem ursprünglichen Angriff wiederverwendet oder für weitere Angriffe eingesetzt werden könnten. [1]

Die im August veröffentlichte Untersuchung von CloudSEK versuchte anschließend, die potenzielle nachgelagerte Exposition im Zusammenhang mit der Kampagne zu rekonstruieren. Dabei wurden mehr als 2.500 potenziell exponierte Organisationen und rund 434.000 CI/CD-Pipelines genannt. Auch hier gilt: Diese Zahlen dürfen nicht als 2.500 bestätigte Sicherheitsverletzungen interpretiert werden. CloudSEK unterscheidet ausdrücklich zwischen einer Exposition und einer bestätigten bösartigen Aktivität. [2]

Wie funktionierte der Angriff?

Der bedeutendste Aspekt dieser Kampagne ist die Angriffskette. Die Rekonstruktion von CloudSEK stellt eine Verbindung zwischen dem LiteLLM-Vorfall und einer früheren Kompromittierung von Trivy her. LiteLLM selbst erklärte, man gehe davon aus, dass der Vorfall möglicherweise auf eine Trivy-Abhängigkeit zurückzuführen sei, die im CI/CD-Security-Scanning-Workflow eingesetzt wurde. [2] [3] Die Untersuchung von LiteLLM deutete gleichzeitig darauf hin, dass die schädlichen LiteLLM-Pakete offenbar direkt auf PyPI hochgeladen wurden und nicht über den regulären Release-Prozess. [3] Die genauen technischen Abläufe müssen daher differenziert dargestellt werden: Nicht jedes Element der rekonstruierten Angriffskette sollte als unabhängig bestätigt dargestellt werden.

Auf einer höheren Ebene zeigt die Kampagne jedoch ein sechsstufiges Angriffsmodell:

  1. Eine vertrauenswürdige Komponente kompromittieren.
    Ein Angreifer übernimmt die Kontrolle über ein Paket, ein Publishing-Credential, eine Abhängigkeit oder eine Komponente, die von einem legitimen Entwicklungs- oder Sicherheitsprozess verwendet wird.
  2. Das vertrauenswürdige Ökosystem die schädliche Komponente verteilen lassen.
    Entwickler und automatisierte CI/CD-Systeme laden weiterhin Software herunter oder führen sie aus, die scheinbar legitim ist.
  3. Ausführung innerhalb privilegierter Entwicklungsinfrastruktur.
    Der Schadcode läuft nun auf Runnern, Build-Systemen oder Entwicklerumgebungen, die möglicherweise bereits Zugriff auf sensible Credentials besitzen.
  4. Authentifizierungsinformationen sammeln.
    Abhängig von der jeweiligen Umgebung können dazu Cloud-Credentials, SSH-Schlüssel, Kubernetes-Tokens, API-Schlüssel, Umgebungsvariablen und andere Secrets gehören.
  5. Die gestohlenen Credentials zur Ausweitung des Zugriffs verwenden.
    Gestohlene Zugangsdaten können Zugriff auf Repositories, Registries, Cloud-Ressourcen, Kubernetes-Umgebungen oder andere Services ermöglichen.
  6. Den gestohlenen Zugriff später erneut verwenden.
    Durch die Entfernung des schädlichen Pakets wird zwar der ursprüngliche Verteilungsmechanismus beendet, bereits kopierte Credentials werden dadurch jedoch nicht ungültig. Sie können weiterhin verwendet werden, bis sie rotiert oder widerrufen werden.

Auch die Analyse von CloudSEK beschreibt einen ähnlichen Verlauf: von einem betroffenen Artefakt über den Zugriff auf Secrets und die Erweiterung von Berechtigungen bis hin zu einer möglichen Kompromittierung nachgelagerter Systeme. [2] Genau dieser letzte Punkt verwandelt eine kurzfristige Paketkompromittierung in einen möglicherweise langfristigen Sicherheitsvorfall.

Was könnte exponiert worden sein?

Nach Angaben des FBI setzte TeamPCP im Rahmen seiner Kampagnen mehrere Malware-Familien ein, die speziell auf den Diebstahl von Zugangsdaten ausgerichtet waren. CanisterWorm wurde entwickelt, um Cloud-Zugriffstokens, API-Schlüssel und andere Authentifizierungsinformationen aus Umgebungen wie AWS, Google Cloud Platform und Microsoft Azure zu erfassen. SANDCLOCK zielte unter anderem auf AWS-Credentials, Kubernetes-ServiceAccount-Tokens und lokale Umgebungsvariablen. Das FBI nennt außerdem Mini Shai-Hulud, einen selbstreplizierenden npm-/PyPI-Supply-Chain-Wurm, sowie Miasma, eine verwandte Variante, die sich über Open-Source-Registries verbreiten und dabei Credentials sammeln sollte. [1]

Für Organisationen, die eine mögliche LiteLLM-Exposition untersuchen, reicht der potenzielle Schadensradius daher deutlich über einen einzelnen LLM-API-Key hinaus. Je nachdem, welche Informationen für den betroffenen Prozess zugänglich waren, könnten unter anderem folgende Daten exponiert worden sein:

  • Cloud-Credentials
  • GitHub- oder GitLab-Tokens
  • SSH-Schlüssel
  • Kubernetes-Service-Account-Tokens
  • Zugangsdaten zur Paketveröffentlichung
  • Datenbank-Credentials
  • Umgebungsvariablen
  • SaaS-Tokens
  • Container-Registry-Credentials
  • API-Schlüssel von KI-Anbietern

Auch CloudSEK identifiziert diese Credential-Klassen als potenziell zugängliche Informationen innerhalb betroffener CI/CD- und Entwicklungsumgebungen. [2] Dies ist insbesondere im Kontext von KI-Infrastrukturen relevant. Ein AI Gateway kann gleichzeitig mit Modellanbietern, Anwendungen, Datenbanken, Vector Stores, internen Services und agentenbasierten Tools verbunden sein. Eine Kompromittierung von Zugangsdaten im Umfeld eines solchen Gateways kann daher Systeme außerhalb der eigentlichen KI-Anwendung betreffen.

KI-Infrastrukturen werden zunehmend zu einem Bestandteil der Identity- und Access-Infrastruktur eines Unternehmens.

Nur den eigentlichen Modell-Endpunkt abzusichern, reicht nicht aus, wenn die umgebende Plattform über Zugangsdaten verfügt, mit denen auf Repositories, Cloud-Dienste, Datenbanken und andere Geschäftssysteme zugegriffen werden kann.

Vierzig Minuten können ein monatelanges Risiko erzeugen

Einer der auffälligsten Aspekte dieses Vorfalls ist der kurze Zeitraum, in dem die schädlichen LiteLLM-Versionen verfügbar waren. Etwa 40 Minuten mögen zunächst unbedeutend erscheinen – für automatisierte Software-Delivery-Systeme sind sie das jedoch keineswegs. CI/CD-Umgebungen arbeiten kontinuierlich: Abhängigkeiten können automatisch aufgelöst, Container neu gebaut, geplante Workflows ausgeführt und temporäre Runner erstellt werden, ohne dass ein Mensch eingreifen muss. Eine manipulierte Version muss daher nicht tagelang verfügbar sein, wenn Automatisierungssysteme sie innerhalb weniger Minuten herunterladen. [3]

Sobald Credentials kopiert wurden, macht das Löschen des betroffenen Pakets diese Zugangsdaten nicht ungültig. Genau deshalb legen sowohl die CloudSEK-Analyse als auch der FBI-Hinweis großen Wert auf eine Rotation von Zugangsdaten, anstatt lediglich zu überprüfen, ob die schädliche Version nicht mehr verfügbar ist. [1] [2]

Paketkompromittierung → Credential-Kompromittierung → Identitätskompromittierung

Der erste Schritt kann nur wenige Minuten dauern. Die daraus resultierende Credential- oder Identitätskompromittierung kann dagegen noch Wochen oder Monate später relevant sein.

Wie geht es weiter? Was Unternehmen jetzt tun sollten

Organisationen sollten die Kampagne aus zwei Perspektiven betrachten: Incident Investigation und langfristige Härtung der Software-Lieferkette. Für Unternehmen, die LiteLLM im relevanten Zeitraum eingesetzt haben, besteht die erste Aufgabe darin festzustellen, ob die Versionen 1.82.7 oder 1.82.8 heruntergeladen oder installiert wurden, Bestandteil eines Container-Builds waren oder transitiv über eine andere Abhängigkeit eingebunden wurden. LiteLLM weist darauf hin, dass insbesondere nicht gepinnte Installationen und transitive Abhängigkeiten dazu geführt haben könnten, dass betroffene Versionen automatisch bezogen wurden. [3]

Wenn eine Exposition möglich ist, sollten Organisationen feststellen, welche Credentials für den betroffenen Prozess zugänglich waren, und diese rotieren. Die Maßnahmen sollten dabei nicht auf einen LLM-API-Key beschränkt werden. Cloud-, Repository-, Registry-, Kubernetes-, Datenbank-, SaaS- und andere Secrets, die für einen betroffenen Runner zugänglich waren, sollten in den Untersuchungsumfang einbezogen werden. [1] Das FBI empfiehlt außerdem ausdrücklich, innerhalb von GitHub-Organisationen nach unerwarteten Repositories mit den Namen tpcp-docs oder docs-tpcp zu suchen, da diese im Zusammenhang mit der Kampagne beobachtet wurden. Für eine spätere Untersuchung sollten relevante CI/CD-Logs, Netzwerk-Logs, Informationen zu betroffenen Paketversionen sowie Informationen über potenziell exponierte Credentials aufbewahrt werden. [1]

Die langfristige Reaktion muss jedoch noch weiter gehen. Das FBI empfiehlt unter anderem: [1]

  • GitHub Actions an verifizierte Commit-SHA-Hashes statt an veränderbare beziehungsweise „floating“ Tags zu binden,
  • die Berechtigungen von CI/CD-Service-Accounts und Publishing-Tokens zu reduzieren,
  • phishingresistente MFA für Repository- und Registry-Publishing-Accounts einzusetzen,
  • Runtime-Verhaltensüberwachung für CI/CD-Runner einzuführen,
  • temporäre statt langlebiger Credentials zu verwenden,
  • Offline- und unveränderliche Backups von Repositories und Release-Artefakten vorzuhalten,
  • Integritätsprüfungen mit Hashes und Signaturen vor Veröffentlichung oder Deployment von Artefakten durchzuführen,
  • ein Inventar aller Drittanbieter-Services zu führen, die in Pipelines integriert sind,
  • die Berechtigungen dieser Drittanbieter-Services einzuschränken,
  • CI/CD-Logging zu zentralisieren und
  • Pipelines kontinuierlich auf ungewöhnliche Trigger, Privilegienerweiterungen und nicht autorisierte Uploads von Artefakten zu überwachen.

Eine besonders interessante Empfehlung des FBI ist die Einführung eines Mindestalters für Softwarepakete, wobei sieben Tage als Beispiel genannt werden. [1] Das Prinzip ist einfach: Produktionsumgebungen müssen eine Abhängigkeit nicht zwingend wenige Minuten nach deren Veröffentlichung in einem öffentlichen Repository übernehmen. Eine kontrollierte Verzögerung kann Maintainer, Sicherheitsanbieter und die Open-Source-Community in die Lage versetzen, schädliche Releases zu identifizieren, bevor sie sich in besonders sensible Umgebungen verbreiten.

Eine weitergehende Lehre für Security-Teams

Die TeamPCP-Kampagne macht ein grundlegendes Problem moderner Cybersicherheit sichtbar. Unternehmen haben erhebliche Ressourcen in den Schutz von Produktionsservern, Endgeräten und Netzwerkgrenzen investiert. Gleichzeitig haben Software-Pipelines im Hintergrund immer umfangreichere Privilegien erhalten. Ein Build Runner ist möglicherweise nur temporär aktiv, kann während seiner Lebensdauer jedoch Zugriff auf eine Reihe besonders sensibler Ressourcen besitzen:

  • Quellcode,
  • Signing-Infrastruktur,
  • Package Registries,
  • Cloud-Accounts,
  • Kubernetes-Cluster und
  • produktive Deployment-Credentials.

Damit wird CI/CD-Infrastruktur zu einem äußerst attraktiven Angriffsziel. Sicherheitsmaßnahmen müssen daher zunehmend der Identität und dem Workload folgen, anstatt davon auszugehen, dass eine Komponente sicher ist, nur weil sie aus einem vertrauenswürdigen Repository oder von einem vertrauenswürdigen Anbieter stammt. Die Empfehlungen des FBI spiegeln diesen Wandel wider: Least Privilege, kurzlebige Credentials, Artefaktintegrität, Inventarisierung von Drittanbietern, Verhaltensüberwachung und umfassendes Logging sind keine optionalen DevOps-Optimierungen mehr. Sie entwickeln sich zu grundlegenden Sicherheitskontrollen. [1]

Dasselbe Prinzip gilt für KI. AI Gateways, Agents und Orchestrierungsplattformen werden zunehmend zu stark vernetzten Komponenten innerhalb von Unternehmensinfrastrukturen. Ihre Sicherheit sollte deshalb nicht allein danach bewertet werden, was eine KI-Anwendung selbst tun kann, sondern auch danach, welche Systeme und Identitäten über die umgebende Infrastruktur erreichbar sind.

Entscheidend ist nicht nur, was eine KI-Anwendung selbst tun kann, sondern: Auf welche Identitäten, Systeme und Daten kann die umgebende KI-Infrastruktur zugreifen?

Exposition ist nicht dasselbe wie Kompromittierung

Eine letzte Unterscheidung ist bei der Diskussion dieses Vorfalls von entscheidender Bedeutung. Die Untersuchung von CloudSEK nennt mehr als 2.500 Organisationen und 434.000 CI/CD-Pipelines als potenziell exponiert, basierend auf einem rekonstruierten Exposure-Datensatz. Die Untersuchung weist jedoch ausdrücklich darauf hin, dass selbst eine Zuordnung mit hoher Konfidenz zu einer Organisation kein Beweis für eine erfolgreiche Kompromittierung, den tatsächlichen Diebstahl von Credentials oder deren Nutzung durch Angreifer ist. [2] Diese Unterscheidung sollte auch in jeder öffentlichen Diskussion über möglicherweise betroffene Organisationen beibehalten werden.

  • Potenzielle Exposition: Es liegen Hinweise vor, die eine Umgebung oder Pipeline mit einem betroffenen Artefakt beziehungsweise Angriffspfad in Verbindung bringen.
  • Wahrscheinliche Kompromittierung: Es liegen Hinweise darauf vor, dass Schadcode ausgeführt wurde oder ein Zugriff auf Credentials stattgefunden hat, eine Nutzung durch den Angreifer wurde jedoch noch nicht bestätigt.
  • Bestätigte Kompromittierung: Schädliche Ausführung, Datenexfiltration, nicht autorisierte Kontoaktivitäten oder die nachgewiesene Nutzung der erlangten Zugänge durch den Angreifer wurden unabhängig bestätigt.

CloudSEK verwendet in seiner Methodik eine im Wesentlichen vergleichbare Unterscheidung. [2] Dabei geht es nicht nur um Wortwahl. Diese Differenzierung verhindert, dass Erkenntnisse aus Threat Intelligence fälschlicherweise in Aussagen über bestätigte Sicherheitsverletzungen bei Organisationen umgewandelt werden, für die eine tatsächliche Kompromittierung nicht nachgewiesen wurde.

Wo NetUSE und Zscaler unterstützen können

Die Verhinderung von Software-Supply-Chain-Angriffen erfordert Sicherheitsmaßnahmen direkt innerhalb der Entwicklungspipeline. Dependency Pinning, Artefaktverifikation, sichere Publishing-Identitäten, Credential-Hygiene und Runtime Monitoring können nicht durch eine reine Netzwerk-Sicherheitsplattform ersetzt werden. Allerdings können zusätzliche Kontrollpunkte den möglichen Schadensradius erheblich reduzieren, wenn eine ursprünglich vertrauenswürdige Abhängigkeit tatsächlich kompromittiert wird.

NetUSE kann Unternehmen dabei unterstützen, solche Kontrollmechanismen mithilfe von Technologien wie Zscaler Zero Trust Cloud und Zscaler Internet Access (ZIA) zu planen und umzusetzen. [4] Die Workload-Security-Architektur von Zscaler kann identitätsbasierte Richtlinien und Segmentierung auf die Kommunikation von Workloads anwenden – für Ingress-, Egress- und East-West-Traffic. ZIA stellt darüber hinaus Inspektionsmöglichkeiten für Entwickler-Traffic bereit, einschließlich TLS-/SSL-Inspection sowie Sicherheitskontrollen für häufig verwendete Entwicklungswerkzeuge. [4] Solche Funktionen können dazu beitragen, laterale Bewegungen eines Angreifers einzuschränken, unerwartete ausgehende Kommunikation besser sichtbar zu machen und zusätzliche Möglichkeiten zu schaffen, eine Angriffskette zu unterbrechen, bevor gestohlene Credentials zu einer umfassenderen Kompromittierung der Unternehmensumgebung führen.

Das zentrale Ziel sollte nicht sein, sich darauf zu verlassen, dass ein einzelnes Produkt „Supply-Chain-Angriffe verhindert“. Stattdessen sollten mehrere voneinander unabhängige Kontroll- und Unterbrechungspunkte innerhalb der Angriffskette geschaffen werden.

Die Kompromittierung einer einzelnen vertrauenswürdigen Komponente darf nicht automatisch zu uneingeschränktem Zugriff auf den Rest der Organisation führen.

Quellen

[1] Federal Bureau of Investigation – „Cyber Criminal Group TeamPCP“, FLASH-20260702-01, 2. Juli 2026.
Der FBI-Hinweis dokumentiert die Taktiken von TeamPCP, das betroffene Software-Ökosystem, eingesetzte Malware, Indicators of Compromise und empfohlene Gegenmaßnahmen.
https://www.ic3.gov/CSA/2026/260702.pdf

[2] CloudSEK – „2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest AI Supply Chain Breach of 2026“, 11. August 2026.
Die Untersuchung liefert die rekonstruierten Exposure-Zahlen sowie eine Analyse der potenziellen nachgelagerten Auswirkungen.
https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines

[3] LiteLLM – „Security Update: Suspected Supply Chain Incident“, erstmals veröffentlicht am 24. März 2026 und anschließend aktualisiert.
LiteLLM beschreibt die kompromittierten Releases, den Zeitraum der Exposition, die vermutete Verbindung zum Trivy-Vorfall und die vom Projekt durchgeführten Gegenmaßnahmen.
https://docs.litellm.ai/blog/security-update-march-2026

[4] Zscaler – Zero Trust Cloud.
Produktinformationen zu den im Abschnitt über NetUSE und Zscaler beschriebenen Zero-Trust-, Workload- und Traffic-Security-Funktionen.
https://www.zscaler.com/products-and-solutions/zero-trust-cloud

📌 Die Beiträge auf dieser Website wurden – auf Basis der NetUSE-eigenen Wissendsdatenbank – in Teilen mithilfe künstlicher Intelligenz erstellt.

Veröffentlicht am

Veröffentlicht in