Die Lieferkette: das Paket, das gestern noch sauber war

Der klassische Angriff sucht eine Lücke in deiner Software. Der Angriff auf die Lieferkette spart sich das: Er bringt seinen Code dorthin, wo du ihn freiwillig installierst, in ein Paket, das du seit Jahren verwendest, oder in eines, von dem du gar nicht weißt, dass es bei dir liegt.

Die drei Wege hinein#

Übernommenes Konto. Der Betreuer eines echten, beliebten Pakets verliert seine Zugangsdaten (Phishing, wiederverwendetes Passwort, kompromittierter Rechner). Es erscheint eine neue Patchversion mit zusätzlichem Code. Das ist der Weg mit der größten Reichweite und der Grund, warum Zwei-Faktor-Zwang in Paketregistern kein Schikane-Thema ist.

Vertippte Namen. Ein Paket heißt fast wie das echte. Trifft vor allem automatisierte Installationen und schnelle Nachinstallationen auf dem Server.

Bösartige Abhängigkeit tief unten. Nicht das Paket, das du installierst, sondern dessen zwölfte transitive Abhängigkeit. Du liest den Namen nie.

Das gilt für npm und PyPI genauso wie für Container-Images auf öffentlichen Registries, für Action-/Plugin-Kataloge in CI-Systemen und für „curl ins Terminal“-Installationsanleitungen.

Was der Code typischerweise tut#

Nicht ausschließlich, aber immer wieder dasselbe Muster: Umgebungsvariablen und Konfigurationsdateien einsammeln (Zugangsdaten, Tokens, Cloud-Schlüssel), an eine Adresse senden, sich in weiteren Projekten desselben Kontos einnisten. Bei Bauprozessen läuft das im Installationsschritt, noch bevor irgendein Test ausgeführt wurde.

Für dich heißt das: Ein Fund in der Lieferkette ist immer auch ein Geheimnis-Vorfall. Rotieren, nicht nur aktualisieren, siehe Geheimnisse gehören nicht ins Repo.

Fünf Maßnahmen, nach Wirkung sortiert#

1. Versionen festnageln, inklusive Prüfsumme. Lockfiles gehören ins Repo und in den Build. Container-Images per Digest statt per Tag:

# statt: image: nginx:1.27
image: nginx@sha256:9c4f2b1a...        # ein Tag kann umgehängt werden, ein Digest nicht

# npm: exakt das Lockfile, keine Auflösung zur Laufzeit
npm ci --ignore-scripts

# pip: Hashes erzwingen
pip install --require-hashes -r requirements.txt

2. Installationsskripte abschalten, wo es geht. --ignore-scripts verhindert den häufigsten Ausführungszeitpunkt. Was wirklich ein Skript braucht, wird bewusst freigegeben, nicht pauschal.

3. Bauen und Laufenlassen trennen. Der Build läuft in einem Container, der keine dauerhaften Zugangsdaten sieht und nur dorthin darf, wo er hinmuss. Ein Deploy-Schlüssel mit Schreibrecht auf alles ist genau das, was ein Lieferkettenangriff sucht.

4. Ausgehenden Verkehr des Bauprozesses begrenzen. Ein Build braucht das Paketregister, nicht das ganze Internet. Dieselbe Logik wie in Ausgehend begrenzen, nur eine Ebene früher.

5. Wissen, was drin war. Ohne Bestandsliste kannst du nach einer Meldung nicht beantworten, ob du betroffen warst: Bestandsliste statt Bauchgefühl.

Wenn eine Meldung kommt#

# Steckt die Version irgendwo im Baum?
npm ls betroffenes-paket
pip show betroffenes-paket 2>/dev/null || pip freeze | grep -i betroffenes-paket

# Läuft ein Image mit dem betroffenen Digest noch?
docker ps --format '{{.Image}}' | sort -u
docker image inspect $(docker ps -q) --format '{{.RepoDigests}}'

Danach in dieser Reihenfolge: betroffene Version entfernen, alle Geheimnisse rotieren, die der Prozess sehen konnte, ausgehende Verbindungen des fraglichen Zeitraums prüfen, erst dann aufräumen. Der vollständige Ablauf steht in Die erste Stunde.