La separazione dei compiti in una pipeline CI/CD non si dimostra con una schermata che mostra due pulsanti di approvazione. Occorre poter seguire una singola modifica dalla richiesta al codice esaminato, dalla build all’artefatto e dall’artefatto all’evento di distribuzione. A ogni passaggio va chiesto chi poteva agire, chi ha agito e se la persona che approvava era indipendente secondo la regola dichiarata. Questo articolo propone un fascicolo di rilascio che collega richiedente, revisore, commit, identità della build, approvatore dell’ambiente e deploy, con un esempio di eccezione urgente.
La politica di sicurezza informatica stabilisce i ruoli generali. Qui si costruisce la prova per una release precisa. Le regole di branch protection documentate da GitHub e le protezioni degli ambienti di deploy sono esempi di capacità configurabili, non obblighi universali né prova che ogni repository le abbia attivate. NIST SP 800-53A Rev. 5 aiuta a scegliere come esaminare, intervistare e testare il controllo, senza prescrivere una piattaforma CI/CD.
Definire quale decisione è separata
Una pipeline contiene decisioni diverse: autorizzare il cambiamento funzionale, accettare il codice, eseguire la build, consentire la distribuzione e verificare il risultato. Non tutte richiedono persone diverse in ogni organizzazione, ma il modello scelto deve essere esplicito. Identificate i passaggi che non possono essere conclusi dalla stessa persona che li ha richiesti o eseguiti. Per una modifica a una regola di sicurezza, per esempio, la revisione del codice e l’approvazione del deploy potrebbero avere criteri differenti.
Scrivete il controllo in termini verificabili: “Per i rilasci in produzione, una persona autorizzata diversa dall’autore della modifica approva il contenuto finale, e un approvatore autorizzato sblocca l’ambiente dopo che le verifiche richieste sono completate.” Poi definite le eccezioni, gli amministratori e gli account di servizio. Una regola che vale solo per utenti ordinari può essere aggirata da chi possiede privilegi di bypass; il fascicolo deve mostrare se tali privilegi esistono e come vengono sorvegliati.
Definite anche il perimetro. Un repository può avere più rami, ambienti e workflow. Un’approvazione per staging non prova l’approvazione di produzione. Una richiesta di modifica approvata prima dell’ultimo push può non coprire il codice effettivamente distribuito, se le impostazioni non richiedono una nuova revisione. La documentazione GitHub espone opzioni per rifiutare approvazioni obsolete o richiedere la revisione dell’ultimo push; il controllo deve descrivere quali opzioni sono state scelte nella vostra configurazione e perché.
Il fascicolo minimo di una release
Usate identificativi che si possano collegare senza interpretazione orale. Il ticket indica l’intento; la richiesta di modifica contiene la discussione sul codice; il commit identifica la revisione; la build produce un artefatto; il deploy mostra quale artefatto ha raggiunto l’ambiente. Salvate i riferimenti e gli esiti, evitando di copiare interi log con segreti nel verbale. Una persona non presente al rilascio deve poter ricostruire la catena.
| Elemento | Domanda cui risponde |
|---|---|
| Richiesta | Chi ha chiesto il cambiamento e con quale motivo? |
| Revisione | Chi ha approvato il contenuto finale e con quali limiti? |
| Commit | Quale revisione della sorgente è stata costruita? |
| Build | Quale workflow, identità e artefatto risultano? |
| Gate | Chi o che cosa ha autorizzato l’ambiente di produzione? |
| Deploy | Quale artefatto è stato distribuito, dove e quando? |
| Verifica | Che cosa è stato osservato dopo la distribuzione? |
Aggiungete il riferimento alla versione delle regole applicate al momento del rilascio. Le impostazioni attuali non provano come fosse protetto un ramo sei mesi fa. Se la piattaforma conserva un audit trail delle modifiche alle regole, collegatelo o esportate la configurazione secondo le vostre possibilità. Quando manca una storia affidabile, dichiarate il limite. Un diagramma di processo approvato oggi non ricostruisce automaticamente una release passata.
Collegare richiesta e commit finale
Una richiesta dovrebbe descrivere il comportamento voluto e la valutazione del rischio, non soltanto il numero di ticket. Il revisore del codice deve sapere quali file e configurazioni sono stati modificati. Conservate il commit finale effettivamente fuso nel ramo che alimenta la build. Se la piattaforma crea un commit di merge diverso dalla testa della richiesta, annotate la relazione. Non basta registrare l’URL della richiesta senza verificare quale revisione la pipeline ha usato.
Controllate gli aggiornamenti dopo la revisione. Un autore può aggiungere un commit legittimo per rispondere ai commenti; la domanda è se la politica richieda e registri l’esame della nuova versione. Non date per scontato che ogni piattaforma annulli automaticamente le approvazioni precedenti: il comportamento dipende dalle impostazioni. Una prova di separazione dei compiti deve mostrare l’effettiva configurazione del repository e l’identità di chi ha approvato la versione finale.
Le modifiche alla pipeline stessa meritano attenzione particolare. Chi può cambiare il workflow, i permessi dei token, i segreti o il riferimento all’artefatto? Una revisione rigorosa del codice applicativo può essere vanificata se il processo di build cambia senza lo stesso controllo. La guida all’audit di sicurezza aiuta a scegliere un esame più ampio; il fascicolo della release deve almeno indicare quale versione del workflow è stata eseguita.
Dimostrare l’identità della build e dell’artefatto
Collegate il commit a un’esecuzione concreta della pipeline e a un artefatto identificabile, preferibilmente con un digest o altro identificatore immutabile. Un numero di build in un’interfaccia è utile, ma non basta se durante il deploy viene recuperato un tag mutabile che punta a un contenuto diverso. Registrate la provenienza disponibile e il risultato della verifica rispetto alla vostra politica. Una attestazione firmata può sostenere il collegamento fra sorgente e build, ma non garantisce che il codice sia sicuro o che la distribuzione abbia usato proprio quell’artefatto.
Per immagini container, confrontate digest della build, digest nel registro e digest consumato dall’ambiente. Per pacchetti o file, usate un identificatore equivalente. Se un artefatto viene ricostruito dopo l’approvazione, trattatelo come un nuovo oggetto da collegare alla decisione. Il piano di hardening riguarda la configurazione del sistema destinazione; il fascicolo CI/CD risponde alla diversa domanda su quale contenuto sia stato autorizzato e installato.
Verificate chi può lanciare la pipeline e con quali parametri. Un workflow approvato può avere input che modificano sorgente o ambiente. Documentate quali parametri sono ammessi, quali richiedono nuova approvazione e quali vengono registrati. Se la build dipende da componenti esterni, indicatene le versioni rilevanti nella misura in cui il vostro processo le conosce. Non promettete riproducibilità completa quando la pipeline non conserva tutti gli input; dichiarate il livello di prova disponibile.
Separare l’approvazione del deploy
Una revisione del codice non equivale automaticamente ad autorizzare la messa in produzione. Il proprietario del servizio può dover valutare finestra, dipendenze, rollback e comunicazione. Se usate un ambiente protetto, controllate chi può approvarlo e se la piattaforma impedisce che chi ha avviato il job approvi se stesso. Nelle impostazioni GitHub questa prevenzione è un’opzione configurabile, non un effetto implicito del semplice nome “protected environment”. Registrate la regola effettiva e il piano commerciale applicabile, perché alcune capacità hanno condizioni di disponibilità.
La persona che approva deve vedere la revisione e l’artefatto cui si riferisce il gate. Se una nuova build appare mentre la richiesta è in attesa, l’approvazione deve essere legata a un oggetto inequivocabile. Verificate anche se sono consentiti bypass da amministratori o integrazioni. Un bypass autorizzato può avere uno scopo operativo; il controllo richiede motivazione, avviso e revisione successiva. Un registro che mostra soltanto “deploy riuscito” non dimostra perché il gate sia stato aperto.
Conservate lo stato dei controlli automatici richiesti, ma non li presentate come approvazione umana. Un test può passare senza coprire il rischio della modifica; un revisore può approvare il codice senza sapere che un test era stato disattivato. La scheda distingue risultato tecnico, giudizio umano e autorizzazione operativa. Un flusso che li riassume in un solo semaforo deve consentire di aprire i dettagli usati nella decisione.
Esercitare un caso ordinario
Scegliete una release non critica e ricostruite la catena dopo il fatto. Dal ticket risalite alla richiesta di modifica, ai commenti e al commit finale; dal commit passate alla build e all’artefatto; dal deploy verificate ambiente, approvatore e risultato osservato. Chiedete a una persona diversa dal team di rilascio di seguire i riferimenti. Annotate ogni punto in cui serve una spiegazione orale o un accesso privilegiato non previsto.
Confrontate identità reali, non solo nomi di ruolo. Se l’autore ha due account, la presenza di due nomi può non rappresentare due persone. Se un bot applica un’approvazione automatica, spiegate chi ne controlla la regola e quale revisione indipendente esiste. Non tutte le attività di automazione violano la separazione dei compiti; il problema è una concentrazione non dichiarata delle facoltà di proporre, modificare e autorizzare l’esito finale.
Valutate il risultato della release, non soltanto la riuscita del workflow. La verifica post-deploy può comprendere una transazione sintetica, l’esame dei log e il controllo dell’assenza di regressioni note. La guida all’architettura dei log sostiene questa parte. Se il deploy è stato annullato, il fascicolo deve collegare anche l’evento di rollback e l’artefatto ripristinato. Una pipeline verde prima del rilascio non dimostra che il servizio sia rimasto utilizzabile dopo.
Trattare un rilascio urgente senza cancellare la traccia
Un incidente può richiedere una correzione rapida. Definite in anticipo chi può invocare il percorso urgente, quale rischio giustifica la deroga e quali controlli minimi restano. La deroga non dovrebbe permettere a una sola persona di modificare codice e distribuirlo senza alcuna tracciabilità. Se una revisione preventiva non è praticabile, stabilite come vengono conservati i fatti e quando una persona indipendente esaminerà commit, build e risultato. La revisione successiva non fa diventare retroattivamente esistente un’approvazione preventiva; descrive una compensazione.
Nel fascicolo distinguete le fasi svolte prima e dopo il deploy. Indicate chi ha deciso l’urgenza, quale sistema era colpito, che cosa è stato distribuito e quali segnali hanno confermato la riduzione del problema. Un’eccezione ricorrente rivela forse una pipeline ordinaria troppo lenta o una politica non realistica. Analizzatela come problema di processo, invece di normalizzare la deroga. La decisione sul rischio residuo può documentare ciò che resta aperto, ma non deve mascherare un obbligo applicabile.
Revocate i privilegi temporanei dopo la crisi. Un account elevato creato per un hotfix può diventare un percorso permanente di bypass. Controllate i log di uso, la rimozione dell’accesso e l’aggiornamento delle istruzioni. Se l’urgenza ha impedito una verifica dell’artefatto, ripetete il controllo appena possibile e decidete se mantenere, ricostruire o sostituire l’immagine in produzione.
Un esempio di fascicolo e del suo limite
Un team modifica una regola di autorizzazione nel portale clienti. Il ticket descrive l’accesso trasversale che la modifica deve impedire. La richiesta di modifica contiene l’approvazione di una persona diversa dall’autore dopo l’ultimo commit. La pipeline di produzione costruisce l’artefatto A1 dalla revisione C1; la scheda conserva il riferimento alla build e al digest. L’approvatore dell’ambiente sblocca il job e il deploy registra A1. Un test controllato mostra che il secondo cliente non può leggere il documento del primo.
Durante il riesame, il verificatore nota che il job di produzione ammette un parametro per scegliere un’altra revisione. Nell’esecuzione esaminata il parametro corrisponde a C1, dunque la catena di questa release è ricostruibile. Il rischio sistemico resta però: un futuro operatore potrebbe scegliere una revisione non approvata. Il team apre un’azione per limitare il parametro e monitorare i bypass. Il fascicolo distingue l’esito della release concreta dalla conclusione sull’efficacia generale della separazione dei compiti.
Il proprietario del controllo ripete poi la prova con una richiesta di modifica aggiornata dopo l’approvazione e verifica se le regole bloccano il merge o richiedono nuova revisione. Conserva risultato e impostazioni effettive. NIST SP 800-53A supporta questa distinzione fra esame documentale e test di meccanismo. Il fascicolo non pretende una certificazione: mostra quali passaggi della catena sono stati osservati, dove esiste un limite e quale correzione sarà provata.
Riesaminare la separazione quando cambia la pipeline
Riaprite il controllo dopo modifiche a branch, workflow, ambiente, identità di servizio, registro degli artefatti o processo di rilascio. Un nuovo strumento può preservare la stessa separazione con evidenze diverse; un aggiornamento apparentemente minore può introdurre un bypass. Conservate la mappa fra passaggi e prove invece di vincolare tutto a un nome di prodotto. La capacità di ricostruire una release passata è il criterio che resta valido dopo una migrazione.
Nel riesame periodico prendete un campione di release ordinarie e di eccezioni. Verificate se chi approva ha davvero visto il contenuto finale, se la build è riconducibile al commit esaminato e se il deploy ha consumato l’artefatto autorizzato. Una dichiarazione “abbiamo la branch protection” copre solo una parte. Il fascicolo completo permette alla direzione di sapere dove la separazione è effettiva e dove dipende da una persona, da un’impostazione revocabile o da un controllo non ancora provato.