Mini-Shai-Hulud-Lieferkettenangriff: Warum diese Kampagne die Denkweise von Verteidigern in Bezug auf vertrauenswürdige Software verändert

Der „Mini Shai-Hulud“-Angriff auf die Lieferkette ist nicht nur ein weiterer Vorfall im Zusammenhang mit bösartigen Paketen. Im Rahmen dieser Kampagne wurde die legitime Release-Infrastruktur missbraucht, darunter vertrauenswürdige Veröffentlichungsabläufe, mit Herkunftsnachweis signierte Pipelines und Entwicklerumgebungen. Diese Techniken sind besonders erfolgreich darin, böswillige Aktivitäten als normal erscheinen zu lassen, da der Code die meisten üblichen Verifizierungs- und Integritätsprüfungen besteht.

Laut dem „Postmortem“ zu TanStack auf der „ “ () wiesen die kompromittierten TanStack-Pakete gültige Herkunftsbescheinigungen auf, die von der projektinternen, vertrauenswürdigen Veröffentlichungspipeline „GitHub Actions“ erstellt worden waren. Selbst wenn die Herkunftsnachweise gültig waren, reichte die Herkunft allein nicht aus. Die Kampagne, die dem Cyberkriminellen „TeamPCP“ zugeschrieben wird, nutzte anschließend gestohlene Anmeldedaten von Herausgebern, um die Kampagne auf weitere Pakete auszuweiten.

Viele der Kontrollmaßnahmen, deren Einführung Sicherheitsteams Jahre gekostet hat, wurden entwickelt, um die Authentizität zu überprüfen, nicht jedoch die Absicht. Bei dieser Kampagne würden die Echtheitsprüfungen weiterhin erfolgreich verlaufen, obwohl die ausgelieferte Software manipuliert war.

Was geschah bei dem Angriff auf die Lieferkette von Mini Shai-Hulud?

Wie in der gesamten Sicherheitsgemeinschaft öffentlich berichtet wurde, betraf diese Kampagne mehr als 170 Pakete auf npm und PyPI und hatte Auswirkungen auf Ökosysteme mit einer enormen Reichweite in nachgelagerten Bereichen. Der Angriff richtete sich gegen weit verbreitete Entwicklertools und Bibliotheken, darunter Pakete im Zusammenhang mit Frontend-Frameworks, KI-SDKs, Tools zur Unternehmensautomatisierung und Suchinfrastruktur.

Im Großen und Ganzen funktionierte die Kampagne wie folgt:

• Die Angreifer haben einen vertrauenswürdigen Veröffentlichungspfad missbraucht, indem sie den Build-Prozess selbst kompromittierten.
• Die schädlichen Paketversionen wurden über legitime Arbeitsabläufe veröffentlicht und wiesen gültige Herkunftsbescheinigungen auf.
• Nach der Installation stahlen diese Pakete Anmeldedaten von Entwicklerrechnern und CI/CD-Runner.
• Die Malware nutzte diese gestohlenen Zugangsdaten anschließend, um weitere manipulierte Pakete zu veröffentlichen.
• Es wurden Persistenzmechanismen hinzugefügt, um Bereinigungsversuche zu überstehen und den Diebstahl von Anmeldedaten fortzusetzen.

Genau das hat der Kampagne ihren „Wurmcharakter“ verliehen. Jede neu kompromittierte Umgebung könnte zu einem Verbreitungsort für die nächste Angriffswelle werden.

Warum sich dieser Angriff von anderen unterscheidet

Es hat vertrauenswürdige Veröffentlichungsprozesse missbraucht, nicht nur die Vertrauenswürdigkeit von Paketen

Der Angreifer hat eine legitime Release-Pipeline missbraucht, anstatt lediglich offensichtliche Typosquats oder gefälschte Pakete zu veröffentlichen. Die böswilligen Veröffentlichungen wiesen weiterhin gültige Herkunftssignale auf, was deutlich macht, dass Authentizitätsprüfungen allein nicht ausreichten.

Wenn Ihre einzige oder wichtigste Kontrollmaßnahme darin besteht, zu prüfen, ob ein Paket aus der erwarteten Pipeline stammt, reicht das nicht aus. Die Pipeline diente als Angriffsvektor, und der „Mini Shai-Hulud“ würde bei typischen Überprüfungen, die feststellen und bestätigen, welche Pipeline ein Artefakt erstellt hat – nicht jedoch, ob der Inhalt des Artefakts beabsichtigt ist –, als legitim erscheinen.

Es verbreitete sich durch Identität, nicht nur durch Code

Diese Kampagne war stark identitätsorientiert und wurde in einem Umfeld durchgeführt, das durch eine extreme Ausbreitung von Geheimnissen gekennzeichnet war. Das Ausmaß der offengelegten Geheimnisse im Ökosystem bot dem Problem freien Lauf: GitGuardian meldete, dass im Jahr 2025 28,65 Millionen neue, fest codierte Geheimnisse auf GitHub öffentlich zugänglich waren.

Anstatt sich ausschließlich auf eine einmalige Ausführung zu verlassen, konzentrierte sich der Angriff darauf, Anmeldedaten auf den Rechnern der Entwickler und den CI/CD-Runner zu stehlen. Sobald die Angreifer über diese Identitäten verfügten, wurde die Softwareveröffentlichung selbst zum Verbreitungsmechanismus. Es war als Persistenzschicht für Entwicklerumgebungen konzipiert.

Im Rahmen der Kampagne wurden Persistenz-Hooks in Entwicklertools und lokalen Konfigurationspfaden installiert, darunter IDE-bezogene Verzeichnisse sowie KI-gestützte Programmierumgebungen. Da die Daten in der Datei „.claude/settings.json“ (ein SessionStart-Hook, der bei jeder Claude-Code-Sitzung erneut ausgeführt wird) und in der Datei „.vscode/tasks.json“ (wird beim Öffnen des Ordners automatisch ausgeführt) gespeichert sind, wird das Programm durch die alleinige Ausführung von „npm uninstall“ nicht entfernt.

So funktionierte die Angriffskette

Zwar variierten die Umsetzungen je nach Softwarepaket und Ökosystem, doch umfasste die Kampagne im Großen und Ganzen die folgenden Elemente: „ “, Kompromittierung der Lieferkette (), Diebstahl von Anmeldedaten sowie Selbstverbreitung.

Was die Malware zu stehlen versuchte

Berichte über den „Mini Shai-Hulud“-Angriff auf die Lieferkette deuten auf einen weitreichenden Erfassungsumfang hin. Das Ziel war nicht nur eine einzige Art von Wertmarke. Im Jahr Q3 2025 stellte Sonatype unter fest, , dass 37 % der bösartigen Open-Source-Pakete auf die Exfiltration von Daten abzielen, und diese Kampagne folgte demselben Muster. Es wurde entwickelt, um alles zu erfassen, was für die laterale Bewegung, die Persistenz und weitere Kompromittierungen von Nutzen ist.

Zu den üblichen Zielen gehörten:

• Anmeldedaten für Cloud-Anbieter
• Paketregistrierungs-Token
• Geheimnisse der CI/CD-Pipeline
• Git-Anmeldedaten und Token für die Quellcodeverwaltung
• Kubernetes-Konfigurationsdateien, Service-Account-Token sowie Anmeldedaten oder Token, die Zugriff auf Secret-Manager gewähren
• SSH-Schlüssel
• Lokale Entwicklerkonfigurationsdateien
• Einstellungen für KI-Entwicklertools
• Daten von Kryptowährungs-Wallets in verschiedenen Varianten

Einsatzteams sollten nicht nach dem Motto „das npm-Token wechseln und weitermachen“ vorgehen. Sollte ein mit Schadcode versehenes Paket in einer sensiblen Umgebung ausgeführt werden, dürfte der Wirkungsradius der Explosion wesentlich größer sein.

Anzeichen dafür, dass Sie möglicherweise betroffen sind

Sicherheitsteams, die mögliche Sicherheitslücken untersuchen, sollten sowohl die Abhängigkeiten als auch das Verhalten der Endgeräte berücksichtigen. Dies ist nicht nur ein Problem der Softwarekomposition.

Zeichen auf der Ebene der Abhängigkeiten

Beginnen Sie mit:

• Sperrdateien, die auf betroffene Versionen verweisen
• Installationsprotokolle für Pakete ab Version „ 11. Mai “
• Unerwartete Lebenszyklus-Skripte wie „preinstall“ oder „prepare“
• Verdächtige optionale Abhängigkeiten oder Git-basierte Paketverweise
• Ungewöhnlich große Tar-Dateien oder eingebettete verschleierte Dateien

Anzeichen auf Endgeräte- und Umgebungsebene

Suchen Sie auch nach:

• Unerwartete Änderungen in den Verzeichnissen „ .vscode/“, „ “ oder „.claude/“ sowie „ “
• Nicht autorisierte LaunchAgents oder systemd-Dienste auf Benutzerebene
• Neue Workflow-Dateien wurden zu den Repositories hinzugefügt
• Ausgehende Verbindungen zu verdächtiger Infrastruktur während der Installation des Pakets
• Veröffentlichungsereignisse für Pakete, die von den Betreuern nicht erkannt werden
• Verdächtige öffentliche Repositorys oder Commits, die mit gestohlenen Zugangsdaten erstellt wurden

Netzwerk- und Verhaltensmerkmale

Auch führende Vorfallberichte weisen auf redundante Exfiltrationskanäle hin. Das bedeutet, dass Sicherheitsverantwortliche nicht davon ausgehen sollten, dass das Blockieren einer Domain das Risiko beseitigt. Bitte beachten Sie:

• Ungewöhnliche API-Aufrufe an Code-Hosting-Plattformen
• Datenverkehr zu bekannten, von Angreifern kontrollierten Domains, öffentlichen Code-Hosting-APIs, die zur Datenexfiltration genutzt werden, Webhook-Endpunkten, Tor-bezogener Infrastruktur oder IPFS-Gateways, sofern diese festgestellt wurden
• Plötzlicher Zugriff auf Metadatendienste, lokale Tresore oder Token-Speicher
• Prozessverhalten, bei dem Umgebungsvariablen, Token-Speicher, die Shell-Verlaufsdaten, Anmeldedaten für Paketmanager oder andere Dateien mit vertraulichen Informationen auf Entwickler-Arbeitsplätzen und CI-Laufumgebungen ausgelesen werden

Wie Sie auf den „Mini Shai-Hulud“-Angriff auf die Lieferkette reagieren sollten

Dies ist ein Vorfall, der eine Koordinierung sowohl der Sicherheits- als auch der IT-Abläufe erfordert. Eine wirksame Reaktion folgt in der Regel einer strengen Abfolge.

Sofortmaßnahmen

• Stellen Sie fest, ob betroffene Paketversionen installiert waren.
• Isolieren Sie betroffene Entwickler-Arbeitsplätze und CI/CD-Umgebungen, bevor Sie die Zugangsdaten widerrufen.
• Stimmen Sie sich mit der IR-Abteilung ab, damit die Sperrung von Tokens keine bekannten schädlichen Abläufe auf noch verbundenen Hosts auslöst.
• Suchen Sie nach Persistenz-Artefakten, bevor Sie umfassende Änderungen vornehmen.
• Sichern Sie forensische Beweismittel, soweit dies möglich ist.
• Bitte prüfen Sie, ob Pakete, für die Sie verantwortlich sind, unerwartet erneut veröffentlicht wurden.

Warum die Reihenfolge wichtig ist

Die Malware verfügt über einen Notschalter. Ein Persistenz-Daemon (gh-token-monitor) fragt GitHub alle 60 Sekunden ab. Wenn eine Token-Sperrung festgestellt wird (HTTP- 40X -Antwort), führt das Programm den Befehl „rm -rf ~/“ aus – eine vollständige Löschung des Home-Verzeichnisses. Das bedeutet, dass Sicherheitsbeauftragte kompromittierte Umgebungen isolieren müssen, bevor sie Zugangsdaten widerrufen. Wenn Sie dies in der falschen Reihenfolge tun, wird die zerstörerische Nutzlast ausgelöst. Aus diesem Grund besteht eine besonnene Reaktion in diesem Fall nicht einfach darin, „jetzt alles zu widerrufen“. Es lautet:

• Zunächst isolieren
• Persistenz prüfen
• Bild (falls erforderlich)
• Anschließend führen Sie die Drehung und die Sanierungsmaßnahmen in einer kontrollierten Abfolge durch

Unternehmen, die in die Incident-Response-Lösung „ “ und das Security-Operations- investiert haben, sind besser in der Lage, diesen Ablauf über Endgeräte, Identitäten und forensische Arbeitsabläufe hinweg zu koordinieren.

Was dieser Vorfall über das Vertrauen in Software aussagt

Der „Mini Shai-Hulud“-Angriff auf die Lieferkette deckt einen blinden Fleck auf, den viele Organisationen nach wie vor haben: Sie setzen „signiert“, „offiziell“ oder „mit Herkunftsnachweis“ gleichbedeutend mit „sicher“.

Das sind nach wie vor wertvolle Hinweise. Doch für sich allein genommen reichen sie nicht aus.

Ein umfassenderes Modell umfasst nun alle folgenden Punkte:

• Überprüfung der Herkunft von Software
• Verzögerung der Einführung neu veröffentlichter Versionen
• Einschränkung der Ausführung von Skripten während der Installation
• Überwachung des Laufzeitverhaltens während der Kompilierung und Installation
• Reduzierung der Offenlegung vertraulicher Daten in CI/CD
• Entwickler-Endpunkte mit derselben Sorgfalt überwachen wie Server

Praktische Maßnahmen zur Absicherung, die Teams bereits jetzt umsetzen sollten

Die richtige langfristige Reaktion besteht nicht darin, aus Panik bestimmte Maßnahmen zu vermeiden. Es handelt sich um eine schichtweise Härtung.

Steuerelemente für die Erstellung und das Paketieren

All dies ist Teil einer umfassenderen Strategie zur Absicherung der Software-Lieferkette unter dem Motto „ “ ( ), die davon ausgeht, dass auch vertrauenswürdige Arbeitsabläufe missbraucht werden können.

Identitäts- und Geheimnismanagement

• Reduzieren Sie die Anzahl der langfristig gültigen Veröffentlichungszugangsdaten
• CI/CD-Identitäten streng abgrenzen
• Getrennte Berechtigungen für Build, Release und Bereitstellung
• Reduzieren Sie die Anzahl der auf den Laufinstanzen vorhandenen Geheimnisse auf ein Minimum
• Überprüfen Sie regelmäßig die Zugriffsrechte für die Veröffentlichung von Paketen sowie die Einstellungen zur Umgehung der Zwei-Faktor-Authentifizierung

Kontrollen für Endgeräte und Entwicklerumgebungen

• Überwachen Sie IDE-Konfigurationspfade und Start-Hooks
• Behandeln Sie Verzeichnisse mit Entwickler-Tools als sicherheitsrelevant und nicht als harmlos
• Bestandsaufnahme der Orte, an denen Cloud-Zugangsdaten und Registry-Token gespeichert sind
• Stellen Sie sicher, dass die persistenten Daten entfernt werden, nicht nur die Pakete gelöscht werden

Was eine effektive Reaktion der Lieferkette erfordert

Hierbei handelt es sich nicht lediglich um ein Problem mit einer Sicherheitslücke in einem Softwarepaket. Es handelt sich gleichzeitig um ein Problem im Zusammenhang mit Endpunkten, Identitäten und operativen Maßnahmen.

Fazit: Falls Entwickler oder automatisierte Build-Systeme in Ihrem Unternehmen betroffene Komponenten seit dem 11. Mai installiert haben, betrachten Sie diese Umgebungen als kompromittiert. Da die Verbreitung auf gestohlenen Identitäten beruhte, konnte jede kompromittierte Umgebung zu einem Verbreitungsort werden.

Dies ist der erste dokumentierte Fall eines sich selbst verbreitenden Angriffs über die Lieferkette, bei dem schädliche Pakete mit gültigen, dem Branchenstandard entsprechenden Herkunftsnachweisen erzeugt wurden. Die „Supply-Chain-Ebenen für Software-Artefakte“ (SLSA) funktionierten wie vorgesehen. Das Ökosystem ging davon aus, dass es mehr Probleme gelöst habe, als dies tatsächlich der Fall ist. Die Herkunftsangabe gibt Auskunft darüber, welche Pipeline ein Artefakt erstellt hat, nicht jedoch darüber, ob sich die Pipeline wie beabsichtigt verhalten hat.

Der Angreifer hat keine gefälschte Quittung erstellt. Sie brachen in die Küche ein und bereiteten auf dem Herd des Restaurants eine vergiftete Mahlzeit zu. Der Beleg war formal korrekt.

TeamPCP (auch bekannt unter den Bezeichnungen DeadCatx3, PCPcat, ShellForce und CipherForce) hat systematisch die Vertrauenskette selbst ins Visier genommen:

• März 2026: Trivy, ein Open-Source-Sicherheitsscanner – die Tools, die Sicherheitsverantwortliche nutzen (Microsoft)
• April 2026: Bitwarden CLI, ein Passwortmanager – Speicherung von Anmeldedaten
• Mai 2026: Der Wurm im npm/PyPI-Ökosystem – die übergeordnete Software-Lieferkette

Die Gruppe hat eine Partnerschaft mit Vect bekannt gegeben, einem „Ransomware-as-a-Service“-Betrieb (Unit 42). Zu den Zuordnungsindikatoren gehört ein „Kill Switch“ für die russische Ländereinstellung (Microsoft). Unabhängig davon, ob ein einzelner Akteur oder mehrere Partner beteiligt sind, deutet dieses Muster darauf hin, dass die Werkzeuge für Angriffe auf die Lieferkette innerhalb der mit Ransomware verbundenen Netzwerke immer ausgereifter werden.

Angriffe auf die Lieferkette sind häufig Vorläufer schwerwiegenderer Angriffe, darunter auch Ransomware, und nicht nur vereinzelte Vorfälle von Zugangsdaten-Diebstahl. Jüngste Kampagnen, bei denen vertrauenswürdige Softwaremarken wie Notepad++ und Download-Kanäle missbraucht wurden, unterstreichen, dass Softwarevertriebskanäle nach wie vor hochkarätige Ziele darstellen.

Für die Verteidiger lässt sich dies in drei Phasen und deren Zeitabläufe unterteilen:

1. Sofortige Maßnahmen, die Vorrang haben (Stunden)

• Überprüfen Sie die Lockfiles und CI-Protokolle auf betroffene Paketversionen, die seit dem 11. Mai installiert wurden.
• Sollte eine Exposition bestätigt werden, isolieren Sie die Umgebung, bevor Sie die Token widerrufen.
• Überprüfen Sie, ob Namen bekannter Persistenz-Beispiele wie „ “, „com.user.gh-token-monitor.plist“, „ “, „“, „gh-token-monitor.service“ und „“ vorhanden sind, und suchen Sie zudem nach funktional gleichwertigen, nicht autorisierten LaunchAgents, Benutzerdiensten, Cron-Jobs, Änderungen an der Shell-Startkonfiguration sowie Start-Hooks für IDEs und Tools.
• Überprüfen Sie die Verzeichnisse „.claude/“ und „.vscode/“ auf eingeschleuste Persistenz-Payloads
• Wechseln Sie alle Zugangsdaten, auf die von einer exponierten Umgebung aus zugegriffen werden kann, regelmäßig – nicht nur npm-Token.

2. Kurzfristige Maßnahmen (Tage)

• Prüfen Sie Abhängigkeitslisten, Lockfiles, CI-Protokolle, Caches, Runner-Images sowie alle generierten SBOMs für betroffene Pakete und Versionen, einschließlich Pakete, die mit Frontend-, Unternehmensautomatisierungs-, Such- und KI-Tools verbunden sind
• Sollten CI/CD-Runner beim Ausführen kompromittierter npm-Pakete über Anmeldedaten für die Veröffentlichung auf PyPI verfügen, sollten auch diese regelmäßig gewechselt werden
• Überprüfen Sie GitHub-Actions-Workflows, die „ “ („pull_request_target“ ) in Verbindung mit dem Auschecken nicht vertrauenswürdigen Codes, einem schreibgeschützten „“ („GITHUB_TOKEN“), offengelegten Geheimnissen oder der Wiederverwendung von Cache-Daten über Vertrauensgrenzen hinweg verwenden, da diese Kombinationen eine Kompromittierung des Workflows ermöglichen können.

3. Strategische Maßnahmen (in dieser Woche und darüber hinaus)

• Verzögerungen bei der Mindestveröffentlichungsfrist: Selbst eine Verzögerung von drei Tagen hätte einen Schutzpuffer gegen diese Kampagne geboten und stünde im Einklang mit den Leitlinien der CISA zur Abwehr schnell voranschreitender Angriffe auf die Lieferkette. Implementieren Sie dies über „min-release-age“ in pnpm oder setzen Sie es über eine Proxy-Registry bzw. eine Artifact-Policy-Engine für Paketmanager durch, die diese Funktion nicht nativ unterstützen.
• Legen Sie Abhängigkeiten auf bestimmte Versionen fest und setzen Sie Lockfiles durch, einschließlich der darin gespeicherten Integritäts-Hashes
• Legen Sie „ “ und „ignore-scripts=true“ fest: in .npmrc für CI-Umgebungen
• Betrachten Sie Angriffe auf die Lieferkette als Vorboten einer umfassenderen Kompromittierung des Unternehmens

Fragen, die sich Sicherheitsteams derzeit stellen sollten

Hat ein Entwickler oder eine CI-Umgebung betroffene Versionen nach dem 11. Mai installiert?

Sollte die Antwort „Ja“ lauten, gehen Sie von einer Kompromisslösung aus, bis das Gegenteil bewiesen ist.

Welche Geheimnisse waren zum Zeitpunkt der Ausführung in diesen Umgebungen vorhanden?

Konzentrieren Sie sich zunächst auf die Cloud, die Veröffentlichung von Paketen, die Quellcodeverwaltung und die Bereitstellungsidentitäten.

Wurden Repositorys oder Pakete, für die Sie verantwortlich sind, unerwartet geändert oder erneut veröffentlicht?

Diese Kampagne verbreitete sich von selbst. Ihre Umgebung könnte sowohl Opfer als auch Verbreitungsort gewesen sein. Sollte dies der Fall sein, wurden Ihre Anmeldedaten möglicherweise dazu missbraucht, andere zu kompromittieren.

Können Sie überprüfen, ob die Persistenz von den Endpunkten entfernt wurde?

Beschränken Sie sich nicht darauf, Node-Module zu löschen oder Lockfiles zurückzusetzen.

Mit Tanium lassen sich Risiken in der Lieferkette in konkrete Maßnahmen umsetzen

Tanium Guardian und das Dashboard „ : Mini Shai-Hulud Supply Chain Compromise“ bieten Sicherheits- und IT-Betriebsteams einen gemeinsamen Echtzeit-Überblick über den Status der Endgeräte über die gesamte Angriffsfläche der Entwickler hinweg:

• Helfen Sie dabei, Endpunkte zu identifizieren, auf denen möglicherweise betroffene npm- und PyPI-Pakete ausgeführt werden, und nutzen Sie dabei, sofern verfügbar, SBOM-Daten
• Erarbeiten Sie Anwendungsfälle für Surfacing-Maschinen mit Node.js, Python und KI-Tools wie dem installierten „Claude Code“
• Suchen Sie nach Indikatoren für Persistenz – LaunchAgents, Dienste auf Benutzerebene sowie Start-Hooks von IDEs oder Tools – mithilfe vorgefertigter Abfragen, die anhand von Echtzeit-Endpunkt-Telemetriedaten ausgeführt werden
• Überprüfen Sie den Bereinigungsstatus über alle CI/CD-Runner-Konfigurationen und Bereiche mit offengelegten Anmeldedaten hinweg, nicht nur in Paketregistern.

Unternehmen, bei denen der Tanium-Agent bereits installiert ist, können vorhandene Guardian-Inhalte nutzen, ohne dass zusätzliche Agent-Installationen erforderlich sind.

Die Maßnahmen sollten sich nicht auf die Überprüfung von Registern oder Repositorien beschränken. Entwickler-Endpunkte und CI/CD-Runner sind Teil des Angriffspfads. Mit Tanium können Sicherheits- und IT-Betriebsteams Sicherheitslücken bestätigen, die Beseitigung persistenter Bedrohungen überprüfen und Abhilfemaßnahmen koordinieren – und zwar direkt aus derselben Echtzeitansicht heraus, anstatt sich auf statische Build-Artefakte oder zeitverzögerte manuelle Überprüfungen verlassen zu müssen.

Häufig gestellte Fragen zum „Mini Shai-Hulud“-Angriff auf die Lieferkette

Angriffe auf die Lieferkette wie „Mini Shai-Hulud“ werfen Fragen auf, die weit über die üblichen Leitfäden zur Reaktion auf Vorfälle im Bereich „ “ hinausgehen.

Im Folgenden finden Sie einige häufig gestellte Fragen, die sich Sicherheitsteams zu dieser Kampagne stellen, sowie Informationen dazu, was dies für das Vertrauen in Software in Zukunft bedeutet.

Ist die Angaben zur Herkunft eines Pakets noch vertrauenswürdig?

Es kann zwar nach wie vor nützlich sein, sollte jedoch nicht als umfassendes Sicherheitssignal betrachtet werden. Die Herkunft gibt Aufschluss darüber, woher etwas stammt. Dies beweist nicht, dass die Pipeline nicht missbraucht wurde.

Sollten Teams gestohlene Token unverzüglich entziehen?

Nicht blindlings. Bei Vorfällen mit destruktiver Widerrufslogik sollten Isolierung und Untersuchung Vorrang haben, damit die ergriffenen Maßnahmen keinen weiteren Schaden verursachen.

Was ist die praktischste Präventionsmaßnahme, die den meisten Teams noch immer fehlt?

Eine Wartezeit vor der Nutzung neu veröffentlichter Paketversionen bleibt eine der einfachsten und wirksamsten Kontrollmaßnahmen, insbesondere angesichts sich rasch entwickelnder Ereignisse in der Lieferkette.

Warum ist diese Kampagne nicht nur für Entwickler von Bedeutung?

Denn Entwickler-Workstations und CI/CD-Runner verfügen häufig über Cloud-Zugangsdaten, Bereitstellungsrechte und Identitäten für die Veröffentlichung von Paketen. Ein Angriff auf diese Systeme kann sich schnell zu einem umfassenderen Vorfall im Unternehmen ausweiten.

Tanium wurde entwickelt, um bestehende Maßnahmen und Kontrollen im Bereich der Lieferkettensicherheit sowie des „ “ zu ergänzen, indem es die Erfassung von Paket-Expositionen, den Endpunktstatus, die Persistenzüberprüfung und die Verifizierung von Reaktionen miteinander verknüpft – sodass Sicherheits- und IT-Abteilungen auf der Grundlage desselben Echtzeit-Überblicks handeln können.
Vereinbaren Sie noch heute eine Demo unter , um zu erfahren, wie Tanium die Reaktion auf Lieferkettenvorfälle über Endpunkte und Identitäten hinweg koordiniert.