← Tutti gli articoli

8 min di lettura

Proof of Existence e Sigstore: ti servono entrambi?

Sigstore firma gli artefatti software e registra l'evento in un log pubblico; Label 309 aggiunge un'ancora temporale indipendente, su blockchain, sopra tutte le prove della tua release. Risolvono problemi diversi e funzionano bene insieme.

Sigstore e la Proof of Existence non sono davvero in competizione. Sigstore risponde alla domanda chi ha firmato questo artefatto software, e l'evento di firma è in un log pubblico? Label 309 risponde a un'altra: questi byte esatti esistevano entro un certo momento pubblico, in modo dimostrabile senza fidarsi di un singolo servizio? Per la maggior parte dei team di sviluppo la soluzione più solida usa entrambi: firma e registra le release con Sigstore, poi ancora le prove della release con Label 309.

Sigstore è un ecosistema di firma e trasparenza per il software. Label 309 ancora hash di contenuti, manifest, file sigillati o una Merkle root su Cardano, così chiunque può verificare in seguito che quei dati esatti esistevano entro uno specifico block time — usando solo la transazione e un explorer pubblico, senza alcun server dell'emittente nel mezzo.

Cos'è Sigstore?

Sigstore è un ecosistema open-source per firmare gli artefatti della software supply-chain e registrare gli eventi di firma in un log pubblico.

Il suo flusso keyless tipico usa un'identità OpenID Connect (OIDC), un certificato a breve durata emesso da Fulcio, una firma creata sul client e una voce nel log di trasparenza Rekor. L'obiettivo è rendere più semplice firmare gli artefatti mantenendo al tempo stesso un registro pubblico e verificabile di chi ha firmato cosa.

Sigstore si presta bene a:

  • immagini di container;
  • binari e pacchetti;
  • software bill of materials (SBOM);
  • attestazioni di provenienza;
  • flussi CI/CD e di firma delle release;
  • verificare che un artefatto sia stato firmato da un'identità attesa.

È pensato per la fiducia nella software supply-chain.

Cos'è Label 309?

Label 309 è uno standard aperto e neutrale rispetto al fornitore per i record di Proof of Existence su Cardano. La proposta è stata presentata al processo CIP di Cardano ed è in revisione da parte degli editor CIP; l'identificatore on-chain è la label dei metadati 309.

Un record Label 309 può impegnarsi su uno o più hash di contenuti, su una Merkle root che copre molti file, su firme opzionali a livello di record, su payload sigillati indirizzati a chiavi di destinatari e su URI di storage indirizzato per contenuto. La prova centrale è verificabile in modo indipendente a partire dalla transazione Cardano e dai byte sotto esame — senza account, senza login e senza dipendere da un singolo fornitore.

Per i team di sviluppo questo lo rende utile per ancorare le prove di una release:

  • digest degli artefatti;
  • bundle Sigstore;
  • provenienza SLSA e statement in-toto;
  • SBOM;
  • manifest di release;
  • log di build e risultati dei test;
  • prove relative agli incidenti.

È un livello di impegno pubblico e con timestamp.

Qual è la differenza concreta?

Sigstore risponde a domande di identità e firma per il software. Label 309 risponde a domande di esistenza e tempo per qualunque byte.

Sigstore può aiutare a rispondere:

  • Questa immagine di container è stata firmata?
  • Quale identità OIDC era legata al certificato di firma?
  • L'evento di firma è stato registrato nel log di trasparenza?
  • La firma dell'artefatto può essere verificata?
  • Corrisponde alla mia policy per i firmatari fidati?

Label 309 può aiutare a rispondere:

  • Questo digest dell'artefatto esisteva entro questo block time di Cardano?
  • Questo SBOM faceva parte delle prove di release su cui ti sei impegnato?
  • Questo manifest di release esisteva prima di un incidente?
  • Un'identità di progetto nota ha firmato il record (in via opzionale)?
  • Un destinatario potrà decifrare in seguito un bundle di prove sigillato?

Questi due insiemi di domande si integrano, non si sovrappongono.

Rekor non fa già tutto questo?

Se usi Sigstore, usa Rekor — è lo strumento giusto per il suo compito.

Rekor è un log di trasparenza per firme e metadati software, progettato per rendere gli eventi di firma rintracciabili e verificabili. La documentazione di Sigstore lo descrive come un registro append-only e resistente alle manomissioni, che gli auditor possono monitorare per verificarne la coerenza — l'obiettivo progettuale è che qualsiasi tentativo di modificare o rimuovere una voce sia rilevabile e non silenzioso.

Label 309 non sostituisce Rekor. Fornisce un tipo di ancoraggio diverso:

  • un timestamp pubblico radicato nel consenso di Cardano anziché in un log gestito da un servizio;
  • uno schema di record definito sotto la label dei metadati 309;
  • la conservazione sigillata, opzionale, delle prove sensibili;
  • la consegna a destinatari specifici;
  • il Merkle batching per insiemi di prove di grandi dimensioni;
  • una verifica che non dipende dal fatto che un fornitore specifico resti online.

Se una release ha già delle prove Sigstore, ancorale. Non buttarle via.

Come sarebbe un flusso combinato?

Una pipeline CI/CD può assemblare una cartella di prove della release, poi impegnarsi su di essa.

Quella cartella potrebbe contenere il manifest di release, i digest degli artefatti, le firme o i bundle Cosign, i riferimenti alle voci Rekor, la provenienza SLSA, le attestazioni in-toto, gli SBOM, i log di build, i report dei test e i manifest di deployment.

La pipeline calcola l'hash di ogni file, costruisce un Merkle tree e pubblica un solo record Label 309 che porta la Merkle root. Poiché la root è un singolo valore da 32 byte, una sola transazione può rappresentare un insieme di prove arbitrariamente grande; una inclusion proof dimostra in seguito che un determinato file faceva parte di quella root. Il record può anche portare una firma opzionale proveniente da un'identità di progetto o aziendale. Per la meccanica con cui si riducono molti file a una sola root, vedi un solo record per migliaia di file; per lo schema della pipeline end-to-end, vedi ancorare le prove di build CI/CD.

In seguito, un auditor verifica due cose indipendenti:

  • Sigstore — chi ha firmato cosa, sotto quale identità e in quale contesto del log di trasparenza;
  • Label 309 — quale insieme di prove esisteva entro un momento pubblico di Cardano.

Label 309 verifica la firma del software?

No. Label 309 non sa se una firma Cosign è valida, se un'identità OIDC è fidata, se una policy è soddisfatta o se una build rispetta le aspettative SLSA.

Quello che può dimostrare è che il file di firma, il bundle, l'attestazione, lo SBOM o il manifest di release esisteva entro un momento pubblico. Gli strumenti della software supply-chain continuano a verificare i propri formati secondo le proprie regole.

Questa separazione è sana. Una Proof of Existence non dovrebbe fingere di essere un motore di policy per la firma del software.

Sigstore conserva tutto il tuo insieme di prove?

Non da solo. Sigstore si concentra sulla firma e sulla trasparenza per gli artefatti software. Un vero processo di release spesso ha bisogno di conservare anche log di build, SBOM, report dei test, manifest di deployment, cronologie degli incidenti e bundle di prove privati.

Label 309 può impegnarsi su quei materiali come un unico insieme. Se alcuni materiali sono sensibili, possono restare privati ed essere impegnati tramite una Merkle root senza pubblicarne i contenuti — oppure essere sigillati, così che il testo cifrato risieda in uno storage indirizzato per contenuto e solo chi possiede una chiave possa decifrarlo. Un record sigillato mantiene il testo in chiaro leggibile solo ai destinatari previsti; non garantisce, di per sé, l'anonimato, e un destinatario può comunque divulgare il testo in chiaro dopo averlo decifrato.

Questo rende Label 309 utile per audit, risposta agli incidenti, approvvigionamento, security review dei clienti e prove di release a lungo termine.

Quando dovresti usare Sigstore?

Usa Sigstore quando ti serve firmare artefatti software e ottenere una verifica basata sull'identità. È la scelta giusta per firmare immagini di container, binari e pacchetti; per i flussi pubblici di release open-source; per la firma keyless con identità OIDC; per la trasparenza della supply-chain; per le policy di verifica basate sui firmatari attesi; e per l'integrazione con gli strumenti di distribuzione esistenti.

Sigstore è un'ottima scelta predefinita per la firma del software moderno.

Quando dovresti usare Label 309?

Usa Label 309 quando ti serve un impegno pubblico e con timestamp attorno alle prove — per ancorare i manifest di release, dimostrare che uno SBOM esisteva prima della divulgazione di una vulnerabilità, impegnarti su una Merkle root sopra un insieme di prove di release, conservare materiali di incidente sigillati, dimostrare un insieme di artefatti consegnato a un cliente o mantenere una prova che non dipende dal fatto che un provider CI o la dashboard di un registry di artefatti restino online.

Label 309 non sostituisce la firma. È un'ancora temporale e un formato di impegno sulle prove. La CLI cardanowall open-source è pensata proprio per questo tipo di automazione: indipendente dal gateway e raw-seed-first, così si inserisce in una pipeline senza alcun sito web nel mezzo. Vedi usare la CLI nell'automazione per il flusso completo.

Cosa non dimostra nessuno dei due sistemi?

Nessuno dei due dimostra che il software sia sicuro.

Un artefatto firmato può comunque contenere una vulnerabilità. Uno SBOM con timestamp può essere incompleto. Un log di build può documentare una pipeline configurata male. Una release può essere ben documentata e comunque non sicura.

Sigstore e Label 309 aiutano a dimostrare integrità, identità, trasparenza, tempo e continuità delle prove. La sicurezza in sé dipende ancora dalla revisione del codice sorgente, dall'isolamento delle build, dalla gestione delle dipendenze, dai test, dalla risposta alle vulnerabilità e dai controlli operativi. Per i limiti generali di ciò che una prova può e non può stabilire, vedi cosa non dimostra una prova.

In breve

Usa Sigstore per firmare il software e rendere trasparenti gli eventi di firma. Usa Label 309 per ancorare le prove della release — manifest, log e attestazioni — a un momento pubblico di Cardano che nessun fornitore può spostare di nascosto. Insieme, rendono la storia del software molto più facile da verificare in seguito.

Approfondimenti

proof-of-existencesigstoresoftware-supply-chain