Firma delle dipendenze e degli artefatti

Un SBOM indica che cosa contiene un artefatto. La provenienza indica da dove proviene e come è stato creato. La firma lega un artefatto a un'origine verificabile, così chi lo utilizza può rifiutare tutto ciò che non è stato prodotto dalla vostra pipeline affidabile.

Senza informazioni sulla provenienza, un aggressore che sostituisca un tarball nel registry non si distingue da un rilascio legittimo.

La base dell'integrità è l'indirizzamento tramite contenuto. Un hash crittografico (digest) di un artefatto identifica univocamente quell'esatta sequenza di byte. I tag mutabili come latest possono essere riassegnati; un digest no.

Una firma digitale usa una chiave privata per firmare l'hash dell'artefatto; chiunque disponga della chiave pubblica corrispondente può verificarla. Questo offre due garanzie:

• Integrità — l'artefatto non è stato modificato dopo la firma
• Autenticità — è stato firmato dal titolare della chiave privata

La difficoltà non è la matematica, ma la gestione delle chiavi e la distribuzione della fiducia: come fa un verificatore a sapere di quale chiave pubblica fidarsi?

La firma tradizionale costringe i team a proteggere chiavi private a lunga durata, che possono fuoriuscire. Sigstore offre la firma senza chiavi: rilascia un certificato a breve durata associato a un'identità OIDC, come un workload CI o l'indirizzo email di uno sviluppatore, firma e registra l'evento in un registro pubblico di trasparenza chiamato Rekor.

Non c'è alcuna chiave a lunga durata da sottrarre e ogni firma può essere sottoposta ad audit pubblico.

Cosign è lo strumento di Sigstore per firmare immagini di container e altri artefatti. In modalità senza chiavi usa il token OIDC della pipeline, quindi nessun file di chiave viene memorizzato su disco.

Sigstore registra ogni evento di firma in Rekor, un registro pubblico append-only, a prova di manomissione. Si tratta di un efficace controllo investigativo:

• È possibile dimostrare quando qualcosa è stato firmato
• Un aggressore che sottrae un'identità non può firmare di nascosto — l'evento viene registrato pubblicamente
• Le firme anomale, per esempio con un'identità inattesa o fuori orario, diventano rilevabili

La trasparenza trasforma una compromissione silenziosa in un'evidenza osservabile.

SLSA (Supply-chain Levels for Software Artifacts) è un framework che valuta l'affidabilità del processo di build. I livelli più alti richiedono garanzie più solide contro la manomissione.

• L1 — la provenienza esiste ed è documentata
• L2 — provenienza firmata da un servizio di build ospitato
• L3 — build rafforzate e isolate; la provenienza non può essere falsificata nemmeno da un insider della pipeline

SLSA è un percorso: scelga un livello obiettivo e colmi le lacune.

Un'attestazione della provenienza è una dichiarazione firmata che descrive come è stato creato un artefatto: il commit del codice sorgente, l'identità del builder, i parametri della build e gli input. Il formato in-toto standardizza questa dichiarazione.

La firma è utile solo se qualcosa rifiuta gli artefatti privi di firma. In Kubernetes, un controller di ammissione può bloccare qualsiasi immagine priva di una firma valida e di informazioni sulla provenienza associate alla vostra identità affidabile.

• I controller delle policy verificano le firme cosign prima dell'avvio di un pod
• Rifiutano le immagini firmate da identità inattese
• Richiedono una provenienza che punti al repository sorgente approvato

In questo modo si chiude il ciclo: gli artefatti non attendibili non vengono mai eseguiti.

La provenienza è più preziosa quando si estende a ciò che si utilizza, non solo a ciò che si distribuisce. Gli ecosistemi stanno aggiungendo funzionalità native di firma e provenienza:

• npm provenance collega un pacchetto pubblicato al commit sorgente e all'esecuzione CI che lo ha prodotto
• Le immagini base dei container distribuiscono sempre più spesso firme cosign
• I registry dei linguaggi stanno sperimentando la verifica basata su Sigstore

Preferisca le dipendenze che pubblicano informazioni sulla provenienza verificabili e le verifichi durante l'installazione, quando supportato.

Una strategia di firma pratica è stratificata e verificata da un'estremità all'altra:

• Fissare gli input tramite digest
• Firmare gli artefatti senza chiavi e allegare SBOM e attestazioni di provenienza
• Registrare tutto in un registro di trasparenza
• Applicare la verifica in fase di deploy con una policy di ammissione

La catena è solida quanto il suo collegamento non verificato più debole, quindi verifichi ogni punto di utilizzo.

Valuti in che modo la firma senza chiavi migliora la sicurezza della catena di fornitura.

Ha imparato a dimostrare la provenienza e a farla rispettare.

• Fissare gli artefatti tramite digest, non tramite tag mutabili
• Le firme digitali garantiscono integrità e autenticità; la sfida è la gestione delle chiavi
• Sigstore + cosign consentono la firma senza chiavi con il registro pubblico di trasparenza Rekor
• SLSA valuta l'integrità della build; le attestazioni di provenienza registrano come sono stati creati gli artefatti
• Le policy di ammissione rifiutano tutto ciò che non è firmato o non è attendibile al momento del deploy

Prossimo argomento: rafforzare la pipeline CI/CD che produce questi artefatti.