Gestione delle modifiche, nella pipeline.
CC8.1 è il criterio SOC 2 sulla gestione delle modifiche: le modifiche all'infrastruttura, ai dati e al software devono essere autorizzate, progettate, sviluppate, testate e approvate prima di essere messe in produzione. Gran parte di questo processo risiede nella pipeline e nella protezione dei branch, il che significa che una pull request può rimuovere silenziosamente i controlli che regolano il modo in cui le modifiche vengono distribuite.
The shapes the same control failure takes.
CC8.1 si indebolisce quando una modifica allenta il processo che dovrebbe governare le modifiche. Le forme ricorrenti:
Un'approvazione obbligatoria viene rimossa
Un controllo di revisione o un gate di approvazione obbligatorio prima di un deploy in produzione viene eliminato dalla configurazione CI o dalla protezione del branch, consentendo alle modifiche di essere distribuite senza autorizzazione.
Una migrazione salta la revisione
Una migrazione del database o una modifica dei dati viene configurata per essere eseguita al deploy senza una revisione o approvazione separata per una modifica che altera i dati di produzione.
I test smettono di bloccare il merge
Un controllo di stato obbligatorio (la suite di test, una scansione di sicurezza) viene reso non bloccante o rimosso, consentendo alle modifiche non verificate di essere unite.
Viene aggiunto un percorso di bypass
Viene aggiunto un percorso di emergenza o amministrativo che consente a una modifica di raggiungere la produzione al di fuori della pipeline normale, senza controlli equivalenti.
Il rollback viene rimosso
Un percorso di rollback sicuro o una migrazione inversa viene eliminato, consentendo a una modifica di essere distribuita senza la possibilità di essere annullata in modo pulito se qualcosa va storto.
Un'approvazione di deploy obbligatoria, rimossa.
Un'approvazione manuale obbligatoria prima dei deploy in produzione ha rallentato i rilasci, quindi una modifica rimuove la regola di protezione. I deploy diventano più veloci e ora qualsiasi merge in main raggiunge la produzione senza che nessuno approvi la modifica.
jobs: deploy:- environment:- name: production # requires a reviewer approval steps:Rimuovere l'approvazione obbligatoria per l'ambiente di produzione significa che le modifiche ora raggiungono la produzione senza autorizzazione. CC8.1 richiede che le modifiche siano autorizzate e approvate prima di essere messe in produzione. Se le approvazioni sono troppo lente, limitare chi o cosa le richiede, o automatizzare i controlli, ma mantenere un passaggio di approvazione invece di rimuoverlo.
La gestione delle modifiche viene campionata in base alle modifiche reali.
Un auditor campiona le modifiche che sono state distribuite in produzione e verifica le prove che ciascuna è stata revisionata, testata e approvata, spesso la pull request, le sue approvazioni e i controlli superati. Una modifica che ha rimosso un'approvazione obbligatoria o reso un test non bloccante è il vuoto dietro quelle prove, ed è visibile nel diff della pipeline o della configurazione di protezione del branch.
Una revisione, non il tuo processo di rilascio.
heygrc segnalerà le modifiche che interessano CC8.1 e citerà il criterio in modo che la correzione avvenga nella pull request. Non esegue i tuoi deploy né gestisce la protezione dei tuoi branch. Rileva il momento in cui una modifica allenta il processo che governano le modifiche, direttamente nel diff.