Ogni pratica rilevante nell'ingegneria finisce per avere un nome. Questa si chiama revisione di conformità per le pull request: leggere ogni modifica rispetto ai framework di conformità che la tua azienda deve rispettare e identificare il controllo specifico interessato, direttamente nel diff, prima del merge. heygrc è il nostro prodotto in questa categoria, ma la categoria è più ampia di qualsiasi prodotto e merita una sua argomentazione.
Le categorie si dividono e la revisione del codice si sta dividendo ora
Le pratiche non convergono in un unico strumento che fa tutto, si diversificano in specialisti. La revisione del codice si è già divisa una volta: la revisione di correttezza (questa modifica funziona?) e la revisione di sicurezza (questa modifica è sicura?) sono domande diverse, a cui rispondono revisori diversi con conoscenze diverse, sulla stessa pull request. Nessuno si aspetta che un linter trovi un'iniezione, e nessuno si aspetta che uno scanner di sicurezza rilevi un errore di off-by-one.
La conformità è la terza divisione. Che una modifica interessi un controllo su cui sei sottoposto ad audit non è una domanda di correttezza né di sicurezza: una modifica può essere corretta, sicura e comunque allargare un percorso di accesso che SOC 2 CC6.1 monitora, o ridurre un log che ISO 27001:2022 A.8.15 si aspetta esista. Domanda diversa, conoscenza diversa, stesso diff. Quando una domanda viene posta abbastanza spesso con i suoi termini, diventa una categoria.
Perché la categoria esiste ora e non cinque anni fa
Due curve si sono incrociate. La prima: l'assistenza AI sta aumentando la quantità di codice che i team producono, e l'attenzione umana per revisione per modifica non è scalata di conseguenza. I team che utilizzano agenti consegnano più modifiche, più velocemente, con meno lettura umana per riga rispetto a quanto la pratica era stata progettata.
La seconda: la superficie di conformità degli stessi codebase sta crescendo. Più aziende perseguono SOC 2 e ISO 27001 prima, il GDPR è stato affiancato da DORA, NIS 2 e l'EU AI Act, e gli obblighi risiedono sempre più nel codice: nei limiti di conservazione, nei percorsi di accesso, nei log e nel comportamento dei modelli. Più modifiche, meno lettura umana, più obblighi per modifica: la revisione di conformità ha bisogno di automazione nel diff se deve avvenire in modo coerente.
Cosa è la categoria e cosa non è
Un revisore di conformità per le pull request legge la modifica rispetto ai framework selezionati dalla tua azienda e fonda ogni riscontro sul controllo specifico interessato, con un livello di dettaglio che puoi verificare o contestare. Funziona dove avviene già la revisione del codice e informare piuttosto che bloccare: i riscontri sono commenti di revisione e uno stato di verifica, non un merge bloccato.
Non è una piattaforma GRC (non gestisce il tuo programma di conformità né raccoglie le tue prove), non è un audit (è un indicatore anticipato sugli stessi obblighi che l'audit misura) e non è una certificazione (una revisione è una lettura, non un badge). Quegli strumenti mantengono i loro ruoli. Questa categoria esiste per il compito che nessuno di essi svolge: la domanda di conformità, posta su ogni diff, mentre la modifica è ancora economica da correggere.