Checklist per l'audit del codice: cosa controllare e come documentarlo

Un audit del codice verifica un'intera base di codice rispetto a un elenco fisso: sicurezza, architettura, dipendenze, test, documentazione, prestazioni e gestione operativa. Una revisione del codice controlla una singola modifica prima che venga integrata. Qui trovi la checklist per l'audit, una più breve per le revisioni, i controlli sulla protezione dei dati in Svizzera che spesso vengono dimenticati e un formato per mettere nero su bianco quello che hai trovato.

È scritta per founder, CTO e titolari che stanno per ereditare del codice, acquistare un prodotto, raccogliere capitali o dare il via libera a un lancio. Non devi essere un ingegnere per seguirla. Devi però saper porre le domande giuste e riconoscere una risposta chiara.

In breve

• Un audit esamina l'intera base di codice; una revisione controlla una modifica. OWASP distingue le due cose, e anche la tua checklist dovrebbe farlo.
• Procedi per priorità: prima verifica se il progetto parte da zero, poi sicurezza, architettura, dipendenze, test, documentazione e prestazioni.
• Lascia agli strumenti la formattazione e le vulnerabilità note. Dedica il tempo delle persone alla logica di business, alle autorizzazioni e ai flussi di dati, che gli scanner non vedono.
• In Svizzera aggiungi i controlli sulla protezione dei dati: una valutazione d'impatto dove il rischio è elevato, la documentazione delle violazioni e un'informativa sulla privacy accurata.
• Ogni risultato richiede posizione, impatto, prove, gravità e una soluzione. Poi verifica che le correzioni siano state fatte.

Audit o revisione del codice: cosa ti serve?

Si cerca “code review checklist” e “code audit checklist” come se fossero la stessa cosa. Non lo sono, e confonderle fa perdere tempo.

Una revisione del codice guarda una modifica proposta, di solito una pull request. Succede più volte alla settimana, richiede da pochi minuti a un'ora e serve a impedire che una modifica sbagliata entri nella base di codice. OWASP la chiama revisione basata sulle differenze.

Un audit del codice guarda l'intera base di codice in un dato momento. Si fa una volta prima di un lancio, di un round di finanziamento, di un'acquisizione o di un passaggio di consegne, oppure una volta all'anno per i sistemi importanti. OWASP descrive la revisione di base di un'intera base di codice come un'attività distinta dalla revisione delle modifiche. Richiede giorni o settimane e si conclude con un rapporto scritto e una decisione.

La regola pratica: le revisioni evitano che la qualità scivoli, gli audit ti dicono a che punto sei davvero. Se nessuno ha mai fatto un audit del tuo codice, parti da lì. Se fai un audit ogni anno ma nel frattempo integri codice senza revisione, risolvi prima quello.

Prima di iniziare: perimetro e preparazione

La maggior parte degli audit fallisce prima ancora che qualcuno legga una riga. Chiarisci prima questi punti.

1. Definisci la domanda. “È sicuro lanciarlo?”, “Un nuovo team riesce a mantenerlo?” e “Quanto vale?” portano ad audit diversi. Scrivi la domanda all'inizio del rapporto.
2. Fissa il perimetro. Elenca repository, servizi, definizioni dell'infrastruttura e integrazioni di terzi che rientrano e che non rientrano. Un Swiss university course on code review insiste sul mantenere gestibile la quantità di codice in esame. Lo stesso vale per un audit: un perimetro ristretto fatto bene vale più di un perimetro ampio fatto in superficie.
3. Prepara il materiale. Il codice dovrebbe essere formattato e documentato quanto basta per essere letto, e le parti che richiedono un esame approfondito dovrebbero essere segnalate. In un audit si tratta delle parti rischiose: accesso, pagamenti, caricamento di file, strumenti di amministrazione e tutto ciò che tocca dati personali.
4. Raccogli il contesto. Le indicazioni di OWASP chiedono a chi revisiona di capire i requisiti di business, il modello delle minacce e le risorse critiche prima di giudicare il codice. Chiedi diagrammi dell'architettura, l'elenco degli ambienti e l'elenco di chi ha accesso a cosa.
5. Stabilisci chi legge il risultato. Un founder ha bisogno di un verdetto su una pagina. Uno sviluppatore ha bisogno dei percorsi dei file. Prevedi entrambi.

La checklist per l'audit del codice

L'ordine qui sotto non è casuale. Se il primo punto non regge, il resto conta meno.

1. Parte da un checkout pulito?

Clona il repository su una macchina che non l'ha mai visto e segui il README. Conta quanti passaggi non documentati ti servono.

• Il progetto si compila e si avvia basandosi solo sulla documentazione?
• Le variabili d'ambiente sono elencate, con valori di esempio sicuri?
• Puoi lanciare i test con un solo comando?
• Il processo di messa in produzione è scritto da qualche parte, o vive nella testa di una sola persona?

Se una sola persona sa compilare e pubblicare il prodotto, quello è il tuo primo risultato, a prescindere da com'è il codice.

2. Segreti e accessi

• Cerca nel codice attuale e nella cronologia dei commit chiavi API, password, token e chiavi private. Una chiave cancellata il mese scorso è ancora nella cronologia.
• Verifica che i segreti arrivino da un gestore di segreti o dalla configurazione dell'ambiente, non da file nel repository.
• Controlla chi ha accesso a repository, cloud, dominio e DNS. Gli ex collaboratori esterni non dovrebbero averlo.
• Sostituisci tutto ciò che è stato esposto anche una sola volta. Toglierlo dal codice non basta.

3. Autenticazione e autorizzazione

Sono due controlli diversi, e nel secondo gli strumenti aiutano meno.

• Autenticazione: come vengono memorizzate le password, quando scadono le sessioni, è disponibile l'accesso a più fattori, come funziona il reset della password?
• Autorizzazione: quando un utente autenticato chiede il record di un altro utente cambiando un ID nell'URL, cosa succede? Il controllo dei permessi avviene sul server per ogni endpoint, compresi quelli amministrativi e interni?
• I cookie di sessione hanno il flag secure e le sessioni vengono invalidate al logout?

Le indicazioni di OWASP elencano autenticazione, autorizzazione, validazione degli input, crittografia, gestione degli errori, configurazione e messa in produzione tra gli ambiti che una revisione di sicurezza deve coprire.

4. Input, output e trattamento dei dati

• Le query al database sono parametrizzate, così che l'input dell'utente non diventi mai parte di una stringa di query?
• L'output viene codificato prima di essere visualizzato, per prevenire il cross-site scripting?
• I caricamenti di file sono limitati per tipo e dimensione e salvati fuori dalla radice del web server?
• I dati sensibili sono cifrati in transito e a riposo, usando librerie standard e non crittografia fatta in casa?
• I messaggi di errore e i log evitano di far trapelare stack trace, token o dati personali?

Un breve elenco di controlli di sicurezza come questo, con segreti, query parametrizzate, codifica dell'output e gestione delle sessioni, è un minimo ragionevole. Per un lavoro più approfondito ancorati a uno standard come l'OWASP ASVS, come suggerisce la OWASP DevSecOps guideline.

5. Dipendenze e catena di fornitura

• Esiste un lockfile ed è stato committato?
• Lancia il comando di audit del gestore di pacchetti e un'analisi della composizione del software. Quante vulnerabilità note ci sono, e quante riguardano codice che gira davvero in produzione?
• Ci sono pacchetti abbandonati, non manutenuti da anni o bloccati su una versione maggiore molto vecchia?
• Tutte le dipendenze esistono e provengono dal registro che ti aspetti? Questo conta soprattutto nel codice prodotto con assistenti basati sull'intelligenza artificiale, che possono suggerire nomi di pacchetti sbagliati.
• Le licenze sono compatibili con il modo in cui vendi il prodotto?

6. Architettura e confini

• Riesci a disegnare il sistema su una pagina: componenti, archivi di dati, servizi di terzi e le linee lungo le quali i dati attraversano i confini di fiducia?
• La logica di business è in un unico posto, o è copiata tra frontend, backend e script?
• C'è un singolo punto di rottura, come un solo server, un database senza backup o una sola persona?
• I moduli sono separati abbastanza da poterne sostituire uno (il fornitore di pagamenti, il CRM) senza riscrivere tutto?
• Il progetto corrisponde ai requisiti, o è derivato verso qualcosa che il team originale non riconoscerebbe?

È qui che chi revisiona con esperienza si guadagna il compenso. Un linter non può dirti che il modello dei dati non sopravviverà ai tuoi prossimi cinque clienti.

7. Test

• La suite copre i nuovi comportamenti e i casi limite, non solo il percorso ideale?
• I test verificano i risultati invece dei dettagli di implementazione, così che il refactoring non li rompa?
• I test coprono la gestione degli errori?
• Esiste una pipeline di integrazione continua che li esegue a ogni modifica, e il team si ferma davvero quando fallisce?
• I flussi più rischiosi (checkout, permessi, esportazione dei dati) sono testati da un capo all'altro?

Le percentuali di copertura dicono poco. Un sistema con l'80 percento di copertura e nessun test sui permessi è meno sicuro di uno al 50 percento che testa le cose giuste.

8. Qualità del codice e manutenibilità

• Uno sviluppatore nuovo capisce un file tipico in pochi minuti?
• Ci sono file o funzioni enormi che nessuno ha il coraggio di toccare?
• C'è codice morto, blocchi commentati o logica duplicata?
• La formattazione è coerente e imposta da uno strumento, non dalle opinioni?

Tieni questa sezione nelle giuste proporzioni. Lo stile è il risultato meno importante di un audit, e metterlo sullo stesso piano di un buco nelle autorizzazioni nasconde i rischi veri.

9. Prestazioni e scalabilità

• Dove sono le query lente al database? Cerca le query dentro i cicli e gli indici mancanti.
• C'è qualcosa che dovrebbe essere in cache e non lo è, o qualcosa in cache che non dovrebbe esserci?
• Cosa succede con un carico dieci volte superiore a quello di oggi? Qualcuno ha provato?
• I processi in background vengono ritentati in modo sicuro, o un errore può far inviare due volte un'email o addebitare due volte una carta?

10. Configurazione, messa in produzione e monitoraggio

• Sviluppo, staging e produzione sono separati, con credenziali diverse?
• L'infrastruttura è definita come codice, così che un server perso possa essere ricostruito?
• I backup vengono eseguiti, e un ripristino è mai stato testato?
• Ci sono monitoraggio, avvisi e conservazione dei log, e qualcuno viene svegliato quando qualcosa si rompe?
• Esiste un piano di monitoraggio della sicurezza per rilevare comportamenti sospetti?

11. Documentazione e passaggio di consegne

• Ci sono un README, una panoramica dell'architettura e un elenco delle integrazioni?
• Le decisioni sono annotate da qualche parte, anche in breve?
• Una persona competente ma estranea riuscirebbe a subentrare in due settimane? Se no, dipendi da chi lo ha scritto.

Controlli svizzeri: protezione dei dati e regole di settore

Le checklist generiche arrivano dagli Stati Uniti e dall'UE e raramente menzionano la Svizzera. Se il tuo software tratta dati personali di persone in Svizzera, aggiungi questi punti.

Valutazione d'impatto sulla protezione dei dati. Secondo la Legge federale sulla protezione dei dati (LPD), il titolare del trattamento deve svolgere una valutazione d'impatto quando il trattamento previsto comporta probabilmente un rischio elevato per la personalità o i diritti fondamentali delle persone interessate. La factsheet on the DPIA dell'Incaricato federale della protezione dei dati e della trasparenza indica che deve descrivere il trattamento, valutare i rischi ed esporre le misure di protezione. La definisce anche uno strumento di lavoro proattivo per i progetti digitali, non un adempimento burocratico. In un audit, chiedi se ne esiste una per funzionalità come la profilazione, i dati sanitari o il tracciamento su larga scala, e se il codice corrisponde a quanto dichiarato.

Documentazione delle violazioni. L'Data Protection Ordinance impone ai titolari del trattamento di documentare le violazioni, e una notifica all'Incaricato deve indicare la natura della violazione, le sue conseguenze e le misure adottate o previste. Verifica che la registrazione dei log sia sufficiente per ricostruire l'accaduto. Se i tuoi log non ti dicono a quali record si è acceduto, quella notifica non puoi scriverla.

Informativa sulla privacy e realtà. La pagina dell'Incaricato su privacy statements on the internet invita i titolari ad analizzare prima i propri trattamenti e poi a rispondere a cosa viene raccolto, perché, dove e per quanto tempo viene conservato e se finisce all'estero. Nell'audit, segui ogni script di analisi, ogni modulo e ogni SDK di terzi e confrontali con l'informativa pubblicata. Le regioni cloud e i trasferimenti all'estero sono le lacune più frequenti.

Regole di settore. La Svizzera ha un quadro giuridico tecnologicamente neutro invece di una certificazione universale sullo sviluppo sicuro, come descrive questa Swiss law firm overview of cybersecurity. Quindi la checklist deve adattarsi al prodotto e ai dati. La stessa panoramica rileva che eHealth Suisse si aspetta che il software medico definisca la sicurezza in fase di progettazione, svolga un'analisi dei rischi e documenti verifica, validazione, aggiornamenti e protezione dei dati sensibili. I clienti del settore finanziario, sanitario e pubblico aggiungono di solito requisiti contrattuali, quindi chiedili prima che l'audit cominci.

Se il tuo sito è pubblico e vuoi un secondo parere sulla sua esposizione, alcuni website security checks possono completare la revisione a livello di codice.

Automazione e giudizio umano

Un buon audit usa entrambi, e sa quando usare l'uno e quando l'altro.

Gli strumenti sono bravi nel lavoro ripetitivo: formattazione, analisi statica, dipendenze con vulnerabilità note, schemi dei segreti. Le Sourcegraph’s review guidance fanno lo stesso discorso anche per le revisioni: automatizza ciò che si ripete, così le persone possono concentrarsi su progettazione e logica.

Per il resto servono le persone. OWASP afferma che gli strumenti automatici SAST e DAST completano, non sostituiscono, la revisione umana, perché la logica di business, il contesto dei flussi di dati e i controlli di sicurezza complessi richiedono qualcuno che capisca il prodotto. Uno scanner non si accorgerà che un codice sconto può essere usato un numero illimitato di volte, o che un endpoint delle fatture restituisce la fattura di un altro cliente.

Usa prima gli strumenti per ottenere una mappa, poi leggi il codice dove la mappa dice che conta.

La checklist breve per le revisioni del codice

Per le pull request di tutti i giorni, tieni l'elenco entro una schermata. Le checklist lunghe vengono ignorate.

Controllo	Domanda da porsi
Requisiti	La modifica fa quello che chiedeva il ticket, e nient'altro?
Correttezza	I casi limite e i percorsi di errore sono gestiti?
Leggibilità	Qualcuno di nuovo la capirebbe senza l'autore accanto?
Test	I nuovi comportamenti e i casi limite sono coperti, con verifiche sui risultati?
Sicurezza	Ci sono nuovi input, permessi, segreti o query da guardare più da vicino?
Architettura	Si inserisce nel progetto esistente, e cos'altro tocca?
Gestione operativa	Richiede una modifica alla configurazione, una migrazione o del monitoraggio?

Due abitudini fanno funzionare il tutto, entrambe descritte nella Sourcegraph’s review guidance. Metti prima i problemi bloccanti e segnala i commenti sullo stile come dettagli, così l'autore sa cosa deve cambiare davvero. Il materiale del corso dell'ETH aggiunge che autori e revisori dovrebbero avere ciascuno una propria checklist, che la discussione deve restare sui difetti tecnici e che il team dovrebbe annotare i difetti e tornarci sopra per confermare che siano stati corretti.

Un avvertimento: considera qualsiasi checklist un promemoria, non un sostituto del giudizio, e aggiornala quando il team impara qualcosa. Se un bug è passato, aggiungi la domanda che lo avrebbe intercettato.

Come documentare i risultati

Un audit vale quanto ti permette di fare il rapporto. Usa la stessa struttura per ogni risultato, seguendo le indicazioni di OWASP sulla rendicontazione:

1. Componente e posizione: il servizio, il file e la riga.
2. Problema: cosa non va, in una o due frasi.
3. Impatto: cosa potrebbe succedere, in termini di business.
4. Prove: passaggi per riprodurlo, una richiesta, uno screenshot o un estratto di codice.
5. Gravità: critica, alta, media o bassa, con un criterio dichiarato per ciascuna.
6. Rimedio: cosa cambiare, in modo abbastanza preciso da poterlo stimare.

Poi aggiungi una pagina di sintesi: il verdetto sulla domanda che hai posto all'inizio, i cinque rischi principali e un ordine di lavoro di massima. Raggruppa i risultati in “da sistemare prima del lancio”, “da sistemare questo trimestre” e “accettare e tenere d'occhio”.

Infine, torna sui risultati. Annota i problemi in un rapporto e verifica in seguito che ogni difetto sia stato corretto, come dice il materiale dell'ETH. Ricontrolla di persona i punti critici e ad alta gravità, invece di fidarti di un aggiornamento di stato.

Un esempio concreto: audit prima di una raccolta di capitali

Immagina di essere un founder con un prodotto funzionante costruito da due freelance, e un investitore chiede una due diligence tecnica. Hai una settimana.

• Giorno 1: checkout pulito, ricerca dei segreti ed elenco degli accessi. Se uno dei due non regge, sistemalo prima che lo guardi qualcun altro.
• Giorno 2: autorizzazioni su ogni endpoint che restituisce dati degli utenti. Prova con due account.
• Giorno 3: scansione delle dipendenze, lockfile e licenze.
• Giorno 4: schizzo dell'architettura, test di backup e ripristino, prova completa della messa in produzione.
• Giorno 5: test, documentazione e le domande sulla protezione dei dati: la tua informativa sulla privacy corrisponde ai tuoi tracciatori?
• Giorni 6 e 7: scrivi il rapporto, dividi i risultati in tre gruppi e correggi i punti critici che costano poco.

Non troverai tutto. Troverai le cose che l'ingegnere di un investitore trova nella prima ora, ed è quello che ti serve.

Quando coinvolgere qualcuno dall'esterno

Fai tu il primo giro, se sai leggere il codice. Coinvolgi un revisore esterno quando non sei indipendente (lo hai scritto tu o paghi chi lo ha scritto), quando la posta in gioco è alta (un round di finanziamento, un'acquisizione, dati regolamentati) o quando nessuno nel team ha esperienza senior su quello stack.

In Ampersand facciamo audit e due diligence tecniche come parte del nostro lavoro di consulenza, e le persone che svolgono l'audit sono gli stessi ingegneri senior che poi sistemerebbero quello che emerge. Siamo un piccolo studio di Zurigo e tra i nostri clienti ci sono UBS e la Città di Lugano. Se vuoi vedere come lavoriamo prima di decidere, il nostro portfolio dello studio mostra i progetti recenti, e la pagina dei prezzi elenca le formule di collaborazione. Il nostro piano Guidance è indicato a CHF 799 al mese e Run & monitor, il nostro piano di supporto continuativo, a CHF 750 al mese. Gli audit e gli altri incarichi vengono definiti caso per caso, quindi la pagina non ne indica il prezzo. Se preferisci imparare il processo e svolgere tu stesso gli audit, puoi chiederci di impostarlo come percorso di affiancamento.

Domande frequenti

Qual è la differenza tra un audit del codice e una revisione del codice?

Una revisione del codice controlla una singola modifica, per esempio una pull request, prima che venga integrata. Un audit del codice esamina l'intera base di codice in un dato momento, di solito prima di un lancio, di una vendita o di un passaggio di consegne. OWASP tratta la revisione dell'intera base di codice e quella basata sulle differenze come due attività distinte.

Ogni quanto conviene fare un audit del codice?

Fai un audit prima degli eventi importanti: un lancio, un round di finanziamento, un'acquisizione, un cambio del team di sviluppo. Per i sistemi che contengono dati sensibili, un audit annuale è un ritmo ragionevole. Nel frattempo rivedi ogni modifica, così l'audit troverà uno scostamento e non una pila di sorprese.

Gli strumenti automatici possono sostituire un audit manuale del codice?

No. Gli scanner gestiscono bene formattazione, vulnerabilità note e schemi ricorrenti. Le indicazioni di OWASP dicono che la revisione umana resta necessaria per la logica di business, le autorizzazioni legate al contesto e l'architettura, che gli strumenti tendono a non vedere. Usa gli strumenti per capire dove far guardare le persone.

Le aziende svizzere devono fare un audit del codice per la protezione dei dati?

La LPD non impone un audit del codice in quanto tale. Impone però una valutazione d'impatto quando il trattamento comporta probabilmente un rischio elevato, la documentazione delle violazioni e un'informativa sulla privacy accurata. Un audit del codice è un modo pratico per verificare che il software faccia davvero quello che quei documenti dichiarano.

Fonti

• OWASP
• OWASP DevSecOps guideline
• Swiss university course on code review
• Sourcegraph’s review guidance
• factsheet on the DPIA
• Data Protection Ordinance
• privacy statements on the internet
• Swiss law firm overview of cybersecurity