Zusammenfassung

  • SLSA v1.2 behandelt Provenance als Beleg, der gegen Erwartungen geprüft werden muss; die Attestierung entscheidet nicht von selbst.
  • Die Spezifikation trennt artefaktgebundene Erklärung, Vertrauenswurzel, paketnamengebundene Erwartung und die Annahme durch Ökosystem, Verbraucher oder Monitor.
  • Ein Erwartungs- und Reaktionsbeleg verhindert, dass eine gültige Attestierung als allgemeine Release-Freigabe gelesen wird.

Der Beleg gilt einem Artefakt

Das SLSA-Modell für Build-Provenance erklärt nicht allgemein ein Projekt für sicher. Es attestiert, dass eine konkrete Build-Plattform Artefakte durch eine buildDefinition erzeugt hat. subject kann an einen Digest gebunden sein; Builder, Build-Typ, Parameter und Abhängigkeiten können geprüft werden. Damit lässt sich vergleichen, ob ein wirklicher Build dem erwarteten Build entspricht, und der Vorgang kann bei Bedarf untersucht oder nachgebaut werden.

Die Verteilungsregeln ziehen dieselbe Grenze: Attestierungen sollen an Artefakte und nicht an Releases gebunden werden. Ein Release kann Dateien für verschiedene Architekturen und Umgebungen umfassen, die zu unterschiedlichen Zeitpunkten entstanden sind; später können weitere Artefakte und Attestierungen dazukommen. Ein Release-Name ersetzt deshalb nicht den prüfbaren Bezug zwischen einer einzelnen Datei und ihrem Beleg.

Diese Begrenzung ist keine Schwäche. SLSA sagt ausdrücklich, dass Provenance nichts tut, solange niemand sie inspiziert. Es gibt drei Vorgänge: Beleg erzeugen, ihn gegen Erwartungen vergleichen, anschließend über Annahme, Ablehnung, Quarantäne oder Beobachtung entscheiden. Ein pauschales „freigegeben“ verwischt diese Vorgänge und macht spätere Korrektur schwer.

Erwartungen wählt der Prüfer

SLSA fordert vom Prüfer Vertrauenswurzeln: anerkannte Builder-Identitäten und den Build-Level, bis zu dem jede Identität akzeptiert wird. Danach sind Signatur, Zusammenhang zwischen subject und Artefaktdigest sowie buildType und externalParameters gegen die erwarteten Werte zu prüfen.

Eine korrekt signierte Attestierung wählt diese Erwartungswerte nicht. Unterschiedliche Prüfer dürfen verschiedene Vertrauenswurzeln besitzen. SLSA unterscheidet Erwartungen, die an einen Paketnamen gebunden sind, von Provenance, die an ein Artefakt gebunden ist. Ein Ökosystem kann ein kanonisches Quell-Repository festlegen; ein Verbraucher kann eigene Regeln anwenden; ein Produzent kann Erwartungen über einen authentisierten Kanal mitteilen; Trust-on-first-use kann den ersten Zustand als Vergleichsbasis verwenden. Das beantwortet eine andere Frage als die Attestierung: Was ist für dieses Paket in diesem Zusammenhang zulässig?

externalParameters zeigen die Grenze klar. Sie stehen unter externer Kontrolle, müssen erfasst und nachgelagert geprüft werden. Ihre Anwesenheit bedeutet keine Zulassung; nicht erkannte Parameter sollen abgelehnt werden. Auch ein aufgeführtes builder.id zwingt niemanden, den Builder in die eigene Vertrauenswurzel aufzunehmen. Authentizität verbindet Aussage und Aussteller; Vertrauen bleibt eine Richtlinienentscheidung.

Der Annahmepunkt hat einen Eigentümer

SLSA nennt die Prüfung beim Upload in ein Paketökosystem, beim Herunterladen oder Verwenden durch den Verbraucher und durch einen Monitor. Diese Orte können nebeneinander bestehen. Ein Register entscheidet über Aufnahme, ein Verbraucher über Installation oder Deployment, ein Monitor über die Veröffentlichung eines Befunds. Der Standard weist darauf hin, dass das Erkennen eines Fehlers nur begrenzt nützt, wenn keine menschliche oder automatisierte Reaktion folgt.

Dasselbe Artefakt kann folglich unter einer Regel angenommen, unter einer anderen abgelehnt oder von einem Monitor gemeldet und noch nicht bearbeitet sein. Das ist kein Widerspruch der Provenance, sondern die Folge verschiedener Entscheidungsträger. Die Verteilungsspezifikation beschreibt Provenance als das, was ein Repository zur Prüfung einer möglichen Richtlinie für Veröffentlichung benötigt. Sie ist weder die Richtlinie noch ihre Durchsetzung noch der Nachweis erfolgter Annahme.

Ein Beleg für Erwartung und Reaktion

Nötig ist kein neues SLSA-Format. Sinnvoll ist ein kurzer Beleg neben der Prüfentscheidung: Artefaktdigest und Attestierungsreferenz, Prüfer und Richtlinienversion, tatsächlich verwendete Vertrauenswurzel, erwartete kanonische Quelle, buildType, erlaubter Parameterbereich, Prüfzeitpunkt und Ergebnis.

Bei einem Fehler sollte er Ablehnung, Quarantäne, Alarm, befristete Ausnahme oder Wartestatus sowie die Stelle nennen, die den Status ändern darf. Ändert sich eine Erwartung, muss die autorisierte Änderung verlinkt werden, statt das alte Ergebnis still umzuschreiben. Das verspricht keine universelle Sicherheit oder vollständige Abhängigkeitsprüfung. Es hält aber authentischen Beleg, angenommene Datei, Richtlinienwechsel, Alarm und erledigte Reaktion auseinander.

Grenze bewahren, Wahl bewahren

Heng Lus Gedanke ist hier Methode, nicht SLSA-Beweis: Ein Koordinierungsdatensatz darf nur die Autorität beanspruchen, die er tatsächlich besitzt. SLSA beschreibt Erzeugung, Verteilung und Prüfung von Provenance; es ersetzt nicht die unabhängigen Entscheidungen über Vertrauen, Erwartung und Folge.

Der teure Kurzschluss vereint authentischen Build, angenommenes Paket, abgeschlossenes Release und wirksame Reaktion in einer Behauptung. Bei Wechsel der Vertrauenswurzel, neuer Architektur, ablaufender Ausnahme oder Monitorbefund lässt sich diese Behauptung nicht mehr zerlegen. Der Beleg erhält die Teile getrennt und dennoch anschlussfähig.

Quellen

  1. SLSA v1.2 — Build: Verifying artifacts
  2. SLSA v1.2 — Build: Provenance
  3. SLSA v1.2 — Build: Distributing provenance