Audit del codice prima di ereditare o rifare un software: cosa controllare

L’agenzia che ha sviluppato il gestionale chiude, lo sviluppatore interno se ne va, oppure un nuovo fornitore guarda il progetto e propone di rifarlo da zero. Qualcuno in azienda deve decidere senza saper leggere il codice. Questo articolo è per quella persona: cosa controllare in un audit prima di firmare e cosa pretendere dal report.

In breve

• Prima del codice, verifica di avere in mano tutto: repository, server, dominio, database, account.
• Linguaggio, framework e librerie fuori supporto sono un rischio di sicurezza, e rimetterli in pari ha un costo da stimare.
• Senza test automatici, ogni modifica si verifica a mano o la scoprono gli utenti.
• Se una sola persona sa come si installa e si pubblica il software, quel sapere va messo per iscritto per primo.
• Riscrivere da zero è la scelta più rischiosa. A volte serve, ma va motivata.
• Il report deve dire cosa comporta ogni problema e in che ordine affrontarlo.

Prima del codice: cosa possiedi

Capita che una presa in carico si blocchi prima ancora di aprire un file. Le domande da fare sono semplici:

• Il codice è in un repository con tutta la storia delle modifiche, o hai ricevuto una cartella compressa?
• A chi sono intestati hosting, dominio, account degli store e servizi esterni (email, pagamenti, mappe)?
• Hai le credenziali amministrative del database e dei pannelli, o le ha solo il vecchio fornitore?
• Ci sono componenti a pagamento con licenza intestata a qualcun altro?
• Seguendo le istruzioni disponibili, una persona nuova riesce a installare il progetto su un computer pulito?

L’ultima è la prova più utile. Se fallisce, la documentazione manca e parte della conoscenza sta nella testa di qualcuno.

Dipendenze e versioni ferme

Ogni software poggia su componenti di terzi: il linguaggio, il framework, decine o centinaia di librerie. OWASP, la fondazione che pubblica la Top 10 dei rischi per le applicazioni web, segnala questo rischio dal 2013. Nella classifica 2025 è al terzo posto come “Software Supply Chain Failures” (OWASP Top 10:2025, A03). Secondo OWASP sei probabilmente esposto se non tieni traccia delle versioni di tutti i componenti, comprese le dipendenze delle dipendenze, e se usi software vulnerabile, non più supportato o non aggiornato: sistema operativo, web server, database, librerie.

Ogni versione di PHP ha due anni di supporto completo e due di sole correzioni di sicurezza, poi esce dal supporto (php.net). PHP 7.4 non riceve correzioni dal 28 novembre 2022, PHP 8.1 dal 31 dicembre 2025 (php.net, versioni non supportate). Anche Node.js 18 e 20 risultano a fine vita nella pagina ufficiale delle release (nodejs.org).

Cosa guardo in questa fase:

• versione del linguaggio e del framework rispetto alle date di supporto;
• il file che fissa le versioni delle librerie (lockfile): senza, due installazioni possono dare risultati diversi;
• vulnerabilità note e librerie abbandonate, con strumenti come npm audit o composer audit.

A chi decide serve sapere quanto si è lontani dalla versione supportata e quanto lavoro richiede tornarci. Duecento avvisi su librerie secondarie possono valere meno di un framework rimasto indietro di tre versioni principali.

Il codice scritto con l’AI e mai ripulito

Negli ultimi anni molto codice nasce con l’aiuto dell’AI, e nei progetti che analizzo si vede: file e funzioni molto più lunghi del necessario, codice generato e mai ripulito, le stesse parti ripetute in più punti. Anche GitClear, che produce strumenti di analisi del codice, ha esaminato 211 milioni di righe modificate tra il 2020 e il 2024 e segnala un’impennata dei blocchi di codice duplicato (GitClear).

Il costo arriva due volte. Il codice è più difficile da leggere e da correggere per chi viene dopo. E se si continua a lavorarci con l’AI, ogni modifica consuma più token del necessario, perché il modello deve rileggere tutto quel codice. Con le API anche i token letti dal modello si pagano (prezzi Anthropic).

Uso Claude Code ogni giorno anch’io, con agenti di revisione e test automatici. Il problema è il codice accettato così com’è uscito. Nell’audit segno dove si può accorciare e in che ordine conviene farlo.

Test: cosa succede quando cambi qualcosa

I test automatici controllano che il software faccia ancora quello che deve dopo una modifica. Le domande sono quattro: ci sono, girano ancora, coprono i flussi che contano (pagamenti, registrazioni, calcoli, fatturazione), e partono da soli a ogni modifica?

Un progetto senza test si può comunque prendere in carico. Si comincia scrivendo test sui flussi critici, così da fissare il comportamento attuale, e solo dopo si toccano le parti fragili. È lavoro da mettere nel preventivo fin dall’inizio.

Documentazione e conoscenza in una sola testa

Un progetto può funzionare per anni finché c’è la persona che lo ha scritto. Le istruzioni per pubblicare un aggiornamento esistono solo nella sua memoria, e certe regole di business (perché lo sconto si calcola così, perché quel campo è obbligatorio) stanno solo nel codice. OWASP lo considera un rischio anche per la sicurezza: nessuna persona da sola dovrebbe poter scrivere codice e portarlo in produzione senza il controllo di un’altra (A03).

Da verificare:

• c’è un documento che spiega come installare, configurare e pubblicare?
• esiste un ambiente di prova separato da quello reale?
• la pubblicazione è automatizzata o la fa a mano una persona?
• le regole di business principali sono scritte da qualche parte?

Sicurezza di base

Un audit del codice non sostituisce un penetration test. Leggendo il codice, però, alcune cose si vedono subito:

• Password e chiavi nel codice. OWASP nota che molte organizzazioni le tengono scritte in chiaro nel codice sorgente e nei file di configurazione (OWASP Secrets Management). Se sono finite nel repository vanno cambiate: cancellarle dal codice non basta, perché restano nella storia delle modifiche.
• Controllo degli accessi. È il primo rischio della classifica OWASP 2025, e OWASP lo ha trovato in qualche forma nel 100% delle applicazioni testate (A01). L’esempio tipico: cambiando un numero nell’indirizzo della pagina si vede l’ordine o la scheda di un altro cliente.
• Backup e ripristino. Se il software tratta dati personali, il GDPR chiede di poterne ripristinare l’accesso in tempi rapidi dopo un incidente e di verificare regolarmente le misure di sicurezza (GDPR, art. 32). Chiedi quando è stato fatto l’ultimo ripristino di prova.

Riscrivere o sistemare a pezzi

Quando un progetto è in cattivo stato, rifarlo da zero sembra la strada più pulita. Martin Fowler racconta di aver visto questo piano fallire nella maggior parte dei casi: sostituire un sistema serio richiede molto tempo, gli utenti non possono aspettare e ricostruire il comportamento esistente è più difficile del previsto (Fowler, Strangler Fig). Joel Spolsky citava Netscape, rimasta quasi tre anni senza una nuova versione per riscrivere il browser da zero: il codice vecchio contiene anni di correzioni nate dall’uso reale, e buttarlo significa perderle (Spolsky).

L’alternativa è sostituire il software un pezzo alla volta, partendo dalle parti più fragili o da quelle che cambiano più spesso, mentre il resto continua a funzionare.

Una riscrittura ha senso quando:

• la tecnologia è abbandonata e non esiste un percorso di aggiornamento;
• il software deve fare cose diverse da quelle per cui è nato, e del codice attuale si salverebbe poco;
• il progetto è piccolo, e rifarlo costa meno che capirlo;
• ogni modifica rompe qualcos’altro, mancano i test e nessuno conosce il codice.

Negli altri casi conviene di solito sistemare per gradi. Se dopo l’audit decidi di rifare tutto, lo decidi con i dati in mano.

Cosa deve darti il report

Il report serve a chi decide, quindi un elenco di difetti esportato da uno strumento non basta. Deve contenere:

1. Una sintesi di una pagina: si può lavorare su questo progetto, a quali condizioni, con quali rischi.
2. Ogni problema con la sua conseguenza, scritta in termini di azienda. “Il server usa PHP 7.4, che non riceve correzioni di sicurezza da novembre 2022” dice qualcosa; “versione PHP obsoleta” no.
3. Le priorità: cosa fare subito, cosa nei prossimi mesi, cosa può aspettare.
4. Stime di massima per ogni blocco di lavoro, così puoi confrontarle con i preventivi.
5. La risposta alla tua domanda: prendere in carico o rifare, oppure se la proposta del fornitore è sensata.
6. Una sezione tecnica separata per chi dovrà lavorare sul codice.

Chiedi anche un incontro per discuterlo, aperto al tuo team o al fornitore.

Se devi prendere in carico un progetto o valutare una proposta di rifacimento, qui trovi come lavoro: audit del codice e second opinion tecnica.