Hoe je kunt verifiëren dat een GitHub Actions-artifact door jou is gebouwd, niet door een aanvaller

Supply chain-aanvallen zijn allang geen theorie meer maar harde realiteit. Stel dat een gebruiker een vooraf gebouwde binary downloadt uit het Releases-gedeelte op GitHub. Hoe kunnen ze verifiëren dat het bestand daadwerkelijk door de CI-server is gebouwd op basis van de broncode van een specifieke commit, en niet is geüpload door een hacker die toegang heeft gekregen tot het account van de ontwikkelaar?

Om dit probleem op te lossen heeft GitHub een speciale action uitgerold actions/attest-build-provenance. Laten we uiteenzetten hoe het werkt, waarom Sigstore-handtekeningen nodig zijn, en waarom je een iets ander hulpmiddel nodig hebt bij het maken van nieuwe pipelines.

Waar de handtekening binden

De essentie van provenance-ondertekening is vrij eenvoudig. Elk voltooid bestand heeft een digitaal paspoort nodig. Dit document bevestigt: het artefact met een specifieke hash is gebouwd binnen een specifieke workflow, in een specifieke repository, en op een specifieke commit.

Het hulpmiddel genereert een manifest volgens de in-toto-standaard en de SLSA-specificatie (Supply-chain Levels for Software Artifacts). Dan gebeurt het meest interessante deel: het ondertekenen van dit manifest.

In plaats van ontwikkelaars te dwingen om langlevende PGP-sleutels te genereren en deze in repository-secrets op te slaan, wordt Sigstore-architectuur gebruikt. De action vraagt een tijdelijk OIDC-token op bij GitHub Actions en wisselt dit in voor een kortlevend ondertekeningscertificaat.

Voor openbare repositories wordt de handtekening gegenereerd via de publieke Sigstore-service, en gegevens hierover komen terecht in het transparante Rekor-logboek. Als de repository privé is, gebruikt GitHub zijn eigen privé Sigstore-instantie (deze functie is beschikbaar op het Enterprise Cloud-plan).

Een kleine verrassing in de documentatie

Als je de officiële repository van het project opent, zie je direct bovenaan de README een belangrijke noot.

Vanaf versie vier is actions/attest-build-provenance getransformeerd tot een eenvoudige wrapper rond de basis-action actions/attest. De GitHub-ontwikkelaars geven expliciet aan: als je oude pipelines onderhoudt, kun je alles laten zoals het is. Maar voor nieuwe projecten moet je direct beginnen met actions/attest.

Waarom heeft GitHub een extra laag toegevoegd? In eerste instantie bouwde het team een nauw gespecialiseerd hulpmiddel alleen voor build-provenance. Later ontstond de wens om niet alleen binaries te ondertekenen, maar ook SBOM's (afhankelijkheidslijsten) of resultaten van kwetsbaarheidsscans. Zo ontstond de meer universele actions/attest, en werd de oude action gepensioneerd als synoniem.

Hoe de setup eruitzag

In oudere versies van de action was de logica in .github/workflows/build.yml samengeperst tot een paar regels na de artefact-bouwstap.

Wat hier belangrijk is, zijn de permissies id-token: write en attestations: write. Zonder de eerste optie kan de workflow geen OIDC-token ophalen voor passwordless ondertekening via Sigstore, en zonder de tweede wordt het resultaat niet geüpload naar de GitHub Attestations API.

Hoe de authenticiteit van het artefact verifiëren

Nadat de attestatie is gemaakt en gebonden aan de repository, kan elke gebruiker of verificatiescript het bestand lokaal controleren. Hiervoor wordt het officiële GitHub CLI-hulpprogramma gebruikt.

Het verificatiecommando ziet er zo uit:

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

Als het bestand niet is gewijzigd en is gebouwd in de opgegeven organisatie, zal de CLI informatie uitvoeren over de commit en het ondertekeningscertificaat. Echter, als het bestand ook maar minimaal is gewijzigd, zal de verificatie mislukken met een fout.

Is het de moeite waard om te implementeren

Als je een open-source bibliotheek of CLI-tool ontwikkelt, geeft het genereren van attestaties gebruikers een eenvoudige manier om de beveiliging van je releases te verifiëren.

Anderzijds, als je een klein intern project hebt zonder strikte supply chain-beveiligingsvereisten, kan het toevoegen van extra stappen aan je CI overkill zijn.

Gebruik voor nieuwe workflows direct actions/attest in plaats van actions/attest-build-provenance. De kernfunctionaliteit blijft hetzelfde, maar je gebruikt een actueel hulpmiddel zonder deprecated wrappers.