Cerca controlli di conformità nelle pull request e la maggior parte dei risultati riguarda i controlli di stato obbligatori di GitHub: assicurarsi che la suite di test e il linter siano passati prima di un merge. È una cosa reale e utile, ma non è di questo che tratta questa pagina. Un controllo di conformità è una domanda diversa posta alla stessa pull request: questa modifica tocca un controllo per cui la tua azienda è sottoposta a audit, in SOC 2, ISO 27001, GDPR o un altro framework a cui sei vincolato.
Questa domanda rara volta ha un responsabile nella revisione del codice. Correttezza e sicurezza hanno ciascuna controlli ben definiti; se una modifica ha influenzato un controllo per cui sei sottoposto a audit è una lettura separata, ed è quella che un controllo di conformità sulla pull request aggiunge. Vale la pena essere precisi su cosa sia e cosa non sia questo controllo.
Cosa è e cosa non è
Un controllo di conformità legge il diff, non i risultati dei test. Mappa la modifica effettiva al controllo specifico che influisce e segnalalo per nome, con un livello di dettaglio verificabile. Non è un superamento o un fallimento della suite di test, non è una soglia di copertura e non è un documento di policy che un auditor campiona una volta all'anno. È una lettura per modifica che verifica se la pull request davanti a te ha modificato qualcosa che sei tenuto a mantenere.
Il risultato che lo rende utile è la citazione. "Questo sembra non conforme" è rumore. "Questo rimuove il log di audit per un'azione privilegiata, che ISO 27001:2022 A.8.15 si aspetta che tu mantenga" è qualcosa su cui un ingegnere può agire o discutere. Un controllo di conformità che non può nominare il controllo non vale la pena di essere aggiunto.
Tre modifiche rilevanti per i controlli che si nascondono nelle pull request di routine
Un percorso di accesso allargato. Una pull request amplifica un ruolo IAM o apre una nuova route a una risorsa. Il codice è corretto e potrebbe essere perfettamente sicuro, ma allarga chi può accedere ai dati protetti, che è esattamente ciò di cui tratta SOC 2 CC6.1 (controlli di accesso logico). Può sembrare una modifica di configurazione di routine mentre il controllo che influisce rimane non nominato.
Un log di audit indebolito. Una pulizia rimuove o riduce una riga di log che risultava essere il record di un'azione privilegiata. Nulla si rompe e può sembrare una pulizia innocua, ma la prova che un auditor campiona secondo ISO 27001:2022 A.8.15 (registrazione) ora è scomparsa. La modifica che l'ha causata è il posto più economico per coglierla.
Un nuovo archivio di dati personali senza limiti. Una migrazione aggiunge una tabella che inizia a raccogliere dati personali senza un limite di conservazione. È codice pulito e funzionante, e ti mette silenziosamente dalla parte sbagliata del GDPR Art. 5(1)(e) (limitazione della conservazione), che richiede che i dati personali non siano conservati più a lungo del necessario. Nessuna di queste tre è un bug o una vulnerabilità. Ogni modifica è rilevante per i controlli e si nasconde in una pull request di routine.
Consultivo per impostazione predefinita, bloccante solo se lo scegli
Un controllo di conformità che blocca ogni merge per qualsiasi riscontro abitua le persone a ignorarlo; uno che non blocca mai nulla viene trascurato. L'impostazione predefinita utile è consultiva: il controllo pubblica il controllo e la clausola come commento e uno stato neutro, in modo che il riscontro sia visibile senza interrompere il merge. La decisione di bloccare appartiene alla tua policy di protezione del branch, non allo strumento.
Se un controllo trascurato è effettivamente costoso, qualsiasi cosa che tocchi il controllo degli accessi, la crittografia o i dati personali, puoi richiedere il controllo tramite la protezione del branch nei repository o nei branch protetti in cui è più importante, e lasciarlo consultivo altrove. Il meccanismo dovrebbe permetterti di scegliere la postura piuttosto che imporne una su tutto.
Come aggiungerne uno
Un controllo di conformità viene eseguito sulla pull request nello stesso modo degli altri controlli: viene attivato quando una PR viene aperta o aggiornata, legge il diff rispetto ai framework che hai selezionato e al contesto della tua azienda, e pubblica i controlli che una modifica tocca con la clausola allegata. La parte difficile non è notare che qualcosa è cambiato, ma nominare esattamente quale controllo è stato modificato, correttamente, motivo per cui i framework a cui sei vincolato e il tuo contesto devono alimentare il controllo.
heygrc è progettato per essere quel controllo come un'app GitHub: installalo, comunicagli i tuoi framework e il contesto una volta, e revisiona ogni pull request per l'impatto sulla conformità, pubblicando uno stato neutro dei controlli più commenti in linea in modo che informi piuttosto che bloccare, a meno che tu non decida di richiederlo. La guida di configurazione copre l'onboarding di tre minuti.