Il compliance appartiene alla pull request.
Chiamiamo questa pratica 'compliance review per pull request': analizzare ogni modifica rispetto ai framework che la tua azienda deve rispettare, direttamente nel diff, non mesi dopo in un audit. Questi saggi sono gli argomenti alla base di questa categoria. Brevi, opinati e scritti per chi cambia effettivamente il sistema: ingegneri e ingegneri della sicurezza.
- 00
Revisione di conformità per le pull request.
La revisione del codice si sta suddividendo in ottiche: correttezza, sicurezza e ora conformità. Questo saggio definisce la terza ottica come categoria e spiega perché esiste ora.
- 01
Rilevalo nella PR, non nell'audit.
Un divario di conformità costa meno da correggere nel momento in cui viene scritto e di più il giorno in cui un revisore lo trova.
- 02
La compliance è un controllo CI, non un'esercitazione antincendio trimestrale.
Trattare la compliance come un evento da superare due volte l'anno è il motivo per cui sembra un'esercitazione antincendio. Trattatela come un controllo che viene eseguito su ogni modifica e diventerà noiosa, che è l'obiettivo.
- 03
Il tuo linter è cieco rispetto ai framework.
I linter e gli scanner rilevano difetti e classi di vulnerabilità. Una modifica può essere codice perfetto e comunque violare un obbligo di compliance, perché l'obbligo non è una proprietà del codice, ma del framework.
- 04
I controlli vivono nei diff, non nei documenti Word.
Un controllo scritto in un documento di policy è un'intenzione. Il controllo è reale solo dove il sistema in esecuzione lo applica, e il sistema in esecuzione cambia un diff alla volta.
- 05
L'audit è un indicatore ritardato.
Un audit ti dice cosa era vero mesi fa. Se è l'unico segnale che hai, stai guidando un sistema guardando nello specchietto retrovisore.