Was ist Software-Lieferkettensicherheit?

Was ist die Software-Lieferkette?

Die Software-Lieferkette umfasst alle und alles, was daran beteiligt ist, Software vom Editor eines Entwicklers in die Produktion zu bringen. Stellen Sie sie sich in vier Stufen vor, jede mit eigenen Risiken.

Stufe	Was dazugehört	Was schiefgeht
Quellcode	Ihr Code, Repositories und Entwicklerkonten	Gestohlene Zugangsdaten, bösartige Commits, geleakte Secrets
Abhängigkeiten	Open-Source-Pakete, Basis-Images, Code von Drittanbietern	Verwundbare Versionen, bösartige Releases, Typosquatting
Build	CI-Runner, GitHub Actions, Build-Tools, Caches	Kompromittierte Actions, vergiftete Caches, gestohlene Pipeline-Secrets
Release	Artefakte, Registries, Deployments, Updates	Ausgetauschte Artefakte, manipulierte Updates, keine Aufzeichnung des Ausgelieferten

Warum es gerade jetzt wichtig ist

Das meiste von dem, was Sie ausliefern, haben Sie nicht geschrieben. Eine moderne Anwendung besteht größtenteils aus Open Source, und jede direkte Abhängigkeit bringt weitere mit, die niemand in Ihrem Team ausgewählt hat. Diese Pakete laufen mit denselben Rechten wie Ihr eigener Code, und ihre Install-Skripte können in Ihrer CI-Pipeline laufen, direkt neben Ihren Secrets.

Die Vorfälle der letzten Jahre zeigen, wie das ausgenutzt wird:

• SolarWinds: Der Build wurde kompromittiert, sodass aus sauberem Quellcode ein verseuchtes Release entstand.
• Log4Shell: Ein Fehler in einer einzigen Logging-Bibliothek erreichte Produkte, die nie wussten, dass sie sie nutzten.
• xz utils: Ein vertrauenswürdiger Mitwirkender schleuste eine Hintertür in ein Projekt ein, das in Linux-Distributionen steckt.
• tj-actions: Eine gekaperte GitHub Action führte Angreifercode in den Pipelines aus, die sie nutzten, mit Secrets in Reichweite.
• Shai-Hulud: Ein Wurm verbreitete sich über npm-Pakete und stahl Tokens von den Rechnern und CI-Jobs, die sie installierten.

Wie diese Angriffe Schritt für Schritt ablaufen, lesen Sie unter Was ist ein Lieferkettenangriff.

Wie Software-Lieferkettensicherheit funktioniert

Ein Programm braucht vier Dinge. Alles andere ist Detail.

1. Wissen, was Sie ausliefern. Führen Sie für jedes Release eine genaue SBOM, aus dem Build, der es erzeugt hat, einschließlich transitiver Abhängigkeiten.
2. Steuern, was hineinkommt. Pinnen Sie Versionen, nutzen Sie ein Lockfile, begrenzen Sie, woher Builds laden dürfen, und prüfen Sie neue Pakete.
3. Den Build schützen. Isolieren Sie Jobs, begrenzen Sie Secrets, pinnen Sie Actions per Commit und beschränken Sie ausgehenden Datenverkehr, damit ein kompromittiertes Paket Ihre Tokens nirgendwohin senden kann. Siehe Runner-Sicherheit und warum Lieferkettensicherheit ins CI gehört.
4. Das Ausgelieferte weiter beobachten. Neue Schwachstellen betreffen Software, die bereits in Produktion ist. Überwachen Sie sie, ermitteln Sie die betroffenen Releases und verfolgen Sie jeden Fix bis zu einem neuen Release.

Die ausführliche Checkliste finden Sie unter Best Practices für Software-Lieferkettensicherheit.

Frameworks und Regulierung

Name	Was es ist	Ideal für
SLSA	Level für Build-Integrität und Provenienz	Härtung des Build-Prozesses
NIST SSDF	Praktiken für sichere Entwicklung, SP 800-218	Ein vollständiges Programm für sichere Entwicklung
NIST SP 800-161	Risikomanagement für die Cybersicherheit der Lieferkette	Unternehmensweites Risikomanagement
OpenSSF Scorecard	Automatisierte Prüfungen des Zustands von Open-Source-Projekten	Prüfung von Abhängigkeiten
Cyber Resilience Act	EU-Gesetz für Produkte mit digitalen Elementen	Verkauf in der EU. Siehe Was ist der CRA

Welche Tools gehören dazu?

Kein einzelnes Produkt deckt all das ab. Die Kategorie gliedert sich in SCA-Tools, SBOM-Tools, CI/CD- und Runner-Sicherheit, Paket-Firewalls, Application Security Posture Management und Binäranalyse. Was jede Kategorie leistet und wer sie anbietet, zeigen Tools für Software-Lieferkettensicherheit im Vergleich und was sie kosten.

Wo Sie anfangen sollten

1. Erzeugen Sie aus dem CI-Build Ihres wichtigsten Produkts eine SBOM und lesen Sie sie.
2. Aktivieren Sie Schwachstellenwarnungen für Abhängigkeiten und legen Sie fest, wer dafür zuständig ist.
3. Pinnen Sie Ihre GitHub Actions per Commit und prüfen Sie, welche Secrets Ihre Workflows erreichen können.
4. Beschränken Sie den ausgehenden Datenverkehr Ihrer Builds auf die Hosts, die sie tatsächlich brauchen.
5. Richten Sie eine Überwachung für das ein, was Sie ausgeliefert haben, nicht nur für das, was Sie gerade bauen.

Wie CRACI das Thema angeht

CRACI setzt beim Build an, denn der Build ist der einzige Ort, der alles sieht. Es ersetzt Ihre GitHub-gehosteten Runner durch schnellere und günstigere, die jedes Paket aufzeichnen, das ein Job lädt, auf jeder Ebene des Baums und einschließlich der aus CI-Caches wiederhergestellten Pakete. Die Egress-Richtlinie blockiert Verbindungen, die Ihr Build nicht braucht, und schützt Sie so selbst vor einem Angriff, den noch niemand gesehen hat. Anschließend gleicht CRACI das Ausgelieferte laufend mit neuen Schwachstellen ab und verfolgt jede von der Sichtung bis zum korrigierten Release. Siehe Software-Lieferkettensicherheit mit CRACI.

Software-Lieferkettensicherheit: häufig gestellte Fragen

Was ist Software-Lieferkettensicherheit?

Sie bedeutet, alles zu schützen, was in Ihre Software einfließt, bevor sie die Nutzer erreicht: Open-Source-Abhängigkeiten, Build-Systeme, Pipeline-Tools und Releases.

Was ist ein Beispiel für einen Angriff auf die Software-Lieferkette?

Beim SolarWinds-Angriff wurde der Build kompromittiert, sodass Kunden ein verseuchtes Update von einem vertrauenswürdigen Anbieter erhielten. Bei den Shai-Hulud-Angriffen verbreitete sich ein Wurm über npm-Pakete und stahl Tokens von den Rechnern, die sie installierten.

Was ist der Unterschied zwischen Lieferkettensicherheit und Anwendungssicherheit?

Anwendungssicherheit betrachtet Fehler in dem Code, den Sie schreiben. Lieferkettensicherheit betrachtet das, was Sie nicht geschrieben haben, und wie Ihre Software gebaut und veröffentlicht wird. Ein Programm braucht beides.

Reicht eine SBOM für Lieferkettensicherheit aus?

Nein. Eine SBOM sagt Ihnen, was Sie ausliefern, und das ist die Grundlage. Sie müssen außerdem steuern, was hineinkommt, den Build schützen und das Veröffentlichte weiter überwachen.

Was sind die wichtigsten Frameworks?

SLSA für Build-Integrität, das NIST SSDF für Praktiken sicherer Entwicklung und NIST SP 800-161 für Risikomanagement in der Lieferkette. In der EU legt der Cyber Resilience Act gesetzliche Anforderungen für Produkte mit digitalen Elementen fest.

Wer ist für Software-Lieferkettensicherheit zuständig?

Meist liegt sie bei der Anwendungs- oder Produktsicherheit, in Zusammenarbeit mit den Plattform- und DevOps-Teams, die die Pipelines betreiben. Fixes gehen dann an die Entwicklungsteams, die für den jeweiligen Dienst zuständig sind.