5 Tipps, wie du deine Pipeline nach dem Axios-Vorfall verbessern kannst.

Bei Axios gelang es Angreifern, eine bösartige Version direkt in die npm-Registry zu schleusen, die beim Installieren private Daten vom Rechner der Entwickler oder vom Build-Server entwendete. Im Fall der Trivy GitHub Action wurde eine Sicherheitslücke ausgenutzt, die es erlaubte, über manipulierte Pull Requests eigene Befehle in der Pipeline des Opfers auszuführen (Command Injection).

Beide Fälle verdeutlichen: Angreifer haben längst erkannt, dass unsere Delivery Pipelines oft mit deutlich mehr Rechten agieren, als sie eigentlich benötigen. Während wir uns massiv auf die Sicherheit unserer Applikationen fokussieren, vernachlässigen wir oft die Infrastruktur, die diese erst baut und ausliefert.

Nach den Prinzipien von Continuous Delivery sollte unsere Pipeline „Feature Zero“ sein: Das bedeutet, die Pipeline wird mit der gleichen Priorität behandelt wie das Produkt selbst. Wird sie zu langsam, optimieren wir die Performance; ist sie anfällig für Sicherheitslücken oder spezifische Attacken, beheben wir das sofort. Solche Aufgaben erledigen wir nicht erst, wenn wir zwischen zwei Features mal Zeit haben, sondern mit höchster Priorität.

1. Identitäten statt statischer Schlüssel

Statische Keys in den CI-Settings sind ein bekanntes Risiko. Wenn bösartige Skripte in der Pipeline laufen, sind diese Keys das erste Ziel.

• OIDC & Least Privilege: Der Wechsel zu OpenID Connect (OIDC) ist ein Schritt zu mehr Professionalität. Weg von langlebigen Passwörtern, hin zu kurzlebigen Tokens.

• Granularität: Wo OIDC noch nicht geht, hilft das Least-Privilege-Prinzip: Ein Key sollte nur das können, was für diesen einen spezifischen Schritt absolut notwendig ist. Ein Key, der nur Files in einen S3-Bucket schieben darf (eingeschränkt auf den spezifischen Pfad), kann viel weniger Schaden verursachen als ein Key mit Admin-Rechten.

• Rollen statt Rechte: Least Privilege gilt auch für OIDC: Löse gezielt Token mit Rollen aus, die du für den einzelnen Schritt brauchst, und nicht mehr.

2. Determinismus durch Pinnen

Ein Grundpfeiler von Continuous Delivery ist, dass Builds wiederholbar und vorhersehbar sein müssen. Das gilt für Abhängigkeiten wie auch für die Pipeline-Logik:

• Exakte Versionen: Mit save-exact=true in der .npmrc entscheiden wir aktiv, wann wir upgraden, statt uns auf vage Bereiche zu verlassen.

• npm ci: In der CI-Pipeline ist npm ci der Standard. Er stellt sicher, dass exakt das installiert wird, was im Lockfile steht, und löst durch das vorherige Löschen der node_modules einen garantiert sauberen Build-Zustand aus.

• Actions, Orbs und Templates auf SHA pinnen: Tags (wie @v4) können verschoben werden. Die sicherste Methode ist as Pinnen auf den Commit-SHA.

  • GitHub: uses: actions/checkout@a5ac7e5... (Pinning GitHub Actions for Enhanced Security: Everything You Should Know - StepSecurity)

  • GitLab: Pinne bei include-Statements auf eine spezifische Commit-SHA.

  • CircleCI: Nutze bei Orbs exakte Versionen statt „mutable tags“.

• Lifecycle-Skripte: Skripte zu ignorieren ist nicht immer möglich. Hier ist eine Abwägung nötig. Werden sie für deine Applikation jedoch nicht benötigt, nimmst du mit --ignore-scripts in der .npmrc bösartigen postinstall-Hooks die einfachste Angriffsfläche, ohne den Prozess zu stoppen.

3. Das Quarantäne-Prinzip: Zeit als Sicherheitsfaktor

Wir müssen nicht immer die Ersten sein, die ein Routine-Update einspielen. Ein geplantes Intervall kann ein einfacher, aber effektiver Schutz sein.

• Der Cooldown: Ein wöchentliches Intervall für Routine-Updates gibt der Community Zeit, bösartige Releases zu identifizieren. Dies erreichst du bei Dependabot mit folgender Konfig:

• Security-Fast-Track: Echte Security-Patches (CVEs) sollten diesen Cooldown natürlich überspringen. Es ist die Balance zwischen dem Schutz vor unbekannter Malware und dem schnellen Schliessen bekannter Lücken. Das passiert zum Beispiel auf Github automatisch, wenn du in den GitHub-Repository-Einstellungen unter "Code security and analysis" die "Dependabot security updates" aktivierst.

4. Small Batches: Fehlerisolation als Priorität

Ein Kernargument von Continuous Delivery ist die Small Batch Size. Das gilt auch für Abhängigkeiten.

• Einzel-PRs statt Gruppen: Es ist verlockend, Updates zu bündeln, aber es erschwert die Fehleranalyse. Einzel-PRs sorgen dafür, dass wir sofort wissen, welcher Baustein den Build instabil gemacht hat. Zudem blockiert ein einziges fehlerhaftes Paket nicht die restlichen neun Updates.

• Automatisierung: Das erhöht die Reaktionsgeschwindigkeit und macht Reverts trivial. Verfügst du über eine gute automatisierte Testabdeckung, lassen sich solche PRs sogar automatisiert mergen.

5. Secrets schützen: Kontext-Isolation

Ein automatisierter PR sollte nicht automatisch Zugriff auf alle Produktions-Geheimnisse haben.

• Schrittweise Freigabe: CI-Contexts sollten so restriktiv wie möglich eingesetzt werden – idealerweise pro Step. Ein npm ci braucht keinen Zugang zu deiner AWS Umgebung.

Fazit: Handwerk statt Hektik

Der Axios-Vorfall war kein Grund für neue Theorien, sondern eine Erinnerung an gute Ingenieurspraktiken. Die Pipeline als „Feature Zero“ zu begreifen bedeutet, ihr die gleiche Aufmerksamkeit und Sorgfalt zu schenken wie dem Produktivcode selbst.

Indem wir bekannte Prinzipien wie kurzlebige Identitäten, Determinismus und Small Batches konsequent anwenden, machen wir unsere tägliche Arbeit ein Stück sicherer.

Wichtig dabei: Diese Liste ist kein absolutes "Allerheilmittel". Sicherheit ist kein Ziel, das man einmal erreicht, sondern ein kontinuierlicher Prozess der Professionalisierung. Je nach Bedrohungslage und Komplexität deines Projekts gibt es noch deutlich tiefergehende Massnahmen – von Binary Authorization bis hin zu isolierten Build-Umgebungen. Doch diese Tipps bilden ein starkes Fundament, auf dem du aufbauen kannst.

Letztlich geht es darum, die eigene Lieferkette als wertvolles Handwerk zu verstehen. Wer seine Delivery Pipeline im Griff hat, kann auch bei der nächsten Schlagzeile gelassen bleiben.