Build-Provenienz-Attestierungen: Was SLSA-Provenienz erfasst und wie sie geprüft wird

Worum es geht

Provenienz ist gemäss der SLSA-Spezifikation prüfbare Information darüber, wie ein Artefakt hergestellt wurde: welche Entität es gebaut hat, welchen Prozess sie verwendet hat und was die Eingaben waren. Der Build-Track definiert Stufen. Build L1: Provenienz existiert, möglicherweise unsigniert; sie verhindert Fehler, lässt sich aber „trivial umgehen oder fälschen“. Build L2: Eine gehostete Build-Plattform erzeugt und signiert die Provenienz, was vor nachträglicher Manipulation nach dem Build schützt. Build L3: eine gehärtete Plattform, deren Läufe sich nicht gegenseitig beeinflussen können und deren Signaturmaterial für die Provenienz für benutzerdefinierte Build-Schritte nicht zugänglich ist, was vor Manipulation während des Builds schützt. Das empfohlene Format ist eine in-toto-Attestierung mit predicateType https://slsa.dev/provenance/v1. Ihr subject listet die erzeugten Artefakte nach Digest auf. buildDefinition enthält den buildType (eine Vorlage, die den Prozess identifiziert), externalParameters (die nicht vertrauenswürdigen Eingaben, die erfasst und nachgelagert geprüft werden müssen), optionale internalParameters und resolvedDependencies (wozu die Eingaben aufgelöst wurden, etwa der genaue Commit, auf den eine Repository-URL verwies). runDetails nennt die builder.id und Metadaten zum Lauf. Die Build-Plattform signiert den Umschlag.

Warum es wichtig ist

Ein SBOM sagt, was in einem Artefakt steckt; Provenienz sagt, wer es aus was gebaut hat. Mit geprüfter Provenienz kann eine konsumierende Partei ein Paket ablehnen, das aus einem Commit gebaut wurde, der nicht im Upstream-Repository liegt, das von einem unerwarteten Workflow gebaut wurde, oder das mit Parametern gebaut wurde, die vom dokumentierten Release-Prozess abweichen. Ungeprüfte Provenienz ist nur Dokumentation.

So wird es angewendet

• Produzierende Partei: auf einer Plattform bauen, die Provenienz erzeugt und signiert, die Attestierung neben dem Artefakt veröffentlichen und den Build-Prozess konsistent halten, damit konsumierende Parteien Erwartungen daran bilden können.
• Konsumierende Partei: den Schritten der Spezifikation folgen. Die Signatur des Umschlags gegen konfigurierte Vertrauenswurzeln prüfen (eine Zuordnung von Builder-Identität zur Stufe, für die ihr vertraut wird); prüfen, dass der subject-Digest zum Artefakt passt und predicateType der SLSA-Provenienztyp ist; dann buildType und externalParameters mit erwarteten Werten vergleichen. Die Spezifikation besagt, dass unerkannte externe Parameter die Prüfung fehlschlagen lassen sollten.
• Vor dem Aktivieren der Prüfung die Fehlschlag-Aktion festlegen (blockieren, warnen, protokollieren) und mit Artefakten beginnen, bei denen beide Enden selbst kontrolliert werden.

Stolpersteine

L1-Provenienz ist fälschbar; sie fängt Fehler ab, nicht Angreifer. Einer builder.id zu vertrauen, ohne deren Schlüssel- oder Zertifikatsidentität festzupinnen, macht die Signatur bedeutungslos. Provenienz deckt den Build ab, nicht die Quellcode-Prüfung und nicht die eigenen Builds der Abhängigkeiten; dafür sind die optionale rekursive Abhängigkeitsprüfung der Spezifikation und ihr separater Source-Track zuständig.