L'audit è il momento in cui lo scopri. La pull request è il momento in cui è successo. Da qualche parte tra questi due momenti, spesso separati da mesi, un controllo che l'auditor campionerà ha smesso di funzionare e nessuno se n'è accorto, perché la modifica che l'ha rotto non sembrava una modifica di conformità. Sembrava una pulizia.
Ecco la situazione. Il controllo è l'ISO 27001:2022 A.8.15, il logging. La modifica è una riga eliminata.
La modifica
Una pull request riordina una funzione che aggiorna il ruolo di un utente. C'è una chiamata di log al centro che l'autore legge come rumore, viene attivata ad ogni modifica del ruolo e ingombra l'output, quindi viene rimossa. La funzione funziona ancora. I test passano ancora. Il diff è più corto di una riga e, se mai, più pulito.
async function updateRole(actor, target, role) { await db.roles.set(target, role)- await audit.log("role.update", { actor, target, role }) return ok()}Quella riga era il record di audit per una modifica dei diritti di accesso. L'A.8.15 (logging) richiede che gli eventi rilevanti per la sicurezza, incluse le modifiche ai privilegi, vengano registrati e conservati, e l'A.8.16 (monitoraggio) dipende dall'esistenza di quel record. Eliminarla rimuove l'unica prova che un ruolo sia mai stato modificato.
Perché nessuno l'ha notato
Un revisore che guarda questo diff vede una riga di log rimossa. Per notare il problema, dovrebbe sapere che questo log specifico è la prova per un controllo, che il controllo è l'A.8.15 e che l'A.8.15 è nel campo della certificazione. Sono tre informazioni sul framework che un revisore di codice non ha in mente mentre approva un refactoring di routine.
Questa è la lacuna. Il punto di controllo è nel posto giusto: la revisione del codice esamina già ogni modifica, appositamente, prima che venga distribuita. Ciò che manca è la consapevolezza del framework per riconoscere che una riga apparentemente normale è portante per un audit.
Cosa costa dopo
Se notato qui, è un revert di una riga e una conversazione di trenta secondi. L'autore ha ancora tutto il cambiamento in mente. Se notato durante l'audit, è un'eccezione: il controllo non ha funzionato durante il periodo, e ora qualcuno deve ricostruire quando il logging è stato interrotto, cosa dipendeva da esso e come ripristinarlo in modo sicuro, con una scadenza, possibilmente dopo che l'autore ha lasciato il progetto.
Il costo di una lacuna di conformità è determinato da una cosa sola: quanto tempo è rimasta lì prima che qualcuno se ne accorgesse. La pull request è il posto più economico per notarlo.
Il punto
La conformità fallisce in una PR di cinque righe, non durante l'audit. L'audit è un indicatore ritardato di una decisione che qualcuno ha preso in un diff settimane prima. heygrc è stato creato per leggere quel diff rispetto ai framework che devi rispettare e indicare il controllo che una modifica tocca, A.8.15, nella pull request, mentre la correzione è ancora economica.