SLSA-Provenienz: Wie Supply-Chain-Sicherheit durch verifizierbare Metadaten gestärkt wird

Die jüngste Cyberattacke auf SolarWinds mit dem SUNSPOT-Malware zeigte: Selbst signierte Software und SBOMs (Software Bill of Materials) reichen nicht aus, um Lieferketten vor gezielten Angriffen zu schützen. Die Schwachstelle lag nicht im Code selbst, sondern im fehlenden Nachweis darüber, wie und wo der Code entstanden ist. An dieser Stelle setzt SLSA-Provenienz an – ein Framework, das verlässliche Metadaten über Herkunft, Erstellungsprozess und Umgebung eines Softwareartefakts liefert. Damit wird es möglich, Manipulationen wie bei SolarWinds frühzeitig zu erkennen und zu verhindern.

Was ist SLSA-Provenienz und warum ist sie entscheidend?

SLSA-Provenienz ist eine verifizierbare Attestierung, die den gesamten Lebenszyklus eines Softwareartefakts dokumentiert – von der Quellcode-Entnahme bis zur finalen Kompilierung. Technisch handelt es sich um eine in-toto-Statement, die den SLSA-Spezifikationen entspricht und in einem DSSE-Umschlag (Digital Signature Standard Envelope) signiert wird. Diese Struktur stellt sicher, dass die Daten nicht nachträglich verändert werden können. Im Gegensatz zu einfachen Signaturen oder SBOMs bezieht SLSA-Provenienz auch den Build-Prozess und die Build-Umgebung ein, was eine lückenlose Rückverfolgbarkeit ermöglicht.

Ein zentraler Vorteil liegt in der Angriffsresistenz: Selbst wenn Schadcode in den Build-Prozess eingeschleust wird, lässt sich dies durch die Provenienz nachweisen. So wird verhindert, dass manipulierte Artefakte als vertrauenswürdig gelten. Unternehmen können damit nicht nur Compliance-Anforderungen erfüllen, sondern auch das Vertrauen in ihre Software-Lieferkette stärken.

SLSA-Provenienz mit GitHub Actions generieren

Die Generierung von SLSA-Provenienz ist dank des offiziellen Tools `slsa-github-generator` besonders einfach umsetzbar. Dieses Tool erfüllt die höchsten SLSA-Level (L3) und nutzt GitHubs OIDC-Tokens sowie wiederverwendbare Workflows, um eine manipulationssichere Build-Umgebung zu schaffen. Der Clou: Der Nutzercode hat keinen Zugriff auf den internen Zustand des Builders, was das Risiko von Supply-Chain-Angriffen weiter reduziert.

So lässt sich die Provenienz in drei Schritten erstellen:

• 1. Vorbereitung: Einrichten eines GitHub-Repositorys mit dem zu bauenden Projekt. Der Build muss als GitHub Action definiert werden.
• 2. Konfiguration: Verwendung des slsa-github-generator in der Workflow-Datei. Das Tool generiert automatisch die Provenienzdatei und signiert sie.
• 3. Veröffentlichung: Das Artefakt wird zusammen mit der Provenienzdatei (.intoto.jsonl) bereitgestellt.

Ein Beispiel für die Workflow-Konfiguration:

github:
  workflows:
    - name: SLSA Provenance Generator
      uses: slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@v1.9.0
      with:
        go-version: "1.21"

SLSA-Provenienz mit slsa-verifier überprüfen

Die Überprüfung der Provenienz erfolgt mit dem Tool `slsa-verifier`, das die Integrität eines Artefakts gegen die erwarteten Metadaten validiert. Besonders hilfreich ist dies für die Selbstvalidierung: Auch die Tools selbst (wie slsa-verifier) werden mit SLSA-Provenienz ausgeliefert, sodass Nutzer deren Herkunft prüfen können.

Schritt-für-Schritt-Verifikation am Beispiel von slsa-verifier

1. Artefakt herunterladen:

Der Nutzer lädt das Binary (z. B. slsa-verifier-darwin-arm64) und die dazugehörige Provenienzdatei (slsa-verifier-darwin-arm64.intoto.jsonl) aus dem Release herunter.

1. Verifikationsbefehl ausführen:

Mit dem folgenden Kommando wird die Provenienz überprüft:

slsa-verifier verify-artifact slsa-verifier-darwin-arm64 \
  --provenance-path slsa-verifier-darwin-arm64.intoto.jsonl \
  --source-uri github.com/slsa-framework/slsa-verifier \
  --source-tag v2.7.1

1. Ergebnis prüfen:

Das Tool gibt eine Bestätigung aus, wenn das Artefakt den SLSA-Anforderungen entspricht. Bei Abweichungen (z. B. geänderter Quellcode oder Build-Umgebung) wird dies explizit gemeldet.

Die Überprüfung ist besonders wertvoll für Unternehmen, die Open-Source-Software in kritischen Umgebungen einsetzen. Sie können damit sicherstellen, dass die genutzten Bibliotheken und Tools nicht manipuliert wurden.

SLSA-Provenienz als Standard für sichere Lieferketten

Die SolarWinds-Attacke war ein Weckruf für die Tech-Branche. SLSA-Provenienz bietet eine technische Lösung, um solche Vorfälle künftig zu verhindern. Durch die Kombination aus automatisierter Generierung (mit Tools wie slsa-github-generator) und unabhängiger Verifikation (mit slsa-verifier) entsteht ein mehrstufiges Sicherheitsnetz.

Während SBOMs bereits einen wichtigen Schritt darstellen, geht SLSA-Provenienz einen Schritt weiter: Sie dokumentiert nicht nur, was gebaut wurde, sondern auch wie und wo. Für Entwicklerteams bedeutet dies mehr Aufwand in der Einrichtung, doch der Nutzen überwiegt – insbesondere in regulierten Branchen wie Finanzen oder Gesundheitswesen.

Die Zukunft der Supply-Chain-Sicherheit wird davon abhängen, wie schnell sich solche Frameworks durchsetzen. Erste Schritte sind bereits gemacht: GitHub unterstützt SLSA-Provenienz nativ, und weitere CI/CD-Tools arbeiten an der Integration. Langfristig könnte SLSA zum de facto Standard für vertrauenswürdige Software werden – ähnlich wie HTTPS für sichere Webverbindungen.

Für Entwickler und Security-Teams lohnt es sich daher, die Möglichkeiten von SLSA heute zu erkunden – bevor Angreifer die nächste Lücke in der Lieferkette ausnutzen.