sigstore: la firma del software senza la chiave da custodire
sigstore è il progetto che ha reso praticabile una cosa che la sicurezza predicava da decenni senza riuscire a farla adottare: firmare il software, per poter dimostrare chi lo ha prodotto e che non è stato manomesso. L’idea della firma digitale degli artefatti è sempre stata giusta, ma nella pratica è rimasta marginale per una ragione molto concreta: gestire una chiave privata di firma è difficile e pericoloso. Va generata, protetta per anni, ruotata, e se trapela tutto ciò che è stato firmato con essa diventa sospetto. Quella frizione ha tenuto la firma del software fuori dalla portata della maggior parte degli sviluppatori. sigstore la rimette in gioco togliendo dall’equazione proprio la parte più scomoda: la chiave.
Il risultato è un capovolgimento del modello di fiducia. Invece di affidarsi a una chiave che deve restare segreta e integra nel tempo, sigstore lega la firma a un’identità verificata e ne registra l’evento in un archivio pubblico e a prova di manomissione. La domanda di chi verifica non è più se una chiave sia ancora al sicuro dopo mesi o anni, ma se quel preciso atto di firma sia stato compiuto da quell’identità, in quel momento, e regolarmente registrato. È una differenza che cambia la scala del problema.
La firma del software era giusta, e quasi nessuno la faceva
Per capire cosa risolve sigstore conviene ricordare perché la firma tradizionale ha fallito nell’adozione. Firmare un artefatto, un’immagine container, un pacchetto, un binario, richiedeva di possedere e custodire una chiave privata di lunga durata. Questo significava un onere costante: dove conservarla perché non venga rubata, come ruotarla, cosa fare se un dipendente che vi aveva accesso se ne va. E significava un rischio sistemico: una sola chiave compromessa mette in dubbio l’autenticità di tutto ciò che ha firmato, magari per anni a ritroso. Di fronte a questo costo, la maggioranza ha semplicemente rinunciato, lasciando la catena di distribuzione del software senza un modo affidabile per verificare la provenienza.
È esattamente la lacuna che gli attacchi alla supply chain sfruttano. Quando un worm si infila nei pacchetti di un repository pubblico e ne pubblica versioni compromesse, il problema non è solo l’intrusione: è che chi scarica quei pacchetti non ha uno strumento semplice per accorgersi che non provengono da chi dovrebbe. Senza una firma verificabile, l’integrità e l’origine di un artefatto restano un atto di fede. La firma del software risolverebbe il problema, se solo fosse abbastanza facile da usare da essere usata davvero.
Firmare con l’identità, non con la chiave
La mossa di sigstore è la firma senza chiavi persistenti, ciò che viene chiamato firma keyless. Quando uno sviluppatore o, più spesso, una pipeline automatica vuole firmare un artefatto, non estrae una chiave da un caveau. Si autentica invece tramite OIDC presso un fornitore di identità, tipicamente la stessa piattaforma di integrazione continua che esegue il lavoro, e a quel punto la certificate authority del progetto, Fulcio, emette un certificato a vita brevissima, dell’ordine di dieci minuti, che lega quell’identità verificata a una coppia di chiavi effimere.
Con quel certificato lo strumento di firma, Cosign, firma l’artefatto, e subito dopo la chiave privata effimera viene scartata. Non viene mai scritta su disco, non è nota ai servizi di sigstore, non esiste più passati i pochi minuti necessari. Sparisce così l’intero problema della custodia: non c’è una chiave di lunga durata da proteggere, ruotare o temere di perdere, perché la chiave è vissuta giusto il tempo di una firma. La firma che ne resta non porta con sé un segreto da difendere, ma il riferimento a un’identità e a un certificato che chiunque può controllare.
C’è un di più che questo modello rende possibile, ed è forse il suo aspetto più potente. Quando la firma avviene dentro una pipeline automatica, il certificato non lega l’artefatto a una persona generica, ma al contesto preciso della build: quale flusso di lavoro, in quale repository, su quale ramo e quale commit lo ha prodotto e firmato. La verifica può quindi pretendere non solo che l’artefatto sia firmato da qualcuno di fidato, ma che sia stato costruito e firmato esattamente da quel flusso di lavoro, in quel repository e da quel ramo: una garanzia di provenienza che una firma tradizionale non avrebbe mai potuto esprimere.
sigstore e il registro pubblico: Rekor sposta la fiducia
Il pezzo che tiene insieme il tutto è il registro di trasparenza, chiamato Rekor. Ogni evento di firma, con la firma stessa, il certificato e l’impronta dell’artefatto, viene scritto in un registro pubblico, ad accodamento e a prova di manomissione: una volta inserita, una voce non può più essere modificata, e l’integrità del registro è verificabile crittograficamente da chiunque. La documentazione di sigstore descrive questo come il cuore del modello: il registro sostituisce le chiavi di lunga durata come radice della fiducia. Il registro annota anche l’istante esatto in cui la firma è avvenuta, e questo scioglie l’apparente paradosso di un certificato che dura dieci minuti: per verificare non serve che il certificato sia ancora valido, basta poter dimostrare, grazie al registro, che la firma fu prodotta mentre quel certificato era in vita. È così che un certificato effimero produce una prova che dura per sempre.
Il cambiamento concettuale è profondo. Nel modello tradizionale ci si fida di una chiave finché si spera che non sia stata compromessa, una scommessa che peggiora con il passare del tempo. Con sigstore ci si fida del fatto che un certo atto di firma sia stato registrato, in un certo istante, per un’identità verificata, in un log che non si può alterare a posteriori. Come spiega il modello di sicurezza del progetto, questa pubblicità è anche una difesa: poiché tutti i certificati devono finire nel registro e i client non devono fidarsi di quelli che non vi compaiono, un certificato emesso in modo improprio, per un’autorità compromessa o per un’identità violata, diventa rilevabile. È la stessa logica della trasparenza dei certificati del web, applicata alla firma del software. E perché questa architettura non poggi a sua volta su chiavi fragili, la radice della fiducia, cioè le chiavi degli stessi servizi di sigstore, è distribuita e ruotata in modo verificabile da un ulteriore livello, The Update Framework, così che nemmeno la compromissione di un singolo componente faccia crollare l’intero sistema.
Dalla firma alla verifica
Firmare è metà del lavoro; l’altra metà, quella che produce valore, è verificare prima di usare. Una firma sigstore non serve a nulla se nessuno la controlla, e il suo posto naturale è il momento che precede l’esecuzione o il rilascio: verificare con Cosign che un’immagine sia firmata dall’identità attesa, e imporre questa verifica come politica al momento dell’ammissione di un carico, esattamente come si fa con altri controlli sull’infrastruttura. In questo modo la provenienza smette di essere un’informazione che si spera vera e diventa una condizione che si pretende prima di mandare qualcosa in produzione.
Sta arrivando negli ecosistemi, ma l’adozione è il collo di bottiglia
La spinta più forte arriva dai grandi repository di pacchetti, che hanno integrato sigstore nel loro flusso di pubblicazione. Su PyPI le attestazioni basate su sigstore sono diventate generalmente disponibili nel novembre 2024, e su npm la pubblicazione affidabile via OIDC, che allega automaticamente un’attestazione di provenienza, è arrivata alla disponibilità generale nel luglio 2025: in entrambi i casi la provenienza viene generata per impostazione predefinita. Su Maven Central l’integrazione è per ora più debole: il portale di pubblicazione di Sonatype valida le firme sigstore, ma le accetta come opzione accanto alla firma PGP, che resta lo standard richiesto. Questi meccanismi, basati sugli stessi mattoni OIDC della firma keyless, eliminano anche un’altra debolezza nota, i token di pubblicazione di lunga durata conservati nei repository, sostituendoli con credenziali temporanee legate alla singola esecuzione.
Sarebbe però disonesto presentare la questione come risolta. Nonostante i meccanismi esistano e siano gratuiti, l’adozione effettiva resta lenta: la maggior parte dei pacchetti attivamente mantenuti continua ad affidarsi ai vecchi token segreti, e solo una minoranza dei progetti, anche tra i più diffusi, pubblica oggi attestazioni. La tecnologia ha rimosso la barriera tecnica, ma non quella dell’inerzia, e finché la verifica non diventa una pratica diffusa lato consumatore, la firma lato produttore vale meno di quanto potrebbe.
Resta il fatto che sigstore ha cambiato ciò che è possibile. Non a caso il progetto si è presentato come la Let’s Encrypt della firma del codice: come quella rese l’HTTPS un’impostazione predefinita eliminando la gestione manuale dei certificati, sigstore punta a rendere la firma del software un gesto ordinario togliendo di mezzo la gestione delle chiavi. La domanda che gli attacchi alla supply chain sfruttano, è questo artefatto davvero di chi credo, ed è integro, era fino a poco fa quasi senza risposta pratica. Affianco al bill of materials che dice cosa contiene un software e ai framework che certificano come è stato costruito, sigstore fornisce il pezzo mancante, la prova verificabile di chi lo ha firmato e che non è stato toccato, finalmente abbastanza semplice da poter essere usata su larga scala. Non è l’intera risposta alla sicurezza della catena di fornitura, ma è la parte che mancava, e che per la prima volta non chiede a nessuno di custodire una chiave.
