Publiziert: Zuletzt aktualisiert:

Software Supply Chain Security

Vertraue keiner Komponente ohne Herkunftsnachweis

Software Supply Chain Security sichert nicht den eigenen Code, sondern alles, was in ihn hineinfliesst: zugekaufte Bibliotheken, quelloffene Abhängigkeiten und die Build-Pipeline, die sie zusammenfügt. Sie ist eine Architektur und ein Betriebsmodell, nicht eine einzelne Massnahme.

Moderne Software besteht zum grössten Teil aus fremdem Code. Eine Anwendung zieht dutzende direkte und hunderte transitive Abhängigkeiten, von denen die wenigsten je gelesen wurden. Jede dieser Komponenten ist ein Einfallstor, und jeder Schritt zwischen Quellcode und Auslieferung ist ein möglicher Manipulationspunkt. Eine SBOM beantwortet die erste Frage, was überhaupt enthalten ist, und ist damit das unverzichtbare Inventar. Diese Seite ordnet die Ebene darüber: wie sich die Lieferkette als Ganzes absichern lässt, von der Herkunft einer Komponente über die Integrität der Pipeline bis zum laufenden Betrieb.

Anti-Patterns: Vertrauen ohne Nachweis

  • Blindes Vertrauen in Abhängigkeiten: Pakete werden aus öffentlichen Registern gezogen, ohne dass Herkunft, Integrität oder Pflegezustand geprüft werden. Was der Paketmanager liefert, gilt als gut.
  • Ungepinnte Versionen: Abhängigkeiten werden lose referenziert, sodass ein Build heute andere Bausteine zieht als gestern. Was gebaut wird, ist nicht reproduzierbar und nicht nachvollziehbar.
  • Ungeschützte Pipeline: Die Build-Umgebung hat weitreichende Rechte, lädt Werkzeuge aus dem Netz nach und ist selbst kaum abgesichert. Wer sie kompromittiert, kompromittiert jedes Artefakt, das sie verlässt.
  • Einmalige Prüfung: Eine Komponente wird beim Einbau einmal geprüft und danach nie wieder. Schwachstellen, die erst später bekannt werden, bleiben unentdeckt.

Die Bedrohungsklasse: Angriff auf die Lieferkette statt auf das Ziel

Ein Angriff auf die Lieferkette zielt nicht auf das eigene System, sondern auf einen Baustein, dem dieses System vertraut. Der Hebel ist die Reichweite: Wer eine weit verbreitete Bibliothek oder ein Build-Werkzeug kompromittiert, erreicht jeden, der es einsetzt.

Zwei Muster prägen die Bedrohungsklasse. Beim ersten wird eine Abhängigkeit selbst kompromittiert: Eine harmlose Bibliothek erhält in einer neuen Version bösartigen Code, sei es durch ein übernommenes Konto eines Maintainers oder durch ein untergeschobenes Paket mit ähnlichem Namen. Das Log4Shell-Ereignis zeigte die Wucht dieser Klasse, als eine einzelne, allgegenwärtige Bibliothek unzählige Systeme zugleich verwundbar machte. Beim zweiten wird die Build-Pipeline manipuliert: Nicht der Quellcode, sondern der Weg von der Quelle zum ausgelieferten Artefakt wird unterwandert, sodass das Endprodukt Schadcode enthält, den niemand je in das Repository geschrieben hat. Der SolarWinds-Vorfall folgte diesem Muster und machte die Pipeline selbst zum Angriffsziel.

Herkunft und Signatur als Beweis der Integrität

Die Antwort auf beide Muster ist Nachweisbarkeit: Jedes Artefakt soll belegen können, woher es stammt und dass es seit seiner Erzeugung unverändert ist. Drei Bausteine tragen diesen Nachweis.

  1. Signatur. Ein Artefakt wird kryptografisch signiert, sodass sich jede nachträgliche Veränderung erkennen lässt. Sigstore mit dem Werkzeug cosign hat das Signieren vereinfacht, indem es kurzlebige Zertifikate an bestehende Identitäten bindet und so den Aufwand klassischer Schlüsselverwaltung vermeidet.
  2. Herkunftsnachweis (Provenance). Über eine Build-Attestierung dokumentiert die Pipeline überprüfbar, aus welcher Quelle, mit welchen Werkzeugen und in welcher Umgebung ein Artefakt entstanden ist. Damit lässt sich ein ausgeliefertes Artefakt lückenlos auf einen bestimmten Commit zurückführen.
  3. Reifegradmodell. Das SLSA-Rahmenwerk (Supply-chain Levels for Software Artifacts) ordnet diese Massnahmen in aufeinander aufbauende Stufen. Es macht aus Einzelmassnahmen einen Pfad, an dem sich der erreichte Schutzgrad der eigenen Lieferkette ablesen und schrittweise erhöhen lässt.

Signatur und Herkunftsnachweis kehren das Vertrauensmodell um: Ein Artefakt gilt nicht als vertrauenswürdig, weil es aus der gewohnten Quelle kommt, sondern weil es seine Herkunft und Unversehrtheit selbst belegt.

Disziplin bei Abhängigkeiten als laufende Hygiene

Vor dem Nachweis steht die Auswahl. Jede aufgenommene Abhängigkeit erweitert die Angriffsfläche, weshalb ihre Pflege eine eigene Disziplin ist.

  • Pinnen. Abhängigkeiten werden auf exakte Versionen festgelegt und über eine Lockdatei mit kryptografischen Prüfsummen abgesichert. So zieht jeder Build dieselben Bausteine, und eine untergeschobene Version fällt auf.
  • Bewerten. Vor der Aufnahme wird eine Komponente nach Pflegezustand, Verbreitung und Reaktionsgeschwindigkeit ihrer Maintainer beurteilt. Eine ungepflegte Abhängigkeit ist ein künftiges Risiko, unabhängig von ihrem heutigen Zustand.
  • Reduzieren. Die sicherste Abhängigkeit ist die, die nicht aufgenommen wird. Eine kleine, bewusst gewählte Menge an Bausteinen ist leichter zu überblicken als ein wuchernder Abhängigkeitsbaum.

Das Betriebsmodell: Beobachten, reagieren, erneut prüfen

Supply-Chain-Security ist kein einmaliges Projekt, sondern ein Dauerzustand, weil die meisten Schwachstellen erst nach der Auslieferung bekannt werden. Eine Komponente, die heute als sicher gilt, kann morgen verwundbar sein, ohne dass sich an ihr etwas geändert hat.

Das Betriebsmodell schliesst daher einen Kreislauf. Die Inventarliste aus der SBOM wird kontinuierlich gegen neue Schwachstellenmeldungen geprüft, sodass eine frisch bekannt gewordene Lücke sofort den betroffenen Systemen zugeordnet werden kann. Auf einen Treffer folgt eine geübte Reaktion: bewerten, ob die Schwachstelle im eigenen Einsatz erreichbar ist, die Abhängigkeit aktualisieren oder ersetzen, und das Ergebnis erneut verifizieren. Diese Schleife verankert sich am natürlichsten in der CI/CD-Pipeline, wo Erzeugung der SBOM, Signatur, Herkunftsnachweis und Schwachstellen-Scan zu festen Schritten jedes Builds werden. So wird Sicherheit der Lieferkette nicht zur Sonderaktion, sondern zum eingebauten Verhalten.

Praxis-Beispiel: Eine neue kritische Schwachstelle

In einer weit verbreiteten Bibliothek wird eine kritische Lücke bekannt. Ohne Betriebsmodell beginnt nun eine hektische Suche: Welche Anwendungen nutzen diese Bibliothek, in welcher Version, und wo überhaupt. Mit einem eingerichteten Kreislauf läuft es umgekehrt. Die kontinuierliche Prüfung gleicht die Meldung gegen die gespeicherten SBOMs ab und nennt in Minuten die betroffenen Artefakte. Der Herkunftsnachweis führt jedes davon auf seinen Commit und seine Pipeline zurück, die Abhängigkeit wird aktualisiert, das neue Artefakt signiert und erneut geprüft. Aus einem Notfall wird ein eingespielter Vorgang.

FAQ

Reicht eine SBOM nicht aus?

Die SBOM ist notwendig, aber nicht hinreichend. Sie sagt, was enthalten ist, und ist die Grundlage jeder Schwachstellenprüfung. Sie sagt aber nicht, ob ein Artefakt unterwegs manipuliert wurde oder aus der erwarteten Quelle stammt. Das leisten erst Signatur und Herkunftsnachweis. Die SBOM ist das Inventar, Supply-Chain-Security ist die Architektur darum herum.

Ist das nicht nur für sicherheitskritische Software relevant?

Nein. Die Lieferkette ist für jede Software dieselbe, weil jede aus denselben öffentlichen Registern und Bausteinen schöpft. Eine kompromittierte, weit verbreitete Abhängigkeit trifft die einfache Anwendung genauso wie das kritische System. Regulatorische Anforderungen wie der Nachweis einer Komponentenliste machen den Nachweis zudem zunehmend zur Compliance-Pflicht.

Verlangsamt das die Auslieferung?

Die zusätzlichen Schritte, also Signatur, Attestierung und Scan, laufen automatisiert in der Pipeline und kosten Sekunden bis Minuten pro Build. Dem steht der ungleich grössere Aufwand einer ungeordneten Reaktion auf einen Vorfall gegenüber. Die Disziplin verlagert Aufwand vom Notfall in den Normalbetrieb, wo er planbar ist.

Referenzen

Verwandte Themen

  • SBOM, die maschinenlesbare Inventarliste, auf der dieses Betriebsmodell aufsetzt.
  • CI/CD, die Pipeline, in der Signatur, Herkunftsnachweis und Scan zu festen Schritten werden.
  • Compliance, die regulatorischen Anforderungen, die einen Nachweis der Lieferkette verlangen.
  • Public Code, die quelloffenen Bausteine, deren Herkunft und Pflege diese Disziplin absichert.

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.