Come ancorare le prove di build CI/CD a un timestamp pubblico?

Sì — una pipeline CI/CD può pubblicare la prova di cosa ha costruito, e quando. Lo schema è questo: calcola l'hash degli output che contano (artefatti, SBOM, log, manifesti di rilascio), riunisci quegli hash in un'unica Merkle root e pubblica un solo record Label 309 per la build, il rilascio o la finestra temporale. In seguito, chiunque può dimostrare che uno specifico artefatto o manifesto faceva parte di quel batch vincolato, e che il batch esisteva entro un orario pubblico di blocco.

Questo non sostituisce SLSA, Sigstore, GitHub Artifact Attestations o in-toto. Li completa con l'unica cosa che nessuno di essi fornisce direttamente: un'àncora temporale pubblica, indipendente e neutrale rispetto all'emittente, che nessun fornitore controlla.

Cosa dovrebbe davvero dimostrare una pipeline CI/CD?

Parti dalle prove che potresti dover produrre tra un anno.

Una prova CI/CD può impegnarsi su:

• artefatti di rilascio;
• digest delle immagini dei container;
• file SBOM (software bill of materials);
• attestazioni di provenienza SLSA;
• metadati di link in-toto;
• log di build;
• report dei test;
• manifesti di deployment;
• snapshot dei changelog;
• riferimenti ai commit sorgente;
• lockfile delle dipendenze;
• checksum firmati;
• note di rilascio.

Non calcolare l'hash di tutto solo perché esiste. Calcola l'hash degli artefatti che contano per sicurezza, audit, risposta agli incidenti, fiducia del cliente o integrità del rilascio.

Una buona prova risponde a una domanda futura concreta: «questo esatto artefatto o manifesto faceva parte delle prove di rilascio che abbiamo vincolato in quel momento?»

Come funziona lo schema del Merkle batching?

Per un singolo artefatto basta una prova solo-hash.

Per un rilascio di solito hai molti artefatti, e pubblicarli uno per uno come transazioni separate è uno spreco. Una Merkle root risolve il problema. Calcoli l'hash di ogni elemento di prova in una foglia, riunisci le foglie ordinate in un'unica root da 32 byte e pubblichi solo la root — un unico record on-chain che copre l'intero rilascio.

La pipeline:

1. Costruisce gli artefatti.
2. Genera o raccoglie SBOM, attestazioni, log e manifesti.
3. Calcola l'hash di ogni elemento di prova in una foglia.
4. Assembla una lista ordinata delle foglie.
5. Costruisce il Merkle tree e calcola la root.
6. Pubblica un record Label 309 che porta la root.
7. Conserva la lista delle foglie e le inclusion proof insieme alle prove di rilascio.

In seguito, un verificatore prende un file o un digest, ne controlla la inclusion proof e conferma che l'elemento appartiene alla root nel record Label 309. La prova di inclusione cresce solo con il logaritmo della dimensione del batch, quindi una root su migliaia di foglie si verifica comunque in millisecondi — interamente offline, senza gateway e senza rete. Per la meccanica completa, vedi un solo record per migliaia di file.

Perché non affidarsi semplicemente alle attestazioni esistenti?

Usa le attestazioni esistenti — poi ancorale.

La provenienza SLSA descrive dove, quando e come è stato prodotto un artefatto software. GitHub Artifact Attestations stabilisce la provenienza di build per artefatti come binari e immagini dei container. Sigstore registra metadati firmati della supply chain in un log di trasparenza pubblico e append-only chiamato Rekor. in-toto è un framework per verificare che ogni passo di una supply chain sia stato eseguito come previsto, dalla parte giusta, sugli input giusti.

Ciascuno di essi risolve un problema reale. Label 309 ne risolve uno diverso: pubblicare una prova ancorata su Cardano e verificabile in modo indipendente, che attesta che uno specifico insieme di prove esisteva entro un determinato orario pubblico. Una pipeline robusta non sceglie tra «attestazioni o Proof of Existence». Usa entrambe:

• SLSA o GitHub Attestations per la provenienza di build;
• Sigstore per i flussi di firma e di log di trasparenza;
• in-toto per la verifica dei passi della supply chain;
• Label 309 come àncora temporale pubblica sull'intero insieme di prove.

Cosa aggiunge Label 309 sopra a tutto questo?

Aggiunge un impegno pubblico e durevole su Cardano.

Quell'impegno può coprire un singolo manifesto di rilascio o una Merkle root su molti elementi di prova. Può essere firmato dall'identità di un progetto o di un'azienda. E può essere verificato usando solo i metadati della transazione e un explorer Cardano pubblico — senza account, senza login e senza dipendere dal fatto che la dashboard del provider CI originale resti online.

Quell'indipendenza conta soprattutto quando un team deve dimostrare che le prove esistevano prima di qualche evento successivo:

• la divulgazione di una vulnerabilità;
• un incidente di sicurezza;
• una verifica di sicurezza richiesta da un cliente;
• un audit di approvvigionamento;
• la scadenza di una compliance;
• una controversia su un rilascio;
• un'indagine sulla supply chain.

La prova dà alla cronologia un'àncora che nessuno dei coinvolti può spostare in silenzio.

Cosa verificherebbe un auditor?

Un auditor dovrebbe poter ricostruire la catena da un singolo artefatto fino al record on-chain:

1. Prendi l'artefatto o l'SBOM in esame.
2. Calcolane l'hash.
3. Controlla la inclusion proof rispetto alla Merkle root del rilascio.
4. Conferma che la root compare in un record Label 309.
5. Cerca la transazione Cardano e leggine l'orario di blocco.
6. Verifica l'eventuale firma del record.
7. Controlla la provenienza o l'attestazione associata secondo le sue regole.

Questo separa nettamente due domande. La prova Label 309 risponde a: queste prove sono state vincolate entro questo orario pubblico? Il livello SLSA, Sigstore, GitHub o in-toto risponde a: cosa dicono queste prove su come l'artefatto è stato costruito, firmato o distribuito? Nessuno dei due cerca di fare il lavoro dell'altro.

Cosa deve contenere il manifesto di rilascio?

Un manifesto di rilascio dovrebbe essere banale e completo. Può includere:

• nome e versione del rilascio;
• URL del repository;
• commit sorgente;
• identificatore del workflow di build;
• ID dell'invocazione di build;
• nomi e digest degli artefatti;
• digest delle immagini dei container;
• digest dei file SBOM;
• digest dei file di attestazione;
• digest dei report dei test;
• digest del log di build;
• il timestamp riportato dal sistema CI;
• il riferimento della transazione Label 309, aggiunto dopo la pubblicazione.

Il manifesto stesso può essere sottoposto a hash e incluso come foglia. Funge anche da indice leggibile che spiega ogni altra foglia del batch. Mantieni stabile il formato: una prova è più facile da verificare quando la struttura delle prove è prevedibile da un rilascio all'altro.

La pipeline dovrebbe firmare il record?

Di solito sì.

Una Merkle root dimostra che una lista è stata vincolata. Una firma mostra inoltre che un progetto, un'azienda, un sistema di rilascio o un'identità approvata si è fatto garante di quell'impegno. In Label 309 si tratta di una firma a livello di record opzionale — l'autorialità non è mai richiesta perché l'affermazione di esistenza si verifichi, ma è disponibile quando vuoi responsabilità.

Gestisci la chiave di firma con criterio. Non disseminare seed d'identità a lunga durata su runner CI qualsiasi. A seconda del tuo modello di minaccia, usa un'identità di rilascio dedicata, un servizio di firma controllato, un flusso con supporto hardware o un runner self-hosted con controlli di accesso stringenti. La CLI cardanowall open source è fatta esattamente per questo — indipendente dal gateway e raw-seed-first, così si inserisce nell'automazione senza un sito web nel circuito. Vedi usare la CLI nell'automazione per il flusso end-to-end.

Una firma aggiunge responsabilità. Non rende sicura, di per sé, una pipeline di build debole.

Dove dovrebbe risiedere la lista delle foglie?

Conservala insieme alle prove di rilascio.

La lista delle foglie e le inclusion proof sono ciò che ti permette di dimostrare i singoli elementi in seguito. Se pubblichi solo la root e poi perdi la lista delle foglie, puoi ancora dimostrare che una qualche lista esisteva — ma potresti non essere più in grado di dimostrare che uno specifico artefatto ne facesse parte.

Le opzioni di conservazione migliori dipendono dal workflow:

• allegala all'archivio di rilascio;
• conservala in un repository di artefatti;
• tienila in un bucket di prove interno;
• sigillala come contenuto cifrato per prove riservate;
• pubblicala tramite storage indirizzato per contenuto quando è sicuro renderla pubblica.

La root è l'àncora. La lista delle foglie è la mappa.

Con che frequenza dovrebbe pubblicare una pipeline?

Allinea la cadenza delle prove alla cadenza dei rilasci. Scelte comuni:

• una prova per rilascio;
• una prova per build;
• una prova per deployment;
• una prova al giorno per i log continui;
• una prova per ogni evento rilevante per la sicurezza.

Pubblicare troppo di rado indebolisce la cronologia; pubblicare troppo spesso aggiunge costi e rumore operativo. Il Merkle batching ti permette di scegliere una cadenza che corrisponde alla domanda di business. Se un cliente chiede «cosa è stato esattamente rilasciato nella versione 2.3.1?», una prova per rilascio è più che sufficiente. Se un regolatore o un auditor chiede se il monitoraggio fosse continuo, impegni giornalieri od orari rispondono meglio.

Pubblicare costa, perché il gateway paga le commissioni reali delle transazioni Cardano più lo storage — quindi la cadenza è un genuino compromesso tra costo e prove, non una manopola gratuita.

Cosa non dimostra una prova CI/CD?

Non dimostra che la build fosse sicura.

Una Proof of Existence può mostrare che un artefatto, un SBOM, un log o un manifesto esisteva entro un orario pubblico; che l'elemento era incluso in un batch vincolato; e che una chiave ha firmato il record. È tutto ciò che certifica.

Non dimostra che il codice sorgente fosse sicuro. Non dimostra che il runner non sia stato compromesso. Non dimostra che le dipendenze fossero prive di vulnerabilità. Non dimostra che l'SBOM sia completo. E non dimostra che un'attestazione sia affidabile, a meno che non superi le proprie regole di verifica. È esattamente per questo che Label 309 sta accanto agli strumenti di sicurezza della supply chain anziché sostituirli — vedi cosa non dimostra una prova per i limiti generali.

Qual è una buona prima implementazione?

Comincia con una prova di rilascio. Per ogni rilascio:

1. Genera i tuoi normali artefatti.
2. Genera o raccogli SBOM e attestazioni.
3. Crea un manifesto di rilascio.
4. Calcola l'hash di ogni file di prova in una foglia.
5. Costruisci la Merkle root.
6. Pubblica un record Label 309 firmato.
7. Salva il riferimento della transazione nelle note di rilascio.
8. Conserva il manifesto, la lista delle foglie e le inclusion proof insieme al rilascio.

Questo ti dà una catena di prove pratica senza riprogettare il tuo sistema di build il primo giorno. Da lì, estendi ai log giornalieri, ai manifesti di deployment o a un'automazione a volume più alto.

In breve

Una prova CI/CD è un impegno con timestamp sulle prove di rilascio.

Calcola l'hash degli artefatti, degli SBOM, dei log, delle attestazioni e dei manifesti che contano. Raggruppali in un'unica Merkle root. Pubblica quella root in un record Label 309. Firma il record se vuoi che l'identità di un progetto o di un'azienda se ne faccia garante.

Tieni SLSA, Sigstore, GitHub Artifact Attestations e in-toto per la provenienza e i metadati della supply chain. Aggiungi Label 309 come àncora temporale pubblica e indipendente che lega l'intero insieme di prove a un momento che nessun fornitore può spostare.

Approfondimenti

• Un solo record per migliaia di file — come il Merkle batching ancora un intero insieme sotto un'unica root.
• Usare la CLI nell'automazione — come guidare publish e verify da una pipeline.
• Proof of Existence vs Sigstore — in cosa differiscono i due livelli e dove si incastrano insieme.
• Provenienza di build SLSA — la specifica di provenienza SLSA.
• Sigstore e il log di trasparenza Rekor — firma keyless con un log pubblico append-only.
• GitHub Artifact Attestations — provenienza di build per gli artefatti costruiti su GitHub.
• in-toto — il framework di integrità per la supply chain del software.