La maggior parte dei team che prendono sul serio le pull request esegue già una o due revisioni su ogni modifica. Un bug checker come Cursor Bugbot o CodeRabbit legge il diff e chiede se il codice è corretto. Un agente di sicurezza lo legge e chiede se il codice è sicuro: un'iniezione, un controllo di accesso rotto, una credenziale esposta. Entrambi rispondono a domande reali, e una modifica seria merita entrambe.
C'è una terza domanda che la revisione del codice raramente assegna a un responsabile: questa modifica rispetta ancora i framework di conformità per cui l'azienda è sottoposta a audit? Non 'è un bug' e non 'è una vulnerabilità', ma 'toccando un controllo in SOC 2, ISO 27001 o GDPR, le prove sono ancora valide dopo il deploy?' È una domanda diversa dalla correttezza e dalla sicurezza, ed è per questa che heygrc è stato creato. Si affianca alle altre due senza sostituirle.
Corretto, sicuro e comunque un riscontro
Le tre domande sono indipendenti. Una modifica può essere un bug ma non una vulnerabilità. Può essere una vulnerabilità ma non un problema di conformità. E può essere codice pulito e funzionante che comunque modifica un controllo su cui verrai sottoposto a audit. Questo ultimo caso è quello che raramente ha un revisore in stanza.
Ecco il tipo di modifica a cui ci riferiamo. Considerala illustrativa: una riga di codice pulito che compila ed esegue, e che non è né il bug né la vulnerabilità nel diff.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}Il branch è codice pulito e funzionante: restituisce una decisione e non c'è nulla che sia un bug o una vulnerabilità. Ma prende una decisione completamente automatizzata su una persona, negandole il rimborso, senza possibilità di revisione umana. Quando una decisione del genere produce un effetto giuridico o comunque significativo, il GDPR Art. 22 dà alla persona il diritto di non essere sottoposta a tale decisione e il diritto di ottenere l'intervento umano. Quello che questa modifica ha effettivamente introdotto è una domanda di conformità a cui rispondere, non un difetto da correggere.
Perché la terza domanda non ha un responsabile
Un bug checker e un agente di sicurezza possono essere 'framework-blind' di proposito, e questa è la loro forza. Le loro regole sono universali: un use-after-free è un use-after-free in ogni repository, una query non parametrizzata è un'iniezione ovunque. Le regole universali sono il motivo per cui questi strumenti funzionano senza configurazione.
La conformità è l'opposto. Se una modifica è un riscontro dipende da quali framework sei tenuto a rispettare, quali controlli hai documentato e su cosa si basava il tuo ultimo audit. Lo stesso diff che per un'azienda non è nulla, per un'altra rappresenta un vuoto di evidenza per SOC 2 CC7.2. Non è qualcosa che una regola 'framework-blind' può gestire da sola, perché il problema non è una proprietà del codice. È una proprietà dei tuoi obblighi, e deve essere letto alla luce di questi.
Sovrapponi le lenti, non scegliere tra loro
La conclusione non è 'aggiungi un altro strumento'. È che una pull request viene letta al meglio attraverso tre lenti, non una: è corretto, è sicuro, rispetta ancora i nostri framework. Tieni il tuo bug checker. Tieni il tuo agente di sicurezza. Sono bravi nelle loro domande, e heygrc non cerca di rispondere alle loro. heygrc aggiunge la terza lente e la segnalazione avviene nell'unico modo in cui un riscontro di conformità ha valore: citando esattamente il controllo interessato.
L'esempio sopra è illustrativo, il tipo di modifica che solleva la terza domanda, non un incidente specifico. Ma la forma è proprio il punto: le modifiche che influenzano la tua postura di conformità di solito non sono quelle buggate o insicure. Sono quelle pulite e apparentemente corrette che, in modo silenzioso, toccano un controllo, che è una cosa diversa da cercare rispetto a un bug o una vulnerabilità.