Source Provenance (Quellcode-Herkunftsnachweis)

Source Provenance bezeichnet den kryptographisch abgesicherten Nachweis darüber, woher der Quellcode eines Software-Artefakts stammt und welche Qualitätssicherungsschritte vor der Auslieferung durchlaufen wurden. Im Gegensatz zur Build Provenance, die den Build-Prozess dokumentiert, fokussiert sich Source Provenance auf den Entwicklungsprozess selbst.

Was wird nachgewiesen?

Eine Source Provenance Attestierung dokumentiert die folgenden Aspekte des Quellcodes:

• Code-Ursprung: Exakte Referenz auf Commit-Hash, Branch, Tag und Repository-URL — der genaue Zustand des Quellcodes, aus dem das Artefakt entstanden ist, ist eindeutig und unveränderlich nachvollziehbar.

• Protected Branches / Protected Tags: Nachweis, ob der Branch oder Tag, für den die Build-Pipeline ausgeführt wurde, im Repository als geschützt markiert ist. Geschützte Referenzen unterliegen strengeren Zugriffskontrollen und verhindern direkte Pushes ohne Review.

• Code-Review-Nachweis: Verbindung zu Merge Requests und deren Genehmigungen, die vor dem Merge stattgefunden haben. Dies belegt, dass der Code vor der Integration durch mindestens eine weitere Person geprüft wurde.

• Rückverfolgbarkeit: Im Falle von Sicherheitsproblemen oder Bugs kann exakt nachvollzogen werden, welcher Quellcode zu welchem Image geführt hat und welche Änderungen enthalten sind.

• Compliance: Für regulierte Bereiche und die öffentliche Verwaltung ist die lückenlose Dokumentation der Code-Herkunft essentiell für Audits und Compliance-Nachweise.

Warum reicht Build Provenance allein nicht aus?

Build Provenance beantwortet die Frage: Wie wurde das Artefakt gebaut? — also welcher Build-Prozess, welche Tools, welche Umgebung. Source Provenance beantwortet die tiefere Frage: Wer hat den Code geschrieben, wer hat ihn geprüft, und aus welchem Repository stammt er?

Beide Nachweise sind komplementär. Erst zusammen ermöglichen sie eine vollständige Rückverfolgung von einem laufenden Container-Image bis zu einem konkreten, verifizierten Commit mit Code-Review-Nachweis.

Verbindung zu SLSA

SLSA ist in separate Tracks unterteilt. Source Provenance gehört zum Source Track — einem eigenständigen Track, der beschreibt, wie vertrauenswürdig der Quellcode einer Software-Revision ist:

Die im openCode Badge-System erfassten Daten — Protected Branch Status, Merge Request Genehmigungen, Commit-Referenzen — sind genau die Nachweise, die der SLSA Source Track auf den Stufen L3 und L4 fordert.

Dies ist vom Build Track zu unterscheiden, der den Build-Prozess selbst abdeckt — siehe Build Provenance.