Autorizzare il rilascio di un’immagine container richiede una risposta verificabile a una domanda precisa: l’immagine che sarà distribuita è quella costruita dalla sorgente e dal processo approvati? Un tag leggibile come latest o v2 aiuta a trovare un’immagine, ma può essere spostato. Un digest identifica invece il contenuto specifico. La provenienza collega quel digest alla revisione della sorgente, all’identità del processo di build e alle condizioni in cui è stato eseguito. La scheda proposta qui raccoglie queste prove insieme all’esito della verifica, senza confondere la provenienza con una garanzia generale di sicurezza del codice.
Il dossier di approvazione della sicurezza di un sistema tratta il rischio residuo del servizio nel suo insieme. Questa guida è più circoscritta: produce un fascicolo di accettazione per una singola immagine candidata al rilascio. Le attestazioni di artefatto documentate da GitHub mostrano un modo concreto di firmare affermazioni sulla build; la specifica SLSA sulla provenienza chiarisce quali informazioni possono essere verificate. Nessuno dei due riferimenti impone universalmente GitHub o una particolare piattaforma: il controllo va adattato alla catena realmente utilizzata.
Definire l’oggetto esatto della decisione
La scheda deve identificare repository, servizio, ambiente di destinazione e immagine con nome completo e digest. Registrate anche la versione dell’applicazione leggibile dalle persone, ma non usatela come unico identificatore. Se una pipeline produce immagini per più architetture, distinguete il manifesto multiarchitettura e gli artefatti specifici. Altrimenti potreste verificare un digest e distribuire una variante diversa. Indicate chi propone il rilascio e chi ha l’autorità di accettarlo; la persona che compila i dati non deve essere automaticamente quella che giudica le eccezioni.
La decisione riguarda un momento determinato. Se l’immagine viene ricostruita dopo la verifica, anche a parità di tag, il digest cambia e la vecchia accettazione non prova la nuova build. Se la distribuzione recupera l’immagine tramite tag, conservate il digest risolto al momento della distribuzione e confrontatelo con quello accettato. Un processo che mostra soltanto il nome del tag lascia aperta la domanda principale, soprattutto quando il registro consente la sostituzione o la ripubblicazione.
Stabilite il perimetro delle prove. Un’immagine prodotta internamente può avere attestazioni della vostra pipeline; una base image e le dipendenze provengono da altre filiere. La vostra attestazione non certifica automaticamente ogni componente importato. Nel fascicolo collegate la valutazione delle dipendenze e delle vulnerabilità quando richiesta, ma mantenete distinti i relativi esiti. Il contributo all’audit di sicurezza informatica è proprio rendere chiaro quale controllo abbia prodotto quale conclusione.
Costruire la scheda di accettazione
Usate campi stabili che possano essere riletti senza accesso alla memoria del team. Una riga per ogni immagine candidata evita di fondere risultati di revisioni diverse. Collegate i documenti originali, non soltanto schermate di una dashboard. Una schermata può aiutare a spiegare il risultato, ma il verificatore deve poter ricostruire soggetto, firma, predicato e criterio applicato.
| Campo | Valore da raccogliere | Domanda di accettazione |
|---|---|---|
| Soggetto | Nome OCI e digest dell’immagine | È esattamente l’artefatto distribuito? |
| Sorgente | Repository e commit risolto | È la revisione autorizzata? |
| Builder | Identità del workflow o della piattaforma | Rientra fra i processi fidati? |
| Attestazione | Riferimento, tipo, firma e disponibilità | È associata al digest e verificabile? |
| Verifica | Strumento, politica, data, esito e operatore | Sono state controllate le proprietà attese? |
| Rilascio | Ambiente, evento di deploy e approvatore | È stato distribuito il soggetto accettato? |
La tabella non è una certificazione. Per ogni campo decidete che cosa significa “conforme” nel vostro contesto. Potete accettare soltanto un repository organizzativo e un workflow di build specifico, oppure richiedere che il commit appartenga a un ramo protetto e abbia superato le revisioni previste. Se la politica è vaga, una verifica crittografica positiva può essere scambiata per approvazione di un builder sconosciuto. Conservate quindi la versione della politica applicata insieme al risultato.
Collegare l’immagine alla revisione sorgente
La revisione sorgente va indicata con un identificatore immutabile, per esempio il commit risolto, non solo con il nome di un ramo. Un ramo può avanzare fra build e rilascio. Nel fascicolo verificate che la revisione indicata dall’attestazione coincida con quella sottoposta al processo di autorizzazione. Se una build è partita da una richiesta di modifica, distinguete commit iniziale, commit di merge e revisione effettivamente usata. La scelta dipende dalla piattaforma, ma l’ambiguità non deve essere lasciata al lettore dell’evidenza.
Un’approvazione del codice e un’attestazione della build coprono passaggi diversi. La prima riguarda la modifica proposta e le regole di revisione; la seconda collega un artefatto a un processo e ai suoi input dichiarati. La politica di sicurezza aziendale può stabilire chi approva ciascun passaggio. Non considerate la presenza del nome dell’approvatore nel sistema di versionamento come prova che egli abbia esaminato l’immagine prodotta. Anche una revisione autorizzata può essere costruita da un workflow non previsto o con parametri modificati.
Controllate le dipendenze della build dichiarate nel predicato, nei limiti delle informazioni disponibili. Una provenienza ben formata può indicare sorgente, builder e parametri senza dimostrare che una dipendenza esterna fosse innocua. Se il rilascio richiede una base image approvata, stabilite quale digest è ammesso e come il cambio viene valutato. La mappatura dei sistemi e dei flussi aiuta a collocare il componente nel servizio, ma il controllo sulla base image richiede prove della filiera software, non una sola mappa architetturale.
Capire che cosa attesta il builder
L’identità del builder descrive il processo che ha prodotto l’artefatto. Confrontatela con la lista dei processi autorizzati per il servizio: repository, workflow, ambiente e permessi rilevanti. Un’attestazione emessa da una pipeline di prova può essere valida dal punto di vista della firma e tuttavia non autorizzata per produzione. La domanda non è soltanto “la firma è autentica?”, ma “questa identità poteva costruire questo servizio con queste condizioni?”.
La documentazione GitHub per l’uso delle attestazioni distingue la generazione per immagini container dalla verifica. Nell’esempio GitHub, il soggetto usa nome completo e digest; la verifica via CLI di un’immagine OCI usa il prefisso oci:// e il repository atteso. È un esempio operativo, non un obbligo per chi usa altri registri o servizi. Registrate versione dello strumento, comando o procedura e output essenziale, evitando di incollare credenziali nei verbali.
Verificate inoltre la protezione del workflow. Chi può modificare il file di build, i segreti, i permessi di pubblicazione e la configurazione del registro? Una firma non compensa un processo in cui chiunque possa cambiare silenziosamente i passaggi eseguiti. Le regole del repository, le autorizzazioni del workflow e la revisione delle modifiche alla pipeline fanno parte della fiducia accordata al builder. Non descrivete un livello SLSA come un bollino automatico: la conformità a uno specifico livello richiede le proprietà previste dal relativo modello e una valutazione del processo.
Verificare firma, soggetto e politica insieme
La verifica deve produrre almeno tre conclusioni separate. Primo, l’attestazione è autentica secondo il meccanismo utilizzato e riferita all’artefatto corretto. Secondo, la sorgente e il builder dichiarati corrispondono ai valori autorizzati. Terzo, gli eventuali requisiti aggiuntivi, come workflow approvato e ambiente di rilascio, sono soddisfatti. Un output generico “verified” può coprire soltanto il primo punto. Annotate esplicitamente i controlli fatti e quelli non disponibili nello strumento usato.
Eseguite la verifica sul digest che intendete distribuire. Se l’attestazione è conservata nel registro, controllate che sia recuperabile nelle condizioni reali della distribuzione. Un’immagine può essere firmata durante la build e perdere la relazione con l’attestazione quando viene copiata fra registri, ripacchettata o pubblicata sotto un altro nome. In questo caso la risposta non è dichiarare falsa la firma: è documentare quale passaggio ha interrotto la catena di prova e ripetere la verifica nel punto corretto.
Nel caso GitHub, il comando illustrativo gh attestation verify oci://REGISTRY/ORGANIZZAZIONE/IMMAGINE:TAG -R ORGANIZZAZIONE/REPOSITORY va completato con un confronto del digest risolto e dei campi restituiti con la politica interna. GitHub avverte espressamente che l’attestazione non garantisce che l’artefatto sia sicuro. Un’immagine può avere provenienza perfettamente verificabile e contenere una vulnerabilità o una configurazione pericolosa. L’esito di provenienza deve quindi rimanere una voce del fascicolo, non sostituire scansioni, test e valutazioni di rischio pertinenti.
Gestire assenza o incoerenza delle prove
Prevedete stati diversi per “verifica fallita”, “prova mancante” e “prova non valutata”. Una firma che non corrisponde al soggetto è un errore diverso dall’impossibilità temporanea di recuperare l’attestazione. Un campo sorgente che non corrisponde alla revisione autorizzata è diverso da un’attestazione integra ma emessa da una pipeline non ancora censita. Separare i casi aiuta a decidere se occorre fermare il rilascio, ricostruire l’immagine, correggere il collegamento o chiarire una procedura.
Se la provenienza manca, non inventate una ricostruzione retrospettiva da nomi di file o chat. Potete rieseguire una build attraverso il processo controllato e attestare il nuovo artefatto, mantenendo evidenza del cambiamento di digest. Una deroga eccezionale richiede responsabile, motivazione, protezioni temporanee, scadenza e criterio di chiusura; non dovrebbe trasformarsi nell’approvazione ordinaria delle immagini prive di prova. Il verbale sul rischio residuo può contenere la decisione più ampia, mentre questa scheda conserva il dettaglio tecnico del rilascio.
Se il predicato contiene più sorgenti o input, non scegliete automaticamente quello più familiare. Una build può usare un repository applicativo e una libreria di configurazione separata. Identificate quali input sono decisivi per il comportamento dell’immagine e chi ne autorizza le modifiche. Registrate l’incertezza quando il processo non espone tutto; la provenienza è utile proprio perché rende visibile il confine fra ciò che è verificato e ciò che resta affidato a un altro controllo.
Un caso di rilascio completo
Un team prepara un’immagine per un portale clienti. La richiesta cita il commit approvato C1 e il tag candidato release-42. L’operatore risolve il tag nel digest D1, recupera l’attestazione e verifica che il soggetto sia D1. Il predicato indica C1 come sorgente e il workflow produttivo autorizzato come builder. Il secondo operatore confronta questi dati con la richiesta, controlla la firma e salva il risultato. La scheda riporta anche il digest della base image previsto dalla politica e l’esito separato delle verifiche di sicurezza applicabili.
Durante la distribuzione emerge che l’ambiente di staging usa D1, ma la configurazione di produzione punta ancora al tag, ora associato a D2. L’approvazione non può essere estesa per analogia a D2. Il team blocca quel passaggio, risolve perché il tag sia cambiato e verifica il nuovo digest o ripristina la distribuzione di D1. La conclusione “build approvata” sarebbe stata corretta solo per il soggetto esaminato. Conservare l’evento di deploy nella scheda permette di scoprire la differenza prima che venga interpretata come un semplice dettaglio del registro.
Dopo il rilascio, un revisore prende digest, attestazione e politica senza chiedere spiegazioni a chi ha costruito l’immagine. Deve poter vedere quali proprietà erano obbligatorie, quali sono state osservate e quale evento di deploy ha effettivamente consumato l’artefatto. Se la relazione può essere ricostruita soltanto attraverso una schermata che non conserva la versione storica, migliorate il metodo di archiviazione. Il criterio è la trasferibilità della prova, non la quantità di allegati.
Mantenere la verifica utile nei cambiamenti successivi
Riaprite la scheda quando cambiano sorgente, builder, workflow, registro o processo di distribuzione. Un aggiornamento di dipendenze produce un nuovo digest; una migrazione della pipeline cambia il soggetto della fiducia anche se il codice resta simile. Stabilite chi aggiorna la lista dei builder autorizzati e chi verifica che l’ambiente di produzione usi il digest approvato. Conservate le eccezioni aperte in modo visibile al responsabile del servizio.
Le prove di provenienza possono alimentare un audit, ma non diventano da sole una valutazione dell’intera sicurezza applicativa. Un incarico di audit ben delimitato può esaminare codice, configurazione e processo di rilascio con metodi distinti. La scheda di accettazione risponde a una domanda più limitata e molto concreta: questa immagine, identificata da questo digest, è stata prodotta dal processo e dalla revisione che abbiamo autorizzato, ed è proprio quella distribuita? Se ogni passaggio ha un esito e un responsabile, la decisione rimane verificabile anche dopo la rotazione del personale o della piattaforma.
Attribuire la verifica fra piattaforma, registro e team applicativo
Quando l’immagine attraversa servizi gestiti, chiarite chi conserva l’attestazione, chi protegge il registro, chi definisce le identità dei builder ammessi e chi applica la politica prima del deploy. La matrice delle responsabilità cloud offre un metodo per assegnare questi passaggi. Un fornitore può mantenere disponibile il registro senza sapere quale revisione del vostro repository sia stata autorizzata; il team applicativo può approvare il codice senza controllare chi abbia pubblicato il digest. Lasciare entrambe le attività senza proprietario rende la verifica apparentemente automatica ma incompleta.
Provate il percorso durante un guasto ordinario, non soltanto durante una dimostrazione riuscita. Se il servizio delle attestazioni è temporaneamente indisponibile, la politica deve dire se il rilascio attende, usa una verifica offline già predisposta o avvia una deroga formale. Non inventate un esito positivo sulla base dell’ultima immagine disponibile. Dopo il ripristino, annotate se la prova è stata recuperata e se coincide con l’immagine effettivamente distribuita. La gestione dell’eccezione mostra se il controllo rimane operativo quando il percorso ideale non è disponibile.