Mehr Sicherheitsrisiken in kürzerer Zeit

Der Angriff auf TanStack ist interessant, weil er nicht in das alte Bild vom gestohlenen Passwort passt. Lange wurde Software-Supply-Chain-Sicherheit so erzählt: Ein Maintainer klickt auf eine Phishing-Mail, ein npm-Token wird gestohlen, eine manipulierte Version landet im Registry, alle anderen müssen schnell patchen. Das passiert weiterhin. Aber der spannendere Teil moderner Angriffe liegt an einer anderen Stelle: in der Infrastruktur, die eigentlich Vertrauen herstellen soll.

Bei TanStack wurde öffentlich beschrieben, dass kompromittierte Paketversionen über den normalen Release-Kontext verteilt wurden. Der Angriff nutzte die Build- und Veröffentlichungslogik selbst als Hebel. Das ist ein anderes Risikomodell. Nicht nur ein Mensch wird Ziel. Die Pipeline wird zum Ziel, weil sie mehr Rechte, mehr Kontext und mehr Reichweite hat als fast jeder einzelne Entwickler.

Für Unternehmen ist genau das der Punkt. Viele Teams behandeln CI/CD noch als technische Komfortzone: schneller testen, schneller bauen, schneller deployen. In Wirklichkeit ist die Pipeline ein privilegiertes Produktionssystem. Sie liest Quellcode, verarbeitet Secrets, erzeugt Artefakte, signiert Releases, schreibt Images, veröffentlicht Pakete und startet Deployments. Wer dort Code zur Ausführung bringt, steht nicht am Rand des Systems. Er steht oft mitten im Maschinenraum.

Warum dieser Angriffstyp so unangenehm ist

Klassische Schutzmaßnahmen greifen nur teilweise. Zwei-Faktor-Authentifizierung für Maintainer ist wichtig. Lockfiles sind wichtig. Dependency-Scanning ist wichtig. Aber all das beantwortet nicht die Frage, ob eine vertrauenswürdige Pipeline gerade etwas Unvertrauenswürdiges ausführt.

Das Problem entsteht durch implizites Vertrauen zwischen Schritten, Caches, Artefakten und Tokens. Ein Pull Request scheint harmlos, weil er nicht direkt veröffentlichen darf. Ein Cache scheint harmlos, weil er nur Build-Zeit spart. Ein Installationsscript scheint normal, weil das JavaScript-Ökosystem es seit Jahren erlaubt. Ein temporärer Token scheint sicher, weil er kurzlebig ist. Die Kombination kann trotzdem gefährlich werden, wenn ein späterer Schritt mehr Rechte besitzt als der frühere Schritt.

Genau diese Übergänge sind die neuen Bruchstellen:

• Ein unprivilegierter Workflow erzeugt oder vergiftet Daten, die später von einem privilegierten Workflow wiederverwendet werden.
• Ein Cache wird nicht als ausführbarer Bestandteil der Sicherheitsgrenze verstanden.
• Ein Release-Job installiert Pakete mit Lifecycle-Scripts, während sensitive Tokens verfügbar sind.
• Ein Artefakt wird als "intern" behandelt, obwohl seine Herkunft nicht stark genug überprüft wurde.
• Eine Pipeline kann nach außen kommunizieren, obwohl sie für den Job eigentlich keinen Netzwerkzugang braucht.

Das ist unbequem, weil es nicht mit einem einzelnen Tool gelöst wird. Es ist ein Architekturthema.

Der Cache ist kein neutraler Speicher

Build-Caches werden häufig wie Infrastrukturrauschen behandelt. Sie sind da, sie machen Builds schneller, man denkt selten über sie nach. Aus Sicherheitssicht sind sie jedoch ein Übergabepunkt zwischen Ausführungen. Wenn ein späterer Job Daten aus einem früheren Kontext übernimmt, übernimmt er auch dessen Risiko.

Das gilt besonders, wenn Caches über Branches, Forks oder Workflow-Typen hinweg geteilt werden. Ein Cache kann ausführbare Dateien, vorbereitete Dependencies, generierte Skripte oder manipulierte Zustände enthalten. Wenn der Release-Job später daraus liest, ist der Cache Teil der Supply Chain.

Eine robuste Pipeline behandelt Caches deshalb wie Artefakte mit Herkunft:

• Caches aus Pull Requests von außen dürfen nicht in Release-Jobs wiederverwendet werden.
• Privilegierte Workflows sollten eigene Cache-Scopes verwenden.
• Cache-Keys brauchen mehr als Betriebssystem und Lockfile-Hash, wenn unterschiedliche Vertrauensstufen beteiligt sind.
• Release-Builds sollten reproduzierbar genug sein, um auch ohne riskante Cache-Wiederverwendung zu laufen.

Das kostet manchmal Minuten. Aber Geschwindigkeit ist nur dann ein Vorteil, wenn sie nicht die Grenze zwischen Test- und Produktionsvertrauen auflöst.

Installationsscripts sind kleine Programme mit großem Radius

Viele npm-Angriffe nutzen preinstall, postinstall oder prepare, weil diese Scripts automatisch laufen können. Das wirkt banal, ist aber ein mächtiges Muster: Der Angreifer muss nicht erst eine Anwendung ausführen. Es reicht, dass die Abhängigkeit installiert wird.

In einer Entwicklerumgebung ist das schon kritisch. In CI ist es oft schlimmer. Dort liegen häufig Cloud-Zugänge, Registry-Tokens, GitHub-Rechte, SSH-Schlüssel, Signaturmaterial oder Deploy-Berechtigungen in Reichweite. Ein bösartiges Installationsscript kann diese Umgebung scannen, Daten exfiltrieren oder weitere Veröffentlichungen vorbereiten.

Unternehmen sollten deshalb unterscheiden, wo Installationsscripts wirklich nötig sind. Für viele Build-Schritte ist npm ci --ignore-scripts oder eine vergleichbare Policy möglich. Wenn Scripts gebraucht werden, sollten sie in einem isolierten Schritt laufen, bevor sensitive Tokens verfügbar sind. Der Release-Schritt sollte nicht gleichzeitig "alles installieren" und "alles veröffentlichen" dürfen.

Die praktische Frage lautet nicht: Vertrauen wir npm? Die praktische Frage lautet: Was kann passieren, wenn eine einzelne installierte Abhängigkeit während des Builds Code ausführt?

Trusted Publishing ist kein Freifahrtschein

OIDC und Trusted Publishing sind gute Fortschritte, weil sie langlebige Tokens reduzieren. Sie verschieben das Risiko aber in die Frage, welcher Workflow unter welchen Bedingungen einen kurzlebigen Token bekommen darf. Kurzlebig heißt nicht harmlos. Ein Token, der fünf Minuten lang veröffentlichen darf, ist in den falschen fünf Minuten ausreichend.

Deshalb braucht Trusted Publishing starke Bedingungen:

• Nur klar definierte Release-Workflows dürfen veröffentlichen.
• Releases sollten an Tags, geschützte Branches und Review-Regeln gebunden sein.
• Der Workflow darf keine unkontrollierten Daten aus weniger vertrauenswürdigen Kontexten übernehmen.
• Der Moment, in dem der Publish-Token verfügbar ist, muss möglichst spät und möglichst kurz sein.
• Ausgehender Netzwerkverkehr im Release-Job sollte beobachtet oder eingeschränkt werden.

Viele Teams führen diese Kontrollen erst ein, wenn sie ein eigenes Security-Team haben. Das ist zu spät gedacht. Gerade kleinere Unternehmen profitieren von einfachen, harten Defaults, weil sie weniger Zeit für Incident Response haben.

Was kleine und mittlere Unternehmen jetzt konkret prüfen sollten

Für ein Schweizer KMU mit Webshops, Kundenportalen, internen Tools oder headless CMS ist das Thema nicht abstrakt. Auch wenn kein eigenes npm-Paket veröffentlicht wird, laufen Builds, Deployments und Container-Images durch eine Lieferkette. Der Angriff muss nicht auf das Unternehmen selbst zielen. Es reicht, wenn eine populäre Abhängigkeit in einem ungünstigen Zeitfenster kompromittiert ist.

Ein pragmatischer Review beginnt mit fünf Fragen:

1. Welche CI-Jobs haben Zugriff auf Secrets?
2. Welche davon installieren externe Dependencies?
3. Welche Jobs teilen Caches oder Artefakte mit Pull-Request-Jobs?
4. Welche Build-Schritte dürfen ins Internet senden?
5. Welche Artefakte wurden während eines bekannten Angriffszeitfensters gebaut und später deployt?

Die letzte Frage wird oft vergessen. Ein Lockfile zu korrigieren schützt zukünftige Builds. Es sagt aber nichts über Images, Functions oder Deployments aus, die bereits während des kompromittierten Fensters gebaut wurden. Wer ernsthaft reagieren will, muss auch laufende Artefakte betrachten.

Ein gutes Zielbild für die Pipeline

Eine belastbare Pipeline fühlt sich nicht kompliziert an. Sie ist klar getrennt.

Pull Requests dürfen testen, aber nicht veröffentlichen. Release-Jobs dürfen veröffentlichen, aber nur aus geschützten Quellen. Caches sind nach Vertrauensstufe getrennt. Installationsscripts laufen nur dort, wo sie gebraucht werden. Secrets erscheinen spät und verschwinden schnell. Artefakte sind nachvollziehbar. Deployments können auf einen konkreten Build, Commit und Dependency-Zustand zurückgeführt werden.

Das ist keine akademische Perfektion. Es ist operative Resilienz. Moderne Angriffe suchen nicht den dramatischsten Einstieg, sondern den billigsten Übergang zwischen zwei Vertrauenszonen. Die CI/CD-Pipeline ist voller solcher Übergänge. Wer sie sichtbar macht, reduziert das Risiko deutlich.

Unser Fazit

Open Source bleibt ein enormer Produktivitätshebel. Aber die alte Bequemlichkeit, dass ein grüner Build automatisch ein sicherer Build sei, trägt nicht mehr.

Unternehmen sollten ihre Pipeline wie ein Produkt behandeln: mit Architektur, Verantwortlichkeit, Logging, Tests und klaren Grenzen. Dann beleibt CI/CD das, was es sein sollte: ein kontrollierter Weg in die Produktion.

Weiterführende Quellen: TanStack Postmortem zur npm-Supply-Chain-Kompromittierung, TanStack Follow-up zur Härtung der Release-Prozesse, heise zur Anzahl betroffener Pakete und All About Security zur Einordnung des Angriffs.