GitHub ist eine der weltweit größten Plattformen für das Hosting von Quellcode. Die Tatsache, dass ein Angriff über die IDE-Erweiterung eines Entwicklers erfolgte, sagt alles darüber aus, wo diese Risikokategorie steht. Die Angreifer gaben an, dass etwa 3 800 interne Repositorys abgezogen worden seien: Eine Zahl, die laut GitHub in groben Zügen mit den Ergebnissen seiner Untersuchung übereinstimmt.
Die wichtigere Erkenntnis geht jedoch über ein einzelnes Unternehmen oder eine einzelne manipulierte Erweiterung hinaus. Der Hackerangriff auf GitHub ist ein anschauliches Beispiel und eine Mahnung auf Vorstandsebene dafür, was geschieht, wenn Unternehmen IDE-Erweiterungen als Komfortsoftware statt als regulierte Software behandeln.
Details zum Datenleck bei GitHub (bisher)
Basierend auf , den öffentlichen Erklärungen von GitHub unter und sowie Branchenberichten unter ergibt sich folgende Abfolge:
- Ein Mitarbeitergerät wurde durch eine schädliche VS-Code-Erweiterung kompromittiert
- GitHub hat den betroffenen Endpunkt isoliert und die schädliche Version der Erweiterung entfernt
- Das Unternehmen leitete unverzüglich Maßnahmen zur Bewältigung des Vorfalls ein
- GitHub teilte mit, dass seine aktuelle Einschätzung darauf hindeutet, dass lediglich Daten aus GitHub-internen Repositorys abgezogen wurden.
- GitHub erklärte zudem, dass es zum Zeitpunkt der Bekanntgabe keine Hinweise darauf gab, dass Kundendaten, die außerhalb dieser internen Repositorys gespeichert waren, betroffen waren.
In einem Forum für Cyberkriminalität ist ein Bekennschreiben aufgetaucht. GitHub hat keinen Akteur namentlich genannt, und die Behauptung sollte als unbestätigt betrachtet werden.
Derzeit konzentriert sich der bekannte Anwendungsbereich auf interne Repositorien und nicht auf Kundenrepositorien. Für Sicherheits- und IT-Teams reicht die Tragweite dieses Vorfalls jedoch weit über GitHub selbst hinaus, da der Zugriffsweg so häufig vorkommt: ein vertrauenswürdiger Entwickler-Endpunkt, auf dem eine vertrauenswürdig erscheinende Erweiterung aus einem bekannten Ökosystem ausgeführt wird.
Warum dieser Vorfall mehr ist als nur eine schädliche Erweiterung
Die einfache Schlussfolgerung lautet, dass die Marktüberprüfung versagt hat. Die schwierigere Erkenntnis ist, dass IDE-Erweiterungen nach wie vor eine nicht verwaltete Software-Lieferkette darstellen. Sie werden installiert, aktualisiert und erhalten Zugriff auf Entwicklerebene, ohne dass die Kontrollmechanismen zur Anwendung kommen, die für fast jede andere Softwarekategorie in der Umgebung gelten.
Moderne Entwicklerumgebungen sind vollgepackt mit Komponenten, die außerhalb der herkömmlichen Workflows für Endgeräte- und Software-Governance liegen:
- IDE-Erweiterungen
- Paketmanager und Pakete
- Lokale KI-Programmierwerkzeuge
- CLI-Hilfsprogramme
- Sprachserver
- Plugins erstellen
- Repo-spezifische empfohlene Werkzeuge
- Maßgeschneiderte Dienstprogramme und Konfigurationen, die die Arbeitsabläufe von Entwicklern beschleunigen
Jeder dieser Punkte kann der erste Schritt zu einem unbefugten Zugriff sein. Sobald es auf einem Entwicklerrechner landet, erhält der Angreifer nicht nur Zugriff auf den Code, sondern auch auf alles, was dahinter steht.
Warum Endpunkte von Entwicklern so attraktive Angriffsziele sind
Ein Entwickler-Arbeitsplatz ist von außergewöhnlichem Wert, da er häufig eine hohe Konzentration an Zugriffsrechten aufweist.
Der Wirkungsbereich umfasst in der Regel mehr als nur den Quellcode
Eine kompromittierte Erweiterung könnte möglicherweise Zugriff auf Folgendes erhalten:
- Anmeldedaten für die Versionsverwaltung
- Cloud-Zugriffstoken
- SSH-Schlüssel
- Geheimnisse in Umgebungsdateien
- Lokale Konfiguration für interne Dienste
- Anmeldedaten für die Veröffentlichung von Paketen
- Zertifikate zur Codesignierung
- Konfiguration des KI-Assistenten oder Nutzung der KI
- Mit Entwicklerdiensten verknüpfte Browsersitzungen
Aus diesem Grund entwickeln sich Vorfälle wie dieser so schnell von einem „Endgeräteproblem“ zu einem unternehmensweiten Problem und werden zu einem globalen Problem, wenn der betroffene Entwickler weit verbreitete Software pflegt. Diese schädlichen Erweiterungen müssen nicht jedes System direkt kompromittieren. Schon das Sammeln einer Handvoll Zugangsdaten oder Schlüssel kann deren Zugriffsmöglichkeiten schneller erweitern, als dies bei einer herkömmlichen Malware-Infektion der Fall wäre.
Erweiterungen übernehmen die Vertrauenswürdigkeit der umgebenden Tools
Das tiefgreifendere Risiko ergibt sich aus Vertrauen und technischen Privilegien. Sicherheitsteams prüfen ausführbare Dateien, Installationsprogramme und Browser-Downloads oft genauer als die Aktualisierung oder Installation einer IDE-Erweiterung.
Entwickler sind es unterdessen gewohnt, Tools zu installieren, die die Geschwindigkeit und den Arbeitsablauf verbessern, wobei sie häufig mit Administratorrechten auf ihren Arbeitsplätzen arbeiten. Allein zwei Erweiterungen zum Thema KI erreichten 1,5 Millionen Installationen, bevor sie entdeckt wurden , während sie heimlich Quellcode abzugreifen. Diese Kombination schafft ideale Voraussetzungen für Missbrauch, insbesondere in Umgebungen, die bereits mit einer übermäßigen Anzahl von Cybersicherheits-Tools ( ) zu kämpfen haben.
IDE-Erweiterungen gelten mittlerweile als Angriffsfläche
Dies ist mittlerweile kein Randthema mehr. IDE-Erweiterungen stellen eine bekannte, offiziell anerkannte Angriffsfläche dar.
MITRE hat die IDE-Erweiterungen „ “ als ATT&CK-Technik unter März 2025 hinzugefügt. Das ist von Bedeutung, da es widerspiegelt, was Verteidiger und Angreifer bereits in der Praxis erkannt hatten: Erweiterungen sind Ausführungsumgebungen mit echtem, dauerhaftem Zugriff auf Entwicklersysteme.
Entdeckungen bösartiger Erweiterungen sind mittlerweile keine Seltenheit mehr. Laut ReversingLabs haben sich die Erkennungen bösartiger VS-Code-Dateien im „ 2025“ fast vervierfacht.
In den wichtigsten Extension-Ökosystemen stoßen Sicherheitsbeauftragte so regelmäßig auf vergiftete oder als Waffen eingesetzte Komponenten, dass Organisationen davon ausgehen sollten, dass es sich hierbei um eine dauerhafte Gefährdung handelt und nicht um einen vorübergehenden Anstieg.
Das Muster, auf das Sicherheitsteams achten sollten
Der Hackerangriff auf GitHub passt zudem zu einem sich wiederholenden Muster, das in den Ökosystemen der Entwicklertools in den Abschnitten 2025 und 2026 zu beobachten ist.
Das übliche Vorgehen sieht wie folgt aus:
| Bühne | Was geschieht |
|---|---|
| Erstzugang | Eine manipulierte Erweiterung, ein manipuliertes Paket oder ein manipuliertes Tool gelangt auf den Endpunkt eines Entwicklers |
| Erfassung von Zugangsdaten | Die schädliche Komponente erfasst Tokens, Schlüssel, Sitzungen und lokale Geheimnisse |
| Erweiterung von Berechtigungen | Angreifer nutzen diese Zugangsdaten, um Zugriff auf Repos, Cloud-Dienste, CI/CD-Systeme oder interne Systeme zu erlangen |
| Exfiltration oder Ausbreitung | Sie stehlen Daten, veröffentlichen kompromittierte Artefakte erneut oder erweitern den Zugriff über vertrauenswürdige Kanäle, beispielsweise durch die Veröffentlichung von Software mit Hintertüren oder Trojanern unter dem Zugriff des Entwicklers |
| Folge-Risiko | Gestohlener Code und gestohlene Geheimnisse führen auch nach der Isolierung des ursprünglichen Endpunkts zu einer sekundären Gefährdung |
Jedes Ereignis als einen für sich stehenden Sicherheitsverstoß zu betrachten, geht am Kern der Sache vorbei. Die Angriffsfläche ist die Entwicklerumgebung selbst.
Die meisten Organisationen sind sich ihrer eigenen Risiken nach wie vor nicht bewusst
An dieser Stelle wird das Gespräch unangenehm.
Viele Organisationen können Ihnen bestätigen:
- Wie viele Endgeräte verwalten sie?
- Wie viele kritische Sicherheitslücken sind derzeit offen?
- Wie viele Benutzer verfügen über Administratorrechte?
- Sogar, wie viele Versionen von wie vielen Varianten der IDE installiert sind
Weitaus weniger können diese Frage beantworten:
- Wie viele IDE-Erweiterungen sind auf den Entwicklerrechnern installiert?
- Von welchen Verlagen sie stammten
- Welche Erweiterungen haben sich diese Woche geändert?
- Auf welchen Endgeräten wurde in den letzten 24 Stunden eine neue Erweiterung installiert?
- Welche Entwickler nutzen IDEs, die mit offeneren Erweiterungsregistern verbunden sind?
Ohne diese Transparenz bleibt ein durch eine Erweiterung verursachter Sicherheitsverstoß unentdeckt, bis die Datenexfiltration bereits im Gange ist.
Taniums Sichtweise zum Risiko von IDE-Erweiterungen
Hier geht es nicht um eine einzige Erweiterung. Es handelt sich um eine Geschichte über die Hygiene bei Erweiterungen. IDE-Erweiterungen stellen eine Angriffsfläche dar, die ausgenutzt werden kann , und die jedes Unternehmen, das VS Code, Cursor, Windsurf, VSCodium oder ähnliche Tools einsetzt, in seiner eigenen Umgebung kontrollieren muss.
Marktplatzbetreiber übernehmen zwar im Laufe der Zeit immer mehr Aufgaben, doch die Verantwortung dafür, was innerhalb der Umgebung einer Organisation abläuft, liegt bei dieser Organisation.
Was Tanium in den Umgebungen seiner Kunden beobachtet:
- Auf 43 % der macOS-Endgeräte ist mindestens eine IDE installiert
- Auf 9 % der Windows-Endgeräte ist mindestens eine IDE installiert
- In einem durchschnittlichen Unternehmen sind 330 verschiedene VS Code-Erweiterungen installiert
Die meisten Sicherheitsteams können Ihnen sagen, wie viele Endgeräte sie haben. Nur sehr wenige können Ihnen sagen, wie viele Erweiterungen auf diesen Endgeräten ausgeführt werden, wer sie installiert hat oder auf welche Daten diese Erweiterungen zugreifen können. In dieser Lücke liegt das Risiko.
Erweiterungen werden innerhalb des Erweiterungshosts der IDE mit denselben Berechtigungen wie die IDE selbst ausgeführt, was in der Regel bedeutet, dass sie dieselben Berechtigungen wie der Entwickler besitzen. Ein moderner Entwickler-Rechner enthält Zugangsdaten für die Cloud, die Versionsverwaltung, interne Dienste und KI-Programmierassistenten. Eine einzige kompromittierte Erweiterung kann den ersten Zugang zu einer gesamten technischen Organisation ermöglichen. Der Explosionsradius umfasst alles, worauf der Entwickler Einfluss nehmen kann.
Unternehmen sollten IDE-Erweiterungen mit derselben Sorgfalt verwalten wie jede andere Software, die in die Umgebung integriert wird. In der Praxis bedeutet dies:
- Erfassung aller auf den Endgeräten der Entwickler installierten Erweiterungen
- Einführung eines Genehmigungsverfahrens für neue Erweiterungen: Erweiterungen von etablierten Anbietern wurden in 2026 wiederholt kompromittiert und sollten nicht als Ersatz für interne Kontrollmechanismen betrachtet werden
- Die Überwachung neuer oder geänderter Dateiendungen als Frühindikator für Risiken
- Besonderes Augenmerk gilt dabei IDEs wie Cursor, Windsurf und VSCodium, die je nach Version und Konfiguration möglicherweise Open VSX oder andere, nicht von Microsoft stammende Erweiterungsquellen nutzen, wobei das Governance-Modell offener ist und die Verantwortung für die Überprüfung stärker bei der Organisation liegt
- Die Anmeldedaten von Entwicklern in regelmäßigen Abständen zu wechseln und alle auf einem Entwicklerrechner gespeicherten Anmeldedaten als potenziell von Datenexfiltration bedroht zu betrachten
- Die Anwendung derselben strengen Standards in der Lieferkette auf IDE-Erweiterungen, wie sie etablierte Programme bereits auf npm- und PyPI-Pakete anwenden
Dies gilt nicht nur für VS Code. In derselben Woche, in der der Angriff auf GitHub stattfand, wurde in der Nx-Console-Erweiterung „ “ () Schadcode entdeckt, der auf Konfigurationsdateien von Claude Code sowie auf Anmeldedaten für AWS, GitHub, npm, Vault, Kubernetes und 1Password abzielte. Schädliche Versionen des Python-SDKs von Microsoft für „ “, „durabletask“, „“, „ “ und „“ wurden ebenfalls auf PyPI veröffentlicht:.
Es handelt sich hierbei um unterschiedliche Arten von Sicherheitslücken mit unterschiedlichen Kontrollmechanismen und Behebungsmaßnahmen, doch in beiden Fällen werden vertrauenswürdige Entwicklertools missbraucht. Die gleiche Risikokategorie trat gleichzeitig in mehreren Ökosystemen auf. Auch Erweiterungen für KI-Tools sind keine sicherere Kategorie: Die Erweiterung „ CVE-2025-52882 “ im Claude Code macht deutlich, dass sich diese Risikoklasse auch auf die Tools erstreckt, denen Entwickler am meisten vertrauen.
IDE-Erweiterungen stellen eine Angriffsfläche in der Lieferkette dar. Ihre Verwaltung erfordert Transparenz, Bestandserfassung, Änderungserkennung und Kontrollen über den gesamten Lebenszyklus hinweg.
Warum es bereits Warnzeichen gab
Dies ist keine neue Art von Bedrohung. Eine Untersuchung von „ “ und Koi Security, die unter Dezember 2025 dokumentiert ist, ergab, dass Millionen von Nutzern im Rahmen einer siebenjährigen Kampagne mit Browser-Erweiterungen ins Visier genommen wurden, bei der zuvor legitime Erweiterungen missbraucht wurden. Der Hackerangriff auf GitHub bestätigt ein bekanntes Muster und stellt kein neues dar.
Tanium hat bereits in „ 2026“ Leitlinien zum Umgang mit dieser Angriffsfläche veröffentlicht. Unternehmen, die bereits über Bestands- und Änderungsüberwachungssysteme verfügen, sind besser in der Lage, diese Art von Angriffen abzuwehren, bevor sie zu einem Sicherheitsvorfall führen.
Marktplätze werden ihre Überprüfungsverfahren im Laufe der Zeit wahrscheinlich verbessern, doch bereits heute muss Ihr Unternehmen wissen, welche Komponenten in seiner Umgebung ausgeführt werden, und ob es Änderungen schnell genug erkennen kann, um zu handeln, sobald eine kompromittierte Erweiterung entdeckt wird.
Was Sicherheitsteams jetzt tun sollten
Die richtige Reaktion ist weder Panik noch pauschale Verbote ohne ordnungsgemäßes Verfahren. Das ist eine disziplinierte Regierungsführung.
1. Erstellen Sie ein Erweiterungsverzeichnis
Beginnen Sie mit einer grundlegenden Frage: Was ist derzeit installiert?
Sie benötigen eine aktuelle Bestandsaufnahme folgender Punkte:
- Verwendete IDEs
- Erweiterungen nach Endpunkt
- Anbieter der Erweiterung
- Version
- Datum der Erstaufführung
- Datum der letzten Änderung
Ohne diese Informationen handeln Sie im Blindflug. Unternehmen, denen eine zeitnahe Bestandsaufnahme der Endgeräte sowie erweiterungsspezifische Telemetriedaten fehlen, werden Schwierigkeiten haben, selbst diese grundlegenden Fragen zu beantworten.
2. Behandeln Sie unerwartete Änderungen an Erweiterungen als Sicherheitsvorfall
Eine neu installierte oder aktualisierte Erweiterung auf einem Entwicklerrechner sollte nicht unsichtbar sein. In vielen Umgebungen ist dies ein deutlicheres Frühwarnsignal als eine Warnmeldung in einem späteren Stadium, die mit ungewöhnlichen Repo-Zugriffen in Verbindung steht. Eine Abstimmung mit dem Änderungsmanagement, genehmigten Erweiterungen und bekannten Entwickler-Baselines ist unerlässlich, um eine Alarmmüdigkeit zu vermeiden.
3. Ein Modell für die Prüfung und Genehmigung einführen
Der Status „Verifizierter Herausgeber“ sollte nicht als Ersatz für interne Kontrollmechanismen betrachtet werden. Dieses Signal kann dazu beitragen, dem Vertrauen Vorrang einzuräumen, doch es sollte das Gespräch nicht beenden.
4. Beachten Sie insbesondere alternative Erweiterungs-Ökosysteme
Unternehmen setzen zunehmend auf Tools, die auf Erweiterungsregistern basieren und von Grund auf offener konzipiert sind. Dies kann zwar die Flexibilität der Entwickler fördern, verlagert jedoch einen größeren Teil der Verantwortung für die Validierung auf das Unternehmen.
5. Entwicklerzugangsdaten rotieren und reduzieren
Gehen Sie davon aus, dass alles, was auf einem Entwicklerrechner gespeichert ist, potenziell erfasst werden kann. Dazu gehören alte Schlüssel, abgelaufene Sitzungen, Paket-Token und Geheimnisse der lokalen Umgebung, an deren Vorhandensein sich niemand mehr erinnert.
6. Erweitern Sie die Leitfäden zur Reaktion auf Vorfälle um Entwicklertools
Ihr IR-Prozess sollte ausdrücklich folgende Punkte abdecken:
- Schädliche Erweiterungen
- Manipulierte lokale Pakete
- Von Repo empfohlener Missbrauch von Werkzeugen
- Konfigurationen für KI-Programmierwerkzeuge
- Durch Erweiterungen verursachter Diebstahl von Zugangsdaten
Unternehmen, die ihre Notfallpläne für den Umgang mit Sicherheitsverletzungen im Bereich der Entwicklertools nicht aktualisiert haben, sind auf diesen Angriffsweg wahrscheinlich nicht ausreichend vorbereitet.
Wie ein praktischer Reaktionsrahmen aussieht
Das einheitliche Vorgehenskonzept für die Reaktion erstreckt sich auf drei Zeithorizonte: sofortige Eindämmung, kurzfristige Steuerung und kontinuierliche Einhaltung der Lieferkettenstruktur.
| Priorität | Maßnahme | Warum dies von Bedeutung ist |
|---|---|---|
| Sofort | Übersicht über IDEs und installierte Erweiterungen | Aktuelles Risiko ermitteln |
| Sofort | Kürzlich hinzugefügte oder geänderte Erweiterungen ermitteln | Finden Sie schnell vielversprechende Einstiegsmöglichkeiten |
| Sofort | Entwicklerzugangsdaten regelmäßig wechseln | Folgemissbrauch eindämmen |
| Kurzfristig | Workflows für die Genehmigung von Erweiterungen erstellen | Langsame, unsichere Installationen, ohne die Produktivität zu beeinträchtigen |
| Kurzfristig | Änderungsereignisse am Entwickler-Endpunkt überwachen | Frühe Anzeichen für Sicherheitsverletzungen erkennen |
| Laufend | Anwendung der Lieferketten-Governance auf Erweiterungen | Machen Sie dies zu einem strukturierten Prozess und nicht zu einer Ad-hoc-Reaktion |
Ein umfassenderes Programm zur Cyberhygiene von trägt dazu bei, dass diese Maßnahmen nachhaltig und nicht nur reaktiv umgesetzt werden.
Was man aus dem Hackerangriff auf GitHub nicht überbewerten sollte
Es gibt einige einfache Fehler, die Sie vermeiden sollten.
Reduzieren Sie die Geschichte nicht auf die Nennung der Quelle. Die Zuordnung mag sich im Laufe der Zeit klären, doch die operative Erkenntnis hängt nicht davon ab, einen Akteur namentlich zu benennen. Das Risiko ist der Angriffsweg.
Gehen Sie nicht davon aus, dass es Auswirkungen auf die Kunden gibt, nur weil es sich um ein vielbeachtetes Ereignis handelt. In einer öffentlichen Erklärung teilte GitHub mit, dass es keine Hinweise darauf gebe, dass Kundendaten, die außerhalb der betroffenen internen Repositorys gespeichert seien, beeinträchtigt worden seien. Dies sollte ernst genommen werden, wobei zu berücksichtigen ist, dass sich Ermittlungen weiterentwickeln.
Gehen Sie nicht davon aus, dass das Problem durch das Entfernen einer Erweiterung behoben wird. Wenn eine schädliche Erweiterung erst einmal identifiziert wurde, stellt sich vor allem die Frage, auf welche Daten sie während ihrer aktiven Zeit zugegriffen hat. Aus diesem Grund sind neben der Protokollierung von Identitäten, Repositorys, Cloud-Umgebungen und Netzwerken auch die kontinuierliche Endpunkt-Telemetrie und eine schnelle Eindämmung von Bedeutung. Vorbeugende Maßnahmen allein reichen nicht aus. Die Ermittler benötigen domänenübergreifende Beweise, um festzustellen, auf welche Ressourcen die Erweiterung zugegriffen hat und welche Anmeldedaten anschließend verwendet wurden.
Häufig gestellte Fragen zum Hackerangriff auf GitHub
Der Hackerangriff auf GitHub hat bei Sicherheitsteams eine Reihe von Fragen aufgeworfen. Hier sind die häufigsten.
Wurden bei dem Hackerangriff auf GitHub Kunden-Repositorys abgegriffen?
GitHub teilte mit, dass bei der aktuellen Überprüfung keine Hinweise auf Auswirkungen auf Kundendaten gefunden wurden, die außerhalb der GitHub-internen Repositorys gespeichert sind. Das ist der bisherige Stand der Dinge.
Welche Erweiterung hat den Sicherheitsvorfall bei GitHub verursacht?
GitHub hatte den Namen der Erweiterung zum Zeitpunkt seiner Stellungnahme noch nicht öffentlich bekannt gegeben. Für die meisten Organisationen ist es sinnvoller, alle installierten Erweiterungen zu überprüfen, anstatt auf einen bestimmten Namen zu warten.
Sollten Unternehmen auf die Verwendung von IDE-Erweiterungen verzichten?
Nein. Aber man sollte aufhören, sie als nicht verwaltete Komfortsoftware zu behandeln. Erweiterungen erfordern eine Bestandserfassung, eine Genehmigung, eine Änderungsüberwachung sowie Kontrollen während des gesamten Lebenszyklus.
Inwiefern ist dies relevant, wenn mein Team GitHub intern nicht nutzt?
Denn diese Lektion bezieht sich nicht speziell auf GitHub. Jedes Unternehmen, das über Entwickler-Endpunkte, Zugriff auf Quellcode, Cloud-Zugangsdaten und Workflows mit hohem Einsatz von Erweiterungen verfügt, ist denselben Risiken ausgesetzt.
Die wichtigste Erkenntnis
Der Hackerangriff auf GitHub ist nicht nur eine weitere Schlagzeile über einen Datenverstoß. Dies ist ein deutliches Zeichen dafür, dass die Steuerung von Entwicklertools zu einem zentralen Sicherheitsthema geworden ist.
Sicherheitsteams haben jahrelang daran gearbeitet, den Überblick über Server, Laptops, mobile Geräte und Cloud-Workloads zu verbessern. Nun ist dieselbe Disziplin auch für die Prozesse innerhalb der Entwicklerumgebung erforderlich, insbesondere für Erweiterungen, lokale Tools und die Zugangsdaten, auf die diese Tools zugreifen können.
Das ist die eigentliche Erkenntnis, die man aus diesem Vorfall ziehen kann. Die Herausforderung besteht nicht mehr darin, nachzuweisen, dass IDE-Erweiterungen missbraucht werden können. Die Herausforderung besteht darin, ob Unternehmen bereit sind, diese Risiken ebenso zu bewältigen wie die Risiken der Software-Lieferkette, die unter bereits beschrieben sind.
Falls Ihr Team nach dem GitHub-Hack überdenkt, wie es Entwickler-Endpunkte, den Softwarebestand und durch Erweiterungen bedingte Änderungen überwacht, sind Transparenz und Governance entscheidend, um dieses abstrakte Lieferkettenrisiko in ein Problem zu verwandeln, das Sicherheitsteams tatsächlich bewältigen können.
Fordern Sie eine Demo an unter , um zu erfahren, wie Tanium Unternehmen Transparenz über Endpunkte, Erweiterungen und Softwareänderungen in Ihrer gesamten Umgebung verschafft.
