Zusammenfassung

  • Eine kryptografisch gültige GitHub-Attestierung bindet den Digest eines Artefakts an dokumentierte Build-Provenienz; sie bescheinigt nicht, dass das Artefakt sicher ist.
  • Die entscheidende Kontrolle liegt beim Verbraucher: Weichen Repository, unveränderliche Workflow-Identität, Commit- oder Release-Bedingung, Umgebung oder Runner-Vertrauensgrenze von der Richtlinie ab, muss das Deployment abgelehnt werden.
  • Attestierungen privater Repositories nutzen GitHubs Sigstore-Instanz ohne das öffentliche Transparenzprotokoll der öffentlichen Repositories. Das verändert die Beobachtbarkeit, beweist aber keine Schwäche.

Erfolgreich geprüft, trotzdem abgelehnt

Ein Deployment-Gateway erhält ein Container-Image. Die Signatur ist gültig, der Digest stimmt überein und die Provenienzaussage ist unverändert. Trotzdem weist das Gateway das Image zurück. Es könnte aus einem unerwarteten Repository stammen, einen externen wiederverwendbaren Workflow über ein verschiebbares Tag referenzieren, auf einem nicht genehmigten Commit beruhen, die falsche Umgebung nennen oder auf einem Runner außerhalb der akzeptierten Vertrauensgrenze erstellt worden sein.

Die Ablehnung widerlegt die Attestierung nicht. Sie zeigt, dass aus der Attestierung eine echte Zulassungsentscheidung geworden ist.

GitHub beschreibt Artefakt-Attestierungen als kryptografisch signierte Aussagen zur Build-Provenienz. Sie können den zugehörigen Workflow, das Repository, die Organisation, die Umgebung, den Commit-SHA und das auslösende Ereignis ausweisen. Weitere Angaben können aus der OpenID-Connect-Identität stammen, mit der die Provenienz etabliert wurde.

Im Workflow wird die Attestierung nach dem Build erzeugt. Dafür sind unter anderem Berechtigungen für das Identitätstoken und das Schreiben der Attestierung nötig. Bei einer Binärdatei kann das erzeugte Artefakt selbst der Gegenstand sein. Bei einem Container binden der vollständig qualifizierte Name und der Digest die Aussage an einen bestimmten Inhalt statt lediglich an ein veränderliches Tag. Der Verbraucher kann damit feststellen, ob der vorgelegte Inhalt tatsächlich zu dem dokumentierten Build-Pfad gehört.

Diese Feststellung bleibt enger als ein Sicherheitsurteil. Die Attestierung bewertet weder den Quellcode noch die Vertrauenswürdigkeit der Abhängigkeiten oder die Qualität der Build-Anweisungen. Ebenso wenig beweist sie, dass die Ausführungsumgebung unversehrt geblieben ist. Sie macht Herkunft überprüfbar, ersetzt aber nicht die übrigen Entscheidungen zur Softwaresicherheit.

GitHub zieht diese Grenze ausdrücklich. Die bloße Erzeugung einer Attestierung bringt keinen Sicherheitsgewinn; der Verbraucher muss sie verifizieren. Auch ist eine Attestierung keine Garantie für ein sicheres Artefakt. Der Verbraucher definiert die Kriterien, wertet die Angaben aus und trifft seine Risikoentscheidung. Wer nur die Echtheit der Signatur prüft, beantwortet nicht die entscheidende Frage, ob der signierte Weg zulässig war.

Die Richtlinie entscheidet über die Bedeutung

Das erwartete Repository und die Organisation bilden eine erste Schranke. Sie reichen jedoch nicht aus. Innerhalb derselben Organisation können ein zentral geprüfter Release-Workflow und andere Automatisierungen mit deutlich schwächeren Kontrollen existieren. Dass beide eine gültige Aussage erzeugen dürfen, macht ihre Artefakte nicht gleichwertig.

Deshalb muss die Workflow-Identität unveränderlich sein. GitHub nennt den vollständigen Commit-SHA als sicherste Referenz für einen externen wiederverwendbaren Workflow. Ein Branch entwickelt sich weiter, ein Tag kann verschoben werden. Eine Attestierung kann den Referenznamen korrekt festhalten, obwohl dessen aktueller Inhalt nicht mehr der geprüften Fassung entspricht. Wird nur der Workflow-Name akzeptiert, bleibt ein Teil der Build-Definition außerhalb der Zulassungsprüfung.

Commit, Release-Bedingung, auslösendes Ereignis und Umgebung schränken die Route weiter ein. Eine Produktionsrichtlinie kann einen ausdrücklich freigegebenen Release-Commit fordern, statt jeden Commit im richtigen Repository zu akzeptieren. Ebenso kann sie einen kontrollierten Release-Kontext von einer gewöhnlichen Testumgebung unterscheiden. Die Signatur erzeugt diese Kriterien nicht; der Verbraucher muss sie bestimmen.

Runner-Vertrauen ist eine eigenständige Dimension. GitHub warnt, dass selbst gehostete Runner nicht garantiert auf flüchtigen, sauberen Maschinen ausgeführt werden und durch nicht vertrauenswürdigen Workflow-Code dauerhaft kompromittiert werden können. Aus einer gültigen Attestierung folgt daher nicht, dass der Runner unversehrt war. Welche Runner-Gruppen und Isolationsbedingungen zulässig sind, muss die Richtlinie separat festlegen.

Von der Aussage zur technischen Zulassung

Für Kubernetes dokumentiert GitHub ein Modell aus Sigstore Policy Controller, GitHub-Vertrauenswurzel und Cluster-Image-Richtlinie. Nach der Aktivierung in ausgewählten Namespaces kann der Controller Attestierungen vor der Zulassung von Images prüfen und nicht regelkonforme Artefakte abweisen.

Die Konfiguration legt die tatsächliche Reichweite fest. Die Installation des Controllers allein erzwingt noch nichts. Eine Richtlinie muss konfiguriert und im betreffenden Namespace aktiviert sein. Auch Image-Muster und Ausnahmen verändern die Kontrollfläche. Der Satz, eine Organisation „nutze Attestierungen“, sagt deshalb wenig darüber aus, welche Deployments tatsächlich geschützt sind.

Öffentliche und private Repositories unterscheiden sich zudem in ihrer Beobachtbarkeit. Öffentliche Attestierungen verwenden die öffentliche Sigstore-Instanz und werden in ein öffentlich lesbares, unveränderliches Transparenzprotokoll geschrieben. Private Repositories nutzen GitHubs Sigstore-Instanz auf derselben Codebasis, jedoch ohne öffentliches Transparenzprotokoll und nur mit GitHub Actions als Föderationspartner. Das begrenzt die öffentliche unabhängige Einsicht, ist für sich genommen aber kein Nachweis einer schwachen Sicherheitswirkung.

Die verfügbaren Primärquellen nennen weder allgemeine Einführungsquoten noch Ablehnungs- oder Fehlakzeptanzraten. Sie belegen auch nicht, dass sämtliche Verbraucher Richtlinien erzwingen oder ein bestimmter Runner unkompromittiert war. Diese Evidenzgrenzen dürfen nicht durch Vermutungen ersetzt werden.

Die operative Schlussfolgerung lautet daher: Attestierungsprüfung ist Zulassungskontrolle. Vor dem Deployment sind das erwartete Repository, eine unveränderliche Workflow-Identität, die genehmigte Commit- oder Release-Bedingung, die vorgesehene Umgebung und eine akzeptable Runner-Vertrauensgrenze zu verlangen. Weicht ein Merkmal ab, wird das Artefakt abgelehnt und ein Beleg über die verletzte Bedingung aufbewahrt.

Quellen