L'analisi statica è diventata molto brava a rispondere a una domanda specifica: questo codice è sbagliato? Trova il dereferenziamento nullo, l'iniezione, la deserializzazione non sicura, il pattern noto dannoso. Ciò che non può chiedere è un'altra domanda del tutto diversa: questa modifica viola un dovere che risiede in un regolamento?
Due domande diverse
Un linter ragiona sul codice che ha davanti: tipi, flusso di controllo, taint, firme di vulnerabilità note. È cieco rispetto ai framework per progettazione, perché le regole che applica sono universali, le stesse in ogni repository al mondo.
La compliance è l'opposto. Se una modifica è un problema dipende da fatti che il codice non contiene: quali framework la tua azienda deve rispettare, cosa conta come dato personale nel tuo dominio, per quanto tempo sei autorizzato a conservarlo, dove è autorizzato a fluire. La stessa diff può essere perfettamente conforme in un'azienda e un riscontro in un'altra.
La modifica corretta e non conforme allo stesso tempo
Aggiungi una riga di log che registra l'intero corpo della richiesta per debuggare un flusso di checkout. Il codice è corretto. Compila, funziona, nessun linter obietta, i test passano. Scrive anche un'email e un indirizzo del cliente nei tuoi log, che è più dati personali di quanto necessario per lo scopo, e questo è territorio GDPR Art. 5(1)(c).
Nessuno strumento che ragiona sulla qualità del codice segnalerà questo, perché non c'è nulla di sbagliato nella qualità del codice. Il problema è visibile solo se si legge la modifica rispetto agli obblighi di protezione dei dati che l'azienda ha effettivamente. Questo è il livello consapevole dei framework che i linter non hanno.
Il livello mancante, non una sostituzione
Questo non è un argomento contro i linter o gli scanner. Manteneteli; catturano cose che heygrc non catturerà mai. È un argomento che esiste un'intera categoria di rischi sopra di essi, gli obblighi dei framework, che nessuna quantità di analisi della qualità del codice può vedere.
heygrc è quel livello. Legge la modifica rispetto ai tuoi framework e cita il controllo specifico, in modo che il punto cieco rispetto ai framework nei tuoi strumenti esistenti ottenga un paio di occhi.