Zum Inhalt

Framework-Übersicht: SLSA (Supply-chain Levels for Software Artifacts)

SLSA (ausgesprochen "Salsa") ist ein branchenübergreifendes, standardisiertes Sicherheits-Framework, das darauf abzielt, die Integrität der Software-Lieferkette (Software Supply Chain) zu gewährleisten.

Das Kernprinzip von SLSA ist die Etablierung einer lückenlosen, kryptografisch überprüfbaren Beweiskette (Provenance) vom ersten Code-Commit bis zum auslieferbaren Software-Paket (Artefakt).

Die Architektur von SLSA: Tracks und Level

Um die Komplexität der Software-Entwicklung abzubilden, unterteilt SLSA die Sicherheitsanforderungen in verschiedene Verantwortungsbereiche, sogenannte Tracks. Innerhalb dieser Tracks werden ansteigende Reifegrade (Levels) definiert, die es Organisationen ermöglichen, ihre Sicherheit schrittweise zu erhöhen.

1. Source Track (Quellcode-Integrität)

Der Source Track bewertet die Vertrauenswürdigkeit des Quellcodes und die Prozesse zur Code-Erstellung. Das Ziel ist es, sicherzustellen, dass jede Änderung am Code gewollt und nachvollziehbar ist.

  • Source L1 (Version controlled): Der Code wird in einem modernen Versionskontrollsystem verwaltet.

  • Source L2 (History & Provenance): Die Änderungshistorie (Change History) ist kontinuierlich, unveränderlich und es werden Herkunftsnachweise (Source Provenance) für Code-Revisionen erstellt.

  • Source L3 (Continuous technical controls): Die Organisation erzwingt technische Kontrollen (z. B. automatisierte Tests) auf geschützten Branches und weist diese nach.

  • Source L4 (Two-party review): Jede Änderung an geschützten Branches erfordert zwingend das Review durch zwei vertrauenswürdige Personen (4-Augen-Prinzip), was den Schutz vor Innentätern (Insider Threats) drastisch erhöht.

2. Build Track (Prozess- und Infrastruktursicherheit)

Der Build Track definiert technische Anforderungen an die Plattform (Build-Infrastruktur, CI/CD-Pipelines), die den Quellcode in ein fertiges Artefakt transformiert.

  • Build L0 (No guarantees): Es gibt keine Garantien (z. B. ein lokaler Build auf einem Entwickler-Rechner).

  • Build L1 (Provenance exists): Es existiert ein Nachweis (Provenance), wie das Paket gebaut wurde, um operative Fehler zu erkennen.

  • Build L2 (Hosted build platform): Der Build läuft auf einer gehosteten Plattform, die den Nachweis (Provenance) selbst generiert und kryptografisch signiert. Dies schützt vor Manipulationen nach dem Build.

  • Build L3 (Hardened builds): Der Build läuft auf einer gehärteten Plattform in einer strikt isolierten, ephemeren Umgebung. Dies verhindert, dass laufende Builds sich gegenseitig beeinflussen oder geheime Schlüssel (Secrets) kompromittiert werden, und schützt vor Manipulationen während des Builds.

Technische Nachweisbarkeit (Attestations)

Die GRC-Relevanz von SLSA ergibt sich aus der Möglichkeit, Compliance automatisiert zu prüfen. Hierfür nutzt das Framework standardisierte, maschinenlesbare Nachweise (Attestations):

  • Provenance Attestations: Detailprotokolle, die fälschungssicher dokumentieren, wie eine Code-Revision entstanden ist oder wie ein Artefakt gebaut wurde.

  • Verification Summary Attestations (VSAs): Zusammenfassende Bescheinigungen (oft im in-toto Format), die von einer vertrauenswürdigen Instanz ausgestellt werden. Sie bestätigen gegenüber Endkonsumenten oder Systemen (z. B. einem Kubernetes Admission Controller), dass ein Artefakt erfolgreich auf ein bestimmtes SLSA-Level (z. B. SLSA_SOURCE_LEVEL_3) geprüft wurde.

Overtime Mapping

(Hier folgt in Kürze eine Matrix, die relevante Beispiele des Overtime Projekts zu einzelen Themenseiten mappt)

Die beste Quelle für SLSA ist die offizielle Dokumentation. Es gibt viel Blog-Einträge zu dem Thema, aber diese beziehen sich auf verschiedene Versionen und definieren SLSA oft so, dass ihr Produkt dafür relevant ist. s