Future{hacks}: Fatale Dependencies: So bleibt Ihre Supply-Chain dauerhaft stabil

Dein Risiko steckt nicht nur im eigenen Code, es sitzt auch in Dependencies und Automatisierung. Manipulierte Pakete aus Registries wie npm, Zugangsdaten mit langer Gültigkeit und Releases ohne Herkunftsnachweis treffen Auslieferung, Vertrauen und Audits zugleich. Genau das sah man in den vergangenen Wochen. Wer jetzt Paketsignaturen überprüft, Zugriffsschlüssel nur kurz gültig hält und den Paketbezug kontrolliert, bleibt schnell und gewinnt Ruhe im Betrieb.

Worum es wirklich geht

Supply-Chain-Angriffe zielen auf Bausteine der Kette statt auf das Produkt selbst ab. Ein fremdes Paket aus einer Registry, eine Lücke in der Buildumgebung oder ein gestohlenes Veröffentlichungs-Token reicht aus, um Entwicklergeräte, CI-Pipelines oder den Release-Pfad zu kompromittieren. Wer diese Einfallstore kennt, kann priorisieren. Erst die Veröffentlichung absichern, dann den Bezug straffen, anschließend die Überwachung ausbauen.

Was gerade passiert

In mehreren Fällen wurden npm-Pakete so verändert, dass sie beim Installieren Schlüssel und Tokens einsammeln und in automatisierten Schritten in die Hände der Angreifer gelangen. Besonders im Fokus stehen Veröffentlichungen, die noch mit dauerhaft gültigen Tokens laufen. Deshalb schalten Anbieter auf Verfahren um, die sich bei jedem Publish neu ausweisen, etwa Trusted Publishing über OIDC. Die Abschaltung der alten „classic tokens“ ist im Fall von *npm* für den 9. Dezember 2025 terminiert, ein deutliches Signal in Richtung kurzlebiger, granularer Zugänge.

Zum Glück entdeckt die Open Source Community solche Probleme oft schnell und ziehen kompromittierte Versionen rasch zurück, wie das Nx-Team nach dem Angriff Ende August 2025 zeigte.

Hype vs. Realität

Der Hype behauptet, Open Source sei per se unsicher. Die Realität ist differenzierter. Offenheit macht Fehler sichtbarer und beschleunigt den Fix, solange Unternehmen sauber veröffentlichen und Dependencies bewusst von sicheren Quellen beziehen. Geschwindigkeit wird erst dann zum Vorteil, wenn die Herkunft eines Releases belegbar ist und die Supply-Chain kontrolliert bleibt.

Dein Wochenprogramm in sechs Schritten

Ziel ist ein Setup, das Tempo erhält und Angriffsflächen senkt.

1. Zugänge entschärfen

Veröffentlichungen sollten ohne langfristig gültigen Zugang auskommen. Man sollte wenn möglich auf Trusted Publishing mit OIDC umstellen. Dabei weist sich der veröffentlichende Job bei jeder neuen Veröffentlichung nachweisbar aus. Wenn Tokens unvermeidbar sind, dann mit kurzer Laufzeit und minimalen Rechten.

2. Herkunft nachweisbar machen

Jedem Release einen Provenance-Beleg (SLSA) mitgeben, also einen maschinenlesbaren Herkunftsnachweis mit Commit, Pipeline und Buildumgebung. Konsumentinnen können damit prüfen, ob ein Paket echt ist, bevor es in Produktion landet.

3. Registry kontrollieren

Produktionssysteme beziehen Pakete nicht direkt aus dem offenen Netz, sondern über einen Registry-Proxy mit Allowlist. Lockfiles sind verpflichtend, damit exakt die geprüften Versionen installiert werden. Post-Install-Skripte, die beim Installieren Code ausführen, bleiben in sensiblen Umgebungen standardmäßig gesperrt.

4. CI und Veröffentlichung härten

Builds laufen nur auf vertrauenswürdigen Workern mit minimalen Rechten. Passwörter und geheime Informationen kommen zur Laufzeit aus einem Secret Store, nicht aus Klartext-Dateien. Veröffentlicht wird ausschließlich aus einem freigegebenen Job, dessen Artefakte signiert sind.

5. Inventar und Alarm etablieren

Eine aktuelle Liste aller externen Pakete, SDKs und Build-Plugins hält den Überblick. Alarme schlagen an, wenn neue Maintainer-Rechte vergeben, neue Tokens erstellt oder ungewöhnliche Veröffentlichungen erkannt werden. Verdächtige Pakete wandern zuerst in eine sichere Testumgebung.

6. Quarantäne und Rückruf üben

Änderungen laufen zunächst in Staging. Releases starten mit einem kleinen Nutzeranteil als Canary und werden erst danach breit ausgerollt. Vorlagen für Rückruf, Schlüsseltausch, E-Mail an Kundschaft und Eintrag auf der Statusseite liegen bereit, damit im Ereignisfall Stunden genügen statt Tage zu verlieren.

Warum das Management steuern sollte

Da das Management meistens über einen Überblick der technologischen Landschaft der einzelnen Teams verfügt, macht es Sinn eine firmenweite Strategie zur Absicherung der Supply-Chain direkt auf dieser Ebene zu koordinieren.

Dabei gibt es verschiedene Schritte die man, auch oft unabhängig voneinander, setzen kann.

• Technologie-Stack konsolidieren: Wer in seiner Firma nicht auf allzu viele verschiedene Technologien setzt, kann die Supply-Chains anderer Programmiersprachen meistens ignorieren und muss sich somit nur um ein paar Angriffsvektoren kümmern. Dieser Schritt kann aber nicht in jeder Firma leicht umgesetzt werden.
• Zugriffsrechte/Zugriffsdauer minimieren: Grade in den meist automatisierten Schritten bei dem Bauen der Applikation oder der Veröffentlichung werden Schlüssel oder geheime Informationen verwendet. Damit diese möglichst wenig Schaden anrichten können müssen die verwendeten Schlüssel entweder a) nur kurz gültig sein oder auch b) häufig ausgetauscht (rotiert) werden. Auch sollen diese Schlüssel nur die für den Zweck notwendigen Rechte bekommen.
• Überwachung der eigenen Supply-Chain: Um schneller auf möglicherweise kompromittierte Pakete in den eigenen Dependencies reagieren zu können, ist es auch ratsam eine Überwachung dieser einzurichten. Dazu gibt es Tools, die sowohl Registries als auch aktuelle Exploit Meldungen beobachten und im Ernstfall auch alarmieren, sodass sie für die eigenen Projekte schnell reagieren können.
• Eigene Registries: Bei Inhouse-Produkten (o.Ä.) ist oft auch eine eigene Registry wünschenswert. Hierdurch kann man mögliche unverifizierten Builds ablehnen und damit auf diesem Level schon den Angriffsvektor schließen. Eine eigene Registry zu hosten ist allerdings häufig mit mehr Arbeit und auch Wartung verbunden.

Drei Zahlen, die den Punkt setzen

• Jede dritte Datenpanne hat heute eine Drittpartei im Spiel. Der Verizon DBIR 2025 spricht von einem verdoppelten Anteil gegenüber dem Vorjahr. Externe Analysen beziffern ihn für 2025 bei rund 30 Prozent. Das ist nicht Rand, das ist Zentrum.
• 4,44 Mio. US-Dollar im Schnitt pro Datenpanne. Der IBM Report 2025 nennt diesen globalen Durchschnitt und vermerkt einen Rückgang um 9 Prozent gegenüber 2024. Der Preis bleibt hoch genug, um Prozesse jetzt zu härten.
• Die Angriffsfläche wächst sichtbar. Sicherheitsanalysen berichten unter anderem von groß angelegten npm-Angriffen und zehntausenden kompromittierten oder neu angelegten Repositories in der jüngsten Welle. Das unterstreicht, wie attraktiv die Lieferkette für Angreifer geworden ist.

Kurz zu Regulierung und Prüfungen

NIS2 und DORA erwarten Sorgfalt in der Lieferkette. Prüfbare Herkunft, kontrollierter Bezug, Reaktionsfähigkeit. Wer Provenance, kurzlebige Zugänge und Quarantäne heute etabliert, steht morgen bei Audits und in der Kommunikation ruhiger da.

Unser Future{hacks} Fazit

Supply Chain ist kein Randthema für Entwickler, sondern ein Stück Betriebssicherung. Open Source bleibt ein Vorteil, weil Fehler schneller sichtbar werden und schneller gefixt werden. Voraussetzung ist ein Veröffentlichungsprozess, der Herkunft belegt, Zugänge kurz hält und den Bezug kontrolliert. Wer diese Schritte jetzt umsetzt, baut schneller und sauberer und bleibt im Vorfall handlungsfähig statt überrascht.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.