Come verificare che un artefatto di GitHub Actions sia stato creato da te, non da un attaccante

Gli attacchi alla supply chain sono da tempo passati dalla teoria alla dura realtà. Supponiamo che un utente scarichi un binario precompilato dalla sezione Releases su GitHub. Come può verificare che il file sia stato effettivamente creato dal server CI dal codice sorgente di uno specifico commit, e non caricato da un hacker che ha ottenuto l'accesso all'account dello sviluppatore?

Per risolvere questo problema, GitHub ha introdotto un'azione speciale actions/attest-build-provenance. Analizziamo come funziona, perché sono necessarie le firme Sigstore e perché avrai bisogno di uno strumento leggermente diverso quando crei nuove pipeline.

Dove associare la firma

L'essenza della firma della provenienza è abbastanza semplice. Ogni file finito ha bisogno di un passaporto digitale. Questo documento conferma: l'artefatto con uno specifico hash è stato creato all'interno di un workflow specifico, in un repository specifico e su uno specifico commit.

Lo strumento genera un manifest secondo lo standard in-toto e la specifica SLSA (Supply-chain Levels for Software Artifacts). Poi succede la parte più interessante: la firma di questo manifest.

Invece di costringere gli sviluppatori a generare chiavi PGP di lunga durata e memorizzarle nei secret del repository, viene utilizzata l'architettura Sigstore. L'azione richiede un token OIDC temporaneo da GitHub Actions e lo scambia con un certificato di firma di breve durata.

Per i repository pubblici, la firma viene generata attraverso il servizio pubblico Sigstore e i dati su di essa finiscono nel log trasparente Rekor. Se il repository è privato, GitHub usa la propria istanza Sigstore privata (questa funzionalità è disponibile nel piano Enterprise Cloud).

Una piccola sorpresa nella documentazione

Se apri il repository ufficiale del progetto, vedrai una nota importante proprio all'inizio del README.

A partire dalla versione quattro, actions/attest-build-provenance si è trasformato in un semplice wrapper dell'azione base actions/attest. Gli sviluppatori di GitHub affermano esplicitamente: se stai mantenendo vecchie pipeline, puoi lasciare tutto così com'è. Ma per i nuovi progetti, dovresti iniziare subito con actions/attest.

Perché GitHub ha aggiunto un livello extra? Inizialmente, il team stava costruendo uno strumento strettamente specializzato solo per la provenienza della build. Successivamente, è emerso il desiderio di firmare non solo i binari ma anche gli SBOM (elenchi delle dipendenze) o i risultati delle scansioni di vulnerabilità. È così che è apparso il più universale actions/attest, e la vecchia azione è stata ritirata come sinonimo.

Come appariva la configurazione

Nelle versioni precedenti dell'azione, la logica in .github/workflows/build.yml era compressa in un paio di righe dopo il passaggio di build dell'artefatto.

Ciò che è importante qui sono i permessi id-token: write e attestations: write. Senza la prima opzione, il workflow non sarà in grado di ottenere un token OIDC per la firma senza password tramite Sigstore, e senza la seconda, non caricherà il risultato nell'API GitHub Attestations.

Come verificare l'autenticità dell'artefatto

Dopo che l'attestazione viene creata e associata al repository, qualsiasi utente o script di verifica può controllare il file localmente. Per questo, viene utilizzata l'utility CLI ufficiale di GitHub.

Il comando di verifica si presenta così:

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

Se il file non è cambiato ed è stato creato nell'organizzazione specificata, la CLI emetterà informazioni sul commit e sul certificato di firma. Tuttavia, se il file è stato modificato anche in minima parte, la verifica fallirà con un errore.

Vale la pena implementarla

Se stai sviluppando una libreria open-source o uno strumento CLI, generare attestazioni offre agli utenti un modo semplice per verificare la sicurezza delle tue release.

D'altra parte, se hai un piccolo progetto interno senza requisiti rigorosi di sicurezza della supply chain, aggiungere passaggi extra al tuo CI potrebbe essere eccessivo.

Per i nuovi workflow, usa actions/attest direttamente invece di actions/attest-build-provenance. La funzionalità core rimarrà la stessa, ma userai uno strumento aggiornato senza wrapper deprecati.