Sicurezza nel software custom: standard e best practice

"Il software è sicuro?" è una domanda apparentemente semplice con una risposta complessa. La sicurezza non è uno stato binario: è uno spettro che dipende da rischi specifici, contesto d'uso, dati gestiti. Un sito vetrina ha esigenze diverse da un'app bancaria.

In questa guida vediamo cosa significa davvero costruire software sicuro, quali livelli di protezione sono ragionevoli per ogni tipo di progetto, e come riconoscere un approccio professionale dalle promesse vuote.

I tre livelli di sicurezza

Distinguiamo per chiarezza tre livelli, applicabili in proporzione alla criticità del sistema:

Livello 1: baseline (obbligatorio per tutti)

Quello che qualunque software professionale deve avere, indipendentemente dal caso d'uso:

• HTTPS ovunque
• Password con hashing forte
• Validazione di tutti gli input utente
• Configurazione corretta degli header HTTP
• Aggiornamento regolare delle dipendenze
• Conformità GDPR base

Senza questi, il software non è "professionale" in nessun senso ragionevole del termine.

Livello 2: standard (per business application)

Quello che si aggiunge per software che gestisce dati di utenti reali:

• Rate limiting e protezione brute-force
• Crittografia dati sensibili a riposo
• Audit log delle operazioni critiche
• Gestione robusta degli errori senza esposizione informazioni
• Monitoring attivo con alert
• Backup automatici testati
• Procedura di incident response

Se gestisci dati di clienti, devi avere questi standard.

Livello 3: avanzato (per dati ad alto rischio)

Per progetti regolamentati o ad alto rischio (sanità, fintech, infrastrutture critiche):

• Penetration test periodici
• Audit di sicurezza esterni regolari
• Crittografia avanzata (es. database completamente cifrato)
• Multi-factor authentication obbligatoria
• Segmentazione di rete avanzata
• Conformità a standard specifici (ISO 27001, PCI-DSS dove applicabile)
• Disaster recovery con RPO/RTO definiti

Tabella applicabilità per tipo di progetto

Le 6 pratiche trasversali che applichiamo

Indipendentemente dal livello richiesto, queste sei pratiche le applichiamo sempre:

1. Security by design

Le decisioni di sicurezza vengono prese durante il design, non aggiunte dopo. Quale schema di autenticazione? Dove vivono i secret? Come si gestiscono le sessioni? Tutto deciso prima della prima riga di codice.

2. Code review con focus sicurezza

Ogni modifica significativa al codice passa attraverso review di un secondo paio di occhi. Una checklist specifica include controlli di sicurezza standard: input validation, autorizzazione, gestione errori, logging.

3. Audit dipendenze automatico

In ogni pipeline di build c'è un audit automatico delle dipendenze. Vulnerabilità note vengono segnalate immediatamente, prima del deploy.

4. Test di sicurezza dedicati

Oltre ai test funzionali, scriviamo test che verificano specificamente i comportamenti di sicurezza: accesso non autorizzato negato, input ostili rifiutati, errori gestiti senza esposizioni.

5. Deploy con principio del minimo privilegio

Ogni componente del sistema (server, database, servizi) ha solo i permessi strettamente necessari. Niente "tutto può tutto" per comodità.

6. Monitoring attivo post-lancio

Anche il software meglio testato può essere oggetto di tentativi di attacco. Il monitoring continuo è la prima linea di difesa attiva: alert su pattern sospetti, log analizzabili, capacità di reagire rapidamente.

Come riconoscere un fornitore serio sulla sicurezza

Cinque domande da fare prima di firmare:

1. "Come integrate la sicurezza nel processo di sviluppo?" — risposta vaga ("seguiamo best practice generali") = non serio. Risposta specifica con esempi concreti = serio.

2. "Cosa fate quando trovate una vulnerabilità in produzione?" — deve esistere una procedura nota, scritta. Non improvvisazione.

3. "Cosa è incluso nell'audit finale di sicurezza?" — l'audit non deve essere un'extra costoso ma parte standard del progetto.

4. "Come gestite i secret applicativi?" — vault, variabili d'ambiente, mai in codice committato. Risposta diversa = problema.

5. "Cosa firmate prima di accedere al nostro repository?" — NDA è il minimo. Senza, è un campanello.

Errori comuni che vediamo nei progetti che ereditiamo

Quando subentriamo su progetti sviluppati da altri, troviamo regolarmente:

1. Credenziali in codice committato

Chiavi API, password database, token di accesso in file .env versionati. Disastro: qualunque persona con accesso al repo (anche un ex-collaboratore) ha accesso a sistemi produttivi.

2. Validazione input solo nel frontend

L'utente vede il messaggio "campo obbligatorio", ma il backend accetta qualsiasi cosa. Risultato: bypass banale chiamando l'API direttamente.

3. Sessioni che non scadono mai

Una volta loggato, sempre loggato. Anche dopo mesi. Anche dal computer di un internet point.

4. Backup non testati

Backup automatici configurati, ma nessuno ha mai provato a usarli. Quando serve davvero, scoprono che il backup è incompleto o non utilizzabile.

5. Tutti gli utenti sono admin

Modello di permessi semplificato: chi è loggato può fare tutto. Quando un utente normale viene compromesso, l'attaccante eredita poteri amministrativi.

Conclusione

La sicurezza nel software non è un livello binario "sicuro/insicuro": è uno spettro proporzionato al rischio. Un software ben progettato applica il livello giusto di protezioni per il proprio contesto, senza over-engineering ma anche senza scorciatoie pericolose.

La differenza tra un fornitore professionale e uno improvvisato la si vede esattamente qui: il professionista parla di sicurezza al kickoff, non al go-live.

Investire in sicurezza è il modo più economico di gestire un rischio che, se ignorato, costa esponenzialmente di più. È matematica, non opinione.