Abbiamo provato a fare un'analisi delle vulnerabilità sul nostro codice ma ci siamo bloccati: quali sono le trappole più comuni?

Configura bene la "taint analysis" (tracciamento dei dati non attendibili) nei tool di analisi statica. Segui il percorso dei parametri inseriti dall'utente per vedere se vengono sanificati prima di arrivare al database o ai comandi di sistema. Se disattivi le regole che considerano vulnerabilità SQL ogni singola concatenazione di stringhe, elimini all'istante almeno due terzi degli avvisi.

Far revisionare il codice sotto il profilo della sicurezza allo sviluppatore che non ha una formazione in merito è solo una formalità. Chi scrive il codice non può vedere i propri errori di progettazione. Se il budget è limitato, richiedere un audit esterno mirato di 2-3 giorni solo per l'autenticazione e il modulo di pagamento è molto più economico ed efficace rispetto a farlo sull'intero sistema.

Non fate di nuovo l'errore di revisionare 12.000 righe tutte insieme. Suddividete la revisione della sicurezza nelle pull request. Che non ci siano più di 300 righe di codice per ogni merge e mettete solo 5 punti critici di sicurezza nella checklist. Bisogna controllare mentre si scrive il codice, non quando lo sprint sta per chiudersi.

Alla prima scansione avevamo ricevuto 410 avvisi. Ci siamo sbattuti come matti con tutto il team per due settimane. Poi abbiamo configurato il filtro di sicurezza solo sulle 10 vulnerabilità web più critiche; il numero è sceso subito a 19. E di quei 19 riscontri, solo 4 rappresentavano un rischio reale da correggere per davvero.

i tool automatici non sanno cosa fa il codice, fanno solo pattern matching. se nelle query del database usate librerie parametrizzate eliminate già in automatico gran parte dei rischi di sql injection, non state a fissarvi su ogni singolo alert del tool x niente.

Sul nostro primo prodotto abbiamo discusso per giorni in team su complesse regole di validazione con regex, convinti di aver fatto una secure code review perfetta. Al terzo giorno dal rilascio in produzione, un cliente ha modificato l'id nel parametro dell'url ed è riuscito a scaricare il bilancio di un'altra azienda. Era proprio questo tipo di falle logiche che i tool non riuscivano a rilevare.

Ci sono tre classiche trappole in cui si cade: 1) Prendere l'output dei tool come oro colato e perdere ore dietro ai falsi positivi, 2) Far percepire la revisione di sicurezza come una valutazione delle performance dello sviluppatore innescando un atteggiamento difensivo, 3) Confondere lo stile del codice con una vulnerabilità di sicurezza.

Il succo di quanto detto è questo: alzate la soglia di allarme degli scanner automatici per ridurre il rumore, spezzettate le revisioni in parti più piccole e testate con scenari manuali le falle nella logica di autorizzazione che i tool non sono in grado di intercettare.

stavo pensando la stessa cosa. quano decidiamo senza misurare finiamo sempre nello stesso punto.

ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente. boh lascio una nota, potrebbe servire.

A me è successo l'esatto contrario, per questo scrivo. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Naturalmente cambia se la vostra situazione è diversa.

sono d'accordo.

Breve riassunto per i nuovi arrivati: Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

La sicurezza non è assoluta; significa rendere l'attacco non conveniente. Buon lavoro.

Nel nostro caso è andata così. Un backup non testato non è un backup.

Se scrivete qui il risultato, sarà utile anche ad altri.

Avete ragione sono passato anch'io per la stessa strada. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

Buon lavoro.

Concordo pienamente. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Se avete domande, scrivete, rispondo per quanto possibile.

Riassumo l'argomento, perché sono state date diverse risposte. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

sono nella stessa situazione, per questo chiedo. se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

se rimproverate i falsi allarmi, nessuno segnalerà più nulla. questa è la mia opinione, non la scrivo come verità assoluta.

Non trascurare nulla: Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Inizia con un piccolo test non impegnarti subito su tutto. Buon lavoro.