Warum Lieferkettensicherheit in Ihr CI gehört

1:53

Ihr Produktions-Build ist nicht der Build auf Ihrem Laptop

Die meisten Teams gehen davon aus, dass der lokal getestete Code auch der ausgelieferte Code ist. Der Quellcode ist derselbe, die Software oft nicht. Ein Build besteht aus Quellcode plus allem, was er lädt, und allem, was ihn bei der Ausführung umgibt, und nur sehr wenig davon steht fest.

Nicht gepinnte Abhängigkeiten werden unterschiedlich aufgelöst

Versionsbereiche sind die Norm. In npm akzeptiert ^1.0.4 jedes spätere 1.x-Release, sodass dieselbe package.json an verschiedenen Tagen verschiedene Versionen installiert. Ein Lockfile pinnt sie, aber nur, wenn es committet ist und der Build es beachtet: npm ci schlägt fehl, wenn Lockfile und package.json nicht übereinstimmen, während npm install das Lockfile stillschweigend aktualisieren kann. Viele Projekte committen gar keins. Auch Express 5.2.1, ein weit verbreitetes Web-Framework, tut das nicht.

Selbst eine gepinnte Version ist ein Name, keine Datei. Die pip-Dokumentation erklärt, dass Version-Pinning allein einen Paketindex nicht daran hindert, für dieselbe Version andere Dateien auszuliefern, und bietet deshalb den Hash-Checking-Modus an.

Die Zeit verändert die Eingaben

Registries ändern sich zwischen Builds. Neue Versionen erscheinen, alte werden zurückgezogen, und ein Versionsbereich, der am Montag sicher aufgelöst wurde, kann am Dienstag ein kompromittiertes Release erwischen. Auch Container-Tags bewegen sich: Die Dokumentation von Docker selbst warnt, dass Image-Tags veränderlich sind und ein Herausgeber einen Tag auf ein neues Image zeigen lassen kann. FROM node:20 ist also von Monat zu Monat nicht dasselbe Basis-Image, sofern Sie es nicht per Digest pinnen.

Die Zeit landet auch im Ergebnis. Das Projekt Reproducible Builds nennt Zeitstempel die größte Quelle von Reproduzierbarkeitsproblemen, weil so viele Tools das aktuelle Datum und die Uhrzeit in das schreiben, was sie bauen.

Die Umgebung ist eine andere

• Betriebssystem und Architektur. Ein Laptop mit macOS und ARM und ein CI-Runner mit Linux und x86-64 installieren für dasselbe Paket unterschiedliche vorgefertigte Binärdateien. Viele npm-Tools werden inzwischen als plattformspezifische Pakete ausgeliefert, die eine kompilierte Binärdatei umschließen.
• Toolchains. Versionen von Compilern, Runtimes und Paketmanagern driften zwischen Maschinen auseinander, sofern nicht jede davon gepinnt ist.
• Caches. Ihr Rechner und Ihr CI stellen unterschiedliche Caches wieder her, die zu unterschiedlichen Zeiten aus unterschiedlichen Auflösungen entstanden sind.
• Install-Skripte und Build-Schritte. Post-Install-Hooks, Setup-Actions und Build-Skripte laden zur Build-Zeit Tools und Daten herunter. Nichts davon steht in einem Manifest.
• Konfiguration. Umgebungsvariablen, Build-Flags und Secrets gibt es im CI und nirgendwo sonst.

Das Projekt Reproducible Builds definiert einen reproduzierbaren Build so: Bei gleichem Quellcode, gleicher Build-Umgebung und gleichen Build-Anweisungen kann jeder bitgenau identische Kopien aller festgelegten Artefakte erzeugen. Diese Definition zeigt, wie viel konstant gehalten werden muss. Die Builds der meisten Teams erreichen das nicht, und die, die es tun, haben hart dafür gearbeitet. Bis Sie so weit sind, ist die einzige verlässliche Auskunft darüber, was ausgeliefert wurde, die Aufzeichnung, die während des ausgelieferten Builds entstanden ist.

1:18

Wo Sie prüfen können und was jeder Ort sieht

Sicherheitsprüfungen können an vier Orten laufen. Jeder hat seine Aufgabe, aber nur einer sieht den Build, der Ihr Release tatsächlich erzeugt hat.

Ein Scan des Repositorys meldet, was das Projekt deklariert. Ein Scan des fertigen Artefakts meldet, was er darin erkennen kann. Keiner hat den Build erlebt. Express 5.2.1 committet kein Lockfile, sodass ein Scanner bei einem frischen Checkout keine der npm-Abhängigkeiten des Projekts auflösen kann und meldet, was er sonst erkennt. Richten Sie dasselbe Tool auf eine installierte Kopie desselben Repositorys, und ein einziges Cataloger-Flag ändert die Antwort erneut. Was zurückkommt, hängt davon ab, was vor dem Scan installiert war, und genau das kontrolliert ein Scan nicht. Die Seite zu SBOMs zur Build-Zeit erklärt, warum Scans voneinander abweichen und was die Aufzeichnung des Builds ändert.

Die Pipeline ist ein eigenständiges Angriffsziel

Im CI treffen Quellcode, Abhängigkeiten und Secrets aufeinander. Das macht es zu einem lohnenden Ziel.

• tj-actions/changed-files (2025). Eine weit verbreitete GitHub Action wurde kompromittiert und schrieb CI-Secrets in die Build-Logs.
• Codecov Bash Uploader (2021). Ein verändertes Skript, das im CI von Kunden lief, sendete Umgebungsvariablen an den Server eines Angreifers.
• Der Shai-Hulud-npm-Wurm (2025). Kompromittierte Pakete stahlen bei der Installation Zugangsdaten und veröffentlichten damit weitere kompromittierte Pakete.
• xz utils (2024). Eine Hintertür war in Release-Tarballs und im Build-Prozess selbst versteckt, nicht im sichtbaren Quellcode.

Jeder dieser Angriffe führte während eines Builds oder einer Installation Code aus. Ein Repository-Scan davor oder ein Artefakt-Scan danach hätte nicht gesehen, was der Build-Prozess getan hat. Kontrollen, die beobachten und begrenzen, was ein Job erreichen kann, müssen dort sitzen, wo der Job läuft. Das gilt auch für interne und unauffällige Apps: Solche Angriffe zielen auf die Pipeline und die Pakete, die jede App teilt, nicht darauf, was eine App tut. Siehe Lieferkettensicherheit für interne und risikoarme Software.

Mehr Code, mehr Abhängigkeiten, weniger Menschen, die sie lesen

KI-Coding-Agenten schreiben und ändern Code schneller, als Teams jede Zeile prüfen können, und fügen dabei Abhängigkeiten hinzu. Außerdem nennen sie Pakete, die es nicht gibt: Eine Studie der USENIX Security 2025 mit 576.000 generierten Codebeispielen fand Raten halluzinierter Pakete von mindestens 5,2 % bei kommerziellen Modellen und 21,7 % bei Open-Source-Modellen. Registriert ein Angreifer einen dieser Namen, wird sein Paket vom nächsten Build installiert, der dem Namen vertraut.

Jede Änderung, egal wer oder was sie geschrieben hat, durchläuft auf dem Weg in die Produktion den Build. Das macht den Build zum einzigen Kontrollpunkt, der nicht davon abhängt, dass jemand hingesehen hat.

Nachweise müssen beschreiben, was ausgeliefert wurde

Regulierung und Kunden verlangen Belege, nicht Absichten. Der EU Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu ermitteln und zu dokumentieren und Schwachstellen darin während des Unterstützungszeitraums des Produkts zu behandeln. Eine aus einem Manifest erzeugte SBOM beschreibt, was das Projekt angefordert hat. Eine aus dem Build aufgezeichnete SBOM beschreibt, was in das Release eingeflossen ist, für das Sie verantwortlich sind. Wird eine neue Schwachstelle veröffentlicht, sagt Ihnen die zweite, welche Releases betroffen sind. Lesen Sie, was der CRA verlangt.

Was „im CI“ bedeuten sollte

Einen Scanner als CI-Schritt auszuführen ist ein Anfang, aber er betrachtet weiterhin Dateien, nachdem sie angekommen sind. Richtig umgesetzt bedeutet „im CI“:

1. Aufzeichnen, nicht ableiten. Erfassen Sie jedes Paket und jeden Download, den der Job tatsächlich lädt, einschließlich transitiver Abhängigkeiten und allem, was aus einem Cache wiederhergestellt wird.
2. Angeben, wie vollständig die Aufzeichnung ist. Eine SBOM sollte ausweisen, ob sie alles abdeckt, was der Job geladen hat, und nicht nur auflisten, was sie gefunden hat.
3. Den ausgehenden Datenverkehr kontrollieren. Legen Sie fest, welche Hosts ein Job erreichen darf, und stoppen Sie den Rest, bevor eine kompromittierte Abhängigkeit nach Hause telefonieren kann.
4. Auch nach dem Release weiter beobachten. Prüfen Sie das Ausgelieferte erneut, wenn neue Schwachstellen auftauchen, und machen Sie aus Befunden Fixes.

Genau das leistet CRACI. Es ist ein Runner für Ihre GitHub-Actions-Jobs, zeichnet also auf, was jeder Build lädt, wendet die Egress-Richtlinie an und überwacht, was Sie ausgeliefert haben. Einen Workflow umzustellen ist eine Zeile: runs-on: craci. Siehe So funktioniert CRACI.

Was CI nicht ersetzt

Lieferkettensicherheit im Build macht andere Ebenen nicht überflüssig.

• Entwicklerrechner enthalten weiterhin Zugangsdaten und führen Install-Skripte aus. Schützen Sie auch sie; ein kompromittierter Laptop kann Code pushen, bevor irgendein Build läuft.
• Code-Review und statische Analyse finden Fehler in Ihrem eigenen Code, was eine Aufzeichnung der Abhängigkeiten nicht leistet.
• Pinning, Lockfiles und Digests bleiben gute Praxis. Sie verringern die Unterschiede zwischen Builds; die Aufzeichnung des Builds sagt Ihnen, was trotzdem passiert ist.

Der Build ist nicht der einzige Ort für Prüfungen. Er ist der einzige Ort, der die Software sieht, die Sie tatsächlich ausliefern.