Come iniziare a fare code review orientata alla sicurezza prima del rilascio con il nostro team?

Sul fronte dell'automazione, la scansione delle dipendenze è fondamentale tanto quanto l'analisi statica. Configurate strumenti open source di dependency checking che verifichino in fase di build le vulnerabilità note nelle librerie esterne che utilizzate. Inoltre, per prevenire falle di autorizzazione, rendete obbligatori a livello di codice i test unitari e di integrazione che controllano la logica di business; nessun codice dovrebbe passare senza aver prima testato la corrispondenza tra l'ID utente e l'oggetto dati.

In un team di quattro persone, se caricate il controllo di sicurezza sulle spalle di una sola persona, quella diventerà presto un collo di bottiglia. Fate in modo che la review non sia un meccanismo punitivo o di mera approvazione, ma una responsabilità condivisa. Applicate la regola del four-eyes su ogni pull request: deve essere chi revisiona, e non chi ha scritto il codice, a spuntare le voci di sicurezza una per una. Anche una semplice checklist intercetta la maggior parte degli errori già nell'ambiente di sviluppo.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

Il passo più pratico con cui potete partire già da domani mattina è inserire una sezione dedicata alla sicurezza nel template della pull request. Lo sviluppatore deve essere obbligato a spuntare caselle come "Ho validato l'input dell'utente" e "Ho aggiunto il controllo di autorizzazione" prima di inviare il codice. Anche solo queste due domande costringono il programmatore a fermarsi a riflettere prima di fare il push.

è successa la stessa cosa anche nel nostro team, siamo saltati x colpa delle librerie esterne. abbiamo collegato al repository dei tool open source gratuiti di scansione, quando trovano una falla bloccano il merge. comunque all'inizio si lamentavno tutti ma in due settimane ci siamo abituati adesso stiamo super tranquilli.

L'anno scorso abbiamo affrontato un percorso simile. Dopo aver impostato l'analisi statica automatizzata e la checklist per le pull request, al penetration test indipendente svolto sei mesi dopo il numero di criticità riscontrate è sceso a zero. I nostri tempi di review si sono allungati mediamente di soli 12 minuti per pull request. Quei 12 minuti spesi ci hanno risparmiato migliaia di dollari di costi per patch d'emergenza.

Il bypass dell'autorizzazione riscontrato nel report del pen test commissionato dal vostro cliente è avvenuto a livello di API layer o di query sul database? Se non esiste un layer di autorizzazione centralizzato sugli endpoint delle API, scrivere i controlli manualmente all'interno di ogni singola funzione continuerà a generare vulnerabilità in futuro. Avete un sistema centralizzato di Identity and Access Management nella vostra architettura?

Non fidatevi troppo degli scanner automatici. I tool di analisi statica sono ottimi per scovare vulnerabilità nelle librerie o banali falle di SQL injection, ma non riusciranno mai a vedere gli errori di business logic come il bypass dell'autorizzazione che vi è capitato. Finché qualcuno non fa un'analisi logica guardando il codice per chiedersi "l'utente A può vedere la fattura dell'utente B?", nessun software automatico vi salverà da quel report.

Riassumendo, la roadmap è chiara: 1) Integrate strumenti automatici gratuiti nella repo per scansionare dipendenze e falle di base, 2) Inserite nelle pull request un requisito di review in 5 punti focalizzato su autorizzazioni e validazione dati, 3) Affidate i controlli di business logic alla code review manuale degli sviluppatori. Non servono grandi budget, basta la disciplina.

Ho vissuto la stessa cosa.

Per un periodo ci siamo bloccati anche noi nello stesso punto. Quando prendete una decisione, scrivete anche lo scenario peggiore non solo quello migliore.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Grazie mille proverò oggi.

Salvato.

Concordo pienamente. Prendere misure senza fare un inventario lascia aperta una porta che non vedi.

Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Scrivo questo per evitare che facciate lo stesso errore. Un backup non testato non è un backup.

Il tempo che impiegate a rilevare un problema ne determina direttamente il costo. Sono curioso di sapere se qualcuno lo fa in modo diverso.

C'è un errore comune che si commette facendo questo. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Questa è la mia opinione, non la scrivo come verità assoluta.

Sono una piccola impresa, vi parlo dal mio punto di vista. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Non abbiate paura di chiedere, chi non chiede paga sempre di più.

il mio dubbio è stato chiarito, grazie.

C'è una parte che non ho capito. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Un backup non testato non è un backup. Io seguirei questa strada.