Abbiamo preso in carico il codice lasciato dall'agenzia: come fare una revisione sicura del codice e da dove iniziare?

La primissima cosa da fare subito è ripulire la cronologia di Git. Anche se cancellate la password dal file di codice e fate un nuovo commit, quei dati restano visibili in chiaro per sempre nella cronologia dei commit. Usate scanner open source per i segreti su tutta la history, riscrivete la cronologia rimuovendo le credenziali e cambiate immediatamente quelle password sui server.

Già da domani fate lanciare al vostro sviluppatore il comando nativo di security audit del vostro package manager. Su librerie vecchie di due anni ci saranno sicuramente dozzine di bollettini di sicurezza critici già noti. Solo aggiornare i pacchetti alle versioni stabili e recenti eliminerà all'istante metà dei vostri rischi.

Anche noi l'anno scorso abbiamo lanciato un'analisi statica su un progetto da 30 mila righe appena ereditato. Il sistema ha generato 142 possibili avvisi; analizzandoli, il nostro dev ha trovato 8 falle reali che avrebbero potuto causare direttamente una fuga di dati dal DB. Per sistemare quelle 8 falle ci sono voluti appena tre giorni.

Non fate troppo affidamento sui tool di analisi automatica, rischiate di annegare tra centinaia di falsi positivi in report da migliaia di righe. I data leak più gravi non derivano dalle vulnerabilità delle librerie, ma dai banali errori di controllo sessione che lo sviluppatore dell'agenzia ha trascurato pensando "tanto chi vuoi che ci provi". Concentratevi sui test logici manuali.

un'agenzia che hardcoda le password quasi sicuramente non ha guardato manco la parte di upload file. testate subito se quando il cliente carica i documenti si riesce a piazzare un eseguibile php dietro, quella è la porta più pericolosa di tutte.

Registrate i risultati emersi all'interno di una matrice di rischio di sicurezza aziendale. Classificate le vulnerabilità come critiche, alte e medie. Mantenere il sistema attivo in produzione per i clienti prima di aver risolto le criticità che minacciano direttamente il database e la privacy degli utenti può comportare gravi responsabilità legali.

Riaprite il contratto stipulato con l'agenzia e dategli un'occhiata. Nella maggior parte dei contratti è presente una clausola di garanzia, implicita o esplicita, che prevede la consegna del codice in conformità agli standard di settore e alle pratiche di sicurezza di base. Hardcodare le password nel codice costituisce un chiaro vizio del servizio; potreste avere il diritto di inviare una diffida formale all'agenzia per richiedere i dovuti fix.

come fanno i tool di analisi statica del codice a verificare il codice senza eseguirlo? in che modo riescono a capire esattamente se una funzione contiene una vulnerabilità senza installarla su un server di produzione e senza connettersi al database?

Non ho alcuna esperienza in materia di revisione sicura del codice, quindi chiedo. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Inizia con un piccolo test, non impegnarti subito su tutto. Se avete domande, scrivete, rispondo per quanto possibile.

mi chiedo anch'io.

Questo approccio ha un costo, di cui non si parla. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Se avete domande, scrivete, rispondo per quanto possibile.

Stavo pensando la stessa cosa. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Io seguirei questa strada.

Ho vissuto la stessa cosa. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

È tutto, scusate se mi sono dilungato.

Stavo pensando la stessa cosa. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi. Lascio una nota, potrebbe servire.

tre cose da controllare mentre lo fai ma le persone difendono le abitudini, non i processi. la resistenza nasce da lì.

Sono nella stessa situazione, per questo chiedo. onestamente se permessi e ambito non sono scritti quel test non deve iniziare.

Nessun processo migliora senza tracciamento perché non sai cosa correggere... Questa è la mia opinione non la scrivo come verità assoluta.

A me è successo l'esatto contrario, per questo scrivo. L'errore commesso da revisione sicura del codice è generalmente reversibile ma costoso.

Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Il mio dubbio è stato chiarito, grazie. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

Se avete domande, scrivete rispondo per quanto possibile.