Cercando SOC 2 nelle pull request si trovano soprattutto checklist di processo: richiedere revisioni, controlli di stato e commit firmati. Queste impostazioni contano. Sono prove che esiste un processo di gestione delle modifiche. CC8.1 (gestione delle modifiche secondo i Common Criteria) riguarda anche se il controllo è stato applicato per una determinata modifica: la modifica è stata autorizzata secondo quanto previsto dalla policy, o un hotfix, un bot o un percorso di emergenza hanno saltato un passaggio richiesto?
Questa guida analizza il dettaglio a livello di pull request. Non spiega di nuovo la differenza tra Tipo I e Tipo II (vedi /guides/how-to-pass-soc-2-as-a-startup) e non mappa l'intera famiglia CC6 di accesso (vedi /guides/what-soc-2-actually-checks-in-your-repo). Si concentra sulla gestione delle modifiche nel momento in cui una pull request viene unita.
La protezione del branch è necessaria, ma non sufficiente
Richiedere una revisione di approvazione e un controllo CI verde è la baseline usuale. Gli auditor verificano se quel processo è stato applicato durante la finestra di osservazione. Un repository con protezione attiva può comunque produrre eccezioni quando qualcuno unisce con override admin, quando un percorso di deploy bypassa il branch protetto o quando un account di automazione unisce senza l'approvazione umana che la policy richiede.
L'indicazione visibile nel codice non è sempre nel codice applicativo. Spesso si trova nei file di workflow, CODEOWNERS, script di deploy o in una modifica di una riga su chi può approvare. Anche queste finiscono nelle pull request.
Esempio pratico: percorso di emergenza che salta l'approvazione richiesta
Un on-call viene allertato. Un ingegnere apre una pull request che aggiunge un job workflow_dispatch con continue-on-error e un percorso che deploya in produzione da una fork personale usando un token a lunga scadenza, documentato come "break-glass". Una seconda pull request nello stesso giorno modifica CODEOWNERS in modo che quel percorso non richieda più il team di piattaforma. Entrambe le pull request sembrano igiene operativa. Il codice applicativo potrebbe non cambiare affatto.
Ciò che interessa a CC8.1 è se le modifiche in produzione passano comunque attraverso il processo di modifica autorizzato. Un percorso break-glass che indebolisce permanentemente le approvazioni richieste è una modifica del controllo, non solo una comodità. Durante una finestra di Tipo II, se l'auditor campiona deploy che hanno usato quel percorso senza l'approvazione documentata, dovrai spiegare un'eccezione. Rilevare i diff di workflow e CODEOWNERS durante la revisione è più economico che spiegarli sei mesi dopo.
Come questo si collega alla finestra di osservazione (senza riesporre l'audit)
Per il Tipo II, l'auditor verifica se i controlli sono stati applicati durante un periodo. Un'unica approvazione saltata all'interno di quella finestra può diventare un'eccezione campionata anche se il resto dell'anno è stato pulito. Per questo l'igiene della gestione delle modifiche durante la finestra non è burocrazia fine a sé stessa: è il modo per evitare sorprese nel parere per cui hai lavorato mesi. I dettagli su prontezza, ambito e selezione dell'auditor rimangono nella guida al processo SOC 2 per startup.
Un controllo di conformità nelle pull request che cita CC8.1 su un gate di approvazione indebolito non approva l'emergenza. Rende visibile la modifica del processo mentre la pull request è ancora aperta.
Dove si inserisce heygrc e il confine dell'onestà
heygrc è progettato per leggere le pull request rispetto ai framework selezionati, inclusa SOC 2 quando abilitata, e per citare criteri come CC8.1 quando una modifica sembra indebolire la gestione delle modifiche (gate di approvazione, controlli richiesti, autorizzazione al deploy). Non esegue l'audit, non raccoglie prove IdP o HR, né emette un parere.
Mantieni il revisore della qualità del codice. CC8.1 riguarda l'integrità del processo sulla modifica, non se l'hotfix era elegante.