Das TanStack Query npm-Paket wurde durch ein kompromittiertes OpenAPI-Codegenerierungstool angegriffen.

Startseite » JavaScript » npm » TanStack Query: Angriff auf npm-Paket durch kompromittiertes OpenAPI-Codegenerierungstool

Für Teams, die TanStack Query als bevorzugtes npm-Paket zur Verwaltung des Serverzustands in React und anderen Frontend-Frameworks nutzen , zeigt ein aktueller Lieferkettenvorfall, wie schnell dieses Vertrauen erschüttert werden kann. Ein beliebtes Begleittool, das speziell zur Generierung typsicherer TanStack Query-Hooks aus OpenAPI-Schemas entwickelt wurde, wurde unbemerkt manipuliert und mit einer ausgeklügelten Malware-Payload in die npm-Registry hochgeladen.

Sicherheitsforscher beschreiben den Angriff als eine Kampagne im Stil von TeamPCP , die viele der inszenierten und technischen Muster früherer Vorfälle wiederverwendet. Diesmal liegt der Fokus jedoch eindeutig auf Entwicklern, die ihre Datenschicht mithilfe des Pakets @7nohe/openapi-react-query-codegen erstellen. Dieses Hilfsprogramm verspricht Zeitersparnis durch die automatische Generierung von TanStack-Query-Hooks anstelle des manuellen Schreibens von Boilerplate-Code.

Wie ein TanStack-Query-Codegenerator zu einem Malware-Verbreitungsmedium wurde

Das im Zentrum des Vorfalls stehende Paket @7nohe/openapi-react-query-codegen dient dazu, aus einer OpenAPI-Spezifikation vollständig typisierte Hooks zu generieren, die mit TanStack Query kompatibel sind. Mit über 150,000 Downloads pro Woche ist es für viele Teams, die TanStack Query zur Orchestrierung des Abrufs, Caching und der Synchronisierung von Backend-Daten in ihren React-basierten Frontends standardisieren, von entscheidender Bedeutung.

Laut der Analyse gelang es dem Angreifer, sowohl das npm-Paket als auch dessen GitHub-Repository zu kompromittieren . Der Angriff wurde durch Ausnutzung einer Schwachstelle in einem der GitHub-Actions-Workflows des Projekts ermöglicht. Dadurch schienen die manipulierten Builds weiterhin aus der legitimen CI-Pipeline zu stammen und wurden mit gültigen Herkunftsnachweisen ausgeliefert. Diese kryptografischen Nachweise, normalerweise ein starkes Vertrauenssignal für npm-Nutzer, wurden irreführend, sobald der Workflow selbst unter feindlicher Kontrolle stand.

Innerhalb eines kurzen Zeitraums von etwa zwanzig Minuten veröffentlichte der Angreifer zehn manipulierte Versionen des Pakets auf npm. Jede dieser Versionen enthielt Code, der während der Installation ausgeführt werden und eine mehrstufige Schadsoftware einschleusen sollte. Die betroffenen Versionen umfassen mehrere Neben- und Patch-Versionen, die nun alle als nicht vertrauenswürdig eingestuft werden sollten.

• @7nohe/openapi-react-query-codegen@0.5.4
• @7nohe/openapi-react-query-codegen@0.5.5
• @7nohe/openapi-react-query-codegen@1.6.3
• @7nohe/openapi-react-query-codegen@1.6.4
• @7nohe/openapi-react-query-codegen@2.2.1
• @7nohe/openapi-react-query-codegen@2.2.2
• @7nohe/openapi-react-query-codegen@3.0.3
• @7nohe/openapi-react-query-codegen@3.0.4
• @7nohe/openapi-react-query-codegen@0.0.0-365d4eb738d3146583431948d3ba6e27a32556be
• @7nohe/openapi-react-query-codegen@0.0.0-ec7876d6c917dad516ba69bbfafc948b834bf0ab

Alle diese Varianten verfolgen das gleiche Grundziel: die Popularität des Pakets unter TanStack Query-Benutzern auszunutzen, um während der npm-Installation Code auszuführen und diesen dann in der breiteren JavaScript-Lieferkette zu verbreiten.

Die „Trinitite“-Payload und ihre Tricks zur Ausführung während der Installation

Die Malware identifiziert sich mit dem augenzwinkernden Label „Trinitite: Gesponsert von Preview 2 Effects“, eine Anspielung auf das glasartige Material, das bei Atomtests entsteht. Frühere interne Skriptnamen wie is_it_this_simple.js Sie deuten zwar auf die lässige Haltung des Angreifers hin, doch die zugrundeliegende Technik ist alles andere als simpel.

Der primäre Ausführungsmechanismus hängt von einem ab binding.gyp Sandbox-FluchtIn normalen Node.js-Projekten dient binding.gyp zur Konfiguration nativer Add-ons, die von node-gyp kompiliert werden. Hier wird es jedoch für einen bestimmten Zweck missbraucht. Wenn npm auf eine binding.gyp-Datei stößt, wertet node-gyp deren Inhalt aus. conditions Der Angreifer schleust mithilfe von Python einen sorgfältig konstruierten Python-Ausdruck in dieses Feld ein und nutzt dabei die Klassenhierarchie von Python aus, um aus der erwarteten Sandbox auszubrechen und beliebige Shell-Befehle auszuführen.

Im kompromittierten Paket ist der Bedingungsausdruck stark verschleiert mit Unicode- und Hex-Escape-SequenzenNach der Dekodierung durchläuft es die internen Strukturen von Python. __subclasses__ Baum, um den zu finden catch_warnings Die Klasse nutzt dies als Dreh- und Angelpunkt, um zu erreichen __builtins__, importiert die os Modul und schließlich Aufrufe os.system() um die Hauptnutzlast mit Node zu starten. type Das Feld in binding.gyp ist hexadezimal kodiert als noneEs wird also kein echter nativer Build versucht; die Konfiguration dient lediglich dazu, einen einzelnen Shell-Befehl einzuschleusen.

Dieser Ansatz bedeutet, dass das Paket während der Installation bösartigen Code ausführen selbst wenn es keine explizite preinstall Das Skript ist in der package.json definiert. Allerdings nutzen nicht alle manipulierten Versionen genau diesen Trick. Zwei Vorabversionen verwenden einfachere Preinstall-Hooks: Einer davon führt ein Node-Skript namens aus. nu.js direkt, während ein anderer die Bun-Laufzeitumgebung über wget gerohrt zu bash und dann läuft das treffend benannte is_it_this_simple.jsSpätere Versionen kombinieren beide Methoden und liefern eine schädliche binding.gyp-Datei aus. und a preinstall Der Einstiegspunkt verweist aus Redundanzgründen auf dieselbe JavaScript-Hauptnutzlast.

Verschleierungsschichten und Sandbox-Umgehung in der Haupt-JavaScript-Nutzlast

Sobald der erste Hook ausgelöst wird, verlagert sich der Angriff auf eine große JavaScript-Datei namens 3FWCvzduYZg.js , die im Stammverzeichnis des npm-Pakets abgelegt wird. Mit einer Größe von etwa 5.4 MB und einer auf eine einzige Zeile minimierten Datei ist das Skript auf den ersten Blick so undurchsichtig wie möglich gestaltet. Eine genauere Analyse zeigt jedoch, dass es durch mehrere separate Verschlüsselungs- und Verschleierungsebenen geschützt ist.

Die äußerste Schicht besteht aus einem 1.6‐Millionen‐Elemente Ganzzahl-ArrayDie Entschlüsselung erfolgt durch eine einfache XOR-Verknüpfung mit der Konstanten 29. Diese Entschlüsselung erzeugt ein zweites Skript, dessen Aufgabe es ist, die Bun-Laufzeitumgebung im Hintergrund abzurufen und unter einem temporären Dateinamen zu speichern. trinnyyyy-XXXXX Das Muster wird im temporären Verzeichnis des Systems abgelegt, und anschließend wird mit Bun die eigentliche Kernnutzlast ausgeführt. Der Kern selbst wird mit AES-128-GCM verschlüsselt und anschließend zusätzlich zu Standard-JavaScript-Verschleierungstechniken, wie sie beispielsweise in gängigen Tools wie obfuscator.io verwendet werden, durch benutzerdefinierte Verschlüsselungsverfahren geleitet.

Die vollständig entpackte, vielschichtige Payload offenbart eine Vielzahl von Funktionen: einen Credential-Harvester, der auf ein breites Spektrum von Cloud- und Entwicklerplattformen abzielt, eine Wurmkomponente, die die Infektion auf neue Ziele ausbreiten kann, und einen zerstörerischen Befehlskanal. Bevor eine dieser Komponenten aktiviert wird, führt das Skript eine Reihe von Umgebungsprüfungen durch, um Sandboxes und Sicherheitstools zu umgehen, und beendet sich stillschweigend, sobald bestimmte Bedingungen erfüllt sind.

Zu den Prüfungen gehören Gebietsschema-, Umgebungs- und Dateisystemindikatoren Diese Malware wird häufig mit Forschungsumgebungen in Verbindung gebracht. Sie bricht ab, wenn die Systemsprache Russisch ist, Verzeichnisse von Endpoint-Security-Produkten wie CrowdStrike, SentinelOne oder Carbon Black vorhanden sind, das aktuelle Arbeitsverzeichnis mit Pfaden bekannter Supply-Chain-Scanning-Tools übereinstimmt oder Umgebungsvariablen gefälschte Anmeldeinformationen für Sicherheitsscanner enthalten. Sie prüft außerdem die GITHUB_REPOSITORY_OWNER und das Vorhandensein von Härtungstools wie beispielsweise StepSecurity harden-runnerund dabei GitHub-Konten zu meiden, die bekanntermaßen Sicherheitsforschern gehören.

Was die Malware aus TanStack-Abfrage-basierten Entwicklungsumgebungen stiehlt

Sobald die Umgebungsprüfungen erfolgreich abgeschlossen sind, beginnt die Malware, Anmeldeinformationen in großem Umfang zu sammeln. Obwohl das ursprüngliche Paket als Hilfsmittel für TanStack Query-Nutzer dargestellt wird, reicht das tatsächliche Angriffsfeld weit über eine einzelne Bibliothek hinaus und berührt nahezu jede Ebene der Toolchain und Cloud-Architektur moderner JavaScript-Entwickler.

Auf Entwicklerseite scannt die Payload nach GitHub persönliche Zugriffstoken in verschiedenen Formaten, einschließlich klassischer Token, die mit beginnen gho or ghp und neuere, feinkörnige Token, die mit github_pat_Bei GitHub Actions-Runnern werden außerdem OpenID Connect-Token über die dokumentierte Methode angefordert. ACTIONS_ID_TOKEN_REQUEST_TOKEN und ACTIONS_ID_TOKEN_REQUEST_URL Umgebungsvariablen, die dem Angreifer die Möglichkeit geben, Workload-Identitäten anstelle von statischen Geheimnissen zu erlangen.

Das Skript wendet sich dann den gängigen Sprachregistern zu. Es liest: npm-, PyPI- und RubyGems-Tokens aus Konfigurationsdateien wie ~/.npmrc, Scans für zusätzliche projektlokale .npmrc Dateien und Versuche, gefundene npm-Bearer-Token durch Aufruf der /-/whoami Endpunkt im öffentlichen Register. Ähnliche Muster werden für PyPI und RubyGems verwendet, um Authentifizierungsdaten zu extrahieren und zu bestätigen, dass jedes Token erfolgreich mit dem jeweiligen Register kommunizieren kann, bevor es exfiltriert wird.

Der Cloud-Fußabdruck ist sogar noch größer. Auf Amazon Web Services listet die Malware Umgebungsvariablen auf wie beispielsweise AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY, analysiert ~/.aws/credentials und ~/.aws/configund fragt den EC2-Instanzmetadatendienst ab unter 169.254.169.254Es bevorzugt IMDSv2, greift aber bei Bedarf darauf zurück. Bei Container-Workloads kommuniziert es mit dem ECS-Metadatenendpunkt unter 169.254.170.2Alle wiederhergestellten Anmeldeinformationen oder temporären Token werden getestet gegen sts:GetCallerIdentity um die Gültigkeit zu bestätigen, bevor die Daten zur Exfiltration in die Warteschlange gestellt werden.

Eine vergleichbare Logik ist auch für andere Cloud-Anbieter vorhanden. Das Skript kann Daten sammeln. Azure-Clientanmeldeinformationen und verwaltete Identitäteneinschließlich AZURE_CLIENT_ID, AZURE_CLIENT_SECRET und AZURE_TENANT_IDund kann nach erfolgreicher Authentifizierung auf Azure Key Vault, Azure Resource Manager und Microsoft Graph zugreifen. Für Google Cloud wird gesucht nach GOOGLE_APPLICATION_CREDENTIALS Dateien, fragt den GCP-Metadatenserver ab unter metadata.google.internal und verwendet, wenn möglich, die generierten Token, um Google Secret Manager aufzurufen. HashiCorp Vault-Bereitstellungen sind ebenfalls enthalten: Die Payload sucht über Umgebungsvariablen und Token-Dateien nach Vault-Adressen und -Token und prüft anschließend die HTTP-API von Vault, um die zugänglichen Geheimnisse aufzulisten.

Über Cloud-IAM hinaus führt die Malware umfangreiche Aktionen durch. Dateisystemdurchsuchung mit über 150 Glob-MusternEs sucht nach privaten SSH-Schlüsseln, Docker-Konfigurationen, .env Dateien, Git-Anmeldeinformationsspeicher, .npmrc und .pypirc Es werden Dateien, Terraform- und Cargo-Zugangsdaten, Shell-Verlaufsdateien, Daten von Kryptowährungs-Wallets und Konfigurationsverzeichnisse für weit verbreitete Messaging-Apps wie Signal, Telegram Desktop, Discord, Slack und Element durchsucht. Außerdem werden VPN-Konfigurationsdateien von Diensten wie NordVPN, ProtonVPN, CyberGhost, PIA und anderen sowie Tokens und Domains für Binär-Repository-Manager wie JFrog Artifactory überprüft.

Datenexfiltration über GitHub-Repos und die „Miau Miau Miau“-Commits

Nachdem die Schadsoftware all diese Geheimnisse gesammelt hat, benötigt sie einen Ort, um sie zu senden. Anstatt eine feste Command-and-Control-Domain zu verwenden, die leicht blockiert werden könnte, nutzen die Angreifer öffentliche GitHub-Repositories als Exfiltrationskanal und mischen die gestohlenen Daten in den normalen Datenverkehr der Entwickler ein.

Die Schadsoftware durchsucht zunächst die öffentliche Commit-Historie von GitHub nach Nachrichten, die einem bestimmten Muster entsprechen und ein verschlüsseltes Token im Klartext enthalten. Dabei wird eine Formulierung verwendet, die Benutzer für den Widerruf des Tokens rügt. Sobald ein solcher Commit gefunden wird, entschlüsselt die Schadsoftware das eingebettete Token und erstellt mit dem zugehörigen Konto ein neues Repository, in dem die gestohlenen Daten gespeichert werden. Durch diese indirekte Vorgehensweise werden die Zugangsdaten eines Opfers in Repositories gespeichert, die technisch gesehen einem anderen GitHub-Benutzer gehören. Dadurch wird es schwieriger, das Netzwerk kompromittierter Repositories auf einen einzelnen Angreifer zurückzuführen.

Die neu erstellten Repositories haben skurrile, automatisch generierte Namen zusammengesetzt aus zwei Charakteren aus der Touhou Project-Reihe und einer Zufallszahl, was zu Kombinationen wie diesen führt cirno-marisa-74291 or reimu-kogasa-12048Ihre Beschreibungen enthalten dieselbe Phrase „Trinitite: Gesponsert von Preview 2 Effects“, die auch in der Payload zu finden ist. Dies ist eines der wenigen eindeutigen Erkennungsmerkmale für die Verteidiger, die versuchen, diese Repositories in großem Umfang zu identifizieren.

Gestohlene Zugangsdaten werden als verschlüsselte JSON-Dateien in einem results/ Verzeichnis, wobei Dateinamen verwendet werden, die mit doubletrinnys- gefolgt von einem Zähler und einem Zeitstempel. Jede Datei enthält einen envelope Feld, das das verschlüsselte Datenpaket enthält, und ein key Das Feld enthält den Verschlüsselungsschlüssel selbst, der zusätzlich mit dem öffentlichen RSA-Schlüssel des Angreifers verschlüsselt ist. Auf den ersten Blick sehen diese Daten wie beliebige verschlüsselte Datenblöcke aus. Nur jemand mit dem passenden privaten Schlüssel kann den Vorgang umkehren. Selbst wenn die entsprechenden Repositories gefunden werden, … Die eigentlichen Geheimnisse bleiben für Dritte undurchsichtig.Commit-Nachrichten sind typischerweise kurz und flapsig, wobei Zeichenketten wie „miau miau miau“ wiederholt verwendet werden.

Wurmartige Ausbreitung in andere npm-Pakete und GitHub-Projekte

Einer der besorgniserregendsten Aspekte der Trinitite-Kampagne ist ihre Fähigkeit, gestohlene Tokens wiederzuverwenden, um weitere Pakete und Repositories zu kompromittieren . Anstatt sich auf das ursprüngliche TanStack Query-Codegeneratorpaket zu beschränken, verhält sich die Malware wie ein Wurm und sucht systematisch nach Wegen zur Verbreitung.

Mit einem gültigen npm-Token fragt die Payload die npm-API ab, um alle mit dem Konto verknüpften Token aufzulisten und das privilegierteste Veröffentlichungstoken auszuwählen. Anschließend sucht sie nach allen Paketen dieses Maintainers, lädt die jeweiligen Tarballs herunter und fügt die gleiche `binding.gyp`-Sandbox-Escape-Datei sowie die Haupt-Payload-Datei in den Paketinhalt ein. Nach diesen Änderungen veröffentlicht sie eine neue Version auf npm unter dem Namen des rechtmäßigen Maintainers und verwandelt so vertrauenswürdige Pakete in neue Infektionsvektoren . Ein ähnliches Verhalten wird für PyPI und RubyGems über deren jeweilige Upload-Endpunkte implementiert, wobei die TLS-Zertifikatsprüfung in ausgehenden Anfragen deaktiviert ist, um clientseitige Pinning-Probleme zu vermeiden.

GitHub-Repositories werden auf vergleichbare Weise behandelt. Sobald die Malware ein GitHub-Token mit ausreichendem Umfang erlangt hat, listet sie alle zugänglichen Repositorys und Branches auf und überspringt dabei einige bekannte Automatisierungsbranches, wie beispielsweise solche mit dem Präfix „--automatisierungs-branch“. release/, dependabot/, renovate/ or copilot/Für die übrigen Branches werden sorgfältig ausgewählte Dateien committet, die sowohl als Hintertüren als auch als Schnittstellen zu modernen Entwicklungswerkzeugen dienen.

Darunter sind Hintertürige VS Code- und Claude-Konfigurationsdateieneinschließlich .vscode/tasks.json, .claude/settings.json und Skripte wie setup.mjs Diese werden ausgeführt, wenn ein Entwickler ein Projekt in bestimmten KI-gestützten Editoren öffnet. Die Malware platziert außerdem eine gefälschte Datei. .github/workflows/codeql.yml Ein Workflow, der als Sicherheitsscan getarnt ist und gleichzeitig einen weiteren Kanal zur Codeausführung innerhalb der CI-Pipeline bietet. Zusätzliche Dateien zielen auf andere Editoren und Tools wie Gemini, Cursor und verschiedene Code-Assistenten ab und helfen dem Angreifer so, sich dauerhaft an den jeweiligen Arbeitsplätzen der Entwickler aufzuhalten.

Jeder dieser Commits wurde unter dem Namen verfasst. github-actions Identität, mit Meldungen, die wie routinemäßige Wartungsarbeiten aussehen, wie z. B. „Aufgabe: Abhängigkeiten aktualisieren“ und einem entsprechenden Hinweis. skip-checks:true um die erforderlichen Prüfungen zu umgehen. Für ein vielbeschäftigtes Team, das Commit-Logs nur flüchtig überfliegt, können diese Änderungen leicht verwechselt werden mit … harmlose Automatisierungsaktualisierungen.

Indikatoren für Kompromisse bei Teams, die TanStack Query-Tools verwenden

Für Organisationen, die auf TanStack Query setzen und @7nohe/openapi-react-query-codegen in ihren Workflow integriert haben, beginnt die Identifizierung potenzieller Sicherheitslücken mit Versions- und Dateiindikatoren, die von mehreren Quellen hervorgehoben wurden. Diese Hinweise können helfen, die Projekte zu identifizieren, die während der Installation möglicherweise den kompromittierten Code ausgeführt haben.

Jegliche Verwendung der zuvor genannten betroffenen Versionen von @7nohe/openapi-react-query-codegen sollte als verdächtig eingestuft werden, insbesondere wenn die Builds auf gemeinsam genutzter CI-Infrastruktur oder auf Entwickler-Laptops mit Zugriff auf sensible Zugangsdaten durchgeführt wurden. Sicherheitsteams wird empfohlen, Sperrdateien, package.json-Verläufe und Build-Logs zu überprüfen, um festzustellen, ob diese Releases jemals in Produktions- oder Staging-Umgebungen verwendet wurden.

Ein wichtiges Indiz für eine Kompromittierung ist das Vorhandensein der Datei 3FWCvzduYZg.js im Paketverzeichnis . Die Ermittler haben mehrere SHA-256-Hashes katalogisiert, die mit verschiedenen verschleierten Versionen dieses Skripts verknüpft sind und alle auf dieselbe zugrunde liegende Funktionalität verweisen:

• 8e5d1af68ca340ae0c6e8132cb00c686ec2d60502c1994d94ce353d1472ad5a3
• b49afb7dba04cd99b357ce7c652c823a3707f28e130bd5c6645851a7adc030d6
• 59370c67b54a0ccaedd265e2356f04540b2fba1e1845300ef6de4d5437d99380
• 778d6f0058045d6a2ab9a7e1d3e3be8e7e6b4d9cc217d13949bf1dfbab759a7c
• b24d121667f21f492cb9db34fbfd515d5922a8dd30b9c45215c7220abbb10ca8
• e1f1162ece9a6e6ea21a20399cbf31c563a8149d433a68711f4223870c203d5a
• b6012b2ff87f08f93ee53921c48db907ddbcf5461b03bb988083b01a36886237
• 709af2fdeb50324229e94c44c679a0fab18bd8e17d3864405989c526cbb63ad8

Darüber hinaus erstellen viele infizierte Hosts temporäre Verzeichnisse, deren Namen mit einem bestimmten Präfix beginnen. trinnyyyy- Darauf folgt eine kurze Zeichenfolge aus zufälligen alphanumerischen Zeichen im temporären Systemordner. Dieses Muster allein beweist zwar noch keine Kompromittierung, doch in Kombination mit einer verdächtigen binding.gyp-Datei und einem der bekannten Payload-Hashes erhöht es die Wahrscheinlichkeit erheblich, dass die Trinitite-Malware auf diesem System ausgeführt wurde.

Einige Sicherheitsanbieter haben diese Indikatoren bereits in ihre Erkennungssysteme integriert. Plattformen für Entwicklerwerkzeuge und Lieferkettensicherheit kennzeichnen beispielsweise jedes Repository oder Projekt, das die betroffenen Versionen importiert, als kritische Malware-Probleme und stufen es oft mit der höchsten Priorität ein, um eine sofortige Untersuchung zu veranlassen. Teams werden angehalten, unternehmensweit erneute Scans durchzuführen, insbesondere in Umgebungen, in denen TanStack Query eine zentrale Rolle in der Anwendungsarchitektur spielt und Codegenerierungstools weit verbreitet sind.

Es entstehen spezialisierte Tools und Open-Source-Dienstprogramme, die vor npm, yarn, pnpm und verwandten Paketmanagern eingesetzt werden und die Paketversionen vor der Installation anhand kuratierter Informationsfeeds überprüfen. Ziel ist es, schädliche oder verdächtige Pakete, insbesondere solche, die mit Vorfällen wie diesem in Verbindung stehen, abzufangen, bevor sie überhaupt in die Systeme gelangen. node_moduleswodurch das Risiko verringert wird, dass eine kompromittierte Hilfsbibliothek indirekt offenlegen kann TanStack-Abfrageanwendungen und die dazugehörige Infrastruktur.

Für Entwicklungsteams verdeutlicht dieser Vorfall, wie ein scheinbar harmloses Hilfspaket – das lediglich typisierte Hooks für TanStack Query aus einer OpenAPI-Spezifikation generiert – zu einem gefährlichen Einfallstor werden kann, wenn seine CI-Pipeline und sein Vertriebskanal manipuliert werden. Die Abwehrmaßnahmen müssen sich daher nicht mehr nur auf die Hauptanwendungsabhängigkeiten beschränken, sondern auch die Generatoren, CLIs und Automatisierungsskripte umfassen, die die tägliche Nutzung dieser Abhängigkeiten unbemerkt beeinflussen.