Software Supply Chain wirksam absichern

Die Lieferkette ist größer als die Dependency-Liste

Moderne Software entsteht aus eigenem Code, Open-Source-Paketen, Container-Images, Build-Tools, CI-Erweiterungen und externen Artefakten. Eine Schwachstelle oder Manipulation an einer dieser Stellen kann bis in die Produktion gelangen. Deshalb betrachtet Supply-Chain-Sicherheit den gesamten Weg vom Quellcode bis zum ausgelieferten System.

Die OWASP Top 10:2025 führt Software Supply Chain Failures als eigene zentrale Risikokategorie. Das verdeutlicht, dass nicht nur bekannte Schwachstellen relevant sind. Auch kompromittierte Quellen, unkontrollierte Updates und schwache Build-Prozesse gehören zum Risiko.

Ein vollständiges Inventar schaffen

Was nicht bekannt ist, kann nicht bewertet oder aktualisiert werden. Ein Inventar umfasst direkte und transitive Abhängigkeiten, Laufzeiten, Betriebssysteme, Images, Plugins und Build-Werkzeuge. Eine Software Bill of Materials kann diese Informationen strukturiert bereitstellen.

• Direkte und transitive Abhängigkeiten erfassen.
• Version, Quelle und Lizenz dokumentieren.
• Verantwortliche Teams oder Systeme zuordnen.
• End-of-Life-Termine und Supportstatus beobachten.
• Artefakte mit den ausgelieferten Releases verknüpfen.

Lockfiles und reproduzierbare Builds

Lockfiles halten konkrete Versionen fest und reduzieren unerwartete Änderungen. Sie müssen im Repository liegen und im CI-Prozess verwendet werden. Ein Build, der ohne kontrollierte Versionen bei jedem Lauf andere Pakete lädt, ist schwer prüfbar.

# PHP
composer install               --no-dev               --prefer-dist               --no-interaction               --classmap-authoritative

# Node.js
npm ci               --ignore-scripts

Das Deaktivieren von Installationsskripten ist nicht in jedem Projekt möglich, sollte aber bewusst entschieden werden. Skripte aus Paketen können Code während des Builds ausführen und benötigen daher dieselbe Vertrauensprüfung wie andere Build-Schritte.

Vertrauenswürdige Quellen und minimale Rechte

Pakete und Images sollten aus kontrollierten Registries stammen. Spiegel oder interne Registries können Verfügbarkeit, Scans und Freigaben zentralisieren. CI-Tokens erhalten nur die Rechte, die für den konkreten Build nötig sind. Ein Build-Job sollte nicht gleichzeitig Quellcode verändern und Produktion deployen können.

CI/CD als produktives System behandeln

Eine Pipeline besitzt Zugriff auf Quellcode, Secrets und Artefakte. Sie ist damit ein attraktives Ziel. Branch-Schutz, Reviews, isolierte Runner und getrennte Umgebungen reduzieren das Risiko. Änderungen an Pipeline-Dateien und Actions benötigen besondere Aufmerksamkeit.

• Externe Actions und Images auf feste Versionen oder Digests pinnen.
• Persistente Runner regelmäßig zurücksetzen oder isolieren.
• Secrets nur in Jobs verfügbar machen, die sie benötigen.
• Produktionsfreigaben von normalen Builds trennen.
• Änderungen an Build- und Deployment-Konfigurationen gesondert prüfen.

Artefakte prüfen und nachvollziehbar machen

Das Ergebnis eines Builds sollte eindeutig dem Quellcode, der Pipeline und den verwendeten Abhängigkeiten zugeordnet werden können. Prüfsummen, Signaturen und Provenance-Informationen helfen, Manipulationen zu erkennen. Produktion sollte nur freigegebene Artefakte aus einer kontrollierten Registry akzeptieren.

Schwachstellen risikobasiert behandeln

Ein Scanner erzeugt Befunde, aber noch keine Priorisierung. Entscheidend sind Erreichbarkeit, Ausnutzbarkeit, Datenzugriff und die Rolle des betroffenen Systems. Ein nicht genutzter Entwicklungspfad kann ein anderes Risiko besitzen als eine öffentlich erreichbare Bibliothek im Checkout.

Auf Vorfälle vorbereitet sein

Bei einer kompromittierten Abhängigkeit zählt Geschwindigkeit. Das Team muss wissen, welche Systeme und Releases betroffen sind, wie Artefakte gesperrt werden und welche Zugangsdaten rotiert werden müssen. Ein Inventar ist erst dann wertvoll, wenn es in einem Vorfall schnell abgefragt werden kann.

Fazit

Supply-Chain-Sicherheit verbindet Inventar, kontrollierte Quellen, gehärtete Pipelines und nachvollziehbare Artefakte. Automatische Scans sind wichtig, ersetzen aber keine Verantwortlichkeit und keine sichere Freigabestrategie. Wer den Build-Prozess wie ein produktives System behandelt, reduziert Risiken lange bevor Code die Produktion erreicht.