Nach SolarWinds, Codecov und anderen Angriffen auf die Build-Kette mussten Softwarekonsumenten wissen können, ob ein Artefakt aus der erwarteten Quelle und dem erwarteten Build-Prozess stammte. Eine Binärdatei allein konnte diese Frage nicht beantworten.
Der Ansatz von SLSA bestand nicht darin, sofort Perfektion zu verlangen. Googles Vorschlag aus dem Jahr 2021 beschrieb vier schrittweise übernehmbare Stufen, beginnend mit automatisierten Builds, die Provenienz erzeugen, und aufsteigend zu stärkerer Build-Isolation, Überprüfung und Reproduzierbarkeit.
Die Spezifikation v1.0 verfeinerte dies zu Tracks und Stufen: ein gemeinsames Vokabular, eine Checkliste und ein Evidenzmodell für Produzenten, Konsumenten und Infrastrukturanbieter. Das Format setzte sich durch, indem es Teilfortschritte sichtbar machte, statt Sicherheit als Alles-oder-nichts zu behandeln.
Integrität zu einer Leiter machen, nicht zu einem Schalter
Stufen ermöglichten es Organisationen, eine bestimmte Integritätshaltung zu beanspruchen, ohne vorzugeben, jede Abhängigkeit sei perfekt.
Provenienz machte den Build-Prozess für Policy-Engines und Konsumenten überprüfbar.
Das Framework ordnete abstrakte Supply-Chain-Risiken konkreten Kontrollen für Quelle, Build und Verteilung zu.
Niedrigere Stufen schufen einen Upgrade-Pfad für Projekte, die nicht direkt zur höchsten Messlatte springen konnten.
Wenn der Idealstandard für die meisten Nutzer zu teuer ist, kann die Übernahme damit beginnen, Teilgarantien zu benennen, die das Risiko dennoch verringern.
SLSA wurde zu einer gemeinsamen Sprache für die Integrität von Softwareartefakten. Seine Stufen werden heute zusammen mit SBOMs, Sigstore und in-toto-Attestierungen genutzt, um zu entscheiden, ob ein Paket von einem erwarteten System aus erwarteter Quelle gebaut wurde.
DEN BELEGEN FOLGEN
Die Quellen
- Introducing SLSA, an End-to-End Framework for Supply Chain Integrity Google Online Security Blog · security.googleblog.com ·
- About SLSA SLSA Specification 1.0 · slsa.dev