Software‑Lieferkettensicherheit: SBOMs, Artefakt‑Signierung und die neue Baseline

Im Jahr 2020 kompromittierten Angreifer SolarWinds’ Build‑Pipeline und verteilten ein mit Hintertür versehenes Update an etwa 18 000 Kunden, darunter US‑Regierungsbehörden. Ein Jahr später wurde ein bösartiges Paket in den Codecov‑Bash‑Uploader eingeschleust, woraufhin Geheimnisse aus Tausenden von CI‑Pipelines preisgegeben wurden. Im gleichen Jahr dauerte es Monate, eine kritische Schwachstelle in Log4j – einer in Hunderttausenden von Anwendungen eingesetzten Logging‑Bibliothek – vollständig zu beheben, weil Organisationen nicht wussten, wo sie sie einsetzten. Das Fehlen einer genauen Inventarisierung verzögerte die Identifikation aller betroffenen Systeme erheblich.

Diese Vorfälle verbinden ein gemeinsames Thema: Die Angriffsfläche lag nicht im Anwendungscode, sondern in der Pipeline, die ihn baut und liefert. Software‑Lieferkettensicherheit ist die Disziplin, die die gesamte Kette vom Quellcode bis zum laufenden Artefakt überprüft – nicht nur den Code selbst, weil Angreifer dort bereits vor dem Ausführungszeitpunkt Schadcode einschleusen können.

Was eine Software‑Lieferkette ist

Jede Software hat eine Lieferkette: den Quellcode, die importierten Abhängigkeiten, die Werkzeuge, die ihn kompilieren, die Pipeline, die ihn baut, die Registry, die das Artefakt speichert, und die Infrastruktur, die es ausführt. Ein Angreifer, der ein beliebiges Glied in dieser Kette kompromittieren kann, kann das Endprodukt kompromittieren.

Quellcode
    ↓
Abhängigkeiten (npm, Maven, PyPI, Go‑Module)
    ↓
Build‑Werkzeuge (Compiler, Bundler, Test‑Runner)
    ↓
CI/CD‑Pipeline (GitHub Actions, Jenkins, GitLab CI)
    ↓
Artefakt‑Registry (Docker Hub, ECR, Artifactory)
    ↓
Deployment‑Infrastruktur (Kubernetes, ECS, Lambda)
    ↓
Laufende Anwendung

Traditionelle Sicherheit konzentrierte sich auf den Anwendungscode. Lieferkettensicherheit schaut jedoch auf jeden Pfeil in diesem Diagramm, weil Angreifer dort bereits vor dem Laufzeit‑Moment Schadcode einbringen können.

SBOMs: Wissen, was man ausliefert

Ein Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar jeder Komponente in einem Software‑Artefakt: Bibliotheken, Frameworks, Betriebssystempakete und ihre Versionen und Lizenzen. Es ist das Software‑Äquivalent einer Zutatenliste. Damit lässt sich automatisiert prüfen, ob bekannte Schwachstellen in einer der Komponenten existieren.

Die US‑amerikanische Cybersecurity and Infrastructure Security Agency (CISA) veröffentlichte 2021 Mindest‑SBOM‑Elemente und aktualisierte Leitlinien 2023. Diese Leitlinien etablieren diese als Baseline‑Erwartung für Software, die an US‑Bundesbehörden verkauft oder von ihnen verwendet wird – und zunehmend für jede Organisation, die Lieferkettensicherheit ernst nimmt.

SBOM‑Formate

Zwei Formate dominieren:

SPDX (Software Package Data Exchange): ein ISO‑Standard (ISO/IEC 5962:2021), ursprünglich von der Linux Foundation entwickelt und breit durch Open‑Source‑Tooling unterstützt.

CycloneDX: von OWASP entwickelt, speziell für Sicherheitsanwendungsfälle konzipiert. Es unterstützt Schwachstellendaten, Lizenz‑Compliance und Abhängigkeitsgraphen.

// CycloneDX SBOM‑Fragment
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{ "alg": "SHA-256", "content": "abc123..." }]
    }
  ]
}

SBOMs generieren

SBOMs können zur Build‑Zeit aus Paket‑Manifests generiert oder durch Scannen von Container‑Images erstellt werden:

# SBOM aus einem Container‑Image generieren (Syft)
syft nginx:latest -o cyclonedx-json > nginx-sbom.json

# SBOM aus einem Node.js‑Projekt generieren
syft dir:. -o spdx-json > app-sbom.json

# SBOM auf bekannte Schwachstellen scannen (Grype)
grype sbom:./app-sbom.json

Der erste Befehl erzeugt ein CycloneDX-SBOM für ein Docker-Image; der zweite nutzt dasselbe Tool, um ein Node-Projekt zu analysieren; der dritte prüft das erzeugte SBOM gegen bekannte Schwachstellen. Das SBOM ist nur dann nützlich, wenn es präzise und aktuell ist. Ein veraltetes SBOM, das das tatsächliche Artefakt nicht widerspiegelt, ist schlimmer als kein SBOM – es erzeugt falsches Vertrauen. Teams, die veraltete SBOMs benutzen, übersehen neue Schwachstellen dadurch.

Artefakt‑Signierung: Verifizieren, was man bereitstellt

Zu wissen, was in einem Artefakt steckt, reicht nicht aus, wenn man nicht verifizieren kann, dass das Artefakt zwischen Build und Deployment nicht manipuliert wurde. Artefakt‑Signierung bietet diese Garantie.

Sigstore und Cosign

Sigstore ist ein Open‑Source‑Projekt (unterstützt von der Linux Foundation, Google, Red Hat und Purdue University), das eine kostenlose, transparente Signierungsinfrastruktur bereitstellt. Cosign ist sein Werkzeug zum Signieren und Verifizieren von Container‑Images und anderen Artefakten.

# Container‑Image signieren (schlüssellos, mit OIDC‑Identität)
cosign sign ghcr.io/myorg/myapp:v1.2.3

# Vor dem Deployment verifizieren
cosign verify ghcr.io/myorg/myapp:v1.2.3 \
  --certificate-identity=https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Durch die schlüssellose Variante wird das Vertrauen in die Identität des CI‑Jobs gelegt, weil das OIDC‑Token kryptografisch signiert ist. Schlüsselloses Signieren verwendet die OIDC‑Identität des CI‑Systems (z. B. einen GitHub‑Actions‑Workflow) anstelle eines langlebigen Schlüssels. Das Signierereignis wird in Rekor aufgezeichnet, Sigstores transparentem Protokoll – einem manipulationssicheren, nur‑anhänge‑fähigen Datensatz jedes Signierereignisses. Damit lässt sich später prüfen, ob das Image von dem erwarteten Build‑Workflow stammt.

SLSA: Supply‑chain Levels for Software Artifacts

SLSA (ausgesprochen „Salsa“) ist ein von Google entwickeltes und jetzt von der OpenSSF gepflegtes Framework, das vier Ebenen der Lieferkettenintegrität definiert:

Ebene	Was es garantiert
SLSA 1	Build‑Prozess ist dokumentiert; SBOM wird generiert
SLSA 2	Build wird auf einer versionskontrollierten Plattform gehostet; Provenienz wird generiert
SLSA 3	Build ist isoliert; Provenienz ist nicht fälschbar
SLSA 4	Zwei‑Personen‑Review; hermetische, reproduzierbare Builds

SLSA‑Provenienz ist eine signierte Bescheinigung, die beschreibt, wie ein Artefakt gebaut wurde: welcher Quell‑Commit, welches Build‑System, welche Eingaben und welche Schritte unveränderlich dokumentiert wurden.

Abhängigkeitsintegrität

Abhängigkeiten sind die größte Angriffsfläche in den meisten Software‑Lieferketten. Dependency‑Confusion‑Angriffe (bei denen ein bösartiges Paket mit demselben Namen wie ein internes Paket in einer öffentlichen Registry veröffentlicht wird) und Typosquatting‑Angriffe (bei denen ein Paket mit einem ähnlichen Namen wie ein beliebtes Paket veröffentlicht wird und bösartigen Code enthält) sind gut dokumentiert.

Gegenmaßnahmen:

Lock‑Dateien mit Integritäts‑Hashes. Lock‑Dateien (package‑lock.json, yarn.lock, Pipfile.lock, go.sum) enthalten exakte Versions‑ und Hash‑Angaben jeder Abhängigkeit. Sie müssen im Repository versioniert und von der CI aus der Lock‑Datei installiert werden, nicht aus einem schwimmenden Versionsbereich.

Private Registries mit Allow‑Lists. Alle Abhängigkeitsabrufe über eine private Registry (Artifactory, Nexus, AWS CodeArtifact) leiten, die nur genehmigte Pakete proxyt. Das verhindert Dependency‑Confusion‑Angriffe.

Automatisiertes Schwachstellen‑Scanning. Tools wie Dependabot, Renovate, Snyk und OWASP Dependency‑Check scannen Abhängigkeiten gegen bekannte Schwachstellendatenbanken (NVD, OSV) und öffnen Pull‑Requests für Updates.

# GitHub Dependabot‑Konfiguration
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Dieses Beispiel zeigt, wie Dependabot wöchentlich nach Updates für npm‑Pakete sucht und maximal zehn gleichzeitige Pull‑Requests eröffnet.

Eine minimale Lieferkettensicherheits‑Baseline

Für die meisten Teams sieht eine praktische Baseline so aus:

1. SBOM zur Build‑Zeit generieren und an jedes Release‑Artefakt anhängen, damit jeder Verbraucher sofort prüfen kann, welche Komponenten enthalten sind.
2. Artefakte signieren mit Cosign und schlüssellosem Signieren in CI; der Signatur‑Header wird im Image‑Manifest verankert.
3. Signaturen vor dem Deployment verifizieren – in der CD‑Pipeline und in Admission‑Controllern (z. B. Kyverno oder OPA Gatekeeper in Kubernetes). Ein abgelehntes Deployment verhindert das Einschleusen manipulierten Codes.
4. Abhängigkeiten sperren und bei jedem Pull‑Request auf Schwachstellen scannen; der Scan ist Teil des CI‑Jobs und blockiert das Mergen bei kritischen Findings.
5. Private Registry verwenden, um Dependency‑Confusion zu verhindern; nur freigegebene Pakete werden aus dem internen Proxy gezogen.
6. Die CI‑Pipeline selbst auditieren: Zugriff auf Workflow‑Dateien einschränken, gepinnte Action‑Versionen nach Commit‑Hash verwenden (nicht nach Tag) und Secrets regelmäßig rotieren. Ein minimaler Zugriff reduziert das Risiko, dass ein Angreifer die Build‑Umgebung kompromittiert.

Warum Signierung allein nicht ausreicht

Artefakt‑Signierung beweist, dass ein Image von einer bestimmten Identität zu einem bestimmten Zeitpunkt signiert wurde. Sie beweist jedoch nicht, dass das Image frei von Schwachstellen ist, dass der Build‑Prozess vor der Signierung nicht kompromittiert wurde, oder dass der Quellcode überprüft wurde. Signierung ist eine Kontrolle in einer mehrschichtigen Verteidigung – sie schließt die Lücke bei Manipulation während des Transports, aber nicht die Lücken bei kompromittierten Builds oder anfälligen Abhängigkeiten.

Deshalb sind SLSA‑Stufen wichtig: Sie erweitern die Vertrauenskette rückwärts vom signierten Artefakt zum Build‑Prozess selbst. Eine SLSA‑3‑Bescheinigung sagt nicht nur „dieses Image wurde signiert“, sondern „dieses Image wurde aus diesem spezifischen Commit von dieser spezifischen isolierten Pipeline gebaut, und diese Behauptung ist nicht fälschbar.“ Die Kombination aus Signierung (Cosign) und Provenienz (SLSA) schließt erheblich mehr der Lieferketten‑Angriffsoberfläche als jedes allein.