Ein Software-Supply-Chain-Angriff kompromittiert nicht nur die Zielorganisation, sondern einen Bestandteil ihrer Lieferkette: Quellcode, Abhängigkeiten, Build-Systeme, Artefakt-Repositorys, Updates oder Dienstleister. Ein erfolgreicher Eingriff kann sich über eine vertrauenswürdige Software an viele Kunden verteilen.
Was gehört zur Software-Lieferkette?
Die Lieferkette beginnt nicht erst beim fertigen Installationspaket. Sie umfasst Entwicklerkonten und Quellcode, Open-Source- und kommerzielle Abhängigkeiten, Paketquellen, CI/CD-Pipelines, Compiler und Container-Basisimages, Signatur- und Update-Infrastruktur sowie externe Entwicklungs- und Betriebsdienste. Eine Software Bill of Materials beschreibt gelieferte Komponenten, bildet aber weder den gesamten Buildprozess noch alle Zugriffs- und Vertrauensbeziehungen ab.
Nicht jedes Problem in einer Abhängigkeit ist ein Supply-Chain-Angriff. Eine gewöhnliche, unbeabsichtigte Schwachstelle wird über CVE, Versionsinventar und Updates behandelt. Bei einem Supply-Chain-Angriff manipuliert ein Angreifer dagegen gezielt eine vertrauenswürdige Quelle oder einen Schritt der Herstellung und Verteilung. Ein Beispiel für diesen Angriffsweg ist Dependency Confusion.
Wo kann die Lieferkette angegriffen werden?
| Phase | Beispiel | Kontrolle |
|---|---|---|
| Entwicklung | Gestohlener Entwicklerzugang, manipuliertes Repository oder eingeschleuster Commit. | MFA, Reviews, Branch-Schutz, signierte Commits. |
| Abhängigkeiten | Schädliches Paket, Typosquatting oder Dependency Confusion. | Lockfiles, interne Namespaces, Provenance, SCA. |
| Build | Manipulierte CI/CD-Runner, Skripte oder gestohlene Signing Keys. | Isolierte Builds, minimale Secrets, reproduzierbare Artefakte. |
| Verteilung | Repository oder Updatekanal liefert veränderte Binärdateien. | Signaturen, Hashes, TUF/Sigstore, getrennte Rollen. |
| Betrieb | Unsicherer Dienstleisterzugang oder kompromittiertes Managed Update. | Segmentierung, Monitoring, vertragliche Meldewege. |
Warum reicht ein Vulnerability Scanner nicht?
Ein Scanner findet bekannte Schwachstellen in identifizierten Komponenten. Er erkennt nicht automatisch, dass ein legitimes Paket absichtlich bösartig wurde, ein Build-Server andere Quellen verwendete oder ein signiertes Update mit gestohlenem Schlüssel erzeugt wurde. Supply-Chain-Sicherheit benötigt deshalb Identität, Integrität, nachvollziehbare Herkunft und Überwachung entlang des gesamten Prozesses.
Wie wird ein Angriff erkannt und eingegrenzt?
Warnsignale sind neue Maintainer oder Paketquellen, unerwartete Lockfile-Änderungen, Netzwerkzugriffe in Builds, abweichende Hashes, neue Signaturschlüssel und Artefakte, die sich nicht reproduzieren lassen. Protokolle aus Repository, Identitätsplattform, Buildsystem, Registry und Signaturdienst müssen deshalb zusammengeführt werden. Bei einem Vorfall sind betroffene Versionen, Buildläufe, Schlüssel, Kunden und Laufzeitumgebungen zu bestimmen. Zugangsdaten werden rotiert, Artefakte gesperrt und korrigierte Releases über einen vorab festgelegten Meldeweg veröffentlicht.
Praktische Mindestmaßnahmen
- Inventar:
Eine SBOM je Release erzeugen und mit ausgelieferten Artefakten verknüpfen. - Abhängigkeiten:
Versionen sperren, Herkunft festlegen und neue Pakete beziehungsweise Maintainer-Wechsel prüfen. - Build:
Ephemere, gehärtete Runner; minimale Rechte; getrennte Signing-Schlüssel; nachvollziehbare Provenance. - Secrets:
Secrets nicht in Code oder Images einbauen und kurzlebige Credentials bevorzugen. - Reaktion:
Betroffene Komponenten, Kunden, Schlüssel und Releases schnell bestimmen und Widerruf sowie Updates vorbereiten.
Beispiel für eine kontrollierte Installation
# Lockfile unverändert verwenden; keine stillen Versionsupdates
npm ci --ignore-scripts
# Komponenten und bekannte Schwachstellen erfassen
syft dir:. -o cyclonedx-json > sbom.json
osv-scanner scan --sbom sbom.json
--ignore-scripts ist nicht für jedes Projekt möglich und keine vollständige Absicherung. Es zeigt
aber, dass Installationsskripte fremden Code bereits während des Builds ausführen können. Ausnahmen sollten
bewusst, überprüfbar und in isolierten Umgebungen erfolgen.
Nützliche Open-Source-Werkzeuge
Syft erzeugt SBOMs, OSV-Scanner und Trivy prüfen Komponenten. Cosign signiert und verifiziert Artefakte, während in-toto Lieferkettenschritte und Attestierungen abbildet. Die Werkzeuge ergänzen Prozesse; sie beweisen allein nicht, dass Quellcode oder Buildumgebung vertrauenswürdig waren.
Supply-Chain-Sicherheit und Regulierung
Der Cyber Resilience Act verbindet Schwachstellenbehandlung, Produktpflege und Informationen über Komponenten mit Pflichten für Hersteller. Ein Vulnerability Disclosure Program schafft einen verlässlichen Eingang für externe Hinweise. Beide ersetzen keine technische Absicherung, machen Verantwortlichkeiten und Reaktionswege aber überprüfbar.
Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.