Come dimostrare la gestione delle modifiche da GitHub per SOC 2 o ISO 27001?
il team heygrc
In gran parte sì, se le impostazioni sono corrette. Un flusso di lavoro basato su pull request registra già cosa è cambiato (il diff), chi lo ha revisionato e approvato, cosa è stato eseguito prima del merge (i controlli) e quando è stato unito (il commit di merge). SOC 2 CC8.1 e ISO 27001 A.8.32 richiedono che le modifiche siano autorizzate, testate, approvate e tracciabili, e un repository ben gestito fornisce la maggior parte di queste prove senza strumenti aggiuntivi. Ciò che non offre gratuitamente è la prova dell'applicazione (la dimostrazione che le approvazioni non potevano essere saltate) e il collegamento tra ogni modifica e il controllo che interessa. Questi elementi vanno aggiunti.
Lascia che la protezione del branch gestisca la parte di autorizzazione
La gestione delle modifiche risponde a due domande: ogni modifica è stata autorizzata e puoi dimostrarlo. La pull request mostra l'istanza; la protezione del branch mostra la regola. Richiedi pull request con almeno un'approvazione (due dove conta la segregazione dei compiti), richiedi i controlli di cui ti fidi e richiedi la revisione dei code owner sui percorsi rilevanti. Un revisore che campiona CC8.1 o A.8.32 chiede come sai che una modifica non revisionata non può raggiungere il branch main: le impostazioni di protezione mostrano la regola così com'è oggi, ogni approvazione è un'istanza della sua applicazione e, se la regola è cambiata durante il periodo di audit, il registro di audit del repository (modifiche alle regole e alle protezioni) è il posto dove mostrare quando.
Rendi ogni pull request leggibile come un registro delle modifiche
Il corpo della PR spiega il perché, il diff mostra il cosa, le esecuzioni dei controlli dimostrano che è stato testato, l'approvazione conferma che una seconda persona l'ha accettato e il commit di merge indica quando la modifica è stata unita. Quando è effettivamente stata distribuita è un registro di deployment (un rilascio, un ambiente, un'esecuzione di deployment), che la gestione delle modifiche tratta come un passaggio a sé stante, non qualcosa che il merge dimostra. Mantieni le pull request abbastanza piccole perché una revisione sia effettivamente tale, collega il ticket o l'issue per il motivo aziendale e non fare push direttamente sul branch protetto anche dove puoi, perché è il modo per aggirare la revisione che richiedi a tutti gli altri. Una cronologia ordinata non è vanità: è la popolazione che un revisore campiona.
Sappi cosa GitHub non dimostra
Tre lacune. Il force-push può riscrivere la cronologia sui riferimenti non protetti e gli admin possono bypassare alcune protezioni, quindi la storia dell'applicazione ha dei limiti; è meglio ammetterli onestamente piuttosto che esagerare. Anche la conservazione ha dei limiti: elimina il repository e i record delle pull request scompaiono con esso, e i log di GitHub (il registro di audit dell'organizzazione, i log di Actions) scadono dopo un periodo limitato e dipendente dal piano, quindi esporta ciò di cui il periodo di audit ha bisogno prima che accada. E nulla nel record della pull request collega una modifica al framework: CC8.1 non etichetta un diff e A.8.32 non commenta una pull request. Quel collegamento è ciò che aggiunge una revisione di conformità per PR (heygrc pubblica riscontri che citano la clausola), costruendo il percorso controllo-modifica nello stesso posto in cui vive già la modifica.
# Revisori predefiniti per l'intero repository* @acme/devs+ /security/ @acme/securityCon la protezione del branch che richiede la revisione dei code owner, le modifiche sotto security/ vengono indirizzate al team di sicurezza per l'approvazione. Proteggi anche il file CODEOWNERS allo stesso modo, altrimenti la regola può essere indebolita in una pull request ordinaria. Autorizzazione per i percorsi a rischio, scritta in un file che un revisore può leggere.
Correlati