So verifizieren Sie, dass ein GitHub Actions-Artefakt von Ihnen erstellt wurde und nicht von einem Angreifer

Supply-Chain-Angriffe haben sich längst von der Theorie zur harten Realität entwickelt. Angenommen, ein Benutzer lädt eine vorkompilierte Binärdatei aus dem Releases-Bereich auf GitHub herunter. Wie kann er überprüfen, ob die Datei tatsächlich vom CI-Server aus dem Quellcode eines bestimmten Commits erstellt wurde und nicht von einem Hacker hochgeladen wurde, der Zugang zum Konto des Entwicklers erhalten hat?

Um dieses Problem zu lösen, hat GitHub eine spezielle Aktion eingeführt actions/attest-build-provenance. Lassen Sie uns aufschlüsseln, wie sie funktioniert, warum Sigstore-Signaturen benötigt werden und warum Sie ein etwas anderes Tool benötigen werden, wenn Sie neue Pipelines erstellen.

Wo die Signatur verankert wird

Das Wesen der Provenienz-Signatur ist recht unkompliziert. Jede fertige Datei benötigt einen digitalen Pass. Dieses Dokument bestätigt: Das Artefakt mit einem bestimmten Hash wurde innerhalb eines bestimmten Workflows, in einem bestimmten Repository und auf einem bestimmten Commit erstellt.

Das Tool generiert ein Manifest gemäß dem in-toto-Standard und der SLSA-Spezifikation (Supply-chain Levels for Software Artifacts). Dann geschieht der interessanteste Teil: die Signatur dieses Manifests.

Statt Entwickler zu zwingen, langlebige PGP-Schlüssel zu generieren und in Repository-Secrets zu speichern, wird die Sigstore-Architektur verwendet. Die Aktion fordert ein temporäres OIDC-Token von GitHub Actions an und tauscht es gegen ein kurzlebiges Signaturzertifikat aus.

Bei öffentlichen Repositories wird die Signatur über den öffentlichen Sigstore-Dienst generiert, und die Daten darüber landen im transparenten Rekor-Log. Wenn das Repository privat ist, nutzt GitHub seine eigene private Sigstore-Instanz (diese Funktion ist im Enterprise-Cloud-Plan verfügbar).

Eine kleine Überraschung in der Dokumentation

Wenn Sie das offizielle Repository des Projekts öffnen, werden Sie eine wichtige Notiz direkt am Anfang der README bemerken.

Ab Version vier wurde actions/attest-build-provenance zu einem einfachen Wrapper über die Basis-Aktion actions/attest. Die GitHub-Entwickler stellen ausdrücklich klar: Wenn Sie alte Pipelines pflegen, können Sie alles so belassen. Für neue Projekte sollten Sie jedoch sofort mit actions/attest beginnen.

Warum hat GitHub eine zusätzliche Abstraktionsschicht hinzugefügt? Zunächst baute das Team ein eng spezialisiertes Tool nur für Build-Provenienz. Später entstand der Wunsch, nicht nur Binärdateien zu signieren, sondern auch SBOMs (Abhängigkeitslisten) oder Ergebnisse von Vulnerability-Scans. So entstand das universellere actions/attest, und die alte Aktion wurde als Synonym eingestellt.

Wie die Einrichtung aussah

In älteren Versionen der Aktion war die Logik in .github/workflows/build.yml auf ein paar Zeilen nach dem Artefakt-Build-Schritt komprimiert.

Entscheidend hier sind die Berechtigungen id-token: write und attestations: write. Ohne die erste Option kann der Workflow kein OIDC-Token für die passwortlose Signatur über Sigstore erhalten, und ohne die zweite wird das Ergebnis nicht in die GitHub Attestations API hochgeladen.

So überprüfen Sie die Authentizität des Artefakts

Nachdem die Attestierung erstellt und an das Repository gebunden ist, kann jeder Benutzer oder jedes Verifikationsskript die Datei lokal prüfen. Dafür wird das offizielle GitHub CLI-Tool verwendet.

Der Verifikationsbefehl sieht so aus:

gh attestation verify app.sh --owner my-organization

Wenn die Datei nicht verändert wurde und in der angegebenen Organisation erstellt wurde, gibt die CLI Informationen über den Commit und das Signaturzertifikat aus. Wurde die Datei jedoch auch nur minimal modifiziert, schlägt die Verifikation mit einem Fehler fehl.

Lohnt sich die Implementierung?

Wenn Sie eine Open-Source-Bibliothek oder ein CLI-Tool entwickeln, geben Attestierungen den Benutzern eine einfache Möglichkeit, die Sicherheit Ihrer Releases zu überprüfen.

Wenn Sie jedoch ein kleines internes Projekt ohne strenge Supply-Chain-Sicherheitsanforderungen haben, könnte das Hinzufügen zusätzlicher Schritte zu Ihrer CI überdimensioniert sein.

Für neue Workflows verwenden Sie actions/attest direkt statt actions/attest-build-provenance. Die Kernfunktionalität bleibt gleich, aber Sie verwenden ein aktuelles Tool ohne veraltete Wrapper.